5 ms·

As a new programmer, I was also seduced by the FP hype, and learned web development in ClojureScript without knowing JavaScript. This was a really hard way to

As a new programmer, I was also seduced by the FP hype, and learned web development in ClojureScript without knowing JavaScript. This was a really hard way to learn, and once I finally went mainstream I found that the messaging about how bad other languages were was much exaggerated. In general I think the ecosystem trumps the language quality, and the senior developers who think otherwise generally underestimate the difficulty for a junior developer of working on the bleeding edge. Pragmatism over purity (while keeping enough purity-focus to keep the codebase clean). I also think JS is absolutely fine as a language and its warts are not that hard to work around.

rimliu 5y ago
JS may be fine, but I start do doubt the same can be said about the ecosystem.
- kansface 5y ago
  I really enjoy writing JS/TS - I find that eg arrow functions mixed with React allow for really concise and expressive solutions. You are correct about the ecosystem... maybe not per se, but that supply chain attacks are hopelessly intractable at the moment. How could you possibly go about writing a modern SPA that notionally cares about security when the third party software you must rely on is impossible to verify? I would love if browsers let you run JS in a sand boxed mode wherein you could just pass a bundle of vendored upstream software without the ability to touch the window, network, global state, etc.
- skinkestek 5y ago
  > JS may be fine, If you compare JS (not TS, TS is fine) and PHP (I have extensive experience in both) you'll find that once you go beyond the syntax on the top you'll find the same flaws in some form or another. Yes, PHP is uglier, but that is about it. > but I start do doubt the same can be said about the ecosystem. JS is a horrible language that works because of the tireless effort of its community that has created an ecosystem so rich that even JS can be programmed efficiently. The ecosystem might be flawed but it is the only reason why JS is usable at all.
jmfldn 5y ago
FP programmer here and I agree insofar as ecosystem matters a lot and you want to be able to onboard juniors easily and on. To that end a pure FP language is often not the best choice, especially in lowering the learning curve. However it can be great a choice on the right project and with the right team. Overall it makes sense that we have way more JS and Go programmers than Haskell or 'pure FP' Scala. JS is fine as a language but so is F#, they fit different niches and different contexts. I love the diversity of our industry and I see having all these different paradigms and languages as a massive strength. I welcome them all.
- daltont 5y ago
  Not something on a scale of a project, but "bowling score" exercises are a lot more elegant in functional languages than more procedural ones due to things like pattern matching.
- coyotespike 5y ago
  I completely agree with this balanced take - it's all about context and making the right tradeoffs.
jerf 5y ago
I'm really tempted to write a blog post about "fake functional". The thing is, I really like functional. I really like Haskell. But most of the things that I like about Haskell aren't present when you rip things out of it willy-nilly and drop it into a language not designed for those idioms. The thing I like about functional programming is the fluid composition of all those ideas, and just dropping "map" or "option" doesn't mean you've got the fluid composition. Jamming functional paradigms into languages where they don't compose like they do in Haskell is just fake functional. I'd much rather work with a language in the space where it does provide fluid composition of its concepts then jam a foreign idiom into it and enter into a constant low-level war, where I'm likely going to have to roll out the Inner Platform gun to try to wrangle the language into being a bad imitation of another language. And that's a gun I want to be firing as a last resort, not using as my primary weapon.
- coyotespike 5y ago
  Really well put! Like, you wouldn't try for FP in Java, it's better suited for OOP, much of the time.
  - int_19h 5y ago
    There are certainly bits and pieces associated with FP that are just as handy in Java. Discriminated unions with pattern matching, for example. Which is why those languages are also getting that stuff. C# already has matching (but not unions), and Java is on the way there.
