3 ms·

No need to kid. Self-described "FP" languages are a pain in the ass for the type of programming scientists do. I don't even know what kind of programming those

by tokipin 11y ago

No need to kid. Self-described "FP" languages are a pain in the ass for the type of programming scientists do. I don't even know what kind of programming those languages aren't a pain in the ass for.

fsloth 11y ago
"I don't even know what kind of programming those languages aren't a pain in the ass for." If we limit the discussion to ML languages, they are generally very nice e.g. for datastructure transforms (including interpreters and compilers). Static typing with type inference makes implementations short, and, if written in good style, are correct when they compile. There are various other reasons why one would not want to use them. For me it's platform stability and availability - while I enjoy functional languages in principle - I yet seem to choose C++ more often than not for my hobby projects. I would say learning self-described fp-languages have made me a better programmer who values static typing more than before.
- restalis 11y ago
  "I would say learning self-described fp-languages have made me a better programmer who values static typing more than before." FP paradigm has indeed didactic value and the experience gained in a functional language may translate into a plus of productivity ...in other languages. When you have to get things done, the functional language's embedded arm-twisting (well, mind-twisting actually) doesn't help! That's when you'll either abandon the (idea of) "pure" functional language for a multi-paradigm language (that will allow you to keep a mainly functional style with limited deviations when the situation warrants it) or you'll keep pushing yourself and throw the blame on you for not being good enough with a language that wasn't designed from very beginning for much anything but the FP standpoint (for the sake of it).
reverius42 11y ago
I could make the same assertion about "self-described OOP languages" or "self-described procedural languages" with just as much evidence. Once you've done it enough, all programming feels like a pain in the ass. I see FP languages being able to excel at the kind of projects with large, maintainable codebases that evolve over a decade and are shared between dozens of developers. Service oriented architectures serve the same goal -- isolating behavior and state locally, and being explicit about mutation and state changes over time.
hughw 11y ago
Using Scala, I've found the ability to pass around first class functions, and the default immutability of variables, enables me to make profound algorithmic optimizations I wouldn't undertake in C++ et al. Then, if the computation generates too much garbage or goes slowly in a loop, I can then take shortcuts, like using mutable local variables, to make that section go faster.

by tokipin 11y ago

No need to kid. Self-described "FP" languages are a pain in the ass for the type of programming scientists do. I don't even know what kind of programming those languages aren't a pain in the ass for.

fsloth 11y ago

"I don't even know what kind of programming those languages aren't a pain in the ass for." If we limit the discussion to ML languages, they are generally very nice e.g. for datastructure transforms (including interpreters and compilers). Static typing with type inference makes implementations short, and, if written in good style, are correct when they compile. There are various other reasons why one would not want to use them. For me it's platform stability and availability - while I enjoy functional languages in principle - I yet seem to choose C++ more often than not for my hobby projects. I would say learning self-described fp-languages have made me a better programmer who values static typing more than before.

restalis 11y ago
"I would say learning self-described fp-languages have made me a better programmer who values static typing more than before." FP paradigm has indeed didactic value and the experience gained in a functional language may translate into a plus of productivity ...in other languages. When you have to get things done, the functional language's embedded arm-twisting (well, mind-twisting actually) doesn't help! That's when you'll either abandon the (idea of) "pure" functional language for a multi-paradigm language (that will allow you to keep a mainly functional style with limited deviations when the situation warrants it) or you'll keep pushing yourself and throw the blame on you for not being good enough with a language that wasn't designed from very beginning for much anything but the FP standpoint (for the sake of it).

reverius42 11y ago

I could make the same assertion about "self-described OOP languages" or "self-described procedural languages" with just as much evidence. Once you've done it enough, all programming feels like a pain in the ass. I see FP languages being able to excel at the kind of projects with large, maintainable codebases that evolve over a decade and are shared between dozens of developers. Service oriented architectures serve the same goal -- isolating behavior and state locally, and being explicit about mutation and state changes over time.

hughw 11y ago

Using Scala, I've found the ability to pass around first class functions, and the default immutability of variables, enables me to make profound algorithmic optimizations I wouldn't undertake in C++ et al. Then, if the computation generates too much garbage or goes slowly in a loop, I can then take shortcuts, like using mutable local variables, to make that section go faster.