13 ms·

Mastering Time-to-Market with Haskell

142 points by Tehnix 10y ago

pron 10y ago
> In summary we've seen that: Haskell decreases development time... Have we actually seen that or have you just asserted that? Is this really true, and if it is, by how much? Haskell has been around for a couple of decades now, and has had least two hype cycles (I remember that when I was in university in the late '90s, Haskell was the next big thing). It does not seem to expand significantly even within organizations that have tried it (and that's a very negative signal), with at least one notable case where the language has been abandoned by a company that was among the flagship adopters. In general, we know that often linguistic abstractions that seem like a good idea in theory -- or even seem to work nicely in small programs -- don't end up having a significant effect on the bottom line when larger software is concerned. People say that scientific evidence of actual contribution is hard to collect, but we don't even have well-researched anecdotes. Not only do we not have strong evidence in favor of this hypothesis, but there aren't even promising hints. All we do have is people who really like Haskell based on its aesthetics and really wish that the the nice theoretical arguments translated to significant bottom-line gains. This blog post by Dan Ghica, a PL researcher, really addresses this point: there is nothing to suggest that aesthetically nice theory translates to actual software development gains, and wishful thinking (or personal affinity) simply cannot replace gathering of data: http://danghica.blogspot.com/2016/09/what-else-are-we-getting-wrong.html http://danghica.blogspot.com/2016/09/what-else-are-we-gettin...
- radicality 10y ago
  Not the author and I don't know much besides a little dabbling in Haskell, but I'm sure that quote holds true, but only if the engineer already is an intermediate-advanced Haskeller, which probably translates to at least a couple years of daily Haskell work.
  - pron 10y ago
    > but I'm sure that quote holds true How can you be sure? Have you seen Haskell shops churn out software significantly faster than others?
    - willtim 10y ago
      We use Haskell for "rapid application development" in the front office at Standard Chartered bank. We have excellent typed APIs over most of the banks systems and can assemble applications in hours or days, rather than weeks or months as is typical. The language is as succinct as python, but thanks to types, purity and many standardised abstractions, we get better code reuse and maintenance.
      - pron 10y ago
        Have you written a well-researched case study? If not, please do. It's very hard to assess such statements otherwise. After at least six years of Haskell at SC, is it spreading to larger software in the bank? If so, how fast? If not, why not? Are other banks really spending orders of magnitude more on that kind of software? I've heard that SC adopted Haskell when Lennart Augustsson -- who wrote the first Haskell compiler -- moved to SC from Credit Suisse. When he left CS, they stopped using Haskell. If Haskell gives an order-of-magnitude difference in productivity as you claim, why did CS drop it after Augustsson had left?
        willtim 10y ago
        AFAIK, Credit Suisse only used Haskell for one particular project and that project came to a natural end. CS did end up adopting functional programming and F# became their strategic choice. I never claimed "orders of magnitude" productivity from a language alone. Haskell has every weakly-typed mainstream imperative language as a valid subset. You need good people, teams and processes to get the best out of the language. This means it is difficult to do case studies without getting dismissed as anecdotal. Most other banks have settled on Python for similar use cases. I hear on the grapevine that they have significant maintenance problems (unsurprisingly). Haskell is spreading to larger software in the bank and we are currently hiring.
- psibi 10y ago
  It's hard to measure these types of things. But if you are interested, there is a related paper regarding that: http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel... Although the study in the paper isn't very practical, it's still an interesting experiment.
  - pron 10y ago
    > It's hard to measure these types of things. I'll settle for well-researched case studies. > there is a related paper regarding that That's a step in the right direction, but the paper doesn't discuss software development, but prototyping. We know that "theoretically aesthetic" languages do well in specification and prototyping.
    - Tehnix 10y ago
      >I'll settle for well-researched case studies Don't know if it helps, but they have some case studies here https://www.fpcomplete.com/case-studies https://www.fpcomplete.com/case-studies.
      - pron 10y ago
        That would have helped a lot if those really were case studies. Unfortunately, they're just marketing material for FP Complete (with statements like "In Haskell, Acme Inc. found the perfect solution!"). There's nothing wrong with marketing material, but that's not what I meant by case studies (I meant actual technical reports).
- Tehnix 10y ago
  >Have we actually seen that or have you just asserted that I'd say they have probably seen it. The author of the post himself works at FPComplete, and they use Haskell for their consulting business. That and there are some case studies on their site (I'm fairly sure they all have experience in other languages too).
  - pron 10y ago
    There aren't any case studies. Under the headline "case studies" they only have some marketing material.