- WatchDog 5y ago
  In contrast, I really like the simplistic functional elements added to a language, like the Java 8 stream API, but I feel like banging my head against a wall using scala with effects systems.
  - jerf 5y ago
    I actually like some of the things added; being able to write a map function that takes an already-existing function and applies it to an array con be more convenient than the for loop. Depends on the language, obviously. What I dislike are people who get on a high horse about it, as if they're programming "functionally" and it's better than what everyone else in the language is doing. They're not "programming functionally", because they can't be, the language doesn't support it. A single map call is convenient. Sometimes you can put a couple of them together. Huge piles of code in imperative languages written in functional paradigms is a mess, because most of the putative advantages of functional aren't present. The one that I notice the most is that the "functional" paradigm embedded in imperative languages creates a barrier against refactoring. Sometimes it is simply that all the noise and chaff prevents programmers from seeing through to the underlying essense, and simply not realizing that if you have a recurring pattern of mapping the same three functions over an array in multiple places that you can in fact refactor that into a function. Sometimes, though, it's just not possible to refactor properly through inner platform you've introduced. Sometimes, refactoring is possible, but requires bringing in yet more firepower to get around the inner platform, like defunctionalization. By the time you're defunctionalizing something (by necessity, not choice) because of your inner platform to do something that would have been 4 lines of code in the original core language if you'd just used that, you're in deep trouble. And what's worse, people will call this good programming. It's just the functional programming equivalent of frameworkitis that you see in languages like Java. "We need all this machinery to program properly!" No. You don't.
dgb23 5y ago
I don’t disagree, but for someone who has been using JS for almost a decade, it is liberating and relaxing to use Clojure. Similar can be said about other languages that have a deliberate and thoughtful design.
- facelessuser 5y ago
  but for someone who has been using JS for almost a decade, it is liberating and relaxing to use Clojure. Can you elaborate what you find liberating and relaxing in Clojure vs modern JS? Putting aside runtime features like multi-threading the only thing I miss a bit after having use Clojure for one year was macros. But the for the rest, is all the same, just functions and data, and some polymorphic abstractions here and there.
  - dgb23 5y ago
    Tons of things actually. If I have to choose a few: For one, JS feels clunkier with its expression/statement mish-mash. Once I started getting expression based syntax, everything made so much sense. It's such a simple feature that lets code compose granularily and is one of the key enablers for _seamless_ interactive development (and macros). One instance where this is pronounced is when you compare React JSX with Reagent and ClojureScript. Secondly, you can do FP in JS but no matter how you do it, it feels tacked on, is typically less performant, doesn't compose as well and relies more on discipline because it isn't the default. I'm not saying FP all the things either. It's just that in interactive web GUI's you have tons of state and asynchronicity, so the type of bugs and problems that occur from mismanaging those are incredibly frustrating. There are JS libraries that mutate the stuff you pass into for no reason at all. FP by default is very, very relaxing and composes well.
    - facelessuser 5y ago
      Sure but those are all minor things (and greatly exaggerated) in the grand scheme of shipping stuff and producing value IMO, today, a language being mainstream and its ecosystem matters. You are falling for the exact trap the article warns about. You'll say you can use the Java ecosystem but them you loose all the benefits you mentioned, you say you will keep interop/mutation/side effects isolated but then again you can do the same in JS if some lib is causing unwanted mutation. I have seen JS developers run in circles around Clojure developers because the JS devs have specialized in their language and ecosystem while the others keep moving between ecosystems and niche languages hoping for some magical thing that will fix all their problems. Rich Hickey is a great software engineer and software architect but what most don't notice is that he also is a good salesman.
JoelMcCracken 5y ago
while FP is hyped, it is also fundamentally good technology. I was very skeptical of Haskell for years, and finally really tried it, and I dont think I have ever changed my mind so completely on anything. Don't get me wrong. It has warts. And you're right, a jr who has problems with like configuring their environment variables correctly for example is going to really have a hard time. This is mostly why I think that while I'd still recommend Haskell to people, you can't just throw it on a team of newly grads and expect it to work out. Not that you can do that with JS either per se, but you CANNOT do it with Haskell. Sure, JS has warts, and a lot of them are bad, but heck, Haskell has a lot of warts too. They all have warts. Any language that has been around for any length of time has generally had its share of ideas which didn't really work out over the long term. For me the bigger issue with JS is the ecosystem quality. If you aren't on the golden path of package usage, you may find that you are in for a world of hurt.

