Journal tomhudson's Journal: Bohemian programming 13
The interesting thing about living through a period of rapid change is that most people don't even realize what's really going on until it's already complete.
For example, most people are completely blind to the effects of "user-tailored search" in that as it evolves, they will see fewer and fewer opinions, theories, and even facts that disagree with their current world view. Rather, they see this as a good thing!
What does this have to do with programming? OOP is a dead end. It failed, it's a stinking rotting carcase, and yet we continue to use it because it caters to our prejudices - in particular, to the idea that we are SO clever because we an build ever more complex systems. And because OOP resembles empires in another way - they all get their biggest and bloatiest (is that even a word???) right before the fall.
The problem is, more complex OOP systems eventually become more complex than they would have been with a non-OOP solution. While initially OOP allows us to kick the complexity can down the road a ways, as systems evolve, the extra overhead (brain space, code, maintenance, debugging, etc) more than makes up for any "win" that OOP brings to the table.
After spending some time converting re-implementing some code as OOP, and looking at the bloated and much less flexible results that a "proper" encapsulation/inheritance/whatever-the-heck scheme once again produces, I took a break, and played around with an old friend I had been ignoring
Assembler
Haven't touched it in years, but it really is like riding a horse. Better than riding a bike, because you don't have to do as much work pedaling. I looked at it, and realized that compared to todays "modern" solutions, it would be much easier to teach someone assembler from scratch than, say, Java.
So why does assembler have a reputation for being "hard" when you don't have to have an IDE to code-complete for you because the required libraries in Java have proliferated like rabbits? Who knows - probably because people who teach it make it hard to learn. Or because they're afraid of the big bad macro.
this next section replaces a bunch of language-specific OOP fails
Why? Because you either already know what they are, or you're not yet at that place where it's become painful enough, so what's the point?
Instead, take a few minutes to zone out and read one example of how messy inheritance can get
The end result is that, after spending a week or so on re-impementing code as OOP, I now have to undo it, because OOP once again fails to deliver on the promise of better maintainability. And that is going to be the last time that happens. OOP is like the "Year of the linux desktop" - sounds good in theory, but the reality is that it's mostly more work than it's worth. Sure' it's attractive, in an intellectual sense. I think that's part of why it's so popular. But it doesn't deliver.
That's too bad, because I can still remember how exciting it was using BC++ 3.1, back in the days when Borland was the only vendor that produced a decent c++.
Moral of the story
The only way to manage complexity is to *ahem* actually manage complexity. OOP is just another fake silver bullet along the way. But like any empire, it's going to take a LONG time to die, because there's just too many people who have invested too much psychologically and economically to even consider that OOP may be the disease, not the cure.
and vegetables taste bad (Score:2)
I think that's (necessarily) true, it's just that the trouble in this is outweighed by the gains by it. I started my career in C programming, and large programs in the much simpler fashion of global functions operating on global data much more easily can get away from us. I've seen it, and just didn't know there was a better way until I started learning C++ and how to think in OO-ness. T
Re: (Score:2)
"Object-oriented programming is an exceptionally bad idea which could only have originated in California." -- Edsger Dijkstra
"object-oriented design is the roman numerals of computing." -- Rob Pike
"The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes." -- Paul Graham
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are
Re: (Score:2)
Excellent troll - "... just like 99% of programmers don't understand Hungarian Notation ..." Hahahaha!
Well played :-)
Here's one for you - "Design patterns are an anti-pattern".
BTW - for future reference, you can do OOP in c, and even assembler. It has nothing to do with the language itself. And it appears that I'm i half-decent company, if you look at some of the other people who say the same thing - Edsger Dijkstra, Rob Pike, John Ousterhout, etc.
One word (Score:2)
And an inferrential pun: "ObjectiveC"
Re: (Score:2)
As the sole author of a massive product... (Score:1)
OOP is like sex - if you don't like it, you're doing it wrong.
Re: (Score:2)
I never said I didn't like using OOP ... it's just that, like many others, I've found that there's always some edge case that makes it more complicated than it has to be, and then it's like "why don't I just use a bunch of structs and functions and the heck with all the syntactic sugar and the need to crawl up and down object hierarchies just to get a peek at one piece of data the 'proper' way".
After all, everything that you do with OOP can be done with structs and functions, including inheritance, polym
Re: (Score:2)
You don't have to avoid OOP to get this -- for example algorithms can operate on containers thru formal (or informal, a la the former STL) OO interfaces. But what the information-hiding features of OOP-supporting languages give you is even better granularity of separation of data and functions. More expressive power != less good. Just more likely misused.
Re: (Score:2)
I never said I didn't like using OOP ... it's just that, like many others, I've found that there's always some edge case that makes it more complicated than it has to be, and then it's like "why don't I just use a bunch of structs and functions and the heck with all the syntactic sugar and the need to crawl up and down object hierarchies just to get a peek at one piece of data the 'proper' way".
Then you're doing it wrong. Crawling up and down hierarchies is a symptom of violating the Law of Demeter. (OK, the "suggestion of Demeter".)
See if this helps. Start thinking of design from a testability perspective. What's the most testable code? A stateless function. Values go in; values come out; assert that what came out is what you expected based on the inputs you gave it, done. What's harder to test? A function that changes some state. To test it, you have two strategies: do some refactoring
Re: (Score:2)
I used to believe all that. Then I found that it's frequently simpler to implement the "OOPness" in straight c - and finding that the same techniques also work just as well in other languages.
There is one thing I think c (and the c-like languages) could borrow from c++; operator overloading. (Yes, I know most people think it's Teh EBIL, but I like it :-)
I'll still use OOP - but, like salt, only as needed :-)
Coincidence? (Score:2)
I swear to {deity} that as I was reading this, Wordfeud gave me ASEMBLR.
Yes, in that order.