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

Programming without objects

falkoriemenschneider.de

Post reply on HN
Print view View original

11–20 of 133 posts

Re: Programming without objects

#11

Post by DanielBMarkham »

swift wrote: post #8
aftbit wrote: post #5

Earlier quoted context omitted.

The sole argument in this article seems to be that OO systems introduce more complexity than is justified which results in larger code bases than an FP-based system would, which increases maintenance costs. Then the article goes on to show some toy example solutions in FP style, without really touching on the challenges that don't show up until larger problems. I can write a great Account balance summer program in Py…

I'd really like someone on any side of this debate (and there are certainly more than two; for example, some people are advocates of "FP in the small, OO in the large") to write an article that does describe how their approach handles the challenges of designing and maintaining a large system. I think such articles are rare because they're much harder to write than something like this. In complex systems it becomes v…

So strong, pure FP coding will lead to a naturally decomposed system of small pieces -- once the re-factoring is done. There are no large pieces. That's the beauty of it. I believe that the premise of your question is in error.

The sucky part is that there is no guarantee that you will ever get there. A bad programmer or two and you've got a mess. Large FP systems crucially depend on high-quality coding. There is no place for everything to go, that's what the coders figure out!

Contrast that to an OO system, where things go where they naturally belong, but you really don't know what the algorithm is. Hell, you can spend days just wiring stuff up and putting stuff in place before the actual "real" code finds a home. But you always have a plan for where things go.

I don't think you can find a large, complex FP project because I think all the good complex FP projects are clusters of small executables.

Re: Programming without objects

#12

Post by millstone »

This article, like many that cheer functional programming, falls into a certain cognitive bias, that prevents it from seeing what OO is good at.

Alan Kay wrote "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."

To start to see what this means, consider the annoying String / Data.Text split in Haskell. String is very much in the "leave data alone" mindset, baring its guts as a [Char]. Now you're stuck: you can't change its representation, you can't easily introduce Unicode, etc. This proved to be so rigid that an entirely new string type had to be introduced, and we're still dealing with the fallout.

Great and growable systems! The large scale structure of our software, decomposed into modules, not just at a moment frozen in time, but in the future as well. We are tasked with thinking about relationships and communication.

So here is how "the better way" is introduced:

> Data is immutable, and any complex data structure...

There's that insidious FP bias: to immediately dive into data structures, to view all programs as a self-contained data transformation. So reductionist! It's completely focused on those "internal properties and behaviors" that we were warned about above.

I would end here, but I just couldn't pass this up:

> To come up with a better solution [for dispatching], Haskell and Clojure take very different approaches, but both excel what any OO programmer is commonly used to.

"Any OO programmer?" No way! OO as realized in truly dynamic languages exposes not just a fixed dispatch mechanism, but the machinery of dispatch itself, i.e. a metaobject protocol:

"...there are not only classes for workaday tools, such as UI widgets, but there are also classes that represent the metastructure of the system itself. How are instances themselves made? What is a variable really? Can we easily install a very different notion of inheritance? Can we decide that prototypes are going to work better for us than classes, and move to a prototype-based design?"

This is far richer than the anemic switch-style dispatch that Haskell's guards and pattern matching provide. For example, try modifying a Haskell program to print a log every time a string is made. You can't!

I'm not familiar with Clojure but I'll bet its object model has its roots in CLOS. Whether or not you call it "object oriented," CLOS is solidly in the spirit of having a dynamic meta-structure.

Re: Programming without objects

#13

Post by dragonwriter »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think.

Honestly, while I think OO programming in the broadest sense does that, I think class-oriented OOP (what the article mostly focusses on) languages, particularly statically-typed class-oriented languages in the C++/Java lineage--don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs. They aren't useless in that respect--there is a reason why they flourished--but there's also a reason that after them an important programming paradigm for several decades, and a dominant one since at least the late 1980s, there's a whole lot of moves away from traditional class-oriented OOP in newer languages.

I think that we're seeing a model--which is mostly viewed as being within the FP tradition but which has learned a lot from OOP languages and supports a lot of OO thinking--emerge (and that this article points to a lot of its elements) that provides a framework that better matches the intuition than class-oriented OOP does, while also better supporting building correct, maintainable, easy-to-reason-about systems.

