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

51–60 of 94 posts

Re: The Joy and Agony of Haskell in Production

#51

Post by danidiaz »

charlieflowers wrote: post #50
tamana wrote: post #44

Earlier quoted context omitted.

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.

I wouldn't say they are eschewed.

Haskell programmers do seem to prefer typeclasses that come equipped with some set of meaningful "laws" that help to reject "unreasonable" instances.

And even without that, they are very useful for data type conversions and the like.

Re: The Joy and Agony of Haskell in Production

#52

Post by tome »

charlieflowers wrote: post #50
tamana wrote: post #44

Earlier quoted context omitted.

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.

Highly abstract and general typeclasses for standard mathematical and algebraic concepts are extremely useful and not eschewed. With them you can do genuinely generic programming in a syntactically convenient way. Examples include: Functor, Applicative, Monad, Num, Floating, Integral, MonadState, MonadReader, Profunctor, Contravariant, ...

Typeclasses which are ad hoc, specific, and typically defined on a per project basis, are much more debatable. If you have the concept of "rendering to the screen" and you have typeclass Renderable with a render method then this is really no better than just writing separate functions for each instance of the Renderable. This isn't genuinely generic programming, it's just symbol overloading.

Re: The Joy and Agony of Haskell in Production

#53

Post by mike_hearn »

danidiaz wrote: post #39

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

Is there any good article on how Haskell got into a situation where there are multiple different string types? I understand how it happened with C/C++ (e.g. on Windows), but Haskell is much more modern than that.

I feel there must be some sort of story or interesting thing to learn here. Or is it just the usual str vs widestr type problems?

Also was interested to see the comment about huge records and the memory pressure it can cause. Seems like that's really an issue with immutability. I was expecting the author to provide some sort of advice or workaround for it, but apparently not.

Re: The Joy and Agony of Haskell in Production

#54

Post by samth »

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…

Are you saying that you never hire anyone at all to work on your project, or that you think so little of the community that created the language your project uses that you lie to them about job openings?

Re: The Joy and Agony of Haskell in Production

#55

Post by efnx »

tome wrote: post #52
charlieflowers wrote: post #50

Earlier quoted context omitted.

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.

Highly abstract and general typeclasses for standard mathematical and algebraic concepts are extremely useful and not eschewed. With them you can do genuinely generic programming in a syntactically convenient way. Examples include: Functor, Applicative, Monad, Num, Floating, Integral, MonadState, MonadReader, Profunctor, Contravariant, ... Typeclasses which are ad hoc, specific, and typically defined on a per project…

Hey, you're talking about my library Renderable - and I'm totally up to finding a more idiomatic way to express the problem. It just so happened that type classes were the easiest way to do that.

Re: The Joy and Agony of Haskell in Production

#56

Post by mcguire »

mike_hearn wrote: post #53
danidiaz wrote: post #39

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

Is there any good article on how Haskell got into a situation where there are multiple different string types? I understand how it happened with C/C++ (e.g. on Windows), but Haskell is much more modern than that. I feel there must be some sort of story or interesting thing to learn here. Or is it just the usual str vs widestr type problems? Also was interested to see the comment about huge records and the memory pres…

I don't know about such an article, but Haskell's basic string is a linked list of characters. Nobody likes that.

Re: The Joy and Agony of Haskell in Production

#57

Post by michael_007 »

mike_hearn wrote: post #53
danidiaz wrote: post #39

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

Is there any good article on how Haskell got into a situation where there are multiple different string types? I understand how it happened with C/C++ (e.g. on Windows), but Haskell is much more modern than that. I feel there must be some sort of story or interesting thing to learn here. Or is it just the usual str vs widestr type problems? Also was interested to see the comment about huge records and the memory pres…

I don't know an article, but the overall situation is pretty straightforward to understand.

The original Haskell strings were linked lists of characters. This was simple and elegant and worked well with the functional programming approach of the time (1980s, by the way, so maybe Haskell in its origins isn't quite so modern as you think). Nobody was much concerned about high performance string operations in Haskell at the time.

Inevitably, later people wanted to add more performant string types. But should they be lazy or strict? And do you want an abstract representation of Unicode, or do you want something more immediately suitable for arbitrary binary data? Enter four more string types. And now here we are with 5 string types in common use.

Re: The Joy and Agony of Haskell in Production

#58

Post by fsloth »

sklogic wrote: post #28
fsloth wrote: post #24

Earlier quoted context omitted.

Thanks, but I'm not very productive in Lisp. Lisp development environments need emacs and emacs and my brains are not compatible. I've tried the 15 years to pick it up time and again but to no avail. Last time I even made a cheat sheet for myself (a link here as a proof of effort): https://www.dropbox.com/s/ceiijwn8s31j8hv/emac_memo.svg?dl=0 Given the platform availability I'm pretty sure C++ will eventually reach th…

With all the activity with C++ development it'll hardly ever stabilise. Ever since C++11 it keeps changing at a frightening pace. And you don't really need Emacs for Lisp, there are multiple other options (but yes, I'm using Emacs for C++ too). Btw., quite a nice cheat sheet. What did you use to make it?

What's the best alternative to emacs for common lisp development?

"Btw., quite a nice cheat sheet. What did you use to make it?"

Thanks. Inkscape.

Re: The Joy and Agony of Haskell in Production

#59

Post by tome »

efnx wrote: post #55
tome wrote: post #52

Earlier quoted context omitted.

Highly abstract and general typeclasses for standard mathematical and algebraic concepts are extremely useful and not eschewed. With them you can do genuinely generic programming in a syntactically convenient way. Examples include: Functor, Applicative, Monad, Num, Floating, Integral, MonadState, MonadReader, Profunctor, Contravariant, ... Typeclasses which are ad hoc, specific, and typically defined on a per project…

Hey, you're talking about my library Renderable - and I'm totally up to finding a more idiomatic way to express the problem. It just so happened that type classes were the easiest way to do that.

Ha, sorry, didn't mean to make it sound like I was talking about anything in particular! I just made up that example on the spot. A "Renderable" thing fits into a common pattern where you see typeclasses used in this way.

(Are you talking about this library? https://hackage.haskell.org/package/renderable-0.1.0.0/docs/...

I don't actually see a Renderable class there anyway.)

Post reply on HN