10 ms·

Haskell in Production: The good, the bad, and the ugly

115 points by hamidr 14y ago

hamidr 14y ago
Ask HN: Anyone using Haskell in production? http://news.ycombinator.com/item?id=1909093 http://news.ycombinator.com/item?id=1909093
shin_lao 14y ago
Although I'm mainly a C++ developer, I'm a big fan of functional programming languages. Haskell is more difficult, it requires to really grasp some computer science principles whereas you can start hacking php/python/ruby right away. It requires to actually think about what you're going to do instead of integrating a couple of libraries: that's a double edged sword. You need to understand that the added value of Haskell for most start ups is near zero. It will more difficult to hire, the final result will not be better and in the end code quality matters less than business relevance. If your technical founder is a Haskell guru and knows a couple of engineers, then sure, why not, it may provide some competitive advantage, otherwise just forget about it.
- danieldk 14y ago
  Obligatory link: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- danieldk 14y ago
  You need to understand that the added value of Haskell for most start ups is near zero. I used to have that opinion as well, but I am slowly retracting it. Very strong typing and great abstraction does make development easier. E.g., I have been writing parsers lately for an application-specific macro language. Writing such parsers using a good Haskell parser combinator library such as parsec is many times more productive than parser generators for most imperative languages. Another advantage is that strong languages allow you to refactor code easily. If you change some types, the compiler will find type mismatches, allowing you to fix code rapidly. I can imagine that startups often refactor and substantially modify their codebase. In the end you do not only want to develop an application quickly, but also correctly. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup.
  - shin_lao 14y ago
    You have tools to help you find mismatches in Python. I agree that maintaining a large code base in Python (or Ruby) is harder, but it's possible and is mainly a question of discipline and process. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup. Most startups projects I've seen are technically trivial.
    - chii 14y ago
      > Most startups projects I've seen are technically trivial. may be this is due to the fact that technically non-trivial problems aren't easily solved by startups, who might tend to choose a technology thats easy to use (such as php/ruby), but makes it difficult to solve the technically non-trivial problems with the same degree of ease? I m just guessing here having no real insight.
    - papsosouid 14y ago
      >Most startups projects I've seen are technically trivial. Most startup projects are made by people who are only capable of solving technically trivial problems, and who are only willing to consider languages that make solving difficult problems borderline impossible. Imagine someone said "welding is a good way to fasten metal to metal". You are responding with "all the carpenters I've seen use screws".
  - mwotton 14y ago
    A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.
- dasil003 14y ago
  If the outlook is short-term than I agree. You will always be able to hack out a quick solution in PHP/Ruby/Lisp much faster than Haskell. But this advantage is only unmitigated if you fail and the code goes away before it has to be maintained. If the code is going to be around for a while it's going to need to be maintained, and here the advantage of Haskell grows with the code base size. It's a bit deceiving because the type of bugs that Haskell will catch automatically are not so much of a burden in a greenfield Ruby project, rather it's years later after bitrot and layers of iteration and no one really understands the whole system anymore that the advantages of Haskell really shine. Granted, if you don't know Haskell then it's not worth the cost to learn with everything else you need to juggle when doing a startup, but if you can, I believe there are significant long-term advantages.
  - mwotton 14y ago
    It really depends on the type of risk. My assertion is that most startups have most of their risk in the market bucket rather than the technical bucket. If you can move some risk from the market bucket to the technical bucket, and compensate by using Haskell, that may be a good tradeoff. in the case where your risk is in the market bucket, you may go through many just-barely-working prototypes before you hit product-market fit. at that point, if you've saved some time using Ruby (say) because of external factors like Heroku, Bundler, and ruby-friendly services, you're ahead of the game, even if your tenth prototype sucks and needs to be rewritten.
klibertp 14y ago
"strong static types save time" I would find the presentation without controversial points at all were it not for this one sentence :) Edit: aaargh, I treated mention of Ruby primitivism as a joke and forgot about it; if taken seriously it can be controversial as well.
- rpearl 14y ago
  every single NoneType error I have gotten using in the python I'm paid to write would go away with a static type system. Every single function I've changed the signature of and then failed to change one caller would go away with a static type system. I cannot count the number of times I've had to stop and write down the types of things I wanted to reason about, an d then keep all that in my head, to figure out what was going on in a large code base. Guess what? Most of the types were static. If I had Haskell's good type inference, I wouldn't have had to do any of this time-wasting endeavor. The statement isn't controversial. Correct code type-checks. When there are type errors in your code, in a dynamic language, they would be bugs found at runtime. [edit for formatting]
  - klibertp 14y ago
    And then you need to write some serialization code or IPC and static type system is a pain or just makes it plain impossible to do (in which case this is a shortcoming of this particular type system, not the idea itself, but still). No, I don't want to argue and I'm not religiously in favor of either unityped or typed languages. I have no problem in admitting that there are things that are made easier with static typing. I'm having good time writing both in OCaml and Erlang. On the other hand it worries me that proponents of static typing have difficulty admitting that even most sophisticated type systems are not suited for certain other tasks.
    - jroesch 14y ago
      To me it seems that the point on serialization is completely moot in languages like Haskell(what we are talking about), serialization may be hard(er) to do in a language like Java or C++ where we have a rooted type hierarchy and we can't easily add new functionality, or do type based dispatch. Haskell's type classes allow us the freedom to define new kinds of functionality on top of existing types easily. You can look at libraries like Aeson, which allows serialization and deserialization from JSON with just a few lines of code. The biggest problem is that people's view is strapped to this old dynamic Lisp vs. C kind of paradigm that doesn't exist in modern functional languages.