Re: Programming without objects

#14

Post by lifeisstillgood »

DanielBMarkham wrote: post #9
AnimalMuppet wrote: post #7

Earlier quoted context omitted.

Agreed. The problem is, what you're asking him to do is really hard. Why was OOP considered a good idea? Before OOP, programs were just structs and functions that operated on them. But as programs got larger, that approach broke down. Someone on a team of programmers would create an instance of a struct, but would initialize it in a way that some function (written by a different programmer) would regard the struct as…

This is the argument I would use against FP. It's an open question -- to some degree. Couple of notes. First, have you seen what real-world large-scale OO looks like? Dude, it ain't pretty. We're swimming in projects that are staffed at 10x or 20x the number of coders they probably really need, and a lot of time is spent in support activities. Second, maybe the real question here isn't one of scale, it's how the mode…

Programming is a commodity? In a generation I hope so - now?

And to be fair I think that OoP and FP are the wrong paradigms for handling bad management of a large project. Open source methodologies are eating into that (I have just started at a major Fortune 500 with effectively a huge open source project inside it's employees) and even without that a good focus on risk management will help

In short, talking about your problems and taking early steps to resolve them will do more to fix a project than moving from OoP to fp.

Re: Programming without objects

#15

Post by colanderman »

I think you've confused "intensional" and "extensional".

("Intensional" means "identity determined by structure"; "extensional" means "identity determined by behavior". You seem to use them in the exact opposite sense.)

Re: Programming without objects

#16

Post by Terr_ »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> skeuomorphic

No, skeuomorphism involves ornamental details, which are at best hints about how something is to be used.

How you break-down the responsibilities of your system and name them is much much more important than that.

Re: Programming without objects

#18

Post by colanderman »

millstone wrote: post #12

This article, like many that cheer functional programming, falls into a certain cognitive bias, that prevents it from seeing what OO is good at. Alan Kay wrote "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be." To start to see what this means, consider the annoying String / Data.Text split in Haskell. St…

I think you and the author have posed a false dichotomy.

I avoid "traditional" OO in my own work for the some of the same reasons the author points out; not least of which that traditional classes are a kitchen sink.

But many of the ideas of OO; notably extensionality (what the author incorrectly calls intensionality), I could never do without. I agree with you, that exposing the innards of my data structures is a crime: not only do I lose control over their construction and use (including defining equality), but I'm restricted from ever modifying the structure.

But nothing in FP prevents hiding structure. You can see it all the time in OCaml: a module signature will declare an opaque, possibly parametric, type, as well as a set of operators over that type. The internal structure of that type is never exposed. All creation and use, and ideally comparisons (though it is unfortunately not enforced in OCaml) must go through the module's API.

(Module signatures, it should be noted, may be shared by multiple implementations, permitting compile-time dispatch.)

Yet while maintaining opacity, I am free to dispense with the excess baggage an OO class entails: run-time dispatch; a single "self" (i.e. the "friend" problem); that abomination known as inheritance; all these things I need no longer worry about, and my code can be cleaner and more efficient.

Re: Programming without objects

#19

Post by AnimalMuppet »

DanielBMarkham wrote: post #11
swift wrote: post #8

Earlier quoted context omitted.

I'd really like someone on any side of this debate (and there are certainly more than two; for example, some people are advocates of "FP in the small, OO in the large") to write an article that does describe how their approach handles the challenges of designing and maintaining a large system. I think such articles are rare because they're much harder to write than something like this. In complex systems it becomes v…

So strong, pure FP coding will lead to a naturally decomposed system of small pieces -- once the re-factoring is done. There are no large pieces. That's the beauty of it. I believe that the premise of your question is in error. The sucky part is that there is no guarantee that you will ever get there. A bad programmer or two and you've got a mess. Large FP systems crucially depend on high-quality coding. There is no…

That's great - if you can do it. The Unix design philosophy has held up well over the years.

But what you're doing is building small pieces that communicate with each other (via pipes, files, databases, or something similar). That looks almost like an OO design (pieces that communicate with each other over defined interfaces, hiding their internals from each other), except that the inter-object communication channel is both more inefficient and more impoverished in what it can express.

Re: Programming without objects

#20

Post by Dewie »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think.

With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).

Post reply on HN