I got used to Dylan's syntax from a C background, I still haven't got used
to Lisp's.

int CPlusPlus()
{
    return 1;

define method dylan() => ( result )
    1;
end method dylan;

- Rob.

  I think it would more accurate that the Dylan syntax was likely more a
  direct "anti" reaction to the baroque language C++.  That language was
  in the "cures all ills" phase that Java is in now about that time. I
  don't think the designers wanted to take the herculean leap from
  "scheme like" to "c++ like".  Languages like Ada and Modula-3 had
  more compatible syntatical goals than C/C++.

  The commonality that C/Dylan share is along the respective
  Algol ancestory lines. Which for both is kind of far back. ;-)
  However, it is enough, with modest effort, for folks predisposed
  to C syntax to latch onto.

       Dylan                                      C
   reference based semantics            value based semantics
   (never make a copy unless            ( always make copies)
     explicity asked for)

   operators are function calls         operators tend to map to opocodes

   most "statements" are expressions    statements don't return values.
   (e.g.
      1 ==  if test then a else b end; )

There are not totally unsimilar, but there are some definately some stuff
that can throw a C programmer into confusion.

The presented code fragments were almost entirely "syntax", IMHO.
The "last expression, function's value" sematics are matched in
dylan and lisp whereas the C requires explicit control change.

I will grant that people present their most negative visceral  reactions
to "alien" syntax. Second only to "alien" editors. :-)  They seem to
much more forgiving of difference as long as it malleable enough to
tweaked to what they want. (if necessary, a big enough hammer to
fit round peg into square hole.
         if test then temp := a else temp := b end;
         1 == temp;
Or the classic "FORTRAN written in C". )

I meant that within the language syntax you have markers for beginning and
ending blocks, blocks are scopes, and lines generally end with an end of
line marker. I know this sounds trivial, but the fuss people make over
syntax tends to obscure this.

So, despite having each others' programmers reaching for their Red Books,
these are equivalent:

// C

