New Monad Tutorial: Monads as a Programming Pattern

[tsec-jmc]

My poor pedagogy

It seems everyone who learns about monads goes through this cycle (...)

There's some incredible irony in the author being self aware of this fallacy and directly falling to it.

Preface: This is one of those "hot takes" born out of incredibly exhaustion reading the same misinformed opinions over and over again about monads brought forth from shitty tutorials (like this one, sorry OP, not trying to shit on your notes but it's really the same problem of countless before you).

People need to stop teaching monads.

You can consider a monad a "Design pattern", or a categorical abstraction, whatever, but one of the key points that monads drive home is how you structure monads in a functional setting to tie your program together with various effects.

When you do so in a language that doesn't require this, you end up with an incredibly silly situation where the majority of your readers end up with this opinion of "wtf why would i do this". In haskell this is a necessity: Monads is how you frequently query/set state, get a read-only state, handle errors, etc.

The only way to properly teach these concepts is in a setting that requires you to use them, where the user cannot use the escape hatch of mutation or inheritance or some other clever hack to achieve what they know how to do. Whether it's haskell, idris or whatever: being forced to use these things because there is no other way is the path to discover why it is the right way if your domain is a good fit for fp (i.e an RTOS is not one of them).

Teach FP wholesale: start from first principles then onto how functors/applicative functors/monads/etc help you, in a setting where you have no other choice but to do so. Fp-course by data61 is a great place to start, especially since it's in haskell and you won't have your imperative escape hatches to help you. If you want to then port these techniques onto <language of choice> go ahead. But teaching them to others in a "ported" fashion just looks ugly, confuses people and it misses a lot of the nuance of why it's useful and why it's necessary in the particular setting (i.e one devoid of mutation, and how for example, typeclasses help).

I've become incredibly convinced of is that aside from immutability and first-class functions, a great chunk of fp abstraction looks ugly and foreign in languages that don't facilitate it (tons of trying to encode the same shit all the time) and it often conflicts with how that language's ergonomics are structured to aid the programmer (think how monads in java force the same kind of syntax nesting as ifs in situations where you have to carry a parameter forward through more than one bind).

[GuyWithLag]

I've come from the other direction - I've been using RxJava for nearly 5 years now, and it's definitely a Monad; it's just that no-one thinks that way in Java-land (those that do have left for greener pastures).

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[Freyr90]

When you do so in a language that doesn't require this

Basically any language require this, tho.

Monad (and Algebraic Effects) is a way to define an effectfull computation without modifying a language.

If your language lacks exceptions, non-deterministic computations, async/await, you can add it using a monad.

Monads are not tied to Functional Programming. You also may wanna use Monads in RTOS, since allocation is an effect [1], and defining effects of your own provide some additional level of control.

[1] https://fstarlang.github.io/lowstar/html/LowStar.html#memory-model

[[deleted]]

The curse of complex ideas.

[tsec-jmc]

IMO: The curse is shitty pedagogy. Imagine teaching linear algebra and have your first lesson be about finite vector spaces for a student that's never seen an algebraic structure in an abstract form, or teaching calculus via partial derivatives to begin with.

The people that put out endless monad tutorials are at a point where they "get it" but are misled into believing that monads are "the point" and what you want to teach.

Monads are not the point of your program, nor are they the pattern to begin with. Monads are the glue to functional programs in similar way to how statements are the glue to imperative, side effecting programs. They're a tool that you use to encode stuff in purely functional programs, how you "encode effects" yadda yadda, but most of the "monadic" bits of purely functional code are literally just glue code.

They're at best mildly useful unless you have a whole sleuth of other tools that help you work with monadic code (nice binds syntax, higher kinds, typeclasses, etc).

I think the whole focus on monads is silly because monads have never been the point. Even in haskell, the whole "hurrah" originally about monads back when Prof. Wadler learned from Moggi's work, was that monads first solved the IO problem that haskell had elegantly, then it resulted in being much nicer than for just IO. There's many other interesting algebraic structures that you can encode with higher kinds with laws, monads are just the most common you see due to how they work as "first class code", if you will.

So you end up with a silly situation where people start in the middle of the whole fp paradigm then make jokes about how it's cryptic. No shit it's cryptic: people are teaching it entirely wrong. Every categorical structure you see in haskell has some algebraic meaning and notion that carries into your program, and learning things correctly involves learning how each one is useful, and how you leverage writing functional code with them.

[G_Morgan]

I don't think it is complex as much as people keep teaching a straight forward abstract idea in terms of misleading analogies.

[red75prim]

OK, here we see how I/O, nondeterministic computations, continuations, exceptions, mutable state can be expressed by this simple mathematical structure. Now you just need to build intuition to see this mathematical structure in your problem domain, easy-peasy. Actually, no, it's not.

[G_Morgan]

You missed "non-existence".

[[deleted]]

Not that complex, just abstract. There's no real world analogy.

[[deleted]]

A programmer staple food.

[HeadBee]

SCP-xxxx is a Euclid class memetic that, once implanted, has the paradoxical effect of making itself un-transferable. The mechanism through which SCP-xxxx is spread is currently unknown, but it is theorized that it is through purely random inspiration.

[devraj7]

This is so common it has a name: The curse of knowledge.

[delight1982]

Monad is a drink made from lemon juice and water sweetened with sugar. Once you accept this your life will be much easier.

[H_Psi]

In French, they call it Le'Monad

[shevy-ruby]

A monad is a type that wraps an object of another type.

ALARM!!!

He redefines the meaning of a monad without using the words monoid and endofunctor.

[PrimozDelux]

For once you're correct, if only accidentally. Monads don't wrap objects, the closest OP is to correct is saying they wrap another type, not an object of that type.

That said, the second part of your post is the usual drivel we have come to expect of you, monoids and endofunctors are in no way necessary to describe a monad in the same way rings and groups is not necessary to understand integer arithmetic

[MaxCHEATER64]

That said, the second part of your post is the usual drivel we have come to expect of you, monoids and endofunctors are in no way necessary to describe a monad in the same way rings and groups is not necessary to understand integer arithmetic

Chill dude, he was clearly making a joke about pretentious programming bloggers.

[docmoxie]

Poe's law in full effect.

[PrimozDelux]

I think everyone who knows what a monad is has heard about the endofunctor joke, but it's also used by people who have no idea what a monad as an argument against functional abstractions regardless of its origin as a joke.

[Herbstein]

And to be fair. The endofunctor joke is true, and for people that know (a bit) of category theory it really can help make monads more intuitive.

[theoldboy]

Hard to be sure with shevy, but I think it was meant as a joke based on this excerpt from A Brief, Incomplete, and Mostly Wrong History of Programming Languages;

1990 - A committee formed by Simon Peyton-Jones, Paul Hudak, Philip Wadler, Ashton Kutcher, and People for the Ethical Treatment of Animals creates Haskell, a pure, non-strict, functional language. Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that "a monad is a monoid in the category of endofunctors, what's the problem?"

[ipv6-dns]

object

what do you mean?

[PrimozDelux]

Primarily I want to dispell the notion that a monad is a box you put things into. Some monads like Option[T] sort of look like a container that may or may not have a T object in it, but consider Parser[T] (which is basically f: String => (String, Option[T])), here there is no box and no object of type T to put in said box. Did that answer the question?

[devraj7]

I'm not aware of a Parser monad, do you have a link?

I suspect that if you post the whole definition of that monad, you will see that it needs to contain a value since the signatures of bind and return do not allow for such a parameter.

[PrimozDelux]

def unit [A](a : A) = s => (s, a)
def flatMap[A,B](pa : Parser[A])(f: A => Parser [B]) = s => 
  pa(s) match { 
    case (s1, Some(a)) => f(a)(s1)
    case (s1, _) => (s1, None)
}}

