6 ms·

"To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong." I feel li

"To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong." I feel like this applies to everything. I mostly work on ecommerce and analytics systems, and I feel like I'm having to make this same argument all the time.

sillysaurus3 11y ago
There is an interesting, opposite mindset: The program will not function unless nothing is wrong. It was surprising how reliable the programs turn out to be. But the shocking part is how small they are. I'm starting to be convinced that the only way to write reliable code is to spend most of your time trying to remove code. And not at the expense of clarity; tricks like that don't matter.
- adrianN 11y ago
  Very small programs don't solve complex tasks. If you plan to glue many small, correct programs together you'll likely get unintended behavior from the collection. You're just shifting the complexity around.
  - taneq 11y ago
    And this is why subdividing code too finely is as bad as not finely enough. In an informal way I think of it as a good design being 'square', as in the design is distributed evenly across all scales. So a small program might have ten functions of about ten lines each. A bigger one might have ten files, each containing about ten functions of about ten lines. It's different in every project but solid, elegant, well structured systems always seem to feel 'square'.
  - a3n 11y ago
    The collection is a program.
  - ska 11y ago
    Very small programs don't solve complex tasks. That's not quite right (some simple algorithms solve complex tasks). I think it is more true that very small programs can't model or facilitate complex interactions. Your point about shifting complexity around is a good one.
    - adrianN 11y ago
      Well yeah, the universal turing machine has a pretty small program and solves all kinds of problems. But that's not really what I imagine when I say "a simple program".
      - ska 11y ago
        I wasn't being that abstract, I'm thinking of real world systems. Some numerical solvers, graph algorithms, control systems, etc. have this property. They are definitely what I would call a simple program, even if the math behind them is not. YMMV.
  - soperj 11y ago
    As a contradiction: e=mc^2
    - ludamad 11y ago
      Which is just a series of symbols. Using it or explaining it is far more complex.
  - stcredzero 11y ago
    ...you'll likely get unintended behavior from the collection. You're just shifting the complexity around. This is one of the valid criticisms of OO. "Gluing" small (mostly) correct objects together can produce unforseen results in the aggregate, or can be hard to understand in aggregate.
  - marcosdumay 11y ago
    That's why you write a very small core with the essential tasks, that include updating the non-core. And then add the complexity in another layer, where failure is handled by the core.
    - fapjacks 11y ago
      Something interesting about your point is that people will eventually land on this fundamental design as long as they are 1) curious enough about programming to learn new things and 2) continuously improving their abilities. I think what surprised me the most over my lifetime is the number of people writing code that do neither of those things.
  - deleted 11y ago
    [deleted]
- btilly 11y ago
  What makes you think that these approaches are opposite? When you introduce containers in some form, it becomes reasonable to add monitoring for errors. Make sure that there is redundancy. Now if error conditions are found, it is OK to lose the container. Another will be along shortly to pick up where you left off. This approach is often used in distributed software. For example a good MapReduce framework will take care of detecting failing machines and replacing them, hopefully with perfect results. Erlang uses the same approach, and some of the most reliable software in the world has been written with it. This idea does not just apply to a digital world. For example each rocket in a Falcon 9 is able to detect that it is not working right and shut down. The overall system is designed to work if any 7 rockets still fire.
solipsism 11y ago
This applies to some things, not to everything. In some systems the right thing to do when an error is detected is to halt everything. In these systems, the cost of continuing to operate when errors are present is much higher than the cost of halting operations. Take high-frequency trading, for example.
- macintux 11y ago
  Erlang (software) and Tandem (hardware) take the sensible approach of halting everything that the error has touched, while allowing the overall system to proceed.
spacehome 11y ago
There's only finitely many designs that will fit in a Hubble volume. It's hard to believe that choosing among this finite number of choices takes infinite effort.

sillysaurus3 11y ago

There is an interesting, opposite mindset: The program will not function unless nothing is wrong. It was surprising how reliable the programs turn out to be. But the shocking part is how small they are. I'm starting to be convinced that the only way to write reliable code is to spend most of your time trying to remove code. And not at the expense of clarity; tricks like that don't matter.

adrianN 11y ago
Very small programs don't solve complex tasks. If you plan to glue many small, correct programs together you'll likely get unintended behavior from the collection. You're just shifting the complexity around.
- taneq 11y ago
  And this is why subdividing code too finely is as bad as not finely enough. In an informal way I think of it as a good design being 'square', as in the design is distributed evenly across all scales. So a small program might have ten functions of about ten lines each. A bigger one might have ten files, each containing about ten functions of about ten lines. It's different in every project but solid, elegant, well structured systems always seem to feel 'square'.
- a3n 11y ago
  The collection is a program.
- ska 11y ago
  Very small programs don't solve complex tasks. That's not quite right (some simple algorithms solve complex tasks). I think it is more true that very small programs can't model or facilitate complex interactions. Your point about shifting complexity around is a good one.
  - adrianN 11y ago
    Well yeah, the universal turing machine has a pretty small program and solves all kinds of problems. But that's not really what I imagine when I say "a simple program".
    - ska 11y ago
      I wasn't being that abstract, I'm thinking of real world systems. Some numerical solvers, graph algorithms, control systems, etc. have this property. They are definitely what I would call a simple program, even if the math behind them is not. YMMV.
- soperj 11y ago
  As a contradiction: e=mc^2
  - ludamad 11y ago
    Which is just a series of symbols. Using it or explaining it is far more complex.
- stcredzero 11y ago
  ...you'll likely get unintended behavior from the collection. You're just shifting the complexity around. This is one of the valid criticisms of OO. "Gluing" small (mostly) correct objects together can produce unforseen results in the aggregate, or can be hard to understand in aggregate.
- marcosdumay 11y ago
  That's why you write a very small core with the essential tasks, that include updating the non-core. And then add the complexity in another layer, where failure is handled by the core.
  - fapjacks 11y ago
    Something interesting about your point is that people will eventually land on this fundamental design as long as they are 1) curious enough about programming to learn new things and 2) continuously improving their abilities. I think what surprised me the most over my lifetime is the number of people writing code that do neither of those things.
- deleted 11y ago
  [deleted]
btilly 11y ago
What makes you think that these approaches are opposite? When you introduce containers in some form, it becomes reasonable to add monitoring for errors. Make sure that there is redundancy. Now if error conditions are found, it is OK to lose the container. Another will be along shortly to pick up where you left off. This approach is often used in distributed software. For example a good MapReduce framework will take care of detecting failing machines and replacing them, hopefully with perfect results. Erlang uses the same approach, and some of the most reliable software in the world has been written with it. This idea does not just apply to a digital world. For example each rocket in a Falcon 9 is able to detect that it is not working right and shut down. The overall system is designed to work if any 7 rockets still fire.

solipsism 11y ago

This applies to some things, not to everything. In some systems the right thing to do when an error is detected is to halt everything. In these systems, the cost of continuing to operate when errors are present is much higher than the cost of halting operations. Take high-frequency trading, for example.

macintux 11y ago
Erlang (software) and Tandem (hardware) take the sensible approach of halting everything that the error has touched, while allowing the overall system to proceed.

spacehome 11y ago

There's only finitely many designs that will fit in a Hubble volume. It's hard to believe that choosing among this finite number of choices takes infinite effort.