4 ms·

> ends up becoming an obfuscated mess of wrapper functions and custom control flow This right here is the reason I don't like pure functional programming. Any

> ends up becoming an obfuscated mess of wrapper functions and custom control flow This right here is the reason I don't like pure functional programming. Any engineer should be able to pick up your code and understand it pretty close to immediately. And with pure FP, even when they understand functional programming, they end up wasting valuable time tracking down what it is you're trying to do. * I guess I need to edit to say I mean pure FP in a language not explicitly built for pure FP. The article is about implementing in JS, this is what I'm addressing.

valenterry 4y ago
> Any engineer should be able to pick up your code and understand it pretty close to immediately. So a webdev should almost immediately pick up a mix of C++ and assembly? No. There's a reason we specialize. That is not a good argument against functional programming.
- borbulon 4y ago
  You're hitting a strawman here. I shouldn't have to explicitly say that I meant someone with at least some experience in the language you happen to be writing in.
  - Verdex 4y ago
    I'm not convinced that previous poster was hitting a strawman. Your argument (if I understand correctly) is that given some language (here javascript) that one ought not program in such a way that other people who use that language are incapable of understanding it. This example of FP involves a bunch of junk that makes javascript incomprehensible to javascriptors therefore it's bad. Now, previous poster replies with "Hey not everyone understands c++ and assembly ..." and this does sort of sound like a strawman, however we can extract the core argument as "there exist things which you haven't seen before which you don't understand, but that doesn't make them bad" and that does not sound like a strawman. That sounds like a legit argument. For example, perhaps there exists a library which performs some domain specific task using FFT, linear algebra, and distributed computing load balancer algorithms. All of it in javascript. An arbitrary javascript developer is probably not going to be able to understand what's going on. However, that wouldn't be a legit argument against FFT, linear algebra, or distributed computing load balancing algorithms. Specializations exist. Pure FP in javascript might not be a great idea, but it possibly confusing someone who otherwise knows javascript doesn't feel like a real argument against it to me.
    - 0x445442 4y ago
      But is the article/book actually advocating the idea that this non-idiomatic paradigm should only be used in very specific places in a code base where it’s objectively and demonstratably better? Or is the article/book advocating wide spread usage? I think it’s the latter and so I think the comment was a straw man. As an aside I think this a problem with kitchen sink languages that allow all these different paradigms. Maybe not so much with JavaScript because its roots are more functional but with Java where they’ve continually bolted on functional capabilities. With a language like Smalltalk, there is no idiomatic Smalltalk, just Smalltalk. I imagine something like Clojure is the same way. With these kitchen sink languages you can end up with code bases that vary wildly in style, especially if there’s been a lot of turnover in the project.
      - Verdex 4y ago
        With respect to your first point: Wide spread usage is a relative term. Like, if the a program just happens to be 99% FFT code, then you'll have "wide spread usage" of incomprehensible FFT code in the code base. This is a question of scope of the project. So I don't think that an argument becomes strawman just because most projects will probably be bigger than their specialized component. With respect to your second point: Hard agree. I think languages should have much more constrained focus that largely disallows an impedance mismatch between what you're trying to do and how you go about doing it. [Worth noting is that I largely agree with the points against this type of FP in javascript. However, I'm opposed to the line of reasoning that's being used against it. Something not being readily understood is not a good argument for rejection. Because anything worth doing that hasn't already been done is likely to be incomprehensible until you've spent some time with it.]
  - valenterry 4y ago
    Okay, I think your edit made it more clear. I would also not try to turn a javascript codebase into pure functional style. On that one I agree with you. :)
- jjav 4y ago
  > > Any engineer should be able to pick up your code and understand it pretty close to immediately. > So a webdev should almost immediately pick up a mix of C++ and assembly? There's a reason assembly has been relegated to very specific & specialized use cases. I'd almost want to say the same about C++. The best production code is very simple, very understandable.
  - valenterry 4y ago
    True, but I can extend my example to "javascript -> Haskell" or "Haskell -> Rust" or "Rust -> Prolog" - and vice vera. In every case, you can't just simply understand the code because you will have to learn new concepts first.
jerf 4y ago
There's a difference between "pure FP in an imperative-oriented language" and "pure FP in a pure-FP-oriented language". In Haskell, this isn't an obfuscated mess of wrapper functions and custom control flow, it's the most straightforward and sensible way to do things. Functions have very thin syntax and don't get in the way, laziness means you lose all the function wrappers that imperative languages add just for that, etc. Personally I find trying to write Haskell in an imperative language to make exactly as much sense as trying to write imperative code in Haskell. Same error, same reasons, same outcome.
- borbulon 4y ago
  I agree completely, but since the article is about writing JS in a pure FP manner, I was addressing that and not anything else.
  - jerf 4y ago
    That's fine. I just couldn't tell. I agree with you.
