

Thoughts on a New Dylan Ecosystem - BruceM
http://dylanfoundry.org/2013/11/12/thoughts-on-a-new-dylan-ecosystem/

======
rayiner
I've always lamented that Ruby and the like caught on when Dylan didn't. At a
time when most dynamic languages are still struggling without multi-threading
or generational garbage collection (or hell, even correct lexical scoping!),
Dylan has had a very sophisticated implementation for 15 years now. Open Dylan
has native compilation, type inference, native threads, a sophisticated
garbage collector, etc. The other side of the coin is, unfortunately, that
it's hard to maintain such a sophisticated implementation without substantial
manpower. The compiler is 100kloc of well-written but complex and dense code,
and the runtime library is quite complex as well. That said, the Dylan Hackers
are doing some really interesting work, e.g. building an LLVM backend for the
compiler, so if you have an interest in the subject it's worth checking out.

~~~
pjmlp
Yeah, if Apple hadn't ditched it, maybe it would even be Mac OS X main
language instead of Objective-C.

Well, one can always dream.

~~~
mpweiher
Mac OS X's main language is Objective-C because it is essentially NeXTStep 5.0
and the basic libraries were mature Objective-C libraries. I don't see how
Dylan would have entered the picture.

~~~
pjmlp
I know Objective-C since the NeXT days, even before Apple dreamed about buying
NeXT.

As for Dylan, it was going to be Newton's application language, before the
project was canned.

So playing "What If" scenarios, if the language stayed in Apple's control, and
if NeXT was still bought, Dylan might have had a life in whatever form Mac OS
X would have shaped itself.

Although this is a very unlikely scenario, Apple was actually not that sure
that Objective-C would take off as it did.

This is why there was a Java/Cocoa bridge with first class treatment on the
early days of Mac OS X, before focusing only on Objective-C.

------
coolsunglasses
Dylan is a great language but I managed to transition from Common Lisp ->
Python -> Clojure -> Haskell without ever really having sufficiently good
cause to use it.

I wish the hackers working on Dylan the best, but it's a hard sell with the
current design. Needs something to differentiate itself (from my POV).

------
skittles
I'd like to have a Dylan dialect based upon Clojure concepts (the Sequence
abstraction and immutable collections being two that come to mind). It would
also need Clojure's idea of being a hosted language to get past the lack of
libraries.

~~~
graue
As a Clojurist not familiar with Dylan, that sounds awesome, but then it also
just sounds like Clojure. What does Dylan add to the mix?

I'm reading their "Why Dylan?" page:

[http://opendylan.org/documentation/intro-dylan/why-
dylan.htm...](http://opendylan.org/documentation/intro-dylan/why-dylan.html)

and I don't see anything that makes me want to go run and install it. I'm
already used to dynamic, garbage-collected, infix programming languages that
can be used in a functional style. Heck, JavaScript is one. Integers and
strings are objects, cool, but how does that help me prototype faster or write
more maintainable code?

~~~
BruceM
You're missing the optional static typing, the multimethods, the Common Lisp-
style condition system, the ability to produce native and efficient
executables ...

~~~
graue
> _optional static typing_

[https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)

> _multimethods_

[http://clojure.org/multimethods](http://clojure.org/multimethods) \- also,
arguably better for many use cases:
[http://clojure.org/protocols](http://clojure.org/protocols)

> _native and efficient executables_

Clojure performs much better than popular web development language
implementations like Python, Ruby or Node.js. See
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)
People have found it performant on harder problems:
[http://clojurefun.wordpress.com/2013/03/07/achieving-
awesome...](http://clojurefun.wordpress.com/2013/03/07/achieving-awesome-
numerical-performance-in-clojure/) And it's possible to produce executables
that depend only on the JVM, which is just as easy as fully-native for
deployment.

I grant you the one about the Common Lisp condition system. I wasn't familiar,
but reading about it
([http://c2.com/cgi/wiki?CommonLispConditionSystem](http://c2.com/cgi/wiki?CommonLispConditionSystem)),
it does look intriguing. Apparently something inspired by it is available as a
Clojure library, but the last commit was 10 months ago, and I hadn't heard of
it till now:
[https://github.com/scgilardi/slingshot](https://github.com/scgilardi/slingshot)

------
codygman
Am I incorrect in assuming that Dylan is a faster and better designed ruby? At
first glance that is what it appears to be.

~~~
rayiner
Dylan and Ruby aren't that similar, except to the extent of their use of "end"
as a delimiter (inherited from Algol through Pascal). In Dylan, methods do not
belong to objects, and can dispatch on more than one of their parameters.
Ruby, on the other hand, uses more traditional Smalltalk-style OOP.

Dylan isn't necessarily better designed than Ruby (though I think it is), but
rather it's less eccentric than Ruby and more targeted at static compilation.
It has type declarations the compiler can use to eliminate dynamic dispatch,
it has proper lexical scoping allowing variables to be allocated to registers,
etc.

~~~
codygman
Thanks for the explanation! I also noticed the static typing after I posted
this.

