Functional Programming Is Not What Makes Haskell Great | Hacker News Reader

Functional Programming Is Not What Makes Haskell Great

hackernoon.com

43 pointsruneks16 comments

So the article goes on to mention a few individual features of the language which are good features and would definitely be appreciated by those that have already seriously committed to learning and using it, but are pretty opaque to an outsider.

The real killer feature of Haskell is that it is the closest language to mathematics and makes reasoning mathematically much easier than even other functional languages.

Superficially, the syntax has more similarity to mathematical definitions and statements, the conventions (like single letter variables) are borrowed from mathematics and don't feel ugly or forced. Lack of side effects, composition, currying etc and other functional benefits much more neatly line up with how functions are treated in maths.

Ultimately it's still a programming language, and is used much more for traditional engineering or compsci applications than something like Maple or Mathematica would be in Mathematics research, but nonetheless the main draw of Haskell is that it will feel like a home away from home for mathematicians and not because of 5 features noted in this article.

> The real killer feature of Haskell is that it is the closest language to mathematics and makes reasoning mathematically much easier than even other functional languages.

And the reason is it's like that is its focus on purity.

Is the reason it's easy to reason with mathematically because it was designed to be pure or is it pure because it was designed to be easy to reason with mathematically?

I think the point is that the language has to have a comprehensive runtime if it wants to have a mathematical(-like) notation in its syntax and to be efficient. Implementing such a runtime is a very hard engineering task, and GHC's runtime is the feature that I appreciate equally to its comprehensive type system.

GHC's RTS (and optimizations/codegen too) is really great. I have a b/g in CompE and hardware but I mostly do FP now, so the RTS is the perfect fusion of those two. It's the area to find answers to "how do we efficiently evaluate lambda calculus?"

> that it is the closest language to mathematics and makes reasoning mathematically much easier than even other functional languages

Closer than e.g. Lean?

No, although I don't think you'd try to make a website backend in lean.

> you'd try to make a website backend in lean

Well, I would neither use Haskell for this purpose, and Lean is indeed supposed to also be a "programming language", not only a theorem prover.

That's interesting, I've only ever seen it being used in the context of mathlib.

I think the killer feature is the separation of IO and pure & mutable functions. Pure functions are easy to reason about, easy to test, have predictable performance and are well suited for concurrent applications. IO is crucial for a useful application but it forces you to sacrifice some guarantees.

What I like about Haskell development is that the compiler enforces this separation, so when things misbehave you can just focus on the IO components. I think this would fit well into the paradigm rust had for marking variables as "mutable".

I wonder if that would be possible without types. Maybe some kind of IO decorator, that enforces the separation, to allow for enforced pure functions in an untyped language.

Sounds like an effect system. But I haven't used them either.

Clojure...?

Decorators are just a way to introducing typing via another mechanism.

> Pure functions are easy to reason about, easy to test, have predictable performance and are well suited for concurrent applications.

Predictable performance is a property of a compiler, not a pure function (a language construct).

I like Haskell because of the reasons here already said: it's more like math, so it's easy to reason about, and it's got a lot of cool features that make programming in higher levels of abstraction easy. The downsides are that the tooling is hard to learn at first and it's hard to understand and reason about the compiler because it's so advanced, so you really have to know Haskell well in order to create the most efficient programs. I think strict types and functional style is the future of software, since it's designed for abstractions and today's software is all about abstractions. Security wise, a strict type system with type driven development can be great, limiting the user while giving greater freedoms overall.

Reply on news.ycombinator.com