🚀 go-pugleaf

In article <2416@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>It should be such as to enable the programmer to express his problem
>in a manner that is compatible with the structure of his problem and
>the capabilities of the machine.  It should also be such that the
>resulting program is reasonably efficient.
>
>Now I do not believe that a language which can accomplish all this
>can be produced which is completely portable.  But it is necessary
>to take these things into account in designing the language.  Making
>it extensible can enable local modifications to be made. 

It seems to me that Herman has a completely different set of needs (from a
programming language) than I do. Hence, his opinions on what a good programming
language needs differ from mine. Herman is concerned about the efficiency
and ease of representation of small pieces of code which are crucial to
his overall application. I am concerned about the readability, maintainability
and efficiency of much larger programs. Most programs that I work on are
well over 10,000 lines, and, usually, no one part is much more important than
any other (there are of course hot spots, but there are lots of them, rather
than just one or two). I don't agonize over a small piece of code, either
to make it as short as it can be or to make it as fast as it can be. I let
the compiler worry about code size and speed. I worry about the overall
operation and readability of the whole program, since I am constantly adding
new things, fixing bugs (like critical sections and timing-related bugs in
my IOP code), etc.

As someone who has designed, implemented and regularly uses his own compiler
(don't ask - its only available on CP/M and the Amiga), I also disagree with
Herman's ideas about very loose syntax, extensibility, etc. Such a beast would
have very poor error handling, and hence would be quite unfriendly to work
with (even worse than pre-ANSI C!!). It would, also, in my opinion, be
DANGEROUS to work with - the compiler would have to trust the programmer
implicitly (just like in assembler), so would have few opportunities to point
out things that don't make sense. I wouldn't want such a language to be
used in things like nuclear reactors, railroad control systems, etc. It
could be fine for Herman's fine detail fiddling, but its not for me!
-- 
Chris Gray		Myrias Research, Edmonton	+1 403 428 1616
	cg@myrias.COM          {uunet,alberta}!myrias!cg