Comment by ncmncm | Hacker News Reader

Comment by ncmncm | Hacker News Reader

The great mistake is to believe there is something useful called "Object-oriented", or "Data-oriented", or "Functional", or what-have-you-oriented programming.

Carpenters don't learn "hammer-oriented" building; or "saw-oriented", "screwdriver-oriented", "chisel-oriented", or "glue-oriented". They learn to use hammers, saws, screwdrivers, chisels, and glue, and use them all at different times, sometimes one more than others. Machinists don't learn "lathe-oriented", "drill-oriented", "mold-oriented", or "welding-oriented" fabrication. They do all or any of them strictly according to what they are making, and what they are making it out of.

It is as utterly stupid to design a whole language around one of them as it would be for a carpenter to try to run a screwdrivering business. A language is useful exactly to the degree that it enables building whatever you might be called upon to build.

That is not to say any generally useful language is equally good for any purpose. Wood is better for some products, metal for others. A metal violin would be weird, a wooden gun action would be stupid. But violins often have metal bits and guns often have wood stocks.

This is just a rephrasing of a boilerplate response to any criticism at all: "there is a time/place for OOP!" followed by precisely zero articulation about when one should use OOP over a rival paradigm. It is one of the weakest arguments I can conceive of (perhaps following "but that's not true OOP" with no assertion about what characterizes OOP, or a definition of OOP that is only esoteric).

Why do you feel the need to talk to programmers using a construction metaphor rather than talking about programming paradigms directly? If OOP has merit, shouldn't it be relatively easy to articulate as to programmers? What is OOP good at? When should I use it rather than a data-oriented approach? Why talk in tenuous metaphor?

You just read that the whole notion of object-oriented (or anything-oriented) programming has no merit, and are now asking me for examples where it has merit.

You are usually constrained to a particular language or, sometimes, mix of languages. You have access to a set of language features. Use them in any mix that solves the problem. If runtime polymorphism would be useful, use it. If arrays would be useful, use them. If recursion would be useful, use it. If compile-time type matching would be useful, use it.

Thank you, I always appreciate a thoughtful critique.

I have to disagree with the sentiment you express here.

Your metaphor is bit confused. You are comparing individuals tools to methodologies. For example, object oriented programming is a methodology which involves the use of a variety of the tools like inheritance, composition, interfaces, dependency injection, etc. So, object-oriented programming does not correspond to always using a hammer in every situation. It rather corresponds to particular theory about which tools to use in which situations.

There have been a variety of methodologies of framing buildings. There was traditional framing, then balloon framing, and now platform framing. These different approach to framing are what would actually corresponding to things like procedural programming, objected programming, and functional programming, not the individual tools.

It seems to me that it is pretty clear that there is something usefully termed data-oriented programming or functional programming. Neither is appropriate to all scenarios, but that doesn't prevent them from being useful concepts.

Crucially, though, your thrust seems to be that we should use the right approach for the task at hand. That's true to a degree. But what remains is that some paradigms are either bad ideas or frequently get applied in domains they aren't suited to (I'm looking at you OO!).

The consequence is that I don't see it as particular helpful to say "use the right tool for the job." Yes, it is true, you should use the right tool for the job. But I think its also true that some paradigms are better then others, just as some framing techniques are improvements on anothers.

If you start building a skyscraper by nailing up 2x4s, you won't get very far. But that says nothing about the merits of nailing up 2x4s.

If you start a project thinking, "I'm going to make an object-oriented program", or "I'm going to make a data-oriented program", you are just working with one hand tied behind your back. A mature programmer mixes elements freely with no thought to "orientation".

If you demand simple advice: Don't Be Stupid. It's not helpful, but neither is TFA. At least mine is correct.

> A mature programmer mixes elements freely with no thought to "orientation".

Seriously, you advocate freely mixing radically different architectural approaches? Well... I don't want to share a codebase with you.

I advocate freely using language features anywhere they are useful.

Architecture has nothing to do with seminar-peddlers' "paradigms". Architecture is about organization. For each problem, some architecture is uniquely suited to addressing it. If you constrain yourself to this or that paradigm, you commit at the outset to failing to arrive at the optimal organization for the actual problem.

> Architecture has nothing to do with seminar-peddlers' "paradigms".

No, these paradigms all have ideas about how software should be organized. OO thinks you should organize everything into interacting objects. Functional thinks you should organize everything into pure functions.

OO doesn't think. Functional doesn't think. Paradigms don't have ideas about anything.

Advocates for those, and others, characteristically think badly. People who build things that work do not limit themselves with pat labels. Nature has no respect for pat labels.

Obviously, when I say OO thinks X, I mean that people working within the paradigm think that.

Given that you've decided to pretend that I meant something stupid instead, you aren't a person worth talking to.

You have presented your credentials.

There are different methods of framing a house and roof and builders do tend to specialize in just one. Balloon framing is different than platform framing which is different than mortise and tenon framing. To learn a new system, a carpenter would have to learn a whole new system of rules, measurements, suppliers, attachment methods, and seasonal tolerances. Here's an overview of some of these techniques: https://www.hometips.com/diy-how-to/house-framing.html

It's actually pretty analogous to programming methods.

Different methods of framing correspond to different materials available. Long 2x4s are too expensive now for balloon framing to be cost-effective, just as posts and beams, and lath and plaster, became too expensive (for different reasons), earlier. None is abstractly better than the other, even for identical end products.

In some places bricks are, or once were, cheaper than lumber. A carpenter who can't build a house with brick walls, or can't add a platform-framed room to one, is no carpenter at all.

The weird thing about this article's category of OOP criticism is that it makes all sorts of assumptions about class design and memory allocation which are absolutely not intrinsic to OOP.

Like, there are plenty of good points to be made here without discarding the entire idea of object-oriented design. It really just needs a little tweak.

I don't have a substantive response except to thank you for giving me a helpful analogy in future discussions on the topic.

> The great mistake is to believe there is something useful called … "Functional", or what-have-you-oriented programming.

It’s a remarkably substantial mistake — “the great mistake”, even — to blithely discard a concept so fundamental to computer science and programming language theory that we literally could not progress in the field without it.

You may as well be an earth-bound carpenter denying the existence of “gravity-oriented design”.

Yet, we did progress without it.

Learning a program organization style is helpful for beginners, if the toy problems they get are more easily solved using the style. But you progress, ultimately, by transcending it. A mature programmer mixes elements freely without labels.

Crawling-oriented locomotion is fine for babies. Adults walk, run, swim, drive, pilot, ride, sometimes even crawl. Learning to run does not make you worse at crawling, or make you run when you should crawl.

> Yet, we did progress without it.

No, we didn't, and claiming so merely demonstrates your profound ignorance regarding the most basic fundamentals of our field.

We must be working in wholly different fields. I make software that, you know, works.

Says the carpenter to the architect.

Peddle your snake oil where it sells.

Reply on news.ycombinator.com