Hi folks,
I’m glad to present you my talk “Functional Programming: Failed Successfully” from LambdaConf 2024.
The talk is about the system of values that holds functional languages such as Haskell with an iron grip and doesn’t allow them to become more popular in the industry.
In fact, my point is that Haskell has lost its past popularity despite all the good things and changes it has enjoyed in past years.
Feel free to agree/disagree.
(yawns)
Learn you Func Prog on five minute quick! • The Register
Why Dysfunctional Programming Matters
[[pure]] attribute, JTC1.22.32 Programming Language Evolution Working GroupThanks @graninas. I find listening to a talk a time-consuming and ineffective way to find out what you’re saying. Flipping through the slides doesn’t tell me either: that’s what you’re talking about, not what you’re saying.
Have you written up notes or a blog-post somewhere?
I’m not sure I would even agree with your measurement criteria. For example you have “Losers” COBOL 1958, C/C++ 1972/1973 – ?? Wikipedia has C++ “First released in 1985”. Those languages may be old, but I guess even today there’s far more of that code run in production than Haskell. (And then those turn into “Winners” at slide 13. By then I’d given up listening through the talk, so I don’t know why.)
Your survey doesn’t include any language directly in the Algol stream: /68, Pascal, Delphi. In particular, I would think Pascal vintage 1970’s very comparable to Haskell vintage 1990’s with the objective of fighting the ‘Flabby’ of Backus 1978.
Thank you for a thought-provoking presentation. By way of context, I have three personal limitations in taking it in: (1) I’ve been interested in Haskell for only a decade (starting part-way through the ‘era of misbeliefs’, in your historical scheme); (2) I’m only a hobbyist (I don’t have an ‘industry’ or ‘academic’ perspective to draw upon); and (3) my own experience is that people have been generous and patient, as I’ve followed Haskell (clearly your own experiences have differed).
Your presentation is, understandably, an abstraction of your ideas, but I would be interested if you could provide some practical examples to make it more ‘concrete’ for somebody like me. For example, one of your themes is a ‘lack of pragmatism as a perceived community value’ (EDIT: as clarified by @graninas below, that is ‘a lack of’ as in ‘insufficient’ - not ‘a lack of’ as in ‘an absence of’). What do you consider is a good example that embodies that theme?
Yeah. That’s a pretty accurate description of GHC’s Haskell as at today. I was attracted to Haskell ~2010 because it captured the mathematical simplicity of LISP but without all those darned parens; it was at a sweet spot of expressive/elegant/succinct without being too terse or too scary. (Well, OK Monads might be scary, but mostly you could use them and think your were writing procedural code without having to follow all the theory.)
Today not so much. There’s too many scary ways to write stuff. And yet they don’t seem to achieve more than I could achieve already. Perhaps when Dependent Haskell gets to something like complete, it’ll all suddenly become clear.
I’ve got to ~4:30/slide 11/1990’s “correctness and mathematical rigour is what the industry really wanted”.
I was there at the time/commercial programming in COBOL and RPG. At no time did my employers want mathematical rigour: they wanted functionality, and quickly! I don’t see the rise of OOP having much to do with mathematical rigour; it was argued as promoting programmers’ productivity for those new-fangled interactive screen-based systems.
So is your talk just another dissing one programming language/paradigm vs another? Is that why @atravers comments “(yawns)”? Those kind of surveys are just pointless navel-gazing unless you identify which industry sector you’re talking about, and what particular application. Some languages are ‘better’ for some purposes, for some definition of ‘better’. Yeah yawn.
Hi, I didn’t get the idea of this list, but thanks! It’s not a bad company to be listed with.
Hi AntC2,
I haven’t. But maybe I’ll do it soon.
Well actually, this is the only way to understand what I’m really saying. Judging from the slides may not work, as it didn’t here. You didn’t get the point of the intro. I was telling a story that is intentionally fake. Once I finished telling this story, I said “we all understand this story is fake, and everything was quite the opposite”. The slides also confirm this: it’s not that FP languages are winners, they are actually losers. You interpreted the first slides incorrectly. In this regard, imperative languages are not losers.
Again, “correctness and mathematical rigor is what the industry really wanted” is a line from the initial fake story. Didn’t you notice my tone and intonation? It was made pretentious not by chance. Of course, OOP doesn’t have mathematical rigor. There is no such point in the talk.
Of course not. Again, I’m explicitly stating in the talk that I love all the paradigms, languages and approaches. So your interpretation is not fully correct, – I believe because of your way of watching it. But anyway, thanks.
Thanks!
I think I need some time to collect the things. Let me answer in a while (it’s very late in Dubai already)
Thank you for the clarification. What I noticed about your tone is that you’re not a native speaker of English. In any case, sarcastic/parodic/intentionally fake is very difficult to deliver effectively over the very narrow communication channel of online videos. Notably, AIs are terrible at it.
[**Poe's law**](https://en.wikipedia.org/wiki/Poe%27s_law) is an adage of Internet culture which says that, without a clear indicator of the author's intent, any parodic or sarcastic expression of extreme views can be mistaken by some readers for a sincere expression of those views.
If the story is ‘conventional wisdom’ or a commonly-believed ‘Just-so story’, it might be worth briefly recapping it, so your audience is all on the same page. But if you expect your audience already “all understand” it’s a fake, you’re just wasting your breath and their time. Myth-busting is maybe a way into a more nuanced understanding; but inventing a myth out of nowhere for the sole purpose of immediately busting it is just confusing.
Did you notice your audience’s glazed-over faces? Oh, no it wasn’t a face-to-face talk.
Heh heh! Thanks for ‘Teedy Deigh’, the 2021 ‘<script>’ is quite funny. The Dysfunctional piece took a while to warm up. (Playing with dictionary definitions of ‘functional’/any everyday word used in a specialist sense is just too soft a target to be humorous.) " the qualities the conditional operator can bring to a codebase when employed extensively and without mercy." is good.
There seems to be a problem with the YT recording - in the Q&A part (from 32:40 onwards) the questions you answer cannot be heard, so listeners will have to guess what they were.
Considering just how much you have espoused the virtues of pragmatism:
I would also be interested in such an example, because it still seems to me that:
So an example which avoids such drastic changes would be quite useful.
Yeah, that article appeared in some I/O-related search results - I like Haskell, but I also have a sense of humour:
That article is also ironic…
Hi Alexander, I’ve figured out why I had such difficulty getting to grips with your talk.
There’s a long-standing bit of wisdom about attracting and keeping an audience’s attention:
"Tell the audience what you're going to say, say it; then tell them what you've said." — Dale Carnegie[from: How to Open a Presentation: Tell 'Em What You're Going to Say
opinions on the interwebs vary as to who first said that. Maybe Aristotle’s ‘Art of Rhetoric’; maybe Jesuits teaching priests how to give persuasive sermons; …]
Your presentation started with “I’m going to tell you a story …”. So I had no idea whether the story was aimed at me/whether what you were going to say would resonate with my programming experience.
And if I might say so, your books also suffer from that lack of framing: who should read this book? Why?/what’s in it for me?
The book is intended for any developer who wants to sharpen their software design skills.[from early in your ‘Functional Design and Architecture’]
The book will be useful for developers who want to start doing real things on the type level.
[from the blurb for your ‘Pragmatic’ book]
Well yes, “any developer” would want to sharpen their skills/do “real things”. But there’s a bazillion books claiming to do that. Why would I as a developer want to read this book specifically?
(Now there’s a few situations where you might not want to “Tell the audience what you’re going to say” exactly: where you have a shocking and controversial discovery that you need to work up to slowly and convincingly; but I don’t think that applied in this case(?) )
And “Pragmatic” features bigly in the slides. Alexander’s next/in-progress book is ‘Pragmatic Type-Level Design’, so fair enough to feature the word.
I’m not sure the word works for me/in my Haskell life. Perhaps ’ прагматичный’ has a rather different nuance?
Wiktionary has ‘pragmatic’ = ‘practical’, but also gives an example “… was pragmatic, but unattractive”. I think of ‘pragmatic compromise’: nobody is happy, but they’ll live with it. Etymonline has several historic meanings with negative connotation: “meddlesome, impertinently busy,”; a euphemism for something bad or disgraceful; often in a bad sense, “trouble”.
Wiktionary in Russian has
основанный на следовании во всём узкопрактическим интересам, соображениям пользы и выгоды
based on adherence to narrow practical interests, utility and profit considerations in everything [DeepL]
which sounds like something Stalin might advocate as against idealist Trotskyites.
I think the usual English word here would be ‘practical’. But then there’s lots of programming/type system texts called ‘Practical’ something or other.
Not a native speaker, but I would say it is not that harsh in English.
In any case, I don’t think OP is (yet) looking for editorial revisions, the point of his talk is clear.
The few members of the haskell community I have seen come across as the collaborative, individual, rational debate kind. They are a refreshing desert of dissidents in the complacent oasis of imperative programming. If you’re looking for individualism and debates, FP has the dissidents, FP provides the debates, FP is the minority report (think Feynman’s minority report).
If anything, I would think it is most mainstream programmers who are collective, hive, cancelling. May I also add: echo chamber, self-congratulating, circlej*rk, Stockholm syndrome (C++ is the paragon of the kind of complexity gone rogue that expert beginners love and defend).
A prominent example of cancellation from the mainstream was GvR. He proactively cancelled functional programming. He opposed an expression version of if-then-else. He denounced any Python implementations that featured TCO. His reason was expressedly to ban FP, it’s his ideology.
In contrast, around the same time, “ivory tower” “academics” such as Moggi, Plotkin, and Wadler were trying hard to make theories that integrate FP and imperative effects. I wouldn’t call that “if something works in practice, but not in theory, then it doesn’t exist”. (Was it some kind of self-congratulating isolationist who said that?) I believe instead they’re thinking “clearly it works, so we need a better theory and catch up!” My point is not whether they succeeded; my point is that they tried. Unlike people who call themselves “more real than thou” but what they really do is cancel all of math, even those little bits that are actually relevant and helpful.
And now the elephant in the room: Is the mainstream wise?
I say that mainstream science is wise, mainstream engineering is wise, mainstream medicine is wise, mainstream accounting is wise, mainstream plumbing is wise, etc. Mainstream competitve tournament sports is wise (but only after they finally ditched intuition and used actual data, see https://danluu.com/talent/ and maybe the Moneyball movie or book). In general, a mainstream profession is wise.
But I say that mainstream programming is unwise.
OK how dare I imply that mainstream programming is unprofessional?
In the professions: When a technique is proposed, people ask: How do we know that it gets the job done? Is it cost-effective?
In mainstream programming, people ask: Is it intuitive? (Read: intuitive to uneducated people. Recall the GvR example.)
My engineering friends once explained to me their stance about theories: They don’t mind theories, but first they want to see that a theory solves engineering problems, then they will learn it. I respect that very much—no, that’s an understatement. I am honoured to have such wise and professional friends.
I haven’t heard a mainstream programmer saying that. Have you?
I’m sorry to pick you out, but yours has been the last post.
Your post is a perfect example of what Alex’ is criticising. You cannot convince people to use “your tool” of choice by calling them and their tools stupid. Btw. the second paragraph perfectly fits Haskell too (and Common Lisp and Scala and Rust and …).
Just to be sure: it wasn’t meant ironically, was it?
For decades now the more mathematically-based functional programming languages (and those who use them) have been the subjects of adverse commentary, to the point of entering “pop culture” e.g. xkcd: Haskell. That some of us here are reacting to (what seems like!) more of this then really isn’t that great a surprise. To me, this begs an obvious question: do those using logic languages like Prolog (and the languages themselves) get similar negative attention? After all, both languages are usually labelled “declarative”. Moreover, Prolog was one of the progenitors of Datalog (for use in deductive databases), and I’ve seen more than enough complaints about the “impedance mismatch” between relational-DB and OO-languages!
@mpilgrem has asked for an example, and @graninas has provided them in the past - let’s see what he can provide; that may help to focus the discussion here.