Are we still doing OOP?
hackinghat.com
hackinghat.com
Thanks to Paul Graham's language abuse, dead is becoming a meme: "X is dead" = "I don't use X".
OO really shines with UI programming, where incrementally building up behaviour through inheritance makes a lot of sense.
With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows.
This is the problem document databases are designed to solve. :)
2. I think the worst thing that happened in OOP was the development of ER-like methods (Rumbaugh, Booch) to "model" the system before it got built. It doesn't clarify anything and it doesn't fit with the original idea from Smalltalk, where software is developed in a gradual and exploratory style. When he states you don't need to develop a "complex object class hierarchy" for a small task, I think he is falling into this trap.
3. Obviously, other approaches are good for a number of problems, and OOP is not the be-all and end-all. I would never avoid using it, though, because it is good for many problems, especially UI. OOP is worst in static languages (EC++), and best in dynamic languages (Smalltalk, Ruby, JS), in my opinion.
4. Spreadsheets. I wish the VBA interface to Excel were more OO, because I think the methods are on the wrong interfaces. There is definitely room for improvement. OTOH, the user interface is a facade around something that may or may not be implemented in OO. I also wish that I could refer to things in the user interface using OO methods, kind of like using Prototype in JS.
5. In financial applications, I wonder what technique allows him to "innovate" without his model "breaking down". He doesn't say, but it sure seems like he doesn't like objects! (for whatever reason, he also doesn't really say.)
6. Finally, I get the feeling that he's really saying he no longer writes a real object model for his applications. This is, apparently, because the object libraries he is working with have gotten so good at modeling everything he needs that he is mostly writing glue, and it is all fitting into a few modules of mostly procedural code. So, in other words, OO is a huge success.
Outside of that other things become useful... this is how the world has always worked :)
Personally, I don't know.
As to OO, Bertrand Meyer gives the best rationale: it is about organising software around data instead of procedure, because data is more stable. That yields a rather abstract definition, but in that sense OO is perhaps more alive now than ever.
What has happened is that the developer's canvas has expanded enormously. We think and write for the WWW first now. The data types are the various sub-parts and relations of web standards. Our software is very much organised around these, they just don't map to small language features.
"The money class is the root of all evil"
They're a crutch for people who can't (or don't have the training to) think in terms of sets, mappings, graphs, combinators, etc.
The fact is, we shouldn't adapt computers to our thinking, nor our thinking to computers. We should adapt both to our problems.
By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.
That said, I tested both OO an FP, and my current opinion is that thinking more mathematically (in terms of sets, mappings…), almost always yields smaller designs, which are almost always more flexible and more efficient.
> By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.
I don't understand you here. Derefr didn't make any mathematical statement. He didn't described the concepts, he named them. The four items he mentioned are related. And why should they, anyway? The way I see it, Derefr just made a statement, not an argument.
To put it another way:
> Before I understood the Art, a punch was just a punch, a kick was just a kick. Then, while learning the Art, a punch became more than a punch, a kick more than a kick. Now that I understand the Art, a punch is a punch, and a kick is a kick.
Notice the removal of the "just"—now the underlying knowledge (the "more") is attached to the concept (it is not a pure concept, existing "just" for itself), but it is also understood that that the "more", learned while studying the Art, is perfectly described by the words "punch" and "kick"—that those high-level concepts are just abstractions for the low-level concepts learned while studying the Art.
It's a crutch to rely on concepts without understanding their foundations. (This is what I meant with my original conclusion, vague as it might have been.) However, having learned those foundations, you can decide for yourself, on a case-by-case basis, whether to think in terms of the high- or low-level concept, and indeed the high-level is sometimes the perfect tool for the job. But it's not the perfect tool for everything—and only studying the Art of Computer Science will show you why.
Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.
Look. OOP is just the use of categorization and set theory to organize code and data. It doesn't have to involve a lot wiring things together, it doesn't have to mean tremendously huge class diagrams before coding, and it is absolutely not related to one particular language. I can use OOP techniques in any language, and to the degree they're necessary, I should. It's just a tool.
I understand that the OOP movement got way overblown and annoying, but we as technologist are always making overly-broad generalizations of anything we do. There's a tremendous amount of selection bias that goes on in technology, most of it hidden. I remember in one of my early contracting jobs we had a PM who was a FoxPro programmer. No matter what the problem we were talking about, somehow he would feel that FoxPro was the best answer for that problem.
At the time I thought he was unique -- sort of a joke. Looking back over many years of observing technologists, however? He was the rule, not the exception. At the risk of stating the obvious we only understand those things we have familiarity with. This means if you haven't programmed in OOP, or if you've had extensive experience with OOP and you know somebody at the same experience level with different opinions, you should try very hard to have an open mind and learn something from somebody else. It's very easy to make broad claims that are unsupported by anything but a small set of observations.
Saying "Are we still doing OOP?" is like saying "Are we still using categorization and set theory" which sounds to me a LOT like "Are we still using arithmetic?"
The question is nonsensical.
OO is hardly equivalent, and not as fundamental (or anywhere near fundamental) as Set Theory, leave alone Arithmetic. The implied equivalence is misleading.
You can use "categorization" and Set theory to design programs with never an Object in sight.
Types and (mathematical) functions are both defined using Set Theory as are Relations (as in relational databases). You could program in Haskell with only types and functions and monads and such with no "object oriented design". The primary difficulty for people who've only done (what some call) "OOP" is forgetting all the OO technique they learned.
At best you could say that objects (for various definitions of "OO") could also be expressed with Sets and (mathematical) functions and such. ALmost every programming language feature could be so expressed, that isn't saying much.
There is no specifically "Object Oriented" super technique that transcends all languages (both OO and non OO) and is applicable in all of them. You'd be cutting against the grain of many languages if you tried to think in OO while using them. LIke Fortan, you can write "OO" in any language and it isn't always a good thing to do.
Not defending the author of TFA ( I don't read these "Ohh technique X or language Y is so outdated" type of articles any more) but the sentence quoted (' "Are we using OO" is lik e "Are we using Set Theory" ') is as generic and misleading as anything the author claimed. Balance in all things.
Here's a wonderful example. Let's say you're in C. You start writing code and continuously refactor as you go along. What most people find is, after a good bit of coding and refactoring, you end up with code grouped in modules with public and private functions, public and private data, etc. You can have data abstraction, encapsulation, modularity, polymorphism, and inheritance -- all to varying degrees, depending on the problem and solution.
OOP takes that categorization and set work and makes it part of the language. But programming in objects -- true OOP - does not require a language that provides objects. In fact, it's the other way around: because people programmed in objects, languages started providing that capability. Where folks get lost in the woods is where they think the language features are OOP instead of the conceptual work. Languages are just varying levels of syntactic sugar on top of the core tools.
Hope that clears it up for you
Without getting into some mystical definition of "True OOP" You don't need any OOP to program or design.
"data abstraction, encapsulation, modularity, polymorphism, and inheritance"
None of these things (except inheritance maybe) is specific to OOP. All of them occur in all kinds of languages and paradigms with no objects or "OOP".
As to
" (with C programs) after a good bit of coding and refactoring, you end up with code grouped in modules with public and private functions, public and private data, etc. you end up with code grouped in modules with public and private functions, public and private data"
Sure if you refactor that way.
You could also end up with a collection of rules (as in Prolog) , polymorphic types and functions (as in Haskell), communicating processes (Occam/Erlang) etc with no "OOP" anywhere. (unless you want to claim any and all use of polymorphism or abstraction of any kind is indicative of some kind of all pervading mystical "True OOP" technique. There is no "True OOP" underlying all use of (say) abstraction or polymorphism).
I think people who've done only OO or primarily OO are as bad as people who've never done any OO or rarely do any OO in making outrageous claims.
Grandiose claims opposing or favoring specific subsets of programming technique [ example 1 --> "Are we still using OO?WTF" example 2 --> "Saying are we using OO is like saying are we using Arithmetic" don't stand up to scrutiny.
Objects are a useful abstraction. So are functions, logic staements, relations, processes, polymorphic types .. . Each in its place. (and balance in claims ;-) )
Yes, you can refactor in lots of ways. Some rely more on OOP, some on FP, some on rules-based or constraint-based programming, etc. This is my point -- the tools are there regardless of the language features. Some languages just make this easier or more difficult. No mysticism required :)
Objects are a useful abstraction at times, but "object" does not and should not map directly to some language feature. If you think that then perhaps you've done a great job of learning a language and not-so-good-a-job learning OOP.
As fas the "people who've done only OOP" part? I take it you mean me? Dude I've only been doing functional programming in F# for the last couple of years or so. Found that my OOP chops came in very handy with data structures and functional composition. But perhaps you didn't mean me. I'm not sure.
I'm done here. The only reason I took this thread deeper is that there is a useful thing for HN'ers to learn. The tool is bigger (and more useful) than the language. Don't confuse the concept with the application.
It's a definition thing, sure. But it's important to realize that there's no trickery going on here. There's a very important point.
I get this all the time, and from all aspects of software engineering. As an example, it's become quite fashionable to say something along the lines of "use-cases suck!"
However use-case analysis is just a way of thinking about system functionality. Most people, when pressed, actually mean "we hate these monstrous word templates and rigorous bullshit that people make us do and call them use cases"
To which I do not disagree. But that's confusing the application with the tool again. To insist that they are the same is to throw out huge hunks of software engineering simply because a few people got into them and made them overly-complicated and onerous to use.
Or put another way: I'm sure some folks would like to describe OOP in terms of overly-complex class diagrams, lots of wiring, un-manageable systems, yadda yadda. Some other folks would like to describe OOP in terms of small systems pragmatically created bottom-up. It can be any or all of that. OOP is actually constructing solution code in a pattern that supports encapsulation, polymorphism, information hiding, etc. The idea is a conceptual tool, a code construction pattern of thinking. The implementation can be all sorts of things. Various implementations suck to more or less degree. But that's really not important. What's important is whether this tool is useful right now, do I know how to use it, and which parts work and which parts get in the way of where I'm going.
I understand that this can sound like sophistry, but it's not.
Yeah except Alan Kay, you know that guy who invented OOP, says everything you mention there is the overly complex BS unOOP. OOP is late binding and message passing. It isn't the hair splitting you seem to think it is, it truly different philosophies about programming. What you are calling OOP is more like Structured Programming Redux, strong on the structure and light on the dynamic message passing and late binding.
Either you understand how silly you sound or you do not. I suspect the latter. Perhaps you and Alan could continue the discussion.
The way I read this, he should have called his paradigm "Message Oriented Programming", and Erlang is actually closer to his views than Java.
(I suppose you refer to the "just a tool" sentence.) I'm sure of that. It's just that its an easy sentence to throw up while not really thinking about it. I see it often, and it rarely actually says something. And its effect, whether intended or not, is often the rhetorical trick I spoke of.
About the rest, I agree: when (if) disagreeing parties manage to set definitions straight, they often find that they actually agree.
Please don't use that rhetoric trick. That sentence is both very close to a tautology, and bears a strong connotation of pragmatism. It says nothing, yet it proves anything.
Also, I don't like this sentence especially in the context of programming languages. Programming languages and context are ways of thinking. As such, they have far more influence over us than the proverbial hammer. Saying they are just tools tend to deny that influence.