Geoffrey P. Clements

People who have trouble conceptualizing have to categorize things before they can grasp a difficult comparison. Currently, people are categorizing Dylan as a Lisp variant and therefore base their comments and judgements on how Dylan compares to Common Lisp.
[...]

I believe that these language comparisons are a bad thing. They stiffle language development and cripple new ideas.
[...]

Folks, lets try out Dylan and see if we like it. If not, it will go away. If we do we'll have the advantage of using a dynamic language over our competitors who use a static languages.

Raffel Cavallaro

The Holy Grail of Dylan was to create a language, runtime, and compiler that incorporated the best aspects of Common Lisp/Scheme (dynamism - interacting with and/or modifying a running application, generic functions, closures, macros) and go beyond them (OO from the ground up - e.g., writing methods that specialize on individual instances of built-in classes, macros that are hygenic - unlike Common Lisp macros), all while generating compiled code that is as fast as the fastest statically compiled languages like C, or Fortran.

Many such people try a simple "Hello, World" app and then give up. If that were the only way to judge development software, we wouldn't even be using C.

It becomes obvious after some use that the Dylan syntax was not designed for short definitions and toy programs. Rather, it's meant for large blocks of code with really-long- variable-names. And after a while of writing large blocks of code with really-long-variable-names, one begins to appreciate the syntax the way it is.