It's a crying shame that Dylan did not become the systems language of Apple's new era — it's really quite lovely. Much nicer than Objective C, though undoubtedly trickier to compile efficiently.
Objective-C had the advantage that it worked while Dylan struggled to get an implementation that was acceptable. It would have been interesting if it had made it onto the Newton or got a compiler that could do PowerPC acceptably.
Deterministic realtime attribute was required condition on Apple product, and any GC based language was not acceptable at the time. But sometimes I think they could solve the issue if they could research longer.
A lot of open source projects are quite human resource constrained. I see two solutions to this problem:
- universal citizen revenue, so that programmers who want to work on free software or open source may do it more easily.
- let's reduce the ecosystem diversity. I'd move to drop all those useless fancy languages, and let's all concentrate on Common Lisp, developping tools and libraries, perfecting the implementations, etc.
(No need to argue, I know the former will occur sooner).
In the mid-90s I did some playing round with something called MINDY from Carnegie Mellon. It was (IIRC) a Dylan interpreter (the acronym was 'MINDY Is Not Dylan Yet') and was very interesting both to experiment with Dylan and also to see how MINDY itself was implemented.
As I remember, a cool thing about the Dylan concept was that it had a sliding scale of dynamic-ness - in other words you could start off being quite relaxed about types but, where needed, you could narrow down the types, seal generic methods etc. and the compiler would then be able to optimise better, for example by avoiding dynamic dispatch if it could prove it knew the specific method at compile time.
Mindy was used to bootstrap Gwydion Dylan, a Dylan compiler implementation. This was the main open source Dylan implementation for quite some time until Functional Objects (which obtained the code and rights from Harlequin when they went out of the language business) open sourced their implementation which is now 'Open Dylan'.
Functional Developer (What was Harelequin Dylan) was nice. The editor would syntax highlight the code based on the optimization level. In this way you could look at a method call and see if it was inlined or not and decide whether to seal functions or classes to improve performance.
Another interesting feature was the editor was written in Dylan (using a framework called Deuce). This was emacs-like and had features like virtual sections in a buffer that could each be mapped to a different file on disk. This allowed viewing in a single editor pane the implementations of all methods of a generic function even if they crossed multiple files. This could also be edited as if it was a single file.
ah, Dylan! I remember from far 2005 a team called "Dylan Hackers" who earned both the judges' prize and the second prize at the ICFP Contest (cop & robbers), http://icfpc.plt-scheme.org/.
and IIRC, in that 2005 cops-and-robbers game, the game rules invited complex strategies, but the game wasn't balanced, so degenerate strategies dominated, and the competitiveness was over details of implementation.
When reading about Dylan, it seems one of it's main selling points is "everything is an object." But nowadays, that's true in many other dynamic languages like Python, Ruby and Clojure. Macros are everywhere and you can even add them to Python if you want to using third party modules. Though I've never felt the need because Python's syntax is excellent as it is.
For me it is very hard to see what Dylan brings to the table. It's nieche is already filled by more popular languages.
I understand where your coming from. For me, the selling point of Dylan is that it gives me many of the things I like from dynamic languages, like Ruby, but also gives me static typing (and type inference), relatively high performance and a compiler that catches a lot of problems before I run my code.
Different people like different things, and while I love Ruby, static typing does catch a lot of problems earlier on.
Apple designed it as a replacement for languages like C++, now Objective-C, Java, C#. Stuff like Apple Keynote, Apple Pages, Apple's Xcode, Apple Mail, Contacts, Calendar, and the Apps on mobile devices like the iPhone and iPad would have been written in Dylan. Applications which Apple now writes in Objective-C. Apple already had an Operating System for an ARM-based computer written in an early version of Dylan (with some help of a C++ based kernel). It also tried to develop some Mac-based prototype applications: an interface builder and I think there was a 'Finder' written in Dylan.
I have a branch that will soon allow using either Boehm or MPS on the various backends. That'll probably be the case for the LLVM backend as well.
Part of the reason that I'm doing that is to help gather some performance data on the MPS. (I'm actually doing that Dylan runtime work under contract.)
Well, none of the things listed in our current call for help are issues with modifying the language. In fact, we spend a lot of time on improving things like the tools, libraries and documentation.
Lately, we've made our test framework integrate well with Jenkins (using Surefire output) and have been getting more and more of our libraries and tests building via Jenkins.
We've also been pulling out some chunks of code and turning them into useful and usable libraries. Our binary data library is an example of this (http://opendylan.org/documentation/binary-data/).
And one of our hackers has spent a large amount of time this week cleaning up and re-working a tool that he had for visualizing the compiler's optimizer. This will let us better perform bugfixes, ensure that the transforms are operating correctly.
We do have areas where we intend to improve the language. There are some extensions to the type system that we're looking at, improving Unicode support, and improving our numerics. But these aren't our main or daily areas of focus.
We want to bring our IDE to non-Windows platforms, we're improving our compiler backends, improving the GC integration, working on editor integration with CodeMirror, vim, emacs, and IntelliJ.
[+] [-] gcv|12 years ago|reply
[+] [-] BruceM|12 years ago|reply
But at the time, the Apple Dylan IDE was pretty slow and buggy. It is amazing what a few years make much more feasible!
[+] [-] protomyth|12 years ago|reply
[+] [-] eonil|12 years ago|reply
[+] [-] gress|12 years ago|reply
[+] [-] informatimago|12 years ago|reply
- universal citizen revenue, so that programmers who want to work on free software or open source may do it more easily.
- let's reduce the ecosystem diversity. I'd move to drop all those useless fancy languages, and let's all concentrate on Common Lisp, developping tools and libraries, perfecting the implementations, etc.
(No need to argue, I know the former will occur sooner).
[+] [-] peterhull90|12 years ago|reply
[+] [-] yetfeo|12 years ago|reply
Functional Developer (What was Harelequin Dylan) was nice. The editor would syntax highlight the code based on the optimization level. In this way you could look at a method call and see if it was inlined or not and decide whether to seal functions or classes to improve performance.
Another interesting feature was the editor was written in Dylan (using a framework called Deuce). This was emacs-like and had features like virtual sections in a buffer that could each be mapped to a different file on disk. This allowed viewing in a single editor pane the implementations of all methods of a generic function even if they crossed multiple files. This could also be edited as if it was a single file.
[+] [-] gghh|12 years ago|reply
Here the blog post describing their entry: http://www.hoult.org/bruce/icfp2005/
[+] [-] gohrt|12 years ago|reply
In 2001, the Dlyan Hackers placed #2, but the #1 team had a team member named Dylan (Thurston)
http://developers.slashdot.org/story/01/09/07/0131231/icfp-2...
and IIRC, in that 2005 cops-and-robbers game, the game rules invited complex strategies, but the game wasn't balanced, so degenerate strategies dominated, and the competitiveness was over details of implementation.
[+] [-] yetfeo|12 years ago|reply
[+] [-] bjourne|12 years ago|reply
For me it is very hard to see what Dylan brings to the table. It's nieche is already filled by more popular languages.
[+] [-] BruceM|12 years ago|reply
It is highly readable. And you can use '!' and '?' in names!
An optimized implementation of multimethods is always nice.
The ability to apply optional static typing is great for putting stuff into production and feeling good about it.
Having multiple return values, keyword arguments and rest arguments is nice (and yes, Python can do much of that).
[+] [-] sspiff|12 years ago|reply
Different people like different things, and while I love Ruby, static typing does catch a lot of problems earlier on.
[+] [-] lispm|12 years ago|reply
[+] [-] AndreasFrom|12 years ago|reply
[+] [-] pjmlp|12 years ago|reply
A dynamic language with native code compiler and language features suitable for both application and systems programming.
Plus being a Lisp like language with a more friendly syntax for those scared of parenthesis.
[+] [-] sspiff|12 years ago|reply
[+] [-] nickik|12 years ago|reply
- What GC will the LLVM backend use?
- Is there any data an the performance of the MPS?
[+] [-] BruceM|12 years ago|reply
I have a branch that will soon allow using either Boehm or MPS on the various backends. That'll probably be the case for the LLVM backend as well.
Part of the reason that I'm doing that is to help gather some performance data on the MPS. (I'm actually doing that Dylan runtime work under contract.)
[+] [-] CmonDev|12 years ago|reply
[+] [-] BruceM|12 years ago|reply
Lately, we've made our test framework integrate well with Jenkins (using Surefire output) and have been getting more and more of our libraries and tests building via Jenkins.
We've also been pulling out some chunks of code and turning them into useful and usable libraries. Our binary data library is an example of this (http://opendylan.org/documentation/binary-data/).
And one of our hackers has spent a large amount of time this week cleaning up and re-working a tool that he had for visualizing the compiler's optimizer. This will let us better perform bugfixes, ensure that the transforms are operating correctly.
We do have areas where we intend to improve the language. There are some extensions to the type system that we're looking at, improving Unicode support, and improving our numerics. But these aren't our main or daily areas of focus.
We want to bring our IDE to non-Windows platforms, we're improving our compiler backends, improving the GC integration, working on editor integration with CodeMirror, vim, emacs, and IntelliJ.
[+] [-] kozhevnikov|12 years ago|reply
[1] http://channel9.msdn.com/blogs/pdc2008/tl16 @ 1h1m
[+] [-] TempleOSV2|12 years ago|reply
[deleted]