10 ms·

Is Haskell the Cure?

175 points by bobfunk 15y ago

Peaker 15y ago
It is somewhat of a shame that learning curve plays such a significant role for career programmers. You would expect that people that spend years and years working with their tools would be willing to put a few weeks or months into learning their most important tool: the programming language. It seems most programmers get frustrated and abandon learning of different programming paradigms very quickly.
- Jach 15y ago
  Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.
  - danieldk 15y ago
    You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.
    - deleted 15y ago
      [deleted]
    - dtbx 15y ago
      Yeah, but the syntax and the verbosity hides your aim. In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer. In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.
      - danieldk 15y ago
        In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way. Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace). Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. Yeah, but the syntax and the verbosity hides your aim. Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.
        eru 15y ago
        > Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. That's why it's called point-less style. It's too seductive. > Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight. In a sense. But at least Haskell is parseable. And overloading is only done in a very systematic manner. So if something fishy's going on, you at least see strange symbols you haven't seen before.
    - Jach 15y ago
      > You must have never done any meta-programming in C++ ;). It's pretty much a functional language. I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].
- stonemetal 15y ago
  Not to be to contrarian but until I see proof to the contrary I think Norvig put said it best: In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you;
  - thesz 15y ago
    Architecture heavily depends on the language. You have to make different choices for C++ than for Java, not mentioning Haskell. Also, I think that comma before "the right" in Norvig statements means logical AND. If we rewrite that statement it will look like that: if you have the right overall architecture AND the right team of programmers AND the right development process that allows for rapid development with continuous improvement, then many languages will work for you. I think it is too many AND's here. In most realistic situations you cannot have such luxury. Also, choice of Haskell (or similar language) allows you to address at least two points from Norvig statement: the right team and right development process. Those who learned and applied Haskell almost cannot form the wrong team. Almost - as we cannot rule out failure completely. The right development process is almost ensured by strong type system. Type systems like Haskell's can be viewed as a tool to spread requirement changes through complete program. (that's why it is seemed hard to introduce or change a constructor in a data type) So all in all I think that languages make a difference here. For many languages you should fulfill those three points, for some languages those points fulfill themselves.
    - eru 15y ago
      As much as I loath Java and co, I have to give them that their mature development tools make up a bit for their weakness. I.e. in Haskell you make a change to a type and propagate it, until the compiler stops complaining. In Java you click some `refactor' button in your IDE, and your changes will propagate through the code base automatically. That's less of a comment on the languages, since Haskell will probably grow better tools some day, but more a comment on the relative stages of maturity.
- Someone 15y ago
  The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back. Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.
  - Peaker 15y ago
    I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn. Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.
    - SwellJoe 15y ago
      "Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn." The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way. You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive? I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.
dorian-graph 15y ago
Hasn't the author already said that the measuring of Fibonacci was not the point of his tirade? Which makes the line in this post 'I think a lot of people missed the main point of Dziuba's troll" slightly amusing. Is there now going to be someone running this 'benchmark' in whatever language they can? One of the blogs already posted said he's going to find time to run it in C. I'll do my part. Delphi, here I come. ;)
- piccadilly 15y ago
  I'm not interested in this Fibonacci benchmark until someone does it in TriINTERCAL. PLEASE GIVE UP
- bobfunk 15y ago
  My benchmark was mostly a parody, since Haskell just memoized the call and never really did the work. The point of the article was more the difference between the languages that really tackles concurrency (Haskell, Clojure, Go, Erlang) and Node's way of simply offering one solution that works for a lot of problems where the common scripting languages (especially PHP) doesn't work that well.
  - lurker19 15y ago
    Haskell broke the Programming Language Shootout by the compiler and runtime optimizing the busy-loop tasks into no-ops and memoizations. It is hard to write a Haskell program that is gimped enough to be in league with other languages in a synthetic benchmark.
  - alexatkeplar 15y ago
    Don't forget Akka (esp Scala-Akka) in that list!
    - gtani 15y ago
      I just put up a [[actors in _ lang]] list http://stackoverflow.com/questions/7566548/actor-based-distributed-concurrency-libraries-for-ocaml-and-other-languages http://stackoverflow.com/questions/7566548/actor-based-distr...
deleted 15y ago
[deleted]
ghc 15y ago
I love Haskell; I do a lot of work with it. That said, I use Python for the web. As nice as Snap is, Haskell just doesn't have the vast array of quality libraries for web development that Python does. Lately, this means that I do web development in Flask, and heavy lifting in Haskell.
- vegai 15y ago
  Check out http://www.yesodweb.com/ http://www.yesodweb.com/
- bwfeldman 15y ago
  Saw your comment about your desire to launch a product with personality. I'd be happy to help (for free) if you want. @BWFeldman
substack 15y ago
I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack https://github.com/substack. I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet. Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use. I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf. Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node. I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense. The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.
- dsharpdiabetes 15y ago
  I had a similar experience with Erlang. Node has totally taken over the erlang shaped hole in my life ;)
- MatthewPhillips 15y ago
  Did you perhaps jump into the water too quickly? I'm currently learning a couple of functional languages (including Haskell) and using it in production environments but my current use is restricted to "I have an input that will always produce a certain output. There are no database or environmental dependencies, this is straight computation. I want to never have to worry about this function ever again". And so far, knock on wood, haskell has been killer for that scenario. I'll probably eventually transition a lot more of my code to functional languages, but will do so slowly (using Go otherwise).
heisenmink 15y ago
Wasn't the point of the original post that node.js blocks the event loop while it executes functions and thus effectively kills concurrency? Not how fast it calculates fibonacci numbers and sends it over http...
- Niten 15y ago
  The point was that it kills parallelism – Node is just a single-threaded event loop, running on a single core. And since computing fibonacci numbers is a CPU bound activity, that type of benchmark would be relevant but for the memoization bit. EDIT: Well also, the author would have to actually benchmark this vs. Node with many concurrent clients in order for it to be relevant; here he's just timing a single request from start to finish, which obviously doesn't say anything about how this scales.
agentultra 15y ago
I don't think Haskell itself is really the answer. If I read the article correctly it's simply a matter of concurrency and parallelism that's important. There are a host of languages that do that quite well and Haskell just happens to be one of them.
- thesz 15y ago
  How those languages fare in other fields, like, constraint programming? http://hackage.haskell.org/package/monadiccp http://hackage.haskell.org/package/monadiccp The real point is that Haskell is quite good in many areas and is excellent in parallelism and concurrency. While other languages are excellent in concurrency and not so good in other areas. Those many languages are the answer for the sole field of concurrency and Haskell is the answer when you combine many fields, one of which could happen to be concurrency.
  - agentultra 15y ago
    Sure Haskell is good for more than just concurrent programming, but the article was leaning on concurrency and parallelism in its comparison with Node.js And I should also point out that said "blub" languages can also implement those features which they lack that Haskell includes by design. Some have better features than Haskell, IMO (ie: Qi/Shen sequent types and the ability to turn the type system off when you don't need it). Again, Haskell is a good language. I just don't see it as a "cure." There are many other options.
    - Peaker 15y ago
      How can the "blub" languages implement Haskell's type-classes as libraries? Or generalized type inference? What about Haskell's higher-kinded polymorphism? And pattern matching? Lisp can do some of these, but it is not exactly a "blub" language. Is there a nice comparison of Qi and Haskell? Once you implement such a large, non-trivial system (such as an advanced type system), I really doubt using Lisp macros rather than implementing a compiler is easier. Macros that do such non-trivial things also do not compose well, so I doubt Lisp is beneficial for this purpose.
megaman821 15y ago
I don't think the point of Ted Dziuba's rant was that every request is a large calculation. In Node.js if most results are small and generated quickly when one large calculation request comes in all the small ones stop going out until it is done. A Haskell web server like Snap should not have this problem.
kennystone 15y ago
What's more important is applying some important concepts in haskell - functional programming and dividing your program into tiny self-contained parts. You can write this way in most languages - Ruby, Python, Scala, etc. The fancier parts of Haskell - lazy evaluation, static typing, whatever - are less important to making software that works than its functional nature.
- Peaker 15y ago
  The static typing is essential to making software that works (and scales). Dynamic typing requires a lot more test code and test code is expensive to write, maintain, and repeatedly execute.
deleted 15y ago
[deleted]
gvb 15y ago
Why is a Fibonacci sequence used as a benchmark for an argument for concurrent programming? The Fibonacci sequence is a recursive algorithm that inherently has dependencies on previous calculations that prevent effective concurrent execution. The Fibonacci algorithm executed concurrently is going to spend an inordinate amount of time creating tasks that do a trivial calculation (add two numbers together). If you want to benchmark concurrency, at least pick an benchmark algorithm that exercises concurrency. The FFT comes to mind, but there are probably lots of better examples (that is a challenge to HNers ;-).
- bunderbunder 15y ago
  I think that's where the "well-executed trolling" comment comes in. He essentially whipped everyone into a tizzy by complaining that a framework for helping to get better performance out of I/O-bound web services by handling I/O calls asynchronously doesn't work so well if you take a CPU-bound monkey wrench and jam it directly into the gearbox. I suspect that it worked so well because the idea of using Fib to talk about performance is kind of built into the collective programmer unconscious. The whys, hows, and whats of using Fib to talk about performance are somewhat less well-entrenched, though. So there's room to trip people up by getting them to go, "Yeah, this sounds interesting, and I recognize all the words so it probably isn't technobabble!"
- nightski 15y ago
  You are talking about parallelism. Concurrency is demonstrated just fine by the example, as it is being executed on a web server on every request.
- lobster_johnson 15y ago
  He was not benchmarking concurrency, he was pointing out that Node is single-threaded system that essentially implements the old-style cooperative multitasking, where a single task will block everything else. He could have used sleep() and it would have illustrated the same point (and more elegantly, since half of the responses miss the point entirely and focus on the Fibonacci part). Node developers probably don't do a lot of computationally complex stuff, but when they do, they have to think about the concurrency problem. Even something as trivial as sorting a large list or parsing a huge chunk of JSON is going to stop all other requests from executing.
shocks 15y ago
For every application there is a language best suited... Let's stop trying to force every language to be good at everything and then compare them as though they were all the same, shall we?
the_mat 15y ago
Please stop with the toy benchmarks and pretty one-liners that show how awesome Haskell is. There is growing list of smart programmers who get all enchanted with Haskell, jump into it wholeheartedly, and end up frustrated (see bottom of message). GHC makes the typical C++ compiler seem fast. Once code grows past the homework problem size, all hope of understanding memory usage is lost. I don't think people really get how bad that it is. The whole culture of Haskell is based around static checking, yet you have to run a program in order to find out if it blows your memory limit several times over. Haskell is still a neat language, but we need less advocacy based on toy programs and more honest realism. (Here's a typical, non-superficial example: http://wagerlabs.com/haskell-vs-erlang-reloaded-0 http://wagerlabs.com/haskell-vs-erlang-reloaded-0)
- gregwebs 15y ago
  That post is from 2005. The situation is entirely different today w/respect to speed (both the compiler and the addition of ByteString and Text libraries), and productive libraries, particularly for web development. Likewise, it is a rare case that you would run into memory consumption issues. I do agree that there is entirely too much enthusiastic toying around in Haskell and not enough real world users and honesty about limitations.
  - the_mat 15y ago
    To me, there's a dichotomy between the "if it compiles, it usually works" aspect of Haskell (and how this is often touted as superior to the dynamic typing, test-driven approach) and that you can't get a picture of memory usage until you run and profile the code. In my experience, hard to understand memory consumption issues are common and take effort to solve. Reference: http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-big-programs/ http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-bi...
    - gregwebs 15y ago
      That blog post says nothing about frequency of memory leaks, but shows that there are good tools to help you in your effort to solve them. One thing to keep in mind is that there are memory issues with every language. I just debugged one in Ruby yesterday, and there wasn't a good tool readily available for that effort. Do you know what the memory consumption of your programs are in other languages are before running them? As a contradictory anecdote, I have never once had a memory consumption issue with Haskell code. Haskell is actually in a nice position w/respect to memory now that enumerators (which always use constant memory) are taking hold. I have no doubt you encountered many memory leaks, but I don't think your experience completely generalises to modern Haskell.
exogen 15y ago
I'll say this again: Ted shouldn't have wasted everyone's time highlighting the response time of the request. He effectively benchmarked V8 right on his blog and then called it slow. Now everyone's complaining that people at least demonstrate that part to be untrue. Ironically, every one of his clients in the ab concurrency test will receive their responses before the users of the hypothetically parallel Python and Ruby services, because Node responds an order of magnitude faster. So he didn't actually demonstrate a problem.
T_S_ 15y ago
The ecosystem for Haskell is improving rapidly. My startup built a computer vision application on top of easyVision and with the intention of rewriting it in ObjC. Instead we are working with the Haskell community to target the mobile platform. A year ago that would have been a dicey bet. About our Haskell experience: Yes, the learning curve seems steep, but mainly because of the things you have to unlearn (OMG no for-loops!). However, functions are the most modular things ever invented. That translates into an uncanny ability to add features quickly. A sophisticated type system catches many errors at compile time.
giardini 15y ago
If Haskell is the Cure, what is the Disease?8-)) Haskell occupies a niche similar to Hamilton's quaternions (for classical physics) and Heisenberg's matrices (for quantum mechanics) - not mandatory, inaccessible to the masses and abandoned with haste once a more intuitive tool is found. But they will always be there if you need them.
jrockway 15y ago
Let's have a talk about the $ operator. When you use it more than once per line, you're writing code that looks weird and is hard to read. Switch to the similar function-composition operator, and everything looks more idiomatic. Instead of: fibServer x = quickHttpServe $ writeBS $ B.pack $ show (fibonacci x) Just write: fibServer = quickHttpServe . writeBS . B.pack . show . fibonacci The case for $ is where you want application instead of composition: fibOf42Server = quickHttpServe . writeBS . B.pack . show . fibonacci $ 42 I even write things like: main = print =<< foo instead of main = foo >>= print for consistency. Anyway, it's a little style thing, but it's nice to use the composition operator (.) when you want composition and the application operator ($) when you want application. It makes the code look nicer and it shows its intent more clearly. And really, they are different concepts, even if they both type-check the same. And finally, remember that function application, by default, is the highest-precedence operator in Haskell. When you write: foo . (bar 42) . baz It's the same as: foo . bar 42 . baz Because of operator precedence. $ only exists to change the order of operations for a particular expression.
- Peaker 15y ago
  I'll add that a nice little benefit of using: a . b . c . d $ e over: a $ b $ c $ d $ e is that any sub-expression taken from the first expression is valid and can be refactored out into its own name. (.) is associative and ($) is not.
- bobfunk 15y ago
  Really interesting style comment. Will keep this in mind.

175 points by bobfunk 15y ago

It is somewhat of a shame that learning curve plays such a significant role for career programmers. You would expect that people that spend years and years working with their tools would be willing to put a few weeks or months into learning their most important tool: the programming language. It seems most programmers get frustrated and abandon learning of different programming paradigms very quickly.

Jach 15y ago
Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.
- danieldk 15y ago
  You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.
  - deleted 15y ago
    [deleted]
  - dtbx 15y ago
    Yeah, but the syntax and the verbosity hides your aim. In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer. In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.
    - danieldk 15y ago
      In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way. Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace). Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. Yeah, but the syntax and the verbosity hides your aim. Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.
      - eru 15y ago
        > Also, point-free style is nice, but it is easily and often abused, leading to unreadable code. That's why it's called point-less style. It's too seductive. > Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight. In a sense. But at least Haskell is parseable. And overloading is only done in a very systematic manner. So if something fishy's going on, you at least see strange symbols you haven't seen before.
  - Jach 15y ago
    > You must have never done any meta-programming in C++ ;). It's pretty much a functional language. I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].
stonemetal 15y ago
Not to be to contrarian but until I see proof to the contrary I think Norvig put said it best: In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you;
- thesz 15y ago
  Architecture heavily depends on the language. You have to make different choices for C++ than for Java, not mentioning Haskell. Also, I think that comma before "the right" in Norvig statements means logical AND. If we rewrite that statement it will look like that: if you have the right overall architecture AND the right team of programmers AND the right development process that allows for rapid development with continuous improvement, then many languages will work for you. I think it is too many AND's here. In most realistic situations you cannot have such luxury. Also, choice of Haskell (or similar language) allows you to address at least two points from Norvig statement: the right team and right development process. Those who learned and applied Haskell almost cannot form the wrong team. Almost - as we cannot rule out failure completely. The right development process is almost ensured by strong type system. Type systems like Haskell's can be viewed as a tool to spread requirement changes through complete program. (that's why it is seemed hard to introduce or change a constructor in a data type) So all in all I think that languages make a difference here. For many languages you should fulfill those three points, for some languages those points fulfill themselves.
  - eru 15y ago
    As much as I loath Java and co, I have to give them that their mature development tools make up a bit for their weakness. I.e. in Haskell you make a change to a type and propagate it, until the compiler stops complaining. In Java you click some `refactor' button in your IDE, and your changes will propagate through the code base automatically. That's less of a comment on the languages, since Haskell will probably grow better tools some day, but more a comment on the relative stages of maturity.
Someone 15y ago
The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back. Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.
- Peaker 15y ago
  I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn. Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.
  - SwellJoe 15y ago
    "Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn." The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way. You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive? I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.

dorian-graph 15y ago

Hasn't the author already said that the measuring of Fibonacci was not the point of his tirade? Which makes the line in this post 'I think a lot of people missed the main point of Dziuba's troll" slightly amusing. Is there now going to be someone running this 'benchmark' in whatever language they can? One of the blogs already posted said he's going to find time to run it in C. I'll do my part. Delphi, here I come. ;)

piccadilly 15y ago
I'm not interested in this Fibonacci benchmark until someone does it in TriINTERCAL. PLEASE GIVE UP
bobfunk 15y ago
My benchmark was mostly a parody, since Haskell just memoized the call and never really did the work. The point of the article was more the difference between the languages that really tackles concurrency (Haskell, Clojure, Go, Erlang) and Node's way of simply offering one solution that works for a lot of problems where the common scripting languages (especially PHP) doesn't work that well.
- lurker19 15y ago
  Haskell broke the Programming Language Shootout by the compiler and runtime optimizing the busy-loop tasks into no-ops and memoizations. It is hard to write a Haskell program that is gimped enough to be in league with other languages in a synthetic benchmark.
- alexatkeplar 15y ago
  Don't forget Akka (esp Scala-Akka) in that list!
  - gtani 15y ago
    I just put up a [[actors in _ lang]] list http://stackoverflow.com/questions/7566548/actor-based-distributed-concurrency-libraries-for-ocaml-and-other-languages http://stackoverflow.com/questions/7566548/actor-based-distr...

deleted 15y ago

[deleted]

ghc 15y ago

I love Haskell; I do a lot of work with it. That said, I use Python for the web. As nice as Snap is, Haskell just doesn't have the vast array of quality libraries for web development that Python does. Lately, this means that I do web development in Flask, and heavy lifting in Haskell.

vegai 15y ago
Check out http://www.yesodweb.com/ http://www.yesodweb.com/
bwfeldman 15y ago
Saw your comment about your desire to launch a product with personality. I'd be happy to help (for free) if you want. @BWFeldman

substack 15y ago

I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack https://github.com/substack. I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet. Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use. I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf. Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node. I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense. The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.

dsharpdiabetes 15y ago
I had a similar experience with Erlang. Node has totally taken over the erlang shaped hole in my life ;)
MatthewPhillips 15y ago
Did you perhaps jump into the water too quickly? I'm currently learning a couple of functional languages (including Haskell) and using it in production environments but my current use is restricted to "I have an input that will always produce a certain output. There are no database or environmental dependencies, this is straight computation. I want to never have to worry about this function ever again". And so far, knock on wood, haskell has been killer for that scenario. I'll probably eventually transition a lot more of my code to functional languages, but will do so slowly (using Go otherwise).

