5 ms·

Are you proposing to break backward compatibility?

akkartik 7y ago
Well, it's a new computer so there's no notion of compatibility. But yes, I'm proposing to rely a lot less on compatibility going forward. A big reason for building a new stack rather than building atop existing interfaces is precisely to avoid backwards compatibility. A big reason to keep the codebase comprehensible is to shift the social contract, so that people can fend for themselves in the face of incompatible changes. By the same token, a big reason to avoid compatibility is so that we don't have to indefinitely make the task of future readers more difficult. I think the age of computers is just starting. 99.999% of computer use is yet to happen. It seems shortsighted to hamper the future for the sake of the miniscule past. You wouldn't want to force the adult to hew to the short-sighted decisions of the toddler.
- Mikhail_Edoshin 7y ago
  I believe that this goal can be better achieved by exposing data rather than procedures. Data are much more stable and although the design depends on what you originally plan to do with them, this dependency is not rigid and there's usually many different usage scenarios. Also, data are much more comprehensible and malleable than procedures so quite a few compatibility issues can be solved automatically. E.g. the primary goal of DTD was to validate XML against a simple grammar, but the same DTD can be used for auto-completion when editing the XML. Same data, different usage. Also, if we want to shift to a more powerful validation engine, e.g. XSD schema, we can parse DTDs and mechanically convert them into equivalent XSDs.
- galaxyLogic 7y ago
  > Well, it's a new computer so there's no notion of compatibility. > It seems shortsighted to hamper the future for the sake of the miniscule past. These too statements seem somewhat contradictory to me. If we don't provide means for making systems where it is easy to validate their backwards compatibility then it becomes difficult to EVOLVE the system incrementally. That would seem to me to "hamper the future". This is how biological evolution became a great success, not by "starting from scratch" every time but by making sure that new individuals were always more or less "backwards compatible". Yes sometimes it makes sense to rewrite something from scratch but forsaking the idea of reusability, which is very closely related to the idea of "compatibility", just seems to me as hampering the future. Not preparing for the future by not making sure you can easily ensure and validate backwards compatibility, is "hampering the future", in my view. :-)
  - akkartik 7y ago
    We'll have to agree to disagree. You're right that there's a tension between present and future. But that's always true. My statements aren't contradictory in isolation, they just reflect this underlying tension. You have to navigate it no matter what point you choose on the spectrum. > If we don't provide means for making systems where it is easy to validate their backwards compatibility... This begs the question of why you need to validate backwards compatibility. What benefits do you get? If we have a list of benefits we can start working through them and figure out if something else may substitute for compatibility. > This is how biological evolution became a great success, not by "starting from scratch" every time but by making sure that new individuals were always more or less "backwards compatible". This analogy isn't helpful, because evolution is constantly testing lots of different approaches all at once, extremophiles and bacteria and cheetahs. While many lessons are shared between simple and complex life forms, there is also a lot of branching where different organisms come up with disjoint solutions to the same problems. Human supply chains are not nearly so redundant. Lessons from evolution don't always apply to something that's 'intelligently' designed. > ..the idea of reusability, which is very closely related to the idea of "compatibility".. It's worth separating these two ideas. You can have reuse without compatibility (reworking an existing codebase to fit an entirely new interface) and compatibility without reuse (cleanroom implementations of protocols). Reuse is a difficult word to wrap my head around because it encompasses so much: a) Calling a function at a new call-site. b) Selecting a library for a use case it was designed for. c) Mangling a library to support a use case it was not designed for. d) Deploying copies of an AMI. e) ... and much more I'm very supportive of post-deployment reuse (e.g. d above) which is usually entirely automated. But I'm suspicious of large-scale reuse during the development process. We've been trying to make it work for decades now, and it just hasn't panned out. At what point do we reframe a goal as a delusion? I think we're way past it in this case.
    - galaxyLogic 7y ago
      > But I'm suspicious of large-scale reuse during the development process. We've been trying to make it work for decades now, and it just hasn't panned out. At what point do we reframe a goal as a delusion? I think we're way past it in this case. Software Reuse is not a "goal" but common well-understood practice. Call a function from more than one location, instantiate a class more than once and call its methods from several locations. We do that because it is helpful for development and maintenance, not because that would be our "goal". I would think most software written say in Java uses that approach, in practice. Create multiple instances of a given class. So what would be the evidence that this approach has not "panned out" and is "delusional goal"? Maybe your "avoid reuse" is a better approach. But I don't think there's a lot of evidence that would prove it to be so, not at least yet.