- PaulHoule 4y ago
  There's also a difference between a Scottsman and a "True Scottsman". There is a common story of a programmer who has journeyed like an itinerant martial artist looking for functional programming enlightenment but never finds it... Our industry is way too susceptible to snake oil stories like "If I wrote all my tests first my programs would never have any bugs" or "If I wrote my programs in Erlang they wouldn't have any bugs..." There are certain tasks for which functional programming idioms are highly effective, other ones where you will twist your brain into knots and end up writing completely unmaintainable code.
  - jerf 4y ago
    This is absolutely not a "true scotsman" argument. I am talking about very distinct classifications of languages, with wildly divergent feature sets, runtimes, libraries, and communities. The differences are real and objective. This is just a special case of the more general principle, "Don't write X in Y". Don't write BASIC in C. Don't write C in Python. Don't write FP in imperative. Don't write imperative in FP. Don't think you've solved whatever problems you have with Y when you're forced to use it by writing X in Y. Writing X in Y inevitably leads to the worst of both worlds, not the best.
steinuil 4y ago
I have to agree with you as far as pure functional programming goes. I also don't like the Haskell approach of of overgeneralizing concepts just because you can; it's the FP equivalent of stuffing every design pattern you can into your OO code. I'd argue that not every pure functional programming language has to be like that but I'm pretty sure all the ones that exist are.
- valenterry 4y ago
  Please don't mix the two things. There are a lot of abstractions in Haskell (monads, monoids, ...) but those are 100% orthogonal to pure functional programming. You can do the latter without any of those abstractions even existing in the language. And if you want to see an example for a language that is not like that, look at Scala and ZIO (www.zio.dev). It is a library for pure functional programming, but look at the examples - those abstractions you mention are not there. The library really aims at making concurrent/async programming easier by leveraging pure functional programming but without crazy category theory stuff.
  - steinuil 4y ago
    I did acknowledge that they are orthogonal when I said that not every pure FP language has to be like that. Thanks for pointing out ZIO, I didn't know about it.
    - valenterry 4y ago
      I know, but you also said "but I'm pretty sure all the ones that exist" so I wanted to show you a counter-example. I'm also not surprised by your thought, since you are right - most of the time it gets mixed, which is actually sad. We need more practical pure functional programming libraries that focus on tackling problems with concurrent updates, streaming, state-changes etc. without forcing you to take a course in category theory beforehand.
  - HelloNurse 4y ago
    Two other things that shouldn't be mixed are a programming language's features and what programmers are using them for. As noted in other comments, Haskell is good at defining all sorts of functions, but the card castles of excessive and inappropriate algebraic abstraction are a tradition of rather uniformly extremist Haskell users.

valenterry 4y ago

> Any engineer should be able to pick up your code and understand it pretty close to immediately. So a webdev should almost immediately pick up a mix of C++ and assembly? No. There's a reason we specialize. That is not a good argument against functional programming.

borbulon 4y ago
You're hitting a strawman here. I shouldn't have to explicitly say that I meant someone with at least some experience in the language you happen to be writing in.
- Verdex 4y ago
  I'm not convinced that previous poster was hitting a strawman. Your argument (if I understand correctly) is that given some language (here javascript) that one ought not program in such a way that other people who use that language are incapable of understanding it. This example of FP involves a bunch of junk that makes javascript incomprehensible to javascriptors therefore it's bad. Now, previous poster replies with "Hey not everyone understands c++ and assembly ..." and this does sort of sound like a strawman, however we can extract the core argument as "there exist things which you haven't seen before which you don't understand, but that doesn't make them bad" and that does not sound like a strawman. That sounds like a legit argument. For example, perhaps there exists a library which performs some domain specific task using FFT, linear algebra, and distributed computing load balancer algorithms. All of it in javascript. An arbitrary javascript developer is probably not going to be able to understand what's going on. However, that wouldn't be a legit argument against FFT, linear algebra, or distributed computing load balancing algorithms. Specializations exist. Pure FP in javascript might not be a great idea, but it possibly confusing someone who otherwise knows javascript doesn't feel like a real argument against it to me.
  - 0x445442 4y ago
    But is the article/book actually advocating the idea that this non-idiomatic paradigm should only be used in very specific places in a code base where it’s objectively and demonstratably better? Or is the article/book advocating wide spread usage? I think it’s the latter and so I think the comment was a straw man. As an aside I think this a problem with kitchen sink languages that allow all these different paradigms. Maybe not so much with JavaScript because its roots are more functional but with Java where they’ve continually bolted on functional capabilities. With a language like Smalltalk, there is no idiomatic Smalltalk, just Smalltalk. I imagine something like Clojure is the same way. With these kitchen sink languages you can end up with code bases that vary wildly in style, especially if there’s been a lot of turnover in the project.
    - Verdex 4y ago
      With respect to your first point: Wide spread usage is a relative term. Like, if the a program just happens to be 99% FFT code, then you'll have "wide spread usage" of incomprehensible FFT code in the code base. This is a question of scope of the project. So I don't think that an argument becomes strawman just because most projects will probably be bigger than their specialized component. With respect to your second point: Hard agree. I think languages should have much more constrained focus that largely disallows an impedance mismatch between what you're trying to do and how you go about doing it. [Worth noting is that I largely agree with the points against this type of FP in javascript. However, I'm opposed to the line of reasoning that's being used against it. Something not being readily understood is not a good argument for rejection. Because anything worth doing that hasn't already been done is likely to be incomprehensible until you've spent some time with it.]
