3 ms·

I found Bracha's talk poor. That guy really has a chip on his shoulder vis-a-vis functional programming. A lot of things he said were not well though out. Here

by mafribe 13y ago

I found Bracha's talk poor. That guy really has a chip on his shoulder vis-a-vis functional programming. A lot of things he said were not well though out. Here are some examples. - He claimed that tail recursion could be seen as the essence of functional programming. How so? - He complained that tail recursion has problems with debugging. Well, tail recursion throws away stack information, so it should not be a surprise. You don't get better debug information in while loops either. And you can use a 'debug' flag to get the compiler to retain the debug information (at the cost of slower execution). - His remarks about Hindley-Milner being bad are bizarre. Exactly what is his argument? - His claims about pattern-matching are equally poor. Yes, pattern matching does some dynamic checks, and in some sense are similar to reflection. But the types constrain what you can do, removing large classes of error possibilities. Moreover, typing of patterns can give you compile-time exhaustiveness checks. Pattern matching has various other advantages, such as locally scoped names for subcomponents of the thing you are matching against, and compile-time optimisation of matching strategies. - He also repeatedly made fun of Milner's "well-typed programs do not go wrong", implying that Milner's statement is obviously non-sense. Had he studied Milner's "A Theory of Type Polymorphism in Programming" where the statement originated, Bracha would have learned that Milner uses a particular understanding of going wrong which does not mean complete absence of any errors whatsoever. Milner uses a peculiar meaning, and in Milner's sense, well-typed programs do indeed not go wrong. - He also criticises patterns for not being first-class citizens. Of course first-class patterns are nice, and some languages have them, but there are performance implications of having them. - His critique of monads was focussed on something superficial, how they are named in Haskell. But the interesting question is: are monads a good abstraction to provide in a programming language? Most languages provide special cases: C has the state monad, Java has the state and exception monad etc. There are good reasons for that. - And yes, normal programmers could have invented monads. But they didn't. Maybe there's a message in this failure?

the_af 13y ago
Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge. It is instructive to read Bracha's blog too, mostly for the comments where readers refute a lot of what he claims. His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production? He also presents Scala as a successful marriage between OOP and FP, but in reality this is a controversial issue. Some of the resistance to Scala (witnessed here in Hacker News, for example) is due to it trying to be a jack of all trades and master of none. Scala's syntax is arguably _harder to read_ than that of other FP languages. Some of his "funny" remarks sounded mean-spirited to me. Nobody in his right mind claims that FP invented map or reduce, for example. The only point of his talk I somewhat agree with is that language evangelists are annoying. Oh, and that "return" is poorly named.
- newgame 13y ago
  > His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production? He pointed out that a more nominal type system is a solution. Because when you give meaningful names to your types the error messages will become clearer and not full of long, inferred types that reveal potentially confusing or unimportant implementation details.
  - mafribe 13y ago
    Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names. More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any even moderately experienced programmer can easily detect and fix typing errors as they are given in Haskell, Ocaml, F#, Scala etc.
    - deleted 13y ago
      [deleted]
qu1j0t3 13y ago
Recursion and iteration are equivalent, so it's not much of a stretch to call it a core concept (for more, see SICP & the lambda calculus). It is the only form of iteration available in functional programming. Monads are not only a good abstraction, they are essential* if we are to move away from haphazard construction. Normal programmers have invented them many times; as the truism goes, you have have even "invented" them yourself. Remember when function pointers seemed tricky and unnecessary? Remember when closures seemed tricky and unnecessary? Yeah. One day you're going to see monads in the same way. * - Functional programming => programming with pure functions.

by mafribe 13y ago

the_af 13y ago

Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge. It is instructive to read Bracha's blog too, mostly for the comments where readers refute a lot of what he claims. His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production? He also presents Scala as a successful marriage between OOP and FP, but in reality this is a controversial issue. Some of the resistance to Scala (witnessed here in Hacker News, for example) is due to it trying to be a jack of all trades and master of none. Scala's syntax is arguably _harder to read_ than that of other FP languages. Some of his "funny" remarks sounded mean-spirited to me. Nobody in his right mind claims that FP invented map or reduce, for example. The only point of his talk I somewhat agree with is that language evangelists are annoying. Oh, and that "return" is poorly named.

newgame 13y ago
> His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production? He pointed out that a more nominal type system is a solution. Because when you give meaningful names to your types the error messages will become clearer and not full of long, inferred types that reveal potentially confusing or unimportant implementation details.
- mafribe 13y ago
  Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names. More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any even moderately experienced programmer can easily detect and fix typing errors as they are given in Haskell, Ocaml, F#, Scala etc.
  - deleted 13y ago
    [deleted]

qu1j0t3 13y ago

Recursion and iteration are equivalent, so it's not much of a stretch to call it a core concept (for more, see SICP & the lambda calculus). It is the only form of iteration available in functional programming. Monads are not only a good abstraction, they are essential* if we are to move away from haphazard construction. Normal programmers have invented them many times; as the truism goes, you have have even "invented" them yourself. Remember when function pointers seemed tricky and unnecessary? Remember when closures seemed tricky and unnecessary? Yeah. One day you're going to see monads in the same way. * - Functional programming => programming with pure functions.