• David Wonnacott added an answer:
    Haskell For Parallel Algorithms

    My friend says Haskell is better than Java for parallel programming. Haskell is a functional-programming language. I would like to know which language is better.

    David Wonnacott · Haverford College

    My research isn't really focused on this question, but I can share some insight from a class I teach that is 50% focused on shared-memory explicit parallelism [URL #1 below]. Looking back after writing my thoughts, this is at best a partial answer, but as there aren't any other answers yet, I'll put in what I can. Perhaps my ignorance will encourage a Haskell expert to correct/extend my contribution.

    Note that there are strengths and weaknesses to both languages and paradigms, and I try to focus on both in my class. So I'll talk about the strengths and challenges of pure functional coding in general, and then move on to what little I can say about Haskell.

    * First, some context:

    My course starts with the "shared memory with threads and locks" approach that is standard in Java. We then discuss the strengths and weaknesses of this approach, and introduce other options: pure-functional programming (i.e., implicit parallelism), transactional programming, and the actors paradigm. I've been quite happy with Venkat Subramaniam's book, btw [URL #2 below].

    The most important prerequisite for my course was two semesters of intro C.S., that introduce students to the Python language as a vehicle for pure functional, imperative, and data-abstraction-centric programming (o-o without much inheritance, which comes later in our curriculum). Thus, we didn't work through any really complicated parallel algorithms, and had to introduce a bit of Java before we could really get started (though this was surprisingly quick).

    The most relevant exercises involved the students choosing one classic data structure (e.g., a binary search tree, for the un-ambitious, or a 2-3-4 tree or red-black tree, for the ambitious), and creating concurrent versions first in Java using locks and threads, and then (possibly in some other language, such as Clojure or Scala) using one of the other paradigms. Even at this simple level, I got a new appreciation for the strengths and limitations of the other paradigms (and a new respect for skip-lists ... "threads & locks" red-black trees were rather painful even for my top students).

    * Now that I've provided context, my actual comment:

    Advocates of pure-functional coding sometimes claim that it is great for parallelism, because it is easy to find concurrency in pure code: all function parameters can be evaluated simultaneously. To my prior critique of this claim, I've added an observation that pure code can also hide some parallelism, in that it's hard to _express_ a request to e.g., concurrently add two things to a given collection. If you have an operation that adds an element by taking 1 element and 1 tree, you'd add two elements with:

       add(newElement2, add(newElement1, originalCollection))

    and (at least in a strict language), the "obvious" concurrency of adding both at once isn't so obvious. My students ended up writing an "add several" operation to provide concurrent updates of the tree.

    So, for strict pure code, I still see some limitations for parallelism: I no longer think of the concurrency as really obvious; and (my original critique), if one wants performance, the hard question is often _which_ potential concurrency is worth parallel execution, and which is best done sequentially. So even the benefit of "making concurrency obvious" solves the easy half of the two-part question of what to parallelize.

    But your question was about Haskell, and of course Haskell is both pure and _lazy_. So, in my example of adding two elements to a collection, the actual work of adding newElement1 will be wound into the process of adding newElement2, which will be triggered by some use of the result. I don't know nearly enough of the Haskell language system to know how well it would make use of parallelism in this case.

    My current thinking is this: actors, transactions, and pure-functional programming each do a lot to address the huge peril of parallel programming, namely the potential for a seemingly innocuous tweak to the code to change the potential outcome, possibly in a way that will not be quickly revealed by testing. However, they introduce new challenges that can impede your ability to reason about performance, e.g.  you might have to know a lot about performance tuning in Haskell before you can think about performance-tuning concurrent Haskell code. Good tools such as race detectors for standard Java code might provide a totally different way to address that "huge peril", and the choice of which learning curve you should approach (Haksell vs. threads & locks with good tool support) may depend more on your background and thinking style than the tools themselves.

    Based on what little I've done with it, I remain a big fan of Haskell. I'd also like to learn more about transactional Haskell. But reasoning about performance doesn't seem to be its strength. So, at this point, if you care about performance of parallel code and actual degree of parallelism exploited, I think your question can't be answered without serious knowledge of Haskell internals.

    Would any Haskell experts out there care to contribute?

  • Alleyne Thompson asked a question:
    Haskell programming

    haskell parallel

  • Robin T. Bye added an answer:
    What are the advantages and disadvantages of using Haskell for artificial intelligence?
    Specifically, using Haskell for autonomous mobile robots and cooperative control.
    Robin T. Bye · Aalesund University College
    Some nice blog posts comparing Haskell with other languages used for AI:
    Haskell vs. Scala vs. Python: http://blog.samibadawi.com/2013/02/scala-vs-haskell-vs-python.html
    Haskell vs. Scheme: http://scienceblogs.com/goodmath/2006/10/24/haskell-and-scheme-which-one-a/
  • Stefan Savev added an answer:
    Scala implicits and type classes
    Do you know of any good material describing systematically the relationship between scala implicits and type classes?
    Stefan Savev · ResearchGate
    Thanks Michael! It's a good reference.
  • Robin T. Bye added an answer:
    Any suggestions for a good book on Haskell?
    Any book or page that contains good material for language Haskell.
    Robin T. Bye · Aalesund University College

    There is also "Real World Haskell" by Bryan O'Sullivan, John Goerzen, and Don Stewart. That book is published by O'Reilly, and like many O'Reilly books, it is  available for free online: http://book.realworldhaskell.org/. 

    The online version is particularly useful, as it also contains comments by users, which has ensured that even the tiniest errors are caught and explanations are bootstrapped and perfected.

  • Peter Padawitz added an answer:
    Is there any logic language to implement quantum programming?
    I am just now interested in explore the capabilities of quantum programming. I found some implementations on literature based on C or C++. Also there is a very promising language QML on top of the functional language Haskell that is based on linear logic, but i'll rather prefer to manage a logic language. Any one know if there is a work on such line?
    Peter Padawitz · Technische Universität Dortmund
    Maybe this helps: http://www.mathstat.dal.ca/~selinger/quipper/

About Haskell

Group for Haskell learners and practitioner

Topic Followers (78) See all