Hacker News Reader

I'm not sure the Haskell community really wants the language to become more popular as a primary goal. Sure, it would be great if more people appreciated its power and adopted it, but not if it requires compromising on its core strength: rigorous correctness. And that's fine! Not every language needs to focus world domination. It's probably better that we have a lot of niche languages that are uncompromising and highly optimized for specific types of problems (or rather highly optimized for certain types of programmers). Also, you don't need to be mathematician or really be grounded in math at all to understand the abstractions favored in Haskell. I think https://www.scalawithcats.com/dist/scala-with-cats.html is a really good example of explaining abstractions that are grounded in Category Theory without ever even trying to connect them to their mathematical origins. The abstractions can be explained and applied on their own terms.

> But recently I started to think that one of the reasons that prevent it from becoming more popular is that the community focuses too much on "mathematical" abstractions.

Many times being in the middle of any two extremes is a pretty bad experience.

If you shy away from math though, you get closer to tapping into the average programmers experience in other languages.

Because of that, it's easier and more familiar.

Those things are good for adoption, but not necessarily a Haskell experience that is so good it's clearly better.

I think the direction Sandy goes in does achieve something objectively better.

My advice is to try it out and don't let the "it's too mathy like Haskell always has been" comments bog you down.

Do be prepared to learn a new paradigm and solicit help from others to be able to learn it in a timely manner.

- A Haskell programmer who never made it past algebra

Mathematical abstractions are often at the wrong level of abstraction. Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too.

For example, sure, you can think of a list as a "monoid" where the add operator is concatenation of two list. But adding two lists is not a fast operation even using specialized functional data structures. So making concatenation a primitive for equational reasoning just results in really slow code.

> Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too.

Exactly! The thing is this book gives a method where you care about value semantics, keep the ideal representation, and then care later about how it's realized in the hardware!

I'm confused, with the right data structure concatenating lists is an O(1) operation.

You're probably thinking of storing it as some linked list but that doesn't work with mathematical abstractions (which is my point).

For example in mathematics if you write "C = A + B" and then you ask what A is, it's still always going to be the same.

To make this work in programming you basically have to make all your data structures persistent[1]. AFAIK you would need a store the list as a finger tree or something if you need fast concatenation and that will still only be O(log(n)) [2].

[1] https://en.wikipedia.org/wiki/Persistent_data_structure

[2] http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/D...

[3] https://stackoverflow.com/questions/28406512/why-does-concat...

In math everything is persistent/immutable anyway, so persistent data structures are a given when working with purely mathematical abstractions.

There is a memory issue because of this, but this problem isn't exclusive to FP languages. Many languages solve this with something called garbage collection.

The very definition of pure FP (which is basically just programming founded on the principles of mathematics) rest foundationally on just a program that is immutable and has no side effects. Those are the only two requirements needed to do FP.

Immutability is therefore the axiomatic foundation of FP.

You don't need a linked list you can just store C as 'A + B'.

> "Oh, this thing turns out to be a Monoid! Let me abstract it."

You seem to have an example in mind where this leads to the "making everything a mathematical problem" , can you share it?

> Haskell communities do it very differently by making everything a mathematical problem, and it's only math experts who feel comfortable with the code.

I program in Haskell every day and I have no idea what Haskell code you have in mind.

Also as I've said elsewhere, nearly everyone reading this has more math experience than this Haskell programmer without a degree or calculus class under their belt.

It's a common curse. Lisp has no value for mundane business applications that need to massage some data and bolt a gui to print reports.

The thing is when you start attacking odd problems you can find solid solutions in 100LoC instead of brittle sandcastles made with 27 classes.

Let's let haskellers go wild in their abstractitis, it's great. Sure it's not important for many cases but let them roll.