4 ms·

I love Haskell and appreciate its abstraction power. But recently I started to think that one of the reasons that prevent it from becoming more popular is that

I love Haskell and appreciate its abstraction power. 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. Almost every abstraction becomes a mathematical one. "Oh, this thing turns out to be a Monoid! Let me abstract it." "Oh, I can simplify this using Traversal", etc. They usually make perfect sense and useful abstractions, but at the same time they scare many programmers away. Especially non-math-savvy programmers will be easily turned away when they see code that is heavily abstracted in a mathematical manner. I also come from Lisp and Lisp focuses on building a language using the terms/concepts from the given problem domain. And when you do it right, it makes the code very natural in that specific problem domain and any domain experts can understand the code easily. Haskell communities do it very differently by making everything a mathematical problem, and it's only math experts who feel comfortable with the code.

thinkharderdev 6y ago
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 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.
ghj 6y ago
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.
- contravariant 6y ago
  I'm confused, with the right data structure concatenating lists is an O(1) operation.
  - ghj 6y ago
    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 https://en.wikipedia.org/wiki/Persistent_data_structure [2] http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/Data-FingerTree.html#v:-62--60- http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/D... [3] https://stackoverflow.com/questions/28406512/why-does-concatenation-of-lists-take-on https://stackoverflow.com/questions/28406512/why-does-concat...
    - leafboi 6y ago
      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.
      - leafboi 6y ago
        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.
    - contravariant 6y ago
      You don't need a linked list you can just store C as 'A + B'.
agumonkey 6y ago
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.
codygman 6y ago
> 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
codygman 6y ago
> "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.

thinkharderdev 6y ago

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

ghj 6y ago

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.

contravariant 6y ago
I'm confused, with the right data structure concatenating lists is an O(1) operation.
- ghj 6y ago
  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 https://en.wikipedia.org/wiki/Persistent_data_structure [2] http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/Data-FingerTree.html#v:-62--60- http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/D... [3] https://stackoverflow.com/questions/28406512/why-does-concatenation-of-lists-take-on https://stackoverflow.com/questions/28406512/why-does-concat...
  - leafboi 6y ago
    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.
    - leafboi 6y ago
      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.
  - contravariant 6y ago
    You don't need a linked list you can just store C as 'A + B'.

agumonkey 6y ago

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.

codygman 6y ago

> 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

codygman 6y ago

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