4 ms·

Conceptually, threads are probably easier than actors for a beginner. I'm not saying that it's easier to implement correct code with threads (in fact it's more

by vemv 10y ago

Conceptually, threads are probably easier than actors for a beginner. I'm not saying that it's easier to implement correct code with threads (in fact it's more complex), but most devs go from OO to FP, not the other way around. These days there is such an explostion of languages, frameworks, techniques etc it must be scary for a beginner. Given that, i'd advise to go by the safe (average) path.

rubiquity 10y ago
But if you learn about concurrency via threads then you have to learn about mutexes... if you learn about mutexes then you have to learn about condition variables... and if you learn about condition variables then you have t... Well you see where this is going. I think it's important to learn about Threads, Mutexes, Condition Variables, and why sharing isn't caring, but I don't think those lessons necessarily need to come before learning about the Actor model.
- nugator 10y ago
  On the other hand, if you want to sell the Actor model it might be good to first go through the complex techniques needed for trying to get concurrency right with threads.
dragonwriter 10y ago
> most devs go from OO to FP, Most devs go from OO to FP because of dominance of OO in industry (with knock-on effects on pedagogy) from sometime around the late-1980s/early-1990s until recently. Shortly before that, the same would be true of procedural to either OO or FP. And probably at one point the same would have been true of unstructured imperative to procedural. But that doesn't mean that concurrency in popular OO languages of today is easier than concurrency in Erlang/Elixir (which may be examples of functional-ish languages, which I assume is the relevance of your OO to FP statement), nor does it mean that concurrency in formerly popular procedural languages is easier than in any particular OO language, or that concurrency in unstructured imperative languages is easier than in any particular procedural language.
- macintux 10y ago
  I think the only argument left for "why I should learn OO before FP" is the lingering suspicion no one would tolerate the pain involved with OO once they reached that point.

by vemv 10y ago

rubiquity 10y ago

But if you learn about concurrency via threads then you have to learn about mutexes... if you learn about mutexes then you have to learn about condition variables... and if you learn about condition variables then you have t... Well you see where this is going. I think it's important to learn about Threads, Mutexes, Condition Variables, and why sharing isn't caring, but I don't think those lessons necessarily need to come before learning about the Actor model.

nugator 10y ago
On the other hand, if you want to sell the Actor model it might be good to first go through the complex techniques needed for trying to get concurrency right with threads.

dragonwriter 10y ago

> most devs go from OO to FP, Most devs go from OO to FP because of dominance of OO in industry (with knock-on effects on pedagogy) from sometime around the late-1980s/early-1990s until recently. Shortly before that, the same would be true of procedural to either OO or FP. And probably at one point the same would have been true of unstructured imperative to procedural. But that doesn't mean that concurrency in popular OO languages of today is easier than concurrency in Erlang/Elixir (which may be examples of functional-ish languages, which I assume is the relevance of your OO to FP statement), nor does it mean that concurrency in formerly popular procedural languages is easier than in any particular OO language, or that concurrency in unstructured imperative languages is easier than in any particular procedural language.

macintux 10y ago
I think the only argument left for "why I should learn OO before FP" is the lingering suspicion no one would tolerate the pain involved with OO once they reached that point.