- willtim 10y ago
  You appear to be misrepresenting the blog post. His example of an aesthetically motivated language is Python, not Haskell. Haskell's design was not motivated by aesthetics or superficial ease-of-use, which could well be its downfall. Haskell was and still is motivated by enabling software development gains, e.g. abstraction, composition, concurrency. You may disagree that it has achieved these goals, but to that I would say don't knock it until you have tried it.
  - pron 10y ago
    > Haskell was and still is motivated by enabling software development gains The same can be said about nearly every language. Haskell is first and foremost a research language motivated by answering a research questions, which is what it is like to program using a certain mathematical formalism that is aesthetically appealing to some. Its designers didn't set out to find the best abstractions etc., but to test the validity of a specific theoretical approach. > but to that I would say don't knock it until you have tried it. I'm not knocking it. I'm saying that given how expensive it is to try, perhaps some actual information rather than marketing would do a better job in persuading people to use it. Saying that I'm not persuaded by virtually zero information is no knocking anything, except perhaps the advocacy effort.
    - willtim 10y ago
      >> Haskell was and still is motivated by enabling software development gains > The same can be said about nearly every language. This clearly isn't true. For example many languages optimise for ease of use, shallow learning curve, programming in the small etc. Some optimise for efficiency and runtime determinism. Features like type-systems are great for software development (programming in the large), but do negatively impact ease-of-use. > Haskell is first and foremost a research language motivated by answering a research questions This isn't true. The Haskell committee contains many people from industry. Haskell just happens to have come from academia and is still heavily used in academia. > Saying that I'm not persuaded by virtually zero information is no knocking anything That's a huge exaggeration to suggest there is zero information. There are many experience reports published all the time at conferences and in academic journals, going back decades. None however will give you the quantitative metrics you seem to be asking for, because it is almost impossible to do such a comparison.
kinkdr 10y ago
Although very fresh into the Haskell world myself, I tend to agree with the author that, when I know what I am doing, my Haskell code is usually written in less time and has less bugs. Having said that, Time-to-Market is only partially influenced by my-code, the biggest part is the code that I don't have to write, i.e. third-party libraries. In my Haskell adventures I am having trouble finding third-party libraries for even the most popular things, e.g. Cassandra. As far as I can tell there are two libraries, the `cassandra-cql` and the `cql-io`, the first hasn't been updated for a year now, and the second has only 3 stars, which makes me uneasy. So, although I can see where the author is coming from, I don't think you can beat Java, Ruby, JS or Python in that sense. Unless of course your code/project doesn't have a lot of dependencies.
- SatvikBeri 10y ago
  I've found Scala to be a really good compromise–it has most of the functional features of Haskell, a wide array of existing libraries, and access to Java libraries when you need them. Plus implicits/typeclasses make it easy to extend otherwise annoying Java libraries to make them easier to use.
- eklavya 10y ago
  Mine has a single star but you may find it useful. https://github.com/eklavya/hascas https://github.com/eklavya/hascas
  - kinkdr 10y ago
    Thanks. I love that you have a fair-sized concrete example for usage. I am giving it a try now.
- marcosdumay 10y ago
  Yes, when working in Haskell, expect to do some yak shaving. It's some incredibly productive yak shaving, it's even fun, but it's still yak shaving. But I'll point that Haskell has also many wonderful libraries, for stuff you won't see in other communities. The libraries that are available are of an unmatched quality. Odds are a library marked as experimental on Hackage is more reliable than a mature one on the Python Index.
mirekrusin 10y ago
Why comparisons to C#/Java are mentioned so many times but not a single mention of F#? Maybe with F# author would see decrease of development time compared to Haskell?
- vog 10y ago
  Or OCaml, which is kind-of the original language F# was copied from.
kriro 10y ago
The article assumes an existing team which is a bit problematic when talking about time to market. If you start the analysis earlier (two people discussing some ideas in a coffee shop) then I'd argue that a language like Haskell can be problematic if your metric is time to market. You might very well make that up later by having a more robust code base or reaping any of the other asserted benefits but the existing gallery of premade and tested building blocks in other languages seems to be richer. It's probably also going to be harder to add people to your team (on average). I would have liked to see a comparison to other functional languages (say Elixir or OCaml) and not just Java and C#. I'd also argue that picking Java instead of a more agile environment (there are some cool lightweight Java frameworks but most people will associate it with the rather heavy enterprise stack) when comparing regarding time to market is a bit odd. Granted I'm mostly thinking about webapps (but the article mentions Yesode). Still a nice article (since my post sounds overly negative upon rereading).
- lmm 10y ago
  > The article assumes an existing team which is a bit problematic when talking about time to market. If you start the analysis earlier (two people discussing some ideas in a coffee shop) then I'd argue that a language like Haskell can be problematic if your metric is time to market. Well, the best language for an early-stage business is the one the founder knows, but that's always going to be true. There's no reason that language can't be Haskell.
