🚀 go-pugleaf

In article <TMB.92Nov7233431@orac.idiap.ch> tmb@idiap.ch writes:

			........................

>Since scientists and mathematicians generally only have little time to
>spend on programming they (including myself) are probably better off
>choosing a programming language that supports safety and reuse (i.e.,
>a language with GC, runtime checks, polymorphism) and that is simple
>and regular enough so that it can be mastered fully in a short amount
>of time.

Since Algol, which ignored much that mathematicians were already doing,
there has been no language designed with the constructs used in mumerical
computations foremost, or even particularly important.  Fortran was 
designed for small programming jobs, not library functions, but it did
consider what is needed for numerical computation.

Those who rewrote my code without gotos had to work to do it.  I am not
opposed to using "structured" ideas when they help, but they often do 
not, and figuring out what is happening with a batch of unlabeled blocks
and break statements is much harder than following a natural goto
control path.  It is the way that mathematicians think, and redefining
continue to be different from Fortran is not going to help.  Requiring
a function call when a goto is what is really wanted, and hoping that 
the compiler can decide if this is what is wanted, or a call-return 
situation with full context switching, is not going to help.  

Also, forcing an unnatural syntax is not going to help.  I can, with
some difficulty, read and write Polish or reverse Polish notation.
With few exceptions, assemblers are essentially Polish.  Lisp is
essentially Polish except for the "standard" arithmetic operations.
Requiring the writing of pow(x,y) (or is it pow(y,x)?) instead of
x^y is forcing Polish without even using its power.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)