Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^2: Programming *is* much more than "just writing code".

by BrowserUk (Pope)
on May 09, 2007 at 18:34 UTC ( #614469=note: print w/replies, xml ) Need Help??

in reply to Re: Programming *is* much more than "just writing code".
in thread Programming *is* much more than "just writing code".

It's hard to pick out a appropriate quote from your first six paragraphs, it would require quoting the whole lot I think. I completely agree with you.

Programming is still yet a very young discipline when compared to most others. It has yet to established itself in the same way or to the same level of scientific reproducibility as the older disciplines. it is still searching for it's equivalent of the universally standard nomenclatures enjoyed by those other disciplines, and that's reflected in the constant strains between existing and new languages; existing and new methodologies; existing and new tool-sets; working practices; et al. Everything within the industry is still in flux.

In part, this is because unlike the historic, slow boil evolution of the scientific methods involved in mathematics, and the other sciences, which evolved over centuries, through the hands, minds and publishings of a few greats, working primarily alone, but in communication with their (few) peers; programming is evolving in a world of mass communication, widespread, low-level participation, and commercial pressure. It is not so much evolving as constantly revolving. (As in revolution, but also going around in circles. :)

With each new generation, comes a least one 'new' methodology, language, set of working practices. And usually many of each. Each will be held up by it's proponents as the magic bullet that will revolutionise the industry. The Holy Grail for productivity, or reliability, or re-usability, or efficiency. And usually all of those. Invariably, each of these revolutions has some merits. Equally invariably, they have their flaws also.

In this ever changing, and multi-frontiered world, it has become nigh impossible to be aware of all the developments as they happen, never mind keep pace with them sufficiently to be able to pick out those parts that will persist and make it into the future. The historical debates between expert practitioners, often conducted over years by letter, or even the publishing of books, has no true equivalent in the modern world. Single ideas that would have formerly been debated over years, (sometimes decades), come and go in fleeting electronic moments. Lost in the noise of internecine wrangling; interpersonal debates; ad hominem attacks; general and specific flame-fests of all kinds. Everyone has an angle; an axe to grind; an ego to defend; a buck to make.

The software industry spends far too little time exploring and debating the outcome of ideas, methods and practices. Instead of looking back at what was done, and trying to determine what was effective and what was not; how small changes might have made big differences to outcomes; how small parts from several methodologies could be extracted and combined to produce something bigger than the sum of the parts. As an industry, we are always looking for the next magic bullet. The next revolution that will save our collective souls. We discard not just the bad parts of what we did before, but everything, and leap upon the next bandwagon like it was a number 32 bus headed for nirvana.

The art of debate has been lost. The merit of seeing the other guys point of view; the benefit of constantly re-evaluating ones opinions in the light of the other guys thoughts and experience; is effectively dead within the programming community. If you use Perl, you must also be convinced that CamelCase is bad; must subscribe to the OSS ethic; must be one of the LAMs in LAMP.

I'm a relatively new study on the history of mathematics, and I am aware that some of the historical greats were far from ego less. I know that there were, at various points in time where two or more of the greats coexisted on this earth, considerable and heated (if you can get heated when communications is by a letter back forth every month or two :), disputes over big ideas. But, from what I read, on those occasions when the owners of those egos and conflicting ideas got together in the same place, they would happily sit down and share a meal and a few bottles of wine before or after a face-to-face debate where they each held opposing views. Technology means that we are able to communicate ever more quickly and with ever wider groups, but the human part of the equation hasn't kept pace. We humans still fall into our historic roles of tribes and combatants.

To try and bring this back on track. The software industry became an industry before it became a discipline. There are many, too many, languages, methodologies, sets of working practices, existing and coming on stream everyday, for any one person or group of people to be able to say what is best and what is not. Where pure research (into software and development) exists, it tends to be very far removed from the every day realities of commercial practice.

To badly paraphrase a line from a sci-fi program: the software industry is still young; it has much to learn. Sometimes, the best way to move forward is to look backward.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: Programming *is* much more than "just writing code".

Replies are listed 'Best First'.
Re^3: Programming *is* much more than "just writing code".
by doom (Deacon) on May 11, 2007 at 17:01 UTC
    BrowserUK wrote:
    I completely agree with you.

    And I found that to be a very puzzling remark at first, because it was pretty clear that MadraghRua was disagreeing with you:

    MadraghRua wrote:

    Going back to you original point, I think what you are advocating is great if it's your own stuff, you are working within a stable group or you are very experienced in all idioms of yor language/development platform. The main problem is the level of documentation needed for projects where the personnel are not stable and the next developer is someone who is not a script kiddie but is not as fluent as the last guy to comprehend and be able to make the modifications necessary to complete a job.

    But I gather that this is the reason you mentioned the "first six paragraphs", because you were explicitly ignoring everything else.

    ("The art of debate"?)

      But I gather that this is the reason you mentioned the "first six paragraphs", because you were explicitly ignoring everything else.

      Yes. That is a fair assessment. As with most of the other contrary points made in the thread, including your own, every point MadraghRua made in his last two paragraphs was addressed in my original post. I saw little purpose in further reiterating my counter arguments to those points, as I saw nothing in those last two paragraphs that in anyway diminished those counter arguments.

      His premise is, that when some relatively expert coder constructs a piece of code, he should make an attempt to review the code he writes in the light of the possibility that the next guy that will view that code may not be as expert in the language being used. He, (the expert original coder), should then add comment cards to explain anything that he feels that the next guy might not understand.

      I addressed this premise in my OP. Nothing in those last two paragraphs forms a counter argument, so there is nothing there to change my mind, and nothing that I can address other than through repetition.

      However, since you seem bent on continuing the discussion, I'll have a go at reformulating the arguments in a way that I hope will lead you, and anyone else still interested enough to go through the exercise, to either produce cogent argument against my point of view, or to accept it.

      What assumption should I make about the level of expertise of the guy that might follow me?

      • Will he understand about context?
      • Will he know when to use $array[ ... ] and when to use @array[ ... ]?
      • Will he consider map too complex?
      • Does he understand the concept of recursion?
      • Will he understand
        if( !$cond1 && !$cond2 && !$cond3 ) { doit() )
        perfectly, but somehow be flummoxed completely by
        doit() unless $cond1 or $cond2 or $cond3;
      • Will he consider regex some kind of scarey magic?
      • While he consider this clear and maintainable?
        #! perl use strict; my %data; while( my $line = <DATA> ) { chomp $line; my $position = index( $line, ':', ); my $key = substr( $line, 0, $position ); my $value = substr( $line, $position + 1 ); $data{ $key } = $value; } my @unsorted_keys = keys %data; my @sorted_keys = sort @unsorted_keys; for( my $index = 0; $index <= ( scalar( @sorted_keys ) - 1 ); $index++ + ) { my $key = $sorted_keys[ $index ]; my $value = $data{ $key }; print "$key : $value\n"; } __DATA__ a:1 b:2 c:3 d:4 e:5
      • Will he consider this, unmaintainable, deliberately obfuscated, arrogant, 'show off' code:
        #! perl -slw use strict; my %data = map{ /^(.+):(.+)$/; $1 => $2 } <DATA>; print "$_ : $data{ $_ }" for sort keys %data; __DATA__ a:1 b:2 c:3 d:4 e:5

        An interesting exercise for anyone convinced that comments help is to try and add comments to the above two snippets. If you feel like doing that and then posting the commented code, please do, because I will have great fun :)

      Even if it was possible, and desirable, to agree some 'base level' of understanding of Perl syntax below which it was not necessary to explain in comments; it would never be possible to reach a universal agreement at where that barrier should be set.

      And even if that barrier existed, requiring each programmer to come up with accurate, meaningful and useful comments to explain any construct or idiom that breaches that barrier, is simply ludicrous.

      The answer to the problem of encountering code you do not understand, is to educate yourself.

      Look it up or ask someone!

      Take 5 minutes now to experiment with the construct until you do understand it, and then you will understand it forever. Avoiding it forever, because it confused you the first time you encountered it is silly.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        The answer to the problem of encountering code you do not understand, is to educate yourself.

        Look it up or ask someone!

        A code example, including some comments I have used:

        # add attributes to object my @fields = (keys %{ $attributes }); @{ $self }{ @fields } = @{ $attributes }{ @fields }; # hash slice

        The first comment gives someone skimming the code a hint about what's happening here (that they can figure it out by close study may be likely, but making them engage in that study just to find out if this is the part of code they care about is at best inconsiderate).

        The second comment, "hash slice", is the sort of thing a beginning programmer would need in order to have a hope of looking up the technique in use.

        The fact that the level of knowledge of the audience is uncertain does not obviate the need to address the audience at a certain level. Would you argue against explanatory subroutine and variable names because a really good programmer doesn't need those hints?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://614469]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (2)
As of 2021-04-21 04:13 GMT
Find Nodes?
    Voting Booth?

    No recent polls found