3 ms·

Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than

by fnl 16y ago

Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than thinking about go or Clojure.

wtracy 16y ago
I did a touch of research on my own. The Clojure slide deck that's currently featured on the front page has some useful definitions: "Concurrency is commonly mistaken for parallelism, but the two are distinct concepts. Concurrency is concerned with managing access to shared state from different threads, whereas parallelism is concerned with utilizing multiple processors/cores to improve the performance of a computation." Haskell has parallelism nailed. You can basically tell the compiler, "I want these two functions to run in parallel on two different cores." The compiler will then transparently do some fork/join type magic, and automatically enforce that the functions can't step on each other's toes. (It probably uses threads instead of processes, but since the functions are not allowed to share data, it feels like Unix-style fork/join.) (Side note: Unless it's explicitly stated in the function's signature, Haskell functions are forbidden by the compiler to have any side effects. This will drive programmers coming from a procedural background absolutely insane, but it makes the above magic possible.) I haven't coded in Erlang, but it seems to rely heavily on message passing. The compiler stops you from doing stupid things, but the concurrency is still exposed to the application. So, if your only goal is to distribute your workload to as many cores as possible (say you're building a video encoder, or in my case a ray tracer) with as little hacking as possible, Haskell will make your day. If the existence of different threads is part of your actual application architecture, Erlang is your friend. It lets you explicitly create producers and consumers, and play around with different event architectures. As mentioned before, I'm a Haskell n00b and completely unfamiliar with Erlang, so if anyone wants to chime in and correct me, please do.
- fnl 16y ago
  So far, your reply about Haskell seems the only promising alternative to C. Could you imagine to develop in Haskell and use, e.g., HaskellDirect, for C libraries that are not available in Haskell for certain tasks? And, it seems you can even interface with Python (see "http://wiki.python.org/moin/PythonVsHaskell http://wiki.python.org/moin/PythonVsHaskell) via the ctypes. So far, I conclude that Haskell could be the most promising language for the upcoming "onslaught" of multicore/multiprocessor architectures (especially when I look at how clean the syntax for distributed processing is). But then I also have read much blogs like this one "http://www.jelovic.com/articles/why_people_arent_using_haskell.htm http://www.jelovic.com/articles/why_people_arent_using_haske.... So is it really worth it to dive into Haskell?
  - wtracy 16y ago
    I concur that the Haskell libraries are pretty crummy. (There's no built-in function to split a string on an arbitrary delimiter? Really?) I'll also say that Haskell has a really steep learning curve, especially if you're coming from a procedural/object oriented background. I've programmed in Scheme and ML before, and neither were as mind-bending as Haskell. I haven't done any projects yet that involved mixing Haskell with another language, so I can't comment on that. That's probably the most sane way to do a large app with Haskell--use Haskell for what it's good at, and use C/Python for what they're good at. If I had heard about Erlang's concurrency support earlier, I might have gone with it instead of Haskell, because Haskell is so hard to learn. Now that I'm already partway over the Haskell learning curve, it seems nice enough to stick with. I really can't say yet whether Haskell is worth learning. Keep in mind that it will be hard to bring new programmers on board with a large Haskell code base. (I'm using it for hobby projects, so that's a non-issue.) The best answer I can give is: If you're going to be writing large swaths of code that make few or no system calls and that are CPU intensive, it might be; otherwise, no. EDIT: Let me try to clarify what I mean by the "mind-bendingness" of Haskell. Think about the Integer and String objects in Java--once instantiated, they are immutable. All data in Haskell behaves like this. However, this immutable data lives on the stack, so you can't just reassign the reference to a new object. (If you want to increment your parameter x, you have to make a recursive call with x + 1.) The exception here is a construct called a monad. Inside a monad, you can reassign references to new objects, and the old objects are cleaned up by the garbage collector. The intermediate objects are invisible to code outside the monad. (As an example, I/O is done inside of monads.) The two things I like about Haskell are the concurrency support (if you can wrap your head around the above paradigm!) and the syntax (you can do Python-style significant whitespace, or C-style semicolons and brackets, your pick). Unfortunately, Haskell manages to screw up almost everything else.
    - fnl 16y ago
      Well, following the advice I got here I started out with Erlang - where you have much of the same issues you describe, too. However, having immutable variables also allows for some pretty nifty stuff in Erlang (and I guess in Haskell even more; thinking of assignment as regex matching etc.), and I would even say for Erlang, which has no static type safety, it actually might come as a blessing. I don't know how often I have traced errors in dynamic languages exactly because of that (or - even worse - still have bogus code I never noticed...). And I don't know why, but to me functional programming in C, Python and Lisp always had seemed far easier than grasping a decent OO model in Java or anything - at best I liked AOP, but that seems pretty quiet nowadays; and with "green threads" and all that stuff coming along, it seems that my easier approach to "functional" is a benefit finally...

by fnl 16y ago

Second that question, too! Actually, in terms of what can be gained, Haskell might be even more interesting to learn in terms of the increasing need of MP than thinking about go or Clojure.

wtracy 16y ago

I did a touch of research on my own. The Clojure slide deck that's currently featured on the front page has some useful definitions: "Concurrency is commonly mistaken for parallelism, but the two are distinct concepts. Concurrency is concerned with managing access to shared state from different threads, whereas parallelism is concerned with utilizing multiple processors/cores to improve the performance of a computation." Haskell has parallelism nailed. You can basically tell the compiler, "I want these two functions to run in parallel on two different cores." The compiler will then transparently do some fork/join type magic, and automatically enforce that the functions can't step on each other's toes. (It probably uses threads instead of processes, but since the functions are not allowed to share data, it feels like Unix-style fork/join.) (Side note: Unless it's explicitly stated in the function's signature, Haskell functions are forbidden by the compiler to have any side effects. This will drive programmers coming from a procedural background absolutely insane, but it makes the above magic possible.) I haven't coded in Erlang, but it seems to rely heavily on message passing. The compiler stops you from doing stupid things, but the concurrency is still exposed to the application. So, if your only goal is to distribute your workload to as many cores as possible (say you're building a video encoder, or in my case a ray tracer) with as little hacking as possible, Haskell will make your day. If the existence of different threads is part of your actual application architecture, Erlang is your friend. It lets you explicitly create producers and consumers, and play around with different event architectures. As mentioned before, I'm a Haskell n00b and completely unfamiliar with Erlang, so if anyone wants to chime in and correct me, please do.

fnl 16y ago
So far, your reply about Haskell seems the only promising alternative to C. Could you imagine to develop in Haskell and use, e.g., HaskellDirect, for C libraries that are not available in Haskell for certain tasks? And, it seems you can even interface with Python (see "http://wiki.python.org/moin/PythonVsHaskell http://wiki.python.org/moin/PythonVsHaskell) via the ctypes. So far, I conclude that Haskell could be the most promising language for the upcoming "onslaught" of multicore/multiprocessor architectures (especially when I look at how clean the syntax for distributed processing is). But then I also have read much blogs like this one "http://www.jelovic.com/articles/why_people_arent_using_haskell.htm http://www.jelovic.com/articles/why_people_arent_using_haske.... So is it really worth it to dive into Haskell?
- wtracy 16y ago
  I concur that the Haskell libraries are pretty crummy. (There's no built-in function to split a string on an arbitrary delimiter? Really?) I'll also say that Haskell has a really steep learning curve, especially if you're coming from a procedural/object oriented background. I've programmed in Scheme and ML before, and neither were as mind-bending as Haskell. I haven't done any projects yet that involved mixing Haskell with another language, so I can't comment on that. That's probably the most sane way to do a large app with Haskell--use Haskell for what it's good at, and use C/Python for what they're good at. If I had heard about Erlang's concurrency support earlier, I might have gone with it instead of Haskell, because Haskell is so hard to learn. Now that I'm already partway over the Haskell learning curve, it seems nice enough to stick with. I really can't say yet whether Haskell is worth learning. Keep in mind that it will be hard to bring new programmers on board with a large Haskell code base. (I'm using it for hobby projects, so that's a non-issue.) The best answer I can give is: If you're going to be writing large swaths of code that make few or no system calls and that are CPU intensive, it might be; otherwise, no. EDIT: Let me try to clarify what I mean by the "mind-bendingness" of Haskell. Think about the Integer and String objects in Java--once instantiated, they are immutable. All data in Haskell behaves like this. However, this immutable data lives on the stack, so you can't just reassign the reference to a new object. (If you want to increment your parameter x, you have to make a recursive call with x + 1.) The exception here is a construct called a monad. Inside a monad, you can reassign references to new objects, and the old objects are cleaned up by the garbage collector. The intermediate objects are invisible to code outside the monad. (As an example, I/O is done inside of monads.) The two things I like about Haskell are the concurrency support (if you can wrap your head around the above paradigm!) and the syntax (you can do Python-style significant whitespace, or C-style semicolons and brackets, your pick). Unfortunately, Haskell manages to screw up almost everything else.
  - fnl 16y ago
    Well, following the advice I got here I started out with Erlang - where you have much of the same issues you describe, too. However, having immutable variables also allows for some pretty nifty stuff in Erlang (and I guess in Haskell even more; thinking of assignment as regex matching etc.), and I would even say for Erlang, which has no static type safety, it actually might come as a blessing. I don't know how often I have traced errors in dynamic languages exactly because of that (or - even worse - still have bogus code I never noticed...). And I don't know why, but to me functional programming in C, Python and Lisp always had seemed far easier than grasping a decent OO model in Java or anything - at best I liked AOP, but that seems pretty quiet nowadays; and with "green threads" and all that stuff coming along, it seems that my easier approach to "functional" is a benefit finally...