8 ms·

Haskell, and Why It Might Be My New Favourite Language

83 points by sambeau 12y ago

eldavido 12y ago
Slightly meta, but: has anyone else noticed how much love languages with very strong type disciplines have been getting on HN recently? Scala, Haskell, Clojure, Go, Rust jump out. Maybe language designers/toolmakers are getting better at bringing the benefits of stronger typing (superior editor support, faster execution times, less need for unit testing) without as much baggage: highly ceremonial code, complex compiler setup/tooling, etc? I suspect editor/compiler-level type inference, where you can do things like "val x = NewVal()" vs. "NewVal x = new NewVal()" might have something to do with it. As someone who's swung back and forth across this divide, I get the sense that modern static language development is much less of a pain in the ass than it was 10yrs ago. I'm less interested in static vs. dynamic than I am in why the community seems to be floating in this direction recently, when the past 5-7 years has been all about RoR, Django, and even Perl.
- ixmatus 12y ago
  I do not consider Go to have a strong type system. It's static though. Strong typing allows you to do a lot and it also solves the problem we fallible humans bring to the table. Humans are pretty good at being creative but extremely terrible with details, remembering things, and keeping track of "hairballs". Strong type systems solve pretty much all of that. Now, with some of Haskell's newest features (like Type Holes) it's starting to make dynamic languages look more like children's toys because you get all the power and safety of a type system with the same "do what you want, it will (usually) tell you what you're intending to put there". Dynamic programming came from a need for rapid iteration of a program because that's how humans work, we "start" then iterate till we have a more complex and functioning program. The problem with that model though, is that the burden of correctness is on us in the end. Programming in Python is like leaving your dishes pile up in the sink for a week, then spending two hours doing dishes on Sunday. Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it.
  - IanCal 12y ago
    > Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it. With the occasional smash coming from the kitchen when you find out the robot has been trying to hold all of your plates at once instead of putting them away because you haven't gone to get one out of the cupboard yet ;)
    - slashnull 12y ago
      A stack of type t things blowing up because of lazyness... How appropriate ; )
  - dllthomas 12y ago
    It's now "typed holes", which really is a much better description anyway.
  - dscrd 12y ago
    Programming in dynamic types is not easier because you can jump around the type system more dextrously. Programming in dynamic types is easier because you (mostly) can forget that types even exist. That leads to lesser cognitive load, and that always makes a thinking job easier. That of course makes it more dangerous too, but it's a trade-off.
    - TheCoelacanth 12y ago
      Even in a dynamically typed language you can't just ignore the types. You still have to make assumptions about what methods and functions can operate on a value; the compiler just doesn't know what assumptions you are making.
- Shamanmuni 12y ago
  I get the feeling that many programmers have been bitten by weak typing too many times and have come to appreciate the benefits of stronger typing. If you want to apply defensive programming, which is always a good idea, you usually encounter this pattern: "I'm expecting an Int. Is this an Int? No, this is a string. But if I converted it, would the result be an Int? No? OK, then we have a problem, what should I do about it?". Some languages even have automatic type coercion, in which the final result depends entirely on what the language decides, and varies across languages. It's a mess. Languages like Haskell or the ML family, with their type systems and type inferences, simply won't compile if you say you are expecting an Int and some other part of the program sends anything else. Maybe it's more work for the programmer upfront, but it reduces future headaches, and it's not difficult once you get the hang of it. Many times you don't even have to state the types explicitly, the compiler just knows. Thanks Hindley-Millner!
- pekk 12y ago
  You could assume it is something inherent, or you could just connect the dots and realize that it's the silver-bullet fad of the decade, just like OOP and various other things before that.
  - Rusky 12y ago
    Silver-bullet fads tend to have a grain of truth that gets carried on into the next fad. Loops are still with us (structured programming), we still write polymorphic code (OOP), we still like less verbose type systems (dynamic languages), etc.
  - _random_ 12y ago
    No, it's just a second take at removing the "ceremony": v. 1: let's remove the ceremony along with strong static typing advantages and just hack-fix everything with unit tests. v. 2: let's remove just the ceremony.