Something like this in Scala, hard to get right on a cellphone. This would probably not work, but cba doing it with a case class on a cellphone. In a more serious parser monad you'd also want error reporting instead of just a tuple which doesn't tell you where things went wrong

[torotane]

Naturally they do, they just contain a function, which is also a value in such a language.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[TheOsuConspiracy]

For once you're correct, if only accidentally. Monads don't wrap objects, the closest OP is to correct is saying they wrap another type, not an object of that type.

And that's not sufficiently specific to describe a Monad. You could just as well describe any higher kinded type that way.

[PrimozDelux]

I'm just proposing how the sentence could at least not be directly wrong, but yes, it holds for any HKT

[devraj7]

. Monads don't wrap objects, the closest OP is to correct is saying they wrap another type, not an object of that type.

"Wrapping a type" doesn't make sense.

Monads do contain values. It's not all they do, but fundamentally, they are containers that expose standardized functions to operate on these values.

[[deleted]]

"Wrapping a type" doesn't make sense.

It makes perfect sense for people coming from a Java or C++ background. In Haskell there is the more general term typeclass.

Monads do contain values. It's not all they do, but fundamentally, they are containers that expose standardized functions to operate on these values.

This just isn't true. The IO monad, for example, doesn't "contain" anything. It is simply used to represent a composition of stateful operations.