_pferreir_ 14y ago
> Ruby is amazingly primitive What? In what sense in Ruby primitive?
- wladimir 14y ago
  "primitive" is an awkwardly chosen word with negative connotations... I suppose it is in the sense that it doesn't do type inference (or reasoning about types at all, for that matter). Like a Lisp it simply executes what you write without any validation beyond syntax checking. The idea is that Haskell's type-based, lazy approach allows for a more high-level approach of specifying what you want instead of how you want it executed. I'm not sure it always succeeds in that, but that's another matter. It's an interesting language nevertheless, with elegant code, but if I need to build something quickly I fall back to Python (which is "primitive" in the same sense as Ruby).
  - klibertp 14y ago
    > Like a Lisp You know about Typed Racked and possibly other efforts, right? http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/
    - wladimir 14y ago
      Well not really. I had a vague sense that there are extensions that add typing, but not more. My experiences with Lisp are mostly limited to SICP. Thanks for the link.
      - klibertp 14y ago
        No problem. Generally, talking about Lisps in this context is not a very good idea - I couldn't find the link, but I remember that in the comments on lambda-the-ultimate someone demonstrated equivalence of static type systems and lisp macros by providing compile time guarantees that then-discussed static type system gave. I'll try to find this discussion later, or maybe someone has the link ready?
  - 14y ago
tikhonj 14y ago
I don't think the library situation is nearly as bad as some people--not necessarily the author of this presentation--make out. For one, Haskell actually has a pretty good and growing collection of libraries, probably disproportionate to the language's popularity. Web development, in particular, is well represented: there are several competing web frameworks; Yesod even has commercial backing now. Haskell even has some libraries that are not well reproduced in other languages like QuickCheck and Parsec. I've also been looking at sbv lately, which seems rather more convenient than other languages' alternatives. Additionally, libraries aren't the only thing that matters. In fact, most libraries are pretty trivial. I remember seeing a presentation by Brian O'Sullivan online about his experiences with using Haskell at a startup. One point that really stood out to me was about libraries: sure, some libraries (like JSON parsing, I believe) were missing; however, it only took him something like a couple of days to write it from scratch. Those days are easily overshadowed by Haskell's core advantages. I would much rather spend a couple of days writing a new library than trying to track down a bug Haskell's type system would have caught. The beauty of this system is also that each library only needs to be written once and can then be reused, making the world better for everyone. Now, there are some other issues with Haskell. Cabal really is a big one. I just spent quite a while fighting cabal, and I'm not even sure how I won in the end :P. Happily, I believe people are working on addressing the cabal issue. I'm sure there are other annoyances besides. But no language is entirely free of annoyances. Considering everything, I really do think Haskell is a good choice for a very wide range of programming problems, especially in a startup setting.
- Argorak 14y ago
  I find the linked slideset uninteresting, as it misses the speakers words - its just a collection of positive and negative words. Still, I want to reply to your comment, even if my reply is bit harsh, but Haskell always makes me a bit bitter: First of all, I played with some web frameworks in Haskell and didn't like them at all: the yesod community had a very dismissive tone towards people that didn't want to use what they perceived as "standard" and Snap is well organized, but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?). I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring. Its nice that you picked the JSON library (by Brian?) as an example for a lib that can be written in "a few day". `aeson` is a great library. Its just not something that someone without detailed Haskell knowledge can write in a few days. It requires good knowledge of Haskell, especially things like the GHC.Generics library and Template Haskell (Hint: GHC.Generics is not very well documented for practical uses as well, the documentation spares you of the hard cases). I found that if you go away from those 'core' libraries, quality drops sharply. Giving just one example may be unfair, but I do it anyways: the readline bindings (haskeline) didn't build on OS X for 2 major releases straight. Also 0.1 and 0.2 seem to be very common version numbers on hackage and most documentation boils down to type descriptions. For loves sake, I couldn't find a good and proper tutorial working with bidirectional streams (think websockets) and asking a GHC committer ended in "well, we're still not sure what the best abstraction for this is, theres multiple competing" and someone on the Haskell User Group Berlin said "well, its not such an easy problem, but it will be solved in a year or so". In Ruby, thats implemented in an hour (safe and sound using libraries, with proper abstractions), today. Yes, I honestly think that the library situation is bad - its not the lack of libraries, its the number of half-hearted libraries vs. the real good ones. Also: Pro-active teaching, like producing screencasts and tutorials is sadly not very common in the Haskell community as well (weirdly, this is spotty: haskell-cafe, Real World Haskell and Learn you a Haskell are shining examples of how things should be, also in other communities). I am surprised by how much the Haskell community always says "type system" first, but seems to put all other practical considerations on the backseat. Also, it is common to just dismiss concerns without addressing them. That said, I still love Haskell and enjoy developing in it when things are working smoothly, I just wished that the community were more receptive and less dismissive to actual problems of people that are not as deep inside the language as people spending every evening on it.
