Introduction and misc ideas (fwd)

[Alexis Read]

---------- Forwarded message ----------
Date: Tue, 18 Jun 2002 11:46:02 +0100 (BST)
From: Alexis Read <ucapare@socrates-a.ucl.ac.uk>
To: Kyle Lahnakoski <kyle@arcavia.com>
Subject: Re: Introduction and misc ideas



On Mon, 17 Jun 2002, Kyle Lahnakoski wrote:

> Thank you very much for this breakdown of expressibility.  I have been
> working on something similar, but stopped prematurely.
>
> 	http://www.arcavia.com/rd/document/LanguageAspects.html
>
> If you do not mind I would like to update my page and give you credit.
> If you have more on this subject, I would be glad to hear about it.
>
> Thanks
>

Sadly I can't claim credit for this breakdown - ideas usually have to come
from somewhere and this one came from:

http://cadcwww.dao.nrc.ca/ADASS/adass_proc/adass3/papers/adorfhm/adorfhm.html

which is an astronomical data analysis paper ie. it should be ok to use.
The paper documents the advantages of using an environment too.

I had a look at your site, the quote below I feel could use some
expansion:
'I have not determined a good measure for expressiveness, but it can be
stated subjectively as: The ability to specify a program clearly and
    concisely. It appears that there may be no way to measure
expressiveness because it depends on the subjectivness of human beings.'

A Java book I've read (Developing Java software by Russel Winder $ Graham
Roberts ch9) has a good section on writing programs. The idea is that of
capturing the abstractions of the PROBLEM DOMAIN in the program code. The
problem domain is the context in which a particular problem exists,
this domain changes more slowly than the problem itself.
A more expressive language will be better at capturing this problem domain
eg. the difference between using a map to get from A to B (kind of OO) and
using a set of directions instead (procedural) - the map can be reused
better for going from A to C.

'One possibility is it could be an inverse of statistical mean development
times. But even that measurement
    would require a domain of problems that may be dissimilar to the
problem at hand, and ultimately a poor measure.'

People usually ignore the last stage of program development - maintenance.
It includes bug fixes, correcting faulty behaviour, supporting the program
in new environments eg. new OSes, adaptions to changes in requirements,
and adding new features.
It is the last two that are important as they change the problem but not
the problem domain, and usually prove a program's true robustness. (and in
true form my programs usually fall at this step!) The other important
point is that you MAY NOT be maintaining your own program!

I guess that there should be another category to the 12 in that the
STRUCTURAL DESIGN of a program should be conveyed in a clear, concise way.
This gets more important the larger a program (and development team) gets,
and so SCALING code to meet requirements is an important test of
expressiveness - a program should be able to work for small and large
problems eg. dataset size in sci problems.

'Lisp uses second order functions and macros to increase expressability
despite simple semantics.'

It might be useful to mention that macros are a from of information hiding
ie. abstraction.

Finally, I should have said that point9 should be rephrased for my post,
to include partial evalutaion.
I started a language review page many moons ago on my site:
http://www.ucl.ac.uk/~ucapare/lang.htm   eg.

http://www.ucl.ac.uk/~ucapare/language/eiffel.htm

It might be useful to you.
Alexis.