void klin()
{
    if( true )
    {
        exit( 0 );
    }

define method blim()
    if( #t )
        exit( 0 );
    end if;
end method blim;

Whilst the Dylan takes more typing (in this hyper-correct form), you get
better documented code and you don't have to start blocks twice as you do in
curly-bracket langauges.

You are right that the examples were entirely syntax, this was what I meant.

- Rob.

This was, of course, in the days before Java, Perl, and C#.

--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

(define fact (lambda (n) (if (< n 1) 1 (* n (fact (- n 1))))))  // Scheme
(define fact (method (n) (if (< n 1) 1 (* n (fact (- n 1))))))  // Dylan

Then the differences start.  Scheme has a shortcut "(define (fact n) ...
)" whereas Dylan has "(define-method fact (n) ... )".  Dylan lets you
replace args in the argument list with (n <integer>) as a type
declaration.  Dylan has a built-in object system (and everything is an
object).  But they are very, very similar.

But neither current implementation of Dylan supports the prefix syntax.  
At all.  It's pining for the Fjords.  It's an ex-syntax.  It's bleedin'
snuffed it.

  Yet, curiously, that was about the same time I decided Dylan was a
  waste of time.

Translation: I implemented Lisp and Lisp environments for 12 years.
I worked on Dylan for 5 years.  I'm back to using Lisp again.  Guess
what?  I like Dylan better, syntax and all.

  Oh, please.

| Translation: I implemented Lisp and Lisp environments for 12 years.
| I worked on Dylan for 5 years.  I'm back to using Lisp again.  Guess
| what?  I like Dylan better, syntax and all.

  Yeah, we need more personal testimonials.

  My point was that the decision to drop the Lisp-like syntax was
  pretty darn stupid considering it was a selling point towards a
  community that was told "you fine people don't matter, anymore".

when people know and love and understand something -- whatever that
something may be -- and then make a serious change (like Lisp->Dylan),
it's always hard to go back.  I think I wrote a post about his
phenomenon not too long ago.  Basically, it's always hard to go back to
something that breaking away from was work.  It's the same thing that
makes it hard for me to live in Long Island after growing up very
sheltered and struggling to live in my own in Boston.  

Of course, for me it was Pascal -> Common Lisp, and so going back to
that is hard for me.  It's really all about what you see and when you
see it.  I try to look at these things with as open a mind as I can, and
I simply cannot for the life of me see how the Dylan syntax is more
sensible.  I'm not counter-arguing; I just want to know details -- that
is, if you feel you can do it justice.  Admittedly, I have only a
cursory understanding of Dylan syntax, and so the best I can do is say
"I just don't like it as much" or something useless like that.  I do
think that Dylan syntax bites, at least for me.  Syntax is _extremely_
important to many programmers because there are many times when several
languages are "equivalent" in many respects, and so in the end it comes
down to which one's syntax one is most comfortable with.  

Since you have lots of experience with both languages, would you agree
that the CL syntax is more expressive?  more malleable?  More uniform?
I would, but if you feel otherwise, I'd like to know why.

I appreciate that the object-pascal-style syntax may be offputting to people
who think they've got a career for life writing COM objects in VC++, but
it's less offputting to these people IMHO than Lisp syntax, and Dylan sorely
needed to differentiate itself from the incorrect common perception of Lisp
as an AI/research language.

- Rob.

I'm tempted to say "irrelevant", because I don't use Dylan and
because it's unlikely that I ever will.  The syntax is largely
to blame for that, though not in the way most people reading this
probably expect.

(Actually, I think Dylan is a good language, and despite being a
"Lisper", I don't much mind the syntax, though it is a bit odd, as
"infix" syntaxes go.)

But ... things may have seemed different to people on the "inside",
working on Dylan design and implementation, but from my point of
view things went though something like the following phases:

 1. I start hearing about Dylan from other Lisp folk.  It sounds
    interesting.  Soon the first book appears, and at the Lisp and
    FP conference there's a lot of interest.  Dylan people are handing
    out copies.  The books says Dylan is a small dialect of Lisp,
    and all the code examples have a Lisp-like syntax.  Some
    implementations appear.

 2. It's emphasised that there are supposed to be two syntaxes.
    It sounds like implementations will support both, and all the
    implementations available to me support only the Lisp-like syntax.
    Indeed, we don't know what the other syntax is yet.

 3. We're told that there will be only one syntax.  We still don't
    know what it is.  Some Dylan people are by now treating "old
    Lispers" with considerable hostility.  Quoting the Dylan book
    on Dylan's relationship to Lisp gets one flamed, even though
    the the issue ought to be largely *semantic* and even though
    Dylan is very close to Scheme+a-CLOS-subset in "language
    space".  It seems like there's been an essentially political
    decision to distance Dylan from "Lisp".    

 4. Time passes.  We still don't know what the syntax is.
    I therefore can't write any Dylan programs.

 5. Eventually the new syntax appears.  There's an implementation
    from CMU (not their main effort) that supports the new syntax,
    so I try it out a bit, but it's not something I could use for
    my work.  There's much discussion of Dylan macros, with more
    hostility towards "Lisp".

 6. Time passes.  Eventually we find out about macros.  There
    still doesn't seem to be a serious Dylan implementation I
    can use.

 7. There's at least one serious implementation, but ...

Ok.  I put in the stuff about hostility because, even though it was
annoying, I still retained an interest in Dylan.  I was hoping Dylan
might save me from having to work in C++.

Unfortunately, so much time passed that Java came along, and Netscape
decided to support it, before I could ever seriously consider using
Dylan.

It's all very well to have a syntax that will appeal to "mainstream"
programmers, or whatever was supposed to happen, but all the syntax-
related stuff (which includes macros, because otherwise Dylan could
have followed Scheme) just took too long.

Dylan might be better than "Lisp" (by which people seemed to really
mean something more like "typical Common Lisp implementations") -
or not - it no longer matters.  I use Common Lisp when I can, Java
when I must, and Dylan never enters the picture.

  Then it's clearly even more pointless to spend any effort "selling"
  anything to you, only one in 6 _billion_ people, such as a much
  better attitude towards "reality" than you currently have, both in
  terms of suckiness and in terms of this mythological _one_ market.

Seriously, I'd love to hear Lisp vs. Dylan comparisons from someone
with Scott's amount of Lisp experience.  I just browsed the subject
tree at Amazon.com, and of the three books listed within "Dylan
Programming," one was a tutorial, one a reference manual, and the
third had the comment, "Incomplete and riddled with errors."  I'd
rather trust the judgement of someone like Scott, who I know *gets*
Lisp.

Scott, I second David Bakhash's interest in more details from you.

- C/C++ programmers work in a mode of thought that is dominated by gnarly
syntax issues and many (in my experience most) do not have enough
experience with other languages or enough education to see beyond the
surface syntax issues.

- Lisp programmers don't think about syntax too much (because Lisp has
almost none), and they tend to have a much deeper understanding of the
semantics of languages and their expression through syntax.

So, given that you must make a choice, and given that you'd like Dylan to
become popular, which group do you deprive of their comfortable syntax?
The group that is terrified of anything that looks too different? Or the
group that can see beyond the surface and understand what a language
really offers?

Of course, that presumes that even WITH infix notation that you could (or
would want to) appeal to C/C++ programmers, and the onslaught of Java has
made that a much more difficult thing to do. With Sun marketing cranking
out lies, backed by millions of $, faster than they can be debunked,
Dylan is left in the position of appealing only to those who can see
through to the underlying semantics.

  Someone just getting the point would be a worthwhile alternative.

/Jon

Dylan will only ever appeal to a small portion of all developers, period.
But not all those of us working with C/C++ are immune to better ideas. So
there ARE some who will look at Dylan, along with Eiffel, Clean, CLOS,
Smalltalk and so on; and even some who will choose Dylan ;-)

The challenge is not to displave Java. (Who would want to have the idiots
of the world join us?) The challenge is to grow a community large enough
for Dylan to prosper.

As for your last comment about the "infantilism" of many developers, I've
long been saying the following:

Like everything else, the talent, education, and dedication of developers
is distributed with a big hump in the middle where the average is. If you
set out to design a language to appeal to the largest number of
developers, you would aim squarely for the average schlepps, and you'd
design Visual BASIC. If you want to actually advance the state of the
art, you have to figure out how to make a go of it when your market is
automatically restricted to the thin slice at the far right edge ;-)

But could you clarify that?

1) you hate Dylan syntax, but still prefer Dylan over CL for other
reasons

2) you prefer Dylan syntax