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.
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
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.
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.
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.
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?
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.
The thread support depends on the compiler backend. It works on 32 bit FreeBSD, Linux and Windows. The thread support in the C backend is broken, but it nearly fixed and will be in place for the next release, bringing the thread support to OS X and 64 bit Linux / FreeBSD.
I would be curious to find out if you guys ever consider LLVM since you mentioned backend work. How much work do you think it would take to switch your C backend to LLVM?
We're actually working on replacing the HARP native backend with one based on LLVM. The HARP backend is currently x86 only and is what we use on Windows, Linux and FreeBSD. (But not OS X, there we use the C backend for both 32 and 64 bit.)
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).
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.?
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.
I have been intressted in dylan for some time. Here is my take on it. Dylan is just an awesome language, you will have to learn some dylan to find out if you agree. It has great potential to be a dynamic language that is really really fast, the compiler and gc are already really good. Its a really intressting project to hack on, the compiler for example is written in dylan itself.
Its not ready to go into production use but if you want an awesome opensource project with loads of potential to hack on dylan might be just the thing.
We dug up the original Framemaker files from the 90s and have been converting them to be processed by Sphinx (http://sphinx.pocoo.org/) into various formats. That should start to be included with the next release.
• 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.
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?
No, I've not seen anyone else doing it. For anyone trying it, I can recall…
• It was fast enough to be undetectable. This was in the days of 50MHz 486DX chips and struggling to fit on a 16MB machine. It used to do the solve on every window display. I think that the system of equations was always easy for the algorithm. (By contrast, the call center work could run into the minutes to solve.)
• lpsolve is more complicated and capable now, but still LGPL.
• As we move to retina displays, the need for integer variables goes away and things get easier. Rounding becomes acceptable.
• Alignment of elements in unrelated boxes was trivial. Rather like designers use grids to enforce order on disparate elements. You could just say "the left edge of this checkbox lines up with the left edge of the section title"
• Somewhere along the years I've misplaced the code.
• I used data structures to express the relationships between elements. This would have be an outstanding use for macros in Dylan to add a syntax for describing user interfaces, but the mindy interpreter didn't support macros.
• It is especially handy in themeable systems, which were all the new thing at the time, since your elements could have different dimensions as needed. I had both Copland and a slightly more compact traditional X11 look.
• Not terribly related but from the same project: if you are using a blocking garbage collector on a GUI, if you can tell when garbage collection will be required soon, then it works well to force a garbage collection at times when the user will not notice it. For instance, after they click an action that takes time you can sneak in a collection and they'll never know. What you want to avoid is something like a menu coming halfway down then a collection triggering.
That's really cool, I've been interested in using a constraint solver to solve some unrelated problems, but not considered doing it for UI.
One problem I see is that much modern UI is being done on mobile devices, including the ipod which afaik have licenses that are incompatible with the LGPL, and there doesn't seem to be a more liberally licensed constraint solver.
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.
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 longtimeago. 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.
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.
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 ;)
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.
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.
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.
