Open Dylan 2011.1 released

http://opendylan.org/news/2011/12/10/new_release.html

by stesch • 15 years ago

89 41 15 years ago

ya3r• 15 years ago

So does anyone here use Dylan for production?

BruceM8• 15 years ago

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

stesch• 15 years ago

So, maybe next week?

;-)

viandante• 15 years ago

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

protomyth• 15 years ago

Hope it all works for you. It would be great to find someone to convert the documentation to epub and mobi formats.

doublec• 15 years ago

I used functional developer (the commercial product that became open dylan when it was open sourced I believe) to write some freeware GUI apps on Windows a few year ago and it worked well.

jws2• 15 years ago

Back in the '90s I used it for:

• the user interface of a call center scheduling system (my own GUI, built on X11 but it looked and worked a lot like Copland. All layout was constraint based and used lpsolve to figure out where everything went. You should try that sometime, very expressive.)

• a code generator to build sane C++ business objects mapped to a ridiculously normalized physical database. (A 20+ way join for the most common query. Bureaucrats for the project kill!)

• generating dynamic web pages. I made a template based system, very much like PHP, but before PHP was popular, even before I was aware of PHP.

These were all done with "mindy", the CMU dylan interpreter. It was a byte code compiled interpreter, but its compiler was so fast you never noticed the "make". Very fast startup time on the executables as well. You would need a stopwatch with milliseconds to tell the workflow from a "edit-run-repeat" scripting language. Mindy was later abandoned because it didn't have macros and it was deemed too much work to add it.

The rub is, Dylan macros will hurt your head. They are not easy to understand, ludicrously difficult to implement (been there), and I suspect frightening to extract coherent compile time error messages in a large system. I rather liked the language without them, though I can also see the appeal of a language with them (or a similar extension mechanism).

Overall I can recommend it for:

• Good compile time detection of many stupid errors.

• Excellent readability. (It is verbose, e.g. "end method frabulate-widget;", but that is a single keystroke in the emacs mode, the "end whatever the heck I'm in" key.)

• Safe.

• Powerful.

• Multimethods. Dispatch guided by both type and singleton values. Once you get the hang of this, and design your frameworks with it in mind, you will cry when you have to go back to a language without it.

Things which are concerns:

• Multimethods. Once you have built a system that is extended in different places by overriding multi methods, and you ask yourself the question: "What happens when I call XYZ(a,b,c)?" You don't really know where to look to find the answer. It could be anywhere. If you write a library, you can't really know what a call to XYZ(a) will do. It could be overridden in some flakey user code. (there are various sealing declarations to prevent extension on methods and types, but then you lose the advantages of extension)

• Macros. I doubt I could have taught one in twenty of our engineers to be proficient in the macro system. I can see what the language designers were aiming at with it, but I think they over estimated the abilities of the population.

Arelius2• 15 years ago

Regarding the user interface using lpsolve, This sounds very interesting, using a full constraint solver to layout a UI. Are you aware of anything else or public that uses a similar approach?

phzbOx• 15 years ago

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.

BruceM8• 15 years ago

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

Borkdude• 15 years ago

This is kind of why I asked this on StackOverflow: http://stackoverflow.com/questions/8463353/what-makes-open-d... - because the OpenDylan page doesn't really makes it clear to me why I should start doing Dylan.

BruceM8• 15 years ago

I should've thought of this earlier, but we have an entire book online (although it hasn't yet been converted to our new documentation / publishing format): http://opendylan.org/books/dpg/db_1.html

algoregular2• 15 years ago

In this page there are a lot of libraries: http://double.co.nz/dylan/libraries/dylanlibs/index.htm

algoregular2• 15 years ago

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• 15 years ago

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

ldesegur5• 15 years ago

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

sbmassey• 15 years ago

Any plans to get it on macports?

BruceM8• 15 years ago

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

tree_of_item2• 15 years ago

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.

nickik2• 15 years ago

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.

robterrell• 15 years ago

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.

mark_l_watson• 15 years ago

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• 15 years ago

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• 15 years ago

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

ldesegur5• 15 years ago

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_item2• 15 years ago

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.

ldesegur5• 15 years ago

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?

rsheridan6• 15 years ago

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

Surely it supports some other form of concurrency?

ldesegur5• 15 years ago

Every modern flavor of concurrency, be it STM, Actor Model or why not, will abstract threads and locks but won't remove them underneath. There is no magic. So if this Dylan implementation doesn't even support the foundation yet, that doesn't seem likely.

Open Dylan 2011.1 released

Related Stories