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

31–40 of 94 posts

Re: The Joy and Agony of Haskell in Production

#31

Post by ergl »

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

Re: The Joy and Agony of Haskell in Production

#32

Post by cm3 »

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…

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

I don't understand what you're saying. Are those applicants to Red Hat, or developers asking to contribute to libguestfs that you say no to.

Re: The Joy and Agony of Haskell in Production

#33

Post by RGamma »

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

Re: The Joy and Agony of Haskell in Production

#34

Post by Gratsby »

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.

Question 1: Do you actually know Haskell?

Question 2: How the F#*$ are you a software developer in Mountain View without a job?

Re: The Joy and Agony of Haskell in Production

#35

Post by runiq »

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

Not just essentially. All monads are functors.

Re: The Joy and Agony of Haskell in Production

#36

Post by tome »

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

The word "functor" means in OCaml something very different to what it means in Haskel.

Re: The Joy and Agony of Haskell in Production

#37

Post by Chattered »

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…

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 ordering module applied to the same ordered set module.

Re: The Joy and Agony of Haskell in Production

#38

Post by jeremyjh »

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.

Re: The Joy and Agony of Haskell in Production

#39

Post by danidiaz »

> Strings The strings types are mature, but unwieldy to work with in practice. It’s best to just make peace with the fact that in literally every module we’ll have boilerplate just to do simple manipulation and IO.

Conversion is part of the hassle, the other part is not having common functions (like, say, "splitPrefix") that will work across all string-like types.

For this, I recommend the monoid-subclasses package which, among other goodies, offers the TextualMonoid typeclass, that has instances for many string-like types.

http://hackage.haskell.org/package/monoid-subclasses-0.4.2/d...

Re: The Joy and Agony of Haskell in Production

#40

Post by mbrock »

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, but loses the baby with the bathwater.

Design patterns as in "common ways to structure programs and parts of programs" are fundamental for people who are learning to program productively. They constitute the repertoire of coding on the level above syntax. They're the principal structures of the idiomatic lexicon. The good ones seem obvious once you understand them, but a poor grasp of them causes vague confusion and big missteps.

In Haskell (and pure FP in general), there are a lot of useful design patterns that beginners pick up from the ambient culture if they're lucky:

  - the reader/state/IO monad transformer stack;
  - domain values as algebraic structures e.g. monoids;
  - functor composition;
  - free monad interpreters;
  - Xmonad-style pure core with I/O wrapper;
  - explicit ID values for representing identity;
  - recursion schemes;
  - and so on and so on.
Sure, Haskell can represent a lot of these things as formal abstractions, and that's wonderful—but people still need to learn when and how to use them and adapt them for their domains.

What I'm describing is far from a Haskell-specific problem, actually—there aren't that many resources in general that focus on these kinds of patterns.

When I was a beginner programmer, I was lucky to find Ward Cunningham's original wiki, the Portland Pattern Repository, which was all about spreading and discussing this kind of cultural conceptual knowledge.

There was a strong humanistic influence (from Christopher Alexander, through the early agile movement before it became a high-octane consultancy buzzword) and Haskell's culture has more DNA from mathematics and logic, and so treats patterns differently...

Still, I would love to see more discussion about functional patterns, at all scales from function implementation to application architecture.

Post reply on HN