Re: [dylan] The Future of Dylan: Why are we here?

Hello,

I've been learning Dylan for the last two weeks, which is a rather
short time. I already learned some fundamentals, but there are many
things I don't know. However, this thread is being discussed right
now, and my response would be of much less use a few months in the
future, so I decided to share my initial impressions of Dylan anyway.
The things I like in Dylan, in no particular order:

Performance. I have no data about "real world" performance obviously,
but my simple scripts start up quickly and execute faster than
equivalent Python scripts. The "start up" part is important: there are
languages which are "generally" fast enough, but which take ages to
initialize and start doing any real work. One especially painful
example would be Clojure, which would be my favourite Lisp already if
it started up faster.

C-ffi. Easy interop with C is important, as it lets me use already
existing libraries instead of writing them from scratch. I didn't look
at Melange yet, but even the core c-ffi forms are nice enough.

Module/library system. It's somewhat limited (no cycles) and it could
use some extending, but it solves both modularity and access control
issues cleanly and elegantly. The problem with it is that it incurs
non-trivial overhead when used outside of IDE. For larger projects
that's a non-issue at all, but for simple scripts it can be painful. I
think adding some metadata to definitions in *.dylan files and then
generating library and module definition from this could help here.

Multiple dispatch. I like how it focuses on operations (verbs) instead
of on things (nouns) - reminds me of algebraic data types and pattern
matching in Haskell, OCaml and the like.

Optional static typing. It reminds me of Erlang Dialyzer, especially
the fact that the "types" are just normal expressions. I don't believe
in exclusively statically typed programming (in a sound type system),
but I do appreciate extra correctness guarantees static types bring.
I'd probably like to see some support for contracts (like in Racket,
where they are much more advanced than in Eiffel), some type system
extensions (parametric types, covariance and contravariance control,
function types) and some kind of type inference.

Macros. I haven't used them yet, but AST based macros are just too
good to leave them out. I like that they are hygienic by default and
pattern based, they remind me of syntax-rules macros in Scheme. As for
errors and problems they can generate, there was much work done by the
Racket people (for example http://www.barzilay.org/misc/stxparam.pdf),
which could be of use to Dylan.

Conditions and blocks. Blocks are actually call/ec
(call-with-escape-continuation) and I like how they are able to
express quite a few common control flow devices with one simple
concept and syntax. I didn't work with conditions and restarts very
much yet, but I have a pretty good understanding of how they work and
I like them much better than conventional exceptions. In general full
call/cc or delimited continuations are not that important to have, as
long as most of their use-cases are covered by other constructs.

I like high regularity of syntax, but I'd look into inserting
semicolons automatically. It's admittedly a can of worms and it can
backfire (like in JS), but if done right it would make working with
the language more pleasant. Other than this there is nothing wrong
with it and I don't think it should be changed.

That's it at the moment, I will certainly have more to say about Dylan
in the future, as I learn more of it.

Best regards,
Piotr Klibert