- sampo 12y ago
  In the 90's Java/C/C++ land, one needed to implement lists and dicts and such by hand. Then came dynamic Perl/Python/Ruby where all these handy data types like list comprehensions, map, foreach were part of the language. I guess we mistook easy operations on a rich set of default data types as a property of dynamic languages? Now we have Scala, Haskell, OCaml, Rust that have all these handy tools by default, but also strong typing, and type inference on top of that. (Well OCaml and Haskell we had already some time ago, but they were not popular then.)
- SkyMarshal 12y ago
  Static typing != Strong typing. Once you've grokked Haskell it's hard to consider mere static type systems to be type systems at all. Languages like Java, Go, etc. may as well just be dynamically typed for all their type systems do for you vs Haskell's. I think that revelation may be one of the things driving this new interest in type systems and comparisons of them. Haskell has really opened some eyes and people are wondering how others compare, and are on the lookout for new languages like Rust doing interesting things with strong typing.
  - slashnull 12y ago
    Dynamic typing without the metaprogramming, plus tacked-on parametric typing in the form of templates or generics or whatever they call it. Or better yet: no parametric typing whatsoever and no way of making strongly-typed abstract data structures. Or duck typing, which is exactly that. Yup, no strong typing anywhere.
  - dscrd 12y ago
    Plenty of killer bugs are smashed in compile time by the most simple compiler checks.
- slashnull 12y ago
  The weirdest thing with the new breed of strongly typed language, in my opinion, is that they naturally accept sum types, which are completely alien from an OOP point of view. I mean, the magnificiently useful case switch feature you have in most of those new languages translates very awkwardly in, say, Java by using a isinstanceof then some kind of cast, which I gather is Considered Harmful because it breaks encapsulation and type safety, yet case switches are a natural consequence of sum types, and are completely safe, in the context of a type system that have sum types. Switching on "type" also happens to be a thing I see a lot in what one would traditionally consider bad code, for example, treating a scalar and an array differently in PHP, or having functions that can deal with many different shapes and kinds of JSON blobs in JavaScript. There also have been a lot of hype around the idea of eliminating null references by using Maybe types, which in the end are just a degenerate case of a sum type. My pet theory is that the ability to keep doing this in a safe and formalized manner is what makes the new breed of statically typed PLs so cool.
woah 12y ago
Haskell syntax just seems pretty crazy. I know nothing about it, but I just read it and wish that maybe one could use a few more lines and get better understandability at the expense of terseness.
- ixmatus 12y ago
  It's the difference between Eclipse and Emacs. Haskell actually encourages "internalization" of abstractions through terser syntax. Emacs is like that, you internalize the editor which makes you 5x more productive than you are with an editor that externalizes the abstraction requiring your brain to use another layer of translation (the visual one). If you learn Haskell, you'll find it quite enjoyable (I do now). The way I think in that language is so much more abstract and precise than it ever was in Python / Scheme / Erlang / Ruby / Javascript. [EDIT] To whomever is downvoting these legitimate comments, speak up why you think they are inappropriate for this discussion instead of downvoting.
  - thescribe 12y ago
    Your enthusiasm has convinced me to give Haskell another shot, do you have a favorite resource I should try? I didn't have great luck prior.
    - louthy 12y ago
      These should get you started: Really well presented series of lectures: http://www.seas.upenn.edu/~cis194/lectures.html http://www.seas.upenn.edu/~cis194/lectures.html Cheat sheet: http://blog.codeslower.com/static/CheatSheet.pdf http://blog.codeslower.com/static/CheatSheet.pdf Books: http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/ "What I Wish I Knew When Learning Haskell": http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ Haskell Tutorial for C Programmers (useful for anyone coming from an imperative world): http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Programmers http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Pr... Hoogle (API search engine): http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/
