OO is not all that and a bag of chips
-
But we *do* build software that [keeps aircraft in the sky](https://en.wikipedia.org/wiki/Boeing\_737\_MAX\_groundings) (that's a system failure, arguably, but involves the software), keeps nuclear reactors from melting down, and [calculates dosages for medical devices](https://en.wikipedia.org/wiki/Therac-25)... I've developed software that is currently flying on passenger aircraft and I can tell you with certainty that the practices and processes used for those lines of code were vastly different than what's used for most software - the [NASA Software Engineering Handbook](https://swehb.nasa.gov/display/SWEHBVC/Book+A.+Introduction) is a pretty good example of this.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Don't even get me started on the dosages one. A multithreading issue killed 3 people (as i recall) connected to machines delivering chemo treatments.
Real programmers use butterflies
-
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
Codewitch, from the replies, your opinion isn't all that unpopular. In specific uses cases, OO is a great technique. Thinking about encapsulation is helpful in identifying all the pieces-n-parts, even in situations where the solution is procedural. But as others have stated, it's not a universal tool and it's amazing how badly people use and mis-use it. I've seen co-workers spend months shoe-horning a solution into an inheritance model, when a procedural solution was completed in 2 weeks (after the OO solution failed). It's like everything else -- when the only tool you have is a hammer, everything looks like a nail ...
-
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).
I'd argue that C++ doesn't have a real vision of OO. It is capable of doing OO but wasn't really made for it. Rather than OOP, CPP is geared for generic programming, like how STL is laid out.
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.
I profoundly agree
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!
Agreed, and thanks for the link. It gives me some reading for this morning =)
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!
your link links back to the lounge btw. I had to copy it out to get it
Real programmers use butterflies
-
I've seen plenty of people, including profs who should darn well know better try to use C++ as an object oriented language. It's one of my peeves. I want to buy anyone that does it a copy of Accelerated C++ by Andrew Koenig and Barbara Moo, so that they can learn the more effective way to abstract in C++
Real programmers use butterflies
-
honey the codewitch wrote:
I'm glad we don't build bridges and skyscrapers.
We've been building physical structures for thousands of years, and writing software for less than 80. Architecture and civil engineering are obviously more mature disciplines than software engineering. Assuming civilization survives, I am certain that our software development efforts will be viewed by future engineers in the same manner that the builders of mud huts are viewed by modern civil engineers. (But we do build some very impressive mud huts! :-\ )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I think you are giving too much credit with the "mud". Mud + straw bricks will last a very long time! More like straw huts with a few sticks. This is making me think of software before memory protection. I imagine a village with thatched roofs side by side by side. Each house is an app. The thatched roofs are the ram for that app. The village is the whole machine. A fire in one house would rapidly jump roofs and take out the entire village.
-
your link links back to the lounge btw. I had to copy it out to get it
Real programmers use butterflies
-
I've seen plenty of people, including profs who should darn well know better try to use C++ as an object oriented language. It's one of my peeves. I want to buy anyone that does it a copy of Accelerated C++ by Andrew Koenig and Barbara Moo, so that they can learn the more effective way to abstract in C++
Real programmers use butterflies
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 teachingC++. Might be there are also very-old-school teachers that don't appreciate (or simply are unaware of) the powerfulOOPsupportC++provides. But I believe this is a negligible minority. -
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 teachingC++. Might be there are also very-old-school teachers that don't appreciate (or simply are unaware of) the powerfulOOPsupportC++provides. But I believe this is a negligible minority.generic programming is something anyone can learn easily for about $25-$30 using Accelerated C++ - too bad it's not a textbook
Real programmers use butterflies
-
it was worth it. Thanks for the link :)
Real programmers use butterflies
-
generic programming is something anyone can learn easily for about $25-$30 using Accelerated C++ - too bad it's not a textbook
Real programmers use butterflies
-
I think you are giving too much credit with the "mud". Mud + straw bricks will last a very long time! More like straw huts with a few sticks. This is making me think of software before memory protection. I imagine a village with thatched roofs side by side by side. Each house is an app. The thatched roofs are the ram for that app. The village is the whole machine. A fire in one house would rapidly jump roofs and take out the entire village.
englebart wrote:
Mud + straw bricks will last a very long time!
Yes, in the right climate. It is not well suited to climates with heavy rains. This is beside the point. No modern architect would seriously consider using mud (or mud + straw) for a building, and likewise no future software engineer would think of using the techniques (or lack of them :sigh: ) used in most current software.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
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 don't think that OO in general is "ill conceived" but I do agree that is by far overused and misused since it was "invented". There are certainly benefits to encapsulate both code and data, and to some degree, abstraction can help to make code more readable and thus maintainable. But in far too many cases, this leads nowadays just to a royal mess where people do this ad nauseam, creating totally unreadable and incomprehensible code (beside the original coder, at the time they creating that piece of code) and are even proud of it. It's simply has turned into "too much of a good thing"...
-
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
I had similar experience early in my career and now have another. I worked on a banking application where I needed to calculate APR (annual percentage rate). I asked several mortgage bankers how they do the calculation, not a one knew. Each stated the rate was on the docs they received from the intake clerk. I asked the clerk, she said she used her mortgage calculator, a hand held device. Currently, I am investigating solar panels for my home. I have 4 companies responding each with proposing different configurations despite using the same utilization rates published by my electric provider. Accuracy, it appears, is in the math of the beholder.
-
I don't think that OO in general is "ill conceived" but I do agree that is by far overused and misused since it was "invented". There are certainly benefits to encapsulate both code and data, and to some degree, abstraction can help to make code more readable and thus maintainable. But in far too many cases, this leads nowadays just to a royal mess where people do this ad nauseam, creating totally unreadable and incomprehensible code (beside the original coder, at the time they creating that piece of code) and are even proud of it. It's simply has turned into "too much of a good thing"...
That's why i say it was ill conceived. At least perhaps. Is software development better or worse off because of it? I'm not so sure it's better. I don't know though.
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
-
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!
the main take away from this article could be summarized like: " I’m not criticizing Alan Kay’s OOP — he is a genius. I wish OOP was implemented the way he designed it. I’m criticizing the modern Java/C# approach to OOP..." The second thing: the article writer talks about OOP and there no mentioning about one of the best OO system -- Smalltalk which was a result of Alan's efforts at Zerox PARC.
-
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).