4 ms·

Personally I've found that learning a functional programming language, with strictly enforced 'no side effects' functions, has simplified multi-threaded program

by timje1 13y ago

Personally I've found that learning a functional programming language, with strictly enforced 'no side effects' functions, has simplified multi-threaded programming for me. I just remember back to those restrictions and force myself to follow them, whatever the current language allows. For reference, the language was Erlang, which I believe has the best handling of threading that I've encountered so far.

tel 13y ago
Agreed! My mind on concurrent programming is far away from the usual nightmare stuff because I just think at the level of immutability, MVars, OTP, STM, LVish. You have to simplify your computational semantic domain before it's easy to augment it with nice abstractions for concurrency.
zvrba 13y ago
So you've basically experienced the benefits of actors (message-passing style, no shared state). But you can use message-passing paradigm in imperative languages too, though it's rather cumbersome in non-extensible languages like C or Java.
- jerf 13y ago
  I think (s)he strongly implied that. I'd simply flat-out say it, the best way to learn how to program in an imperative multi-threaded environment is to clock enough time in Erlang, Haskell, or perhaps Clojure (with as much immutability as possible) that you can get real work done (not merely finish a couple of tutorials) that you are forced to learn how to program in a minimal-sharing style, then if you go back to something like Go or something, it's really not that hard. I think you can learn how to program multithreaded code well without that, but you'll learn a great deal faster if you use a language that kicks you in the face every time you do something stupid (or simply doesn't let you do it). As in, potentially an order of magnitude faster. Fast feedback is non-linearly better than slow feedback. Though this does assume you get to greenfield the multithreaded code. Woe betide ye who have to retrofit existing poor multithreaded code. I don't even know what to tell you, except you have my pity.
  - timje1 13y ago
    That's correct, I love the actor system in Erlang, and I wish I had access to it in every other language I've used. Building multi-threaded applications with functional programming forced me to write pure functions - or close enough, Erlang does have some side-effects but this is just to make it more useable than the mostly academic Haskell. I've carried this approach into C# and Java, and typically end up with methods that fit a multi-threaded paradigm by default because of their lack of state. As a freebie, they can be effortlessly unit tested by mocking their direct parameters and testing the return values (no need to mock or test state).
bottled_poe 13y ago
Side-effect free functions work great for algorithms which can be processed in parallel. Such functions tend to indicate good software design. However, unlike parallel processing, concurrent programming by definition assumes that each process will need to share access to resources. I don't believe side-effect free functions alone will help much...

by timje1 13y ago

tel 13y ago

Agreed! My mind on concurrent programming is far away from the usual nightmare stuff because I just think at the level of immutability, MVars, OTP, STM, LVish. You have to simplify your computational semantic domain before it's easy to augment it with nice abstractions for concurrency.

zvrba 13y ago

So you've basically experienced the benefits of actors (message-passing style, no shared state). But you can use message-passing paradigm in imperative languages too, though it's rather cumbersome in non-extensible languages like C or Java.

jerf 13y ago
I think (s)he strongly implied that. I'd simply flat-out say it, the best way to learn how to program in an imperative multi-threaded environment is to clock enough time in Erlang, Haskell, or perhaps Clojure (with as much immutability as possible) that you can get real work done (not merely finish a couple of tutorials) that you are forced to learn how to program in a minimal-sharing style, then if you go back to something like Go or something, it's really not that hard. I think you can learn how to program multithreaded code well without that, but you'll learn a great deal faster if you use a language that kicks you in the face every time you do something stupid (or simply doesn't let you do it). As in, potentially an order of magnitude faster. Fast feedback is non-linearly better than slow feedback. Though this does assume you get to greenfield the multithreaded code. Woe betide ye who have to retrofit existing poor multithreaded code. I don't even know what to tell you, except you have my pity.
- timje1 13y ago
  That's correct, I love the actor system in Erlang, and I wish I had access to it in every other language I've used. Building multi-threaded applications with functional programming forced me to write pure functions - or close enough, Erlang does have some side-effects but this is just to make it more useable than the mostly academic Haskell. I've carried this approach into C# and Java, and typically end up with methods that fit a multi-threaded paradigm by default because of their lack of state. As a freebie, they can be effortlessly unit tested by mocking their direct parameters and testing the return values (no need to mock or test state).

bottled_poe 13y ago

Side-effect free functions work great for algorithms which can be processed in parallel. Such functions tend to indicate good software design. However, unlike parallel processing, concurrent programming by definition assumes that each process will need to share access to resources. I don't believe side-effect free functions alone will help much...