|
I agree.
And have done since the The Beginning (Turbo Pascal 5.5 and Turbo C++ 1.0).
No language should be purely OO, multi-paradigm (ptui) is the only true path.
Use OO when it makes sense, but not wen it doesn't.
You're not alone out here.
Requisite link:
Stevey's Blog Rants: Execution in the Kingdom of Nouns[^]
|
|
|
|
|
I find it interesting that you now use objects less than when you first started to code. I would've thought that it would work the other way around. But maybe that's for us dinosaurs who first learned structured programming and later had to think in terms of objects. If you learn objects first, I can see it progressing in the opposite direction.
I'm curious as to what you meant by C++ changing your attitude towards objects. Maybe you started to use them less because C++ has too much boilerplate!
Sure, a standalone piece of code will be smaller, faster, and easier to understand if it isn't broken up into many little objects. But you called it a "little HTTP server". What if it had to be big? Or support other protocols? Or be integrated with a large system?
The larger the system, the more important it is to achieve reuse and abstraction, which means separating concerns and using polymorphism, inheritance, and encapsulation. Without this, developers clone and tweak code that can't be reused because it's admixed with other concerns. It also becomes harder and harder to add new capabilities, because they have to interwork with components that exhibit superfluous diversity. A maze of twisty little passages, all different.
That said, OO can get overused and won't solve everything. It would be great if it could be coupled with aspect-oriented programming, but I haven't seen a good way to do that, and aspects may simply be intractable when it comes to cleanly separating concerns.
|
|
|
|
|
I can't really find much to argue with here, as I do believe OO has its place, even if i wonder if it hasn't made a mess of things too.
I moved away from objects with C++ once I learned STL which led me to generic programming which deals in aspects moreso than objects.
Real programmers use butterflies
|
|
|
|
|
The STL is definitely generic programming, but I don't see what it has to do with aspects.
By aspects, I mean things that are orthogonal to a class's purpose but that are impossible to decouple from its implementation. Here are some examples[^]. If you use the code described in that article, without modification, you'll also drag in a pile of other things, whether you want them or not. Even if you do want them, it becomes a question of whether their implementations are what you want.
|
|
|
|
|
I know what aspects are.
To be clear:
Where they tie in here, is you create "services" for your classes - implemented as templates that take your own class as a template argument.
Those allow you to encapsulate orthogonal class services to a degree. It doesn't always allow for complex cross-cutting scenarios, and arbitrarily wrapping methods with pre and post code takes some vtbl foolery (microsoft takes this approach with certain ATL internals) but you get your aspects this way.
It's kind of primitive and just as "kludgy but powerful" as templates are. Between the above and using type traits and such you can get it to do a lot of what you would do with aspect oriented builtins in a higher level language
Real programmers use butterflies
|
|
|
|
|
I think I see what you're getting at. Is there an example that you can point to?
If I'm guessing correctly, it would probably fit in well with what Sutter suggests in Virtuality[^]. If every virtual function is private and invoked by a non-virtual function that is public, that provides a place to add pre- and post-code. But it would certainly have some limitations.
|
|
|
|
|
I'd have to dig up some of old code off of my one drive if it's there. i wasn't using github until more recently.
People usually don't describe it the way I do. It's a technique I picked up while doing research into making a rather ambitious business integration system with COM+ like features. Someone demonstrated cross cutting functionality using the Curiously recurring template pattern - Wikipedia[^]
It gave me one of those aha moments, and since, whenever I see a CRTP like above, i half expect it.
Dr. Dobbs has an article about doing cross cutting but they don't use generic programming to do it.
<h1>Aspect-Oriented Programming & C++</h1> | Dr Dobb's[^]
But if you poke at it you can see there's opportunities for factoring into a template
Real programmers use butterflies
|
|
|
|
|
 Couldn't agree more!
