ratchetfreak
Closure is really just a combination of the tuple and dynamic dispatch. Where dynamic dispatch is a pure stateless function pointer.
That's how you'd typically implement it, yes. However, exponential objects (again, to use the category theory term) are well-defined mathematical objects. Closures were invented, but exponential objects were discovered.
Timothy Wright:
it is wrong to compare the rewriting of software to "reinventing the wheel"
-- I think this is an important insight, and I'd certainly not thought about it this way before. However I wonder if this isn't at risk of being a bit pedantic? I mean, certainly you have demonstrated that the wheel is a poor analogy, but in other industries, they reuse a lot more than just the six simple machines you describe, right? I am guessing here, because I've never worked in these industries, but I always thought that car manufacturers would make extensive reuse of large existing components (not just wheels), and computer hardware manufacturers would reuse large blocks of circuitry that are working well. Maybe this is what the article is trying to draw a comparison with, rather than a literal wheel/axle level building block?
Yeah, a wheel is not a good analogy, but even with a perfect analogy, whatever that may be, if there is a solution to a problem then I would use that, provided it actually worked. I find that most libraries or tools promise a lot but do not actually work or have bugs that make it too much risk, or are structured in such a way that my specific needs are not provided. There are very few libraries I use. If OOP delivered on the promised of reusing the "wheel" then we should already have libraries to do all the low-level programming tasks.
Timothy Wright:
If either one of these technologies was good, then we wouldn't be here, where everything is broken, nothing works, systems crash all the time, and everyone just pretends things are better because the hardware people have been learning to use the tools better, making computers faster, to hide all the problems.
-- I'm not quite sure I follow this. I don't accept that everything is broken, but I'm assuming you mean that rhetorically rather than literally so fair enough. However is your argument here that had OO and FP simply never been used, then software would be less "broken"?
I don't know how long you've been messing with software, but over the decades I see everything getting bigger, slower, buggier, more complicated, and less useful. I spend all day, every day, fixing other people's broken stuff. I have no scientific data to back this up except my own experineces.
Timothy Wright:
A logarithmic curve is what happens when you continually try to improve a flawed technology. Hardware has an exponential curve. Why is that?
-- Again could you elaborate on this? Is your argument that the natural course of things is for exponential improvement, and that falling short of that means you're doing something wrong? My impression was that part of the point of this article was to argue that exponential improvement isn't actually to be expected as the norm, and this isn't a new idea. For example the No Silver Bullet article does a good job of explaining why we're unlikely to see orders of magnitude improvements in software engineering in the future, and it doesn't need the misguided use of OOP to explain it.
I didn't really think this on through. So yes, it doesn't make any sense.
Timothy Wright:
This opinion alone tells me that this is just another theoretical article from an out-of-touch computer scientist.
-- I find that quite hard to accept. Robert C. Martin is really not an aloof academic computer scientist. He's spent his life working in the software industry. That doesn't mean he's right of course, but I simply can't dismiss him as someone lacking relevant experience or background.
I am just reacting to the "Eclipse and IntelliJ are great" comment. I think we have different definitions of good software and powerful tools. I have read many of his books and he does seem more like a regular programmer than some of the other famous computer scientists.
Timothy Wright:
we have to figure out what the "six simple tools" are for software. So far, that still remains an elusive mystery.
-- You're absolutely right on this last point; what he never says in this article is what those simple tools are, or perhaps more importantly, who gets to decide what that core toolset should be. If you asked programmers to list their core toolsets, I imagine it would be difficult to find two programmers who would draw up the same list!
And we can say that we have these, with statments, conditionals, variables, functions, etc. But I don't think there will be any language ever that is the "one true language".
What I do think is that there are different kinds of programming, different types of software, and different ways to make that software the best it can be. OOP may be the best way to build software that evolves over years and is worked on by dozens of people, constantly seeing new developers replace old ones, and managers needing to justify their jobs with gant charts, pair programming, scrum, sigma 6, and whatever crazy stuff people do now.
But games are different. Games do not need frameworks to help mediocre and/or apathetic people with getting work done. Games push the abilities of the platform, and try to do the most possible with least amount of steps. I don't think there is a single thing that they teach you in school that you don't have to throw away to write a clean, fast real-time simulation. Perhaps instead of telling students that OOP is terrible and they should never use it and everything they learned is school is wrong, maybe we just convey that to make performant desktop/console programs, most of those modern software methodologies just go out the window.
it is wrong to compare the rewriting of software to "reinventing the wheel"
-- I think this is an important insight, and I'd certainly not thought about it this way before. However I wonder if this isn't at risk of being a bit pedantic? I mean, certainly you have demonstrated that the wheel is a poor analogy, but in other industries, they reuse a lot more than just the six simple machines you describe, right? I am guessing here, because I've never worked in these industries, but I always thought that car manufacturers would make extensive reuse of large existing components (not just wheels), and computer hardware manufacturers would reuse large blocks of circuitry that are working well. Maybe this is what the article is trying to draw a comparison with, rather than a literal wheel/axle level building block?
Yeah, a wheel is not a good analogy, but even with a perfect analogy, whatever that may be, if there is a solution to a problem then I would use that, provided it actually worked. I find that most libraries or tools promise a lot but do not actually work or have bugs that make it too much risk, or are structured in such a way that my specific needs are not provided. There are very few libraries I use. If OOP delivered on the promised of reusing the "wheel" then we should already have libraries to do all the low-level programming tasks.
Timothy Wright:
If either one of these technologies was good, then we wouldn't be here, where everything is broken, nothing works, systems crash all the time, and everyone just pretends things are better because the hardware people have been learning to use the tools better, making computers faster, to hide all the problems.
-- I'm not quite sure I follow this. I don't accept that everything is broken, but I'm assuming you mean that rhetorically rather than literally so fair enough. However is your argument here that had OO and FP simply never been used, then software would be less "broken"?
I don't know how long you've been messing with software, but over the decades I see everything getting bigger, slower, buggier, more complicated, and less useful. I spend all day, every day, fixing other people's broken stuff. I have no scientific data to back this up except my own experineces.
Timothy Wright:
A logarithmic curve is what happens when you continually try to improve a flawed technology. Hardware has an exponential curve. Why is that?
-- Again could you elaborate on this? Is your argument that the natural course of things is for exponential improvement, and that falling short of that means you're doing something wrong? My impression was that part of the point of this article was to argue that exponential improvement isn't actually to be expected as the norm, and this isn't a new idea. For example the No Silver Bullet article does a good job of explaining why we're unlikely to see orders of magnitude improvements in software engineering in the future, and it doesn't need the misguided use of OOP to explain it.
I didn't really think this on through. So yes, it doesn't make any sense.
Timothy Wright:
This opinion alone tells me that this is just another theoretical article from an out-of-touch computer scientist.
-- I find that quite hard to accept. Robert C. Martin is really not an aloof academic computer scientist. He's spent his life working in the software industry. That doesn't mean he's right of course, but I simply can't dismiss him as someone lacking relevant experience or background.
I am just reacting to the "Eclipse and IntelliJ are great" comment. I think we have different definitions of good software and powerful tools. I have read many of his books and he does seem more like a regular programmer than some of the other famous computer scientists.
Timothy Wright:
we have to figure out what the "six simple tools" are for software. So far, that still remains an elusive mystery.
-- You're absolutely right on this last point; what he never says in this article is what those simple tools are, or perhaps more importantly, who gets to decide what that core toolset should be. If you asked programmers to list their core toolsets, I imagine it would be difficult to find two programmers who would draw up the same list!
And we can say that we have these, with statments, conditionals, variables, functions, etc. But I don't think there will be any language ever that is the "one true language".
What I do think is that there are different kinds of programming, different types of software, and different ways to make that software the best it can be. OOP may be the best way to build software that evolves over years and is worked on by dozens of people, constantly seeing new developers replace old ones, and managers needing to justify their jobs with gant charts, pair programming, scrum, sigma 6, and whatever crazy stuff people do now.
But games are different. Games do not need frameworks to help mediocre and/or apathetic people with getting work done. Games push the abilities of the platform, and try to do the most possible with least amount of steps. I don't think there is a single thing that they teach you in school that you don't have to throw away to write a clean, fast real-time simulation. Perhaps instead of telling students that OOP is terrible and they should never use it and everything they learned is school is wrong, maybe we just convey that to make performant desktop/console programs, most of those modern software methodologies just go out the window.
Edited by Timothy Wright
on
I suppose something different about software vs cars:
1. Reinventing a software wheel requires only time, not hardware, not a factory to build it, and molds, and machines that all have to be new, and testing apparatus that is new. Just some software. So it is cheaper to reinvent, usually. So the amount of advantage you need before reinvention is worthwhile is often less.
2. There is (Sometimes) less risk of your reinvention goes badly. A game crashing is less bad that a car crashing, or a bridge collapsing. Sometimes though, it is just as bad (space ship crashing, due to bad software)
1. Reinventing a software wheel requires only time, not hardware, not a factory to build it, and molds, and machines that all have to be new, and testing apparatus that is new. Just some software. So it is cheaper to reinvent, usually. So the amount of advantage you need before reinvention is worthwhile is often less.
2. There is (Sometimes) less risk of your reinvention goes badly. A game crashing is less bad that a car crashing, or a bridge collapsing. Sometimes though, it is just as bad (space ship crashing, due to bad software)
As I keep saying when the "don't reinvent the wheel" meme is trotted out again in relation to software: We're not even done reinventing the physical wheel. A Mars or Lunar rover needs a different kind of wheel than a car does, and even a car has different wheels depending on whether or not it spends most of its time off or on the road. A jet plane and a tractor also have different kinds of wheels.
It's the most tired of analogies because even the underlying assumption is wrong.
It's the most tired of analogies because even the underlying assumption is wrong.
Edited by Jeroen van Rijn
on
Kelimion
As I keep saying when the "don't reinvent the wheel" meme is trotted out again in relation to software: We're not even done reinventing the physical wheel. A Mars or Lunar rover needs a different kind of wheel than a car does, and even a car has different wheels depending on whether or not it spends most of its time off or on the road. A jet plane and a tractor also have different kinds of wheels.
It's the most tired of analogies because even the underlying assumption is wrong.
But you do *often* share various car parts across decades of new models, because the marginal gains of a new design are not worth the expense and risk, and new designs are often variations on the old (sports cars have used double wishbones for a long time, the thing under a 1990 Miata is not very different than a 2016 Ferrari)
Whereas in software we do entirely new designs monthly!
Which, maybe is a bit too often. Maybe we should wait two months.
MandleBro
But you do *often* share various car parts across decades of new models, because the marginal gains of a new design are not worth the expense and risk, and new designs are often variations on the old (sports cars have used double wishbones for a long time, the thing under a 1990 Miata is not very different than a 2016 Ferrari)
Whereas in software we do entirely new designs monthly!
Which, maybe is a bit too often. Maybe we should wait two months.
Ah, but now we're talking suspension ;-)
I do agree that sometimes software is needlessly thrown out wholesale. There's a balance to be struck between completely rewriting something and reusing code. Unless the code was written with systems in mind which had very different constraints, possibly making a from scratch rewrite faster performing and quicker to write, there is probably a happy medium to be found. One where you examine and replace individual bits of code, then see if that has any implications on other bits of code that it touches or was touched by.
The end result may still be a complete re-envisioning of your "wheel", but in an evolved way. Not the "let's throw out old code", failing to learn from it, and then building a replacement that's not meaningfully better in any way*.
If you're going to "reinvent the wheel", at least make sure you study the thing you try to replace and see what it did well. Formulate exactly how you're going to improve on it. Chances are people - in their haste to replace wheel A - forgot what wheel A did really, really well, so they make a wheel B that doesn't have some of wheel A's quirky bits. Fine, except it also doesn't have the things that made wheel A passable enough to grow a user base to become annoyed by its limitations. It helps to ask the question what problem wheel A initially set out to solve, imperfect in its execution though it was.
Do those assumptions still hold? Have advances been made that render those assumptions obsolete and would you end up perpetuating this quaint old assumption if you write a wheel B that's still pretty much wheel A? Are there new constraints to keep in mind that have surfaced since wheel A's initial design took shape, or that wheel A neglected to address? If so it might be useful to keep that in mind, lest you end up with a great wheel B that just happens to be vulnerable to security issues which were old 2 decades ago.
Notice we're talking about two different models here:
A) Write an 'improved' competitor from scratch, whether or not from the same vendor.
B) Incrementally upgrade existing code for new realities
In both cases it's good to look at what came before. Often the new requirement is just bolted on. Even in case B I'd argue it's a good idea to really go through the code base once in a while - particularly if it's 5+ years old and still looks serviceable. There's bound to be gotchas that made sense at the time but will bite you in this day and age.
So I'm not saying throw everything out all the time. I'm also saying to never throw something out. There are instances where both would be the right thing to do, but there's often a good middle ground to be found that's regrettably overlooked by many.
* See also: The web's infatuation with the new shiny, same as the old shiny except the O'Reilly book has a different animal on it. And maybe it's frustrating to use in a slightly different way.
Edited by Jeroen van Rijn
on
MandleBroKelimion
As I keep saying when the "don't reinvent the wheel" meme is trotted out again in relation to software: We're not even done reinventing the physical wheel. A Mars or Lunar rover needs a different kind of wheel than a car does, and even a car has different wheels depending on whether or not it spends most of its time off or on the road. A jet plane and a tractor also have different kinds of wheels.
It's the most tired of analogies because even the underlying assumption is wrong.
But you do *often* share various car parts across decades of new models, because the marginal gains of a new design are not worth the expense and risk, and new designs are often variations on the old (sports cars have used double wishbones for a long time, the thing under a 1990 Miata is not very different than a 2016 Ferrari)
Whereas in software we do entirely new designs monthly!
Which, maybe is a bit too often. Maybe we should wait two months.
You make a good point (as does Jeroen). It's a difficult problem to figure out what you should and should not reuse. Black boxes make this more difficult of course, but even when it's open, how do you decide whether it's good enough or not? I tend to think the approach Jeroen offered is a good start.
Also, using a similar car analogy, we have gotten to a point where the cars we are making are terrible. When they were invented, they were the best thing we could possibly make (maybe...), but now we need more. Just to drive the point home, if Elon Musk and Tesla Motors could not have possibly made their cars had they simply used a modified version of the Miata. Reinventing the proverbial wheel is exactly what we need in that case.
CaptainKraft
Also, using a similar car analogy, we have gotten to a point where the cars we are making are terrible. When they were invented, they were the best thing we could possibly make (maybe...), but now we need more. Just to drive the point home, if Elon Musk and Tesla Motors could not have possibly made their cars had they simply used a modified version of the Miata. Reinventing the proverbial wheel is exactly what we need in that case.
“If I had asked people what they wanted, they would have said faster horses.”
― Henry Ford