comex 14y ago
I don't even know Ruby, but it's clear that the idea that Ruby is an "amazingly primitive" language that people are using instead of Haskell because it has existing libraries and services or because "startups are not technical" is drastically wrong and almost insulting. To the contrary, Ruby, probably more than any other language, has a large community that's highly enthusiastic about its programming style and culture, which is the reason most of those libraries and ecosystems were created in the first place. I know this is just a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell (plus a motorcycle) along with three seemingly random relatively small issues as criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of unrecognizability.
- nnq 14y ago
  yep, the OP is asking for a flamewar by putting the horse wagon and the "primitive" keyword in there. ...though I like the unintended message he's sending with the motorbike pic for Haskell: it's hot, fast, but it really can get you killed! :)
- Argorak 14y ago
  I think he is referring to the implementation of MRI. First of all, its not as primitive as some people make it and second, there are multiple alternatives that gave a lot of thought to how to fix all the problems of MRI (JRuby, Rubinius).
- regularfry 14y ago
  Compared to GHC, MRI really is primitive. Parts of this are intentional: the object model is intentionally simple, and one of the design goals was to keep unixy goodness close to the surface, so the IO model, forking and so on are quite shallow shim layers over the system calls. Other parts, like the threading, the GC, and the parser (oh god, the parser) are suffering from baggage that's never had GHC-levels of academic effort thrown at it. To the contrary, Ruby, probably more than any other language, has a large community that's highly enthusiastic about its programming style and culture, which is the reason most of those libraries and ecosystems were created in the first place. I know this is just a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell (plus a motorcycle) along with three seemingly random relatively small issues as criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of unrecognizability The presentation is making the point that MRI itself is primitive, and addresses the plus points of the community in the very next slide. For people who care about the implementation underlying their code as much as they care about their own code (or more), MRI's shortcomings are a visible downside.
nnq 14y ago
...I know that HN people are mostly *NIX oriented or dislike Microsoft technologies ...but how about F#? ...wouldn't it provide most of the advantages of a ML family language but coupled with the "smoothness" of VS tooling and .Net integration that could take some of the deployment pains away and provide the "accelerated liftoff" needed by startups? (It's a question, not suggestion... I must admit I've never had the balls to use ML of Lisp like languages in production so far...)
- ryanpers 14y ago
  well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.
  - nnq 14y ago
    I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)
    - MichaelGG 14y ago
      I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing). Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive). mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.) F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance. F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.
ryanpers 14y ago
"startups arent technical" I guess YOUR startup isnt technical... But there are in fact technical startups out there. It's just that they make more money than yours, do better and are generally cooler.
- nnq 14y ago
  ...upvoted you for the pure and refreshing "geek power" spirit of the comment :) ...really miss this attitude lately, too much "business-think" everywhere ...now back to real work
- mwotton 14y ago
  My startup involved custom hardware and realtime messaging. I still would have been better off in the early stages writing it in Ruby.
arocks 14y ago
Ah, powerpoint presentations where the truth is somewhere between the bullet points. I would have preferred a blog post which gives the author enough breathing space to justify his claims. Haskell's single biggest problem is that it looks unfamiliar to programmers who are trained in traditional imperative languages. Due to its minimal syntax, its error messages can be confusing to a learner. New languages like Scala and Clojure are packaging many of Haskell's concepts in a more familiar syntax. They are gaining popularity since they actually solve hard problems like concurrency. In my opinion, startups prefer Ruby because they prefer to start solving the problem right away without worrying too much about its correctness. A classic case of "Worse is better" works for most web applications. Whereas, Haskell requires some thinking into how to best model the solution before you start implementing it. This often leads to more 'correct' code.
- prof_hobart 14y ago
  I think that one of its biggest problems has been the vast majority of the "Teach Yourself Haskell" books/articles. When I first had a go at learning it, I ran into two common problems with them. Firstly they usually did a great job of showing you how to write a quicksort or a Fibonacci sequence but then struggled to explain how it applied to most every day challenges (things like i/o - and yes, I sort of understand the complexity around that in Haskell, but as a developer, it's one of the key things I'm likely to want to do). The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc "fib' (f, g) p" for example. When you're already struggling to understand langauge concepts, having your code full of "f,g, and p" and trying to remember what they mean really doesn't help. I think it's improving (Learn You a Haskell looks pretty good, but I've not had a serious attempt to re-learn since that appeared), but it's always been a bit of stumbling block for me in the past.
  - adimitrov 14y ago
    The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc. That's mostly due to the mathematical or computer-science background of most people who wrote these articles in the early days. It's entirely normal in mathematics etc. to use brief variable names, and it carried over into Haskell because of the large cultural overlap between Haskellers and academics. For short examples, I hugely prefer the short notation with "appalling" names, but that might be due to my background in formal logic and mathematics. It doesn't help in software development, and it's poison in larger applications, that's for sure. But for short examples, you get used to it pretty quickly. You should check out both Real World Haskell and Learn You a Haskell (both are also freely available online.) They're really well-written, and part of why Haskell's community is so awesome.
