in reply to Monk ethics: Beauty vs. Power

It depends on what's needful. Sometimes the right thing to do is to hack out the thing that works, as quickly as possible. Sometimes the right thing to do is to work carefully on the design. Other times you need the fastest possible code, and then you don't use Perl.

We live in a world. Programming is part of that world. It doesn't make sense to ask what a monk 'should' do except in relation to the rest of the world.

No 'ethos' is better than the others. All have their places.

Replies are listed 'Best First'.
Re (tilly) 2: Monk ethics: Beauty vs. Power
by tilly (Archbishop) on Dec 19, 2000 at 00:51 UTC
    I would disagree on one point. No ethos is better than all others. But some are clearly worse.

    In general it is safe to say that adjusting your policy to the need is a good idea. In my experience it has been true that if you worry about how to make things easy to debug and easy to change later, that usually works out pretty well.

[reply]
      No ethos is better than all others. But some are clearly worse.

      Can you give some examples? I can't say I have a particular ethos as such, but I can't really think of a "distinctive spirit" (see dict.org) that people have in regards to programming that I would consider bad. Even not having any particular approach isn't such a bad thing IMHO; it just means you haven't formed a general view as such yet.

[reply]
        Use the second definition.

        A few examples I have seen.

        1. Documenting every line of production code with a mechanical description of what the command does. See Code Complete or The Pragmatic Programmer for an explanation of why this leads to bugs.
        2. Having every program in a system create and destroy block files. The programs in question never did run synchronously, but the block files meant that if anything unexpectedly crashed, there was a good chance that the system would refuse to run again. (Most of the programs should have been function calls, but I digress.)
        3. How about writing long programs in straightline code rather than breaking out functions. For programs of several hundred lines it is faster end to end to produce it breaking out some functions.
        4. How about using goto in preference to function calls, looping constructs, etc? People used to do that at one time. (Not that goto is uniformly bad. I use it from time to time...)
[reply]

In Section Meditations