3 ms·

sigh From the article: Now, before you jump up and down and tell me that "insert-your-favourite-concurrency-model-here addresses these problems", I know there

by gdp 17y ago

sigh From the article: Now, before you jump up and down and tell me that "insert-your-favourite-concurrency-model-here addresses these problems", I know there are strategies for managing the complexity of these tasks. I did concurrency theory for a living, so I know some approaches are better than others. My point here was essentially to illustrate why it is important to manage complexity when doing concurrency. It's definitely not just a case of "you can't do concurrency so that means you are stupid". I'm arguing that pretty much everyone is bad at concurrency beyond some simple patterns of interaction that we cling to because we can maintain a good mental model by using them. To elaborate, things like the technologies you mentioned may provide better mental models for concurrent development, but I'm not convinced that they have solved concurrency in its entirety.

swannodette 17y ago
I noted that from the article. But nowhere did you mention how these languages fail to allow for complex concurrent modeling, which they do. You simply discussed your viewpoint without context for how these languages do not competently allow for massively concurrent programs- that's what they're designed to do. And I'm not saying they solve "concurrency in it's entirety". I'm not even clear what you're trying to express with that statement.
- gdp 17y ago
  Let me clarify: I'm a big fan of most of the languages you've described. I think they do a really good job in the problem domains they are designed for. My only point is that the domains they are designed for are constrained. I don't mean this as a negative - I consider a general pthreads-style implementation of concurrency to be constrained by the ability of people to reason about that kind of concurrency, probably to a much larger degree than a considerably more elegant implementation in a modern functional programming language. I would argue, however, that such languages simply make it easier to construct concurrent programs that follow certain patterns. They provide useful abstractions for managing the complexity of concurrent interactions, which I think was my original point, and which I think is brilliant! What is missing is something that provides good-quality abstractions, high-quality static analysis and very strong safety guarantees in the general case. Think about things like mobile processes, "ubiquitous computing" and software with huge failure tolerances by virtue of being able to reconfigure and coalesce resources at will. And hopefully the flow-on effect of that would be to essentially stop horrible concurrency implementations being used in languages like Java and friends.
  - swannodette 17y ago
    "I think they do a really good job in the problem domains they are designed for." The problem domain of concurrency? "What is missing is something that provides good-quality abstractions, high-quality static analysis and very strong safety guarantees in the general case." They have excellent abstractions and great safety guarantees. Not sure what you mean by static analysis. A concurrent program is non-deterministic, what is going to go under static analysis? I'm sorry if I'm misunderstanding something here. "software with huge failure tolerances by virtue of being able to reconfigure and coalesce resources at will." Wasn't this the whole point of Erlang? You know like telecom switching?
    - gdp 17y ago
      A very similar point was made in the blog comments, but I'll restate my response here in brief: Concurrency is hard even when you're just using a pencil and a piece of paper. If you write down a description of a system using any kind of simple notation, it will be difficult for me or anyone else to read that an have a good intuition about the runtime behaviour of that system. This isn't a discussion of statefulness or mutability. It's just about the presence of a very large number of interactions that essentially defy any usual sense of causality.

by gdp 17y ago

swannodette 17y ago

I noted that from the article. But nowhere did you mention how these languages fail to allow for complex concurrent modeling, which they do. You simply discussed your viewpoint without context for how these languages do not competently allow for massively concurrent programs- that's what they're designed to do. And I'm not saying they solve "concurrency in it's entirety". I'm not even clear what you're trying to express with that statement.

gdp 17y ago
Let me clarify: I'm a big fan of most of the languages you've described. I think they do a really good job in the problem domains they are designed for. My only point is that the domains they are designed for are constrained. I don't mean this as a negative - I consider a general pthreads-style implementation of concurrency to be constrained by the ability of people to reason about that kind of concurrency, probably to a much larger degree than a considerably more elegant implementation in a modern functional programming language. I would argue, however, that such languages simply make it easier to construct concurrent programs that follow certain patterns. They provide useful abstractions for managing the complexity of concurrent interactions, which I think was my original point, and which I think is brilliant! What is missing is something that provides good-quality abstractions, high-quality static analysis and very strong safety guarantees in the general case. Think about things like mobile processes, "ubiquitous computing" and software with huge failure tolerances by virtue of being able to reconfigure and coalesce resources at will. And hopefully the flow-on effect of that would be to essentially stop horrible concurrency implementations being used in languages like Java and friends.
- swannodette 17y ago
  "I think they do a really good job in the problem domains they are designed for." The problem domain of concurrency? "What is missing is something that provides good-quality abstractions, high-quality static analysis and very strong safety guarantees in the general case." They have excellent abstractions and great safety guarantees. Not sure what you mean by static analysis. A concurrent program is non-deterministic, what is going to go under static analysis? I'm sorry if I'm misunderstanding something here. "software with huge failure tolerances by virtue of being able to reconfigure and coalesce resources at will." Wasn't this the whole point of Erlang? You know like telecom switching?
  - gdp 17y ago
    A very similar point was made in the blog comments, but I'll restate my response here in brief: Concurrency is hard even when you're just using a pencil and a piece of paper. If you write down a description of a system using any kind of simple notation, it will be difficult for me or anyone else to read that an have a good intuition about the runtime behaviour of that system. This isn't a discussion of statefulness or mutability. It's just about the presence of a very large number of interactions that essentially defy any usual sense of causality.