tmptmp 10y ago
Warning: be warned before you commit to Haskell. Not all is rosy about Haskell. You may find yourself in quagmire if you don't know for sure what you are going to get from Haskell, especially from the libraries. Although this is true for other languages also, the library support for Haskell is yet far from satisfactory as compared to the library support found for Python/Java. The Haskell community seems to have been divided over it. Not so ago there was some discussion about "batteries" included with Haskell. [1] It compared situation of Haskell with that of Python/Java etc, worth reading if you are about to go the Haskell route. It seems, the priorities (academic, commercial, library support and so on) of the members of Haskell community are at crossroads and they cannot seem to resolve those very good, IMHO. My take: Haskell is good for learning some really deep concepts, but may be not so good when it comes to commercial projects, unless you are a Haskell veteran and also have an army of Haskell veterans with you. [1] http://osdir.com/ml/haskell-cafe@haskell.org/2016-10/msg00014.html http://osdir.com/ml/haskell-cafe@haskell.org/2016-10/msg0001...
- brynedwards 10y ago
  There's also a document maintained on GitHub that gives a rating of Haskell's support for different domains: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md https://github.com/Gabriel439/post-rfc/blob/master/sotu.md Which backs up your statements; many of the sections under "Common Programming Needs" are rated immature: Databases, Debugging, IDEs...