forgotusername 14y ago
I've no doubt this presentation makes some interesting points, but I'm as inclined to finish reading it after noticing it's destroying my browser history as I would continue evaluating software after noticing it's randomly corrupting my home directory. Please leave history alone or at least use window.history.replaceState().
- regularfry 14y ago
  Also a bloody pain to read on a mobile device.
  - lmm 14y ago
    It's not exactly easy to read on a desktop either.
cabalamat 14y ago
Does anyone really think that a slide presentation is a better way of saying what the author wanted to say than an essay? And if so, do they also think that Norvig's Gettysburg Powerpoint Presentation is better than Lincoln's Gettysburg Address?
Bjoern 14y ago
Is this a slideshow? I can't do anything here in FF 16.0.1.
- mooism2 14y ago
  Try the cursor keys?
- bazzargh 14y ago
  Ditto. I just turned off page styles and read the text. There's not much of it.
Qerub 14y ago
I'll consider Haskell for serious programming when (and if) it gets a decent record system. http://bloggablea.wordpress.com/2007/04/24/haskell-records-considered-grungy/ http://bloggablea.wordpress.com/2007/04/24/haskell-records-c...
- nandemo 14y ago
  That blog post seems fairly outdated. There are several lenses libraries that provide decent record support: http://stackoverflow.com/questions/5767129/lenses-fclabels-data-accessor-which-library-for-structure-access-and-mutatio http://stackoverflow.com/questions/5767129/lenses-fclabels-d... Personally, I'd much rather have a better baked-in record system, but that's unlikely to change substantially now.
  - applicative 14y ago
    The state of the art is the amazing `lens` package https://github.com/ekmett/lens/wiki/Overview https://github.com/ekmett/lens/wiki/Overview . See this example, https://github.com/ekmett/lens/blob/master/examples/Pong.hs https://github.com/ekmett/lens/blob/master/examples/Pong.hs
    - Qerub 14y ago
      Looks great! I hope it gets more broadly adopted. Thanks for sharing.
  - Qerub 14y ago
    The post might be old, but AFAIK there have been no significant changes in the built-in record system since. Sure, there are great lens libraries but until the Haskell community blesses one of them the result is a mess of many incompatible record systems. Not exactly the best way to foster a thriving open source community.
Supreme 14y ago
This is a terrible set of slides. The only new thing I gathered from it is "cabal sucks". Then the presentation came to a sudden end which left me thinking "what, that's it?" How does such a low quality link get so many upvotes? takes notes for future marketing endeavours
- mwotton 14y ago
  It wasn't really intended to make much sense by itself. I find if I make slides that stand alone, the audience reads the slides and ignores me. I put the slides up as a courtesy to the people in the audience. There was less than zero marketing involved - I gave this talk months ago and only just noticed this thread.
  - Supreme 14y ago
    Apologies if I sounded like I was criticising what you do - I'm sure that these made a lot more sense in the context of a presentation. I was questioning why the person who posted this link did so and why it has been upvoted to such an extent.
    - mwotton 14y ago
      not caremad, just clarifying. I'm as baffled as you are.
- ky3 14y ago
  takes notes for future marketing endeavours Lol. :) Didn't you notice the multiple david vs goliath references? Or the challenger vs incumbent dimension? Conflict makes for a good story makes for frontpage news. Moreover, the 50/50 text/visuals is a refreshing change away from huge blocks of gray.
  - mwotton 14y ago
    ha. I didn't think that at all when I was writing it, but I can see how it's applicable. I'll be sure to analyse that more explicitly next time I write a presentation.
peterjs 14y ago
What does CoW mean? As in "GC breaks CoW & caching". There are quite a few acronyms and supposedly even some animal with these three letters.
- mwotton 14y ago
  Copy-on-write.
the1 14y ago
eh? haskell program can be really slow, especially when it is written by non-experts who don't understand lazy evaluation well.
- Deestan 14y ago
  A <Language> program can be really slow, especially when it's written by non-experts who don't understand <CorePrinciple> well.
beering 14y ago
What about virthualenv (virtualenv for Haskell)? Does that help alleviate some of the cabal issues?
- boothead 14y ago
  It worked well for me, and there's cabal-dev too. BTW, I think virthualenv is now called hsenv.
thu 14y ago
I think it is very positive. I read it as "Things are being done, please be patient. B.t.w. what's done is insanely great".
finnw 14y ago
* $LANGUAGE is amazingly primitive * GC breaks CoW & caching * dynamic -> lexical scoping between $OLD_VERSION & $NEW_VERSION * concurrent behaviour requires event-driven style Exactly the same could have been written about Lisp in the late 80s