shawkinaw 12y ago
getMultiples is even shorter and clearer written like this: getMultiples = [x | x <- [1..999], x `mod` 3 == 0 || x `mod` 5 == 0]
- ckw 12y ago
  Golf: getMultiples = [3,6..999] `union` [5,10..999]
  - gertef 12y ago
    That doesn't sort the output neatly. You need a merge http://hackage.haskell.org/package/MissingH-0.18.6/docs/Data-List-Utils.html#1 http://hackage.haskell.org/package/MissingH-0.18.6/docs/Data...
cies 12y ago
TL/DR; a flimsy write-up on why he did not like Go, followed by a good write-up on what's great about Haskell when you just start to use it. Again this underlines some ideas I have about both Go and Haskell: * Go is great from a commercial perspective; easy to learn/understand, but nothing ground-breaking. * Haskell is great from a technical perspective; ground-breaking all over the place, but takes an investment. I believe the Haskell investment is one that every serious programmer should like to make as it should make your both work easier _and_ more fun.
- ixmatus 12y ago
  I'm undoubtedly a Haskell convert (from Erlang / Scheme / Python) with little experience in Go. The investment is pretty big, yes, but I also believe it is great from a commercial perspective because it really improves the result for End-Goal-Programming (end goal is to serve business needs, not technology for technology's sake): 1. Time to market for a product 2. Easy / clean refactoring 3. Massive scale code base management 4. Program longevity and maintainability 1) Time to market is extremely important for businesses and products and schedule over-flow is a common problem in software engineering that Haskell really does help solve. Since building production software in Haskell I've become completely frustrated by Python because I spend far more time building in it due to debugging my own undisciplined habits out of the end product. I'm not a very disciplined dynamic type programmer. It also produces cleaner and less buggy product for the end-user. Which is so important!!! Particularly as a startup. 2) If you need to cleanup some technical debt from taking short-cuts or not accurately pre-planning architecture, Haskell's type system makes it so friggin' easy your eyes will bleed when you try to do the same in a Python / Ruby / Erlang program. Additionally, it really allows you to respond to the market better too! If you have to pivot your product it's not "Oh shit, now we're going to have to take that duct taped sewage monster and turn it into a duct taped ninja turtle." it's "Hmmm, well, let's think through the new types a little bit and re-shape some of this code, I know the compiler will tell me when I'm being a silly human." 3. Python and Ruby aren't really appropriate for large scale code bases because dynamic typing means you need an equally massive amount of tests to ensure no one else in the org fucks shit up. It makes team based programming on the same codebase far more manageable!! 4. Once I've built my Haskell programs and wrote a few minor property tests with QuickCheck, they usually run forever. I've rarely ever had a case where I would get unexpected crashes (usually from my not understanding Haskell's laziness earlier on in my Haskell career). Long-term maintainability is massive factor here too; it's so much easier to figure out what the damn thing and all of its constituent pieces do with the type system!!! It's like having an index and a table of contents for a book. Since most programmers forget their own code anyway (comes back to that fallible human thing), having a neat and correct abstract description of your program and its parts is invaluable to a commercial enterprise. So, in short, I actually think Haskell is the best language a commercial enterprise could choose. All you need too is one really good programmer that can mentor, then train them as you go; the good news with Haskell is even when you write shitty Haskell code (un-idiomatic, mostly in the IO monad, and barring space leaks), it's usually better than even the good Python and Ruby code those people would be writing.
stefantalpalaru 12y ago
As crazy as it sounds, I can confirm that Go is a gateway drug for Haskell.
- letstryagain 12y ago
  Have you looked at Rust?
  - stefantalpalaru 12y ago
    Not yet. It looks like a moving target for now so I'm waiting for a stable release.
- codygman 12y ago
  Go was the gateway drug to Haskell for me too. As soon as I found out the type system wasn't giving me as many guarantees as I thought while making me type annotations I figured I should find a language with a stronger type system. As a bonus, said language had type inference ;)
wirrbel 12y ago
one thing about Haskell: It is different from other languages, but once you got the "mindset" it turns out to be surprisingly _easy_* to use. * especially, the haskell way of type-abstraction is sound and makes for really nice and convenient libraries in a way that one cannot imagine if not experiencing it form oneself.

