4 ms·

> the tutorials were self-absorbed in the accoutrements of functional programming At least this has probably improved since then.

PaulRobinson 5y ago
His point seems to have been that the tutorials were like that, because the languages were like that. Functional languages born out of theoretical concerns and commentary tend to prioritise the art of the possible, not the art of the needed. His point - and I've only ever dabbled with Erlang, so can't attest whether he's right or not - is that as a functional language born out of real industrial practice, Erlang prioritises other things that interest him more. He makes a compelling case. Most Erlang programmers do. And unlike proponents of many other languages they can point to decades of industrial success. Those tutorials of other languages can't. They exist because they can, and that's fine, but if you're building stuff salaries - maybe even lives - rely on, maybe those accoutrements are more distraction than essential feature.
- noir_lord 5y ago
  It's part of the essential dichotomy of programming languages. Pragmatic languages and theoretical languages (that may or may not be pragmatic). As a "working" developer I've always preferred pragmatic languages (the more advanced Pascals back in the day, C#, TypeScript etc) over the theoretically "beautiful" languages. Of course the barriers are permeable and we often get the useful parts from the theoretically beautiful languages eventually and that's great - I trust the creators of the pragmatic languages to apply taste to which features we eventually do get.
- pjmlp 5y ago
  Well, as someone that really enjoys C++ despite the flaws inherited from C, that is how many conference talks feel like in a language with years of industrial practice. Not "How I did this product in C++", rather how I mastered template meta-programming and SFINAE to build this gorgeous data structure that picks an element in under 5ms using 10KB max. /s. So FP is not alone in this kind of stuff.

PaulRobinson 5y ago

His point seems to have been that the tutorials were like that, because the languages were like that. Functional languages born out of theoretical concerns and commentary tend to prioritise the art of the possible, not the art of the needed. His point - and I've only ever dabbled with Erlang, so can't attest whether he's right or not - is that as a functional language born out of real industrial practice, Erlang prioritises other things that interest him more. He makes a compelling case. Most Erlang programmers do. And unlike proponents of many other languages they can point to decades of industrial success. Those tutorials of other languages can't. They exist because they can, and that's fine, but if you're building stuff salaries - maybe even lives - rely on, maybe those accoutrements are more distraction than essential feature.

noir_lord 5y ago
It's part of the essential dichotomy of programming languages. Pragmatic languages and theoretical languages (that may or may not be pragmatic). As a "working" developer I've always preferred pragmatic languages (the more advanced Pascals back in the day, C#, TypeScript etc) over the theoretically "beautiful" languages. Of course the barriers are permeable and we often get the useful parts from the theoretically beautiful languages eventually and that's great - I trust the creators of the pragmatic languages to apply taste to which features we eventually do get.
pjmlp 5y ago
Well, as someone that really enjoys C++ despite the flaws inherited from C, that is how many conference talks feel like in a language with years of industrial practice. Not "How I did this product in C++", rather how I mastered template meta-programming and SFINAE to build this gorgeous data structure that picks an element in under 5ms using 10KB max. /s. So FP is not alone in this kind of stuff.