Hacker News Reader

Comment by extension | Hacker News Reader

Modularity is a fundamental design principle that pre-dates computer science: complex systems should be broken down into independent components that interact through formal abstractions. It's very simple and obvious. Everyone understands it on some level.

OOP is really just taking the principle of modularity and making it a first class language feature. There's no reason not to teach it to a beginner. They are going to be using the concepts right away anyway.

Also, OOP is ubiquitous in the real world and rookie coders need to get involved with the real world as early as possible.

View on HN

If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do.

The Objects loss this proberty because they have inheritance. The other problem is that every in OO the data is mixed with the functions.

Rich Hicky on how it can be done right: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do.

I see this exactly the other way around. Objects makes sure you don't have to worry about what's on the inside, but if you use pure functions you need to know how the function is implemented, how it processes data, how it expects input to be and how the output will be.

Using pure functions requires you to seek out lots of information and verify implementation. Not that you shouldn't investigate this when using OOP, but in OOP a lot more of this is formalized in class-definitions IMO making the interaction easier to understand.

The way I see your analogy, is that if you use pure functions, the electricity in your house needs to know what material the bricks are made of so that current doesn't accidentally leak and cause a fire. With OOP this is a detail you don't have to worry about as long as the pieces fit.

If that sounds somewhat flawed or too simplistic, I will take the liberty of blaming the poor metaphor. I'm just pointing out that I see the exact same metaphor in the exact polar opposite way ;)

Why would I need to know the implementation and how it processes data?

The entire point of pure functions is that you don't need to know. Referential transparency guarantees that a pure function given inputs X and Y always returns the same output Z. So if I just follow the interface specification about accepted inputs and accepted outputs I can switch in any arbitrary implementation of that function and have my code keep working.

So if I just follow the interface specification about accepted inputs and accepted outputs I can switch in any arbitrary implementation of that function and have my code keep working.

The funny thing is that this is what I would say about OOP, while for functional solutions I often find the specifications much looser, so that I cannot trust this to always be true.

I'm not saying you are right and I am wrong. But I am saying that the arguments about what holds true for what, and especially the arguments for "OOP is bad" or "FP is bad" etc, they just seem to be highly subjective.

And unless someone can come up with empirical evidence to show that one side is actually better/right, I find this debate both pointless and rather amusing. Pointless in that it doesn't give more insights. Amusing in the sense that it makes people reveal lots of the preconceptions and prejudice against things they seemingly don't fully grasp.

What how do you have to know about the implementation of the function? Think of something like quicksort or a partiton function (partition 2 [1 2 3 4]) => ([1 2][3 4]). How do you have to know anything about that functions implemantation. Sure if the function has a name like myfunction and no docs then you have to look at the code but thats the same with OO.

In clojure you can say (doc anyfunction) and you will get a description of what the function does and it does only that.

You describe the perfect case in OO where you have only objects that only have immutable members and pure methodes. :)

I n the realworld I you often see that something does not work anymore because im some other object some variable changed or that it worked first but after a variable somewhere changed it breaks. With inheritance adds to that a hole set of new problems.

I'm not saying you cant make a good design with object im saying with a FP stile its easy to do the right thing while with objects its harder to do the right thing.

Thats as good as I can argue in a comment.

Think of something like quicksort or a partiton function (partition 2 [1 2 3 4]) => ([1 2][3 4]). How do you have to know anything about that functions implemantation.

Well. I need to know that it accepts two parameters, first being an integer, the second being an array of integers.

In an OOP solution this would at least be exposed by type signatures, something you don't always see in FP solutions (often due to type-inference). Hence you need to check the implementation.

And this is for a simple example. What about more complex example? Where the input-data has a more complex nature? Take the following example:

    var data = [ { id: 1, value: 2 }, { id: 2, value: 3} ];
    var ordered = orderByValue(data);

Ignoring the "var data ="-line: Without checking the implementation, how would you know how the input-data should be formatted? What types and properties are needed, and in what format the function accepts the data? A seq? A list? An object with properties? You don't.