rimliu 5y ago

JS may be fine, but I start do doubt the same can be said about the ecosystem.

kansface 5y ago
I really enjoy writing JS/TS - I find that eg arrow functions mixed with React allow for really concise and expressive solutions. You are correct about the ecosystem... maybe not per se, but that supply chain attacks are hopelessly intractable at the moment. How could you possibly go about writing a modern SPA that notionally cares about security when the third party software you must rely on is impossible to verify? I would love if browsers let you run JS in a sand boxed mode wherein you could just pass a bundle of vendored upstream software without the ability to touch the window, network, global state, etc.
skinkestek 5y ago
> JS may be fine, If you compare JS (not TS, TS is fine) and PHP (I have extensive experience in both) you'll find that once you go beyond the syntax on the top you'll find the same flaws in some form or another. Yes, PHP is uglier, but that is about it. > but I start do doubt the same can be said about the ecosystem. JS is a horrible language that works because of the tireless effort of its community that has created an ecosystem so rich that even JS can be programmed efficiently. The ecosystem might be flawed but it is the only reason why JS is usable at all.

jmfldn 5y ago

FP programmer here and I agree insofar as ecosystem matters a lot and you want to be able to onboard juniors easily and on. To that end a pure FP language is often not the best choice, especially in lowering the learning curve. However it can be great a choice on the right project and with the right team. Overall it makes sense that we have way more JS and Go programmers than Haskell or 'pure FP' Scala. JS is fine as a language but so is F#, they fit different niches and different contexts. I love the diversity of our industry and I see having all these different paradigms and languages as a massive strength. I welcome them all.

daltont 5y ago
Not something on a scale of a project, but "bowling score" exercises are a lot more elegant in functional languages than more procedural ones due to things like pattern matching.
coyotespike 5y ago
I completely agree with this balanced take - it's all about context and making the right tradeoffs.

jerf 5y ago

I'm really tempted to write a blog post about "fake functional". The thing is, I really like functional. I really like Haskell. But most of the things that I like about Haskell aren't present when you rip things out of it willy-nilly and drop it into a language not designed for those idioms. The thing I like about functional programming is the fluid composition of all those ideas, and just dropping "map" or "option" doesn't mean you've got the fluid composition. Jamming functional paradigms into languages where they don't compose like they do in Haskell is just fake functional. I'd much rather work with a language in the space where it does provide fluid composition of its concepts then jam a foreign idiom into it and enter into a constant low-level war, where I'm likely going to have to roll out the Inner Platform gun to try to wrangle the language into being a bad imitation of another language. And that's a gun I want to be firing as a last resort, not using as my primary weapon.

coyotespike 5y ago
Really well put! Like, you wouldn't try for FP in Java, it's better suited for OOP, much of the time.
- int_19h 5y ago
  There are certainly bits and pieces associated with FP that are just as handy in Java. Discriminated unions with pattern matching, for example. Which is why those languages are also getting that stuff. C# already has matching (but not unions), and Java is on the way there.
