* Dylan was designed at Apple and then later a partnership of Apple, CMU and Harlequin in the 1990s
* Harlequin's implementation of Dylan was spun off to another company when they failed. It was then called Functional Developer.
* Functional Developer was open sourced in 2004 as Open Dylan.
Since then, the development was moving rather slowly, the documentation was still in the 1996-era Framemaker documents, etc.
I decided to help really revive it and we've since done the 2011.1 and 2012.1 releases and are working on the 2013.1 release now. The documentation has been brought forward into the modern era, the website updated, new libraries are being written, etc. I've spent a large amount of time over the past 15 months or so to make a lot of that happen.
As for strengths:
* A pretty great compiler that can do a lot of optimizations.
* Multiple dispatch. As StefanKarpinski says in another comment, it is a great thing.
* A condition system like Common Lisp.
* Everything is an object, so multiple dispatch integrates very cleanly.
* I like the macro system. It is more like syntax-case than full macros, but I find it pretty useful.
* Everything is pretty clean and consistent. There aren't a lot of strange edge cases and the code is really pretty readable.
* The compilation model lets a lot of existing tools work with the compiled code. I'm able to use Instruments on OS X, perf on Linux, etc to analyze performance and so on.
* We have a lot of documentation as a result of having formerly been an expensive commercial product.
Weaknesses:
* Small community.
* Some things are still written with 1990s expectations and need some love, like atomic operations and some aspects of the numerical model.
* Some other nits that would get ironed out pretty quickly with a larger community.
* Marketing hangover from the 1990s in terms of people thinking Dylan is old, dead, etc. We've contemplated just changing the name on a future release to make it more clear that we're moving forward.
As for Lisps ... SBCL and Clozure CL are great implementations. :)
With under a week of work, we could probably be up and running on iOS with Open Dylan. I even have the start of some aspects of a Dylan / Objective-C bridge, but that needs a fair bit more work. Talk to us if you're interested.
* Dylan was designed at Apple and then later a partnership of Apple, CMU and Harlequin in the 1990s
* Harlequin's implementation of Dylan was spun off to another company when they failed. It was then called Functional Developer.
* Functional Developer was open sourced in 2004 as Open Dylan.
Since then, the development was moving rather slowly, the documentation was still in the 1996-era Framemaker documents, etc.
I decided to help really revive it and we've since done the 2011.1 and 2012.1 releases and are working on the 2013.1 release now. The documentation has been brought forward into the modern era, the website updated, new libraries are being written, etc. I've spent a large amount of time over the past 15 months or so to make a lot of that happen.
As for strengths:
* A pretty great compiler that can do a lot of optimizations.
* Multiple dispatch. As StefanKarpinski says in another comment, it is a great thing.
* A condition system like Common Lisp.
* Everything is an object, so multiple dispatch integrates very cleanly.
* I like the macro system. It is more like syntax-case than full macros, but I find it pretty useful.
* Everything is pretty clean and consistent. There aren't a lot of strange edge cases and the code is really pretty readable.
* Multiple return values, keyword arguments, 'rest' arguments.
* Compilation to an efficient executable.
* The compilation model lets a lot of existing tools work with the compiled code. I'm able to use Instruments on OS X, perf on Linux, etc to analyze performance and so on.
* We have a lot of documentation as a result of having formerly been an expensive commercial product.
Weaknesses:
* Small community.
* Some things are still written with 1990s expectations and need some love, like atomic operations and some aspects of the numerical model.
* Some other nits that would get ironed out pretty quickly with a larger community.
* Marketing hangover from the 1990s in terms of people thinking Dylan is old, dead, etc. We've contemplated just changing the name on a future release to make it more clear that we're moving forward.
As for Lisps ... SBCL and Clozure CL are great implementations. :)