4 ms·

Functional languages may be overrated, but not nearly as overrated as imperative languages (especially Python and Java). At the very least, avoiding Haskell is-

by tikhonj 14y ago

Functional languages may be overrated, but not nearly as overrated as imperative languages (especially Python and Java). At the very least, avoiding Haskell is--unfortunately--quite easy; avoiding Java or Python in most places is nigh impossible. The past post he references can be summarized by its last sentence: "I seriously don't get it." It spends quite a bit of effort telling us very little about functional languages but quite a bit about the author. And, as usual, he mistakes difficultly for complexity--just because something is new and mind-bending does not mean it is complex; it could just be a little tricky to pick up. (This is where Rich Hickey's "Simple Made Easy" talk really shines.) And, of course, in the current post he misrepresents the main case for functional programming. Which is--quite critically--not concurrency or parallelism! These are, in fact, just nice benefits. The main point is using a higher level of abstraction, reducing coupling, simplifying code, writing less code to do more and making it easy to reason about and verify. If all you care about is concurrency, Haskell is probably not your best bet. But if you care about writing maintainable, reusable and more general code more quickly and without sacrificing too much performance, it is. I would--without thinking twice--use Haskell to write programs in a completely single-threaded world. Haskell may also be good at dealing with concurrent nonsense, but this is really just a symptom of a deeper cause: Haskell is good at dealing with complexity. If that doesn't convince you, Haskell also comes with a ton of shiny toys like QuickCheck and Parsec. It might not have the biggest collection of libraries, but it probably does have one of the most innovative.

soup10 14y ago
Programming languages can strive to be either tools or toys. Programming languages that strive to be tools focus on high quality standard libraries, speed, good debugging facilities, being easy to learn, ability to handle large projects, and hardware support among other things. Toy languages strive to be innovative and explore new depths of computer science. Which is all well and good, but it's pretty annoying when people compare them with 'real' programming languages.
- Scriptor 14y ago
  That's true, actual tools need all those criteria that you described. If you believe that functional languages don't meet those criteria, can you provide evidence for that? For example, from what I've gathered Clojure certainly has high quality libraries, an emphasis on speed when needed (performance is frequently superior to Python's), has debugging facilities, is easy to learn for someone with functional experience (just as Python or Java are relatively easy to learn for those with imperative experience) and can still be picked up with a little extra work otherwise, and has been used in production in large projects. I don't know about its hardware support so I won't comment on that.