115 points by hamidr 14y ago

Ask HN: Anyone using Haskell in production? http://news.ycombinator.com/item?id=1909093 http://news.ycombinator.com/item?id=1909093

shin_lao 14y ago

Although I'm mainly a C++ developer, I'm a big fan of functional programming languages. Haskell is more difficult, it requires to really grasp some computer science principles whereas you can start hacking php/python/ruby right away. It requires to actually think about what you're going to do instead of integrating a couple of libraries: that's a double edged sword. You need to understand that the added value of Haskell for most start ups is near zero. It will more difficult to hire, the final result will not be better and in the end code quality matters less than business relevance. If your technical founder is a Haskell guru and knows a couple of engineers, then sure, why not, it may provide some competitive advantage, otherwise just forget about it.

danieldk 14y ago
Obligatory link: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
danieldk 14y ago
You need to understand that the added value of Haskell for most start ups is near zero. I used to have that opinion as well, but I am slowly retracting it. Very strong typing and great abstraction does make development easier. E.g., I have been writing parsers lately for an application-specific macro language. Writing such parsers using a good Haskell parser combinator library such as parsec is many times more productive than parser generators for most imperative languages. Another advantage is that strong languages allow you to refactor code easily. If you change some types, the compiler will find type mismatches, allowing you to fix code rapidly. I can imagine that startups often refactor and substantially modify their codebase. In the end you do not only want to develop an application quickly, but also correctly. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup.
- shin_lao 14y ago
  You have tools to help you find mismatches in Python. I agree that maintaining a large code base in Python (or Ruby) is harder, but it's possible and is mainly a question of discipline and process. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup. Most startups projects I've seen are technically trivial.
  - chii 14y ago
    > Most startups projects I've seen are technically trivial. may be this is due to the fact that technically non-trivial problems aren't easily solved by startups, who might tend to choose a technology thats easy to use (such as php/ruby), but makes it difficult to solve the technically non-trivial problems with the same degree of ease? I m just guessing here having no real insight.
  - papsosouid 14y ago
    >Most startups projects I've seen are technically trivial. Most startup projects are made by people who are only capable of solving technically trivial problems, and who are only willing to consider languages that make solving difficult problems borderline impossible. Imagine someone said "welding is a good way to fasten metal to metal". You are responding with "all the carpenters I've seen use screws".
- mwotton 14y ago
  A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.
dasil003 14y ago
If the outlook is short-term than I agree. You will always be able to hack out a quick solution in PHP/Ruby/Lisp much faster than Haskell. But this advantage is only unmitigated if you fail and the code goes away before it has to be maintained. If the code is going to be around for a while it's going to need to be maintained, and here the advantage of Haskell grows with the code base size. It's a bit deceiving because the type of bugs that Haskell will catch automatically are not so much of a burden in a greenfield Ruby project, rather it's years later after bitrot and layers of iteration and no one really understands the whole system anymore that the advantages of Haskell really shine. Granted, if you don't know Haskell then it's not worth the cost to learn with everything else you need to juggle when doing a startup, but if you can, I believe there are significant long-term advantages.
- mwotton 14y ago
  It really depends on the type of risk. My assertion is that most startups have most of their risk in the market bucket rather than the technical bucket. If you can move some risk from the market bucket to the technical bucket, and compensate by using Haskell, that may be a good tradeoff. in the case where your risk is in the market bucket, you may go through many just-barely-working prototypes before you hit product-market fit. at that point, if you've saved some time using Ruby (say) because of external factors like Heroku, Bundler, and ruby-friendly services, you're ahead of the game, even if your tenth prototype sucks and needs to be rewritten.

klibertp 14y ago

"strong static types save time" I would find the presentation without controversial points at all were it not for this one sentence :) Edit: aaargh, I treated mention of Ruby primitivism as a joke and forgot about it; if taken seriously it can be controversial as well.

rpearl 14y ago
every single NoneType error I have gotten using in the python I'm paid to write would go away with a static type system. Every single function I've changed the signature of and then failed to change one caller would go away with a static type system. I cannot count the number of times I've had to stop and write down the types of things I wanted to reason about, an d then keep all that in my head, to figure out what was going on in a large code base. Guess what? Most of the types were static. If I had Haskell's good type inference, I wouldn't have had to do any of this time-wasting endeavor. The statement isn't controversial. Correct code type-checks. When there are type errors in your code, in a dynamic language, they would be bugs found at runtime. [edit for formatting]
- klibertp 14y ago
  And then you need to write some serialization code or IPC and static type system is a pain or just makes it plain impossible to do (in which case this is a shortcoming of this particular type system, not the idea itself, but still). No, I don't want to argue and I'm not religiously in favor of either unityped or typed languages. I have no problem in admitting that there are things that are made easier with static typing. I'm having good time writing both in OCaml and Erlang. On the other hand it worries me that proponents of static typing have difficulty admitting that even most sophisticated type systems are not suited for certain other tasks.
  - jroesch 14y ago
    To me it seems that the point on serialization is completely moot in languages like Haskell(what we are talking about), serialization may be hard(er) to do in a language like Java or C++ where we have a rooted type hierarchy and we can't easily add new functionality, or do type based dispatch. Haskell's type classes allow us the freedom to define new kinds of functionality on top of existing types easily. You can look at libraries like Aeson, which allows serialization and deserialization from JSON with just a few lines of code. The biggest problem is that people's view is strapped to this old dynamic Lisp vs. C kind of paradigm that doesn't exist in modern functional languages.

