4 ms·

Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their pr

Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations. Those hybrid languages (e.g. Python, F#, and Scala) are great for new development but awful when you have to maintain low-quality legacy code. That said... I think that observation applies far beyond functional programming. (It's rare, but certainly possible, for bad Haskell code to exist.) A common impetus behind language churn is the programmer's desire to justify green-field development (which is fun, even in C++) instead of career-damning legacy maintenance (which is unpleasant, even in good languages). Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory. This is an exaggeration of that prejudice. I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. Functor, monoid, and monad sound a lot scarier than they actually are.

rtpg 12y ago
pedantic, but I really wouldn't call Python a hybrid language on the same level as F# and Scala. Python's functional programming capabilities are pretty poor (not to mention that things like TCO are missing). Not to say that Python is a bad language, but having continuously tried to program in a functional style I've found that more iterative-seeming code ends up being more idiomatic and maintainable. > do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. That is extremely true. Even in widely-used packages, you'll rarely find good official documentation (quickstarts or the like). Sure, for a lot of packages , types are good enough (if you have a package to read a CSV file, all you need to do is find the CSVConf -> Handle -> [[String]] function), but with the bigger, more framework-y packages, there are so many types internal to the system that you _have_ to read through everything to do even simple things. Too much time is spent trying to explain how the language (which ends up being simple) works and not enough time on practical guides on how to actually do things. This has become a bit of a rant, but in Math (the kind most people go through in middle school), you always learn specific cases before going into general theory. Unfortunately, a lot of Haskellers end up being mathematicians of the PhD style, where they're fine with just going into general theory. Examples are useful!
wavegeek 12y ago
> awful when you have to maintain low-quality legacy code When is it not awful to maintain low-quality legacy code?
the_af 12y ago
> I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) [...] Well, the unofficial motto of the Haskell community is "avoid success at all costs" after all :) [1] [1] https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p...

rtpg 12y ago

pedantic, but I really wouldn't call Python a hybrid language on the same level as F# and Scala. Python's functional programming capabilities are pretty poor (not to mention that things like TCO are missing). Not to say that Python is a bad language, but having continuously tried to program in a functional style I've found that more iterative-seeming code ends up being more idiomatic and maintainable. > do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. That is extremely true. Even in widely-used packages, you'll rarely find good official documentation (quickstarts or the like). Sure, for a lot of packages , types are good enough (if you have a package to read a CSV file, all you need to do is find the CSVConf -> Handle -> [[String]] function), but with the bigger, more framework-y packages, there are so many types internal to the system that you _have_ to read through everything to do even simple things. Too much time is spent trying to explain how the language (which ends up being simple) works and not enough time on practical guides on how to actually do things. This has become a bit of a rant, but in Math (the kind most people go through in middle school), you always learn specific cases before going into general theory. Unfortunately, a lot of Haskellers end up being mathematicians of the PhD style, where they're fine with just going into general theory. Examples are useful!

wavegeek 12y ago

> awful when you have to maintain low-quality legacy code When is it not awful to maintain low-quality legacy code?

the_af 12y ago

> I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) [...] Well, the unofficial motto of the Haskell community is "avoid success at all costs" after all :) [1] [1] https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p...