83 points by sambeau 12y ago

Slightly meta, but: has anyone else noticed how much love languages with very strong type disciplines have been getting on HN recently? Scala, Haskell, Clojure, Go, Rust jump out. Maybe language designers/toolmakers are getting better at bringing the benefits of stronger typing (superior editor support, faster execution times, less need for unit testing) without as much baggage: highly ceremonial code, complex compiler setup/tooling, etc? I suspect editor/compiler-level type inference, where you can do things like "val x = NewVal()" vs. "NewVal x = new NewVal()" might have something to do with it. As someone who's swung back and forth across this divide, I get the sense that modern static language development is much less of a pain in the ass than it was 10yrs ago. I'm less interested in static vs. dynamic than I am in why the community seems to be floating in this direction recently, when the past 5-7 years has been all about RoR, Django, and even Perl.

ixmatus 12y ago
I do not consider Go to have a strong type system. It's static though. Strong typing allows you to do a lot and it also solves the problem we fallible humans bring to the table. Humans are pretty good at being creative but extremely terrible with details, remembering things, and keeping track of "hairballs". Strong type systems solve pretty much all of that. Now, with some of Haskell's newest features (like Type Holes) it's starting to make dynamic languages look more like children's toys because you get all the power and safety of a type system with the same "do what you want, it will (usually) tell you what you're intending to put there". Dynamic programming came from a need for rapid iteration of a program because that's how humans work, we "start" then iterate till we have a more complex and functioning program. The problem with that model though, is that the burden of correctness is on us in the end. Programming in Python is like leaving your dishes pile up in the sink for a week, then spending two hours doing dishes on Sunday. Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it.
- IanCal 12y ago
  > Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it. With the occasional smash coming from the kitchen when you find out the robot has been trying to hold all of your plates at once instead of putting them away because you haven't gone to get one out of the cupboard yet ;)
  - slashnull 12y ago
    A stack of type t things blowing up because of lazyness... How appropriate ; )
- dllthomas 12y ago
  It's now "typed holes", which really is a much better description anyway.
- dscrd 12y ago
  Programming in dynamic types is not easier because you can jump around the type system more dextrously. Programming in dynamic types is easier because you (mostly) can forget that types even exist. That leads to lesser cognitive load, and that always makes a thinking job easier. That of course makes it more dangerous too, but it's a trade-off.
  - TheCoelacanth 12y ago
    Even in a dynamically typed language you can't just ignore the types. You still have to make assumptions about what methods and functions can operate on a value; the compiler just doesn't know what assumptions you are making.
Shamanmuni 12y ago
I get the feeling that many programmers have been bitten by weak typing too many times and have come to appreciate the benefits of stronger typing. If you want to apply defensive programming, which is always a good idea, you usually encounter this pattern: "I'm expecting an Int. Is this an Int? No, this is a string. But if I converted it, would the result be an Int? No? OK, then we have a problem, what should I do about it?". Some languages even have automatic type coercion, in which the final result depends entirely on what the language decides, and varies across languages. It's a mess. Languages like Haskell or the ML family, with their type systems and type inferences, simply won't compile if you say you are expecting an Int and some other part of the program sends anything else. Maybe it's more work for the programmer upfront, but it reduces future headaches, and it's not difficult once you get the hang of it. Many times you don't even have to state the types explicitly, the compiler just knows. Thanks Hindley-Millner!
pekk 12y ago
You could assume it is something inherent, or you could just connect the dots and realize that it's the silver-bullet fad of the decade, just like OOP and various other things before that.
- Rusky 12y ago
  Silver-bullet fads tend to have a grain of truth that gets carried on into the next fad. Loops are still with us (structured programming), we still write polymorphic code (OOP), we still like less verbose type systems (dynamic languages), etc.
- _random_ 12y ago
  No, it's just a second take at removing the "ceremony": v. 1: let's remove the ceremony along with strong static typing advantages and just hack-fix everything with unit tests. v. 2: let's remove just the ceremony.