heisenmink 15y ago

Wasn't the point of the original post that node.js blocks the event loop while it executes functions and thus effectively kills concurrency? Not how fast it calculates fibonacci numbers and sends it over http...

Niten 15y ago
The point was that it kills parallelism – Node is just a single-threaded event loop, running on a single core. And since computing fibonacci numbers is a CPU bound activity, that type of benchmark would be relevant but for the memoization bit. EDIT: Well also, the author would have to actually benchmark this vs. Node with many concurrent clients in order for it to be relevant; here he's just timing a single request from start to finish, which obviously doesn't say anything about how this scales.

agentultra 15y ago

I don't think Haskell itself is really the answer. If I read the article correctly it's simply a matter of concurrency and parallelism that's important. There are a host of languages that do that quite well and Haskell just happens to be one of them.

thesz 15y ago
How those languages fare in other fields, like, constraint programming? http://hackage.haskell.org/package/monadiccp http://hackage.haskell.org/package/monadiccp The real point is that Haskell is quite good in many areas and is excellent in parallelism and concurrency. While other languages are excellent in concurrency and not so good in other areas. Those many languages are the answer for the sole field of concurrency and Haskell is the answer when you combine many fields, one of which could happen to be concurrency.
- agentultra 15y ago
  Sure Haskell is good for more than just concurrent programming, but the article was leaning on concurrency and parallelism in its comparison with Node.js And I should also point out that said "blub" languages can also implement those features which they lack that Haskell includes by design. Some have better features than Haskell, IMO (ie: Qi/Shen sequent types and the ability to turn the type system off when you don't need it). Again, Haskell is a good language. I just don't see it as a "cure." There are many other options.
  - Peaker 15y ago
    How can the "blub" languages implement Haskell's type-classes as libraries? Or generalized type inference? What about Haskell's higher-kinded polymorphism? And pattern matching? Lisp can do some of these, but it is not exactly a "blub" language. Is there a nice comparison of Qi and Haskell? Once you implement such a large, non-trivial system (such as an advanced type system), I really doubt using Lisp macros rather than implementing a compiler is easier. Macros that do such non-trivial things also do not compose well, so I doubt Lisp is beneficial for this purpose.

megaman821 15y ago

I don't think the point of Ted Dziuba's rant was that every request is a large calculation. In Node.js if most results are small and generated quickly when one large calculation request comes in all the small ones stop going out until it is done. A Haskell web server like Snap should not have this problem.

kennystone 15y ago

What's more important is applying some important concepts in haskell - functional programming and dividing your program into tiny self-contained parts. You can write this way in most languages - Ruby, Python, Scala, etc. The fancier parts of Haskell - lazy evaluation, static typing, whatever - are less important to making software that works than its functional nature.

Peaker 15y ago
The static typing is essential to making software that works (and scales). Dynamic typing requires a lot more test code and test code is expensive to write, maintain, and repeatedly execute.

deleted 15y ago

[deleted]

gvb 15y ago

Why is a Fibonacci sequence used as a benchmark for an argument for concurrent programming? The Fibonacci sequence is a recursive algorithm that inherently has dependencies on previous calculations that prevent effective concurrent execution. The Fibonacci algorithm executed concurrently is going to spend an inordinate amount of time creating tasks that do a trivial calculation (add two numbers together). If you want to benchmark concurrency, at least pick an benchmark algorithm that exercises concurrency. The FFT comes to mind, but there are probably lots of better examples (that is a challenge to HNers ;-).

bunderbunder 15y ago
I think that's where the "well-executed trolling" comment comes in. He essentially whipped everyone into a tizzy by complaining that a framework for helping to get better performance out of I/O-bound web services by handling I/O calls asynchronously doesn't work so well if you take a CPU-bound monkey wrench and jam it directly into the gearbox. I suspect that it worked so well because the idea of using Fib to talk about performance is kind of built into the collective programmer unconscious. The whys, hows, and whats of using Fib to talk about performance are somewhat less well-entrenched, though. So there's room to trip people up by getting them to go, "Yeah, this sounds interesting, and I recognize all the words so it probably isn't technobabble!"
nightski 15y ago
You are talking about parallelism. Concurrency is demonstrated just fine by the example, as it is being executed on a web server on every request.
lobster_johnson 15y ago
He was not benchmarking concurrency, he was pointing out that Node is single-threaded system that essentially implements the old-style cooperative multitasking, where a single task will block everything else. He could have used sleep() and it would have illustrated the same point (and more elegantly, since half of the responses miss the point entirely and focus on the Fibonacci part). Node developers probably don't do a lot of computationally complex stuff, but when they do, they have to think about the concurrency problem. Even something as trivial as sorting a large list or parsing a huge chunk of JSON is going to stop all other requests from executing.

shocks 15y ago

For every application there is a language best suited... Let's stop trying to force every language to be good at everything and then compare them as though they were all the same, shall we?

the_mat 15y ago

Please stop with the toy benchmarks and pretty one-liners that show how awesome Haskell is. There is growing list of smart programmers who get all enchanted with Haskell, jump into it wholeheartedly, and end up frustrated (see bottom of message). GHC makes the typical C++ compiler seem fast. Once code grows past the homework problem size, all hope of understanding memory usage is lost. I don't think people really get how bad that it is. The whole culture of Haskell is based around static checking, yet you have to run a program in order to find out if it blows your memory limit several times over. Haskell is still a neat language, but we need less advocacy based on toy programs and more honest realism. (Here's a typical, non-superficial example: http://wagerlabs.com/haskell-vs-erlang-reloaded-0 http://wagerlabs.com/haskell-vs-erlang-reloaded-0)

gregwebs 15y ago
That post is from 2005. The situation is entirely different today w/respect to speed (both the compiler and the addition of ByteString and Text libraries), and productive libraries, particularly for web development. Likewise, it is a rare case that you would run into memory consumption issues. I do agree that there is entirely too much enthusiastic toying around in Haskell and not enough real world users and honesty about limitations.
- the_mat 15y ago
  To me, there's a dichotomy between the "if it compiles, it usually works" aspect of Haskell (and how this is often touted as superior to the dynamic typing, test-driven approach) and that you can't get a picture of memory usage until you run and profile the code. In my experience, hard to understand memory consumption issues are common and take effort to solve. Reference: http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-big-programs/ http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-bi...
  - gregwebs 15y ago
    That blog post says nothing about frequency of memory leaks, but shows that there are good tools to help you in your effort to solve them. One thing to keep in mind is that there are memory issues with every language. I just debugged one in Ruby yesterday, and there wasn't a good tool readily available for that effort. Do you know what the memory consumption of your programs are in other languages are before running them? As a contradictory anecdote, I have never once had a memory consumption issue with Haskell code. Haskell is actually in a nice position w/respect to memory now that enumerators (which always use constant memory) are taking hold. I have no doubt you encountered many memory leaks, but I don't think your experience completely generalises to modern Haskell.

exogen 15y ago

I'll say this again: Ted shouldn't have wasted everyone's time highlighting the response time of the request. He effectively benchmarked V8 right on his blog and then called it slow. Now everyone's complaining that people at least demonstrate that part to be untrue. Ironically, every one of his clients in the ab concurrency test will receive their responses before the users of the hypothetically parallel Python and Ruby services, because Node responds an order of magnitude faster. So he didn't actually demonstrate a problem.

T_S_ 15y ago

The ecosystem for Haskell is improving rapidly. My startup built a computer vision application on top of easyVision and with the intention of rewriting it in ObjC. Instead we are working with the Haskell community to target the mobile platform. A year ago that would have been a dicey bet. About our Haskell experience: Yes, the learning curve seems steep, but mainly because of the things you have to unlearn (OMG no for-loops!). However, functions are the most modular things ever invented. That translates into an uncanny ability to add features quickly. A sophisticated type system catches many errors at compile time.

giardini 15y ago

If Haskell is the Cure, what is the Disease?8-)) Haskell occupies a niche similar to Hamilton's quaternions (for classical physics) and Heisenberg's matrices (for quantum mechanics) - not mandatory, inaccessible to the masses and abandoned with haste once a more intuitive tool is found. But they will always be there if you need them.

