The Joy and Agony of Haskell in Production • Hacker News Board

Re: The Joy and Agony of Haskell in Production

#41

Post by ergl » Sat, Feb 20, 2016, 2:32 PM UTC

Chattered wrote: post #37

ergl wrote: post #31

Earlier quoted context omitted.

Hmm, I found functors a bit confusing on my first encounter with the language, but I wouldn't call them 'academic'. If you've ever used Haskell typeclasses, they serve almost the same purpose. In OO land, they're just a way to ensure that an argument satisfies an interface, exposing certain public functions and properties — just like an object in Java has to implement the Comparable interface in order to be sorted in…

Functors are modules that depend on another module. This works like a function whose argument is a module with type given by a signature. There isn't anything exactly analogous in Java. Functor application can introduce new type definitions at compile time and enforce static type safety. You need this so that you can statically require that you can only take unions of sorted collections whose types came from the same…

Yes, I know my example isn't perfect, but I've found is a good way of explaining the general concept to people not familiar with ML's module system. Thanks for your explanation though!

Re: The Joy and Agony of Haskell in Production

#42

Post by wereHamster » Sat, Feb 20, 2016, 3:04 PM UTC

jeremyjh wrote: post #38

wereHamster wrote: post #20

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.

For Aeson instances you really should be using the Generics. I do agree though that there are useful libraries (AcidState/SafeCopy is one example) that cannot reasonably be used without TemplateHaskell. While TemplateHaskell should be avoided if possible, it isn't the only consideration in choosing a design and dependency tree.

The article does not go into detail why TH is bad, and neither do you. Why should I be avoiding it? What are the exact problems with it, except the occasional breakage with new GHC releases?

Generics is also not without its faults (it inflates compile time/memory, for example, see problems surrounding aeson 0.10). If the article is correct when it says that /[TH is] a eternal source of pain and sorrow/, then you're trading one pain for another.

Re: The Joy and Agony of Haskell in Production

#43

Post by pmarreck » Sat, Feb 20, 2016, 3:15 PM UTC

RGamma wrote: post #33

rwmj wrote: post #19

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

Monads are essentially functors...

... A monoid in the category of endofunctors

Re: The Joy and Agony of Haskell in Production

#44

Post by tamana » Sat, Feb 20, 2016, 3:27 PM UTC

ergl wrote: post #31

rwmj wrote: post #19

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

Hmm, I found functors a bit confusing on my first encounter with the language, but I wouldn't call them 'academic'. If you've ever used Haskell typeclasses, they serve almost the same purpose. In OO land, they're just a way to ensure that an argument satisfies an interface, exposing certain public functions and properties — just like an object in Java has to implement the Comparable interface in order to be sorted in…

Haskell typeclasses are a headache that many Haskell experts eschew.

Re: The Joy and Agony of Haskell in Production

#45

Post by tamana » Sat, Feb 20, 2016, 3:28 PM UTC

runiq wrote: post #35

RGamma wrote: post #33

Earlier quoted context omitted.

Monads are essentially functors...

Not just essentially. All monads are functors.

Not in OCaml. It's a different concept.

Re: The Joy and Agony of Haskell in Production

#46

Post by tamana » Sat, Feb 20, 2016, 3:30 PM UTC

sdegutis wrote: post #4

This felt like a really fair and unbiased overview of the pros and cons of using Haskell. It's really refreshing to see that kind of honesty without any sensationalism. And it seems to have a lot of really interesting social insights about the situation, which I found surprisingly interesting.

Diehl has a lot of good no-nonsense newbie-accessible writing on Haskell.

Re: The Joy and Agony of Haskell in Production

#47

Post by tamana » Sat, Feb 20, 2016, 3:33 PM UTC

mbrock wrote: post #40

DanielBMarkham wrote: post #27

This was good. Thank you. The part that most worried me was If we look at the history of programming, there are many portents of the future of Haskell in the C++ community, another language where no two developers (that I’ve met) agree on which subset of the language to use. I also perked up when he talked about the difference between pipeline-paradigm coding and coding involving monadic trees. I'd love to dive into…

There might be good such books, I wouldn't really know. The Scheme-oriented How to Design Programs seems like a good candidate. I think the Haskell world would benefit from talking a bit more about "design patterns." I've seen the concept get a fair bit of abuse because of the claim that Haskell's abstraction facilities are good enough to eliminate the need for Visitor Pattern style boilerplate—which has truth to it,…

Yes. People say "patterns are just first-class functions"but they miss the point that not all functions can be combined with each other in manageable ways, so there is still an art to it.

Also, stuff like "strictness annotation" is not a function.

Re: The Joy and Agony of Haskell in Production

#48

Post by tome » Sat, Feb 20, 2016, 3:36 PM UTC

tamana wrote: post #47

mbrock wrote: post #40

Earlier quoted context omitted.

There might be good such books, I wouldn't really know. The Scheme-oriented How to Design Programs seems like a good candidate. I think the Haskell world would benefit from talking a bit more about "design patterns." I've seen the concept get a fair bit of abuse because of the claim that Haskell's abstraction facilities are good enough to eliminate the need for Visitor Pattern style boilerplate—which has truth to it,…

Yes. People say "patterns are just first-class functions"but they miss the point that not all functions can be combined with each other in manageable ways, so there is still an art to it. Also, stuff like "strictness annotation" is not a function.

> Also, stuff like "strictness annotation" is not a function.

Ah but it should be :)

[Not a function actually, but a type constructor: http://h2.jaguarpaw.co.uk/posts/strictness-in-types/]

Re: The Joy and Agony of Haskell in Production

#49

Post by bloaf » Sat, Feb 20, 2016, 3:41 PM UTC

sklogic wrote: post #14

fsloth wrote: post #12

Earlier quoted context omitted.

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

There is a reason the Catholic Church uses Latin for important documents. The fact that Latin is a dead language means that the meaning of those documents won't change over time.

Re: The Joy and Agony of Haskell in Production

#50

Post by charlieflowers » Sat, Feb 20, 2016, 3:58 PM UTC

tamana wrote: post #44

ergl wrote: post #31

Earlier quoted context omitted.

Hmm, I found functors a bit confusing on my first encounter with the language, but I wouldn't call them 'academic'. If you've ever used Haskell typeclasses, they serve almost the same purpose. In OO land, they're just a way to ensure that an argument satisfies an interface, exposing certain public functions and properties — just like an object in Java has to implement the Comparable interface in order to be sorted in…

Haskell typeclasses are a headache that many Haskell experts eschew.

Wow, really? I learned some Haskell on the side a few years ago, and typeclasses were one of my favorite features. They allowed so much expressiveness from such small building blocks. They seemed like a cornerstone of the language.

I'm surprised to hear they're often eschewed.