6 ms·

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I hope he is also questioning the premise

by moring 4y ago

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I hope he is also questioning the premise that functional programming is the reason why functional languages are unpopular. Every time I wanted to dive into functional programming I was very quickly frustrated with the abysmal tooling around them and while that didn't really prevent me from trying, I simply found a better use for my time. Most recent example: Clojure wanting me to choose one of multiple package managers before starting my first project. Before that it was package management nonsense in Haskell, and before that some Scheme interpreter not being able to even give a stack trace on errors. IMHO a really underrated feature of Rust is how friendly its tooling is towards its users. I'd really like to see something like that for functional programming.

bslatkin 4y ago
Great examples. Another question that leads to frustration is "can I use my existing code editor for this"? People are turned off when the answer is "no"
- taeric 4y ago
  What examples force not using an editor? Many have a "natives use this" choice, but few lock you to it.
  - bslatkin 4y ago
    Some parentheses languages are much easier to use if you're familiar with a structural editor, for example.
    - taeric 4y ago
      All languages are easier that way, though? My kids learning python are best with a ton of hand holding. Affordances that show the structure are huge.
      - bslatkin 4y ago
        Agreed that seeing structure is important. I mean operating on it at a higher level like https://calva.io/paredit/ https://calva.io/paredit/
        taeric 4y ago
        This makes sense, but I don't think that is at all required for working in lisp and friends. Just as many refactoring tools are not required to get started. Certainly useful if you get running with them.
taeric 4y ago
While I do think an opinionated template would be good; I do also hate how some languages pretend you don't need a package manager. Back when code was shared more in ideas than implementations, this was truer. All too often today, first thing you need to do is import a package.
xiaq 4y ago
As someone who's dabbled in Clojure: the project manager scene (lein vs boot vs deps CLI) is not nearly as bad it is may seem. They are different project workflow runners, not completely different ways to write code and use dependencies. They are not radically different in their core job of taking your code, downloading dependencies and running it. If you're a beginner, you can choose any one and there's very little you're missing out or getting locked into. You only need to worry about the choice when you start having complex development workflows. In comparison, the JavaScript ecosystem is much, much more divided. There are different ways to write modules, different ways to build them, different package repositories, etc..
- moring 4y ago
  > If you're a beginner, you can choose any one I found this to be false in practice: I did choose any one (lein actually, because my IDE suggested that it's the one you'll want to use when you don't know better). The consequence was that the examples from the Clojure page didn't work and/or printed totally different output, because they made a different choice. It's the kind of thing where a Clojure expert would say: they are different tools, of course their output is different, but it doesn't matter because that's only the tool output and the net effect is the same. But in practice, a newbie will struggle solving very simple problems because the tutorial doesn't match reality. Contrast that with the "rust book" (more or less the official tutorial) in which every single example behaves 100% exactly as described in the tutorial, from installing the toolchain to very complex, language-specific issues (yes, of course I'm referring to the borrow checker).
munch117 4y ago
The question "functional programming is great, why isn't it more popular?" predates package managers by decades. That question is older than Linux, older than Haskell. Best of luck with improving tooling, but it's not the answer.
pyjarrett 4y ago
> IMHO a really underrated feature of Rust is how friendly its tooling is towards its users. I'd really like to see something like that for functional programming. > abysmal tooling around them F# has amazing tooling. Debugging works out of the box in Visual Studio and Rider, and it's impure enough I was able to get comfortable quickly and .NET core has a crazy amount built in (e.g. no fuss JSON serialization). I ported a project from C# to F# and the old bash/powershell scripts to publish a standalone executable are now just F# scripts you run with `dotnet fsi`.
slifin 4y ago
Just choose Clojure deps I kind of agree some more clarity would be helpful but we don't have a lot of enthusiastic young programmers in Clojure land who like making super accessible stuff It's just kind of assumed you'll put the work in because Clojure is different enough that you probably have a good reason to be here Btw if you want anything Clojure Google Clojure Slack and they'll help you there
weatherlight 4y ago
> I'd really like to see something like that for functional programming. Elixir has awesome tooling and developer experience, its over 10 years old built on a vm thats 35 years old. Has communities dedicated to domains around embedded systems, distributed/fault tolerant system, web development, machine learning, data pipe lines, ETL, etc. It's just not in the ML or LISP families.
- ch4s3 4y ago
  Yeah, if you're looking for a functional programming language and can live without static types, you need a pretty strong reason to look further than Elixir.
  - weatherlight 4y ago
    ...and if you want the static type checking before compile time with a C like syntax on the Erlang Virtual Machine, Gleam is pretty compelling. https://gleam.run/cheatsheets/gleam-for-python-users/ https://gleam.run/cheatsheets/gleam-for-python-users/ https://gleam.run/cheatsheets/gleam-for-php-users/ https://gleam.run/cheatsheets/gleam-for-php-users/ https://gleam.run/cheatsheets/gleam-for-rust-users/ https://gleam.run/cheatsheets/gleam-for-rust-users/
