Re: language evaluation metrics?

On 21 Nov 1998 12:06:32 -0500, kcooper@cs.ubc.ca (Kendra Cooper)
wrote:
>But when people develop new languages, how do they know they have
>"everything" in the language? (programming language or other)?


Having enough in there to do everything turns out not to be the
problem, Kendra. Put in a few arithmetic operators and datatypes,
plus labels and gotos, and there you are: you can compute anything.
The real problem is making your language fit the problem domain well
enough to be useful. You want a lot of "expressivity" and not a lot
of "boilerplate." In other words, you want to increase the
signal-to-noise ratio of programs written in your language to the
point where your users find it actually useful to use, rather than a
pain.


I know of no better way to do this than to work with the language a
lot. Designs that come down from on high head straight for the
junkpile. The way to work with it is to make your best shot at a
language, then start writing programs in it, even before you have the
compiler built. Write a few small programs, then write a few
medium-sized ones, as though you actually had the language there.
You'll find that you screwed up in a number of places, probably, and
you'll want to go back and change things. Keep doing that a while
until you get it as clean and simple as you can.


Then ... and here's the radical part ... build yourself a little
translator for your language. So it with the intention of throwing it
away. For most specification-type languages, a perl program should
suffice; perl is amazingly powerful at text processing. Build in some
convenient restrictions on the format of the input for the language
(so you don't have to write a full-blown scanner) and build a perl
program that translates programs from your language into the language
that you know best (say, C). It's okay if it doesn't work all that
well, you just want to get it working, so that you can have the
experience of working your way through all of the problems that you'll
encounter in the real application, eventually, when you write the real
compiler.


Work with that a while, until it translates little programs with
somewhat-restricted syntax into workable C. With that in hand, go to
a kindly guinea pig and tell him you would like him to help you with
your language. He's your first user, and get him to write some
programs in the language. Take his comments about the areas that he
doesn't like and work with them until you've got an even better
design, and change your little translator to accommodate the new
specifications. After a time, you're almost there ... take on one
more user, dothe process with him, and now you've got a reasonable
first crack at a language.


But avoid at all costs putting in everything that everyone wants.
Just take their concerns into account, mull them over, and if you
don't think the idea warrants a change, then don't make a change. Or,
think about how to make a more fundamental change that would solve not
only that user's issue, but all other related issues as well.


There is a magical thing in language design: power and generality tend
to come from the removal of crucial limitations, rather than the
addition of new features. When you find out what is truly in the way,
just down down and take it away, and poof, the language cleans itself
up. To see what I mean, take a look at the Revised Report on The
Programming Language Scheme, and compare it to the ANSI C++ draft
specification. C++ has zillions of features that interact in strange
and unexpected ways, making it a bitch to learn. Scheme has a tiny
set of features that are completely general, and that interact
beautifully. The entire language spec for Scheme is on the order of
50 pages or so, smaller than the spec for the C++ preprocessor alone.


Also, these days it makes sense to approach a problem domain armed
with state-of-the-art tools like type inference, algebraic types, and
so on. There's no need for the programmer to have to specify types of
variables when the compiler can figure them out for him; and the types
that he does specify can be much more useful if they follow
sum/product formats. Then you have the ability to add pattern
matches, if that's appropriate to your problem domain, that split out
the various pieces of the types into cases inside your functions.
Also, if you have storage requirements, having garbage collection
around is a godsend. And regardless of C/C++, local functions are the
way to go for sub-computation. These are some of my preferences going
into a project; they come mostly from ML, an astounding language, all
told.


Have fun with your project!


Dwight

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