Haskell, and Why It Might Be My New Favourite Language

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.

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

As long as you're developing on linux. IME, trying to use haskell libraries on another OS is hell.

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.

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!

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.

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.

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

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.

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.

Some of that is just unfamiliarity, doubtless. Optimizing code to be read by people unfamiliar with the language is probably not a good habit. I recall once wading into a C++ code base and coming across the line:

    using namespace std; // using namespace standard

On the flip side, people certainly do go overboard with cramming things into a single line (an affliction not at all unique to Haskell) and in particular overuse of "point free" style where it's inappropriate can lead to particularly unreadable code for those not well versed in the particular tricks used to make the code point free (and that's an affliction more unique to Haskell). I don't see either problem in the code in the article, though.

Indeed. But I am not sure if "crazy" is the right word. Perhaps a better one would be "dense". It is not unlike reading a mathematical proof - one paragraph might need an one semester course to be explained.

This is perfectly nice:

firstBatch = take 10 myDoubles

This is not that nice: sieve (p:ps) xs = h ++ sieve ps [x | x <- t, rem x p /=0] where (h,~(_:t)) = span(< p*p) xs

But that's because there's just too many things going on. A comparable Java code would likely span a page.

I guess, for a trained eye, it is way easier to understand what's going on given those two lines, then a full page program, which would likely hide bugs in side effects.

Every language that differs from the structure you're familiar with will seem crazy until you learn how to read it. Be that Haskell, Erlang or Japanese it's no different.

This will solve that problem for you:

http://learnyouahaskell.com/

One of the best intro programming books around, just happens to be about Haskell. Miran has a knack for explaining complex technical concepts.

Haskell's structure is actually incredibly readable - significant whitespace enforces uniformity across all codebases, and syntactically separating function type signatures from function declarations is far more readable than, say, Scala where it's all crammed together in one line.

You do have to learn all the operators though, but again, Miran's book is really good for that.

Golf:

  getMultiples = [3,6..999] `union` [5,10..999]

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 ;)

Have you looked at Rust?