Max_Limelihood 4y ago
You’re 100% correct, I think. But it’s notable that in that case, an extra functional programming language would make things worse by dividing effort, not better.

by moring 4y ago

bslatkin 4y ago

Great examples. Another question that leads to frustration is "can I use my existing code editor for this"? People are turned off when the answer is "no"

taeric 4y ago
What examples force not using an editor? Many have a "natives use this" choice, but few lock you to it.
- bslatkin 4y ago
  Some parentheses languages are much easier to use if you're familiar with a structural editor, for example.
  - taeric 4y ago
    All languages are easier that way, though? My kids learning python are best with a ton of hand holding. Affordances that show the structure are huge.
    - bslatkin 4y ago
      Agreed that seeing structure is important. I mean operating on it at a higher level like https://calva.io/paredit/ https://calva.io/paredit/
      - taeric 4y ago
        This makes sense, but I don't think that is at all required for working in lisp and friends. Just as many refactoring tools are not required to get started. Certainly useful if you get running with them.

taeric 4y ago

While I do think an opinionated template would be good; I do also hate how some languages pretend you don't need a package manager. Back when code was shared more in ideas than implementations, this was truer. All too often today, first thing you need to do is import a package.

xiaq 4y ago

As someone who's dabbled in Clojure: the project manager scene (lein vs boot vs deps CLI) is not nearly as bad it is may seem. They are different project workflow runners, not completely different ways to write code and use dependencies. They are not radically different in their core job of taking your code, downloading dependencies and running it. If you're a beginner, you can choose any one and there's very little you're missing out or getting locked into. You only need to worry about the choice when you start having complex development workflows. In comparison, the JavaScript ecosystem is much, much more divided. There are different ways to write modules, different ways to build them, different package repositories, etc..

moring 4y ago
> If you're a beginner, you can choose any one I found this to be false in practice: I did choose any one (lein actually, because my IDE suggested that it's the one you'll want to use when you don't know better). The consequence was that the examples from the Clojure page didn't work and/or printed totally different output, because they made a different choice. It's the kind of thing where a Clojure expert would say: they are different tools, of course their output is different, but it doesn't matter because that's only the tool output and the net effect is the same. But in practice, a newbie will struggle solving very simple problems because the tutorial doesn't match reality. Contrast that with the "rust book" (more or less the official tutorial) in which every single example behaves 100% exactly as described in the tutorial, from installing the toolchain to very complex, language-specific issues (yes, of course I'm referring to the borrow checker).

munch117 4y ago

The question "functional programming is great, why isn't it more popular?" predates package managers by decades. That question is older than Linux, older than Haskell. Best of luck with improving tooling, but it's not the answer.

pyjarrett 4y ago

> IMHO a really underrated feature of Rust is how friendly its tooling is towards its users. I'd really like to see something like that for functional programming. > abysmal tooling around them F# has amazing tooling. Debugging works out of the box in Visual Studio and Rider, and it's impure enough I was able to get comfortable quickly and .NET core has a crazy amount built in (e.g. no fuss JSON serialization). I ported a project from C# to F# and the old bash/powershell scripts to publish a standalone executable are now just F# scripts you run with `dotnet fsi`.

slifin 4y ago

Just choose Clojure deps I kind of agree some more clarity would be helpful but we don't have a lot of enthusiastic young programmers in Clojure land who like making super accessible stuff It's just kind of assumed you'll put the work in because Clojure is different enough that you probably have a good reason to be here Btw if you want anything Clojure Google Clojure Slack and they'll help you there

weatherlight 4y ago

> I'd really like to see something like that for functional programming. Elixir has awesome tooling and developer experience, its over 10 years old built on a vm thats 35 years old. Has communities dedicated to domains around embedded systems, distributed/fault tolerant system, web development, machine learning, data pipe lines, ETL, etc. It's just not in the ML or LISP families.

ch4s3 4y ago
Yeah, if you're looking for a functional programming language and can live without static types, you need a pretty strong reason to look further than Elixir.
- weatherlight 4y ago
  ...and if you want the static type checking before compile time with a C like syntax on the Erlang Virtual Machine, Gleam is pretty compelling. https://gleam.run/cheatsheets/gleam-for-python-users/ https://gleam.run/cheatsheets/gleam-for-python-users/ https://gleam.run/cheatsheets/gleam-for-php-users/ https://gleam.run/cheatsheets/gleam-for-php-users/ https://gleam.run/cheatsheets/gleam-for-rust-users/ https://gleam.run/cheatsheets/gleam-for-rust-users/

Max_Limelihood 4y ago

You’re 100% correct, I think. But it’s notable that in that case, an extra functional programming language would make things worse by dividing effort, not better.