OO is not all that and a bag of chips
-
"We don't have a mathematical model for OOP" sounds like a lament from a formal methods fanboi, in which case the objection can be ignored.
Robust Services Core | Software Techniques for Lemmings | Articles
heh. I look at this way - if we don't have a mathematical model for it then we're limited in the sorts of transformations we can do the code. Why would anyone want to transform code? A compiler does just that. A mathematical model lends itself to rigorous checking as well. I'm not a purist about it, but I certainly see the advantages of it and it's one of the reasons I'm fond of functional programming.
Real programmers use butterflies
-
*headdesk*
Real programmers use butterflies
That code is uber 1337! :D But usually... TL;DR: I agree with your post. The long version: I tend to write a bunch of interfaces (as necessary) that explain the function of the code. Take, for example, an IUserRepository. When I see a (ASP.NET Core) Controller being injected with an IUserRepository I know this Controller does something with users. I don't know (or care) where the users come from, but I know I need them. If you look at the specific code that uses the IUserRepository you'll find stuff like userRepository.GetUser(id), which is way more descriptive than some code that accesses a database. So in that sense, I often use classes and methods to describe what my code is doing. That, for me, and to lesser extent re-use of code, are the biggest pros of OOP. I'm not a big fan of re-use anymore. Back in the day I re-used all the things, but just because two pieces of code incidentally need the same results doesn't mean they do the same thing. I now make a clear split of functional re-use and technical re-use. Functional re-use is rare, because that would mean a user has two ways to do the exact same thing. It happens, but not all that often. I think I write my code less "OOP" than seven or even five years ago. The OOP I still write is more architectural in nature (like I now make heavy use of DI and interfaces, but not so much of base classes and such). I've written some simple programs in Haskell, a purely functional language, but I think that doesn't work all that well. It comes natural to think in objects and to have side effects at some point. Nevertheless I started to write more functional in my OOP code, mostly no side effects. I'm pretty sure my bug-to-code ratio went down since I've employed the no side effects approach. A function just does its thing and produces a result, but it won't affect the overall flow or state of the program. All the results come together in the calling function, mostly a controller, and then I do all the side effects in one spot. Makes the code a lot easier to read and you have a lot less to think about. It's still OOP, so it doesn't always work like that, but I try when I can. Another change in my code is the use of delegates instead of one-function interfaces. Makes for less abstraction and classes and it's still easy to read. The biggest game changer for me, and this saved me a lot of bugs, was when I started to use curly braces for one line if and loop statements though :D
Best, Sander
-
But also, with the failure rate of software I'm glad we don't build bridges and skyscrapers. :laugh:
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.
-
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.
Software techniques will undoubtedly improve, but there are things from 45 years ago that I don't find primitive. I think software will always be difficult because, unlike engineers, we continually evolve existing products and, unlike mechanics, we repair them while they are up and running.
Robust Services Core | Software Techniques for Lemmings | Articles
-
Software techniques will undoubtedly improve, but there are things from 45 years ago that I don't find primitive. I think software will always be difficult because, unlike engineers, we continually evolve existing products and, unlike mechanics, we repair them while they are up and running.
Robust Services Core | Software Techniques for Lemmings | Articles
Lets not forget that engineers don't always get it right, either. Sometimes a fix is possible like the [Millennium Bridge, London - Wikipedia](https://en.wikipedia.org/wiki/Millennium\_Bridge,\_London). Other times, though the failure can be spectacular and long remembered, like this one [Tacoma Narrows Bridge (1940) - Wikipedia](https://en.wikipedia.org/wiki/Tacoma\_Narrows\_Bridge\_(1940)).
Keep Calm and Carry On
-
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