- valenterry 4y ago
  Okay, I think your edit made it more clear. I would also not try to turn a javascript codebase into pure functional style. On that one I agree with you. :)
jjav 4y ago
> > Any engineer should be able to pick up your code and understand it pretty close to immediately. > So a webdev should almost immediately pick up a mix of C++ and assembly? There's a reason assembly has been relegated to very specific & specialized use cases. I'd almost want to say the same about C++. The best production code is very simple, very understandable.
- valenterry 4y ago
  True, but I can extend my example to "javascript -> Haskell" or "Haskell -> Rust" or "Rust -> Prolog" - and vice vera. In every case, you can't just simply understand the code because you will have to learn new concepts first.

jerf 4y ago

There's a difference between "pure FP in an imperative-oriented language" and "pure FP in a pure-FP-oriented language". In Haskell, this isn't an obfuscated mess of wrapper functions and custom control flow, it's the most straightforward and sensible way to do things. Functions have very thin syntax and don't get in the way, laziness means you lose all the function wrappers that imperative languages add just for that, etc. Personally I find trying to write Haskell in an imperative language to make exactly as much sense as trying to write imperative code in Haskell. Same error, same reasons, same outcome.

borbulon 4y ago
I agree completely, but since the article is about writing JS in a pure FP manner, I was addressing that and not anything else.
- jerf 4y ago
  That's fine. I just couldn't tell. I agree with you.
PaulHoule 4y ago
There's also a difference between a Scottsman and a "True Scottsman". There is a common story of a programmer who has journeyed like an itinerant martial artist looking for functional programming enlightenment but never finds it... Our industry is way too susceptible to snake oil stories like "If I wrote all my tests first my programs would never have any bugs" or "If I wrote my programs in Erlang they wouldn't have any bugs..." There are certain tasks for which functional programming idioms are highly effective, other ones where you will twist your brain into knots and end up writing completely unmaintainable code.
- jerf 4y ago
  This is absolutely not a "true scotsman" argument. I am talking about very distinct classifications of languages, with wildly divergent feature sets, runtimes, libraries, and communities. The differences are real and objective. This is just a special case of the more general principle, "Don't write X in Y". Don't write BASIC in C. Don't write C in Python. Don't write FP in imperative. Don't write imperative in FP. Don't think you've solved whatever problems you have with Y when you're forced to use it by writing X in Y. Writing X in Y inevitably leads to the worst of both worlds, not the best.

steinuil 4y ago

I have to agree with you as far as pure functional programming goes. I also don't like the Haskell approach of of overgeneralizing concepts just because you can; it's the FP equivalent of stuffing every design pattern you can into your OO code. I'd argue that not every pure functional programming language has to be like that but I'm pretty sure all the ones that exist are.

valenterry 4y ago
Please don't mix the two things. There are a lot of abstractions in Haskell (monads, monoids, ...) but those are 100% orthogonal to pure functional programming. You can do the latter without any of those abstractions even existing in the language. And if you want to see an example for a language that is not like that, look at Scala and ZIO (www.zio.dev). It is a library for pure functional programming, but look at the examples - those abstractions you mention are not there. The library really aims at making concurrent/async programming easier by leveraging pure functional programming but without crazy category theory stuff.
- steinuil 4y ago
  I did acknowledge that they are orthogonal when I said that not every pure FP language has to be like that. Thanks for pointing out ZIO, I didn't know about it.
  - valenterry 4y ago
    I know, but you also said "but I'm pretty sure all the ones that exist" so I wanted to show you a counter-example. I'm also not surprised by your thought, since you are right - most of the time it gets mixed, which is actually sad. We need more practical pure functional programming libraries that focus on tackling problems with concurrent updates, streaming, state-changes etc. without forcing you to take a course in category theory beforehand.
- HelloNurse 4y ago
  Two other things that shouldn't be mixed are a programming language's features and what programmers are using them for. As noted in other comments, Haskell is good at defining all sorts of functions, but the card castles of excessive and inappropriate algebraic abstraction are a tradition of rather uniformly extremist Haskell users.