4 ms·

> In order for a programmer to accept a language with strictly less expressive power Sort of hard to reconcile this view with just how much more expressive the

> In order for a programmer to accept a language with strictly less expressive power Sort of hard to reconcile this view with just how much more expressive the Haskells and Lisps of the world are compared to Go and Python! I've used all of these extensively and functional languages have consistently let me define more general and flexible abstractions, do a better job of reflecting my conceptual model of the domain in my code... all in substantially less code and less boilerplate (excessive imports aside :P) than primarily imperative languages. Functional languages don't stop you from writing imperative code, they allow you to write code that isn't—and, either way, that's just one small aspect of what makes a language adaptable and flexible.

lolinder 4y ago
LISP isn't a pure functional language, it's a multi-paradigm language that is as dynamic as they come. Its problem isn't lack of expressivity, it's probably that it's too flexible (and of course the syntax throws people off). As for Haskell, I guess that gets into the question of how you define expressivity, which is admittedly a very fuzzy term. Here I meant it to mean capable of fluently expressing many different kinds of algorithms without having to resort to circumlocution. Functional programming is natively supported in almost all modern languages. You call a function which calls a function which calls a function which calls a function, return the result. There's no syntactic sugar, just function calls. In Haskell, while I've seen people argue that do notation may as well be imperative code, it isn't. It's an approximation of imperative code using Church—Turing and a liberal dose of syntactic sugar, and using it effectively still requires you to understand the underlying monadic model.
- CrimsonCape 4y ago
  This seems like an easy fix, re-release LISP with cleaner syntax. Lexers have come so far this seems like an easy fix. I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.
  - Kamq 4y ago
    > re-release LISP with cleaner syntax. A lot of the flexibility of lisp relies on there being no difference between a list of symbols and code (for, example, this is how the entire macro system works). Function calls being inside the parentheses (and, really, all language constructs just being lists of symbols) is generally what people mean when they say the syntax throws people. These two things are at odds. You could go with Racket's method of letting people use alternate delimiters, but that's a fairly trivial reader macro in common lisp and probably not worth releasing a language over.
    - charcircuit 4y ago
      The macro system can just work with an AST instead of a list.
      - Kamq 4y ago
        Plenty of successors to lisp have tried that. They gunk up the whole experience.
        bslatkin 4y ago
        Let me know if you'd like to give it a shot to see how gunky it is!
        Kamq 4y ago
        I mean, I'd be down to try. Best I've seen so far (outside of lisp) is elixir, but it really bogs down the entire thing by requiring a bunch of extra information and metadata that common lisp can infer by position and an extra layer of indirection.
        bslatkin 4y ago
        Contact form here: https://quil.la/FVZ3PMZC https://quil.la/FVZ3PMZC Thanks!
- coldtea 4y ago
  >LISP isn't a pure functional language In the modern history-rewritten sense of the term to mean Haskell and purity. In the past LISP was the 100% canonical idea of what a functional language is, including on HN before 2010 or so.
  - wk_end 4y ago
    Lisp was never "pure", but yes, there's definitely been a shift in the meaning of the term "functional language". Which makes sense: the things that made Lisp more "functional" or better suited to the functional style have almost universally adopted by other languages. There's nothing particularly functional about it anymore. Lisp has always been deeply multiparadigm, even if it was the harbinger of FP. It's had support for mutation and OOP since the 70s. If you wanted to (although most Lispers wouldn't), you could view that support as an escape hatch for when the functional paradigm, as expressed in Lisp, was inappropriate or insufficient to solve a problem. It's natural, then, that languages that have taken the functional paradigm and insisted on it, run further with it, are now the ones that are particularly functional. It's how language naturally evolves in cases like this; similar things can be seen with the term "artificial intelligence".
  - goatlover 4y ago
    You might be confusing Lisp with ML.
    - coldtea 4y ago
      Nope. ML, albeit ancient, was not even on the map on HN until after Haskell picked mindshare. I mean you could find a post here and a post there, but nothing like Lisp's posts and HN-mindshare. And, sure, HN was from the start a Lisp-built forum, made by a Lisp-advocate, and thus attracting Lispers, but it wasn't that different on the wider internet.
      - kazinator 4y ago
        But who said more or less of what on HackerNews, and in what years, bears no relevance to what is pure functional language. Lisp had mutable everything from the earliest beginning, and that has been maintained in the descendant dialects. We literally cannot go back to a time in which Lisp was the model of what is purely functional; though it may have been used as an instrument (in restricted ways) for conveying or practically making use of the ideas. There is something called "pure Lisp". Even such backwaters as the Webster Dictionary of Computing seem to know what this is: http://www.webster-dictionary.org/definition/Pure+Lisp http://www.webster-dictionary.org/definition/Pure+Lisp "A purely functional language derived from Lisp by excluding any feature which causes side-effects." I think you will rarely see an entire program written in nothing but pure Lisp. Functions or modules can be designated as being in pure Lisp. If the documentation says that a certain module is pure Lisp, that instantly sets certain expectations about what it will be like to interact with.
