5 ms·

While I agree with some things the author says, his conclusions are bullshit. Very few processes want to be parallel. People who primarily do parallel program

While I agree with some things the author says, his conclusions are bullshit. Very few processes want to be parallel. People who primarily do parallel programming think everything needs to be parallel, so they assume everyone must be going through the pain they are going through. This is false. Most people write sequential software. Another issue is that purely functional programming is fundamentally flawed, because it attempts to eschew state. Many functional programmers will call this a virtue, but the world is stateful, and being able to reason about necessary state is how you do anything useful. Purely functional programming is great when you want a convenient test-bed for ideas, but Haskell as a practical programming language is a horrible idea. Ultimately, what we want is to eliminate unnecessary state, while reasoning about necessary state. Modern programming language researchers are doing this under the guise of "effects systems", however most of the research I've seen far has left me underwhelmed. Eventually functional programming researchers are going to end up somewhere that is quite far from where they started, but just a few small steps from logic programming.

fleitz 15y ago
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.
- NathanRice 15y ago
  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.
  - fleitz 15y ago
    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.
    - NathanRice 15y ago
      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.
moonchrome 15y ago
>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.)
- NathanRice 15y ago
  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.
  - moonchrome 15y ago
    >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.
j_baker 15y ago
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.
- NathanRice 15y ago
  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).
  - j_baker 15y ago
    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?
    - NathanRice 15y ago
      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.

fleitz 15y ago

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.

NathanRice 15y ago
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.
- fleitz 15y ago
  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.
  - NathanRice 15y ago
    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.

moonchrome 15y ago

>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.)

NathanRice 15y ago
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.
- moonchrome 15y ago
  >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.

j_baker 15y ago

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.

NathanRice 15y ago
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).
- j_baker 15y ago
  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?
  - NathanRice 15y ago
    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.