http://qs321.pair.com?node_id=116841


in reply to Re (tilly) 3: Maintainable code is the best code -- principal components
in thread Maintainable code is the best code

Actually, I think that principal components is a horrible way of look at programming. Programming is, essentially, the art of instructing a being as to what to do. This being has an IQ of 0, but perfect recall, and will do actions over and over until told to stop. There is no analysis by the being as to what it's told to do.

As for a human reader, the analysis is focused on atoms, which can be viewed as roughly analogous to principal components, but they're not.

The first principal component is meant to convey the most information about the data space/solution space. The next will convey the most of whatever the first couldn't convey, and so on.

In programming, the goal is for each atom (or component) to convey only as much information as is necessary for it to be a meaningful atom. Thus, the programmer builds up larger atoms from smaller atoms. The goal is to eventually reach the 'topmost' structure, which would be the main() function in C, for example. That function is built completely of calls to language syntax and other atoms, whose names should reflect what that syntax or atom is doing. Thus, we don't have if doing what while would do, and vice versa.

In data analysis, you want to look at the smallest number of things that give you the largest amount of knowledge of your dataset. But, you're not analyzing data. You're reading algorithms, which do not compose a dataset in the same way that observed waveforms would. To understand an algorithm, you have to understand its component parts, or atoms.

Think of it this way - when you explain a task to someone else, say a child, you break it down into smaller tasks. You keep doing so until each task is comprehensible by the recipient. At that point, you have transmitted atoms. At no point have you attempted to convey as much information as possible in one task. Each task is of similar complexity, or contains similar amounts of information.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

  • Comment on Atoms as a concept for programming analysis

Replies are listed 'Best First'.
Re (tilly) 1: Atoms as a concept for programming analysis
by tilly (Archbishop) on Oct 05, 2001 at 17:25 UTC
    I like the idea of atoms in that it captures the point that functions should be small and simple.

    But I really think it is key that a good programming model shows a good conceptual model which is going to be well-compressed. Among other details, that points out not only why you factor code, but also why you avoid repeating it.

[reply]
      I'm not sure why the 'but' ... an atom isn't going to be repeated because it already exists. You're going to reuse an atom every time you can. (But, then again, I'm assuming logic will be used here. *shrugs*)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
        The reason for the but is that if you are trying to merely decompose into atoms, then you have no reason to aim to create atoms that are maximally reusable in creating other atoms. Indeed not creating them makes for more local simplicity.

        When reusability conflicts with local simplicity (and they very often do), saying that reusability generally wins is based on some value system. Without a value system to reason from, your conclusion is not just logic. I think that the concept of intellectual compression captures the value system quite well. I think that the atomic hypothesis captures what you do, but misses why you do it, and cannot resolve that conflict.

[reply]

In Section Meditations