----- Original Message -----
From: Sean Middleditch <elanthis / users.sourceforge.net>
To: ruby-talk ML <ruby-talk / ruby-lang.org>
Sent: Monday, August 27, 2001 3:09 PM
Subject: [ruby-talk:20442] Re: Backwards language


[snip]

> Ruby is a very dynamic language, which is really great, but isn't what I'm
> looking for in my project.  I seem to have generated the wrong set of
> reponses to my original query, which was merely what people though of
> designing a backend before a syntax, for a syntax-neutal language, once
> designed for it's power and speed of execution over it's gramatical and
> syntactical features.

Sean,

My $0.02.

The reason a backend exists is so that it can be conceptually separate
from the rest of the system. It can be maintained, tuned, documented --
and yes, *designed* -- separately. But we all know that.

The question then (your question) is: Does it make sense to design the
backend *first*? And I have to say: I see no problem with that.

But let me qualify that by saying: Once you design the rest, you may find
yourself wanting to change the design of the backend somewhat. And
that is just life in the programmers' world.

One of the few projects from grad school that I remember with fondness
was a simple language I designed. Unlike some other people, I created
three separate pieces: A compiler which generated fake assembly language;
an assembler which assembled that into a relocatable object; and a binary
interpreter acting as a virtual machine on which to run that object.

Testing the three of them could proceed in parallel, of course.

The relative ease with which the project was accomplished was not a tribute
to my programming skill as such, but rather the consequence of a sensible
design choice and a few good habits drilled into me by my instructors.

So my opinion is: Separate the pieces well enough, and it's largely
irrelevant
which order you do them in.

Hal