3 ms·

The bigger problem often is... We don't often understand what we are building most of the time. Software is a communication tool most of the time. You are com

The bigger problem often is... We don't often understand what we are building most of the time. Software is a communication tool most of the time. You are communicating between machine and user or user to machine to network of data and so on. Most of the code is really a translation from input to some kind of command or process and outputting the result. The more layers you add to that, the further you are from the truth and the more confusing the world truly is. For all the patterns, abstractions, and so on that we lean on, we miss out on the most important one... input -> processing -> output

TeMPOraL 10y ago
> We don't often understand what we are building most of the time. Indeed. Programming is a process of constant discovery and reframing of the problems ahead. > Most of the code is really a translation from input to some kind of command or process and outputting the result. I disagree. This may be true in a general form, but a general form like this is of little utility. There are many types of programs for which the focus is state manipulation, and what you care about is that state - whether in its final form (e.g. 3D modelling software) or in its evolution (video games). The classical output here is just a snapshot of state. I don't think trying to squeeze everything into a "dataflow" paradigm of input -> processing -> output is a good idea. Also, in context of design patterns - the problem is that even if we take "input -> processing -> output" assumption, the space of possible outputs is huge, and the criterion for acceptable outputs is very complex. It is this complexity that makes our code complicated, and the reason we have to build layers of abstraction is because our minds are pretty limited and we can't handle much complexity directly.
agumonkey 10y ago
We need a way to explore the design space of the design space.

TeMPOraL 10y ago

> We don't often understand what we are building most of the time. Indeed. Programming is a process of constant discovery and reframing of the problems ahead. > Most of the code is really a translation from input to some kind of command or process and outputting the result. I disagree. This may be true in a general form, but a general form like this is of little utility. There are many types of programs for which the focus is state manipulation, and what you care about is that state - whether in its final form (e.g. 3D modelling software) or in its evolution (video games). The classical output here is just a snapshot of state. I don't think trying to squeeze everything into a "dataflow" paradigm of input -> processing -> output is a good idea. Also, in context of design patterns - the problem is that even if we take "input -> processing -> output" assumption, the space of possible outputs is huge, and the criterion for acceptable outputs is very complex. It is this complexity that makes our code complicated, and the reason we have to build layers of abstraction is because our minds are pretty limited and we can't handle much complexity directly.

agumonkey 10y ago

We need a way to explore the design space of the design space.