Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mtuxo!mtune!rutgers!husc6!hao!ames!sdcsvax!ucsdhub!esosun!seismo!uunet!munnari!moncskermit!moncsbruce!conybear
From: conybear@moncsbruce.UUCP
Newsgroups: comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <326@moncsbruce.oz>
Date: Fri, 30-Oct-87 00:49:23 EST
Article-I.D.: moncsbru.326
Posted: Fri Oct 30 00:49:23 1987
Date-Received: Sun, 1-Nov-87 08:16:23 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA>
Organization: Comp Sci, Monash Uni, Australia
Lines: 81
Summary: Restrictive work practises in computer languages

In article <3603@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes:
>In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>>        6.  Realize that efficient code does not necessarily take longer to
>>produce than inefficient, ...
>True, but the one in a thousand cases where this is true don't help much.
>Efficient code almost always takes longer to produce than inefficient code.
>You must invenst development time to get efficiency.
>

	I feel frustrated when I can imagine simple, efficient machine-level
code to solve a problem, but I cannot get my HLL of choice to produce it.

	For example,  suppose I want to allocate space on the stack,  but I don't
know how much space will be required until runtime (this is very important
if I want to implement function calls efficiently in an interpreter,  or
write a B-tree where the user provides the size of the elements to be stored
in each B-tree).  
	How do I proceed?  If the language does not provide this facility and
gives me no way around its restrictions, then I must find another
solution within the language, and this may be a high price to pay (in a lisp
interpreter, the price might be allocating N cons-cells from the heap on
every function call; in a B-tree, allocating 1 B-tree node from the heap for
each activation of the add() procedure).
	On the other hand,  if the language does allow me to turn off restrictions
(e.g. in-line assembler, type casting), then I can have a non-portable
but efficient solution. 

	I believe that it is *my* business, not the language designer's, to 
choose the tradeoff between efficiency and portability when the language
does not provide a solution to my problem.

	I feel that many modern computer languages suffer from *hubris* on the part
of the language designer(s).  Like everybody, language designers make mistakes,
and I have yet to see a 'perfect' language.  I do not expect the 
designer to anticipate all the features I might want in their language.  I
do mind when the designer says "take my language and submit to it's rules,
or write in assembler".  I am most productive when I can submit to a
language's restrictions where those restrictions help me avoid errors;
and disable such restrictions, with care, when they obstruct "the best"
solution to a problem.

Now for my $0.02...
In article <3603@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes:
>In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>>I suggest that there be a major effort to produce an incomplete language
>>which is ...

>>        2.  Easily extended by the user.
>
>What do you mean by "extended".  Different notions have different costs and
>benefits.
>
>>        3.  Designed with the idea that anything the user wants to do should
>>be efficiently representable in the extended language.

	It is generally agreed nowadays that languages should be extensible.  I
propose that we should strive to produce languages that are extensible in
as many different directions as possible, since every language feature which
is fixed places a restriction on the programmer and the power of the language.
	For example, LISP traditionally can be extended by adding functions,
however just a few types (ints, strings, cons cells) are built into
the language and this set is not extensible.
	In Pascal or C, I can define types and functions, but not operators.
I cannot generally define constants in the types I define.

	I also propose that our compilers should be extensible.  My ideal compiler
would look like one of today's compilers, but decomposed into a set of modules,
with explicit interfaces.  Some modules would describe how to compile builtin
types.  If I did not like the compiler's code generation for floating point
numbers,  I could reimplement the appropriate module.  If I felt that complex
numbers were essential, I could implement them.  While much of this
can be done using user-defined types and functions, the important thing is
that if I have control over my types' compilation then I also control their
implementation.
	Furthermore,  I can develop an application quickly using whatever
compilation methods are available,  and optimise it later.  For example, I
might write a module to provide variable automatic allocation at run-time
using the heap, and later alter it to use the stack.

Roland Conybeare
(conybear@moncsbruce.oz)