4 ms·
Speaking of important distinctions, concurrency isn't a property of a language, but rather a property of a runtime. It's the old procedure vs process distinctio
by User23 4y ago
Speaking of important distinctions, concurrency isn't a property of a language, but rather a property of a runtime. It's the old procedure vs process distinction. Now a language can have nondeterministic constructs that beg for a concurrent runtime, but that doesn't actually require it. After all, a nondeterministic construct can be implemented deterministically. If the language doesn't specify the order the nondeterministic cases are handled in, then the runtime is free to handle them in some deterministic way.
Incidentally that's the root of the misconception that pure functional languages are easier to reason about. It's operational reasoning that's problematic, because simulating a nontrivial state machine in one's mind is a great cognitive challenge for those of us who are less bright than John von Neumann. However, the Dutch basically solved this problem and provided a logical framework for reasoning about imperative programs in a way based off the program text, with no need for attempting to mentally simulate the probably infinite set of possible processes it describes.
- nequo 4y ago> However, the Dutch basically solved this problem and provided a logical framework for reasoning about imperative programs in a way based off the program text, with no need for attempting to mentally simulate the probably infinite set of possible processes it describes. Do you mind clarifying what the framework is that you mean? A pointer would be helpful for me.
- brightball 4y agoMy guess is that he means OTP.
- User23 4y agoSee Dijkstra and Scholten.
- valenterry 4y ago> Speaking of important distinctions, concurrency isn't a property of a language, but rather a property of a runtime. But the way of how you can and will describe how the runtime should execute code in a concurrent way is highly dependant on the language. Compare Assembly and Go or Rust or Erlang. Completely differnt worlds, don't you think so? > Incidentally that's the root of the misconception that pure functional languages are easier to reason about. It's not a misconception. People are different, but at least I can say after many years of experience in both worlds that pure functional programming is much much more productive than any kind of other approach that I have tried when it comes to dealing with concurrency, parallelism and effects.
- User23 4y ago> It's not a misconception. I hear you, but you’re missing the point. The sole reason why you find pure functional programs easier to reason about is because that is one strategy for avoiding operational reasoning. However it’s equally possible to avoid operational reasoning about imperative programs. Hence my claim that it’s a misconception.
- valenterry 4y agoI would be insterested to learn how this can be avoided without pure functional programming. Any sources/references?