Hacker News Reader

We actually don't know that the world is stateful. Quantum physics would tend to suggest that the world is a waveform function that collapses on a discrete value when evaluated. If you think about it the current 'state' of the world should entirely depend on how the previous functions collapsed to produce the current 'state'.

Perhaps like in physics there is a sort of Church-Turing duality to it all that is hard to tease apart.

The reality is stateful on a macro-scale. I find the idea that the universe is actually stateful, and we do not completely understand behavior at quantum level far more parsimonious than the converse.

The double slit experiment confirms the wavelike nature of the universe at macro scale. A completely stateful universe where a photon discretely moves through spacetime could not exhibit self interference, only if the photon takes all paths (suggesting 'functions' that describe its movement) could it then collapse into a discrete position after being observed (aka. evaluated)

What I'm getting at is that in between emission and observation the photon is not in any one state, at best it's state could be described as a superposition.

To take the analogy one step too far, perhaps worst of all this suggests a lazily evaluated haskellian universe with a giant state monad whose NUMA architecture updates at the speed of light.

I hesitate to admit photons into the macro realm, considering they are elementary particles and essentially massless.

Given the de Broglie hypothesis, I must of course admit macroscopic objects do have wavelengths, and thus macroscopic uncertainty (your statelessness) is a nonzero vlue. For all intents and purposes though, the denominator of the equation causes the wavelength to go very close to 0, as the mass value dwarfs the Planck constant and velocity is always non-zero due to brownian motion.

Wave function collapse is interesting and I must admit when it is not induced by momentum, I don't understand it very well.

>Very few processes want to be parallel.

Maybe, but IMO it's often that the abstractions used to build software suck at it. Consider for example UI programming, the UI thread and event loop are hacks done because of lack of tools, performance with the current ones, and legacy environment/design. There is no reason why every event cannot be executed parallel, manipulated as push collections and have event handlers that perform application state transitions as transactions.

>and being able to reason about necessary state is how you do anything useful

I agree, and two parts need to be stressed in this, being able to reason and necessary state. Immutability/values make reasoning part transparent and necessary state is isolated in separate abstractions that again simplify reasoning about them.

I don't know how this applies to Haskell, but from playing with Clojure I can definitely see the advantages of working with values, even with single threaded programming reasoning is much simpler, and state is isolated in to Var/Ref/Atom/Agent primitives that have clear usage patterns and clean semantics (no gotchas with compiler reordering some instruction for lockless programming, no worry about lock acquisition order, etc.)

In my opinion, there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling. Processes that are so CPU intensive they cause the GUI to lag are uncommon (and easily dealt with when they do occur). Even if a re-engineering of the GUI event architecture did occur, that would be a systems level issue, and most developers could remain oblivious.

I like Clojure, I think Rich did a great job with the data structures. My only gripe is that it would be a lot more elegant if the notion of transients went away completely. I think transactions with automatic commit and branching on reference creation would be much nicer (and faster). Still a very well engineered language by and large.

>there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling

Sure but you do agree that the event loop/thread lock is a cumbersome hack due to the system constraints. If the system was based on clojure/functional concepts (with lw threads) it would be natural to implement it that way. And it would hardly be transparent, you deal with event loops and UI thread lock in explicitly.

My experience in user interface coding (though not really my favorite area) has been that event handling is pretty much code and ignore, until you want to do some big nasty thing, at which point you have to implement a callable/runnable interface (in java), queue things up and do some synchronization. This seems to be less of an issue in the browser, though I haven't looked at the implementation details.

I do agree that having some kind of multi-threaded greenlet/fiber dispatcher would be more efficient and handle corner cases better. I just don't think your average developer would notice a huge difference.

Most people write sequential software.

Do you have any proof of this? Because all you need to do to turn that sequential software into parallel software is run it in a web server. In fact, with emphasis on UI responsiveness on the frontend and scalability on the backend, I would be willing to bet the majority of programmers are writing parallel software. But I'm willing to let you prove me wrong with data.

If you're talking about single process cgi/wsgi/node-style-eventloops, the composition of sequential software is still effectively sequential if the data is disjoint. If you have non-disjoint data and a single process environment, then you do have to consider shared mutable information at some point in your architecture. This is mitigated by the fact that shared mutable information in the web domain is typically handled by a database or information store of some kind designed for concurrent use. I am going to make the somewhat bold claim that if you store shared, mutable data in the web application process you are doing it wrong (and for other reasons besides just this one).

I'm sorry, but I simply have no idea what you're talking about. I'm sure it's just me being an idiot, but I'm lost whenever we talk about "composition of sequential software with disjoint data". Could you explain this to me like I'm an 8-year-old?

Sorry, I'm a math person, I use math terms out of habit :)

Your initial statement was that if you take a single threaded program and run multiple instances of it in a single process (composition of sequential software), concurrency issues appear even for programmers working on sequential processes. I wanted to clarify that this is only the case when variables that are modified as part of execution are shared between them. If no variables modified as part of program execution are shared, this is equivalent to saying the data of the programs are disjoint.

To get down to web-level nitty gritty: If you modify global or module level variables, you will run into trouble. If you keep variable that will be modified in a scope specific to the request you are currently handling, and persist objects using an information store designed for concurrency, you will be fine. Avoiding mutable global variables and using specialized data stores have been best practices in coding for a long time.