Why Isn't Functional Programming the Norm? – Richard Feldman
Metosin12 HN recommenders · 2019–2025
1.6M views · talk · evergreen · Uploaded 2019-09-30
Richard Feldman argues that functional programming is not the norm largely because of historical accidents, such as C++ popularity, platform exclusivity, marketing spend and network effects, rather than merit. He traces the history of how languages become mainstream.
HN treats it as the standard answer to why FP isn't mainstream and why languages succeed.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
49:55How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
42:03The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:31:06William Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
31:44The Value of Values with Rich Hickey
InfoQ
1:03:29Maybe Not - Rich Hickey
ClojureTV
20 comments from Hacker News
I know the answer, thanks to watching a recent video by Richard Feldman on why functional programming isn’t popular yet. I recommend watching it for some interesting talk about programming languages in general, it’s on YouTube at [VIDEO] Anyway what privates give you is what everyone wants from a programming language: modularity. We want to be able to expose an api to some code and for it to have some inner workings that we don’t see because: 1. If we know they can’t be touched we have some implicit guarantees about our program. E.g. the mouse pointer cannot go off screen even if we try to make a call to do that. 2. It is simpler for a programmer to understand the api which might be 1% of the size of the module itself with all private’s. 3. I can change my private’s without breaking your calls. Essentially a minor version change in Semvar parlance instead of a major breaking change. 4. Make impossible state impossible! By guarding the state. All these things require modularity, and OO uses classes and private members to provide that modularity. Elm uses modules and the exposing keyword (or lack of!) as a contrast. JS modules are similar with a lack of an export allowing you to hide something. That something you did export can use for state or functionality. There is an old IIFE trick that works this way also. Making everything public is a bad idea, as you miss out on modularity advantages. Not sure how Ruby hides things as I haven’t used it for a while but I’m sure there is a
In the market of ideas, there usually isn't any reason that makes the good ideas unpopular. That's the default outcome. Some good ideas eventually make it to mainstream / conventional wisdom because there's some second factor that brings them to the spotlight. For languages it might be a killer app, big corporate investment, etc. In [VIDEO] Richard Feldman puts up a (well founded IMO) argument that OO became accidentally popular because of C++. C++ didn't do OO well, nor was OO the main benefit of C++, it just happened to be something that came with C++.
“Why isn’t functional programming the norm?” by Richard Feldman. Spoiler: not on the basis of merits. [VIDEO] “React to the future” by Jordan Walke. Why ReasonML is a logical extension of ReactJS’ programming paradigm. [LINK] “Typing the untyped: soundness in gradual type systems” by Ben Weissmann. The trade offs that various gradual type systems make based on their language constraints. [LINK] “Let’s program like it’s 1999” by Lee Byron. How the mutual feedback loop of abstraction, syntax and mental model drives the evolution of web technologies. [LINK]
Yes, any new language needs to start somewhere, but it’s interesting to think we need new languages for existing domains and that they have any chance of success to begin with. Consider that by many accounts JavaScript, Java, and Python basically dominate in terms of number of developers and mindshare. These languages all arrived 25-30 years ago. I know some rankings claim C/C++ are far more popular than JavaScript but I just haven’t seen evidence of that in recent years. Other widely used languages include C, Objective-C, C++, C# and Ruby. The first three are older than the aforementioned languages, and Ruby is from the same era as Java/JavaScript, and C# isn’t far behind that. In terms of newer languages, the only ones I can think of offhand that seem to have serious traction are Swift and to a lesser extent Go. Some people might throw Kotlin in there, but I’m not sure how much actual traction it’s getting. Rust has been gaining traction slowly for ~8+ years and I’m hopeful it has a bright future but I don’t see a lot of actual projects using it today. The point is that it’s really hard to succeed if your primary reason to exist is to make existing practice slightly better. It’s very hard to displace any of the existing languages in the space of general purpose programming. You need to have libraries. You need to have at least syntax coloring support for several editors. You need language server support for VS Code. You need to generate Dwarf. You probably need a repl or we
> If in the next fifty years more than, say, 3% of programmers will be programming in a language like Lean, I will eat my hat. You're not even putting any stakes on the table. That's such a safe bet. It's unlikely you'd even have a chance at losing the odds are so stacked. There's a great talk on why functional programming is not the norm: [VIDEO] The short of it is: network effects . Haskell, OCaml, SML... they've never had the benefit of being the exclusive language to a popular platform like the web, macOS, or UNIX. They've not yet had a killer app like Rails or Numpy/SciPy/PyTorch. They've certainly not been foisted on the market with a war chest of marketing dollars like Java and C#. And they're not an incremental improvement on the status quo with an obvious, easy benefit. > Now, try to explain to a programmer what kind of object id is That's a rhetorical exercise. You can take a random snippet of APL or Fortran and the outcome would be the same. Every language requires training and effort to learn. I teach people Haskell and TLA+. If you think teaching people the value of a language like Haskell is hard you should see the blank stares I get on the first day teaching experienced developers TLA+. Interested folks will come around eventually and have their moment but it takes training and dedication to get there. > was chosen not with the best interests of programmers in mind I'm well aware. I converse regularly with the maintainers of mathlib and the community. I know th
Richard Feldman gave an interesting talk on this in 2019 [0]. He was trying to answer why functional programming isn't mainstream but the opposite is what we're posing here and I think it's for many of the same reasons. Network effects : a lot of these languages were mainstream earlier on and got buy in from a lot of folks who are invested in their continued adoption and success. Platform exclusivity : some companies push their own language ecosystems on their platforms and those languages are often OOP/multi-paradigm languages. Specifically to OOP we have to ask why is the particular style of C++/Java OOP the norm? Why didn't Eiffel, Smalltalk, or Self reach the same market? [0] [VIDEO] edit : forgot the link -- oops.
Keep in mind that what may seem like "personality fit" may be more related to "learned imperative programming first". As an analogy, depending on which spoken language a person learned first (as a child, _automatically), learning some new languages may be particularly difficult or quite natural. If we had all learned functional programming concepts first, our minds would be trained to think that way. We all learned functional (declarative) math, and we don't even think about it as such. It's just math. This video gives some plausible explanations as to why imperative programming is more common than functional: [VIDEO]
This is indeed a very interesting question! I’ve also asked myself that time and time again, along the path of slowly discovering what this FP thing is all about over the course of my career. It does look wonderful, it does save you a lot of effort in some cases, where “some” is a vast swathes of computational problems. And its so damn elegant. A lot of examples are thrown around were a bunch of lambda calculus can result in 10-20 fold reduction in source code size. So where’s the catch?There has to be something wrong right? Well recently I stumbled upon a clojure conf talk that tried to tackle precisely this question. [VIDEO] The short of it is that its more of a historical inertia and chance than any specific hidden gotcha. Fascinating talk.
This talk by Richard Feldman is an excellent discussion about why Functional Programming is not the norm - [VIDEO]
I recently watched this talk- Why Isn't Functional Programming the Norm? ( [VIDEO] ) Here's the HN thread- [LINK] I learned in that talk, among other things that Oracle spent $500 million to promote and market Java. - [LINK] - [LINK] - [LINK]
Richard Feldman (Elm) analyzes why programming languages become popular and says Java is unique. It became popular because Sun spent 100's of millions of dollars promoting it, even after the dot com crash. Others like Ruby, had a killer app. His thesis is object oriented programming wasn't inevitable or is the best way to program. It was an accident of history that OOP became so popular. Why Isn't Functional Programming the Norm? – Richard Feldman [VIDEO] Another Java tidbit is that Miguel de Icaza (Gnome, Mono) really wanted an open source higher level language on Linux so he approached Sun about Java and they wouldn't work with him, so he settled on C# and is probably the man most responsible for the move to cross platform C# and .NET (dotnetcore, v5) [LINK]
There's a great talk -- [VIDEO] -- Why Isn't Functional Programming the Norm? – Richard Feldman -- that goes into this. It's a discussion of "why" programming languages succeed.
Maybe it ought to be but it definitely isn't if you look at success as industry adoption. The author seems to have good intentions and covers all the talking points a new convert will discover on their own. However I'm afraid an article like this will do more harm than good in the end. There are too many network effects in play that go against a new paradigm supplanting the mainstream as it is. And the benefits of functional programming pointed out in this article haven't been convincing over the last... many decades. Without large, industry success stories to back it up I'm afraid any amount of evangelism, however good the intention of the author, is going to fall before skeptical minds. It doesn't help that of the few empirical studies done none have shown any impressive results that hold up these claims. Granted those studies are few and far between and inconclusive at best but that won't stop skeptics from using them as ammunition. For me the real power of functional programming is that I can use mathematical reasoning on my programs and get results. It's just the way my brain works. I don't think it's superior or better than procedural, imperative programming. And heck there are some problem domains where I can't get away from thinking in a non-functional programming way. I think the leap to structured programming was an event that is probably only going to happen once in our industry. Aside from advances in multi-core programming, which we've barely seen in the last cou
That doesn't mean the imperative languages are "better", though, just more popular. I recommend the following video titled "Why isn't Functional Programming the Norm?": [VIDEO]
FP didn't really start to "click" until I found "Functional Core, Imperative Shell"[1] last year (2022). The HN comments from that thread were very helpful, too. I didn't really grok FP until 2022, but I learned Scheme as early as 1999 for programming 101 (comp sci degree). We used the SICP textbook; looking back it seems SICP used an FP language to teach programming, but didn't explore some important FP concepts like Option/Either (a.k.a. Monads. Perhaps our class just didn't cover that part of the book?) Between 1999 and 2022, I dabbled in FP because I heard good things about it. But I think many FP practitioners could improve their marketing/teaching skills. Most FP texts seem to dive into mathematical jargon (monads, functors, etc) without even explaining why knowing these would be useful. So I'm writing a series of articles on FP. The first one is on why FP is worth learning: "More Performant, Testable Code with Functional Programming. (FP language optional!)"[2] The next article will be a curated list of articles/videos that I feel explain FP better than most; the ones I wish I had found way back when starting to dabble in FP. Also there's an argument many of FP's useful features have been copied by more imperative languages[3]. So people may be unwittingly doing FP even if they aren't using an FP language. For example, anonymous first class functions have been added to C++ and even Excel. JS has always had anonymous first class functions. [1]: [LINK] [2]: [LINK] [3]: [
FP is a way of thinking, which FP languages give nice features/syntax for. You can do non-FP style programming with an FP language. In fact, many FP language features have been borrowed by non-FP languages to the point people don't consider them "FP" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class functions[1].) Three features that would make FP thinking in JS easier: 1. immutable tuples and records[2] 2. pipe operator[3] 3. pattern matching[4] Major epiphany: According to Grokking Simplicity[5], good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. Impure functions depend on the time they are called, so they are the most difficult to get right. In the end, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc). "Functional Core, Imperative Shell"[6] is probably the most useful FP concept. It is about pushing mutation/errors/impure functions to the outer edges of your code, so the inner code can focus on the "happy path." Complex business logic lives in the inner core; the outer shell is often simple/branchless so unit tests aren't even needed. [0]: [VIDEO] [1]: [LINK] [2]: [LINK] [3]: [LINK] [4]: [LINK] [5]: [LINK] [6]: [LINK]
I felt that some of your questions, as well as the general history of popular programming languages, were well laid out in this talk: [VIDEO] TL;DW: The presenter mentions that Python experienced a slow but consistent growth trend, leading to its current prominence. Other points he highlighted about its success align with much of the sentiment expressed here.
Also related: [VIDEO] Network effects likely explain a big part of it. Many of the "popular" languages today aren't necessarily great languages and adopted for their technical merits. Often they were the only language available on an exclusive platform everyone wanted to develop software on. Other times it was because folks wanted to write a particular kind of application and there just happened to be this framework in this weird language that made the task easy. We probably have more programming languages now than ever before but I think the market for new languages in the mainstream is relatively static. It shifts... but very slowly.
This is a great talk on exactly this topic from a Clojure conference, if you want a long answer. It focuses on the “functional” feature of Clojure but all of it applies to the whole language (and probably any good lisp) IMO. [VIDEO] My brief text answer (focused on Clojure): -python has been around about 20 more years than Clojure -the advantages of Clojure vs python/etc probably aren’t nearly as big as python vs a non memory managed, compiled, static language like C. That whole generation of “scripting” languages had the wind at their backs in a way Clojure and its contemporaries never quite will (though Clojure et al tend to be much better at concurrency and parallelism and this will help a lot) -unfamiliar syntax (not Algol like) and paradigm (not oop)- and the truth is many programmers back away slowly when a thing is too alien -hasn’t found a niche as big as data science or scientific computing or CRUD website building - I think python has aggregated some great academic niches, at least one of which (ML/data science) exploded in popularity. Ruby had the rails community. Clojure seems to have some popularity in fintech but has no big single niche yet that it dominates.
Why isn't it more popular? I think Richard Feldman [0] proposed some of the most reasonable theories as to why functional programming isn't the norm. Your language needs to be the platform-exclusive language for a widely used platform, have a killer application for a highly desired application domain, or be backed by a monster war-chest of marketing money to sway opinions. Since Feldman's talk, Python has grown much faster in popularity in the sense of wide use in the market place... but mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks which is... a killer application. I like OCaml. I started evaluating functional programming in it by taking the INRIA course online. I spent the last four and half years working in Haskell. I've built some side projects in Zig. I was a CL stan for many years. I asked this question a lot. We often say, "use the best tool for the job." Often that means, "use the tool that's available." I think languages like OCaml, Rust, Haskell etc can be "popular," but in the sense that people like to talk about them and want to learn them and be able to use them (at least, as trends come and go). It's different from "popular" as in, "widely adopted." [0] [VIDEO]