Grammar for future languages (2)

Dear readers of comp.compilers and esp. Michel Schinz,


The article by Michel Schinz on grammar for future languages started
a train of thought which ends in this new posting starting an all
together new topic which has been bothering me for the last two or
so years. The above mentioned article was the last step that made me
realise what the question exactly was...


"What does the world want from a programming language?"


Okay, this seems an obvious question, I agree, but the awnser to it
(as far as I can see and as far as I know "all" the languages of the
world) is not represented in the languages so far implemented.


Lets cautiously analyse what "the world" wants from a programming
language.


1. Reliable code
2. Readable sources
3. No hassles
4. Short development time
5. Portable code




ad 1. Reliable code:


The reliability of programmes is, as far as I am concerned a major
issue. With the growing complexity of software, the reliability of
the individual parts have to be guaranteed. Software quality
assurance is not an easy task, especialy if you're doing it
afterwards. Code coverage tests hardly scratch the surface and
beta-testing takes a lot of time (see windows'95). So the quality
has to be guaranteed in advance. Programming languages should have
mechanisms to support the programmer in maintaining reliable code.
If a method of development is chosen this should be impaired by the
language. For example C++ is not an object oriented language. The
presense of constructs as public declarations and the possability to
write hybrid code tempts the programmer to let go of key concepts of
object orienation.




ad 2. Readable sources:


The source code (if sourcecode is still what we're talking about)
should be highly readable. This is a point that is highly related to
the subject of the above mentioned posting. What is readable code. I
regard, even though I have written programmes in LISP, the syntax of
LISP as error prone due to unreadability. Maybe this could be
overcome by the use of editors with an extensive support for the
language but I think the standards for the layout of LISP programmes
should be adapted to enhance readability. I agree that "C" is not a
great language either, even thoug I write C-code dayly. But that is
not because the language is hard to learn. Learning a language is a
one time thing. Its strange constructs being alowed that make C
error prone, a C programmer is totaly unprotected. If we take a look
at an error that has costed me hours and hours to find out (and I
was not a newbe then):


for(n=1;n<100:n++); /* the colon at the end of this the bug*/
                                x[n]=x[n]+1;


The semicolon at the end of the first line lets the for loop execute
without the statement following it. The increment is only executed
once for n=100 (! a number that should not at all be used as an
index of the array). The layout of the programme looks like the
second line is being executed 100 times but it isn't. Python has a
way around this by using indentation as a means to notate compound
statements. I think that is a great concept and concepts like these
should assist the programmer.


3. No hassles:


Languages like ADA, as far as I have seen them, protect the
programmer against sloppy programming, but hamper the programmer by
asking extensive decalarations of exit and entry conditions. I guess
C++ is such a success because it gives only extra's: If you want to
write a class you can, if you don't you don't. To combine the first
and the third demand is I think the biggest problem to be solved...


4. Short development time:


Rapid prototyping, and time to market. I didn't invent them, but
they are contemporary issues. I think the only way to attain this
goal is by extensive use of libraries and multiple grades of
programmers within one company. Using embedded languages like tcl or
elisp sewing collected functionality into a programme. If possible
the top level programming should be graphicaly supported, the idea
of a "Visual Basic" but without the Basic (of course). This should
result in being able to respond to market infulences, but I am not a
visionary on this topic. Lets got to the next.


5. Portable code:


I guess this is not a programming language topic but one that has to
do with operating systems. (Wouldn't the world be a better place if
good old Bill had implemented Unix on the PC.) The main problem in
portability is that you "have" to port, since there is not yet a
winner commercially so users of multiple platforms have to be
served. Yet it is a problem that has to be solved in
languages/libraries. I have not yet seen a good library that solves
multi platform problems, but I haven't done an intensive search.




So what have I done to overcome these problems. Well nothing realy,
what can be done. I considdered writing yet another language, but
I'll strand on the same implementational difficulties that forced
all other language designers to compromise their "ideal" grammar.
But more and more, performance is of less relevance. Increasing
processing power enables the software to be less efficient but
safer. And constructs that in the sense of parsing may be horrible
can be implemented in a way that makes it possible for a programmer
to write reliable code. It is important to realise that writing a
compiler is relatively little work compared to the many many
programmes that will be written with it. And here we come back to the
above mentioned article on grammar. Michel Schinz says that the
grammar has to be more compiler frienly. I say the language should
fit the needs of the user, if those two can be combined okay, if not
I think the demands of the user should win.


Maybe I should conclude by saying this is not an attack on Michel, I
think on most points he is righ. But I think the scope of the
subject is much wider and should be handled with care.




Jacco van Muiswinkel
jaccom@ambrosia.knoware.nl
--

Return to the comp.compilers page.
Search the comp.compilers archives again.