What's wrong with Object-Oriented Programming and Functional Programming • Hacker News Board

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

#101

Post by pron » Tue, Nov 12, 2013, 4:59 PM UTC

jberryman wrote: post #85

pron wrote: post #62

Earlier quoted context omitted.

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…

Laziness is an implementation detail that permits equational reasoning and a declarative programming model; the only reasons it's even useful to be aware of haskell's evaluation strategy are 1) to know that it isn't strict (if you're already a programmer), and 2) to solve and anticipate space leaks in production code (if you're using it for Real Work). Anyway, you seem pretty [sure]( http://www.idlewords.com/2005/04/…

I don't think I've expressed an opinion because I don't think I have one (I have strong opinions on Scala, but they don't apply to Haskell). I'm just pointing out what seem to be major obstacles to Haskell adoption in the industry. I'm not saying it's not worth the effort because I really don't know. I'm just saying it's not obviously worth the effort. Clearly, the data isn't there yet because there is very little use of Haskell in the industry. This may be unfortunate – or not – but we just don't have enough information to tell yet.

Haskell's roots in academia often steer the discussion towards theoretical PL, which seriously hurts Haskell adoption. I actually like tikhonj's comment because it focused on practicality rather than jargon, so in response I merely pointed out that Haskell is not 100% pure gain in practical terms. That does not mean we shouldn't all adopt it, it just means that the jury is still out.

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

#102

Post by aufreak3 » Tue, Nov 12, 2013, 5:03 PM UTC

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 saying something to the effect of "OOP is not about objects. It's all about messages." which nicely points to the dualism between the two points of view.

    > There exists things that are not objects. Functions are not objects.

Well, objects are any "thing" that you can talk about, toss about in your head. Functions are certainly such "things" and count as "objects" in that sense. If we accept that "monotonic" is an adjective, i.e. an attribute of a noun, then the function described as "monotonic function" is an "object".

    > There exists things that are not pure. Side-effects are very real.

Um, how so? One notion that characterizes side-effects is irreversibility. You cannot unlaunch a rocket, for instance and so it counts as a "side effect" of the code "launch rocket". Despite that, when we look at the basic equations of quantum mechanics, they are all pure unitary! I mean, not only are they perfectly reversible, quantum "information" cannot be destroyed or even copied. So with fundamental physics we have the opposite question - how the hell do we get "side effects" out of this much purity at the core?

    > Also purely functional languages cause a huge cognitive cost.

I call pure BS on this section. "Huge cognitive cost"? For whom? Wouldn't "structured programming" have placed huge cognitive costs to former "goto programmers"? It is more honest to just say "I don't understand monads, so I won't use them."

    > If you look deep into them, monads make programs complicated and hard to write

Again, "complicated" for whom and "hard" for whom? Is there some objective sense in which such declarations can be made? I, for one, have benefited greatly from learning about monads, reading monadic code and recognizing the pattern in existing code.

    > You can write pure functions in any language, but the important thing is, you should be allowed to use side-effects too.

Why? Who's to say you "should" this or "should not" that?

   > Everything starts to do harm when they are pursued to the extreme.

I'd say the exact opposite actually. Both OOP as well as the functional perspective here illuminate the programming world only when taken to the extreme. Until then, folks just keep arguing about what is functional and what is oop and what isn't. Haskell and Smalltalk/Self have done this favour for us by adopting these extreme dual perspectives.

[1] http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

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

#103

Post by dragonwriter » Tue, Nov 12, 2013, 5:15 PM UTC

tree_of_item wrote: post #96

dragonwriter wrote: post #84

Earlier quoted context omitted.

> You can't have monads in Scheme due to the lack of a type system. You can have monads in almost any language. The lack of static typing means you don't have static type safety with them, but monads aren't any different than anything else in that regard. > What you can have are instances of monads, but the point of using the concept of a monad is to abstract over it, and to have functions that work with any possible…

> How does not having static typing prevent you from abstracting over monads? They were probably talking about the way Haskell can figure out which monad you're in through type inference. As an example, `return :: a -> m a` dispatches on the type of the function's return value, which doesn't map cleanly to a dynamically typed implementation. You need to be explicit about the monad you're in if you don't have the comp…

That's true (and, heck, its true even of many static languages that support monads; that feature of Haskell is due to its better-than-most type inference, not just having static typing), but I don't see how that limits the capacity for abstraction. Certainly, you may need an additional explicit parameter in some cases rather than effectively implicitly supplying information via type inference, but that doesn't change the level of abstraction.

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

#104

Post by voxfrege » Tue, Nov 12, 2013, 5:19 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…

> So what percentage of production code anywhere in the world is written in an eager (strict, whatever) language?

How is this relevant?

> If you tell me it's less than 99.999%, then you're being dishonest. 99.999% is a "feature of humanity".