- physPop 4y ago
  If you truly think "functional programming is natively supported in almost all modern languages" then you really don't know what modern FP is about. For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. Just having a labmda doesn't FP make. To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Haskell and Ocaml are the pragmatic leaders here I think, with honorable mentions for things like Scala3, F#, and (kindof?) clojure. (edit spelling)
  - lolinder 4y ago
    I've spent more time studying programming languages than anyone else I know, and I understand FP very well. The argument that I'm making is not that FP has nothing to offer (I dearly hope that many more features from FP languages make it into the mainstream!), it's that FP comes with a set of restrictions on what can and cannot be done, and those restrictions do not seem justified to the majority of programmers. It is as uncomfortable for them to work with Haskell as it is to work with Rust, but unlike with Rust they can't see why they should bother. The author of the article hopes to build a new functional programming language that will finally get traction by making a few different choices. I think that this is a mistake because a single-paradigm language will never reach mainstream adoption. Pragmatically multi-paradigm languages have historically been the only ones to get traction, and I believe that the reason is because they explicitly endorse multiple possible approaches, even if their support for any given approach isn't as strong as a specialized tool. They may not support FP as well as Haskell or OO as well as Smalltalk, but by sacrificing purity they buy pragmatism, and allow programmers more flexibility in problem solving.
    - igouy 4y ago
      > They may not support FP as well as Haskell or OO as well as Smalltalk… The Smalltalk Collection enumeration protocol was probably the first time I'd seen anything like (1 to: 100) select: [ :n | n isPrime ] https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collections.html#index-block https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collec... (Now I recall, I had been required to write some Tower of Hanoi snippet in either Lisp or Prolog, and I'd used Prolog.)
toast0 4y ago
> Functional languages don't stop you from writing imperative code, they allow you to write code that isn't Functional languages are definitely about removing things or stopping things. Nothing stops you from naming a new variable everytime in C, but Erlang stops me from mutating variables. Only stack depth/lack of tail call optimizations stops me from using recursion to loop in C, but Erlang can only loop through recursion. And Erlang is pretty pragmatic; some other functional languages are a lot more opinionated.
AnimalMuppet 4y ago
Imperative languages allow you to write functional code, too, but it's clumsier. It's not the strength of the language. In the same way, sure, you can write imperative code in a functional language. But ergonomically, it's not as nice as writing imperative code in an imperative language. If you're code is going to be 90% imperative, don't write it in Haskell. If it's going to be 90% functional, don't write it in C++.

lolinder 4y ago

LISP isn't a pure functional language, it's a multi-paradigm language that is as dynamic as they come. Its problem isn't lack of expressivity, it's probably that it's too flexible (and of course the syntax throws people off). As for Haskell, I guess that gets into the question of how you define expressivity, which is admittedly a very fuzzy term. Here I meant it to mean capable of fluently expressing many different kinds of algorithms without having to resort to circumlocution. Functional programming is natively supported in almost all modern languages. You call a function which calls a function which calls a function which calls a function, return the result. There's no syntactic sugar, just function calls. In Haskell, while I've seen people argue that do notation may as well be imperative code, it isn't. It's an approximation of imperative code using Church—Turing and a liberal dose of syntactic sugar, and using it effectively still requires you to understand the underlying monadic model.

CrimsonCape 4y ago
This seems like an easy fix, re-release LISP with cleaner syntax. Lexers have come so far this seems like an easy fix. I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.
- Kamq 4y ago
  > re-release LISP with cleaner syntax. A lot of the flexibility of lisp relies on there being no difference between a list of symbols and code (for, example, this is how the entire macro system works). Function calls being inside the parentheses (and, really, all language constructs just being lists of symbols) is generally what people mean when they say the syntax throws people. These two things are at odds. You could go with Racket's method of letting people use alternate delimiters, but that's a fairly trivial reader macro in common lisp and probably not worth releasing a language over.
  - charcircuit 4y ago
    The macro system can just work with an AST instead of a list.
    - Kamq 4y ago
      Plenty of successors to lisp have tried that. They gunk up the whole experience.
      - bslatkin 4y ago
        Let me know if you'd like to give it a shot to see how gunky it is!
        Kamq 4y ago
        I mean, I'd be down to try. Best I've seen so far (outside of lisp) is elixir, but it really bogs down the entire thing by requiring a bunch of extra information and metadata that common lisp can infer by position and an extra layer of indirection.
        bslatkin 4y ago
        Contact form here: https://quil.la/FVZ3PMZC https://quil.la/FVZ3PMZC Thanks!
