Threads for sridatta

  1. 2

    Compared to other decentralized architectures, these folks seems to be “underselling” their idea. Why are you introducing this as an issue tracker for software development?

    This is much more general purpose, like a kind of distributed object protocol.

    1. 5

      Very confusing since is also on the front page and its related project is called Volt.

      1. 3

        He probably got it from my comment in that thread. One reason I didn’t submit it yet was to avoid confusion. I also wanted to dig into the site to assess if vaporware, a throwaway project, etc. I didn’t have time yet.

        1. 3

          Volt is 9 years old. Can’t blame them!

        1. 4

          This is a much needed perspective on tech to balance the generally libertarian bent of Silicon Valley.

          But I was a bit put off by the fanboyism displayed about communism/the left. I was hoping for a more nuanced discussion about how current trends relate to particular theories. Think a left leaning version of Ben Thompson’s Exponent podcast.

          Anyway best of luck! I’ll keep listening.

          1. 4

            Why is this a flexible goal? What will you do with the money if it doesn’t hit the $10K minimum needed for the venue?

            1. 1

              The $10k minimum needed for the venue was not something I was aware of when I set this up. I will reach out to the organizers and see if they can answer.

              1. 1

                There’s also fundraising going on outside of the Indiegogo in the form of sponsorships, so it’s very possible that the Indiegogo might not reach $10K but the sponsorships cover the gap.

              1. 15

                Something like Smalltalk is enabled by dynamic typing. It would be hard (impossible?) to build a statically typed self-modifying environment because you cannot know a priori all the types of objects that will be created.

                Although this may be more to do with the idea of message passing than types. You could have a static typechecker for Smalltalk, but the only interface you can expect of objects outside your control is that they can receive messages. For anything else, you have to wait until runtime to ask them.

                Which brings me to a side thought… message passing-based OOP is basically the weakest of typing. This is ironic considering how modern OOP is often associated with cumbersome static typing.

                1. 6

                  It would be hard (impossible?) to build a statically typed self-modifying environment because you cannot know a priori all the types of objects that will be created.

                  While I agree for the most part, the various versions of the Oberon system are self-modifying with an extensible static type system. They’re elegant in their simplicity.

                  1. 4

                    I don’t agree that this needs to be the case. There are many ways it could be implemented - static typing doesn’t have to mean destruction of the image if there’s a type failure. It could simply tell you that a specific method invocation isn’t expected to work, yet still generate the bytecode that will fail at run-time (and wouldn’t JIT, one would imagine)

                    1. 4

                      Something like Smalltalk is enabled by dynamic typing.

                      No. See StrongTalk, which is a statically typed SmallTalk.

                    1. 14

                      I think that graph would be a lot more useful with some competitors for context.

                      Anyways, I mostly submitted to talk about how the “taking over” feels as I’ve been doing React the last month or so. As in this example, adding a first component to a page feels a little clunky until it’s updating, then it’s sort of magical. The second or some sub-components are really a breeze.

                      But! React is intensely tied to the DOM and hierarchically-oriented. So the moment you want to have two components that interact with each other (perhaps fetching/posting data in bulk), React requires that they share a parent component or one be the parent of the other.

                      Instead of trying to sync the state between different components, you should rely on the top-down data flow.

                      Because “The Data Flows Down”, if the two interacting components are widely-separated on the page (say, the row of a message in your inbox and a header indication of new messages), React wants you to have a top-level component owning and directing that data through the entire page. And because a component in a sense is a DOM element, it wants to own the rendering of the page as well. You get a finger-wagging (but informative) error message if you try to have one component update another from its render.

                      So my React experience has been:

                      • Week 1: Huh, this is weird. I wish the docs weren’t an afterthought.
                      • Week 2: OK, this makes sense, and it’s a great solution to jQuery soup.
                      • Week 4: Damn, either I have a stop-the-world rewrite of everything or a godawful hack.
                      1. 6

                        Week 4: Damn, either I have a stop-the-world rewrite of everything or a godawful hack

                        Full disclosure: I am not a pro frontend programmer, but I’ve tried many frameworks and libraries (following their guidelines and philosophies), and I always end up at this stage :-( I just stopped doing frontend for fun and went back to server rendered apps.

                        1. 3

                          React wants you to have a top-level component owning and directing that data through the entire page.

                          You might have tried these by now but the whole idea behind Flux/redux is to decouple app level state from components/DOM.

                          What do you think of that approach?

                          1. 1

                            I’ve done about 18 months of work with react, some with flux and some without.

                            I would avoid flux until well after you are sure you need it.

                            There are much simpler patterns that solve most of the same problems.

                            1. 1

                              I’m looking at it and will probably fall into it. I’m reluctant because of the high complexity and generally poor documentation I’m finding, but it looks like the only viable choice for my environment.

                            2. 2

                              I don’t know what your constraints are, and I don’t want to be the “re-write it in X” guy, but have you looked at Elm at all? I’ve found the process of building out apps in small pieces with it to be much like your description of working with React, but it’s not constrained to the component approach. I haven’t built anything large enough with it to say whether or not it has the same “Week 4” issue, but I’d suspect it’s much easier to go from “godawful hack” to well-structured code thanks to the type system and excellent compiler messages. All told, I’m quite impressed with it so far. It seems to have many of the same advantages as React, without some of the pitfalls that come with JS. All of that comes at the cost of a learning curve that’s a bit steeper, and a less robust set of libraries to draw from.

                              Caveat: My React and Elm projects have all been fairly small and narrow in scope.

                              1. 2

                                My constraints are that I don’t get to pick the technology on this one.

                                1. 2

                                  That’s fair. In that case, I suppose I’ll re-frame my comment to something along the lines of “If you come away from this project mostly liking React, but finding shortcomings with it, maybe look at Elm next time you get to pick the tech.”

                                  I’d also second @sridatta’s comment below recommending Redux if it’s not something you’re using already. I think it could be a clean path for resolving the issue with disparate components that need to update based on the same logical state. I haven’t tried mixing it with stateful React components, but I think it wouldn’t be too difficult to bring it in for a portion of the app, and gradually grow it out to be the primary manager of application state over time.

                                2. 1

                                  Hijacking this comment to offer another option:

                                  Basically a statically typed wrapper around React using Dart. It’s pretty slick. I can also be used with a Flux-like library (

                                  I personally like Dart a lot, not everyone does. I also like Elm. It finally feels like we have “good” choices for front end development :-)

                                3. 1

                                  Sounds like you need better state managing. You should check out redux if you haven’t yet.

                                1. 10

                                  If there’s implicit trust, you don’t need the cryptographic overhead of a blockchain. In fact, your blockchain is just distributed, append-only request log which you can accomplish with Kafka. Wallets are just serving as a resource allocation mechanism which you can accomplish with Mesos or Kubernetes.

                                  This idea may make sense if you have a shared cluster that you want to open up to the world.

                                  1. 1

                                    I think public APIs requiring a proof-of-work would be rather cool. There are a few ways to do this so far but they don’t work in all situations. For example, to avoid amplification attacks, and API can require that the send send as many byte as there response will be.

                                  1. 8

                                    This is not so much puts debugging. It looks like Ruby provides enough introspection that its runtime can be used to debug itself. Even coming from a Python background, I was surprised to see that so much of this was possible.

                                    1. 1

                                      I never had a Game Genie / GameShark as a kid but this is still a great overview of how the NES worked. I’d be super interested to read a more in depth article about the NES/SNES hardware if anyone knows of one.

                                      1. 3

                                        This is an interesting overview of NES emulation and how it relates to the hardware:

                                        1. 1

                                          You could start with emulators people are writing. Brit Butler has been working on a 6502 emulator in Common Lisp, and has plenty of notes.