4 ms·

Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under

Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under expected limitations and we don't have that. While idea to construct everything from components overall seem to work better than to build monoliths quite often (Space X vs NASA, Linux vs many other OSes) but not always (e.g. SQLite).

bezout 6y ago
Well, your argument would only apply to software which operating contexts are not known to the developers ahead of its release. Is it the case for every piece of software? I’d argue not. Most of the times, you know what to expect . And you can always put up some guards to ensure it fails gracefully.
- daliusd 6y ago
  So expected limitations in your cases is "known to the developers ahead of its release", but what happens with the software after release, e.g. after 10 iterations or 2 years or 10 years? What happens if your product from 10s of users grows to 1000s of users, millions of users? What happens when new functionality must be added and it collides with the existing one in multiple points? You can and you must do your best, but you can't do everything - you must choose what is your sacrifice.
lmm 6y ago
> Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under expected limitations and we don't have that. Verified* instances in safe Idris. Of course GIGO is still valid and failures in lower-level components (such as a processor just not behaving as specified) can cause failures in higher-level components, but it's simply impossible for there to be a failure in that component itself - any observed failure will necessarily be the result of a lower-level failure.
- azornathogron 6y ago
  I think you are ignoring both failures to correctly specify what was intended (the design was right conceptually, but you specified it incorrectly when formalising it so now you have a perfectly verified incorrect implementation), and failures in the design (the thing works as you designed it, but it turns out your design isn't perfect). More likely, you're not unaware of these possibilities, you're just using a meaning of "failure" that excludes them. But regardless of whether you call these failures or call them something else, they prevent you from guaranteeing perfection.
  - lmm 6y ago
    On the contrary, there is guaranteed perfection: I can guarantee that they perfectly implement the given formal specification. I think we're in agreement that one can't produce a guaranteed-perfect system (since the system will always have a part that must interact with humans), but I don't think that actually supports the approach of treating every component as fallible.
    - marcus_holmes 6y ago
      And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly?
      - lmm 6y ago
        > And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. Not my experience; the system may need new components or need to rearrange the existing ones, but the components themselves don't become imperfect. Consider something like a prime factorization algorithm; maybe your system will change to the point where you don't need it, or need to extend it, but it continues to be perfect. > And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly? Tech companies go bankrupt all the time, so I think it's a stretch to say that commercial coding is working perfectly. Automating a sloppy human process in an equally sloppy way can certainly make you money, and maybe there's more money in doing that than in making perfect things, but we should at least acknowledge that there's an unexplored alternative here.

bezout 6y ago

Well, your argument would only apply to software which operating contexts are not known to the developers ahead of its release. Is it the case for every piece of software? I’d argue not. Most of the times, you know what to expect . And you can always put up some guards to ensure it fails gracefully.

daliusd 6y ago
So expected limitations in your cases is "known to the developers ahead of its release", but what happens with the software after release, e.g. after 10 iterations or 2 years or 10 years? What happens if your product from 10s of users grows to 1000s of users, millions of users? What happens when new functionality must be added and it collides with the existing one in multiple points? You can and you must do your best, but you can't do everything - you must choose what is your sacrifice.

lmm 6y ago

> Could you give example of component that is 100% correct? I feel that even components can be 100% correct only within context, e.g. within ideal automaton under expected limitations and we don't have that. Verified* instances in safe Idris. Of course GIGO is still valid and failures in lower-level components (such as a processor just not behaving as specified) can cause failures in higher-level components, but it's simply impossible for there to be a failure in that component itself - any observed failure will necessarily be the result of a lower-level failure.

azornathogron 6y ago
I think you are ignoring both failures to correctly specify what was intended (the design was right conceptually, but you specified it incorrectly when formalising it so now you have a perfectly verified incorrect implementation), and failures in the design (the thing works as you designed it, but it turns out your design isn't perfect). More likely, you're not unaware of these possibilities, you're just using a meaning of "failure" that excludes them. But regardless of whether you call these failures or call them something else, they prevent you from guaranteeing perfection.
- lmm 6y ago
  On the contrary, there is guaranteed perfection: I can guarantee that they perfectly implement the given formal specification. I think we're in agreement that one can't produce a guaranteed-perfect system (since the system will always have a part that must interact with humans), but I don't think that actually supports the approach of treating every component as fallible.
  - marcus_holmes 6y ago
    And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly?
    - lmm 6y ago
      > And don't ignore the fact that needs change over time - a perfectly designed and functioning component will become imperfectly specified over time as the need for it changes. Not my experience; the system may need new components or need to rearrange the existing ones, but the components themselves don't become imperfect. Consider something like a prime factorization algorithm; maybe your system will change to the point where you don't need it, or need to extend it, but it continues to be perfect. > And there is the cost/benefit calculation - the effort required to get something perfect is often greater than the benefit of having a perfect component. The purpose of commercial code is to make money, and if technically perfect code makes less money than technically imperfect code, then is it fulfilling its purpose perfectly? Tech companies go bankrupt all the time, so I think it's a stretch to say that commercial coding is working perfectly. Automating a sloppy human process in an equally sloppy way can certainly make you money, and maybe there's more money in doing that than in making perfect things, but we should at least acknowledge that there's an unexplored alternative here.