The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
The problem with professors is they want to teach their students 'low level stuff', like, for instance, arrays, using C++. It can be done, of course, but it isn't, in my opinion, the smartest way to start teaching C++.
Might be there are also very-old-school teachers that don't appreciate (or simply are unaware of) the powerful OOP support C++ provides. But I believe this is a negligible minority.
I think the real world is similar. They always want me to, say, distinguish between different people when I see them as a homogenous grey map. They even try to tell that this "object" belongs to "that" object, while I think I should be free to use anything the way I want to. They even say that there are things I am not allowed to look at, it is their "private life". This idea of the world being split into distinct "objects" really bothers me.
The simplest pieces of code we try to make so abstract that at some point it doesn't make sense anymore and gets hard to understand. You end op with classes like: OrderManagerProviderOrchestrator or OrderFactoryStrategy. And all of this because, you know, SOLID, KISS, abstraction, dependency injection, blah blah blah,...
We spend so much time making code that way, making it independent, scaleable, etc. But in the end, whenever some change it necessary: oh no, this means we have to refactor everything!
After doing C++ for a couple of years, I've mostly restricted object design to db models and very rudimentary abstractions over external services and data sources.
I feel like in OO design, too often we build abstractions on top of abstractions in a weird attempt to clean up ugly datasets, that somehow feel wrong to us on a basic level. 95% plain data and 5% esoteric? You can bet someone over-engineered a solution so the 5% can now be deduced from model-state alone.
Every year I spend more and more time reversing situations like that, just to keep projects manageable. Cutting factories, flattening inheritance trees, and sometimes even re-introducing the dreaded 2% data redundancy that took 15 objects to solve.
IMO, people are inherently bad at abstraction, so it's in our best interest to KISS.
I found much the same - although it was C++ that finally convinced me that OO wasn't 'all that' 8)
After 'objectifying' some intricate real-world code (for an airline/shipping booking system) I realised that in order to get the behaviour of the objects right I was creating what were in effect object 'global' variables that could (due to inheritance) easily get accidentally 'hidden' by a variable with the same name in the dependent module. In other words - because it was a legal thing to do in C++ - variable scope could be overridden without warning (fortunately compilers these days do warn about such things).
When the fiasco that was manipulators (which I used extensively!) hit when going from Ver1 to Ver2, which then got corrected again in Ver3 (FFS!) I decided that C++ and its vision of OO was getting far more complex and difficult to manage correctly (for me anyway - my failing perhaps, not the language itself?) that I switched to Java for my next OO projects. Very verbose cf C++ but much more stable at the level I was using.
However, other programmers of long-standing who I respect have gradually formed similar views to mine about OO and C++ in particular so I don't feel too downhearted. 8)
Quite by chance all my work now is in either Visual Basic for Applications (Access), SQL Server or Python, so go figure! If I had to go back to something close to the machine I would almost certainly go for C rather than C++ (or maybe Go etc).
Agreed. I started using OO over 20 years ago and from the start, I was wary of some of the uses I saw, and that's just increased as time's passed.
There are some cases where it can be useful, but the vast majority of the time, you are more likely to get value from constraining behaviour (I like the type class feature in Haskell, and also traits in Rust). And if you really have a bunch of related types, then gathering them together as a 'sum type' often has better ergonomics.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Last Visit: 26-May-20 23:48 Last Update: 26-May-20 23:48