Note: Before I possibly get railed for not knowing functional programming or anything like that, I actually really like functional programming, for a limited set of applications (mostly compilers, and other algorithm heavy stuff).

> What about good code that ships? Best of both worlds.

Right, but what is good code?

The author of this page claims that code out of the "Algebra-Driven Design" paradigm is good code. But where's the proof?

It's not enough to pull out the math textbook and give us fancy words like monoids, lattices, whatever (this is coming from someone who loved algebra classes far more than analysis classes in my math degree).

I'd really like to see real world code that uses this. And by real world code, I mean code that isn't some contrived example, code that actually runs somewhere, and provides real-world value, e.g, a semi-popular website, e.g HN, Lobsters, Reddit, or something that runs on a robot, or something. I don't know. The common theme of all of these Haskell/Idris/SomeOtherMathyLanguage posts is that almost none of them bring any real world software to the table, that has been tried and tested by the real world, e.g, consumers, customers, whatever, except for a perhaps GHC, a handful of well maintained Haskell libraries, the Idris compilers, that Haskell spam filter at Facebook.

We keep saying that functional programming is much better than any other paradigm. But the share of functional programming languages is tiny in comparison with the imperative/OO family languages, and there's a reason for that. Most functional languages are hard to use, have very little library support, and functional abstractions don't _really_ matter in the long run when it comes to bugs. Sure, C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think.

I just find it absurd that on these functional programming posts, everyone just keeps saying that the only good code is functional code. It's simply not the case.

> C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think.

My argument that it has nothing to do with object oriented mapping to the way most programmers think, and is almost totally a function of familiarity.

Facebook rewrote the Messenger in ReasonML. Before they got hundreds of bugreports a year. Afterwards? Less then ten.

I worked on a 6 month rewrite of the core of a system. Critical bugs were drastically reduced. We rewrote in the same language.

I would much rather use ReasonML than js but the Facebook result unfortunately doesn't prove much.

Monoids: Map-Reduce and Hadoop

Monads: future chains, streams/sequences

Immutable data structures: the transaction log for distributed databases

Very good point. A lot of the bad code I have seen doesn't ship _because_ it is bad. It can't even get through the testing phase because it is full of crashes type thing. Whereas good code usually has a good design that results in _less_ code and development speeds up as you go on. So the end of the project feels like putting cherries on top of a cake instead of trying to balance cherries on stilts.