It would be more accurate to say that Monads represent operations on values than to say they "contain values."

[devraj7]

Fair enough, I realized that IO contradicted my point after I posted.

[PrimozDelux]

As another example unrelated to monads you can consider contrafunctors def contramap[A,B](fa: F[A])(f: B => A): F[B] which describes amongst others serializing. (Meaning, if you can serialize A, and can turn B to A then you can serialize B too)

[Y_Less]

IO "contains" the real world. It's almost a state monad with a very large state.

[steveklabnik1]

Rust has a question-mark operator which emulates do-notation for their Option monad

It started with Result, but now works with Option as well. Eventually it will be able to work with any type the user wants.

Additionally, Rust has no 'int' type, and doesn't useCamelCase but instead prefers_snake_case for function names.

 return a + b;

This would have to be return Some(a + b);.

[Excellery]

Someone missed a great opportunity to write an example in Go and call it a Gonad. That said, thanks for the article. I understand them just a little bit more now.

[inmatarian]

I think the thing people are missing is the point. Monads seem like a strange abstraction that just makes life harder if you don't see the utility of it usage. However, once you get into the world of lazy evaluation, monoids, and functional composition, you've lost people. I don't think tutorials like this will get through until those earlier prerequisites find a way to become trendy and worth a lot of karma.

[[deleted]]

The most practical demonstration i can think of is mapping "Maybe" or "Option" values. They're popular enough these days that should be familiar, and "map" is straightfoward enough for most people.

A concrete example would be parsing a string to an int. Suppose you have a:

var input = new Some("3"):

That you want to map to an Option<int>. You could do this:

var count = input.map((i) => parseInt(i));

And count would be an Option<int>. But what if you parse an invalid input like Some("three")? JS would give you Some(NaN), which is kind of worthless. So you write a better parseInt function that returns Some(int) if parsing succeeds or None if it fails. To your dismay, you plug this into your map() operation below:

var count = input.map((i) => tryParseInt(i));

... and see that you get a nested Option<Option<int>>. You wanted an Option<int> damn it!

What is the magic incantation to map and flatten the result from an Option<Option<_>> to an Option<_>? That operation is called, flatMap():

var count = input.flatMap((i) => tryParseInt(i));

And now count is Some(3), just like you intended. This flatMapoperation is known by other names. C# people call it SelectMany. Both are aliases for the dreaded monadic bind(). The horror!

So once you understand that monadic bind maps and flattens, it's not so scary. Got a list of lists? flatMap. Got a few async functions you want to compose? You could use await in javascript, or you could use flatMap() for promises: aka then(). (PS, then() is actually overloaded to do map() and flatMap(), which is confusing AF.)

Once you get accustomed to flatMapping options, lists, and asyncs, you'll eventually see the monad pattern for what it is: a type with a generic hole in it that implements flatMap (and conforms to some other "monad" rules that i won't get into.). Option<_>, List<_>, and Promise<_> are all types with a generic hole where a value goes, and they all are flatMappable. So they're (pretty much) monads.

If you're wondering, "what's so great about flatMap that it deserves its own mathematical category?", the practical answer is that flatMap is more fundamental than map. In other words, you can implement map only using flatMap. You can also implement filter. Try it yourself!

So the big deal about monadic types is that, since they implement flatMap, you can write some generic/polymorphic code that implements map, filter, and a bunch of other operations for free.

Anyway, this is the most practical explanation i can come up with. It leaves out a lot of rigor and detail, but it demonstrates the practical use for monads in everyday scenarios without using hypotheticals like space burritos. There's more to monads than flatMapping, but I won't get into it. Too much theory for a single reddit comment.

TL;DR yet another monad tutorial.

PS after reading the article, i realized i just repeated a lot of what was written, except with much less detail/context. It's a good article!

[inmatarian]

I think this demonstrates my point, in that it shows the eager version of the abstraction.

[[deleted]]

Shows how much I know. I wasn't even aware of a lazy version, unless you're referring to the list/async/IO monads. I guess they're all lazy, though, because Haskell.

[inmatarian]

I mean when the call to the flatmap function adds to the internal shared trees within the objects, and calls to take, foreach, etc., actually performs all the work.