_pferreir_ 14y ago

> Ruby is amazingly primitive What? In what sense in Ruby primitive?

wladimir 14y ago
"primitive" is an awkwardly chosen word with negative connotations... I suppose it is in the sense that it doesn't do type inference (or reasoning about types at all, for that matter). Like a Lisp it simply executes what you write without any validation beyond syntax checking. The idea is that Haskell's type-based, lazy approach allows for a more high-level approach of specifying what you want instead of how you want it executed. I'm not sure it always succeeds in that, but that's another matter. It's an interesting language nevertheless, with elegant code, but if I need to build something quickly I fall back to Python (which is "primitive" in the same sense as Ruby).
- klibertp 14y ago
  > Like a Lisp You know about Typed Racked and possibly other efforts, right? http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/
  - wladimir 14y ago
    Well not really. I had a vague sense that there are extensions that add typing, but not more. My experiences with Lisp are mostly limited to SICP. Thanks for the link.
    - klibertp 14y ago
      No problem. Generally, talking about Lisps in this context is not a very good idea - I couldn't find the link, but I remember that in the comments on lambda-the-ultimate someone demonstrated equivalence of static type systems and lisp macros by providing compile time guarantees that then-discussed static type system gave. I'll try to find this discussion later, or maybe someone has the link ready?
- 14y ago

tikhonj 14y ago

I don't think the library situation is nearly as bad as some people--not necessarily the author of this presentation--make out. For one, Haskell actually has a pretty good and growing collection of libraries, probably disproportionate to the language's popularity. Web development, in particular, is well represented: there are several competing web frameworks; Yesod even has commercial backing now. Haskell even has some libraries that are not well reproduced in other languages like QuickCheck and Parsec. I've also been looking at sbv lately, which seems rather more convenient than other languages' alternatives. Additionally, libraries aren't the only thing that matters. In fact, most libraries are pretty trivial. I remember seeing a presentation by Brian O'Sullivan online about his experiences with using Haskell at a startup. One point that really stood out to me was about libraries: sure, some libraries (like JSON parsing, I believe) were missing; however, it only took him something like a couple of days to write it from scratch. Those days are easily overshadowed by Haskell's core advantages. I would much rather spend a couple of days writing a new library than trying to track down a bug Haskell's type system would have caught. The beauty of this system is also that each library only needs to be written once and can then be reused, making the world better for everyone. Now, there are some other issues with Haskell. Cabal really is a big one. I just spent quite a while fighting cabal, and I'm not even sure how I won in the end :P. Happily, I believe people are working on addressing the cabal issue. I'm sure there are other annoyances besides. But no language is entirely free of annoyances. Considering everything, I really do think Haskell is a good choice for a very wide range of programming problems, especially in a startup setting.

Argorak 14y ago
I find the linked slideset uninteresting, as it misses the speakers words - its just a collection of positive and negative words. Still, I want to reply to your comment, even if my reply is bit harsh, but Haskell always makes me a bit bitter: First of all, I played with some web frameworks in Haskell and didn't like them at all: the yesod community had a very dismissive tone towards people that didn't want to use what they perceived as "standard" and Snap is well organized, but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?). I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring. Its nice that you picked the JSON library (by Brian?) as an example for a lib that can be written in "a few day". `aeson` is a great library. Its just not something that someone without detailed Haskell knowledge can write in a few days. It requires good knowledge of Haskell, especially things like the GHC.Generics library and Template Haskell (Hint: GHC.Generics is not very well documented for practical uses as well, the documentation spares you of the hard cases). I found that if you go away from those 'core' libraries, quality drops sharply. Giving just one example may be unfair, but I do it anyways: the readline bindings (haskeline) didn't build on OS X for 2 major releases straight. Also 0.1 and 0.2 seem to be very common version numbers on hackage and most documentation boils down to type descriptions. For loves sake, I couldn't find a good and proper tutorial working with bidirectional streams (think websockets) and asking a GHC committer ended in "well, we're still not sure what the best abstraction for this is, theres multiple competing" and someone on the Haskell User Group Berlin said "well, its not such an easy problem, but it will be solved in a year or so". In Ruby, thats implemented in an hour (safe and sound using libraries, with proper abstractions), today. Yes, I honestly think that the library situation is bad - its not the lack of libraries, its the number of half-hearted libraries vs. the real good ones. Also: Pro-active teaching, like producing screencasts and tutorials is sadly not very common in the Haskell community as well (weirdly, this is spotty: haskell-cafe, Real World Haskell and Learn you a Haskell are shining examples of how things should be, also in other communities). I am surprised by how much the Haskell community always says "type system" first, but seems to put all other practical considerations on the backseat. Also, it is common to just dismiss concerns without addressing them. That said, I still love Haskell and enjoy developing in it when things are working smoothly, I just wished that the community were more receptive and less dismissive to actual problems of people that are not as deep inside the language as people spending every evening on it.