jrockway 15y ago

Let's have a talk about the $ operator. When you use it more than once per line, you're writing code that looks weird and is hard to read. Switch to the similar function-composition operator, and everything looks more idiomatic. Instead of: fibServer x = quickHttpServe $ writeBS $ B.pack $ show (fibonacci x) Just write: fibServer = quickHttpServe . writeBS . B.pack . show . fibonacci The case for $ is where you want application instead of composition: fibOf42Server = quickHttpServe . writeBS . B.pack . show . fibonacci $ 42 I even write things like: main = print =<< foo instead of main = foo >>= print for consistency. Anyway, it's a little style thing, but it's nice to use the composition operator (.) when you want composition and the application operator ($) when you want application. It makes the code look nicer and it shows its intent more clearly. And really, they are different concepts, even if they both type-check the same. And finally, remember that function application, by default, is the highest-precedence operator in Haskell. When you write: foo . (bar 42) . baz It's the same as: foo . bar 42 . baz Because of operator precedence. $ only exists to change the order of operations for a particular expression.

Peaker 15y ago
I'll add that a nice little benefit of using: a . b . c . d $ e over: a $ b $ c $ d $ e is that any sub-expression taken from the first expression is valid and can be refactored out into its own name. (.) is associative and ($) is not.
bobfunk 15y ago
Really interesting style comment. Will keep this in mind.