4 ms·

But the assertion is that bridges could be built today using techniques from the 1950's, and they would still be good bridges, because the principles and physic

by sgrove 12y ago

But the assertion is that bridges could be built today using techniques from the 1950's, and they would still be good bridges, because the principles and physical laws they were built on haven't changed. Software design had a lot of cool things happening in the 1980's (possibly more in the 1970's, though), but the mindset has shifted since then. How many people are implementing their own VM's? How many are running on non x86 intel/amd chipsets? Things that needed to be heavily optimized in the early 80's might actually run faster now with JIT & whole-program optimizations. And so on. It's hard to build an engineering discipline out of such a shifting substrate.

taeric 12y ago
And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion. I don't know what to say regarding your examples. Don't put too much credit in JIT and whole-program optimizations. One could just as easily point to the fact that what used to be too slow of a program is now fast enough with the advance of computing speed. And memory. Do not overlook the importance of memory. More, I doubt most programs of yesteryear failed due to lack of optimization. Seems likely to me, that the main cause of software failure has not changed that heavily in the years.
- coldtea 12y ago
  >And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion. I find that they (from the '50s and even older) hold up just fine. If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle.
  - taeric 12y ago
    This leads to a few questions, though. First, if bridges were built just fine in the 50s, why do they build them differently nowdays? Second, why is the maintenance cost of bridges decidedly non-trivial? Third, is there any software that is that old that still works fine? For the first question, I would only be offering speculation. Google and friends can give pretty good references. For the second, a quick google gives "The annual direct cost of corrosion for highway bridges is estimated to be $6.43 billion to $10.15 billion ..."[1] Third, I offer TeX as a good example of old software that has managed to survive for quite a long time. I am always pleasantly surprised when I go to typeset something from 20+ years ago and things "just work." I think the theme here is that maintenance costs for bridges more often than not entails just keeping them working. Seems that far too often in software maintenance costs try and include complete rewrites into new technologies. [1] http://www.dnvusa.com/Binaries/highway_tcm153-378806.pdf http://www.dnvusa.com/Binaries/highway_tcm153-378806.pdf
    - hueving 12y ago
      Tex is not 50 years old. Also, it's borderline unusable to anyone who hasn't mastered what "underfilled hbox" means and the like. Internally it's so unsustainable that people are trying to start from scratch with full rewrites. However, because there actually isn't a standard for latex beyond "how tex" renders it, it's a horrific undertaking. TeX is far from "just working". Onto bridges, just because they build them differently now does not negate the fact that 50 year old bridges are still reliable and safe to drive over because they were engineered well. Their shortcomings and failure modes are well known so maintenance can be performed to prevent collapses. 50 year old bridges may be expensive to maintain at this point, but the fact that it's still possible shows that they were engineered well. They may build them differently today, but that's more likely related to cost constraints changing (e.g. can't afford an army of riviters now) rather than the engineering being unsound.
      - taeric 12y ago
        This is pure goal post shifting. Without massive and expensive maintenance, many of these bridges would be unusable, having crumbled to the point of destruction. Pretty much period. TeX is not 50, I had not meant to imply it was. Just that it is a relatively old piece of software that has had virtually no maintenance compared to many other pieces of software. Could it have used an overhaul? It is certainly debatable. However, Knuth has had massive success in keeping it working without worrying about use cases that just were not the aim of software. To continue the comparison with bridges, it is not uncommon for them to have restrictions saying that large trucks can not cross them. This is not a recommendation, it is a requirement. In the software world, many would have modified TeX to do such things as typeset documents miles wide. Because, generality! Or some such. And the concerns you have about people not knowing what an "underfilled hbox" means is simply a lack of training. I would be surprised if anyone I work with below the age of 25 has even heard of TeX, much less read the documentation for it. Heck, I could probably raise that to 40. So, my assertion is that the fact that TeX is still very much usable shows that it was "well engineered." Would it require somewhat expensive training? Sure, but how is that any different than the maintenance of bridges?
  - fsloth 12y ago
    "If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle." Given a Fortran compiler I see no reason why lot of the numerical stuff in netlib would not work just as well in 60 years time: http://www.netlib.org http://www.netlib.org
    - coldtea 12y ago
      Libraries sure. I'm talking about production software.
      - fsloth 12y ago
        Yes, that's an entirely different thing. But I would rather compare a production software system to something bit more dynamic, like a nuclear plant or an airplane than a bridge.
        taeric 12y ago
        This is just survivor bias at work, though. How has road building been in the past 50 years? If your road has seen heavy use, it has massively changed. So, then should we assume that software is like road building? No, rather I would assert that there are some pieces of the road that are more isolated from dangerous use and changes than others. In software, we have some of that, too, but not to nearly the extent. We are often holding up pitchforks to rewrite everything.
Nursie 12y ago
They might be good bridges, but they wouldn't necessarily be up to modern safety spec or tolerances, and may not take advantage of new materials. It might actually be a good allegory after all...
lostcolony 12y ago
If software engineering is shifting, it's shifting due to the youth of the discipline. Remember, we've been building bridges for thousands of years. We've had a lot of time to figure out how best to do it. The amount of improvement we've had in 50 years in terms of technique is probably pretty small; improvement in materials is the more likely reason for any variations in technique.
garfij 12y ago
My impression has been that the people in the LISP community would be happy to tell you about how their model has been fairly consistent over the past several decades and that a lot of the 'new advancements' we're seeing all the time have been available in LISP for that whole time. And, funnily enough, one of the most highly recommended projects in LISP is making your own! I don't get to deal with LISP anywhere enough to substantiate these claims from actual experience, but that is the impression I have gotten from hanging around places like this.

