Courting Haskell

https://honzajavorek.cz/blog/courting-haskell

by honzajavorek • 7 years ago

84 55 7 years ago

In the past two months I've been trying to learn the Haskell programming language. It's vastly different from anything I know, so it served me also as a way how to empathize with complete beginners to coding. This is a diary from my journey.

cdaringe• 7 years ago

To the whole article I say "ditto." Great summary. Also, didn't Guido say he wanted to eject the functional operators in Python? #hearsay

sli• 7 years ago

Slashdot had an interview with him where he talks about it[0], he basically says Python isn't the language for FP and then complains about readability which, YMMV on that one. I don't know if his opinion has changed in the last seven years, though.

[0] https://developers.slashdot.org/story/13/08/25/2115204/inter...

alephu52• 7 years ago

I've been been learning haskell by building a standard monolithic web application: Postgres DB, some static content, REST API and firebase authentication. It's taking longer than it would with a familiar language but so far I'm really enjoying the experience. I also took a small deviation a couple of weekends ago to build a simple OSM router and was pleased with the ease of development and performance.

I'd recommend the book Practical Haskell by Alejandro Serrano Mena to get a firm introduction to the language and ecosystem of web applications. After that take at look at the libraries developed by FP complete.

hopia2• 7 years ago

I'm using the same method as you. What are you using as the SQL and REST API libs? I'm using Servant and a library called Squeal for Postgres.

alephu52• 7 years ago

I'm combining servant and Yesod into a single WAI app so that I can serve a web app and provide an API from the same server. For DB access I'm using persistent.

crimsonalucard10• 7 years ago

A different way of thinking of abstraction or just a feeling of elegance or a feeling of power is not a sufficient explanation for why Haskell is so great.

People want definitive and theoretically correct answers not talking points for a philosophical debate on programming styles.

Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences.

solomonb2• 7 years ago

Why does "Typed Functional Programming" have to be measurably "better" then OOP or procedural programming in order for Haskell to be considered a good language?

All those questions at the end of your comment can be turned around the other way and are equally valid and unanswerable.

crimsonalucard10• 7 years ago

Why use it if it's not measure-ably better on some metric? It's important because we should only use things if they are better or the same. Not if they are worse.

Sure, there are tradeoffs but if you quantify all tradeoffs something usually comes out better.

dpatru• 7 years ago

Why is typed functional programming measurably better than procedural? Why is it better than OOP? Definitive answers are in demand not exploratory experiences.

Functional code tends to be shorter than procedural code. This allows you to think in bigger steps. For example, to read whitespace-separated numbers from stdin and print out their sum, in haskell you could write:

    main = interact $ show . sum . map read . words

This uses very generic haskell functions to put the input into a list of strings, read each string as a number, sum the numbers and show the sum as a string.

It seems to me that the equivalent procedural code would be much longer.

Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense. For example, if you leave out the "read" function above, you would be trying to sum strings instead of numbers. Haskell's type checker would complain at compile time. This enables you to program at a high level without having to debug run-time errors because of type mistakes.

crimsonalucard10• 7 years ago

Functional code tends to be shorter than procedural code

Shorter is one metric that FP "tends" to be better at. But it's not definitive. Who says procedural programs can't be shorter? And also is shorter necessarily better? Also does it come at the cost of readability? Actually let's not get into readability as it's not exactly measure-able.

Haskell's type system keeps track of what's going on and alerts you when you try to do something that doesn't make sense.

Algebraic Type systems are indeed a measure-able metric when you measure correctness, amount of errors or total possible programs you can write. It restricts the code you can compile to be correct from a typed perspective. Meaning that out of all the possible programs you can write, Haskell allows you to write less programs in the sense that it stops you from writing certain incorrect programs.

However, ADT's can be used in procedural programs or OOP programs as well. See Rust.

What I want to know is specifically about the functional programs. In the functional programming paradigm what is the quantify-able metric that makes it definitively better?

mkl• 7 years ago

It's shorter in Python:

  sum(int(n) for n in input().split())

I'd argue it's an awful lot clearer, too.

Edit: A more functional version is shorter still, but I think not worth the readability cost:

  sum(map(int, input().split()))

sseth• 7 years ago

I feel to be realistic you have to show a program with failure scenarios. That is at least where i struggle with FP. Like what happens if a user enters a non-numeric value and i want to echo back a warning and get a correction, before continuing?

eyegor• 7 years ago

Definitive answer: sum/union types [0] and currying/partial function application [1]. Between the two, almost anything you write becomes very easy to adapt to new requirements. Anyone who has done a medium to large scale fp project can attest to this.

If you want to be pedantic, currying and partial application are separate concepts, but I've never seen an fp lang implement one without the other. Note that I linked to this f# blog because I think its example-forward approach is clearer than most fp documentation I've read.

