Terrible blog post: present a series of special cases where OOP is not the best fit => throw OOP away except for class libraries? Thanks to Paul Graham's language abuse, dead is becoming a meme: "X is dead" = "I don't use X".
Proper name
Are we still doing OOP?
21–30 of 37 posts
Re: Are we still doing OOP?
#22Earlier quoted context omitted.
And you are making an equally huge mistake: that thinking in terms of sets, mappings, graphs, combinators, etc doesn't help. It does. And if a programmer is incapable of understanding those concepts, he should learn them. The fact is, we shouldn't adapt computers to our thinking, nor our thinking to computers. We should adapt both to our problems.
Sure it helps, but that's not what derefr said. He said that any other type of thinking is a "crutch" and that the ideal of thinking is "thinking in terms of sets, mappings, graphs, combinators, etc". 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 do…
OK, I misread you.
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.
Re: Are we still doing OOP?
#23As with all programming methodologies; OOP is a useful tool for situations where it works. Outside of that other things become useful... this is how the world has always worked :)
Of course. The real question is, where does it work? (And why?)
Personally, I don't know.
Re: Are we still doing OOP?
#24Probably the most disturbing thing about the article is the original title: "Programming like it's 1995". I'd feel better if he had said "OOP is like so 1980's".
The problem is, OOP as Alan Kay envisioned it isn't widely refered to any more. Now, we all talk about OOP as if Java started it.
Re: Are we still doing OOP?
#25Ironically, I don't think OOP was really meant to be used for business objects. I think inheritance doesn't work very well with objects whose backing store needs to fit into a relational database someplace. OO really shines with UI programming, where incrementally building up behaviour through inheritance makes a lot of sense.
If the classes in your system vary a lot in behavior but not in their internal state then mapping to a database can be straightforward. With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows.
> 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. :)
Re: Are we still doing OOP?
#26Earlier quoted context omitted.
" But programming in objects -- true OOP - does not require a language that provides objects. " 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…
Plink I'm not really sure what you're going on about here. 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 sh…
Looking at this thread, it seems your main disagreement is about the definition of OOP. I won't provide one, mind you. But such disagreements are so widespread that we may want to stop using the term OOP altogether, and only use more narrowly defined terms.
Re: Are we still doing OOP?
#271. How bizarre to consider Javascript not object-oriented programming. The entire page is represented in objects.
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.
Re: Are we still doing OOP?
#28Earlier quoted context omitted.
If the classes in your system vary a lot in behavior but not in their internal state then mapping to a database can be straightforward. With lots of variations in object structure things can be horrible - witness designs that have more tables than most tables have rows.
> 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. :)
Maybe someone should create an ERP system based on one then!
Re: Are we still doing OOP?
#29With all respect to this author and this piece -- it was well done and he makes many salient points. There are some topics on HN that are just starting to bore the hell out of me. Apple fanboy-ism, or not. C++: it's complicated so it's bad. Famous person X says this about famous person/product Y. And bitching about OOP. Look. OOP is just the use of categorization and set theory to organize code and data. It doesn't h…
> It's just a tool.
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.
Re: Are we still doing OOP?
#30Earlier quoted context omitted.
Plink I'm not really sure what you're going on about here. 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 sh…
Looking at this thread, it seems your main disagreement is about the definition of OOP. I won't provide one, mind you. But such disagreements are so widespread that we may want to stop using the term OOP altogether, and only use more narrowly defined terms.
No rhetorical trick intended.
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.