WatchDog 5y ago
In contrast, I really like the simplistic functional elements added to a language, like the Java 8 stream API, but I feel like banging my head against a wall using scala with effects systems.
- jerf 5y ago
  I actually like some of the things added; being able to write a map function that takes an already-existing function and applies it to an array con be more convenient than the for loop. Depends on the language, obviously. What I dislike are people who get on a high horse about it, as if they're programming "functionally" and it's better than what everyone else in the language is doing. They're not "programming functionally", because they can't be, the language doesn't support it. A single map call is convenient. Sometimes you can put a couple of them together. Huge piles of code in imperative languages written in functional paradigms is a mess, because most of the putative advantages of functional aren't present. The one that I notice the most is that the "functional" paradigm embedded in imperative languages creates a barrier against refactoring. Sometimes it is simply that all the noise and chaff prevents programmers from seeing through to the underlying essense, and simply not realizing that if you have a recurring pattern of mapping the same three functions over an array in multiple places that you can in fact refactor that into a function. Sometimes, though, it's just not possible to refactor properly through inner platform you've introduced. Sometimes, refactoring is possible, but requires bringing in yet more firepower to get around the inner platform, like defunctionalization. By the time you're defunctionalizing something (by necessity, not choice) because of your inner platform to do something that would have been 4 lines of code in the original core language if you'd just used that, you're in deep trouble. And what's worse, people will call this good programming. It's just the functional programming equivalent of frameworkitis that you see in languages like Java. "We need all this machinery to program properly!" No. You don't.

dgb23 5y ago

I don’t disagree, but for someone who has been using JS for almost a decade, it is liberating and relaxing to use Clojure. Similar can be said about other languages that have a deliberate and thoughtful design.

facelessuser 5y ago
but for someone who has been using JS for almost a decade, it is liberating and relaxing to use Clojure. Can you elaborate what you find liberating and relaxing in Clojure vs modern JS? Putting aside runtime features like multi-threading the only thing I miss a bit after having use Clojure for one year was macros. But the for the rest, is all the same, just functions and data, and some polymorphic abstractions here and there.
- dgb23 5y ago
  Tons of things actually. If I have to choose a few: For one, JS feels clunkier with its expression/statement mish-mash. Once I started getting expression based syntax, everything made so much sense. It's such a simple feature that lets code compose granularily and is one of the key enablers for _seamless_ interactive development (and macros). One instance where this is pronounced is when you compare React JSX with Reagent and ClojureScript. Secondly, you can do FP in JS but no matter how you do it, it feels tacked on, is typically less performant, doesn't compose as well and relies more on discipline because it isn't the default. I'm not saying FP all the things either. It's just that in interactive web GUI's you have tons of state and asynchronicity, so the type of bugs and problems that occur from mismanaging those are incredibly frustrating. There are JS libraries that mutate the stuff you pass into for no reason at all. FP by default is very, very relaxing and composes well.
  - facelessuser 5y ago
    Sure but those are all minor things (and greatly exaggerated) in the grand scheme of shipping stuff and producing value IMO, today, a language being mainstream and its ecosystem matters. You are falling for the exact trap the article warns about. You'll say you can use the Java ecosystem but them you loose all the benefits you mentioned, you say you will keep interop/mutation/side effects isolated but then again you can do the same in JS if some lib is causing unwanted mutation. I have seen JS developers run in circles around Clojure developers because the JS devs have specialized in their language and ecosystem while the others keep moving between ecosystems and niche languages hoping for some magical thing that will fix all their problems. Rich Hickey is a great software engineer and software architect but what most don't notice is that he also is a good salesman.

JoelMcCracken 5y ago

while FP is hyped, it is also fundamentally good technology. I was very skeptical of Haskell for years, and finally really tried it, and I dont think I have ever changed my mind so completely on anything. Don't get me wrong. It has warts. And you're right, a jr who has problems with like configuring their environment variables correctly for example is going to really have a hard time. This is mostly why I think that while I'd still recommend Haskell to people, you can't just throw it on a team of newly grads and expect it to work out. Not that you can do that with JS either per se, but you CANNOT do it with Haskell. Sure, JS has warts, and a lot of them are bad, but heck, Haskell has a lot of warts too. They all have warts. Any language that has been around for any length of time has generally had its share of ideas which didn't really work out over the long term. For me the bigger issue with JS is the ecosystem quality. If you aren't on the golden path of package usage, you may find that you are in for a world of hurt.