Comment by ghodss | Hacker News Reader

Comment by ghodss | Hacker News Reader

I have always wondered why, if functional programming is such a good deal in terms of better abstractions, entire classes of bugs eliminated, cleaner code, etc., it doesn't come near-universally recommended by the world's most experienced programmers for mid- to high-level tasks. I'm thinking people like Martin Fowler, Donald Knuth, etc., but especially people like Rob Pike, Russ Cox, Guido van Rossum, Yukihiro Matsumoto, who are all incredibly smart and experienced engineers who have dedicated their lives to developing non-FP languages. There must be some trade-offs to FP that are almost never make it into these kinds of "FP has dramatically improved my life" articles.

(BTW I don't buy the "they're just not used to it" or "they're comfortable with what they know" explanation for this kind of people. These are not stodgy Java programmers who are working in programming as a day-job who are resistant to learning new things, they're people who know more about programming than a hundred average programmers combined and spend nearly every waking minute thinking about how to make it better.)

This is pure argument from authority, but I'm gonna take the bait anyway.

> Martin Fowler

What has this guy done except writing books about "the best way to program" without ever designing a full system himself ?

> Guido van Rossum, Yukihiro Matsumoto

Those guys are just language designers, and the language they designed are just as questionnable as the functional ones, so why do they get a pass actually ? Because their languages are more used ? Do you want to follow suit and say that COBOL creators are probably part of the "world's most experienced programmers" ? What about PHP ?

There are some good points and critiques about the practicality of functional languages, but you don't actually touch on any of them here.

I had a conversation with another semi-famous PL designer. Not one of the ones you list, but only a little below them. He primarily worked on languages the C/C++ family, and had no conception of the value of a closure.

There are lots of smart PL designers working systems languages, and there are lots of smart PL designers working on high-level, functional languages. That doesn't mean that either group is necessarily aware of everything the other group is doing, and it doesn't mean they share the same goals, experience, or taste.

Being smart doesn't make you a good engineer, and being a great language or library designer doesn't necessarily make you an authority on language selection for most engineering uses. Finally, take Pike and Cox and their work on Go. Go is a great minimum-change-for-engineers language for Google's purposes. Is it a great language for most? No. But if you're trying to introduce new concepts to thousands of C++ programmers at the same time, Go is a safer bet than trying to go full Haskell.

To further answer your question, "functional programming" isn't always so well-defined. We know, realistically, that pure functional programming isn't going to work for all use cases. Once you're grounded in FP, you think of mutable state (or, in databases, destructive updates and deletes) as an optimization... but sometimes it's an optimization that you need. No language is FP-only because no language can be; even Haskell has the "dirty" IO monad.

I think that most good programmers (like, 99%) recognize the importance of immutability and referential transparency, when possible, and in the function rather than the action being the standard compositional unit for programs. Where there is disagreement is on when, how, and how often to depart from the functional ideal.

I don't think I'd call the IO monad "dirty" since it's still pure. Also "dirty" make it sounds like a hack.

Pure manipulation of values describing impure computation.

Good point.

As codygman mentions the IO Monad doesn't make haskell impure.

unsafePerformIO :: IO a -> a on the other hand does make haskell impure when it is used. And it is used in many libraries.

> unsafePerformIO :: IO a -> a on the other hand does make haskell impure when it is used. And it is used in many libraries.

Hmm, does it really? Is 'unsafePerformIO (return 1)' impure?

"And it is used in many libraries."

Citation needed - or at least clarification as to what "many" means here.

Reply on news.ycombinator.com