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

141–145 of 145 posts

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

#141

Post by gizmo686 »

andreasvc wrote: post #140
gizmo686 wrote: post #128

Earlier quoted context omitted.

Consider '||' as a normal function. Consider ||(f(x),g(x)). If this were strictly evaluated, we would compute f(x) and g(x), then pass them as arguments to ||. Instead, we compute f(x) pass it to ||, and compute g(x) only if it is needed. This is lazy evaluation.

Well, the Boolean operators in C-like languages are NOT normal functions, which is the point. Furthermore, what is strict about them is the order in which their operands are evaluated, which is a different aspect than the one you mention: whether all arguments are evaluated before considering the function. Consider e.g., notUnderAttack() || enableDoomsdayDevice(). A lazy language is free to decide that it's more opti…

I don't think a lazy language can necessarily make that decision. Consider the simple implementation of ||:

  ||(f,g){
    if (eval(f)) then return true
    if (eval(g)) then return true
    return false
  }
A lazy language will not evaluate a function until it knows it needs it. In this implementation, there is no way of knowing that g will be needed until after computing f, so f will be computed first. Having said that, it is possible for an optimizing compiler to realize that the order doesn't matter and make a decision on which one to check first, however that is an optimization that the compiler would need to prove does not change the results.

This seems like a good example of why purity seems to be really beneficial to lazy evaluation.

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

#142

Post by voxfrege »

andreasvc wrote: post #140
gizmo686 wrote: post #128

Earlier quoted context omitted.

Consider '||' as a normal function. Consider ||(f(x),g(x)). If this were strictly evaluated, we would compute f(x) and g(x), then pass them as arguments to ||. Instead, we compute f(x) pass it to ||, and compute g(x) only if it is needed. This is lazy evaluation.

Well, the Boolean operators in C-like languages are NOT normal functions, which is the point. Furthermore, what is strict about them is the order in which their operands are evaluated, which is a different aspect than the one you mention: whether all arguments are evaluated before considering the function. Consider e.g., notUnderAttack() || enableDoomsdayDevice(). A lazy language is free to decide that it's more opti…

> Well, the Boolean operators in C-like languages are NOT normal functions, which is the point.

"Not normal", because the language is strict, and there is no way to make a lazy function on your own, even when it is so tremediously useful.

In other words, the C standard comittee decides which functions may be lazy. As a Haskell programmer, you decide.

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

#143

Post by aufreak3 »

aufreak3 wrote: post #102

I was reminded of Anton van Straaten's "koan" on closures vs. objects with venerable master Qc Na [1] ... but I digress. This post is actually a troll post designed to re-ignite fiery discussions about which is the superior PoV - functional or oop - and I'm going to bite. The only point I'm willing to give is the somewhat sane zen-like advise of "don't fall in love with your models". Regarding OOP, I recall Alan Kay…

The Alan Kay reference is from his OOPSLA'97 talk [2], where he says that he's "apologized profusely over the last 20 years for introducing the term 'object oriented'" and suggests that the Japanese notion of "Ma" or "the unseen stuff that goes between objects" as what is important.

(edit) [3] is a quote from a communication with Kay in 2003 -

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."

[2] https://www.youtube.com/watch?v=oKg1hTOQXoY (around 38minutes)

[3] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

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

#144

Post by asgard1024 »

literon wrote: post #137
asgard1024 wrote: post #134

Earlier quoted context omitted.

I also started to study Haskell recently. In my view, it's great from mathematical perspective, but it has its problems. Monads sort of force you to make plumbing visible, and it's not so neat as a result. For example, consider a big program that has two modules. The module A calls module B to do something. Now later, you want to add logging to the application. In normal languages, you can just call logging functions…

I don't think the "Xy monad will taint all your code" stands. I used to think that too, but if you have monadic code M and pure code P, if you need to tie P to M (say at a third callsite C), you just lift the P into the monad at C, and that's it. P stays pure, C of course gets monadic, but that is since it _is_ monadic. Now logging: I guess people overpanic this. There are two separate sides of logging I think: 1) Ef…

I am aware of lifting, but the question is if you have monadic code and pure code in different modules (or you need to go through function which was previously pure), where do you put the lift? If you put it outside the module, you break the modularity. If you put it inside, well then you might as well make the functions monadic in the first place. Basically if you have functions in module API (which may be in itself pure) that may eventually end up calling unpure functions, you have to provision for that somehow, either in the module by making them monadic, or in the caller via lifting. Either way, it's not as clean as it could be.

But I thought about it some more, and to me it seems that actually parametrizing the functions to outside world is not that bad; it's a kind of dependency injection, and seems fine. What is really problematic is returning all the IOs (or other monads) from them; especially since you cannot curry return parameters just like you can entry parameters. So even if that could be replaced by some other mechanism, it would be helpful.

But I didn't know unsafePerformIO, sounds like it can be helpful in some cases.

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

#145

Post by turingbook »

It seems that the author has deleted the original article and posted a reply to critical comments from Haskell school: https://yinwang0.wordpress.com/2013/11/09/oop-fp/

And some content of the original article was posted to: https://yinwang0.wordpress.com/2013/11/16/pure-fp-and-monads...

Post reply on HN