Metosin
12 HN recommenders · recommended in 15 months, 2019–2025
46:09 · 1.6M views · Sep 30, 2019
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.
20 comments from Hacker News
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. this 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 - this video
> 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: this 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
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 this 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
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] this video