[0] https://fsharpforfunandprofit.com/posts/discriminated-unions...

[1] https://fsharpforfunandprofit.com/posts/currying/

leshow6• 7 years ago

Sum and product types are essential for programming. After you have used a language with them you will miss them dearly in any other language you use.

Typeclasses and traits (if you're writing Rust) coupled with ad hoc polymorphism are a succinct and beautiful method of abstraction. You will miss them also in almost any other language.

Those features in a language (functional or not) will let you confidently refactor code, and (IMO) will lead to less mistakes and better abstractions.

ggm• 7 years ago

At last! somebody else who is prepared to be honest about their fear of maths, and mathematical notation, and people who leap from "its just like school maths" to referring to the intimidating maths you skipped or failed in school and university.

Its just like maths: requires deep brain structure wiring you may not have.

Rerarom2• 7 years ago

I wonder why is there is so much fear of math on HN, which is essentially a STEM community. I would expect it among literary types, but not here.

bawolff4• 7 years ago

People overstate the connection between math and computer programming. Sure there are math heavy areas, but your average programmer isn't into them. At most programming typically involves the mildest amounts of whats in an intro to discrete math course.

Tarq0n• 7 years ago

I think many people have a problem with mathematical notation, not maths itself. Mathematical notation is optimized for terseness and suitability for use on a whiteboard. Code has made great leaps in terms of readability and expressiveness compared to that, and is therefore more accessible to many people even when expressing the same concepts.

For an example see the comments on the map/reduce post from yesterday.

bawolff4• 7 years ago

Do people actually claim haskell-ish math (i.e. abstract algebra type stuff) is just like school (highschool?) math.

If so, i wish i was in their high school. Sounds much more interesting than mine.

ssivark• 7 years ago

Though I’m not much of a Haskell programmer (spent some time learning it and writing toy programs), I would use a different motto to characterize Haskell: Stop prescribing (loose) design patterns; make them tight and refactor them into libraries, so they need only be written once.

More than anything else, the language aims at providing modularity (and terseness, on the macro scale) for the programmer (while trying very hard to compile to something efficient). Even laziness is to enable more modularity.

The “make design patterns tight” part is what ends up needing abstract mathematical reasoning (category theory is basically mathematical pattern reasoning distilled to its essence).

The other consequence of abstracting patterns into libraries is that novice programmers end up with a lower “writing code” -vs- “reading+thinking” ratio compared to other languages. And this can be jarring to folks whose attitude is to learn by writing code (to discover patterns in the process).

zozbot234• 7 years ago

I wouldn't say that Haskell is "trying very hard" to enable efficient compilation. It might be trying hard given what the existing language semantics looks like, but we still don't have e.g. an elegant model that can equally account for both strict and lazy code (even though there's quite a bit of research in this area, based on fairly natural considerations).

Reasoning about what code patterns actually require the use of general GC (because they involve creating references that might outlive their pre-defined scope, as with general closures) and what patterns might dispense with this is another source of potential efficiency improvements.

ncmncm3• 7 years ago

"All patterns are anti-patterns."

A pattern is a common expression form that your chosen language is unable to capture in a library. As we get better languages, what had been patterns turn into ordinary library components. Patterns composing those with one another and with core language features either become more library components, or challenges for subsequent language design.

mikekchar3• 7 years ago

I really disagree with this viewpoint. Patterns are just patterns. It doesn't matter if your language is able to express the pattern in a reusable form or not. The whole point of a pattern is that it is a common solution to a class of problems given a set of circumstances. Even if you have a "super awesome pattern" widget that you can use, you still need to know whether or not that pattern is appropriate for the problem you have and the circumstances in which the problem is expressing itself. Even beyond that, most programmers will be dealing with many more than one programming language in their lifetime. Learning well known design patterns is about understanding the abstractions, the problems and the circumstances so that when you are faced with a similar situation in another language you can efficiently see if there are capabilities that will help you out.

Basically, consider the situation where you say, "Here's how I do X in this language. How would I do a similar thing in that language"? A design pattern gives you a name that you can use instead of "X". It also gives you a context where you can realise, this pattern is appropriate in here, but not appropriate there. When you talk to people you can simply say, "Can I easily implement a functor here? If not, how can I get similar utility in the same circumstances? Are there any caveats that are different than the normal ones?" It seriously speeds up the conversation. It also allows one to think about programming more generally rather than thinking of it only in terms of a specific programming language.

Edit: grammar

avindroth• 7 years ago

no mention of haskellbook.com is surprising!

olah_12• 7 years ago

I read that book for 6 months straight, followed all the exercises, and quit when I realized I couldn't write a simple script that did something useful.

But boy did I sure evangelize Haskell throughout the process! facepalm

solomonb2• 7 years ago

HPFFP was the book that finally made the language 'click' for me. It took 13 months to complete and only towards the very end did I start to get an understanding of how to structure an actual program larger then a leet code exercise.

Its a _really_ different language from what I was used to (Javascript, Python, Ruby, etc). The book covered a lot of material that felt very basic to me, but interspersed with that was material that covered concepts I had never even considered, this was the case in the early chapters as well as later on.

I found that the early chapters setup lots of concrete examples that later on would be revealed as simplified cases of highly abstract structures that occur all over the place. Uncovering these is a very magical experience. For that reason alone, I tell people to just grind through the book rather then skipping ahead to the more exciting material later on.

But you don't have to like HPFFP or Haskell, nobody has to like anything. For me, Haskell is a joy to use and provides a seemingly never ending source of learning material to explore.

hopia2• 7 years ago

I started building straight away from day 1, getting a decent REST API together is surprisingly easy. You really don't need to understand most of the advanced type level stuff to stay productive.

Maybe you tried to go for too high abstraction level straight off the bat? That can turn out very depressing on Haskell.

proc0• 7 years ago

" Powerful! It takes just a few lines to implement your own clone of Vim:"

Uh, ok lol.

" If SQL or Python read like an English sentence, then Haskell reads like math. Feels like math. It is math. "

This is basically why there's a learning curve. Any analogy used as a learning example will typically fall short because in order to fully grasp the concepts you just have to learn the math behind it, because that's by design (denotational semantics).

Rerarom2• 7 years ago

You keep mistyping Clojure as Closure

andolanra• 7 years ago

"[Haskell is], indeed, heavily founded on mathematical theories (category theory and lambda calculus)."

This is a pretty common reason given for why Haskell is "math-ey", but I'd argue it's simultaneously a bit misleading and also a bit boring. The part that's misleading is "Haskell is based on category theory": while a major feature of programming in Haskell (the monad abstraction) was inspired by category theory, the truth is that moment-to-moment programming in Haskell doesn't have much to do with category theory unless you want it to. Even monads require zero knowledge of category theory in order to understand or use! Some people find usefulness in category-theoretic abstractions, but many others—myself included!—don't at all: I've actually improved the performance of Haskell code in the past by cutting out category-theoretic abstractions in favor of simpler code, and by now I steer clear of most Haskell code that wears category theory on its sleeve.

The part that's boring is that "Haskell is based on lambda calculus". The lambda calculus is a mathematical description of a simplified model of computation with functions and binding… and that's basically it. Almost every modern programming language uses variable binding as a basic feature, and in that sense, is "based on lambda calculus". Plenty of other languages, for example, are inspired deeply by Lisps (like JavaScript or Ruby) which in turn were directly inspired by the lambda calculus, but I don't think that lineage makes them particularly math-like. Instead, being "based on lambda calculus" usually just means that they have variables and closures—something true of almost every popular language used today!

Now, Haskell-as-practiced can have a fair bit of math-inspired abstraction in it, which can be daunting to someone new to Haskell. Some of that abstraction is useful (e.g. monads), some of it isn't, but the fact that it exists is more about vocal Haskell programmers and bloggers, and much less about Haskell-the-language being "heavily founded on mathematical theories". And you'll also find plenty of programmers and bloggers arguing against the more math-heavy parts of the ecosystem: just in the past month I've seen plenty of Haskell programmers passing around links like https://www.simplehaskell.org/ which advocates for exactly this less-mathy approach to Haskell.

the_duke• 7 years ago

The big problem here is documentation.

Most beginner Haskell resources go into complicated monad explanations very early on, instead of just showing how to use them like a tool. Intermediate resources are even worse.

bawolff4• 7 years ago

I disagree about all computer languages being about lambda calculus. Lambda calculus is fundamentally about functions being first class objects (as opposed to say sets, if we are taking a math prespective). Well that has become a more popular language feature, plenty of languages do not support this. C being an obvious answer.

I'm not a haskell programmer, but I agree with you on the math aspect being largely over excited bloggers. Sometimes i feel like half the haskell articles posted here are taking some simple concept, wrapping it up in heavy duty mathematical machinery, not using the machinery for anything, and then proclaiming profound insight. The other week there was a haskell article on hn literally talking about how great it is that strings form a semigroup under concatenation, because i guess nobody realized you could concat strings before that.

leshow6• 7 years ago

Just like to point out that you don't need to know category theory to program Haskell. You don't need to read or watch Bartosz' videos to program (though they are great fun to watch), that part in the blog is a bit specious.

LYAH isn't a great pedagogical resource. I recommend the Haskell First Principles book. It's long but rewarding and has frequent questions.

axilmar• 7 years ago

Too much drama for no reason. Haskell is a programming language; it has some neat features, and some downsides. If it's the right tool for the job at hand, use it, otherwise use something else.

Courting Haskell

Related Stories