Blogged by Ujihisa. Standard methods of programming and thoughts including Clojure, Vim, LLVM, Haskell, Ruby and Mathematics written by a Japanese programmer. github/ujihisa

Wednesday, September 2, 2009

Summary: Haskell in the Real World

I read a paper.

Curt Sampson "Experience Report: Haskell in the Real World Writing a Commercial Program in Haskell", draft of submission to ICFP 2009

This paper is not for theoretical purpose but for practical one even though the title includes the purely functional language Haskell.

I have been using Haskell for 3 years, but for draft or experimental one, not for actual production. In contrast Curt Sampson, the author of the paper, used Haskell for production code int the real world.

The paper in short

  • Curt Sampson is an experienced Java programmer, who knows C and Ruby as well.

  • He got interested in functional programming languages due to Paul Graham indirectly.

  • He wrote a financial application in Haskell for his client in the spring of 2008, instead of in Java.

  • "We explained that, for us, switching languages every few years was a normal technology upgrade,"

  • He looked for a language which provides concise yet expressive code, so that his client can read and modify them.

  • It's important not to have to change his tool for new language; e.g. Smalltalk needs special environments.

  • He decided to use Haskell instead of OCaml or Scala, because:
    • Once he considered to use OCaml, but the syntax was not clear enough for him; Double semicolons and lack of overloaded functions mattered.
    • Once he considered to use Scala, but he got dissapointed to know that it couldn't run native code.
  • Haskell codes are readable even for non-programmers.

  • He wrote his own parser library, to offer stateful parsing with ByteString in contrary to the standard library Parsec.

  • Haskell needs fewer lines of test code than Ruby.

  • Haskell is more portable than C++ even when his application involved interfacing with the Microsoft products. GHC has a good FFI.

  • Lazy evaluation causes two problems, threads and space leaks. GHC's profiler helps solving the problems, but not enough.

Conclusion: Haskell is the ultimate language.

9 comments:

  1. For the love of god, double semicolons in OCaml are for the interpreter, they do NOT exist in actual code !

    You have minor typos in your text : overload functions (overloaded functions), spce leaks, dissappointed, a experienced Java programmer.

    I'm not a native English speaker too, so I figured fixing your grammatical mistakes would be a good exercice for me:
    very production code in a real world -> production code in the real world
    I have been used Haskell for 3 years -> I have been using ...
    for his client can ... -> so that his client can ...
    codes in Haskell -> Haskell code
    Haskell doesn't need the lines of test codes as many as Ruby -> Haskell needs fewer lines of test code than Ruby
    helps to solve the problems -> helps solving the problems

    It's an interesting paper, thanks !

    ReplyDelete
  2. Hi Jean-Denis,
    Thank you for your correction! I fixed the entry now.

    ReplyDelete
  3. good introduction to make me feel like trying to use Haskell :D

    ReplyDelete
  4. mootoh.shoud be_enlightened_to_use(Haskell)

    ReplyDelete
  5. Ujihisa-san, thanks for your very kind summary of my paper. I presented it last week at ICFP and it went over pretty well, I think. I'm putting a few further thoughts on ICFP and the related workshops up on the TSAC blog from time to time. And next time you're in Tokyo, please come to a TSAC meeting!

    I notice you're interested in parsing, at least to the extent of mucking about with the Ruby parser. I'd encourage you to look at writing a parser in Haskell, perhaps using Parsec. It's a truly amazing language for doing that kind of thing.

    Jean-Denis, I'm not sure at whom you were aiming your comments, but some of the typos were certainly mine. I ought to have had someone else proof-read the paper before submitting it for publication; as it is, those typos are now in the proceedings forever. *Sigh*.

    Regarding the semicolons, well, feel free to blame anything bad I've ever said about O'Caml on the APress book Practical OCaml, which is probably the worst thing to happen to the ML community in years.

    ReplyDelete
  6. Thank you for your comment!

    How was ICFP at Edinburgh? I found your paper via a Japanese blog of a person who attended it.

    Yes, I'm interested in parsing. Primarily I'm interested how the syntax of a programming language matters and how to develop IDEs better as a human interface, so I need to be able to handle them. Last year I tried Parsec and wrote simple RPN parser. I'll try something harder next time.

    I've never imagined you were liging in both Japan and Vancouver -- It's what I am. When I'll come to Tokyo I certainly send an email to you. It may not be far future.

    ReplyDelete
  7. Ah, now I'm curious: which blog was that? I met several other people from Japan (some of them even Japanese :-)) at the conference.

    ReplyDelete
  8. shinh's.
    http://shinh.skr.jp/m/
    He is a Google Japan programmer.

    ReplyDelete
  9. hey can u write down code for mpeg 1 layer 2 decoder in haskell???

    ReplyDelete

Followers