What's wrong with Object-Oriented Programming and Functional Programming

Post by quchen » Tue, Nov 12, 2013, 2:34 PM UTC

pron wrote: post #62

jjaredsimpson wrote: post #56

Earlier quoted context omitted.

> but I think that the problem with the way it manages side effects is that it does so through lazy evaluation. This is not so. > and lazy evaluation is hard to wrap your head around. technically haskell is non-strict, not lazy. (a + (b * c)) evaluates + then * instead of * then +. Also strictness annotations can change this behavior. > They require programmers to think and program solely within Haskell's lambda calc…

This is another problem with Haskell: comments like this. But in order to be helpful, let me explain why. > technically Haskell is non-strict, not lazy. Now, see, I don't care. Neither does anyone really other than PL researchers. I mean, I can care in my spare time if I like spending it on PL research, but when I write a 2 MLOC software for a large customer, I couldn't care less whether "technically" it's "non-stric…

Post by quchen » Tue, Nov 12, 2013, 2:38 PM UTC

pron wrote: post #66

jeremyjh wrote: post #59

Earlier quoted context omitted.

Dabbling really is not enough to show you the problems with your assumptions. You are right that there is a cost, but it is really paid once up-front by each programmer. I could have written this same comment five months ago, before I started down the long dark tunnel of doom which is to go beyond LYAH and trying to write a real application. I think it was two months before I saw a light at the end of that tunnel - a…

I don't doubt you, but your experience also provides little evidence. Have you done profiling and performance analysis yet? Have you tried working in a large team on a large project? Different languages have different strengths. Some excel at quick and dirty prototyping or small projects/small teams. Others make a 50+ developer team more manageable. Some have good runtime performance, some have a shorter development…

Post by jimmaswell » Tue, Nov 12, 2013, 2:42 PM UTC

pron wrote: post #45

tikhonj wrote: post #16

This is a gross mischaracterization of functional programming and basically attacks a straw man--one that's lamentably common when talking about functional programming. I'm going to repost a comment I wrote on the blog. It's long and really needs editing, but I hope it gets my thoughts across. I think the part about OOP is also misguided, but it's so obviously tacked on to a rant about functional programming that I j…

The way Haskell manages side effects is inspired, and I don't think anyone can say that Haskell is not a beautiful and coherent language. I only dabbled in Haskell a bit so I may be wrong, but I think that the problem with the way it manages side effects is that it does so through lazy evaluation, and lazy evaluation is hard to wrap your head around. So I think that if there is one big problem with Haskell, it is thi…

Post by wes-exp » Tue, Nov 12, 2013, 3:07 PM UTC

Post by huherto » Tue, Nov 12, 2013, 3:32 PM UTC

tomp wrote: post #17

sorincos wrote: post #13

"The lack of first-class functions is the major reason why there are so many “design patterns” in Java. Once you have first-class functions, you will need almost none of the design patterns." Now this is a very bold statement. I'm dying to hear more on how you can get rid of design patterns with first-class functions. Does it mean getting rid as in: sharing knowledge is not needed anymore and programming becomes art…

FactoryFactoryFactoryClass, most of dependency injection frameworks, anonymous classes, several different one-method interfaces, (such as event handlers/observers), and probably more become unnecessary when you have first-class functions.