sampo 12y ago
In the 90's Java/C/C++ land, one needed to implement lists and dicts and such by hand. Then came dynamic Perl/Python/Ruby where all these handy data types like list comprehensions, map, foreach were part of the language. I guess we mistook easy operations on a rich set of default data types as a property of dynamic languages? Now we have Scala, Haskell, OCaml, Rust that have all these handy tools by default, but also strong typing, and type inference on top of that. (Well OCaml and Haskell we had already some time ago, but they were not popular then.)
SkyMarshal 12y ago
Static typing != Strong typing. Once you've grokked Haskell it's hard to consider mere static type systems to be type systems at all. Languages like Java, Go, etc. may as well just be dynamically typed for all their type systems do for you vs Haskell's. I think that revelation may be one of the things driving this new interest in type systems and comparisons of them. Haskell has really opened some eyes and people are wondering how others compare, and are on the lookout for new languages like Rust doing interesting things with strong typing.
- slashnull 12y ago
  Dynamic typing without the metaprogramming, plus tacked-on parametric typing in the form of templates or generics or whatever they call it. Or better yet: no parametric typing whatsoever and no way of making strongly-typed abstract data structures. Or duck typing, which is exactly that. Yup, no strong typing anywhere.
- dscrd 12y ago
  Plenty of killer bugs are smashed in compile time by the most simple compiler checks.
slashnull 12y ago
The weirdest thing with the new breed of strongly typed language, in my opinion, is that they naturally accept sum types, which are completely alien from an OOP point of view. I mean, the magnificiently useful case switch feature you have in most of those new languages translates very awkwardly in, say, Java by using a isinstanceof then some kind of cast, which I gather is Considered Harmful because it breaks encapsulation and type safety, yet case switches are a natural consequence of sum types, and are completely safe, in the context of a type system that have sum types. Switching on "type" also happens to be a thing I see a lot in what one would traditionally consider bad code, for example, treating a scalar and an array differently in PHP, or having functions that can deal with many different shapes and kinds of JSON blobs in JavaScript. There also have been a lot of hype around the idea of eliminating null references by using Maybe types, which in the end are just a degenerate case of a sum type. My pet theory is that the ability to keep doing this in a safe and formalized manner is what makes the new breed of statically typed PLs so cool.

woah 12y ago

Haskell syntax just seems pretty crazy. I know nothing about it, but I just read it and wish that maybe one could use a few more lines and get better understandability at the expense of terseness.

ixmatus 12y ago
It's the difference between Eclipse and Emacs. Haskell actually encourages "internalization" of abstractions through terser syntax. Emacs is like that, you internalize the editor which makes you 5x more productive than you are with an editor that externalizes the abstraction requiring your brain to use another layer of translation (the visual one). If you learn Haskell, you'll find it quite enjoyable (I do now). The way I think in that language is so much more abstract and precise than it ever was in Python / Scheme / Erlang / Ruby / Javascript. [EDIT] To whomever is downvoting these legitimate comments, speak up why you think they are inappropriate for this discussion instead of downvoting.
- thescribe 12y ago
  Your enthusiasm has convinced me to give Haskell another shot, do you have a favorite resource I should try? I didn't have great luck prior.
  - louthy 12y ago
    These should get you started: Really well presented series of lectures: http://www.seas.upenn.edu/~cis194/lectures.html http://www.seas.upenn.edu/~cis194/lectures.html Cheat sheet: http://blog.codeslower.com/static/CheatSheet.pdf http://blog.codeslower.com/static/CheatSheet.pdf Books: http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/ "What I Wish I Knew When Learning Haskell": http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ Haskell Tutorial for C Programmers (useful for anyone coming from an imperative world): http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Programmers http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Pr... Hoogle (API search engine): http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/

shawkinaw 12y ago

getMultiples is even shorter and clearer written like this: getMultiples = [x | x <- [1..999], x `mod` 3 == 0 || x `mod` 5 == 0]

