2 ms·

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 i

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. :)

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. :)