OO is not all that and a bag of chips
-
But also, with the failure rate of software I'm glad we don't build bridges and skyscrapers. :laugh:
Real programmers use butterflies
Air traffic control, aircraft avionics Medical equipment Law enforcement communications Defense electronics and C3I Manufacturing controls, especially for food and medication ... All of these applications and many more have profound human health and safety implications. We build much more than bridges and skyscrapers.
Software Zen:
delete this; -
Air traffic control, aircraft avionics Medical equipment Law enforcement communications Defense electronics and C3I Manufacturing controls, especially for food and medication ... All of these applications and many more have profound human health and safety implications. We build much more than bridges and skyscrapers.
Software Zen:
delete this;fair point. :)
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
honey the codewitch wrote:
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.
They're doing it wrong. Deciding what things or processes to abstract and how to divvy things up isn't difficult to do once you know how, but learning it can be painful. It took me over ten years to acquire the background to be able to handle some things. There are a lot of developers out there who simply never get it. They end up blindly applying one or more approaches from Design Patterns[^] or other cookbooks. They finally reach steady state as one trick ponies (apologies to Paul Simon) where every problem is a nail, and they've got the hammer with which to beat it to death.
Software Zen:
delete this; -
honey the codewitch wrote:
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.
They're doing it wrong. Deciding what things or processes to abstract and how to divvy things up isn't difficult to do once you know how, but learning it can be painful. It took me over ten years to acquire the background to be able to handle some things. There are a lot of developers out there who simply never get it. They end up blindly applying one or more approaches from Design Patterns[^] or other cookbooks. They finally reach steady state as one trick ponies (apologies to Paul Simon) where every problem is a nail, and they've got the hammer with which to beat it to death.
Software Zen:
delete this;I agree with that. I did some hard time as a software architect. :)
Real programmers use butterflies
-
Any tool even a lame one is as good as a person using it. OOP is great when used and applied correctly.
-
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.
-
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
Coincidentally, I was tripping through a large C++ program (about 100,000 LOC) to make some relatively minor enhancements. The original architect(s) of this program did a fantastic job of using all the features of C++ including lambdas, auto's, executable code in header files, virtual functions, just to name a few. The frigging code was terribly difficult to follow! But what was the major hindrance was the exorbitant use of getters/setters between classes. A lot of the code looked like:
bool Var;
.....
bool ClassName::isVarSet(){
return Var;
}
using 6 lines on the screen. Alwfully tough to read and comprehend. Caused me to start hating C++.
-
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
Thanks for your time. Greetings
-
I think you'd be surprised at how many rely on Autocad to do their structural calculations for them.
I knew* one Mobile company who thought it would be a good idea to use Lotus Notes to manage their Telecom infrastructure. *Deliberately using past tense here...
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)
-
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.
Clay is actually a very good building material and it's used occasionally to construct ecological buildings. See for example Clay Houses - Resilient Fireproof Unique and Attractive[^] That said, it's advantages are so impressive that it's hard to understand why it's not used more widely.
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)
-
I knew* one Mobile company who thought it would be a good idea to use Lotus Notes to manage their Telecom infrastructure. *Deliberately using past tense here...
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)
-
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
And we do build mars orbiter software[^] that uses imperial units :doh:
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)
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
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. :omg:
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)
-
And we do build mars orbiter software[^] that uses imperial units :doh:
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)
Or [Ariane-5 control software that tried to cram a 64-bit float into a 16-bit integer with disastrous consequences](https://en.wikipedia.org/wiki/Cluster\_(spacecraft)#Launch\_failure) - pretty much any area where software is used can end in calamity...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Clay is actually a very good building material and it's used occasionally to construct ecological buildings. See for example Clay Houses - Resilient Fireproof Unique and Attractive[^] That said, it's advantages are so impressive that it's hard to understand why it's not used more widely.
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)
Do you mean raw clay, or baked clay? Raw clay tends to go soggy when wet...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Or [Ariane-5 control software that tried to cram a 64-bit float into a 16-bit integer with disastrous consequences](https://en.wikipedia.org/wiki/Cluster\_(spacecraft)#Launch\_failure) - pretty much any area where software is used can end in calamity...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
32768 m/s should be fast enough for anybody! ;P
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)
-
Do you mean raw clay, or baked clay? Raw clay tends to go soggy when wet...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Not baked (as in bricks). When building a structure, the clay needs to be wet so it merges tightly with the rest of the material and pores get closed. It needs to dry for quite some time, so you might run into trouble building large structures unless you can be very sure to have a long period of dry weather. I know it works pretty well because my brother used clay (pellets) and straw to replace the walls in his studwork house. No problems with soaking at all.
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)
-
Not baked (as in bricks). When building a structure, the clay needs to be wet so it merges tightly with the rest of the material and pores get closed. It needs to dry for quite some time, so you might run into trouble building large structures unless you can be very sure to have a long period of dry weather. I know it works pretty well because my brother used clay (pellets) and straw to replace the walls in his studwork house. No problems with soaking at all.
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)
I sit corrected. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Coincidentally, I was tripping through a large C++ program (about 100,000 LOC) to make some relatively minor enhancements. The original architect(s) of this program did a fantastic job of using all the features of C++ including lambdas, auto's, executable code in header files, virtual functions, just to name a few. The frigging code was terribly difficult to follow! But what was the major hindrance was the exorbitant use of getters/setters between classes. A lot of the code looked like:
bool Var;
.....
bool ClassName::isVarSet(){
return Var;
}
using 6 lines on the screen. Alwfully tough to read and comprehend. Caused me to start hating C++.
There's such thing as K.I.S.S. I feel your pain though - diving through the STL headers sometimes feels like that.
Real programmers use butterflies
-
I sit corrected. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Don't worry. I'm not an expert, but I guess that our ancestors took ages to learn why some 'mud' huts lasted forever while others melted away in the very first rain storm. ;)
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)
