[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Dylan implemented on Common Lisp
- To: email@example.com
- Subject: Re: A Dylan implemented on Common Lisp
- From: firstname.lastname@example.org (Kelly Murray)
- Date: Wed, 8 Mar 1995 02:28:58 GMT
- Organization: University of Florida Department of Mathematics
- References: <email@example.com>, <1995Mar6.firstname.lastname@example.org>, <email@example.com>
- Sender: firstname.lastname@example.org
In article <email@example.com>, sef@CS.CMU.EDU (Scott Fahlman) writes:
>> In article <D5345w.3xC@cogsci.ed.ac.uk> firstname.lastname@example.org (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
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
I could have sworn I saw this horse still twitching...