Object Oriented Programming Oversold (2001)
web.archive.org
web.archive.org
An actual example of this I saw recently, was when I got into an argument with someone over the use of standalone functions in C++. Apparently, these are evil, and functions should always be part of a class.
Of course, a class with only static functions is basically a namespace. No problem, apparently statics are also evil. So let's not make these functions static, even though they're not accessing any member data.
But now, when we want to use these functions, we need to instantiate an object, which is a bit silly. No problem, we'll just make it a singleton.
I shit you not, this actually happened.
At some point, their lead developer tells me about some guy they had for a job interview a while back, and as the story goes they had him through a code review where he was berated for using a static helper class. Apparently his reply was something like "You're using static classes for view helpers? But that's insane!". The morale of the story as told, was that clearly he didn't know right from wrong and was passed over. I didn't know what to reply to that.
Crazy files of constants seemed to feature a lot as well:
public final static string HTTP = "HTTP";
public final static string COLON = ":";
public final static string SLASH = "/";
string url = HTTP + COLON + SLASH + SLASH....;
As programmers, we need to start demanding that logical explanations always accompany best practices or dismiss them as bullshit.
Anyway, beware challenging conventional wisdom, it evolved due to past pain and gets passed down generations to avoid that pain, even if the reason is not well understood anymore.
I think this is the problem with the received-but-not-understood wisdom -- the implementers don't actually use an interface but hard-code the class that has the method, so it's not any more over-rideable than a regular function call.
Also, singletons aren't portable.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n447...
> ...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm.
This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)."
Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.
Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling.
I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.
Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto".
Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.)
Dijkstra's remarks were contemporary of Fortran IV.
My first piece of advice was to ditch the current system and revert to the old. This had been purposefully sabotaged by the suppliers of the new system. The only way out was then to go forward and this nearly killed the company.
More "modern" flexible applications ended up having multi-month/multi-year "implementation" phases as teams tried to change their new application to their existing processes when it was actually easier to standardise the processes around a fixed application.
Getting an account balance for example was a "Question 8" if I remember right, that is, the PF8 key on the keyboard. Routine banking operations were maybe a couple dozen keystrokes and mostly all the same pattern but different function key with paper overlays taped to keyboards to "name" the PF keys.
It wasn't pretty and the learning slope was steep but the same people who wrote their emails in Lotus Notes in All Caps and scanned word doc printouts into new word docs had no problem memorizing all the obscure operations they had to do every day.
In this case they canceled the contracts on a bunch of facilities that were crucial to operating the old system and that would take a very long time to set up again.
But the whole idea of a non-revertible change-over without at least a period of having the old system on stand-by just in case all by itself is totally reprehensible, especially since their testing regime was comprised mostly of 'let's go live and see if it works'. Of course they didn't mention that little fact beforehand, only afterwards was it made clear that any attempt to move back to the old setup was going to be fruitless because they'd 'closed the door behind them'.
I suspect that they knew full well the new system wouldn't work properly and that if a revert would have been done this would likely trigger some serious backlash so by saddling the client up with the new system and making sure they could not go back they forced them to accept the new situation no matter what. Job security by any means.
Only that part ended up not working.
I've never seen a clusterfuck like this before and I really hope I won't ever see one again.
Just to provide another example, "write a stub prototype of the new system, discover $CRAPPY_ORM in my new hotness language doesn't like a couple of the database constructs, migrate production database to work better with the prototype, new system fails to generate some data the old system needed (history, audit logs, tons of options here)". Back migration now effectively impossible.
Especially not if there is financial information involved.
So you won't have to 'write your code to continue saving some bizarre unnecessary data in the database' and you can have your 'sensible scheme'. It just takes a little bit more care and planning.
> As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better?
They ended up renting a good part of those facilities anyway, the problem was not the money but the fact that certain comms lines had been torn up.
Playing cowboy with critical company data is not a winning strategy.
Personally, I really, really don't like Visual Basic. I don't even claim to have anything resembling a rational reason for this attitude. It's deeply ingrained prejudice. And if I have a reasonable alternative to touching VB code, I'll take it gladly.
But I've had to touch a few VBA/Excel based "applications" over the last year or two, and I did it. It was no fun at all, but it was still better than rebuilding those things from scratch. In one case, we replaced an Excel sheet crawling with VBA by a PivotTable which does the same job, is more maintainable, the file is a lot smaller and it appears to run slightly faster.
There is also a part of me that loves picking up some old code written by somebody who has long since left the company, possibly to solve a problem I do not fully comprehend, and fix some obscure bug or add some minor feature. So far, I'll admit I was quite lucky in that those programs I had to touch were reasonably well written, or at least readable and structured in a sanity-preserving way. But still, it's fun, in a way, and the "dirtier", the funnier; at least as long I have a clearly defined task and get to walk away from it when I'm done.
Using the hot new toy that all the cool kinds are using is probably fun, too. But working on a 10-20 year old application that only a handful of people have ever touched, has an appeal that outweighs the distinct lack of sex appeal. Plus, you get to tell some interesting stories about the things you've seen. =)
> I will eat a week's pay if OOP is still in vogue in 2015.
So, is it time to make the OP eat a week's pay or not? I'd say no.
Anyway, he makes many valid points, like other articles about the disadvantages of OOP, but none of these every draws any convincing conclusions why OOP is 'bad' and why something else would be 'better'. In programming there is no paradigm that fits every application, OOP is just one of many ways to solve problems, and one that has proven that (if used pragmatically) works very well for a very broad range of problems.
But what has changed from the years this article was written is that OOP is not touted a panacea. Back when I learned to code, OOP was a synonym for "good".
That's why I'm saying no. OOP is no longer the hyped as it once was.
Stepanov, the inventor of STL (The C++ Standard Template Library) was the pioneer in avoidance of OO. It was truly revolutionary, and had such a huge influence on library design that today most modern C++ libraries are designed the same way.
"STL is not object oriented. I think that object orientedness is [...] a hoax. I have yet to see an interesting piece of code that comes from these OO people. [...] I find OOP technically unsound. [...] I find OOP philosophically unsound. "
Well said. And that is what is happening today in many forms. I'm under the impression that hiring managers (kids in their 30's) are totally irrational about skillsets because others don't know exactly what they think they should. There is paranoia about making a wrong hire to such a degree that they will most likely make the wrong hire!
What you stare at, you steer for - Bob Goodnough
Say you have two classes, A and B. You have an operation that uses both of them. You can declare A::func(B) or B::func(A) but this couples the classes together. Yuckko.
So you just make a global function, func(A, B). The function gets its job done using public methods, and the classes remain unaware of each other.
That's the foot in the door. Then you whip multidispatch and CLOS on 'em and watch their eyes get real wide :-)
Leave a copy of AMOP as a going away present.
The thing you're trying to avoid with coupling is that when the dependency changes you might have to change the thing that depends on it, right? Isn't global func going to change with the same likelihood as A::func or B::func?
I'm not sure if this is a relevant or not, (but since it relates to your post,) I do often find myself wishing I had multiple dispatch and/or some way to extend interfaces to existing types when programming in a language without those features.
To think that a) all problems can and should be solved via OOP and that b) it is superior to other techniques (as if it was a competition or a fight) is foolish. To think that some program, that is designed in an object-oriented way, is inherently better than some other program that isn't, is - to a degree - like saying some athlete is better than another one because one wears yellow shoes and the other wears green shoes.
The GUI Link
People think of gui elements as seperate objects (scrollbar, list, tree, textbox etc), so why is it a bad thing that the software also reasons about them as objects? Author just seems to want to hate OOP but offers no alternative: "There is more proof to the existence of UFO's than to OOP being the best way to do GUI's or any other programming topic." ???
Bait-and-Switch
Author says here that training examples lure people into this idea of a perfect world that can be modeled easily with separate objects, but in real life projects this is not the case. But how is this any different from any language / paradigm we have today? Angular is often berated for example for being easy to get going with, but a PITA once the project becomes too big. It's a good thing examples introduce you to the strengths of the language, and then later you try to to fit the problem to those strengths.
Land of Confusion
"It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice." This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier!
Not Table-Friendly
"OOP often does not map well to relational databases"
Entity Framework for C# is used by businesses all over and shows this is possible, and easy to do. There are many other solutions to this as well.
Melding Can Be Hazardous
"How many times do different programming languages and systems have to share data? Very often in the real world. Thus, it is usually safer to keep large data pools separate from methods"
What?? This makes no sense. If you need to share your data structures, then serialize your data to a text format and document it, for the next program to read. You could even provide an API.
IDE support
Well I've stopped reading by this point, but the author doesn't mention any advantages gained in the IDE. Specifically by using objects, the computer has more understanding of what I am doing, and can provide me: contextual autocomplete of members, and contextual documentation. Both invaluable for quickly getting up to speed with a new API, and making programming fun.
Maybe it's just me but this is my main gripe with OO. I sometimes need to write involved data processing tasks and it's much simpler if I first think in graphs or through a relational model. The objects are light and either a way to encapsulate state (as in parser), a simple structure (as in a vector xyz) or a container.
Complex data lives in relationships between the data - as opposed to 'encapsulating into an object' - this keeps the system small, easy to understand and modify.
Sure, objects are a nice way to offer an interface to something but I've found the statement 'objects all the way down' usually means poor design.
This gripe is of course mainly pedagogical - students (like I was, once) are exposed to a subotimal abstraction of software composition when objects are introduced as the way to design and implement software.
Sure, they are nice in some places, I don't deny that.