5 ms·

"Engineering" is only possible in the physical world because the laws of physics don't change every thirty years or so. In software, we aren't so lucky. Bridge-

"Engineering" is only possible in the physical world because the laws of physics don't change every thirty years or so. In software, we aren't so lucky. Bridge-building best practices from the 1950s would build a fine bridge today. Software development practices from the 80s would get you... basically nowhere.

taeric 12y ago
I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design. Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are. Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is that I think we'd do better by not always looking across the horizon to a silver bullet language/framework/whatever and keep focused on what the job at hand requires. The amount of failures I have witnessed due to a desire to over generalize is staggering.
- 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.
  - 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.
- minthd 12y ago
  Like others said, it's hard to compare because the hardware also greatly improved. But if you look at embedded programming - in 80's we had c/ada, today we might have rust - fitting similar environments. That's surely an improvement.
  - taeric 12y ago
    Why? And there is a lot more to tooling in embedded systems creation than the language that the software is specified in. If anything, I think the dream from back then would be that embedded systems of today would be more FPGA based. Screw this using fixed design systems. :)
    - minthd 12y ago
      Why rust is better? for example, it has generics, which more abstract and offering greater reuse while still being efficient. As for the dream of dropping fixed systems, you can already buy a cheap fast mcu from xmos with 4 cores which you can use 3 to create extra peripherals.Or another cheap CPU with a small fpga. But of course if you're fighting for pennies of cost or power, there might be better fixed alternatives than those 2. BTW the reason we don't have FPGA on chips is probably mostly commercial - charging by the peripheral offer chip companies ways to more revenues and more differentiation between each other. They really don't want to sell the same commodity chips of mcu+fpga.
      - taeric 12y ago
        Sorry, I shouldn't have thrown in the quip on FPGAs. It really is a complete non-sequitor. I think a very neat topic, but didn't belong here. I don't accept that generics are somehow an automatic win for languages. I do like them somewhat, myself, but I don't think there has been compelling evidence that they can be used to great effect in building embedded systems. Consider, at the low level, the majority of the code written is still in C. Not C++, C. And I can't bring myself to agree that it is lacking because of it. I know he is intentionally inflammatory, but I think Torvald's rant on why he rejected C++ for Git is somewhat poignant. As is all of the attempts at writing the git core in higher level languages. Specifically, how they haven't really succeeded. I will confess to being open to the argument, but outside of revisionist history and wishful thinking, I just don't see proof that things are automatically better with today's practices over those of yesterday's.

taeric 12y ago

I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design. Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are. Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is that I think we'd do better by not always looking across the horizon to a silver bullet language/framework/whatever and keep focused on what the job at hand requires. The amount of failures I have witnessed due to a desire to over generalize is staggering.

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.
- 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.
minthd 12y ago
Like others said, it's hard to compare because the hardware also greatly improved. But if you look at embedded programming - in 80's we had c/ada, today we might have rust - fitting similar environments. That's surely an improvement.
- taeric 12y ago
  Why? And there is a lot more to tooling in embedded systems creation than the language that the software is specified in. If anything, I think the dream from back then would be that embedded systems of today would be more FPGA based. Screw this using fixed design systems. :)
  - minthd 12y ago
    Why rust is better? for example, it has generics, which more abstract and offering greater reuse while still being efficient. As for the dream of dropping fixed systems, you can already buy a cheap fast mcu from xmos with 4 cores which you can use 3 to create extra peripherals.Or another cheap CPU with a small fpga. But of course if you're fighting for pennies of cost or power, there might be better fixed alternatives than those 2. BTW the reason we don't have FPGA on chips is probably mostly commercial - charging by the peripheral offer chip companies ways to more revenues and more differentiation between each other. They really don't want to sell the same commodity chips of mcu+fpga.
    - taeric 12y ago
      Sorry, I shouldn't have thrown in the quip on FPGAs. It really is a complete non-sequitor. I think a very neat topic, but didn't belong here. I don't accept that generics are somehow an automatic win for languages. I do like them somewhat, myself, but I don't think there has been compelling evidence that they can be used to great effect in building embedded systems. Consider, at the low level, the majority of the code written is still in C. Not C++, C. And I can't bring myself to agree that it is lacking because of it. I know he is intentionally inflammatory, but I think Torvald's rant on why he rejected C++ for Git is somewhat poignant. As is all of the attempts at writing the git core in higher level languages. Specifically, how they haven't really succeeded. I will confess to being open to the argument, but outside of revisionist history and wishful thinking, I just don't see proof that things are automatically better with today's practices over those of yesterday's.