comex 14y ago

I don't even know Ruby, but it's clear that the idea that Ruby is an "amazingly primitive" language that people are using instead of Haskell because it has existing libraries and services or because "startups are not technical" is drastically wrong and almost insulting. To the contrary, Ruby, probably more than any other language, has a large community that's highly enthusiastic about its programming style and culture, which is the reason most of those libraries and ecosystems were created in the first place. I know this is just a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell (plus a motorcycle) along with three seemingly random relatively small issues as criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of unrecognizability.

nnq 14y ago
yep, the OP is asking for a flamewar by putting the horse wagon and the "primitive" keyword in there. ...though I like the unintended message he's sending with the motorbike pic for Haskell: it's hot, fast, but it really can get you killed! :)
Argorak 14y ago
I think he is referring to the implementation of MRI. First of all, its not as primitive as some people make it and second, there are multiple alternatives that gave a lot of thought to how to fix all the problems of MRI (JRuby, Rubinius).
regularfry 14y ago
Compared to GHC, MRI really is primitive. Parts of this are intentional: the object model is intentionally simple, and one of the design goals was to keep unixy goodness close to the surface, so the IO model, forking and so on are quite shallow shim layers over the system calls. Other parts, like the threading, the GC, and the parser (oh god, the parser) are suffering from baggage that's never had GHC-levels of academic effort thrown at it. To the contrary, Ruby, probably more than any other language, has a large community that's highly enthusiastic about its programming style and culture, which is the reason most of those libraries and ecosystems were created in the first place. I know this is just a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell (plus a motorcycle) along with three seemingly random relatively small issues as criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of unrecognizability The presentation is making the point that MRI itself is primitive, and addresses the plus points of the community in the very next slide. For people who care about the implementation underlying their code as much as they care about their own code (or more), MRI's shortcomings are a visible downside.

nnq 14y ago

...I know that HN people are mostly *NIX oriented or dislike Microsoft technologies ...but how about F#? ...wouldn't it provide most of the advantages of a ML family language but coupled with the "smoothness" of VS tooling and .Net integration that could take some of the deployment pains away and provide the "accelerated liftoff" needed by startups? (It's a question, not suggestion... I must admit I've never had the balls to use ML of Lisp like languages in production so far...)

ryanpers 14y ago
well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.
- nnq 14y ago
  I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)
  - MichaelGG 14y ago
    I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing). Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive). mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.) F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance. F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.

ryanpers 14y ago

"startups arent technical" I guess YOUR startup isnt technical... But there are in fact technical startups out there. It's just that they make more money than yours, do better and are generally cooler.

nnq 14y ago
...upvoted you for the pure and refreshing "geek power" spirit of the comment :) ...really miss this attitude lately, too much "business-think" everywhere ...now back to real work
mwotton 14y ago
My startup involved custom hardware and realtime messaging. I still would have been better off in the early stages writing it in Ruby.

arocks 14y ago

Ah, powerpoint presentations where the truth is somewhere between the bullet points. I would have preferred a blog post which gives the author enough breathing space to justify his claims. Haskell's single biggest problem is that it looks unfamiliar to programmers who are trained in traditional imperative languages. Due to its minimal syntax, its error messages can be confusing to a learner. New languages like Scala and Clojure are packaging many of Haskell's concepts in a more familiar syntax. They are gaining popularity since they actually solve hard problems like concurrency. In my opinion, startups prefer Ruby because they prefer to start solving the problem right away without worrying too much about its correctness. A classic case of "Worse is better" works for most web applications. Whereas, Haskell requires some thinking into how to best model the solution before you start implementing it. This often leads to more 'correct' code.

prof_hobart 14y ago
I think that one of its biggest problems has been the vast majority of the "Teach Yourself Haskell" books/articles. When I first had a go at learning it, I ran into two common problems with them. Firstly they usually did a great job of showing you how to write a quicksort or a Fibonacci sequence but then struggled to explain how it applied to most every day challenges (things like i/o - and yes, I sort of understand the complexity around that in Haskell, but as a developer, it's one of the key things I'm likely to want to do). The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc "fib' (f, g) p" for example. When you're already struggling to understand langauge concepts, having your code full of "f,g, and p" and trying to remember what they mean really doesn't help. I think it's improving (Learn You a Haskell looks pretty good, but I've not had a serious attempt to re-learn since that appeared), but it's always been a bit of stumbling block for me in the past.
- adimitrov 14y ago
  The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc. That's mostly due to the mathematical or computer-science background of most people who wrote these articles in the early days. It's entirely normal in mathematics etc. to use brief variable names, and it carried over into Haskell because of the large cultural overlap between Haskellers and academics. For short examples, I hugely prefer the short notation with "appalling" names, but that might be due to my background in formal logic and mathematics. It doesn't help in software development, and it's poison in larger applications, that's for sure. But for short examples, you get used to it pretty quickly. You should check out both Real World Haskell and Learn You a Haskell (both are also freely available online.) They're really well-written, and part of why Haskell's community is so awesome.

