Re: A Dylan implemented on Common Lisp

[kem@math.ufl.edu (Kelly Murray)]

In article <3jirll$r0g@cantaloupe.srv.cs.cmu.edu>, sef@CS.CMU.EDU (Scott Fahlman) writes:
>> 
>> In article <D5345w.3xC@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>> 
>>    Contrary to the impression created by Scott's anti-Lisp propaganda,
>>    Common Lisp eliminated most of the small irritations that had built
>>    up over the years.
>> 
>> It eliminated some.  Many others were kept for compatibility reasons.
>> 
>> I feel kind of funny being cast in the role of an anti-Lisp
>> propagandist, just because I believe that Common Lisp is not perfect
>> and that Dylan can do better in certain respects, both large and
>> small.
>> 

I'll just add one more thing to my M1 tank approach on this topic.

While CL may have its quirks,
creating a new untested language will most certainly end up having
it's share of "irritations" as well, they'll just be different ones.
There is the obvious c:=a+b isn't the same as c := a + b, which will
bite lots of people I'm sure, and the (no)macros.
Scheme has it's own little problems too, like no straightforward
object system due to it's "fixing" of the two-namespace "irritation".

To really get on my soap box, I'm reminded of when I helped psychology
students enter experiment results into data files on the Cyber to run SPSS.
They always wanted to start over on a new file when they made 
a data-entry mistake, instead of trying to use the editor 
(often 1st time computer users).  I'd tell them they would just
make a different mistake in the new file, and it would be faster to
take the time to learn to use the editor, but alas it took a couple
retries before they gave up and used the editor to fix the original file.

>> [..]
>> But it is different in important ways, and we want people to evaluate
>> the language on its own merits -- not dismiss it because they dislike
>> Lisp (for valid reasons or not) and think that Dylan is just more of
>> the same.

It won't be more of the same if it really addresses the issues that 
CL put off as unimportant:
(a) unfamiliar syntax (b) C-like image footprint and execution speed.

With a new name, new syntax, and small image size and good execution speed,
I find it hard to believe that being compatible with CL will stop non-CL
people from taking a look.  You don't need to make CL compatibility
a feature of the language when marketing it.  However, it just might turn 
out to be a great feature that a CL system can be used to develop 
Dylan programs.  

I could have sworn I saw this horse still twitching...

-Kelly Murray