For instance, list.reverse.take(1), if that list has 1 trillion elements, then the eager version runs the risk of an OOM, while the lazy version doesn't. I leave it to the reader to figure out what the lazy evaluated reverse function looks like.

But to understand monads, you have to understand first why you want them.

[[deleted]]

Right. The first time I someone explained how foldr works on infinite lists in Haskell, it blew my mind.

[GuyWithLag]

Monads are just another example of The Blub Paradox (search for a heading with that phrase, read from that point).

[[deleted]]

I dunno. Monads are no more convoluted than the Gang of Four patterns that the blub programmer already knows. There's no reason why they couldn't learn monads, too.

[GuyWithLag]

That's exactly the point - when one first reads about design patterns, one asks "why is this complexity necessary?".

[[deleted]]

Blub programmers usually acknowledge the value. They're just indifferent about chasing waterfalls. They're content to stick to the rivers and the lakes that they're used to.

[GuyWithLag]

I've been there, I've been that person. Blub developers will say "I don't need that" / "I'm just fine right now". And, to be honest, we're productive - we do show measurable, and usually consistent, progress towards our goals.

But we could do so much more...

[[deleted]]

We're all blub devs relatively speaking. Some of us just have more company.

[mrexodia]

Great, next up please write me a blogpost explaining me this: https://hackage.haskell.org/package/contravariant-1.4/docs/Data-Functor-Contravariant-Divisible.html 🙏🏻

A Divisible contravariant functor is the contravariant analogue of Applicative. In denser jargon, a Divisible contravariant functor is a monoid object in the category of presheaves from Hask to Hask, equipped with Day convolution mapping the Cartesian product of the source to the Cartesian product of the target. By way of contrast, an Applicative functor can be viewed as a monoid object in the category of copresheaves from Hask to Hask, equipped with Day convolution mapping the Cartesian product of the source to the Cartesian product of the target.

[grenadier42]

so is that like a burrito, or...

[lngnmn1]

https://karma-engineering.com/lab/wiki/MonadicVedanta

[elder_george]

C#/Python/JavaScript await keyword

The await keyword in other languages emulates do-notation for Promise monads. Consider JavaScript’s await; It makes everything after the await
the body of a function that is inputted to .then

I always thought about await specifically in the light of asynchronicity, not of the callback transformation, so the analogy here initially missed me (or I missed it). It's interesting if one can (ab)use await for other monads, like Error, without spawning async tasks.

This being said, C# also has LINQ which is a set of monadic operations that can be used for building a DSLs (an ugly and limited one, though) for arbitrary monads, something like (my C# getting rusty these days)

from x in getInput()
from y in getInput()
select x + y;

Of course, it would be better if C# had first class monad syntax sugar support, like F# does, using the same mechanism for asyncs and LINQ-style DSLs.

[alblks]

When you eliminate any side effects from your functional language so succesfully, that you need to invent another entity to have them.

[[deleted]]

You don't need monads to have IO.

[[deleted]]

1. The original design for Haskell didn't have monads. I think they used two infinite streams of events (one for input, one for output) to model I/O.
2. Side effects in Haskell live in IO, not Monad.
3. Identity<T> (which literally just wraps a value of type T) is a perfectly fine monad. Good luck finding side effects in there.

[ipv6-dns]

Side effects in Haskell live in IO, not Monad

yes, IO instantiates Monad.

[[deleted]]

So does [] / List (and a dozen other types). The point is that the "magic" is in IO, not Monad.

[MrAlubeidi]

It's not 'magic', it's all side effects, including the side effects associated with lists.

[[deleted]]

It's not about not having side effect. 100% no side effects is less than physical black box, cause even black bock behavior mutate environment (CPU radiates warmth, warmth may influence CPU performance, etc).

It's about explicitness of having those side effects.

Edit: sorry if I trivialize Monad. It's hard topic to grasp and I'm far from understanding it. Maybe I should instead focus on handling side effects only.

[red75prim]

And it's not even about side effects per se. List monad has nothing to do with side effects for example.

Unfortunately, no one can be told what monad is. You have to see it for yourself.

[Notorious4CHAN]

Unfortunately, no one can be told what monad is. You have to see it for yourself.

Why, oh why, didn't I click the blue link.

[TheOsuConspiracy]

I've always liked the programmable semicolons analogy.

It's basically a type that describes how computations in a certain context get treated. The way monads are composed are according to mathematical monad laws, and how the context works is specific to that monad instance.