forgotusername 14y ago

I've no doubt this presentation makes some interesting points, but I'm as inclined to finish reading it after noticing it's destroying my browser history as I would continue evaluating software after noticing it's randomly corrupting my home directory. Please leave history alone or at least use window.history.replaceState().

regularfry 14y ago
Also a bloody pain to read on a mobile device.
- lmm 14y ago
  It's not exactly easy to read on a desktop either.

cabalamat 14y ago

Does anyone really think that a slide presentation is a better way of saying what the author wanted to say than an essay? And if so, do they also think that Norvig's Gettysburg Powerpoint Presentation is better than Lincoln's Gettysburg Address?

Bjoern 14y ago

Is this a slideshow? I can't do anything here in FF 16.0.1.

mooism2 14y ago
Try the cursor keys?
bazzargh 14y ago
Ditto. I just turned off page styles and read the text. There's not much of it.

Qerub 14y ago

I'll consider Haskell for serious programming when (and if) it gets a decent record system. http://bloggablea.wordpress.com/2007/04/24/haskell-records-considered-grungy/ http://bloggablea.wordpress.com/2007/04/24/haskell-records-c...

nandemo 14y ago
That blog post seems fairly outdated. There are several lenses libraries that provide decent record support: http://stackoverflow.com/questions/5767129/lenses-fclabels-data-accessor-which-library-for-structure-access-and-mutatio http://stackoverflow.com/questions/5767129/lenses-fclabels-d... Personally, I'd much rather have a better baked-in record system, but that's unlikely to change substantially now.
- applicative 14y ago
  The state of the art is the amazing `lens` package https://github.com/ekmett/lens/wiki/Overview https://github.com/ekmett/lens/wiki/Overview . See this example, https://github.com/ekmett/lens/blob/master/examples/Pong.hs https://github.com/ekmett/lens/blob/master/examples/Pong.hs
  - Qerub 14y ago
    Looks great! I hope it gets more broadly adopted. Thanks for sharing.
- Qerub 14y ago
  The post might be old, but AFAIK there have been no significant changes in the built-in record system since. Sure, there are great lens libraries but until the Haskell community blesses one of them the result is a mess of many incompatible record systems. Not exactly the best way to foster a thriving open source community.

Supreme 14y ago

This is a terrible set of slides. The only new thing I gathered from it is "cabal sucks". Then the presentation came to a sudden end which left me thinking "what, that's it?" How does such a low quality link get so many upvotes? takes notes for future marketing endeavours

mwotton 14y ago
It wasn't really intended to make much sense by itself. I find if I make slides that stand alone, the audience reads the slides and ignores me. I put the slides up as a courtesy to the people in the audience. There was less than zero marketing involved - I gave this talk months ago and only just noticed this thread.
- Supreme 14y ago
  Apologies if I sounded like I was criticising what you do - I'm sure that these made a lot more sense in the context of a presentation. I was questioning why the person who posted this link did so and why it has been upvoted to such an extent.
  - mwotton 14y ago
    not caremad, just clarifying. I'm as baffled as you are.
ky3 14y ago
takes notes for future marketing endeavours Lol. :) Didn't you notice the multiple david vs goliath references? Or the challenger vs incumbent dimension? Conflict makes for a good story makes for frontpage news. Moreover, the 50/50 text/visuals is a refreshing change away from huge blocks of gray.
- mwotton 14y ago
  ha. I didn't think that at all when I was writing it, but I can see how it's applicable. I'll be sure to analyse that more explicitly next time I write a presentation.

peterjs 14y ago

What does CoW mean? As in "GC breaks CoW & caching". There are quite a few acronyms and supposedly even some animal with these three letters.

mwotton 14y ago
Copy-on-write.

the1 14y ago

eh? haskell program can be really slow, especially when it is written by non-experts who don't understand lazy evaluation well.

Deestan 14y ago
A <Language> program can be really slow, especially when it's written by non-experts who don't understand <CorePrinciple> well.

beering 14y ago

What about virthualenv (virtualenv for Haskell)? Does that help alleviate some of the cabal issues?

boothead 14y ago
It worked well for me, and there's cabal-dev too. BTW, I think virthualenv is now called hsenv.

thu 14y ago

I think it is very positive. I read it as "Things are being done, please be patient. B.t.w. what's done is insanely great".

finnw 14y ago

* $LANGUAGE is amazingly primitive * GC breaks CoW & caching * dynamic -> lexical scoping between $OLD_VERSION & $NEW_VERSION * concurrent behaviour requires event-driven style Exactly the same could have been written about Lisp in the late 80s