Mastering Time-to-Market with Haskell • Hacker News Board

Re: Mastering Time-to-Market with Haskell

#21

Post by Tehnix » Tue, Nov 22, 2016, 8:56 AM UTC

millstone wrote: post #15

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

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

Re: Mastering Time-to-Market with Haskell

#22

Post by vog » Tue, Nov 22, 2016, 8:59 AM UTC

millstone wrote: post #15

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

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

Re: Mastering Time-to-Market with Haskell

#23

Post by [deleted] » Tue, Nov 22, 2016, 9:15 AM UTC

millstone wrote: post #15

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

[deleted]

Re: Mastering Time-to-Market with Haskell

#24

Post by vog » Tue, Nov 22, 2016, 9:17 AM UTC

mirekrusin wrote: post #7

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?

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

Re: Mastering Time-to-Market with Haskell

#25

Post by sheepmullet » Tue, Nov 22, 2016, 9:22 AM UTC

willtim wrote: post #18

pron wrote: post #16

Earlier quoted context omitted.

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

> and can assemble applications in hours or days, rather than weeks or months as is typical.

So you are building in hours and days applications that other banks are spending weeks and months on.

I'd love to see a few case studies!!

Re: Mastering Time-to-Market with Haskell

#26

Post by pron » Tue, Nov 22, 2016, 9:35 AM UTC

Tehnix wrote: post #20

pron wrote: post #10

Earlier quoted context omitted.

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

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

Re: Mastering Time-to-Market with Haskell

#27

Post by brynedwards » Tue, Nov 22, 2016, 9:36 AM UTC

tmptmp wrote: post #12

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…

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

Which backs up your statements; many of the sections under "Common Programming Needs" are rated immature: Databases, Debugging, IDEs...

Re: Mastering Time-to-Market with Haskell

#28

Post by willtim » Tue, Nov 22, 2016, 9:40 AM UTC

sheepmullet wrote: post #25

willtim wrote: post #18

Earlier quoted context omitted.

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

> and can assemble applications in hours or days, rather than weeks or months as is typical. So you are building in hours and days applications that other banks are spending weeks and months on. I'd love to see a few case studies!!

It does takes significant investment to get to this point though. SCB have been building APIs and components in Haskell for 8 years. We can now glue these parts together very easily and can be confident it will work, thanks to strong types. With less disciplined languages and/or teams, 8 years of development can yield a codebase that most will want to throw away and start again.

Re: Mastering Time-to-Market with Haskell

#29

Post by pyrale » Tue, Nov 22, 2016, 9:46 AM UTC

tmptmp wrote: post #12

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…

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.

Re: Mastering Time-to-Market with Haskell

#30

Post by amelius » Tue, Nov 22, 2016, 9:48 AM UTC

vog wrote: post #22

millstone wrote: post #15

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

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

You mean non-purely functional languages.