Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yinwang0.wordpress.com

Post reply on HN
Print view View original

61–70 of 145 posts

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

#61

Post by JoeAltmaier »

mercurial wrote: post #60
gbog wrote: post #48

Earlier quoted context omitted.

Well, that's for theory. In practice I have yet to see a big CRUD like Facebook rewritten functional style, and would very interested to check how this magically dissolve the inherent complexity of such a beast. Until then, I'd continue to think that functional is shiny and sexy but that the proven and pragmatic way to keep complexity in check is still the good old and boring oop way.

I don't think anybody is claiming that functional programming makes complexity magically go away. The claim is that functional programming (especially when backed by a strong static type system) makes several categories of issues essentially disappear. That's a much more reasonable claim to make.

And a very powerful property. Never mind conserving CPU or memory; the slowest component in any system is the wetware programming the system: you. I always try to use tools and techniques that eliminate the possibility of categories of bugs. I use scope to control use-counting when possible; I use as strong a type as is helpful in the tool I'm using etc.

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

#62

Post by pron »

jjaredsimpson wrote: post #56
pron wrote: post #45

Earlier quoted context omitted.

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…

> 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-strict" or "lazy". As far as I, the programmer, is concerned, it's lazy. If one must be this familiar with PL jargon in order to program Haskell, then this is a problem.

> but don't pretend its a feature of humanity. All runtimes come with assumptions.

Again, I'm not trying to make a provable statement (how does that joke go? you can tell if someone is a mathematician if everything they tell you is all true and all irrelevant). We're talking software engineering, right? So what percentage of production code anywhere in the world is written in an eager (strict, whatever) language? If you tell me it's less than 99.999%, then you're being dishonest. 99.999% is a "feature of humanity". If your point is that education can change people's habit and way of thinking, I say, you're absolutely right. Go for it, and we'll talk again in 15 years.

> All runtimes come with assumptions.

Again, true but irrelevant. Some assumptions are more familiar and therefore feel more "natural",and some are less so.

I wasn't dissing Haskell. It's a very impressive and elegant language. I was only pointing out that while it has some advantages from a software engineering perspective, it also has some disadvantage.

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

#63

Post by hisham_hm »

DanWaterworth wrote: post #47
pron wrote: post #45

Earlier quoted context omitted.

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…

> the way it manages side effects is that it does so through lazy evaluation This is actually not true. Lazy evaluation forced Haskell to stay pure, but it is purity that provides the tools for constraining effects. You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

> You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

I'm unaware of any strict purely functional language with monads. Could you give an example? Thanks!

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

#64

Post by DanWaterworth »

hisham_hm wrote: post #63
DanWaterworth wrote: post #47

Earlier quoted context omitted.

> the way it manages side effects is that it does so through lazy evaluation This is actually not true. Lazy evaluation forced Haskell to stay pure, but it is purity that provides the tools for constraining effects. You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

> You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist. I'm unaware of any strict purely functional language with monads. Could you give an example? Thanks!

Idris is one example.

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

#65

Post by DanWaterworth »

pron wrote: post #57
DanWaterworth wrote: post #47

Earlier quoted context omitted.

> the way it manages side effects is that it does so through lazy evaluation This is actually not true. Lazy evaluation forced Haskell to stay pure, but it is purity that provides the tools for constraining effects. You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

Isn't the side effect returned as an IO type which is later evaluated by the runtime? (I'm talking about Haskell)

Yes, but you can create the thing of type `IO a` strictly.

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

#66

Post by pron »

jeremyjh wrote: post #59
pron wrote: post #45

Earlier quoted context omitted.

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…

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 time, while others have better runtime monitoring and maintenance tools. No language excels in all of these.

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

#68

Post by pron »

DanWaterworth wrote: post #65
pron wrote: post #57

Earlier quoted context omitted.

Isn't the side effect returned as an IO type which is later evaluated by the runtime? (I'm talking about Haskell)

Yes, but you can create the thing of type `IO a` strictly.

Yes, but when are they executed? When is the byte written to the file?

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

#70

Post by DanWaterworth »

pron wrote: post #68
DanWaterworth wrote: post #65

Earlier quoted context omitted.

Yes, but you can create the thing of type `IO a` strictly.

Yes, but when are they executed? When is the byte written to the file?

Well, you certainly can't start executing until the `IO a` thing has been evaluated, but there aren't any other constraints.

Something that can confuse people (and I'm not sure if this is the case with you or not) is that an `IO a` may/probably will contain a closure. So evaluation and execution are interleaved, but not because of laziness.

Post reply on HN