I agree with everything in this article except its conclusion, that we should dump every existing language for new projects and switch to a pure functional one.
This ignores the tremendous experience and sunk costs we have in the JS/TS environment -- in which we have the ability to write fully functional programs if we want to. Does the compiler enforce it? No. Like Lisp on which it was partially based, JS lets you program in many paradigms.
The author admits that functional has a long on-ramp. It took me years to grok functional[0], and I met its inventor when I worked at IBM. If the difficulty is real, that's even more reason to provide a gradual path to functional by modifying portions of existing JS/TS programs to make them more functional. Since all useful programs have side effects (and all programming is imperative in execution), these abstractions are just for people -- not the underlying machines. There is no such thing as a pure functional program. All software is either more or less functional in style. JS/TS and its support of all the key pillars of functional, is an idea way to get there.
I can't help but agree with this post. In fact, my university makes it a standard
to teach Functional Programming via Haskell, it makes sense.
The trend in programming language design seems to be running away from mathematics
and complex problems, however the moment you remove these aspects from a language
the more error prone or resource heavy they become.
In fact, I'd like to add that, despite believing that side effects and global state
is essential for programming, we cannot simply ignore functional programming, instead
we should look to solve these problems and write error free code from a mathematical
viewpoint, thinking functional and then imperatively or object oriented or whatever.
2 comments
[ 4.6 ms ] story [ 17.7 ms ] threadThis ignores the tremendous experience and sunk costs we have in the JS/TS environment -- in which we have the ability to write fully functional programs if we want to. Does the compiler enforce it? No. Like Lisp on which it was partially based, JS lets you program in many paradigms.
The author admits that functional has a long on-ramp. It took me years to grok functional[0], and I met its inventor when I worked at IBM. If the difficulty is real, that's even more reason to provide a gradual path to functional by modifying portions of existing JS/TS programs to make them more functional. Since all useful programs have side effects (and all programming is imperative in execution), these abstractions are just for people -- not the underlying machines. There is no such thing as a pure functional program. All software is either more or less functional in style. JS/TS and its support of all the key pillars of functional, is an idea way to get there.
[0] https://medium.com/gitconnected/functional-programming-in-ty...
The trend in programming language design seems to be running away from mathematics and complex problems, however the moment you remove these aspects from a language the more error prone or resource heavy they become.
In fact, I'd like to add that, despite believing that side effects and global state is essential for programming, we cannot simply ignore functional programming, instead we should look to solve these problems and write error free code from a mathematical viewpoint, thinking functional and then imperatively or object oriented or whatever.