- derleth 14y ago
  > high quality standard libraries, speed, good debugging facilities, being easy to learn, ability to handle large projects, and hardware support among other things. Hm. C has three, at most four of those desiderata. It lacks good debugging facilities, especially compared to what a real (Smalltalk or Lisp, for example) debugger can do, it is about as easy to learn as driving a car with manual transmission, manual steering, and inadequate brakes, and it is so lacking in support for programming in the large that people were willing to put up with 1990s-era C++. So is C a toy?
  - dchichkov 14y ago
    Right. And also this 'real' debugger would not be predictable, would crash, wouldn't work with my favorite environment, would be a hell to install, etc... No, thank you very much, good old GDB is fine with me.
    - derleth 14y ago
      None of those things are or were problems with Smalltalk and Lisp environments. You might as well rattle off the potential downsides of using a compiler instead of writing machine code by hand.
  - kaffiene 14y ago
    Disagree. C has good debuggers - visual c++ is fine. In my opinion, C has all the features that the parent post was referring to (you might quibble about being easy to learn, but I'd also quibble whether a tool needs to be easy to learn)
bunderbunder 14y ago
Reducing coupling and cutting down on code volume is also supposed to be one of the big wins for object-oriented programming. Incidentally, the languages which I've found to do the best in this department are both object-oriented and functional. This is because one facilitates reusing datatypes while encouraging coupling to operations, while the other facilitates operation reuse while encouraging coupling to datatypes[1]. Since it's desirable to minimize coupling in both respects, being able to choose the better tool for the job in a context-dependent manner rather convenient. Incidentally, I find myself wondering why so many functional programming advocates nowadays seem to be caught up on the myths that object-oriented programming and functional programming are incompatible, or that object-oriented code is inherently messy and difficult to maintain. It makes me wonder if there are a whole lot of people out there whose only experience with object-oriented programming is the way things tend to get done in C++ or something like that. [1] This tension is described fairly well in Philip Wadler's essay The Expression Problem: http://www.daimi.au.dk/~madst/tool/papers/expression.txt http://www.daimi.au.dk/~madst/tool/papers/expression.txt
kaffiene 14y ago
If getting a lot of real work done is overrated, then yes, Java is overrated.
smsm42 14y ago
I'm sorry but I don't see how a language that reasonably smart person, having more than a decade working experience in all kinds of computer environments is unable to master, can be described as anything but "complex". I think using semantic games to reframe the problem does not change its essence - these tools are as easy to use as painting a delicate china vase standing on your head while riding a unicycle. Sure, there are a lot of people among 7 billions of world population that can learn the trick. But telling me it's simple is not actually going to do anything but ruin my confidence in your explanations - I tried it and I know it's anything but. And so did many other people and arrived to the same conclusion. You may argue that it doesn't matter as concurrency and raising complexity will force everybody to go FP or be crushed under the complexity of other solutions. That may be fine argument for FP being inevitable, but it in no way makes FP simple.
- bunderbunder 14y ago
  You may argue that it doesn't matter as concurrency and raising complexity will force everybody to go FP or be crushed under the complexity of other solutions. That may be fine argument for FP being inevitable... Except that that argument would fall on the wrong side of history. Most the really big examples of successful high-concurrency systems are programmed using imperative languages, and have been all along. And they do it using mostly the same habits that a lot of FP advocates would like to suggest are the exclusive domain of functional languages. Personally I like to think of them less as an excuse for functional apotheosis than as "elementary coding standards", but I learned Lisp before C++ so perhaps I'm just showing my age there. Now there are spots where FP offers a serious win on the concurrency front. Continuation passing comes to mind immediately. It'd be nice if the outspoken contingent of FP fans would spend a bit more time talking up node.js. But I suppose it's silly to expect Javascript to be held up as a successful functional language. It spends much too much time rubbing elbows with the object-oriented hoi polloi for that.
  - smsm42 14y ago
    I think functional aspects of JS are awesome and are of great use in a lot of cases. However it definitely lacks the purity of languages like Haskell or Clojure - which in my view makes it 1000 times more useful (when measured by my productivity using that to achieve any practical task) but I guess in the eyes of purists it makes it irrelevant or unworthy.

by tikhonj 14y ago

soup10 14y ago

Programming languages can strive to be either tools or toys. Programming languages that strive to be tools focus on high quality standard libraries, speed, good debugging facilities, being easy to learn, ability to handle large projects, and hardware support among other things. Toy languages strive to be innovative and explore new depths of computer science. Which is all well and good, but it's pretty annoying when people compare them with 'real' programming languages.

Scriptor 14y ago
That's true, actual tools need all those criteria that you described. If you believe that functional languages don't meet those criteria, can you provide evidence for that? For example, from what I've gathered Clojure certainly has high quality libraries, an emphasis on speed when needed (performance is frequently superior to Python's), has debugging facilities, is easy to learn for someone with functional experience (just as Python or Java are relatively easy to learn for those with imperative experience) and can still be picked up with a little extra work otherwise, and has been used in production in large projects. I don't know about its hardware support so I won't comment on that.
derleth 14y ago
> high quality standard libraries, speed, good debugging facilities, being easy to learn, ability to handle large projects, and hardware support among other things. Hm. C has three, at most four of those desiderata. It lacks good debugging facilities, especially compared to what a real (Smalltalk or Lisp, for example) debugger can do, it is about as easy to learn as driving a car with manual transmission, manual steering, and inadequate brakes, and it is so lacking in support for programming in the large that people were willing to put up with 1990s-era C++. So is C a toy?
- dchichkov 14y ago
  Right. And also this 'real' debugger would not be predictable, would crash, wouldn't work with my favorite environment, would be a hell to install, etc... No, thank you very much, good old GDB is fine with me.
  - derleth 14y ago
    None of those things are or were problems with Smalltalk and Lisp environments. You might as well rattle off the potential downsides of using a compiler instead of writing machine code by hand.
