From: "Michael W. Ryder" <_mwryder@...>
Date: 2008-04-24T04:10:07+09:00
Subject: Re: A couple of questions regarding class design

Robert Klemme wrote:
> On 22.04.2008 21:12, Michael W. Ryder wrote:
>> Robert Klemme wrote:
>>> On 21.04.2008 23:28, Michael W. Ryder wrote:
>>>> I chose this after reading about it in Knuth's 2nd volume.  I wanted 
>>>> to try to implement the binary greatest common divisor algorithm in 
>>>> Ruby. It took a little effort but I was able to implement it without 
>>>> any Go Tos.  It is hard to go from languages that require jumping 
>>>> around in the code to one that doesn't.  It's a totally different 
>>>> mind set.
>>>
>>> And, does it feel better?  For me it does - for Knuth apparently 
>>> not.  I haven't felt the need for a goto in ages.  I also rarely use 
>>> continue and break in loops.  My impression is that quite a number of 
>>> cases where either is chosen can be greatly improved and actually 
>>> simplified by choosing a different loop condition.  My 0.02EUR...
>>
>> Coming from a background in computers from the 70's when the language 
>> was much closer to the metal I never had any problems with Go To or Jump.
> 
> Well, you had to use what you got, didn't you?  I believe the reasons 
> Basic et al had GOTO was historic as you said: programming languages did 
> not have evolved very far from the basis (machine code or assembler if 
> you will).
> 
> But later people detected deficiencies of this approach and tried to 
> come up with better solutions.  I would not want to miss structured 
> programming and exceptions.
> 
>>  In assembler there is no way to not use Jumps for loops or 
>> conditional processing.  Fortran and Basic were much the same way.  I 
>> believe Knuth's original works were from this era and of course a lot 
>> of his code is in the MIX assembler.
>> I can see the reason to eliminate jumping around in code when possible 
>> but think they can sometimes make a program easier to read.  I find it 
>> easier to read a program that says "If error goto ERROR" over trying 
>> to figure out where a Break command goes.
> 
> Well, for error handling there is a different mechanism in modern 
> languages: exceptions. :-)
>

One thing I haven't figured out is returning from an exception to the 
calling location.  In Business Basic I can set a location that the 
program will go to when an untrapped error occurs.  From there I can 
handle the error and return back to the program.
I can also do the same if the Escape key is pressed, or I can go to a 
new location and continue.  This comes in real handy when an operator is 
finished with data entry they just press the Escape key to save the 
changes and continue.


> Kind regards
> 
>     robert