coldtea 4y ago
>LISP isn't a pure functional language In the modern history-rewritten sense of the term to mean Haskell and purity. In the past LISP was the 100% canonical idea of what a functional language is, including on HN before 2010 or so.
- wk_end 4y ago
  Lisp was never "pure", but yes, there's definitely been a shift in the meaning of the term "functional language". Which makes sense: the things that made Lisp more "functional" or better suited to the functional style have almost universally adopted by other languages. There's nothing particularly functional about it anymore. Lisp has always been deeply multiparadigm, even if it was the harbinger of FP. It's had support for mutation and OOP since the 70s. If you wanted to (although most Lispers wouldn't), you could view that support as an escape hatch for when the functional paradigm, as expressed in Lisp, was inappropriate or insufficient to solve a problem. It's natural, then, that languages that have taken the functional paradigm and insisted on it, run further with it, are now the ones that are particularly functional. It's how language naturally evolves in cases like this; similar things can be seen with the term "artificial intelligence".
- goatlover 4y ago
  You might be confusing Lisp with ML.
  - coldtea 4y ago
    Nope. ML, albeit ancient, was not even on the map on HN until after Haskell picked mindshare. I mean you could find a post here and a post there, but nothing like Lisp's posts and HN-mindshare. And, sure, HN was from the start a Lisp-built forum, made by a Lisp-advocate, and thus attracting Lispers, but it wasn't that different on the wider internet.
    - kazinator 4y ago
      But who said more or less of what on HackerNews, and in what years, bears no relevance to what is pure functional language. Lisp had mutable everything from the earliest beginning, and that has been maintained in the descendant dialects. We literally cannot go back to a time in which Lisp was the model of what is purely functional; though it may have been used as an instrument (in restricted ways) for conveying or practically making use of the ideas. There is something called "pure Lisp". Even such backwaters as the Webster Dictionary of Computing seem to know what this is: http://www.webster-dictionary.org/definition/Pure+Lisp http://www.webster-dictionary.org/definition/Pure+Lisp "A purely functional language derived from Lisp by excluding any feature which causes side-effects." I think you will rarely see an entire program written in nothing but pure Lisp. Functions or modules can be designated as being in pure Lisp. If the documentation says that a certain module is pure Lisp, that instantly sets certain expectations about what it will be like to interact with.
physPop 4y ago
If you truly think "functional programming is natively supported in almost all modern languages" then you really don't know what modern FP is about. For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. Just having a labmda doesn't FP make. To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Haskell and Ocaml are the pragmatic leaders here I think, with honorable mentions for things like Scala3, F#, and (kindof?) clojure. (edit spelling)
- lolinder 4y ago
  I've spent more time studying programming languages than anyone else I know, and I understand FP very well. The argument that I'm making is not that FP has nothing to offer (I dearly hope that many more features from FP languages make it into the mainstream!), it's that FP comes with a set of restrictions on what can and cannot be done, and those restrictions do not seem justified to the majority of programmers. It is as uncomfortable for them to work with Haskell as it is to work with Rust, but unlike with Rust they can't see why they should bother. The author of the article hopes to build a new functional programming language that will finally get traction by making a few different choices. I think that this is a mistake because a single-paradigm language will never reach mainstream adoption. Pragmatically multi-paradigm languages have historically been the only ones to get traction, and I believe that the reason is because they explicitly endorse multiple possible approaches, even if their support for any given approach isn't as strong as a specialized tool. They may not support FP as well as Haskell or OO as well as Smalltalk, but by sacrificing purity they buy pragmatism, and allow programmers more flexibility in problem solving.
  - igouy 4y ago
    > They may not support FP as well as Haskell or OO as well as Smalltalk… The Smalltalk Collection enumeration protocol was probably the first time I'd seen anything like (1 to: 100) select: [ :n | n isPrime ] https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collections.html#index-block https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collec... (Now I recall, I had been required to write some Tower of Hanoi snippet in either Lisp or Prolog, and I'd used Prolog.)

toast0 4y ago

> Functional languages don't stop you from writing imperative code, they allow you to write code that isn't Functional languages are definitely about removing things or stopping things. Nothing stops you from naming a new variable everytime in C, but Erlang stops me from mutating variables. Only stack depth/lack of tail call optimizations stops me from using recursion to loop in C, but Erlang can only loop through recursion. And Erlang is pretty pragmatic; some other functional languages are a lot more opinionated.

AnimalMuppet 4y ago

Imperative languages allow you to write functional code, too, but it's clumsier. It's not the strength of the language. In the same way, sure, you can write imperative code in a functional language. But ergonomically, it's not as nice as writing imperative code in an imperative language. If you're code is going to be 90% imperative, don't write it in Haskell. If it's going to be 90% functional, don't write it in C++.