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

The Joy and Agony of Haskell in Production

stephendiehl.com

Post reply on HN
Print view View original

11–20 of 94 posts

Re: The Joy and Agony of Haskell in Production

#11

Post by bojo »

sksk wrote: post #7

I am not a professional developer (never gotten paid to write software) but now do some prototyping code in Haskell so real engineers can pick it up from me later. For me, Haskell has been a huge productivity booster. It forces me to write good code and 90% of mistakes that I normally make are all caught at compile time. I use servant for creating my API server and it is pleasure to use (being able to create APIs dec…

Fantastic response.

In regards to changing data records I've suffered the same problem as well. At best I've isolated what I can into separate modules so the impact is smaller after a small change, but obviously isn't universally applicable.

Note that there is also a #haskell-beginners IRC channel where it's sometimes easier to get a responses to certain questions than the much broader #haskell channel. Both channels are full of incredibly nice people for sure.

I too did not know about fieldLabelModifier and am excited about the GHC 8 changes as well!

Re: The Joy and Agony of Haskell in Production

#12

Post by fsloth »

colehasson wrote: post #9

I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.

"when people are ready to engineer code that lasts 1000 years"

Actually, as silly as it sounds, I write most my hobby code in C++ because of this. Well, not for a thousand year span but for longevity anyway.

Re: The Joy and Agony of Haskell in Production

#13

Post by incepted »

colehasson wrote: post #9

I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.

If the language you want to work in is so important, you should have picked the company first and the location second.

Besides, data outlives code. By orders of magnitude. You seem to be in love with Haskell today, chances are you'll be using a different language in ten years but the data you'll be working with will probably have been around for much longer than that.

Don't fall in love with programming languages, it's a waste of emotional energy.

Re: The Joy and Agony of Haskell in Production

#14

Post by sklogic »

fsloth wrote: post #12
colehasson wrote: post #9

I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.

"when people are ready to engineer code that lasts 1000 years" Actually, as silly as it sounds, I write most my hobby code in C++ because of this. Well, not for a thousand year span but for longevity anyway.

C++ if far too volatile. Stick to Common Lisp instead, it is a living fossil.

Re: The Joy and Agony of Haskell in Production

#15

Post by timwaagh »

colehasson wrote: post #9

I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.

come work for me. you'll have to work remotely cause a mountain view office is still in the planning. i will gladly compensate you for your efforts at a rate of 5 cheetos an hour.

Re: The Joy and Agony of Haskell in Production

#16

Post by danidiaz »

sksk wrote: post #7

I am not a professional developer (never gotten paid to write software) but now do some prototyping code in Haskell so real engineers can pick it up from me later. For me, Haskell has been a huge productivity booster. It forces me to write good code and 90% of mistakes that I normally make are all caught at compile time. I use servant for creating my API server and it is pleasure to use (being able to create APIs dec…

A workaround for long compile times is trying to stay withing GHCi whenever possible and reload from there.

http://chrisdone.com/posts/haskell-repl

http://chrisdone.com/posts/making-ghci-fast

The Haxl team seem to use this strategy:

"Haxl users at Facebook do a lot of development and testing inside GHCi. In fact, we’ve built a customized version of GHCi that runs code in our Haxl monad by default instead of the IO monad, and has a handful of extra commands to support common workflows needed by our developers."

http://simonmar.github.io/posts/2016-02-12-Stack-traces-in-G...

Re: The Joy and Agony of Haskell in Production

#18

Post by koloron »

danidiaz wrote: post #16
sksk wrote: post #7

I am not a professional developer (never gotten paid to write software) but now do some prototyping code in Haskell so real engineers can pick it up from me later. For me, Haskell has been a huge productivity booster. It forces me to write good code and 90% of mistakes that I normally make are all caught at compile time. I use servant for creating my API server and it is pleasure to use (being able to create APIs dec…

A workaround for long compile times is trying to stay withing GHCi whenever possible and reload from there. http://chrisdone.com/posts/haskell-repl http://chrisdone.com/posts/making-ghci-fast The Haxl team seem to use this strategy: "Haxl users at Facebook do a lot of development and testing inside GHCi. In fact, we’ve built a customized version of GHCi that runs code in our Haxl monad by default instead of the IO mo…

I find ghcid very useful. It reloads your code automatically when it detects a filechange.

https://github.com/ndmitchell/ghcid http://neilmitchell.blogspot.de/2014/09/ghcid-new-ghci-based...

Re: The Joy and Agony of Haskell in Production

#19

Post by rwmj »

Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too.

In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and the answer has so far always been no.

[1] https://github.com/libguestfs/libguestfs/tree/master/v2v

[2] https://realworldocaml.org/v1/en/html/functors.html

Re: The Joy and Agony of Haskell in Production

#20

Post by wereHamster »

I don't agree that TH is bad. It's bad for generating real code (like I wouldn't use it to generate complicated logic), but just like you don't write Eq,Show,Ord instances yourself and instead let the compiler derive them for you, you use TH to generate JSON instances. I see TH more as a extension of deriving so I can easily derive custom typeclasses than for generating real code.
Post reply on HN