Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!EU.net!Germany.EU.net!zib-berlin.de!news.rrz.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: A bit of Dylan smell (Re: Attention all Dylan enthusiasts!)
Message-ID: <1995Nov8.132609.28334@wavehh.hanse.de>
Organization: BSD User Group Hamburg
References: <roy-071195130025@mac-240.camb.logica.co.uk>
Date: Wed, 8 Nov 95 13:26:09 GMT
Lines: 100

roy@logcam.co.uk (Roy MacLean) writes:

>Dear Dylanoids,
>Over a week ago, I posted a message (reproduced below) asking (I thought
>quite politely) for summaries of the benefits that Dylan might have for
>software development.  Armed with these I could then enthuse along with the
>best of you.  But answer came there none...  Now, it may be that you're all
>busy being 'very, very angry' with Apple, but that seems to make it more
>important for you to get the Dylan message across to the wider
>software-development community.  You certainly need to do this, since out
>here in the Real World, I doubt that one person in 100 has even *heard* of
>Dylan. 

As a general rule, in a newsgroup with strong technical orientation
and a readership of hard-working people, you should not expect anyone
to invest more work in answering you posting that it took you to write
it. Scott Fahlman maybe will tell you more on this.

Anyway, since you bothered to write a second posting, you just
triggered me to give you some impression of Dylan :-)

1) Dylan is dynamically-typed and programs can operate without any
static type information. New in Dylan is that it *also* has mechanisms
(sealing) that enable static binding and inlined calls.

2) Dylan has everything that is needed to make full use of closures
and therefore use of clean, elegant new abstractions for control
structures. See Henry Bakers excellent paper on this.

<a href="ftp://ftp.netcom.com/pub/hb/Iterator.html"> "Iterators: Signs
of Weakness in Object-Oriented Languages".  ACM OOPS Messenger 4, 3
(July 1993), 18-25. If your language requires iterators in order to
get anything done, your language's control structures are grossly
deficient." (quoted from his www site)

While you're at it, read everything else in that directory :-)

3) Related to 2), Dylan can have a real macro system that shows not
such a big conceptional distance between normal code and macros as it
is in C/C++. And it *has* one. Yes I think I need a macro system, even
something non-perfect.

4) Dylan integrates low-level types (int, double, char) and
higher-level types, so you can use object dispatch to work on
them. This is not a big problem in C++, but -for example- in ObjC and
CLOS.

5) Dylan is kind of reflective. You can ask on object what type it is,
what it's variable are, even better you can ask *everything* in the
system about it (not only variables that are statically defined to be
dynamically typed as in Objective-C). The consequences:
- Writing good debuggers, browsers etc is easier and faster.
- Writing things like Object-I/O for persistence is more
  straightforward.
- A producer of a commercial Dylan system that includes these features
  can make them extensible by the user. Inside the debugger the user
  can do things on objects the author of the debugger didn't even
  thought of. The user can define his own object layout for
  persistence and plug this into whatever mechanism someone else
  defined for the Dylan system in use. The point is: Such things are
  easier, therefore cheaper and easier to make bug-free than in other
  languages. 

6) There are many more goodies that make programming more efficient,
such as type dispatch on more than one parameter.

In short (technically): Dylan is the only language I know of that has
the dynamic language I (as a Lisper) like and has the potential to be
compiled to machine code as efficient as C++. And it enables a power
user to make the best out of his tools (Compare Windows/C++ compilers
in this area. You're limited to whatever the implementor thought
of. And this with a *Microsoft* -or Borland- product...).

In short (emotional): Dylan is the only language with few limitations
in what can be done and combined that is not religious. Most other
dynamic/flexible languages are either junk (scripting languages) or
limit themself by refusing features the implementor doesn't consider
to be "The Right Thing". Could you imagine Smalltalk with a macro
system? I swear you, every damned language without some macro system
will see itself being processed this way on my system: 
`m4 < file.foo.m4 | whateverythebraindeadcompilerisnamed -f -`

I'm just looking into Scheme, a wonderful language, but full of
emotions.

OK, end of berserk mode.

Note that I am not a real Dylan programmer, maybe I'm a bit
inaccurate. 

As a note, I think there's very little literature to show Dylan's
features and explain what they are about. The DRM is good as a
reference manual, but there are too few "why?"s in it.

[Sorry for some bad English]

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin.Cracauer@wavehh.hanse.de
BSD User Group Hamburg, Germany 