- kaffiene 14y ago
  Disagree. C has good debuggers - visual c++ is fine. In my opinion, C has all the features that the parent post was referring to (you might quibble about being easy to learn, but I'd also quibble whether a tool needs to be easy to learn)

bunderbunder 14y ago

Reducing coupling and cutting down on code volume is also supposed to be one of the big wins for object-oriented programming. Incidentally, the languages which I've found to do the best in this department are both object-oriented and functional. This is because one facilitates reusing datatypes while encouraging coupling to operations, while the other facilitates operation reuse while encouraging coupling to datatypes[1]. Since it's desirable to minimize coupling in both respects, being able to choose the better tool for the job in a context-dependent manner rather convenient. Incidentally, I find myself wondering why so many functional programming advocates nowadays seem to be caught up on the myths that object-oriented programming and functional programming are incompatible, or that object-oriented code is inherently messy and difficult to maintain. It makes me wonder if there are a whole lot of people out there whose only experience with object-oriented programming is the way things tend to get done in C++ or something like that. [1] This tension is described fairly well in Philip Wadler's essay The Expression Problem: http://www.daimi.au.dk/~madst/tool/papers/expression.txt http://www.daimi.au.dk/~madst/tool/papers/expression.txt

kaffiene 14y ago

If getting a lot of real work done is overrated, then yes, Java is overrated.

smsm42 14y ago

I'm sorry but I don't see how a language that reasonably smart person, having more than a decade working experience in all kinds of computer environments is unable to master, can be described as anything but "complex". I think using semantic games to reframe the problem does not change its essence - these tools are as easy to use as painting a delicate china vase standing on your head while riding a unicycle. Sure, there are a lot of people among 7 billions of world population that can learn the trick. But telling me it's simple is not actually going to do anything but ruin my confidence in your explanations - I tried it and I know it's anything but. And so did many other people and arrived to the same conclusion. You may argue that it doesn't matter as concurrency and raising complexity will force everybody to go FP or be crushed under the complexity of other solutions. That may be fine argument for FP being inevitable, but it in no way makes FP simple.

bunderbunder 14y ago
You may argue that it doesn't matter as concurrency and raising complexity will force everybody to go FP or be crushed under the complexity of other solutions. That may be fine argument for FP being inevitable... Except that that argument would fall on the wrong side of history. Most the really big examples of successful high-concurrency systems are programmed using imperative languages, and have been all along. And they do it using mostly the same habits that a lot of FP advocates would like to suggest are the exclusive domain of functional languages. Personally I like to think of them less as an excuse for functional apotheosis than as "elementary coding standards", but I learned Lisp before C++ so perhaps I'm just showing my age there. Now there are spots where FP offers a serious win on the concurrency front. Continuation passing comes to mind immediately. It'd be nice if the outspoken contingent of FP fans would spend a bit more time talking up node.js. But I suppose it's silly to expect Javascript to be held up as a successful functional language. It spends much too much time rubbing elbows with the object-oriented hoi polloi for that.
- smsm42 14y ago
  I think functional aspects of JS are awesome and are of great use in a lot of cases. However it definitely lacks the purity of languages like Haskell or Clojure - which in my view makes it 1000 times more useful (when measured by my productivity using that to achieve any practical task) but I guess in the eyes of purists it makes it irrelevant or unworthy.