5 ms·

1. This post would have been more interesting if the person he was having this dialog with was a PL researcher/designer. 2. Uncle Bob is trying to speak with a

1. This post would have been more interesting if the person he was having this dialog with was a PL researcher/designer. 2. Uncle Bob is trying to speak with authority, but this subject matter is outside his area of expertise. At least in his previous post, he was nice enough to state this up front: > Learning swift has been an interesting experience. The language is very opinionated about type safety. Indeed, I don't remember using a language that was quite so assiduous about types. 3. I see that Rust, Haskell, and OCaml were conveniently left out. He hand-waves away other modern languages with "negligible," which is hilarious because he is so obnoxiously wordy in the rest of this post. Not very convincing.

nickpeterson 10y ago
I like a lot of Uncle Bob's posts, but his opinion on functional languages is bizarre. He seems to like them (especially clojure), and talks about how they tend to force programmers to stick closer to patterns pretty universally regarded as better (immutability for instance), but then sort of punts when asked to compare them to OO languages. I think, to some degree, his belief in TDD, Solid Principles, and short cycles means that functional languages have less to offer developers than many think because he's comparing Java executed with excellent practices to stock functional languages. I think that C#, Java, and OO-design just leave too much room for developers to go astray. Something like F# results in better code not because of the features of the language, but because of what it doesn't allow.
- wpietri 10y ago
  Interesting! I agree entirely that Java and OO leave a lot of room for developer to go astray. And I've enjoyed my limited coding in functional languages. But is something like F# really better in practice? I ask because every functional-language code base I've been able to look at myself has two advantages: 1) it's not very large, and 2) it was made by very smart, experienced developers with a passion for functional languages. When I look at similarly sized OO code bases produced by people with similar levels of passion and expertise, the code base is also very good. The terrible Java code I've seen, on the other hand, mostly comes from less experienced people whose priorities are things like "keep boss happy", "put in all required hours", and "comply with project plan". Which is, sadly, the average case in the industry. So I'm wondering: What happens if some functional language becomes mainstream? Will junior programmers at EnormoBank's latest death march produce better software?
  - iopq 10y ago
    If Haskell becomes mainstream, there will be some absolutely horrifying Haskell code. But Haskell allows people who know what they're doing to also check that their code doesn't violate certain constraints. That means that the amount of work the compiler does is greater, which makes more guarantees about correctness. It's not about making the worst code less bad, it's about making the median project take less time and have less defects.
    - tinco 10y ago
      There already is some very horrifying Haskell code written by masters of the language. Well written Haskell in my opinion can be readily understood by anyone who has studied the language for a week or two (provided they are experienced programmers). The depth of potential for abstraction in Haskell is so tempting however that often clarity is lost in dense semantics.

nickpeterson 10y ago

I like a lot of Uncle Bob's posts, but his opinion on functional languages is bizarre. He seems to like them (especially clojure), and talks about how they tend to force programmers to stick closer to patterns pretty universally regarded as better (immutability for instance), but then sort of punts when asked to compare them to OO languages. I think, to some degree, his belief in TDD, Solid Principles, and short cycles means that functional languages have less to offer developers than many think because he's comparing Java executed with excellent practices to stock functional languages. I think that C#, Java, and OO-design just leave too much room for developers to go astray. Something like F# results in better code not because of the features of the language, but because of what it doesn't allow.

wpietri 10y ago
Interesting! I agree entirely that Java and OO leave a lot of room for developer to go astray. And I've enjoyed my limited coding in functional languages. But is something like F# really better in practice? I ask because every functional-language code base I've been able to look at myself has two advantages: 1) it's not very large, and 2) it was made by very smart, experienced developers with a passion for functional languages. When I look at similarly sized OO code bases produced by people with similar levels of passion and expertise, the code base is also very good. The terrible Java code I've seen, on the other hand, mostly comes from less experienced people whose priorities are things like "keep boss happy", "put in all required hours", and "comply with project plan". Which is, sadly, the average case in the industry. So I'm wondering: What happens if some functional language becomes mainstream? Will junior programmers at EnormoBank's latest death march produce better software?
- iopq 10y ago
  If Haskell becomes mainstream, there will be some absolutely horrifying Haskell code. But Haskell allows people who know what they're doing to also check that their code doesn't violate certain constraints. That means that the amount of work the compiler does is greater, which makes more guarantees about correctness. It's not about making the worst code less bad, it's about making the median project take less time and have less defects.
  - tinco 10y ago
    There already is some very horrifying Haskell code written by masters of the language. Well written Haskell in my opinion can be readily understood by anyone who has studied the language for a week or two (provided they are experienced programmers). The depth of potential for abstraction in Haskell is so tempting however that often clarity is lost in dense semantics.