OO is not all that and a bag of chips
-
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.
-
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
Tom Deketelaere wrote:
I have no idea I just enter the numbers in this program and it gives me the solution.
Reminds me of when I was considering drilling a ground heat well for a heat pump, and contacted a couple drilling companies. One of them had to know the exact area to have floor heating: Well... in the first round it will be around 120 sq.m, but in a couple years, I will probably furnish two basement rooms, for another 40 sq.m. "I need a single figure from you to calculate how deep the well should be, not two!" The new rooms be coming, so let's say 160 sq.m. then, even though it will be less to begin with. "But then you won't have a well of the correct depth." Fine with me - it will be a little deeper than needed, but... "Then we can take no responsibility for the dimensioning, if you do not give us the correct figures!" I ended up dropping the idea of drilling a well altogether - under my house is more than 45 m of loose masses, which are quite expensive to "drill" (you need to reinforce the hole with solid pipes all the way down) - but if I had realized the idea, I certainly would not have used that company to do the drilling!
-
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 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).
-
But also, with the failure rate of software I'm glad we don't build bridges and skyscrapers. :laugh:
Real programmers use butterflies
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
-
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
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](https://www.haskell.org/tutorial/classes.html), and also [traits in Rust](https://doc.rust-lang.org/book/ch10-02-traits.html)). And if you really have a bunch of related types, then gathering them together as a ['sum type'](https://en.wikipedia.org/wiki/Tagged\_union) often has better ergonomics.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
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 did OO before there was no OO... (Well, Simula had been around for some years, but the term OO was not yet in use. The professor teaching my first university level programming course insisted on strict discipline: With a Pascal RECORD definition followed those functions that operated on the record fields; those were the only code allowed to work on the fields - just like OO methods. A record "class" could have variants, "subclasses", etc. I must admit that I liked the orderly, disciplined way. We didn't know that we did OO; it was just a "best practices" thing to more easily manage the operations on the records. A couple of years later, I got access to the OS source code for a 16-bit mini, written in a language midway between assembler and C. For the drivers, I saw a class hierarchy: Several subclasses of class objects, with method tables and pointers to superclasses, and then instances objects of these for each device, all hand written, but the same way as the a C++ compiler would lay out its classes and instances. I must admit that I was impressed. By this time, OO was on its way in, so I recognized the OO concepts, but when I mentioned this to the OS developers they didn't get it. That's simply how you write an orderly structure of generic drivers with specializations. OO, what's that? So I've come to use OO in a fairly lightweight style: To organize similar data and the operations to go with them. Language developers seem to think that every new release of a language simply must include some new "language concepts", some fancy mechanism(s) that can do things in even more abstract, hard-to-grasp ways (maybe "elegant", once you have comprehended it, but often quite far from "obvious" in the way it works). I tend to ignore super-conceptual, super-fancy mechanism; even though they may help you conceptualize the problem solution in your head, it often tends to make the program code more obscure. "That's not a feature, that is a (design) bug!" Use those OO facilities that make the program code more lucid, better organized. But don't let it obscure your program solution, just because you insist on showing that you master this new concept that was introduced in the last language revision.
-
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 'OOP as currently conceived by many languages didn't fulfil all the promises made about it' is particularly controversial. Especially the idea that we can (or even should) model reality into classes representing things seems a bit odd in retrospect. We found ways to work around these limitations (like design patterns, not using inheritance), but the very fact that we need these things shows the limitations of the paradigm. I came from this from the other way, I learned functional programming and am now very happily merging the 2 paradigms together. (we all do, LINQ is FP) OOP does some things better, FP does others better (like concurrency), the most important thing is to keep it simple. People get hung up on reuse and abstractions, while they should be focussed on cognitive load and simplicity.
-
True, but all the same I'm staying away from glass buildings types in my area these days ;P
Tom
If I knew where a couple of classmates have been working I would avoid some products too :rolleyes:
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