OO is not all that and a bag of chips
-
Disclaimer: Unpopular opinion A lot of coders spend a lot of lines of code dividing things into tiny steps which they then make whole classes for and abstract everything to the Nth degree, often even when the abstraction is not helpful. Back when I was a green coder, I used to write OO code somewhat like this. Then C++ changed me. I stopped relying on objects so much. This bled over into other languages. Now my code is about expedience. For example, I created a little HTTP server that does the request/response cycle in a single method, with two support structs instead of a dozen classes. My code is smaller, faster, easy enough to understand if you aren't a beginner and overall better for it. It's getting to the point where I think OO is an ill conceived paradigm - and not even because it's Broken As Designed (it's not) but because it gets way overused to the point where the dev world may have been better off with something else.
Real programmers use butterflies
You are quarantined for the next 2 weeks to work with only Vb6. :laugh:
-
You are quarantined for the next 2 weeks to work with only Vb6. :laugh:
That's not a quaratine, that's a punishment :rolleyes: :laugh: :laugh:
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.
-
You are quarantined for the next 2 weeks to work with only Vb6. :laugh:
NOOOOOOOOOOOOOOOOOOOO
Real programmers use butterflies
-
That's not a quaratine, that's a punishment :rolleyes: :laugh: :laugh:
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.
-
Disclaimer: Unpopular opinion A lot of coders spend a lot of lines of code dividing things into tiny steps which they then make whole classes for and abstract everything to the Nth degree, often even when the abstraction is not helpful. Back when I was a green coder, I used to write OO code somewhat like this. Then C++ changed me. I stopped relying on objects so much. This bled over into other languages. Now my code is about expedience. For example, I created a little HTTP server that does the request/response cycle in a single method, with two support structs instead of a dozen classes. My code is smaller, faster, easy enough to understand if you aren't a beginner and overall better for it. It's getting to the point where I think OO is an ill conceived paradigm - and not even because it's Broken As Designed (it's not) but because it gets way overused to the point where the dev world may have been better off with something else.
Real programmers use butterflies
I do what I want to do - what makes sense for what I'm doing. Every now and then I'll be inspired to wrap functionality into a class - as much for readability as anything else. Probably because I grew up with that old fashioned idea of a .lib file or something.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
> 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?
-
I do what I want to do - what makes sense for what I'm doing. Every now and then I'll be inspired to wrap functionality into a class - as much for readability as anything else. Probably because I grew up with that old fashioned idea of a .lib file or something.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
That's exactly what I do, even for the sake of encapsulation. The only difference being a translation unit instead of a class. Any way that gets the job done is fine.
-
> 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.
Robust Services Core | Software Techniques for Lemmings | Articles
-
honey the codewitch wrote:
But also, with the failure rate of software I'm glad we don't build bridges and skyscrapers.
The % of "so-called" programmers is much, much, much bigger than the % of architechts.
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.
I wouldn't be so sure. For one off my previous jobs I had to write a program that calculates the thickness (not sure if that's the word) for glass so that it could support a given weight. When I asked the structural engineer about how to implement the formula for this, so a step by step calculation he replied: I have no idea I just enter the numbers in this program and it gives me the solution. So this structural engineer was entirely counting on a programmer (who I hope was counting on a actual structural engineer) somewhere.
Tom
-
Disclaimer: Unpopular opinion A lot of coders spend a lot of lines of code dividing things into tiny steps which they then make whole classes for and abstract everything to the Nth degree, often even when the abstraction is not helpful. Back when I was a green coder, I used to write OO code somewhat like this. Then C++ changed me. I stopped relying on objects so much. This bled over into other languages. Now my code is about expedience. For example, I created a little HTTP server that does the request/response cycle in a single method, with two support structs instead of a dozen classes. My code is smaller, faster, easy enough to understand if you aren't a beginner and overall better for it. It's getting to the point where I think OO is an ill conceived paradigm - and not even because it's Broken As Designed (it's not) but because it gets way overused to the point where the dev world may have been better off with something else.
Real programmers use butterflies
-
Let's face it: C is a successful programming language. C++ has its drawbacks. Java is a pile of crap. In this regard, how good is OOP? :-D
C# is pretty great, but then I'm just being difficult. :)
Real programmers use butterflies
-
C# is pretty great, but then I'm just being difficult. :)
Real programmers use butterflies
-
OO isn't a problem unless you turn it into a problem. Unfortunately, a lot of people manage to.
Real programmers use butterflies
-
CPallini wrote:
C# enforces OOP. That's no good.
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.
-
OO isn't a problem unless you turn it into a problem. Unfortunately, a lot of people manage to.
Real programmers use butterflies
-
CPallini wrote:
C# enforces OOP. That's no good.
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.
-
I wouldn't be so sure. For one off my previous jobs I had to write a program that calculates the thickness (not sure if that's the word) for glass so that it could support a given weight. When I asked the structural engineer about how to implement the formula for this, so a step by step calculation he replied: I have no idea I just enter the numbers in this program and it gives me the solution. So this structural engineer was entirely counting on a programmer (who I hope was counting on a actual structural engineer) somewhere.
Tom
Jerks and morons are overall But still, there is much more less prepared programmers than architechts. Alone due to college. Note: And I am not saying that having a degree makes you automatically better professional, it is just about the numbers of people working in each field.
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.
-
Disclaimer: Unpopular opinion A lot of coders spend a lot of lines of code dividing things into tiny steps which they then make whole classes for and abstract everything to the Nth degree, often even when the abstraction is not helpful. Back when I was a green coder, I used to write OO code somewhat like this. Then C++ changed me. I stopped relying on objects so much. This bled over into other languages. Now my code is about expedience. For example, I created a little HTTP server that does the request/response cycle in a single method, with two support structs instead of a dozen classes. My code is smaller, faster, easy enough to understand if you aren't a beginner and overall better for it. It's getting to the point where I think OO is an ill conceived paradigm - and not even because it's Broken As Designed (it's not) but because it gets way overused to the point where the dev world may have been better off with something else.
Real programmers use butterflies
Agree... More and more I'm starting to think we have been going the wrong way. The article that really had me started thinking about this was this one: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 Excellent article. 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!
-
Jerks and morons are overall But still, there is much more less prepared programmers than architechts. Alone due to college. Note: And I am not saying that having a degree makes you automatically better professional, it is just about the numbers of people working in each field.
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.
True, but all the same I'm staying away from glass buildings types in my area these days ;P
Tom
-
Disclaimer: Unpopular opinion A lot of coders spend a lot of lines of code dividing things into tiny steps which they then make whole classes for and abstract everything to the Nth degree, often even when the abstraction is not helpful. Back when I was a green coder, I used to write OO code somewhat like this. Then C++ changed me. I stopped relying on objects so much. This bled over into other languages. Now my code is about expedience. For example, I created a little HTTP server that does the request/response cycle in a single method, with two support structs instead of a dozen classes. My code is smaller, faster, easy enough to understand if you aren't a beginner and overall better for it. It's getting to the point where I think OO is an ill conceived paradigm - and not even because it's Broken As Designed (it's not) but because it gets way overused to the point where the dev world may have been better off with something else.
Real programmers use butterflies
Same. 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.
