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:
Olav Kappert <[log in to unmask]>
Reply To:
Date:
Tue, 26 Jan 2010 23:18:20 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
Craig:

I think the most important point is the documentation.  With 
documentation, the most complex program can become simple.  Without 
documentation, the simple may be more complex.

I have worked with languages that I did not even know, but with the 
documentation for the program in hand I was able to make the changes 
very quickly.

BUT nobody likes to document their programs.  I have not written a 
program  in 30 years that did not come with documentation.  It could be 
inline docs or as a
separate document.  No matter what, I always document every program I 
write.  (maybe one day, it is I who may need to read it to make changes)

Olav Kappert
IOMIT International (Application Development Specialist)


Fairchild, Craig D wrote:

>One more vote on keeping it simple! 
>
>I'm pretty sure method two always results in the answer 7. However, method 1 can result in either 5 or 7 depending on various systems and languages that I've worked on. Method 1 depends on false being equal to an integer value of 0 and a true being equal to an integer value of 1. Some systems/languages I've worked on define true as -1 (all bits on, as opposed to all bits off). 
>
>By the way, I also agree with Roy that modeling the code as closely as possible to the physical reality of the problem trying to be solved is desirable. In my experience I haven't found these two goals to be contradictory, but rather positively reinforcing of each other.
>
>At the risk of beating this poor horse well after it is dead (and I know Ray was just trying to show the difference between "tricky" code and straight-forward code), I would never use method 1, but I would also think the equivalent to 2 should be something more like:
>
>BASE_VAL = 6
>IF B < C THEN
>  D = 1
>ELSE
>  D = 0
>ENDIF
>A=BASE_VAL + D
>
>I find that when used, people try to justify method 1 as being "more efficient". If that was ever true (and it may have been at some point in the 1970s), it is certainly no longer so. In almost all cases, a few hundred instructions here and there really can't be measured (I/O and locks dominate wait times), and besides, modern compilers are really quite good at optimizing, so there is very likely no difference in the number of instructions executed by method 1 and 2. There is a difference in keystrokes that the coder had to type, and this is the type of "efficiency" that I think those folks really had in mind.
>
>
>  
>
>>-----Original Message-----
>>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
>>>      
>>>
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>  
>

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

ATOM RSS1 RSS2