Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday February 14, 2006
04:38 PM

See Spot Program!

[ #28684 ]

... but this code is easier for newbies to understand! Your code is too complicated!

See Spot Run is easier for novice readers to understand than The Name of the Rose, but the latter is the better book.

Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem? (Though if your problem is teaching how to program, obviously your goal is different.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem?

    Because those are the people who'll be doing maintenance. Or so goes the reasoning.

  • The New York Times targets a specific reading level. It's not kindergarten, and it's not PhD, but somewhere in between. Restraint in coding doesn't have to mean babytalk.
  • Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem?

    I tend to agree. For maintainance reasons I can see helping people ignorant of the platform, or perhaps even the language in some rare cases, but definitely not the problem domain. It's not worth writing kernel code so that programming newbies can understand. You may be able to write much of it so that *kernel* newbies could pick it up and maintain it. Even then, some prob

  • Keep the code as simple as possible while still doing the job effectively.

    Complicated code is necessary at times, but the vast majority of the code should be so clear and easy to read that maintenance actions are obvious without requiring an in depth study.

    • But, what's clear to an expert is NOT the same as what's clear to a novice. It's not a matter of "complicated" vs "clear", it's "concise" vs "wordy".

      Concise, normalized, idiomatic code is very understandable to an expert, but opaque to a novice. Long, spelled-out, heavily commented code is most understandable to a novice, but frustrating to an expert who now has to read (and evaluate) maybe two to ten times as much code as is necessary. Some (short!) things that are obvious to experts may have no meaning at
  • See Spot Run is easier for novice readers to understand than The Name of the Rose, but the latter is the better book.

    But without seeing the code in question how do we know whether the code is incomprehensible because it's a "better book". Maybe it was written by a gibbon given access to a keyboard and liberal quantities of scotch :-)

    Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem?

    For me the danger is thinking that