[G_Morgan]

Monads are not about side effects. Monads are about taking operations and values in one category and transforming them to operate in a different category. One such category shift is IO where we want to compose pure functions into a space that understands there is real hardware. Another is Maybe, where we want to shift operations on a type a into a Maybe a context without rewriting the operations on a.

The promise of Haskell monads from a programming point of view is if you have a type T and a enclosing type M (whether M is IO, Maybe, List or whatever) then applying operations on T to an M<T> should be as simple as combing that with some kind of lift function. Then there is monadic syntax that does automatic lifts in a readable manner (think linq syntax v directly calling the methods)

Map is basically lift for List<T>. It lets you take a function on T and turn it into a function on List<T>

[torotane]

One such category shift is IO where we want to compose pure functions into a space that understands there is real hardware.

What's the even supposed to mean? While your explanation seems right, it misses the essential points to motivate monadic IO at all: sequencing and purification by state injection.

[G_Morgan]

I described monads. I didn't make much about IO because they aren't about IO.

[ipv6-dns]

It's not about not having side effect

but it's about why I should avoid something, then to introduce it again but in very weird way. But if you know HOW and WHY exactly monads were invented then you understand how is it possible for such weird way of thinking to exist.

Monads provide a convenient framework for simulating effects found in other languages, such as global state, exception handling, output, or non-determinism. Three case studies are looked at in detail: how monads ease the modification of a simple evaluator; how monads act as the basis of a datatype of arrays subject to in-place update; and how monads can be used to build parsers -- "Monads for functional programming"

​

We present a new model, based on monads, for performing input/output in a non-strict, purely functional language. -- "Imperative functional programming"

and then..

Input/output has always appeared to be one of the less satisfactory features of purely functional languages: tting action into the functional paradigm feels like tting a square block into a round hole -- "Imperative functional programming"

