
Open Dylan 2011.1 released - stesch
http://opendylan.org/news/2011/12/10/new_release.html
======
phzbOx
Small suggestion: Post some code examples easily accessible from the main
page! I've checked the documentation, the dylan book, the "get started".. I
still have no idea what Dylan looks like. Basically, a quick "Dylan in 5mins"
tour to give me a taste of the neat features.. so it gives me a reason to digg
further in the doc.

~~~
BruceM
There are some examples here (since we didn't actually write the real 'About'
page yet): <http://opendylan.org/about/index.html>

I guess we'll be working on the website a lot in the next couple of days ...

------
robterrell
This is great. I went to a couple of Dylan sessions at WWDC in 1994 and
couldn't wait to try it. It was just one year after Apple and Symantec's
Bedrock fiasco, and it seemed like a huge step in the right direction after
such an enormous misstep.

Dylan and NewtonScript were very exciting languages. I remember many late-
night drunken conversations at WWDC about how we were probably the last
generation of desktop software developers to use C and C++. Boy, were we
wrong.

------
algoregular
Interesting: Converting from Common Lisp to Dylan by Norvig.

norvig.com/ltd/doc/ltd.html -

Also slides from Design Patterns in Dynamic Languages (also by Norvig, in
Dylan) <http://norvig.com/design-patterns/ppframe.htm>

Maxima Cas, that uses Lisp internally, could be translated to Dylan.

~~~
lispm
Given that the translator does not seem to handle CL:DEFMACRO, there is not
much chance to translate anything serious into runnable Dylan code.

~~~
ldesegur
Here is an interesting link about macros in Dylan. IMHO, infix notation makes
it so much harder to implement macros than in CL. [http://www.fun-
principles.info/slot/site/dylan/alpha/openpoi...](http://www.fun-
principles.info/slot/site/dylan/alpha/openpoints/Dylanmacrosareakludge..html)

------
ldesegur
With all due respect for people who've been working on this: Isn't it too late
(by at least 5 years)? What's the point of reviving Dylan if it doesn't bring
something radically new?

And reading the project status: "No support for threads yet"; Than, isn't it
too early to re-release it yet?

Erlang, Clojure, Haskell, and Scala have been fueling my interest in DSL. I
don't see what Dylan would bring to the picture that the other languages
provide already.

~~~
tree_of_item
Too late for what? It's a programming language, not a racehorse.

Dylan offers something very different from the languages you mentioned; even
Clojure, a fellow Lisp, rejects OOP while Dylan embraces it. There's
definitely room for Dylan in the language landscape.

~~~
ldesegur
Too late as being able to bring to the table something that enough developers
would care about so their efforts don't fall quickly into oblivion. I've seen
so many times projects like this trying to resurrect a "passe" technology just
for nostalgia sake. Without a decent community of motivated supporters and a
real solution to current issues developers are facing, I fear that Dylan will
follow the same path. In the specific case of Dylan, I remember that its infix
notation didn't support very well one of best LISP features, namely macros.
And while studying the language in the late 90s, I also learned that David
Moon, one of the original designers, moved to work on something else. I took
it as a sign. Don't get me wrong, I liked Dylan over Common LISP at the time,
becauee they did a great job at simplifying the mess with collections and its
notation would mean greater adoption. That was obviously not enough to
succeed. As for embracing OOP, so does Scala, although at the cost of some
compromises. But at least with Scala, the platform is here to address real
projects. Do you really have the time and energy to start rebuilding all the
libraries that are required to develop anything beside a toy project?

------
ya3r
So does anyone here use Dylan for production?

~~~
BruceM
Honestly, it isn't ready yet. We're catching up as we bring things back up to
date after some years of being left to rest.

We're also not there (yet) with libraries that people commonly expect in this
day and age.

We were hoping this would be a lower profile release as we learn how to make a
new release and get our systems automation in place (as well as improving
platform support).

~~~
viandante
As unfortunately is not low profile any more, could you guys make some main
point on why one should adopt dylan? Maybe a comparison with Python/Ruby etc.?

~~~
cgay
The Dylan language spec has amazingly few edge cases. It allows a continuum of
dynamic -> static typing and a range of functional <-> OO. With the right set
of libraries it could be great in the scripting space as Python, but is also
designed for building large systems that run fast.

------
mark_l_watson
Isn't this a matter of now it is too late? Today, I would consider Clojure,
Scheme (in particular Rackit), (J)Ruby, and maybe Go as good alternative
languages for production use.

I was also excited with Dylan and played with it a _long_ _time_ _ago_. I
think it was about 20 years ago that I had lunch with Larry Tesler (at Apple
he worked on the Newton, a general Dylan evangelist) at a genetic programming
symposium at Stanford. He tried to talk me into basically rewriting my first
Springer-Verlag Common Lisp book to use Dylan. I thought about it, but decided
not to.

~~~
gecko
Let's skip past whether OpenDylan is ready for production use ("No") and
pretend it is.

I'd absolutely use Dylan over those languages in at least some contexts.

Dylan hits a sweet spot between performance and flexibility. Even the existing
OpenDylan ought to perform better than most of the languages you named, for
example. But the level of flexibility is far greater: you get full-blown
macros (Clojure, Common Lisp, Scheme), optional static typing (Racket), a
really pleasant syntax that doesn't make me use a pile of parentheses, has a
great object system based on multiple dispatch...

There's an awful lot to love there. The only reason I don't use it is because
the compiler implementations have historically been very poor, and the library
compatibility worse. If this project goes well, I'd definitely take another
look.

~~~
hannesm
Well, let's face it: There's only one compiler actively maintained. And its
license is MIT!

NB: written in Dylan itself!

This even has an IDE (on Windows only), but has some problems with error
reporting, producing too much output while compiling and a limited set of
libraries.

The only way to improve that is to try it out, and contribute libraries!

I'm happy to look into compiler bugs - that is something I'm used to do over
the last years ;)

~~~
donald_draper
Given the rather small community size (from what I know), wouldn't it be the
best survival technique to port the compiler to JVM, to have at least some
usable real world libraries at hand ? I can hardly imagine anyone starting to
use a complex typed system like that without reliable and proven libraries
from the real world. It just wouldn't be worth the effort of playing around
with it.

------
sbmassey
Any plans to get it on macports?

~~~
BruceM
Would you be interested in bringing this up on our mailing list? That probably
warrants more / broader discussion.

------
nickik
I have been intrested in dylan for some time know and its fantastic to see
some progress. I think dylan has great potential to become the nearly as fast
as C dynamic language. The Compiler and GC were made by people who really knew
what they were doing. Would be cool to see some new benchmarks.

------
tree_of_item
Very cool, was just reading about Dylan and the Newton last week, in light of
the recent buzz about HyperCard. I'll definitely play around with this a bit,
especially due to the Emacs integration.

