OO is not all that and a bag of chips
-
Greg Utas wrote:
although your point might be that this wouldn't stop some people from trying to do it that way.
as in IoT... only because you can, doesn't mean you should :rolleyes: :-D
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.
-
Software failure isn't caused by the tools or paradigms used to develop it - it's cased the the programmers not doing it right.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I didn't intend to imply otherwise, despite the overarching topic. I switched gears.
Real programmers use butterflies
-
I think I see what you're getting at. Is there an example that you can point to? If I'm guessing correctly, it would probably fit in well with what Sutter suggests in Virtuality[^]. If every virtual function is private and invoked by a non-virtual function that is public, that provides a place to add pre- and post-code. But it would certainly have some limitations.
Robust Services Core | Software Techniques for Lemmings | Articles
I'd have to dig up some of old code off of my one drive if it's there. i wasn't using github until more recently. People usually don't describe it the way I do. It's a technique I picked up while doing research into making a rather ambitious business integration system with COM+ like features. Someone demonstrated cross cutting functionality using the Curiously recurring template pattern - Wikipedia[^] It gave me one of those aha moments, and since, whenever I see a CRTP like above, i half expect it. Dr. Dobbs has an article about doing cross cutting but they don't use generic programming to do it. <h1>Aspect-Oriented Programming & C++</h1> | Dr Dobb's[^] But if you poke at it you can see there's opportunities for factoring into a template
Real programmers use butterflies
-
TLDR; Most excesses are bad.
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.
fair enough. it just seems like a popular thing to do in this case. i see it all over with .NET projects.
Real programmers use butterflies
-
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.
also CS is only somewhat engineering. It's half voodoo. :laugh:
Real programmers use butterflies
-
Nelek wrote:
as in IoT
You mean my wifi enabled AI toaster is overkill? :-D
Real programmers use butterflies
It will be when someone hacks into it to burn your house down. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
-
sickfile wrote:
We don’t have a mathematical model for OOP
That's an extremely good point. To be fair, as I've said elsewhere on the thread I use OO in places - like if I expose an API to whatever i'm writing that will often be OO. And I tend to use OO here and there for other reasons when I'm stuck in a hard OO env like Java or C# I limit its use though: 1. Does it help explain the code? 2. Does it work with the rest of the code rather than against it? 3. Does it encapsulate an abstraction such that it makes it simpler to employ? There are so many times when the answers to those questions are no, and I see people using objects. See @SanderRossel's console app upthread - he was ribbing me but it's a good example of class misuse.
Real programmers use butterflies
"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
-
"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
