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

Mark-Jason Dominus has written the second in his series of articles called 'Program Repair Shop'. You can find it here. What I found particularly interesting in this article was the concept of 'synthetic' code.

What he says is that programs contain two types of code, 'natural' code which actually describes and solves the problem in hand and 'synthetic' code which is only there as an artifact of the particular method that you have chosen to solve the problem. Examples of synthetic code are things like loop counters.

He goes on to say that a good program will minimise the amount of synthetic code as too much synthetic code will disguise the natural code and make the program harder to understand. Naturally he shows that Perl is very good at cutting down on the amount of synthetic code in a program.

It's a very interesting article and I'm recommend you all read it. If you're interested, the first of these articles can be found here.

Replies are listed 'Best First'.
RE: 'Synthetic' Code
by tenatious (Beadle) on Jun 29, 2000 at 18:18 UTC

    That is exactly the kind of article that I'd like to see more of. The reasons I like it:

    • It examines code that I could have written
    • It explains exactly what the code is trying to do
    • It breaks the code into manageable snippets
    • It shows a better way to accomplish the same goal
    • It explains the better way to accomplish the same goal
    • It creates vocabulary to discuss the concepts behind better practice.

    I would really like to see a section like this here, written in cooperation between an experienced perlmonk and a less experienced perlmonk. Naturally, the teams could rotate, and maybe somebody could choose at random the teams, granting extra experience on perlmonks.org for a contribution that is worthy.

RE: 'Synthetic' Code
by reptile (Monk) on Jun 29, 2000 at 14:28 UTC

    You know, I've found this to be the case too. I'm glad someone could actually put those thoughts into words for me. Especially things like temporary variables simply piss me off :) Too bad sometimes I just can't avoid them (like copying a referent into another reference to make sure whoever called the function doesn't delete a hash key on me or something - a bug like that bit me hard once).

    For the record, I haven't read the articles you linked to yet, just commenting on the idea you mention. I will check them out, and thanks for the heads up.

    72656B636148206C72655020726568746F6E41207473754A