When I was a tutor (TA) at university (collage) here in aus, I marked assignments from my students. We used an automated test suite to check correctness. I went over each assignment to subjectively assess code style. I would open the first assignment which scored full marks with the test suite and find it was a clean 500 line long implementation. Full marks. The next submission also got full marks, but it did it by spending only 200 lines. How? Was it overly terse? No... it looked clean and decent too. I would go back and look at the first submission and wonder - if you asked “could you throw away 60% of this codebase without sacrificing readability?” I would have answered of course not. But I would have been wrong. Silently, uncorrectably wrong if not for my unique opportunity.
In the programming work you do regularly, do you think there is a way you could structure your code which would allow you to do 60% less work, without sacrificing readability? If there is, would you know? The answer was clearly yes in the web world when jquery was king. Or cgi-bin on Apache. Is it still true today? Can we do better still?
If there is, it would probably demand a critical look at the way we approach our problems, and how we structure logic and data. The value in articles like this is to point at that question. For what it’s worth, I agree with Joe Armstrong and others who have been heavily critical of OO. Software which goes all-in on OO’s ideas of inheritance and encapsulation seems to consistently spend 2-3x as many lines of code to get anything done, compared with other approaches. (Looking at you, enterprise java.)
You’re right - the problem should proceed the solution. But our tools are the medium through which we think of that solution. They matter deeply.
I think this is mostly a reflection of the thing Java/C#/C++ have popularized as “OOP”: if one uses Common Lisp’s CLOS, much of the boilerplate associated with “design patterns” and OO architecture evaporates.
Yes absolutely. The article was written around 2000 when Java was the new sexy thing. When Joe talks about OOP being overhyped, he wasn’t talking about Rust’s traits or Common Lisp. He’s speaking about the hype around Java and C++, and the then-lauded three pillars of OO: Encapsulation, Inheritance and Polymorphism.
Not all OO works that way. In retrospect, inheritance was probably a mistake. And as far as I can tell, modern “OO-lite” coding styles focussing on composition over inheritance work pretty well. Alan Kay: “When I invented object oriented programming, C++ was not what I had in mind.”
I learned OOP in 1992, using Turbo Pascal 5.5, and got hold of Turbo Pascal 6.0 with Turbo Vision, shortly thereafter.
My follow up OOP languages until 2000 were C++ alongside OWL, VCL, MFC. Clipper 5.x, Eiffel, Sather, Modula-3, Oberon variants, Smalltalk, CLOS, SWI Prolog, Delphi and naturally Java.
In 1999 I got a signed copy from the ECOOP 1999 proceedings, full of alternative OOP approaches.
We should strive to actually provide proper bases to CS students, instead of market fads.
My inclination is to say that inheritance isn't the mistake, the mistake is making methods part of a class: my experience with inheritance in CL is that having generic functions/methods as their own first-class construct makes inheritance less of a minefield.
In the programming work you do regularly, do you think there is a way you could structure your code which would allow you to do 60% less work, without sacrificing readability? If there is, would you know? The answer was clearly yes in the web world when jquery was king. Or cgi-bin on Apache. Is it still true today? Can we do better still?
If there is, it would probably demand a critical look at the way we approach our problems, and how we structure logic and data. The value in articles like this is to point at that question. For what it’s worth, I agree with Joe Armstrong and others who have been heavily critical of OO. Software which goes all-in on OO’s ideas of inheritance and encapsulation seems to consistently spend 2-3x as many lines of code to get anything done, compared with other approaches. (Looking at you, enterprise java.)
You’re right - the problem should proceed the solution. But our tools are the medium through which we think of that solution. They matter deeply.