Make all && and || strict in all C, C++, Java, C# code, and chaos will reign.

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

#105

Post by codygman » Tue, Nov 12, 2013, 5:27 PM UTC

lukaseder wrote: post #81

Sign. Yet another discussion full of trolling pros and cons of FP vs. OO Guys, listen to Simon Peyton Jones himself: "Haskell is useless". He's discussing stuff with Erik Meijer in this video: http://www.youtube.com/watch?v=iSmkqocn0oQ

You didn't actually watch this video did you?

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

#106

Post by codygman » Tue, Nov 12, 2013, 5:35 PM UTC

I think that OP mistranslates "extreme functional programming" as "we never have side effects and compose functions".

Also what exactly is "extreme functional programming"? Only using functional programming paradigms and abstract data types instead of OOP paradigms and objects? Is "extreme functional programming" not taking advantage of do notation, ST monad, etc and only programming in pure functions thereby accomplishing nothing?

I think the author should have defined what he believed to be extreme OOP and extreme FP before going on such a diatribe (on mostly FP and haskell in particular, since others don't separate side effects).

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

#107

Post by codygman » Tue, Nov 12, 2013, 5:38 PM UTC

olau wrote: post #18

weland wrote: post #5

This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…

Chill out people. The man is saying that the pure object-oriented model and the pure functional programming model have corners where they are lacking. He's not saying it's a bad idea to write object-oriented programs or pure functions. If you have ever needed a little helper function in Java and wondered why you had to stick it in a static method in a class, I think you'll understand his point. Similarly, many of the…

He's also making accusations and not providing proof for them. As well as casting each paradigm in a negative light (extreme friendliness, extreme helpfulness, extreme eating all sound negative) without even defining what exactly "extreme OOP" or "extreme FP" are.

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

#108

Post by rdsubhas » Tue, Nov 12, 2013, 5:44 PM UTC

weland wrote: post #5

This article is remarkably low on arguments , despite being so long. Just a few of its gems: > OOP is wrong because of its definition of an “object”, and its attempt of trying to fit everything into it. When that goes to the extreme, you arrive at the notion “everything is an object“. But this notion is wrong, because: > There exists things that are not objects. Functions are not objects. This has two problems: 1. It…

> Smalltalk functions are first-class objects

What about the functions inside those objects? And functions inside that function object. Like a chicken and egg problem. I neither agree nor disagree with him, what he's trying to say is that there is a difference between methods and functions. Methods (1) are functions (2) wrapped inside an object. (1) and (2) are different. He's just trying to say that "everything is an object" can't be rigid. At least that's what I understood.

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

#109

Post by wonderzombie » Tue, Nov 12, 2013, 6:11 PM UTC

gbog wrote: post #48

mercurial wrote: post #11

Earlier quoted context omitted.

> A typical CRUD application the web kids like to write can be written so that the only side effects involved are in fact modifications of the database, in which case the side effects are confined to SQL. Well, writing the response is a side effect as well, so no. But the business logic itself can (usually) be pure, even if it's sandwiched between effectful layers (web and SQL). And looking at how a well-crafted CRUD…

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.

As other commenters have said the point isn't the eliminate complexity. Some problems are actually inherently or irreducibly complex! The goal is to find ways to manage the complexity. Abstraction barriers are a trivial example[0]. Type systems are another approach, hopefully foisting the complex management of datatype correctness on the compiler rather than the programmer.

None of these approaches necessarily make the problem itself less complex. But as with a type system there are ways in which a language can help, or hinder. A language which adds too much complexity incidental to the problem you're trying to solve is an example. TFA is groping towards this point, but they did a poor job arguing it.

The proposition is that a functional language's abstractions, conventions, and patterns may make it easier to manage (not dissolve) complexity. It's hard to argue that (e.g.) functions which are referentially transparent are easier to reason about, for instance. Whether this is more difficult in the large, as a project scales, is unknown to me.

[0]: http://mitpress.mit.edu/sicp/full-text/sicp/book/node29.html

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

#110

Post by freyrs3 » Tue, Nov 12, 2013, 7:14 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…

> ... with the way it manages side effects is that it does so through lazy evaluation

Modern Haskell manages effects through it's type system, not through lazy evaluation.

> They require programmers to think and program solely within Haskell's lambda calculus and lazy evaluation framework, which is neither the way people think nor the way computers do

Haskell doesn't require you to think in the lambda calculus any more than C requires you to think in register allocations, it's a low level implementation detail that effectively gets abstracted away. Nor are you required to think solely in terms of pure code, Haskell 2010 has a whole variety of ST Monad solutions where you can effectively do whatever pointer manipulations you want and still remain pure with respect to the rest of your program. I take serious issue with the description of Haskell being "constrained", it has reached a compromise of safety and power that I have yet to see in any other language.