Thoughts on a New Dylan Ecosystem | Hacker News Reader

Thoughts on a New Dylan Ecosystem

dylanfoundry.org

74 pointsBruceM16 comments

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.

I always figured it sat in a bad place, at least in terms of visibility, because Lisp hackers knew about it but mostly viewed it as an unnecessary compromise (why use Dylan when you can use CL?), whereas people outside Lisp either didn't know about it, or didn't understand what all the fuss was about. Which is too bad because it's a great language.

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.

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.

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.

Also: generic functions. And hygienic macros. I miss those in ruby.

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).

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.

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...

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?

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

> optional static typing

https://github.com/clojure/core.typed

> multimethods

http://clojure.org/multimethods - also, arguably better for many use cases: 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/ People have found it performant on harder problems: http://clojurefun.wordpress.com/2013/03/07/achieving-awesome... 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), 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

"It's not s-expr based".

For some us, sexps are just not mentally parsed.

We'd love to have an implementation of the functional datastructures in Dylan. This needn't even change the language definition as they could happen as a library. We just need a volunteer.

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

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.

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

Reply on news.ycombinator.com