A bit of personal history: once upon a time when I was a young student of programming (an a fairly brilliant one if I may modestly say so  ) I started arguing with one of my professors about the merits of structured programming which I thought it led to far more bloated programs compared with the self-modifying code that I was able to churm. He was wise enough to just encourage me to stick with the structured code even if sometimes my unorthodox style would led to very efficient programs. In time I've got to see the error of my ways specially when I started working with a team and having to share code with humans not only with computers.
When I learned OO it was equally hard at first to get used to it and my programs would have all the flaws a beginner OO programmer would do: too many classes, ill-defined responsibilities, multiple inheritance... you name it, I've done them all.
Generic programming came along and I thought in the beginning that I need a debugger for the obscure error messages that the compiler threw at me.
To make a long story short, each one of these steps brought something to my understanding and now I think I can choose the right tool for each problem. Throwing one of them away would not make me a better programmer.
To the man with a hammer everything looks like a nail!
|
|
|
|
|
I think I probably muddied my point with my lament at the end about coding being worse off for OO. It was intended as a kind of rye way of saying it's been overused so much that maybe it has been harmful overall.
I use OO myself where I find it's appropriate. My post shouldn't be read as a universal condemnation of it.
It's more about how it's often used.
Real programmers use butterflies
|
|
|
|
|
TLDR; Most excesses are bad.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
fair enough. it just seems like a popular thing to do in this case. i see it all over with .NET projects.
Real programmers use butterflies
|
|
|
|
|
I'm curious as to what you meant by C++ changing your attitude towards objects.
Maybe he meant that C++ is multiparadigm programming language as opposed to Java which selling point was that it's true and only OOP?
"I actually never said that [C++ is an object oriented language]. It's always quoted, but I never did. I said that C++ supports object oriented programming and other techniques."
Bjarne Stroustrup, Artificial intelligence Podcast 42:20
What if it had to be big?
Do it in OOP and you will make it big.
"Once you reach a particular size, anything beyond that is no longer a reflection of functionality."
Kevlin Henney, GOTO 2016 • Small Is Beautiful 55:40
The Facebook iOS app has over 18000 classes. How do you compare it to Quake 3 that can render 30FPS of a 3D world on Pentium 3?
My guess is that the Quake team could have developed that fb app with 5 or no classes in 10x less time, the app being 10x less buggy and working at 10x speed vs the current iOS fb app.
At the same time the iOS FB team could hardly construct a PAC-MAN type game. (No disrespect to pac-man coderz)
It is always supposed by OOP supporters that the only pure moral way to write code is OOP and that elite developers do only OOP.
|
|
|
|
|
sickfile wrote: Do it in OOP and you will make it big.
You might have a lot of boilerplate, which is a PITA but not "big". It would be big if, say, functional programming was a much better fit for the problem.
Quote from Kevlin Henney: "Once you reach a particular size, anything beyond that is no longer a reflection of functionality."
It's often true that inside a big system, there's a small system struggling to get out. But as a blanket statement, this quote is just a platitude.
sickfile wrote: The Facebook iOS app has over 18000 classes. How do you compare it to Quake 3 that can render 30FPS of a 3D world on Pentium 3?
18000 classes is a joke. But you can't compare it to the portion of a game that renders graphics, which is highly algorithmic and doesn't require much OO, although your point might be that this wouldn't stop some people from trying to do it that way.
|
|
|
|
|
Greg Utas wrote: although your point might be that this wouldn't stop some people from trying to do it that way.
as in IoT... only because you can, doesn't mean you should  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: as in IoT
You mean my wifi enabled AI toaster is overkill? 
Real programmers use butterflies
|
|
|
|
|
It will be when someone hacks into it to burn your house down. 
|
|
|
|
|
18000 classes is a joke. But you can't compare it to the portion of a game that renders graphics, which is highly algorithmic and doesn't require much OO, although your point might be that this wouldn't stop some people from trying to do it that way.
Exactly. Lets not make it a bigger joke by adding more classes to it.
What's your opinion. Is my judgement wrong that a single Quake core team member can make the whole FB app in less time, more robust, easier to expand, easier to understand, less buggy, space and time optimized without even using the class keyword vs the whole team of architects that put those 18k of classes in the app?
|
|
|
|
|
This is speculation, but my guess is no. For one thing, they're very different application domains. And although it's easy to hoot at 18000 classes, we should hoot at the managers and the corporate culture, not the developers. It could undoubtedly be done with 20% of the staff if only they had a clue whom to keep. But when you have the revenues of this lot, productivity is irrelevant. I've seen similar things. Design documents (before coding, in a waterfall methodology) running to hundreds of pages. FFS, I've never stayed true to anything beyond a high-level design that could be described in 20 pages.
When something has 18000 classes, either there';s no architect or there are way too many. I don't recall which, but one of the currently fashionable methodologies says that there shouldn't be architects. Utter drivel unless it's a very small group of skilled developers that agree on the design.
|
|
|
|
|
Thanks for your time.
Greetings
|
|
|
|
|
It was the same for me: I learned C++ very shortly after C, with little practice programming in any other language (and only for learning purposes, no real-world applications, not even playing around). Therefore the procedural paradigm wasn't heavily ingrained on me.
For many years I fully embraced the OO paradigm. There was a even time when I considered introducing a virtual class hierarchy to break up some deeply nested if/else structures. 
I followed it for more than two decades before starting to realize that there's more to programming than OO. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
You are beating the wrong horse. Do you think the JavaScriptors are better off, chasing after a new framework every week? Or maybe the the real Java guys? They are the most fanatic bunch I have ever seen and become totally helpless when they have a problem that should not exist in their dogmatic little world.
Go over to Q&A and you will see the real problem. For quite some time programmers have been homogenized, sterilized and, most important of all, been taught not to waste much time thinking for themselves. Instead, their heads have been stuffed with rules, conventions and dogmas. Ask them why they think that something MUST be done in a certain way. Always, no exceptions allowed.
It's a rule, they say. Or maybe a convention. Whose rules or conventions? When do they apply? What do they acomplish? Dunno, ask Guru Soandso or company xyz. Anyway, some of these mass produced idiots tend go overboard with the beliefs of their particular religion and make life more interesting for all who are not quite as fanatic as they are.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I wouldn't say I'm being a fanatic about it. I use OO sometimes myself. For example, I'll typically expose the surface area of my APIs as objects, even if behind the scenes they don't work that way.
I've seen a lot of otherwise decent developers overuse objects.
Real programmers use butterflies
|
|
|
|
|
|
I'd never heard of that term being applied to programming.
|
|
|
|
|
My thoughts is that overusing since a mantra in developer circle...
For example, my pet peeve, I think Web developer culture is often very prone to over use interfaces and DTO...
Old code in the web app I am working on, to do a return a simple select statement, can go through 6 interfaces, 4 data copy in the simplest case... 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