In C# the same function would probably be contained in a relevant class and have a signature akin to the following:

    IEnumerable<ValueHolder> OrderByValue(IEnumerable<ValueHolder> data)

Now I know what it returns, what it expects and don't have to worry about that. The type-signature tells me everything. The types it expects tells me everything. Moreover, this is probably already implemented on a specialized collection class, so all I need to do is:

    var data = new ValueHolderList();
    // populate
    var ordered = data.OrderByValue(); // notice -pure- implementation in OOP ;)

Again. The implementation tells me what I need to know. Details are blackboxed, abstracted and objects easy to work with. I don't have to worry about functions, context, what they expect and in which order the glue is expected. In FP you are more commonly exposed to the internals of things and need to figure these things out yourself.

I'm not saying I am 100% right and you are 100% wrong. I'm saying there is lots of grey here which this thread doesn't really seem to cover or acknowledge.

FP is not a silver-bullet and nor is OOP. FP has strengths. So does OOP. Lots of the "weaknesses" I see people complain about with regard to OOP here are what I consider weaknesses in FP and strengths of OOP.

I sometimes wonder if we are living on the same planet.

In both OOP and FP, to know what a function (or a method) does, you need (at a minimum) to check its type signature. There are _many_ OOP languages which do not use explicit type signatures, and many FP languages which do; it seems to me that you have confused the OOP vs. FP issue with the issue of explicit vs. implicit typing, or perhaps with static typing vs. dynamic typing. There are languages available to suit pretty much every combination of those properties, so you can easily avoid whatever you don't like.

Further, when you check a type signature, what you read is much more valuable in a pure FP context than in a typical OO context, because OO languages generally (1) allow and encourage the use of state, and (2) do not distinguish in the type system between functions/methods that use state and those that don't. The type signature of a pure function strongly constrains what that function can actually do - so much so that it's possible, and effective, to look up the function you need just by specifying the type that you expect it to have. In a typical OO language, the type signature indicates much less about a method's behavior, because its inputs include not only the parameters you provide, but also the entire "world" at the time it is invoked; similarly, its outputs include the entire "world" in addition to its return value. As an example, a pure function that takes no parameters can only be a constant, but an impure method that takes no parameters could play a song on the speakers, display a window on the screen, or launch a missile.

FP and OOP certainly have both strengths and weaknesses. I suspect one reason that OOP catches so much flak around here is that people are more familiar with it, and the flaws in tools you're familiar with are easier to see. Unfortunately, when you're not familiar with a tool, it can also be easy to see flaws - flaws that aren't really flaws at all, but simply aspects of the tool you don't yet understand. The result of this, I think, is that one should ignore criticisms of OOP from people who aren't deeply familiar with it, and similar for shallow criticisms of FP. Unfortunately, there are a lot of both on Hacker News.

> Without checking the implementation, how would you know how the input-data should be formatted?

How does OOP solve this problem? Either way, you need to check the type signature of the function. If your IDE does that for you, that's great, but it's not an inherent difference between OOP and FP.

    In an OOP solution this would at least 
    be exposed by type signatures

I think you're mixing OOP and FP with language implementations.

Look up blog posts by Mark Guzdial. He's a very thoughtful, reflective CS educator who has written quite a bit about students learning to program.

I can't remember where he wrote about it, but apparently, 1) students can use other people's objects just fine, if they are simple (and so from that perspective, OO is fulfilling its general promise), but 2) new students have a nightmarish time trying to both solve new problems AND decompose problems into objects at the same time.

Which is to say, there is absolutely a reason not to introduce this to beginners. It makes them fail and quit.

Incidentally, the same argument could be made for the concepts of abstraction involved with composing new functions - new students can call existing functions just fine, but the skills involved with abstracting a problem, and replacing a pile of copy/paste with a parameterized solution, is apparently a more taxing set of skills than you might think.

Everything in it's right place.

Reply on news.ycombinator.com