Two minutes in, I correctly guessed that the author was about to claim that their table of mainstream languages was somehow not mostly supportive of functional programming. Out of all of the languages listed, only C and the two languages built upon it, C++ and Objective-C, can’t support functional techniques, due to how pointers to procedures work and how runtime closures can’t be built. (Arguably one could program entirely in Objective-C’s object system, or C++‘s template system, which both support functional techniques, but that’s not the point.)
I need to expand the author’s point a little before getting to the idea of killer apps in general. Ruby’s killer apps are not fully obvious to English-speakers, but it has a powerful following as an embedded language in Japan. Languages become well-known because they are extremely dominant in a niche, and it would be misleading to say that Rails was somehow dominating at the same time that PHP was (has been and continues to) dominate. Now, to look at the killer apps proposed:
elm-ui is nice tooling for Elm. It is not somehow unique to Elm, and has existed before.
Datomic is Just Another Database. It’s a proprietary and slow database, and those are not unique.
Revery is closer; Electron clearly is occupying a niche once occupied by Flash/Shockwave and WildTangent, and Revery could compete with Electron to take over the niche based on technical merit.
I don’t understand why familiarity or history is a good argument. I understand the point about the Microsoft era, but isn’t Lisp from the 1950s? Isn’t functional programming from the 1940s? As I’ve studied category theory and logic, I’ve seen that the functional programming paradigms, families, techniques, and theories are the oldest and most well-studied. I feel that familiarity is not as powerful as massive corporate influence.
Actually, massive corporate influence can stand in for all of the considerations. A corporation can tie a language to its other products, use the products to spread the language, ease the learning curve by immersive advertising, host a walled-garden ecosystem, and even help port from older corporate languages to newer corporate languages. Go back to those slides at two minutes in, and look at Java and Kotlin, Objective-C and Swift, and of course Visual Basic (no longer visible in 2019) and C♯.
We also cannot discount language design. Java was designed to JIT well; it was one of several candidate designs intended to capitalize on the JIT techniques pioneered in the Self language. Yes, Sun spent a lot of money to deploy Java, but also had many situations where other vendors, including Microsoft and GNU, produced alternative Java implementations. Demand for the language outgrew its corporate owner because the language was better than C++ and started competing in those same niches.
At 19 minutes, it’s time for another big question: Why do almost all of the languages have object-oriented features? First, notice that they all (except C++) are not just object-oriented, but object-based in their semantics. I therefore propose a humble answer: Because object-based semantics are good and easy to reason about, and because object-based semantics are good for implementing customized business ontologies. (Can’t forget that massive corporate influence.)
What is true for Go might not be true for OCaml or Python. The author’s recognized that functions and methods are extremely similar, but has inferred that they must always correspond somehow. It varies from language to language. This is an unfortunate effect of the fact that object-based systems are not always message-oriented. Meanwhile, Haskell’s typeclasses and Rust’s traits support inheritance, and all Lisps and MLs are garbage-collected; what exactly are these comparisons supposed to achieve, if they can’t even delineate the languages under discussion?
At 33 minutes, the author questions whether Java’s object-based and object-oriented design features were incidental to C++‘s popularity or indicative of a deeper lineage. They think that it’s the former, because apparently they don’t know about the missing link Self.
Haskell and Python, both about the same age, have map and filter in their built-in preludes. Swift is not doing something new here; this trend is about as old as Java.
To what degree is the author talking about functional programming, and not only Lisps and MLs? To sum up, maybe Clojure’s not popular because it’s not competitive enough in any niche and doesn’t have enough massive corporate influence behind it.
Edit: In the Q&A, the author admits that the entire premise of their talk is bullshit and that the talk is really about how to try to get the Clojure community to be more popular and have more influence. Good hustle, and shame on me for not finishing watching the talk before commenting.
Edit: In the Q&A, the author admits that the entire premise of their talk is bullshit and that the talk is really about how to try to get the Clojure community to be more popular and have more influence. Good hustle, and shame on me for not finishing watching the talk before commenting.
Can you please to link this? I watched the talk and Q&A and did not hear him saying anything like that.
The question is asked at just about 42 minutes in, “Is Lisp a functional programming language?” The author’s answer reveals that there really isn’t such a thing as functional programming. In my critique, I implicitly used a classic set of criteria:
First-class functions as values
Function closure over values/names
Function values can be invoked
s-m-n/Parameter Theorem or currying is available
As the author points out, Java and Python are easily functional programming languages by these criteria. But this defeats their starting thesis by recasting their starting slides as victorious, showing the continued dominance of functional programming in mainstream computer engineering.
Why isn’t functional programming the norm? The question is disingenuous. I think that it’s actually closer to asking why Clojure isn’t more popular. They say that they’re not sure whether a theoretical Lisp that had mutation everywhere (which Lisp is that, exactly?) would not be as functional as Clojure; they say that “Clojure definitely is” a functional programming language.
Edit: In the Q&A, the author admits that the entire premise of their talk is bullshit
Having rewatched the clip, this feels like an extremely unfair characterization of his answer.
The author’s answer reveals that there really isn’t such a thing as functional programming.
Also, not really fair. To his credit, he’s honest about the the difficulty of defining “a functional language” in a cut and dried way. This is not the same thing as revealing there is no such thing. To quote Wittgenstein, it would:
be like saying that the light of my reading lamp is no real light at all because it has no sharp boundary.
And to quote what the author says at the end (after removing some likes and ums), he says that defining a functional programming language is…
definitely kind of fuzzy, and ultimately not as important as talking about the style and their support for the style… of being able to avoid mutation and side effects and still have a really good experience.
That last quality is real, and as I read it he’s making the case that that’s what people are really talking about when they talk about functional programming. The language’s syntax and libraries and de facto idioms make it simple and pleasant to write clear code without mutation and side effects. From this point of view, it makes perfect sense to say Haskell is more functional than Python or Java even if, as you say, Python and Java meet the bullet points of the technical definition you gave for “functional.”
I also didn’t get any hustle-y, sales pitchy vibe from this talk at all.
I don’t agree with you that the quality of supporting functional programming, as a binary quality measured by the author, has no measurable rubric: It seems that being a Lisp or ML is necessary and sufficient. That’s the dilemma here: if it’s not measurable, then it’s a pointless discussion, and if it’s measurable, then it sure looks like the author’s tribal biases on display rather than science or mathematics.
I wonder whether you actually think that Haskell is more functional than Python. Even HN shitposters know enough Python to not believe this sort of Haskeller meme.
But since I’m commenting, I think your main point is both correct and important, although it’s kind of a bummer. The successes or failures of real technologies can’t be explained solely in terms of their technical or intellectual merits. At the very least, we need to consider historical path-dependence and network effects.
It’s the age old debate between Socratic thinkers and Aristotelians. Functional programmers impose their model on to a computer and the world. Pure functions, ideally, with no regard to actual hardware if they can help it. Aristotalians put the hardware first, making abstractions to model the hardware for human use.
This analogy only works if you consider computer architecture to be somehow “natural”. Only software people could ever think that way; computer engineers would find that perspective quite amusing. They generally optimize their designs for existing software, so there’s a feedback loop in place. Computer architectures specifically designed for functional abstractions have been proposed, but the economics of hardware manufacture are not favorable for experimentation. So functional language designers have, quite consciously, mapped their abstractions onto features provided by available hardware. A couple of links:
Good point about the feedback loop. I meant it more in the way that electrical engineers must optimize by caching memory to reduce latency for read/writes. Alan Turing or Von Neumann didn’t invent latency as a design choice. Ideally, there would be no latency anywhere in computer hardware. Abstractions such as async are invented to work with the nature of latency. Working with the ‘cards we were dealt’.
Thanks for sharing the links.
EDIT: To drive home my point, I envision some lisp or some functional language of today useable on hardware of today and the future. Uncle Bob has a good point about Clojure. I can’t say that about Python and others. Look how many environments lisps can live on, all while giving you powerful high level tools. Functional languages are more ‘eternal’ in form than procedural languages. Hence my comparison of Socrates and Aristotle.
I use a substantial amount of TypeScript daily, working on a web app where the frontend and the backend are both written in the language (workspaces, hooray) and share the same types. I’m happy to announce that, as long as you are using modern hooksy React, you can scale an app from its humble two-person beginnings to a five-person team medium-sized enterprise Thing without resorting to any classes or inheritance or trappings of OOP. There is something of a sweet spot where gradual typing and object subtyping intersect, and it’s exactly where TypeScript lives. You can do all the type tricks that you can do in Haskell (minus the higher-kinded types), and the tooling is pretty good to boot.
That said, the main points of the talk (lack of killer apps, lack of big-tech budgets, the molasses of legacy software) I agree with. It would be interesting to see someone spearhead FP, or FP-ish as React/TypeScript was, as a way to construct an operating system and an operating system’s ecosystem. It seems like it would be the next great achievement. It bears pointing out the true power of functional programming is being able to strongly type it, as cute as map/filter/et. al. are. Types are the thing that accelerate refactoring, tooling, and abstraction. A typed operating system would be a sight to behold.
Off topic, but is there a list or collection anywhere of good programming/computer science talks? I love Rich Hickey’s “Simple Made Easy” and would greatly enjoy having a collection of these to slowly make my way through on lazy evenings.
I do agree with Feldman that maybe functional languages are on the rise and could some day belong to most used languages list if a “killer app” is made. Like Google, Kubernetes and Docker could be why Go is so popular nowadays!
I use a substantial amount of TypeScript daily, working on a web app where the frontend and the backend are both written in the language (workspaces, hooray) and share the same types. I’m happy to announce that, as long as you are using modern hooksy React, you can scale an app from its humble two-person beginnings to a five-person team medium-sized enterprise Thing without resorting to any classes or inheritance or trappings of OOP. There is something of a sweet spot where gradual typing and object subtyping intersect, and it’s exactly where TypeScript lives. You can do all the type tricks that you can do in Haskell (minus the higher-kinded types), and the tooling is pretty good to boot.
Two minutes in, I correctly guessed that the author was about to claim that their table of mainstream languages was somehow not mostly supportive of functional programming. Out of all of the languages listed, only C and the two languages built upon it, C++ and Objective-C, can’t support functional techniques, due to how pointers to procedures work and how runtime closures can’t be built. (Arguably one could program entirely in Objective-C’s object system, or C++‘s template system, which both support functional techniques, but that’s not the point.)
I need to expand the author’s point a little before getting to the idea of killer apps in general. Ruby’s killer apps are not fully obvious to English-speakers, but it has a powerful following as an embedded language in Japan. Languages become well-known because they are extremely dominant in a niche, and it would be misleading to say that Rails was somehow dominating at the same time that PHP was (has been and continues to) dominate. Now, to look at the killer apps proposed:
elm-uiis nice tooling for Elm. It is not somehow unique to Elm, and has existed before.I don’t understand why familiarity or history is a good argument. I understand the point about the Microsoft era, but isn’t Lisp from the 1950s? Isn’t functional programming from the 1940s? As I’ve studied category theory and logic, I’ve seen that the functional programming paradigms, families, techniques, and theories are the oldest and most well-studied. I feel that familiarity is not as powerful as massive corporate influence.
Actually, massive corporate influence can stand in for all of the considerations. A corporation can tie a language to its other products, use the products to spread the language, ease the learning curve by immersive advertising, host a walled-garden ecosystem, and even help port from older corporate languages to newer corporate languages. Go back to those slides at two minutes in, and look at Java and Kotlin, Objective-C and Swift, and of course Visual Basic (no longer visible in 2019) and C♯.
We also cannot discount language design. Java was designed to JIT well; it was one of several candidate designs intended to capitalize on the JIT techniques pioneered in the Self language. Yes, Sun spent a lot of money to deploy Java, but also had many situations where other vendors, including Microsoft and GNU, produced alternative Java implementations. Demand for the language outgrew its corporate owner because the language was better than C++ and started competing in those same niches.
At 19 minutes, it’s time for another big question: Why do almost all of the languages have object-oriented features? First, notice that they all (except C++) are not just object-oriented, but object-based in their semantics. I therefore propose a humble answer: Because object-based semantics are good and easy to reason about, and because object-based semantics are good for implementing customized business ontologies. (Can’t forget that massive corporate influence.)
What is true for Go might not be true for OCaml or Python. The author’s recognized that functions and methods are extremely similar, but has inferred that they must always correspond somehow. It varies from language to language. This is an unfortunate effect of the fact that object-based systems are not always message-oriented. Meanwhile, Haskell’s typeclasses and Rust’s traits support inheritance, and all Lisps and MLs are garbage-collected; what exactly are these comparisons supposed to achieve, if they can’t even delineate the languages under discussion?
At 33 minutes, the author questions whether Java’s object-based and object-oriented design features were incidental to C++‘s popularity or indicative of a deeper lineage. They think that it’s the former, because apparently they don’t know about the missing link Self.
Haskell and Python, both about the same age, have
mapandfilterin their built-in preludes. Swift is not doing something new here; this trend is about as old as Java.To what degree is the author talking about functional programming, and not only Lisps and MLs? To sum up, maybe Clojure’s not popular because it’s not competitive enough in any niche and doesn’t have enough massive corporate influence behind it.
Edit: In the Q&A, the author admits that the entire premise of their talk is bullshit and that the talk is really about how to try to get the Clojure community to be more popular and have more influence. Good hustle, and shame on me for not finishing watching the talk before commenting.
Can you please to link this? I watched the talk and Q&A and did not hear him saying anything like that.
The question is asked at just about 42 minutes in, “Is Lisp a functional programming language?” The author’s answer reveals that there really isn’t such a thing as functional programming. In my critique, I implicitly used a classic set of criteria:
As the author points out, Java and Python are easily functional programming languages by these criteria. But this defeats their starting thesis by recasting their starting slides as victorious, showing the continued dominance of functional programming in mainstream computer engineering.
Why isn’t functional programming the norm? The question is disingenuous. I think that it’s actually closer to asking why Clojure isn’t more popular. They say that they’re not sure whether a theoretical Lisp that had mutation everywhere (which Lisp is that, exactly?) would not be as functional as Clojure; they say that “Clojure definitely is” a functional programming language.
Having rewatched the clip, this feels like an extremely unfair characterization of his answer.
Also, not really fair. To his credit, he’s honest about the the difficulty of defining “a functional language” in a cut and dried way. This is not the same thing as revealing there is no such thing. To quote Wittgenstein, it would:
And to quote what the author says at the end (after removing some likes and ums), he says that defining a functional programming language is…
That last quality is real, and as I read it he’s making the case that that’s what people are really talking about when they talk about functional programming. The language’s syntax and libraries and de facto idioms make it simple and pleasant to write clear code without mutation and side effects. From this point of view, it makes perfect sense to say Haskell is more functional than Python or Java even if, as you say, Python and Java meet the bullet points of the technical definition you gave for “functional.”
I also didn’t get any hustle-y, sales pitchy vibe from this talk at all.
I don’t agree with you that the quality of supporting functional programming, as a binary quality measured by the author, has no measurable rubric: It seems that being a Lisp or ML is necessary and sufficient. That’s the dilemma here: if it’s not measurable, then it’s a pointless discussion, and if it’s measurable, then it sure looks like the author’s tribal biases on display rather than science or mathematics.
I wonder whether you actually think that Haskell is more functional than Python. Even HN shitposters know enough Python to not believe this sort of Haskeller meme.
assert pot and kettle == “black”Tiny nitpick: ATS has optional garbage collection. You can avoid it entirely by using linear types.
But since I’m commenting, I think your main point is both correct and important, although it’s kind of a bummer. The successes or failures of real technologies can’t be explained solely in terms of their technical or intellectual merits. At the very least, we need to consider historical path-dependence and network effects.
Today, I learned something interesting and new about ATS. Thank you.
Thanks for your summary. Saved me a lot of time :)
It’s the age old debate between Socratic thinkers and Aristotelians. Functional programmers impose their model on to a computer and the world. Pure functions, ideally, with no regard to actual hardware if they can help it. Aristotalians put the hardware first, making abstractions to model the hardware for human use.
This analogy only works if you consider computer architecture to be somehow “natural”. Only software people could ever think that way; computer engineers would find that perspective quite amusing. They generally optimize their designs for existing software, so there’s a feedback loop in place. Computer architectures specifically designed for functional abstractions have been proposed, but the economics of hardware manufacture are not favorable for experimentation. So functional language designers have, quite consciously, mapped their abstractions onto features provided by available hardware. A couple of links:
Good point about the feedback loop. I meant it more in the way that electrical engineers must optimize by caching memory to reduce latency for read/writes. Alan Turing or Von Neumann didn’t invent latency as a design choice. Ideally, there would be no latency anywhere in computer hardware. Abstractions such as async are invented to work with the nature of latency. Working with the ‘cards we were dealt’.
Thanks for sharing the links.
EDIT: To drive home my point, I envision some lisp or some functional language of today useable on hardware of today and the future. Uncle Bob has a good point about Clojure. I can’t say that about Python and others. Look how many environments lisps can live on, all while giving you powerful high level tools. Functional languages are more ‘eternal’ in form than procedural languages. Hence my comparison of Socrates and Aristotle.
I use a substantial amount of TypeScript daily, working on a web app where the frontend and the backend are both written in the language (workspaces, hooray) and share the same types. I’m happy to announce that, as long as you are using modern hooksy React, you can scale an app from its humble two-person beginnings to a five-person team medium-sized enterprise Thing without resorting to any classes or inheritance or trappings of OOP. There is something of a sweet spot where gradual typing and object subtyping intersect, and it’s exactly where TypeScript lives. You can do all the type tricks that you can do in Haskell (minus the higher-kinded types), and the tooling is pretty good to boot.
That said, the main points of the talk (lack of killer apps, lack of big-tech budgets, the molasses of legacy software) I agree with. It would be interesting to see someone spearhead FP, or FP-ish as React/TypeScript was, as a way to construct an operating system and an operating system’s ecosystem. It seems like it would be the next great achievement. It bears pointing out the true power of functional programming is being able to strongly type it, as cute as map/filter/et. al. are. Types are the thing that accelerate refactoring, tooling, and abstraction. A typed operating system would be a sight to behold.
Off topic, but is there a list or collection anywhere of good programming/computer science talks? I love Rich Hickey’s “Simple Made Easy” and would greatly enjoy having a collection of these to slowly make my way through on lazy evenings.
I do agree with Feldman that maybe functional languages are on the rise and could some day belong to most used languages list if a “killer app” is made. Like Google, Kubernetes and Docker could be why Go is so popular nowadays!
I use a substantial amount of TypeScript daily, working on a web app where the frontend and the backend are both written in the language (workspaces, hooray) and share the same types. I’m happy to announce that, as long as you are using modern hooksy React, you can scale an app from its humble two-person beginnings to a five-person team medium-sized enterprise Thing without resorting to any classes or inheritance or trappings of OOP. There is something of a sweet spot where gradual typing and object subtyping intersect, and it’s exactly where TypeScript lives. You can do all the type tricks that you can do in Haskell (minus the higher-kinded types), and the tooling is pretty good to boot.