- pyrale 10y ago
  It sounds quite unsurprising that Haskell (or for that matter, any language that isn't java/python/c) doesn't have an ecosystem comparable to one of the most successful industrial languages around. I'm not saying everything is great with Haskell, but so far, I haven't run into major holes for what I'm doing, library-wise.
- cageface 10y ago
  You would think that a really rigorous language like Haskell would foster a better ecosystem of libraries than ad hoc languages like Python or JS but that has not been the case at all so far. I'm not sure exactly why but it's one of the main reasons I'm taking a wait and see attitude to Haskell.
almata 10y ago
If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?
- LeonidasXIV 10y ago
  It depends what you are looking for. If you are looking for work then Scala beats the other two hands down. Then comes F# and Haskell somewhere in the end. If you're looking for enlightenment, pick up Haskell, maybe OCaml and skip F#.
  - pjmlp 10y ago
    Well, F# beats both OCaml and Haskell in industrial support and tooling, specially if we take .NET libraries into account.
- hellofunk 10y ago
  As far functional languages go, Erlang, Elixir and Scala would get you further career-wise, and if you want to play in the sorta-functional world, Swift is also a high-in-demand language that borrows a lot from Rust and Haskell. However, Haskell and OCaml are the more classic functional, static-typed languages, and while Haskell has more job opportunities than OCaml, it is probably the steepest learning curve and highest time commitment of all these languages.
- pjmlp 10y ago
  F# and Scala, given that we use both JVM and .NET stacks.
- cageface 10y ago
  I've always liked OCaml and with Facebook putting some real momentum behind it and the OCaml/JS story getting better and better all the time I'd say now is a good time to pick it up. It's more pragmatic than Haskell, simpler than Scala, and not tied to the .Net ecosystem like F#.
- RBerenguel 10y ago
stanislavb 10y ago
And I believe that based on the enlisted properties/features, Elixir may qualify pretty well, too. What is more, Elixir may be a better choice in regards of time-to-market + developer happiness.
- hellofunk 10y ago
  Yes, but that's a dynamically typed language and everything changes when comparing it. There are so many tradeoffs. Clojure is quite quick to write and time to market can be very fast, as with most lisps, but you pay the price at debug time. We recently shipped a production app that had a small typo that the compiler would have easily caught, but instead it crashed the site when this one particular task was run.
  - kazinator 10y ago
    Your experience with Clojure might not in fact generalize to "most lisps", which have very good compilers that catch all kinds of errors. Certainly the "low hanging fruit" ones like references to unbound variables or functions and such. What was the typo? > it crashed the site when this one particular task was run. Might that also be because that was the first time the task was run at all, since the code was written or altered? Code that compiles (such that we are confident it is probably free of silly typos, other than those somewhat rare typos which play out in some way that still compiles), might not be correct; it still requires testing.
    - hellofunk 10y ago
      The typo had to do with accidentally naming a variable in a let binding to the same name as a built-in function. It happily compiled but when that code actually ran in one particular use-case, it crashed due to the way the binding and the scoping worked in that case.
      - kazinator 10y ago
        > accidentally naming a variable in a let binding to the same name as a built-in function. Not even a problem in a Lisp-2 like ANSI CL! (let ((list '(1 2))) (list list list)) -> ((1 2) (1 2)) Facepalm. We could argue you were burned by the stupid Lisp-1 namespacing. Under the separate function and variable namespace of a Lisp-2, you would have to bind a local function in order to shadow a global one. Even without a compiler, we can implement a warning for this. The code walker which expands macros is aware of lexical environments and can issue diagnostics when suspicious-looking shadowing is going on, or unbound variables are referenced and such. Not only is this not the fault of the language being dynamic, but the problem could exist in a static language, like, oh, C: #define DECLARE_MY_PRINTF int (*printf)(const char *, ...) = my_printf; { DECLARE_MY_PRINTF: printf("hello, %s\n", "world"); // goes to my_printf via shadowing local var } ISO C does not require a diagnostic for this. Gcc has -Wshadow. ISTR -Wshadow is not turned on by -Wall or -Wextra; you have to use it explicitly. Of course, the above depends on the local printf pointer actually having the right type so that the call is well-formed. If we just have "int printf" or whatever, the type system will catch it.
millstone 10y ago
IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc. But once the core abstractions are settled, you start to reap its power. The type system catches tons of potential errors. Combinators allow for enormous expressiveness. Here you're rolling: Haskell is in its zone! But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art. You find yourself longing for a language with simple semantics and mechanical sympathy. Now Haskell is bumping up against the real world. Haskell has its sweet spot somewhere between "bang this out by 5pm" and "ship this to a million users". (No surprise it's popular in academia.)
- Tehnix 10y ago
  >But once the core abstractions are settled, you start to reap its power This is so true. Once you get the types settled for your project, then it becomes a breeze to quickly add things and refactor over and over again, because maybe the spec or idea changed. I've recently experienced this in both a Haskell project (using the Yesod framework) and I'm currently working on an Elm project, where I very much feel this strength also. I'll have to agree with you on the debugging though - it is somewhat of an art, and not one I've completely mastered yet, since I haven't had that much need for it for now (haven't done that many production haskell projects).
- vog 10y ago
  > But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art To be fair, these issue are more-or-less solved by newer functional languages, such as OCaml or Rust.
  - amelius 10y ago
    You mean non-purely functional languages.
    - 10y ago
douche 10y ago
Every couple of months, I think to myself that I ought to buckle down and make an effort at really learning Haskell. And I go through some books and some toy projects, and then I hit the wall. The problem is, I can't actually use Haskell in anything production, because nobody else that I work with is going to be able to figure out how it works, and if I move on to some other job, my employer is never going to find somebody with Haskell experience in this area - at least for what they'd be willing to pay. F# looks like a more pragmatic choice, and I've been looking hard for a good place to bite off to use it going forward. But again, it'll be bad for the bus factor. So the best option I've found is to just start using more functional concepts and patterns in Java/C#. C# in particular seems to be leaning in this direction with the features added in the latest language versions.
greydius 10y ago
> Haskell developers are self-selecting This is not going to change. I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.
- kreetx 10y ago
  That's my experience as well. As a Haskell user I once felt that I had a secret, that it's so much better than the rest. Now, years later, it seems many pretty much can't tell a difference between a good and a bad language. Or rather, that many pick a language by the language's spread rather than its properties.
- julian_1 10y ago
  Haskell would be a lot easier to manage in production environments if resource-usage was more predicable - meaning strict by default.
dorfsmay 10y ago
I think this thread which I started this last weekend about Haskell productivity vs Rust might be relevant here: https://m.reddit.com/r/rust/comments/5dtfp2/haskell_more_productive_than_rust/ https://m.reddit.com/r/rust/comments/5dtfp2/haskell_more_pro... (Tried to ask on HN first, which once again proves the value of subreddits, as small focused communities: https://news.ycombinator.com/item?id=12989041 https://news.ycombinator.com/item?id=12989041)
kreetx 10y ago
The take-away for Haskell tends to be if there is some kind of a commitment at some "core" level to it (i.e the the long-term members of the tech team, CTO, etc.). If there is none and people move in-and-out of the company, then it's more practical to use a more mainstream language, which is easier and less far-out to learn.

142 points by Tehnix 10y ago

pron 10y ago

> In summary we've seen that: Haskell decreases development time... Have we actually seen that or have you just asserted that? Is this really true, and if it is, by how much? Haskell has been around for a couple of decades now, and has had least two hype cycles (I remember that when I was in university in the late '90s, Haskell was the next big thing). It does not seem to expand significantly even within organizations that have tried it (and that's a very negative signal), with at least one notable case where the language has been abandoned by a company that was among the flagship adopters. In general, we know that often linguistic abstractions that seem like a good idea in theory -- or even seem to work nicely in small programs -- don't end up having a significant effect on the bottom line when larger software is concerned. People say that scientific evidence of actual contribution is hard to collect, but we don't even have well-researched anecdotes. Not only do we not have strong evidence in favor of this hypothesis, but there aren't even promising hints. All we do have is people who really like Haskell based on its aesthetics and really wish that the the nice theoretical arguments translated to significant bottom-line gains. This blog post by Dan Ghica, a PL researcher, really addresses this point: there is nothing to suggest that aesthetically nice theory translates to actual software development gains, and wishful thinking (or personal affinity) simply cannot replace gathering of data: http://danghica.blogspot.com/2016/09/what-else-are-we-getting-wrong.html http://danghica.blogspot.com/2016/09/what-else-are-we-gettin...

radicality 10y ago
Not the author and I don't know much besides a little dabbling in Haskell, but I'm sure that quote holds true, but only if the engineer already is an intermediate-advanced Haskeller, which probably translates to at least a couple years of daily Haskell work.
- pron 10y ago
  > but I'm sure that quote holds true How can you be sure? Have you seen Haskell shops churn out software significantly faster than others?
  - willtim 10y ago
    We use Haskell for "rapid application development" in the front office at Standard Chartered bank. We have excellent typed APIs over most of the banks systems and can assemble applications in hours or days, rather than weeks or months as is typical. The language is as succinct as python, but thanks to types, purity and many standardised abstractions, we get better code reuse and maintenance.
    - pron 10y ago
      Have you written a well-researched case study? If not, please do. It's very hard to assess such statements otherwise. After at least six years of Haskell at SC, is it spreading to larger software in the bank? If so, how fast? If not, why not? Are other banks really spending orders of magnitude more on that kind of software? I've heard that SC adopted Haskell when Lennart Augustsson -- who wrote the first Haskell compiler -- moved to SC from Credit Suisse. When he left CS, they stopped using Haskell. If Haskell gives an order-of-magnitude difference in productivity as you claim, why did CS drop it after Augustsson had left?
      - willtim 10y ago
        AFAIK, Credit Suisse only used Haskell for one particular project and that project came to a natural end. CS did end up adopting functional programming and F# became their strategic choice. I never claimed "orders of magnitude" productivity from a language alone. Haskell has every weakly-typed mainstream imperative language as a valid subset. You need good people, teams and processes to get the best out of the language. This means it is difficult to do case studies without getting dismissed as anecdotal. Most other banks have settled on Python for similar use cases. I hear on the grapevine that they have significant maintenance problems (unsurprisingly). Haskell is spreading to larger software in the bank and we are currently hiring.
psibi 10y ago
It's hard to measure these types of things. But if you are interested, there is a related paper regarding that: http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel... Although the study in the paper isn't very practical, it's still an interesting experiment.
- pron 10y ago
  > It's hard to measure these types of things. I'll settle for well-researched case studies. > there is a related paper regarding that That's a step in the right direction, but the paper doesn't discuss software development, but prototyping. We know that "theoretically aesthetic" languages do well in specification and prototyping.
  - Tehnix 10y ago
    >I'll settle for well-researched case studies Don't know if it helps, but they have some case studies here https://www.fpcomplete.com/case-studies https://www.fpcomplete.com/case-studies.
    - pron 10y ago
      That would have helped a lot if those really were case studies. Unfortunately, they're just marketing material for FP Complete (with statements like "In Haskell, Acme Inc. found the perfect solution!"). There's nothing wrong with marketing material, but that's not what I meant by case studies (I meant actual technical reports).
Tehnix 10y ago
>Have we actually seen that or have you just asserted that I'd say they have probably seen it. The author of the post himself works at FPComplete, and they use Haskell for their consulting business. That and there are some case studies on their site (I'm fairly sure they all have experience in other languages too).
- pron 10y ago
  There aren't any case studies. Under the headline "case studies" they only have some marketing material.
willtim 10y ago
You appear to be misrepresenting the blog post. His example of an aesthetically motivated language is Python, not Haskell. Haskell's design was not motivated by aesthetics or superficial ease-of-use, which could well be its downfall. Haskell was and still is motivated by enabling software development gains, e.g. abstraction, composition, concurrency. You may disagree that it has achieved these goals, but to that I would say don't knock it until you have tried it.
- pron 10y ago
  > Haskell was and still is motivated by enabling software development gains The same can be said about nearly every language. Haskell is first and foremost a research language motivated by answering a research questions, which is what it is like to program using a certain mathematical formalism that is aesthetically appealing to some. Its designers didn't set out to find the best abstractions etc., but to test the validity of a specific theoretical approach. > but to that I would say don't knock it until you have tried it. I'm not knocking it. I'm saying that given how expensive it is to try, perhaps some actual information rather than marketing would do a better job in persuading people to use it. Saying that I'm not persuaded by virtually zero information is no knocking anything, except perhaps the advocacy effort.
  - willtim 10y ago
    >> Haskell was and still is motivated by enabling software development gains > The same can be said about nearly every language. This clearly isn't true. For example many languages optimise for ease of use, shallow learning curve, programming in the small etc. Some optimise for efficiency and runtime determinism. Features like type-systems are great for software development (programming in the large), but do negatively impact ease-of-use. > Haskell is first and foremost a research language motivated by answering a research questions This isn't true. The Haskell committee contains many people from industry. Haskell just happens to have come from academia and is still heavily used in academia. > Saying that I'm not persuaded by virtually zero information is no knocking anything That's a huge exaggeration to suggest there is zero information. There are many experience reports published all the time at conferences and in academic journals, going back decades. None however will give you the quantitative metrics you seem to be asking for, because it is almost impossible to do such a comparison.

kinkdr 10y ago

Although very fresh into the Haskell world myself, I tend to agree with the author that, when I know what I am doing, my Haskell code is usually written in less time and has less bugs. Having said that, Time-to-Market is only partially influenced by my-code, the biggest part is the code that I don't have to write, i.e. third-party libraries. In my Haskell adventures I am having trouble finding third-party libraries for even the most popular things, e.g. Cassandra. As far as I can tell there are two libraries, the `cassandra-cql` and the `cql-io`, the first hasn't been updated for a year now, and the second has only 3 stars, which makes me uneasy. So, although I can see where the author is coming from, I don't think you can beat Java, Ruby, JS or Python in that sense. Unless of course your code/project doesn't have a lot of dependencies.

SatvikBeri 10y ago
I've found Scala to be a really good compromise–it has most of the functional features of Haskell, a wide array of existing libraries, and access to Java libraries when you need them. Plus implicits/typeclasses make it easy to extend otherwise annoying Java libraries to make them easier to use.
eklavya 10y ago
Mine has a single star but you may find it useful. https://github.com/eklavya/hascas https://github.com/eklavya/hascas
- kinkdr 10y ago
  Thanks. I love that you have a fair-sized concrete example for usage. I am giving it a try now.
marcosdumay 10y ago
Yes, when working in Haskell, expect to do some yak shaving. It's some incredibly productive yak shaving, it's even fun, but it's still yak shaving. But I'll point that Haskell has also many wonderful libraries, for stuff you won't see in other communities. The libraries that are available are of an unmatched quality. Odds are a library marked as experimental on Hackage is more reliable than a mature one on the Python Index.

mirekrusin 10y ago

Why comparisons to C#/Java are mentioned so many times but not a single mention of F#? Maybe with F# author would see decrease of development time compared to Haskell?

vog 10y ago
Or OCaml, which is kind-of the original language F# was copied from.

kriro 10y ago

The article assumes an existing team which is a bit problematic when talking about time to market. If you start the analysis earlier (two people discussing some ideas in a coffee shop) then I'd argue that a language like Haskell can be problematic if your metric is time to market. You might very well make that up later by having a more robust code base or reaping any of the other asserted benefits but the existing gallery of premade and tested building blocks in other languages seems to be richer. It's probably also going to be harder to add people to your team (on average). I would have liked to see a comparison to other functional languages (say Elixir or OCaml) and not just Java and C#. I'd also argue that picking Java instead of a more agile environment (there are some cool lightweight Java frameworks but most people will associate it with the rather heavy enterprise stack) when comparing regarding time to market is a bit odd. Granted I'm mostly thinking about webapps (but the article mentions Yesode). Still a nice article (since my post sounds overly negative upon rereading).

lmm 10y ago
> The article assumes an existing team which is a bit problematic when talking about time to market. If you start the analysis earlier (two people discussing some ideas in a coffee shop) then I'd argue that a language like Haskell can be problematic if your metric is time to market. Well, the best language for an early-stage business is the one the founder knows, but that's always going to be true. There's no reason that language can't be Haskell.

tmptmp 10y ago

Warning: be warned before you commit to Haskell. Not all is rosy about Haskell. You may find yourself in quagmire if you don't know for sure what you are going to get from Haskell, especially from the libraries. Although this is true for other languages also, the library support for Haskell is yet far from satisfactory as compared to the library support found for Python/Java. The Haskell community seems to have been divided over it. Not so ago there was some discussion about "batteries" included with Haskell. [1] It compared situation of Haskell with that of Python/Java etc, worth reading if you are about to go the Haskell route. It seems, the priorities (academic, commercial, library support and so on) of the members of Haskell community are at crossroads and they cannot seem to resolve those very good, IMHO. My take: Haskell is good for learning some really deep concepts, but may be not so good when it comes to commercial projects, unless you are a Haskell veteran and also have an army of Haskell veterans with you. [1] http://osdir.com/ml/haskell-cafe@haskell.org/2016-10/msg00014.html http://osdir.com/ml/haskell-cafe@haskell.org/2016-10/msg0001...

brynedwards 10y ago
There's also a document maintained on GitHub that gives a rating of Haskell's support for different domains: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md https://github.com/Gabriel439/post-rfc/blob/master/sotu.md Which backs up your statements; many of the sections under "Common Programming Needs" are rated immature: Databases, Debugging, IDEs...
pyrale 10y ago
It sounds quite unsurprising that Haskell (or for that matter, any language that isn't java/python/c) doesn't have an ecosystem comparable to one of the most successful industrial languages around. I'm not saying everything is great with Haskell, but so far, I haven't run into major holes for what I'm doing, library-wise.
cageface 10y ago
You would think that a really rigorous language like Haskell would foster a better ecosystem of libraries than ad hoc languages like Python or JS but that has not been the case at all so far. I'm not sure exactly why but it's one of the main reasons I'm taking a wait and see attitude to Haskell.

almata 10y ago

If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?

LeonidasXIV 10y ago
It depends what you are looking for. If you are looking for work then Scala beats the other two hands down. Then comes F# and Haskell somewhere in the end. If you're looking for enlightenment, pick up Haskell, maybe OCaml and skip F#.
- pjmlp 10y ago
  Well, F# beats both OCaml and Haskell in industrial support and tooling, specially if we take .NET libraries into account.
hellofunk 10y ago
As far functional languages go, Erlang, Elixir and Scala would get you further career-wise, and if you want to play in the sorta-functional world, Swift is also a high-in-demand language that borrows a lot from Rust and Haskell. However, Haskell and OCaml are the more classic functional, static-typed languages, and while Haskell has more job opportunities than OCaml, it is probably the steepest learning curve and highest time commitment of all these languages.
pjmlp 10y ago
F# and Scala, given that we use both JVM and .NET stacks.
cageface 10y ago
I've always liked OCaml and with Facebook putting some real momentum behind it and the OCaml/JS story getting better and better all the time I'd say now is a good time to pick it up. It's more pragmatic than Haskell, simpler than Scala, and not tied to the .Net ecosystem like F#.
RBerenguel 10y ago

stanislavb 10y ago

And I believe that based on the enlisted properties/features, Elixir may qualify pretty well, too. What is more, Elixir may be a better choice in regards of time-to-market + developer happiness.

hellofunk 10y ago
Yes, but that's a dynamically typed language and everything changes when comparing it. There are so many tradeoffs. Clojure is quite quick to write and time to market can be very fast, as with most lisps, but you pay the price at debug time. We recently shipped a production app that had a small typo that the compiler would have easily caught, but instead it crashed the site when this one particular task was run.
- kazinator 10y ago
  Your experience with Clojure might not in fact generalize to "most lisps", which have very good compilers that catch all kinds of errors. Certainly the "low hanging fruit" ones like references to unbound variables or functions and such. What was the typo? > it crashed the site when this one particular task was run. Might that also be because that was the first time the task was run at all, since the code was written or altered? Code that compiles (such that we are confident it is probably free of silly typos, other than those somewhat rare typos which play out in some way that still compiles), might not be correct; it still requires testing.
  - hellofunk 10y ago
    The typo had to do with accidentally naming a variable in a let binding to the same name as a built-in function. It happily compiled but when that code actually ran in one particular use-case, it crashed due to the way the binding and the scoping worked in that case.
    - kazinator 10y ago
      > accidentally naming a variable in a let binding to the same name as a built-in function. Not even a problem in a Lisp-2 like ANSI CL! (let ((list '(1 2))) (list list list)) -> ((1 2) (1 2)) Facepalm. We could argue you were burned by the stupid Lisp-1 namespacing. Under the separate function and variable namespace of a Lisp-2, you would have to bind a local function in order to shadow a global one. Even without a compiler, we can implement a warning for this. The code walker which expands macros is aware of lexical environments and can issue diagnostics when suspicious-looking shadowing is going on, or unbound variables are referenced and such. Not only is this not the fault of the language being dynamic, but the problem could exist in a static language, like, oh, C: #define DECLARE_MY_PRINTF int (*printf)(const char *, ...) = my_printf; { DECLARE_MY_PRINTF: printf("hello, %s\n", "world"); // goes to my_printf via shadowing local var } ISO C does not require a diagnostic for this. Gcc has -Wshadow. ISTR -Wshadow is not turned on by -Wall or -Wextra; you have to use it explicitly. Of course, the above depends on the local printf pointer actually having the right type so that the call is well-formed. If we just have "int printf" or whatever, the type system will catch it.

millstone 10y ago

IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc. But once the core abstractions are settled, you start to reap its power. The type system catches tons of potential errors. Combinators allow for enormous expressiveness. Here you're rolling: Haskell is in its zone! But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art. You find yourself longing for a language with simple semantics and mechanical sympathy. Now Haskell is bumping up against the real world. Haskell has its sweet spot somewhere between "bang this out by 5pm" and "ship this to a million users". (No surprise it's popular in academia.)

Tehnix 10y ago
>But once the core abstractions are settled, you start to reap its power This is so true. Once you get the types settled for your project, then it becomes a breeze to quickly add things and refactor over and over again, because maybe the spec or idea changed. I've recently experienced this in both a Haskell project (using the Yesod framework) and I'm currently working on an Elm project, where I very much feel this strength also. I'll have to agree with you on the debugging though - it is somewhat of an art, and not one I've completely mastered yet, since I haven't had that much need for it for now (haven't done that many production haskell projects).
vog 10y ago
> But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art To be fair, these issue are more-or-less solved by newer functional languages, such as OCaml or Rust.
- amelius 10y ago
  You mean non-purely functional languages.
  - 10y ago

douche 10y ago

Every couple of months, I think to myself that I ought to buckle down and make an effort at really learning Haskell. And I go through some books and some toy projects, and then I hit the wall. The problem is, I can't actually use Haskell in anything production, because nobody else that I work with is going to be able to figure out how it works, and if I move on to some other job, my employer is never going to find somebody with Haskell experience in this area - at least for what they'd be willing to pay. F# looks like a more pragmatic choice, and I've been looking hard for a good place to bite off to use it going forward. But again, it'll be bad for the bus factor. So the best option I've found is to just start using more functional concepts and patterns in Java/C#. C# in particular seems to be leaning in this direction with the features added in the latest language versions.

greydius 10y ago

> Haskell developers are self-selecting This is not going to change. I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.

kreetx 10y ago
That's my experience as well. As a Haskell user I once felt that I had a secret, that it's so much better than the rest. Now, years later, it seems many pretty much can't tell a difference between a good and a bad language. Or rather, that many pick a language by the language's spread rather than its properties.
julian_1 10y ago
Haskell would be a lot easier to manage in production environments if resource-usage was more predicable - meaning strict by default.

dorfsmay 10y ago

I think this thread which I started this last weekend about Haskell productivity vs Rust might be relevant here: https://m.reddit.com/r/rust/comments/5dtfp2/haskell_more_productive_than_rust/ https://m.reddit.com/r/rust/comments/5dtfp2/haskell_more_pro... (Tried to ask on HN first, which once again proves the value of subreddits, as small focused communities: https://news.ycombinator.com/item?id=12989041 https://news.ycombinator.com/item?id=12989041)

kreetx 10y ago

The take-away for Haskell tends to be if there is some kind of a commitment at some "core" level to it (i.e the the long-term members of the tech team, CTO, etc.). If there is none and people move in-and-out of the company, then it's more practical to use a more mainstream language, which is easier and less far-out to learn.