3 ms·
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 o
by 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 agoA 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.