ckw 12y ago
Golf: getMultiples = [3,6..999] `union` [5,10..999]
- gertef 12y ago
  That doesn't sort the output neatly. You need a merge http://hackage.haskell.org/package/MissingH-0.18.6/docs/Data-List-Utils.html#1 http://hackage.haskell.org/package/MissingH-0.18.6/docs/Data...

cies 12y ago

TL/DR; a flimsy write-up on why he did not like Go, followed by a good write-up on what's great about Haskell when you just start to use it. Again this underlines some ideas I have about both Go and Haskell: * Go is great from a commercial perspective; easy to learn/understand, but nothing ground-breaking. * Haskell is great from a technical perspective; ground-breaking all over the place, but takes an investment. I believe the Haskell investment is one that every serious programmer should like to make as it should make your both work easier _and_ more fun.

ixmatus 12y ago
I'm undoubtedly a Haskell convert (from Erlang / Scheme / Python) with little experience in Go. The investment is pretty big, yes, but I also believe it is great from a commercial perspective because it really improves the result for End-Goal-Programming (end goal is to serve business needs, not technology for technology's sake): 1. Time to market for a product 2. Easy / clean refactoring 3. Massive scale code base management 4. Program longevity and maintainability 1) Time to market is extremely important for businesses and products and schedule over-flow is a common problem in software engineering that Haskell really does help solve. Since building production software in Haskell I've become completely frustrated by Python because I spend far more time building in it due to debugging my own undisciplined habits out of the end product. I'm not a very disciplined dynamic type programmer. It also produces cleaner and less buggy product for the end-user. Which is so important!!! Particularly as a startup. 2) If you need to cleanup some technical debt from taking short-cuts or not accurately pre-planning architecture, Haskell's type system makes it so friggin' easy your eyes will bleed when you try to do the same in a Python / Ruby / Erlang program. Additionally, it really allows you to respond to the market better too! If you have to pivot your product it's not "Oh shit, now we're going to have to take that duct taped sewage monster and turn it into a duct taped ninja turtle." it's "Hmmm, well, let's think through the new types a little bit and re-shape some of this code, I know the compiler will tell me when I'm being a silly human." 3. Python and Ruby aren't really appropriate for large scale code bases because dynamic typing means you need an equally massive amount of tests to ensure no one else in the org fucks shit up. It makes team based programming on the same codebase far more manageable!! 4. Once I've built my Haskell programs and wrote a few minor property tests with QuickCheck, they usually run forever. I've rarely ever had a case where I would get unexpected crashes (usually from my not understanding Haskell's laziness earlier on in my Haskell career). Long-term maintainability is massive factor here too; it's so much easier to figure out what the damn thing and all of its constituent pieces do with the type system!!! It's like having an index and a table of contents for a book. Since most programmers forget their own code anyway (comes back to that fallible human thing), having a neat and correct abstract description of your program and its parts is invaluable to a commercial enterprise. So, in short, I actually think Haskell is the best language a commercial enterprise could choose. All you need too is one really good programmer that can mentor, then train them as you go; the good news with Haskell is even when you write shitty Haskell code (un-idiomatic, mostly in the IO monad, and barring space leaks), it's usually better than even the good Python and Ruby code those people would be writing.

stefantalpalaru 12y ago

As crazy as it sounds, I can confirm that Go is a gateway drug for Haskell.

letstryagain 12y ago
Have you looked at Rust?
- stefantalpalaru 12y ago
  Not yet. It looks like a moving target for now so I'm waiting for a stable release.
codygman 12y ago
Go was the gateway drug to Haskell for me too. As soon as I found out the type system wasn't giving me as many guarantees as I thought while making me type annotations I figured I should find a language with a stronger type system. As a bonus, said language had type inference ;)

wirrbel 12y ago

one thing about Haskell: It is different from other languages, but once you got the "mindset" it turns out to be surprisingly _easy_* to use. * especially, the haskell way of type-abstraction is sound and makes for really nice and convenient libraries in a way that one cannot imagine if not experiencing it form oneself.