by sgrove 12y ago

taeric 12y ago

And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion. I don't know what to say regarding your examples. Don't put too much credit in JIT and whole-program optimizations. One could just as easily point to the fact that what used to be too slow of a program is now fast enough with the advance of computing speed. And memory. Do not overlook the importance of memory. More, I doubt most programs of yesteryear failed due to lack of optimization. Seems likely to me, that the main cause of software failure has not changed that heavily in the years.

coldtea 12y ago
>And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion. I find that they (from the '50s and even older) hold up just fine. If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle.
- taeric 12y ago
  This leads to a few questions, though. First, if bridges were built just fine in the 50s, why do they build them differently nowdays? Second, why is the maintenance cost of bridges decidedly non-trivial? Third, is there any software that is that old that still works fine? For the first question, I would only be offering speculation. Google and friends can give pretty good references. For the second, a quick google gives "The annual direct cost of corrosion for highway bridges is estimated to be $6.43 billion to $10.15 billion ..."[1] Third, I offer TeX as a good example of old software that has managed to survive for quite a long time. I am always pleasantly surprised when I go to typeset something from 20+ years ago and things "just work." I think the theme here is that maintenance costs for bridges more often than not entails just keeping them working. Seems that far too often in software maintenance costs try and include complete rewrites into new technologies. [1] http://www.dnvusa.com/Binaries/highway_tcm153-378806.pdf http://www.dnvusa.com/Binaries/highway_tcm153-378806.pdf
  - hueving 12y ago
    Tex is not 50 years old. Also, it's borderline unusable to anyone who hasn't mastered what "underfilled hbox" means and the like. Internally it's so unsustainable that people are trying to start from scratch with full rewrites. However, because there actually isn't a standard for latex beyond "how tex" renders it, it's a horrific undertaking. TeX is far from "just working". Onto bridges, just because they build them differently now does not negate the fact that 50 year old bridges are still reliable and safe to drive over because they were engineered well. Their shortcomings and failure modes are well known so maintenance can be performed to prevent collapses. 50 year old bridges may be expensive to maintain at this point, but the fact that it's still possible shows that they were engineered well. They may build them differently today, but that's more likely related to cost constraints changing (e.g. can't afford an army of riviters now) rather than the engineering being unsound.
    - taeric 12y ago
      This is pure goal post shifting. Without massive and expensive maintenance, many of these bridges would be unusable, having crumbled to the point of destruction. Pretty much period. TeX is not 50, I had not meant to imply it was. Just that it is a relatively old piece of software that has had virtually no maintenance compared to many other pieces of software. Could it have used an overhaul? It is certainly debatable. However, Knuth has had massive success in keeping it working without worrying about use cases that just were not the aim of software. To continue the comparison with bridges, it is not uncommon for them to have restrictions saying that large trucks can not cross them. This is not a recommendation, it is a requirement. In the software world, many would have modified TeX to do such things as typeset documents miles wide. Because, generality! Or some such. And the concerns you have about people not knowing what an "underfilled hbox" means is simply a lack of training. I would be surprised if anyone I work with below the age of 25 has even heard of TeX, much less read the documentation for it. Heck, I could probably raise that to 40. So, my assertion is that the fact that TeX is still very much usable shows that it was "well engineered." Would it require somewhat expensive training? Sure, but how is that any different than the maintenance of bridges?
- fsloth 12y ago
  "If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle." Given a Fortran compiler I see no reason why lot of the numerical stuff in netlib would not work just as well in 60 years time: http://www.netlib.org http://www.netlib.org
  - coldtea 12y ago
    Libraries sure. I'm talking about production software.
    - fsloth 12y ago
      Yes, that's an entirely different thing. But I would rather compare a production software system to something bit more dynamic, like a nuclear plant or an airplane than a bridge.
      - taeric 12y ago
        This is just survivor bias at work, though. How has road building been in the past 50 years? If your road has seen heavy use, it has massively changed. So, then should we assume that software is like road building? No, rather I would assert that there are some pieces of the road that are more isolated from dangerous use and changes than others. In software, we have some of that, too, but not to nearly the extent. We are often holding up pitchforks to rewrite everything.

Nursie 12y ago

They might be good bridges, but they wouldn't necessarily be up to modern safety spec or tolerances, and may not take advantage of new materials. It might actually be a good allegory after all...

lostcolony 12y ago

If software engineering is shifting, it's shifting due to the youth of the discipline. Remember, we've been building bridges for thousands of years. We've had a lot of time to figure out how best to do it. The amount of improvement we've had in 50 years in terms of technique is probably pretty small; improvement in materials is the more likely reason for any variations in technique.

garfij 12y ago

My impression has been that the people in the LISP community would be happy to tell you about how their model has been fairly consistent over the past several decades and that a lot of the 'new advancements' we're seeing all the time have been available in LISP for that whole time. And, funnily enough, one of the most highly recommended projects in LISP is making your own! I don't get to deal with LISP anywhere enough to substantiate these claims from actual experience, but that is the impression I have gotten from hanging around places like this.