Comment by lliamander | Hacker News Reader

Comment by lliamander | Hacker News Reader

Parent Full thread

Abstract algebra is certainly abstract, but it is far from "metaphysical bullshit". Abstract algebra is just the precise articulation of patterns that we see across different mathematical formalisms.

Now, the fact that it is so abstract does mean that your average programmer won't use it on a day to day basis. I'm certainly not going to argue that it is the most important math to understand. However, we are finding that there is uses for it. Not just in a "oh look, I can describe my code using abstract algebra, nifty" sort of way, but in a "knowing this was essential to finding the correct solution" sort of way.

For instance, the folks working on .NET's LINQ knew they were implementing monadic comprehensions; they just had the good taste to not use the word "monad".

Furthermore, it seems that having an understanding of abstract algebra is essential to making a distributed real-time analytics engine[0] [0]https://www.infoq.com/presentations/abstract-algebra-analyti...

Oh, monads.. sooner or later they will be mentioned.) Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increases confusion.

Monads make no sense in a non-lazy language.

http://karma-engineering.com/lab/wiki/Monads2

> Oh, monads.. sooner or later they will be mentioned.

Yep, monads :).

> Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increases confusion.

I intentionally brought them up with a concrete, real-world example where they were useful.

> Monads make no sense in a non-lazy language.

A more accurate statement might be "monads make no sense in a non-lazy evaluation context". There are plenty of cases when working in an otherwise strict language you will compose a series of computations over a lazy data-source. For example: you want to process a potentially large series of rows coming from a database without blowing through RAM.

You can solve this problem on an ad-hoc basis, but as far as I understand it, the folks working on LINQ wanted to develop a declarative, readable, sql-like syntax for creating/composing such computations in a way that would work generically across data-sources. The question is, what is the pattern of operations and constraints that is common to all of the disparate data-sources that can be used in this way? The monadic functions + monadic laws is a precise (if arcane) description of those operations and constraints.

Using monads is not the only way to structure computation in the context of lazy evaluation, but it is one that is relatively well understood and worked well with the goal of being "sql-like" because SQL queries can be modeled as monadic computations.

That blog post is a mean-spirited rant and mostly lacking in substantial argument.

Reply on news.ycombinator.com