“Dylan is an advanced, object-oriented, dynamic language which supports the rapid development of programs. When needed, the programmer can later optimize programs for more efficient execution by supplying type information to the compiler. Nearly all entities in Dylan (including functions, classes, and basic data types such as integers) are first class objects. Additionally Dylan supports multiple inheritance, polymorphism, multiple dispatch, and many other advanced features.”
A group programming in Dylan won 2nd place and the Judges Prize at the 2005 ICFP Programming Contest. So apparently it’s effective.
It’s really a Lisp (or more accurately a superset of Scheme) with infix notation (traditional C-style notation).
Really, although Dylan doesn’t get a lot of attention, it’s a very powerful language and many people feel that coupled with generic functions and multi methods, it is a more natural way of doing object-oriented programming.
Ruby programmers might be especially interested in its feel.
… since Bob Dylan’s “Maggie’s Farm”
Damn! This comes at a very bad time for me. I still have to learn C++, Ruby and Ocaml better. Don’t they know how much I have to restrain myself to not search for a good tutorial now? I’ve already installed Dylan so I’ve failed at restraining myself that much already.
join #dylan on irc.freenode.net
A better link that tells more about OpenDylan vs Gwydion Dylan is here:
http://www.opendylan.org/downloading.phtml.
Personally, I’d rather use common lisp. Why reimplement lisp just so you can have infix notation? Looks nice enough though. I had thought Dylan was dead.
I Can’t keep track of Uber OOP languages anymore… C++, Java, Python, Ruby…and now this, among so many others…
So much to learn and so very little time.
Do they have a Roadmap? I look by of and on but I never know whats up untill its in my face.
First off there is only one Dylan now. OpenDylan and Gwydion Dylan are both the same as far as practically concerned.
Second, until you smug lisp weenies understand that syntax matters then there is no hope for you.
Well, they are separate implementations, so they aren’t the same as is practically concerned (as far as I’m concerned). And I agree that syntax matters. That’s why I prefer lisp! Clean and elegant!
“Second, until you smug lisp weenies understand that syntax matters then there is no hope for you.”
We understand. Come over to comp.lang.lisp for a more lengthy explanation. Or just blow it off because you like doing NIH.
Hey! I’m a Smug Lisp Weenie
I’m also a big fan of Dylan. It’s a great language, and very clean on an intellectual level. However, I think I’d give Lisp a slight edge for the sheer power of its macro functionality. Common Lisp is also a bit more willing to go out on a ledge and include features that are not clean at an intellectual level (2 namespaces, for example), but work in practical programming.
It looks like haskell and it’s got an incredibly verbose syntax–eww. I’m just glad people are straying away from the C++/Java model of OOP and more towards a somewhat procedural OOP, hopefully they’ll make to jump to pure procedural with the release of a decent procedural language.
-bytecoder
Do you know a decent procedural language? To me they all show their age.
I don’t know of any right now; that doesn’t mean there can’t be one, though. This is probably the biggest thing that bothers me about you people–you compare a feature-less procedural language (C, C++, etc) to a relatively feature-rich OOP language (C++, Java) and proclaim that procedural sucks.
-bytecoder
No I don’t! Thanks for generalizing! I’m actually searching for a good and modern procedural (and modular) programming language. I want some functional in it too, but dirty functional. I don’t want to be nailed down on the no side effects thing. I want to pass functions without using function pointers, and I want to iterate over arrays without having to write int i = 0; i < 100; i++.
Oh, sorry, thought you were arguing against procedural
Python is an ok procedural language, but it still lacks quite a few nice features. I’m actually working on an advanced procedural programming language, http://67.175.144.120/~bytecoder/syntax.boa shows the general syntax/features.
-bytecoder
If you’re going to classify Python as a procedural language then basically any imperative language with first-class functions should do you.
“Python is an ok procedural language, but it still lacks quite a few nice features. I’m actually working on an advanced procedural programming language, http://67.175.144.120/~bytecoder/syntax.boa shows the general syntax/features.”
This looks like 90% python to me. There are some improvements in the direction of stronger typing. I hope you started with python and didn’t code this from scratch. Have you suggested these kinds of features to the python team?
So your OS will feature an impressive python-like API. This is good. This past summer I made it a point to write three different projects, in each of Perl, Python, and Ruby. IMHO, Python comes out on top, although Ruby has some nice syntax in places.
Lisp! Years of C++ have made my programming style pretty damn procedural, and Common Lisp lets me write code as procedurally as I want, while taking baby steps towards functional programming.
It doesn’t look anything like Haskell. It looks much more like a Wirth language. It’s behavior is much more like a scheme with a limited form of CLOS.
I’m not sure how exactly you’re using the term ‘procedural’ here.
It doesn’t look anything like Haskell. It looks much more like a Wirth language. It’s behavior is much more like a scheme with a limited form of CLOS.
Well, to me it looks very much like haskell’s type declarations.
-bytecoder
Other than that they both use double colons (for completely different things) what about them suggests to you any similarity at all?
The verbosity of the syntax and, as I already stated, the type declarations for, e.g., functions.
-bytecoder
I was specifically asking you why you thought that the type declarations were similar.
http://svn.openfoundry.org/pugs/src/Pugs/Eval.hs
http://www.opendylan.org/cgi-bin/viewcvs.cgi/branches/GD_2_4/src/du…
> No I don’t! Thanks for generalizing! I’m actually searching for a good and modern procedural (and modular) programming language. I want some functional in it too, but dirty functional. I don’t want to be nailed down on the no side effects thing. I want to pass functions without using function pointers, and I want to iterate over arrays without having to write int i = 0; i < 100; i++.
Python. Scheme.
Quick History Lesson from a Dylan fan:
Dylan the language was invented by Andrew Shalit and friends at Apple in 1993 as part of the Newton project. Basically, they got a bunch of Lisp hackers and asked them to come up with an awesome language. Originally, the language was prefix-syntax like Lisp, but they switched to infix-syntax to make the mainstream crowd happier. The basic goals of the language were to create something with the power and dynamism of Common Lisp, except modernized, regularized, cleaned up, and designed to allow creation of fast native-code compilers.
Opan Dylan is the new name of the Functional Objects Dylan environment. This compiler was originally developed at Harlequin, and the IP was acquired by Functional Objects, a company created out of former Harlequin employees, when it was bought out by Global Graphics. Functional Objects open-sourced the code a year or so ago, and the Gwydion folks have been working on it since then to get it in shape for a public release.
The Gwydion Dylan project was a group that was started to take over development of CMU’s Dylan compiler. This compiler was the product of the same team that did the CMUCL Lisp Compiler. Now, they’ve inherited the Functional Developer source tree too.
The Open Dylan environment consists of a compiler, an IDE, and a siginficant set of libraries, including things like a CORBA ORB. Because of the small size of the Dylan community, things like the threads library and GUI library are basically standardized. These libraries come from both the original Functional Objects tree, and from the Gwydion project’s source tree. Work is ongoing to get a single set of libraries that runs on both compilers.
The compilers themselves are both pretty good, with d2c being more portable and perhaps more optimizing, but Open Dylan’s being faster and having a more sophisticated garbage collector. The Open Dylan IDE is pretty kick-ass, with incredible support for debugging, but is Windows-only for now.
It should be pointed out that, on Windows, Open Dylan has a truely excellent GUI library (DUIM) that allows for native-looking applications. The IDE is also fast and responsive, putting to rest the myth that garbage collected dynamic-languages are “too slow” for GUI apps.
If anything, the feel of Dylan is more procedural than C++, Java, C# or a whole bunch of languages because CLOS doesn’t mix data with methods. So it “almost” feels like structs and functions (c-style). But at the same time it’s actually more “OO” than than most languages (mentioned above) with multi-methods, generic functions, good macro facilities (not as uber-advanced as Lisp).
A lot of the verbosity is optional, given that type declaration is option (most of the time I guess), but I’ll agree even without the type declarations it’s still too verbose. What’s up with let for local variables? Why do you need that? And too many semi-colons.
But Dylan also has the advantage of that it’s fast. It’s compiled down to exe and you can add back in types as you identify hotspots which dylan will identify for you. Hell the compiler they just put out will tell you how much of the code it could optimize.
I’ve also heard that Dylan lends itself to incremental development quite nicely even though it gets compiled down to exe.
Apple basically left it out to dry once the NeXT crew came aboard and objective-c invaded. I guess they decided to give up some power for the better compatibility with C…who knows.
Apple abandoned Dylan development before NeXT was in the picture. It’s a shame because it’s a much more sophisticated language than Objective-C, but its syntax what it is, it likely wouldn’t be particularly popular with C programmers anyway.
“It’s a shame because it’s a much more sophisticated language than Objective-C, but its syntax what it is, it likely wouldn’t be particularly popular with C programmers anyway.”
So once again an Algol language holds back computer progress. At least we had the sense to leave COBOL behind. Shame we can’t do the same with C/C++.
Since we’re on the subject of OO and functional languages, a very cool up and coming language is slate. Check it out at slate.tunes.org. Syntactically it looks a lot like smalltalk, but it’s also quite similar to CLOS in terms of OO.
REBOL is also a great language, not functional, but very OO capable, with a brief syntax, very fast to prototype in and for developing full applications, multiplatform (over 40 platforms!) with a built-in graphics and GUI engine.
Some good links:
http://en.wikibooks.org/wiki/Programming:REBOL
http://www.rebol.com/downloads/
http://rebol.com/view-platforms.html
http://www.rebol.net
http://www.rebol.net/article/0188.html
http://www.rebol.net/article/0206.html
This might be news to some of you but can you imagine that the most people posting here already knew about the existence before this post here and that since they knew about Dylan, they have language fetish and hence know about Slate, REBOL and what not (Clean somebody?).
Back to Dylan. What are they going to do with two compilers? They shot one of already before getting the code dump from Functional Objects, now they’ve got two compilers again. Do they have any preferences as to which compiler to further develop? Surely such a small community doesn’t have the manpower to maintain and further develop two compilers over the long term?
I think it’s probably a wait-and-see thing at this point. Each compiler has its strengths, and both are quite usable. There wouldn’t be much of a point in just deprecating one when it works just fine. You’ll probably see much of the optimization work happining in d2c, simply because the maintainers know that code pretty well by know, but the OpenDylan tree isn’t exactly being neglected.
I think one of the keys now is to get DUIM ported over to gtk2+.
There is a gtk1+ tree in the source, but most of it will probably have to be rewritten.
The other thing that needs to be done is to get the IDE editor into a more usable state. It’s horrid, but I hear the Function Developer guys all used Emacs so didn’t put much work into it.
I think I’m going to tackle the editor after I get up to speed on all the tools and stuff.
The IDE’s editor is DEUCE, an Emacs derivative. It’s supposedly quite technically advanced, but I do agree its a bit fiddly. I’d love to see syntax highlighting and good Emacs-style auto-indent in there.
If it can’t handle auto-indent then it’s pretty much worthless these days.
That’s quite a bit of a hasty statement. The code in DEUCE is quite clean and quite advanced. Handling autio-indent would be a simple feature to add, it’s just that someone has to step up and do the work to do it. Relative to other priorities, its pretty low, because there is a decent Dylan mode for Emacs already, but that wouldn’t stop a determined user from adding that feature.
I love Dylan. It is probably my favorite programming language. It’s a shame that there’s no support for OS X. (Older binaries and sources from Gwydion supported OS X, but not this variety.)
I’m very disappointed.
d2c (Gwydion’s Dylan compiler) does still support OS X. OpenDylan doesn’t, though there is an experimental PPC backend. There a surprising amount of code in the source tree, a lot of which is disabled, partially working, etc. It’ll take awhile to sort through everything and get things working.