Well, it's a new computer so there's no notion of compatibility. But yes, I'm proposing to rely a lot less on compatibility going forward. A big reason for building a new stack rather than building atop existing interfaces is precisely to avoid backwards compatibility. A big reason to keep the codebase comprehensible is to shift the social contract, so that people can fend for themselves in the face of incompatible changes. By the same token, a big reason to avoid compatibility is so that we don't have to indefinitely make the task of future readers more difficult. I think the age of computers is just starting. 99.999% of computer use is yet to happen. It seems shortsighted to hamper the future for the sake of the miniscule past. You wouldn't want to force the adult to hew to the short-sighted decisions of the toddler.

Mikhail_Edoshin 7y ago
I believe that this goal can be better achieved by exposing data rather than procedures. Data are much more stable and although the design depends on what you originally plan to do with them, this dependency is not rigid and there's usually many different usage scenarios. Also, data are much more comprehensible and malleable than procedures so quite a few compatibility issues can be solved automatically. E.g. the primary goal of DTD was to validate XML against a simple grammar, but the same DTD can be used for auto-completion when editing the XML. Same data, different usage. Also, if we want to shift to a more powerful validation engine, e.g. XSD schema, we can parse DTDs and mechanically convert them into equivalent XSDs.
galaxyLogic 7y ago
> Well, it's a new computer so there's no notion of compatibility. > It seems shortsighted to hamper the future for the sake of the miniscule past. These too statements seem somewhat contradictory to me. If we don't provide means for making systems where it is easy to validate their backwards compatibility then it becomes difficult to EVOLVE the system incrementally. That would seem to me to "hamper the future". This is how biological evolution became a great success, not by "starting from scratch" every time but by making sure that new individuals were always more or less "backwards compatible". Yes sometimes it makes sense to rewrite something from scratch but forsaking the idea of reusability, which is very closely related to the idea of "compatibility", just seems to me as hampering the future. Not preparing for the future by not making sure you can easily ensure and validate backwards compatibility, is "hampering the future", in my view. :-)
- akkartik 7y ago
  We'll have to agree to disagree. You're right that there's a tension between present and future. But that's always true. My statements aren't contradictory in isolation, they just reflect this underlying tension. You have to navigate it no matter what point you choose on the spectrum. > If we don't provide means for making systems where it is easy to validate their backwards compatibility... This begs the question of why you need to validate backwards compatibility. What benefits do you get? If we have a list of benefits we can start working through them and figure out if something else may substitute for compatibility. > This is how biological evolution became a great success, not by "starting from scratch" every time but by making sure that new individuals were always more or less "backwards compatible". This analogy isn't helpful, because evolution is constantly testing lots of different approaches all at once, extremophiles and bacteria and cheetahs. While many lessons are shared between simple and complex life forms, there is also a lot of branching where different organisms come up with disjoint solutions to the same problems. Human supply chains are not nearly so redundant. Lessons from evolution don't always apply to something that's 'intelligently' designed. > ..the idea of reusability, which is very closely related to the idea of "compatibility".. It's worth separating these two ideas. You can have reuse without compatibility (reworking an existing codebase to fit an entirely new interface) and compatibility without reuse (cleanroom implementations of protocols). Reuse is a difficult word to wrap my head around because it encompasses so much: a) Calling a function at a new call-site. b) Selecting a library for a use case it was designed for. c) Mangling a library to support a use case it was not designed for. d) Deploying copies of an AMI. e) ... and much more I'm very supportive of post-deployment reuse (e.g. d above) which is usually entirely automated. But I'm suspicious of large-scale reuse during the development process. We've been trying to make it work for decades now, and it just hasn't panned out. At what point do we reframe a goal as a delusion? I think we're way past it in this case.
  - galaxyLogic 7y ago
    > But I'm suspicious of large-scale reuse during the development process. We've been trying to make it work for decades now, and it just hasn't panned out. At what point do we reframe a goal as a delusion? I think we're way past it in this case. Software Reuse is not a "goal" but common well-understood practice. Call a function from more than one location, instantiate a class more than once and call its methods from several locations. We do that because it is helpful for development and maintenance, not because that would be our "goal". I would think most software written say in Java uses that approach, in practice. Create multiple instances of a given class. So what would be the evidence that this approach has not "panned out" and is "delusional goal"? Maybe your "avoid reuse" is a better approach. But I don't think there's a lot of evidence that would prove it to be so, not at least yet.