HP3000-L Archives

January 2010, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Tue, 26 Jan 2010 20:07:44 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
In message 
<[log in to unmask]>, 
Ray Shahan <[log in to unmask]> writing at 16:02:58 in his/her 
local time opines:-
>Hi Gary,
>
>       Here are a couple of thoughts on those classes that involve any
>type of programming for your question "What are the right sets of
>competencies that our graduates need?":
>
>       Always, always use KISS (Keep It Simple Sparky). If you can
>write code in your language that a beginner can understand, then you've
>mastered your language, but if someone has to have a PhD to decipher
>your code, you still haven't mastered your language.  For example:
>               Given that A=0, B=1, C=2, we can arrive at A two (or
>more ways), one method (1) is clever (but difficult to understand); the
>second method (2) is simple (but very easy to understand) - and both
>methods arrive at the same answer, A=7.
>
>       1.      A=6+(B<C)
>       2.      IF B<C THEN
>                 A=7
>               ELSE
>                 A=6
>               ENDIF

I can see how, but why? [1]

>       Next, and maybe even more important - Always test, test,
>test...at every stage of development.  Testing at every stage makes
>final testing cleaner and faster, and I can't state this strongly
>enough: "A mediocre programmer who's a great tester will provide a
>better end product than a great programmer who's a mediocre tester
>because the great tester will be more likely to find and correct their
>mistakes".
>
>I strongly believe that these two points are profoundly important to get
>across to all new students for their success in the IT world.
>
>
>HTH,
>
>
>Raymond Shahan

[1] Based on my precept that the code needs to model the problem, even 
if that makes it more complex than some shortcut solution.

If you model the problem, then:
(a) it is much easier to see if your code does indeed implement a 
solution to the stated problem, and not some deceptively similar, but 
different one;
and
(b) when change happens, as it inevitably will, code that models the 
problem will be much more readily changeable to suit the revised problem 
than some super-optimisation or tricky shortcut that is likely to fail 
to meet the new needs.

And such revised code will, in turn, be more logical and maintainable 
for the future.

Accordingly, I could not tell you the best way to program the derivation 
of A from B, C and the constant 6, unless I knew the real-world 
description of what you were doing and why.

And I bet any solution that started with D = 6, and used D instead of 
the constant 6, would be more robust and future-proof than even your 
simple example 2.

-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2