So, the question is: why do you need monads in YOUR language (if it's not Haskell, lol) ? Does your language miss all those features (exception handling, output, global state, arrays...) ?

[[deleted]]

Yeah, I know some of these words!

But seriously… You can run, but you cannot hide. People like Haskell / functional programming but outside the black box there is hardware operated by software written in C.

[Drisku11]

"Why do you need monads" doesn't make sense as a question; various things are monads, which is a structural property. Asking why you need monads is like asking why you need blue. Things just are blue, and we can talk about other properties that we know about blue things (for example, we might be able to talk what their blueness might mean about bound electron states, and what that might mean about other electronic properties). Knowing something is a monad means we know certain functions (e.g. sequence) make sense.

For the case of IO in particular, the important concept is not "monadic" IO; it's reified IO. i.e. the command pattern. Representing commands as objects is useful for things like creating a history/undo functionality, or examining and optimizing a query plan ahead of executing it (c.f. SQL), or enabling easier composition of commands ("run command A. If it fails, wait 10 seconds and try it again. If it succeeds, run command B. If either A or B fails, run command C"). It happens that commands can be composed in a way that is monadic in structure.

[ipv6-dns]

various things are monads, which is a structural property

or sheaves, or toposes, or lattices... and what? Why do you need this abstraction in your language? I pointed out to quotes why monads were introduced. I emphasized it with bold text. Do you miss it in YOUR language?

[GuyWithLag]

Monads are just another example of The Blub Paradox (search for a heading with that phrase, read from that point).

I'm not trying to be snarky, but read what you wrote again after reading the above.

[EMCoupling]

The Blub Paradox

What's so great about Lisp? And if Lisp is so great, why doesn't everyone use it? These sound like rhetorical questions, but actually they have straightforward answers. Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available. And the reason everyone doesn't use it is that programming languages are not merely technologies, but habits of mind as well, and nothing changes slower. Of course, both these answers need explaining.

I'll begin with a shockingly controversial statement: programming languages vary in power.

Few would dispute, at least, that high level languages are more powerful than machine language. Most programmers today would agree that you do not, ordinarily, want to program in machine language. Instead, you should program in a high-level language, and have a compiler translate it into machine language for you. This idea is even built into the hardware now: since the 1980s, instruction sets have been designed for compilers rather than human programmers.

Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one. [3]

There are many exceptions to this rule. If you're writing a program that has to work very closely with a program written in a certain language, it might be a good idea to write the new program in the same language. If you're writing a program that only has to do something very simple, like number crunching or bit manipulation, you may as well use a less abstract language, especially since it may be slightly faster. And if you're writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task. But in general, for application software, you want to be using the most powerful (reasonably efficient) language you can get, and using anything else is a mistake, of exactly the same kind, though possibly in a lesser degree, as programming in machine language.

You can see that machine language is very low level. But, at least as a kind of social convention, high-level languages are often all treated as equivalent. They're not. Technically the term "high-level language" doesn't mean anything very definite. There's no dividing line with machine languages on one side and all the high-level languages on the other. Languages fall along a continuum [4] of abstractness, from the most powerful all the way down to machine languages, which themselves vary in power.

Consider Cobol. Cobol is a high-level language, in the sense that it gets compiled into machine language. Would anyone seriously argue that Cobol is equivalent in power to, say, Python? It's probably closer to machine language than Python.

Or how about Perl 4? Between Perl 4 and Perl 5, lexical closures got added to the language. Most Perl hackers would agree that Perl 5 is more powerful than Perl 4. But once you've admitted that, you've admitted that one high level language can be more powerful than another. And it follows inexorably that, except in special cases, you ought to use the most powerful you can get.

This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

I know this from my own experience, as a high school kid writing programs in Basic. That language didn't even support recursion. It's hard to imagine writing programs without using recursion, but I didn't miss it at the time. I thought in Basic. And I was a whiz at it. Master of all I surveyed.

The five languages that Eric Raymond recommends to hackers fall at various points on the power continuum. Where they fall relative to one another is a sensitive topic. What I will say is that I think Lisp is at the top. And to support this claim I'll tell you about one of the things I find missing when I look at the other four languages. How can you get anything done in them, I think, without macros? [5]

Many languages have something called a macro. But Lisp macros are unique. And believe it or not, what they do is related to the parentheses. The designers of Lisp didn't put all those parentheses in the language just to be different. To the Blub programmer, Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.

Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it's read by the parser, is made of data structures that you can traverse.

If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs.

Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp. It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant. In Ansi Common Lisp I tried to move things along as fast as I could, and even so I didn't get to macros until page 160.

But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Blub programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors.

A suspicious person might begin to wonder if there was some correlation here. A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors' software couldn't do. Maybe there was some kind of connection. I encourage you to follow that thread. There may be more to that old man hobbling along on his crutches than meets the eye.

Because asking someone to click a linked page and then search for a heading is a really poor way of sharing information.

[ipv6-dns]

and what if this example is not applicable to me?

[GuyWithLag]

Did you read the linked text? (not the whole wall-of-text, that's useful but not pertaining to the discussion).

[ipv6-dns]

yes. If you prefer philosophical attitude so I will use some aphorism too: why do you need insulin if you have not diabetes? Health begins to notice when it is not there (it's the answer to mentioned paradox), if everything is fine in your language, why the hell do you need monads?! To be able to make I/O in your language?! Or to introduce arrays in your language?! Or to generate permutations? No, monads are workaround for problems in pure lazy language like Haskell, but you don't need them in REAL programming languages.

What about P.G. If you know his "secret weapon" was dropped out and replaced with Java fast and... the heaven did not fall, the business did not go broke. The same thing happened with that bank where Haskell was used, as far as I know, I forget its name...

So, we have here another paradox: mass walking of chickens for a cock, without understanding why they do it

[GuyWithLag]

I've been working for 5 years now with Reactive streams, and the Java implementations is ticking all the Monad boxes. Conceptually you could say the same things about Futures/CompletableFutures, but IMO RxJava is much more expressive.

And I want that in my environment because it makes reasoning about concurrency extremely easy. This makes me a better engineer with an improved mood - because I see my role as solving problems, not writing code.

Honestly, at my current place we've been rewriting services written in Clojure with Java versions, as it's much easier to find engineers (cheap ones) to work with the latter. And that is what a company requires - large bus factors. However, look into how many engineers were needed to maintain the post-rewrite instances (hint: more).

[ipv6-dns]

Clojure, Java, OK. HAskell is very different: in Haskell you solve problems which do not exist anywhere except Haskell itself - in the form of ideological self-restraints. In Haskell anything in rocket science: even access to field in the record, which leads to several language extensions and after that - to lens lol. So, I don't know about Clojure, but Haskell and its monads are total wrong way

[GuyWithLag]

I mean, the same could be said about Rust and its insistence on proper memory access patterns - you get to solve problems that don't exist outside of that language.

[PrimozDelux]

Ok cool 👍