Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Time-to-Market with Haskell

fpcomplete.com

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Mastering Time-to-Market with Haskell

#11

Post by kriro »

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).

Re: Mastering Time-to-Market with Haskell

#12

Post by tmptmp »

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/msg0001...

Re: Mastering Time-to-Market with Haskell

#15

Post by millstone »

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.)

Re: Mastering Time-to-Market with Haskell

#16

Post by pron »

willtim wrote: post #8
pron wrote: post #4

Earlier quoted context omitted.

> 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?

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.

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?

Re: Mastering Time-to-Market with Haskell

#17

Post by LeonidasXIV »

almata wrote: post #13

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#?

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#.

Re: Mastering Time-to-Market with Haskell

#18

Post by willtim »

pron wrote: post #16
willtim wrote: post #8

Earlier quoted context omitted.

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.

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 comp…

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.

Re: Mastering Time-to-Market with Haskell

#19

Post by Tehnix »

pron wrote: post #2

> 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 organization…

>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).

Re: Mastering Time-to-Market with Haskell

#20

Post by Tehnix »

pron wrote: post #10
psibi wrote: post #6

Earlier quoted context omitted.

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/Haskel... Although the study in the paper isn't very practical, it's still an interesting experiment.

> 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.

>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.

Post reply on HN