I wrote that on the Atom forums ... that's the editor in Open Dylan, which used to be Harlequin Dylan (and was Functional Developer after Harlequin folded and before being open sourced).
I had parts of Deuce up and running as a terminal-based editor at some point. Well, I didn't do input which is clearly a very important thing ... but I'd made good progress on the output side of things. :)
Doesn't build yet but it's great this didn't get lost like other code. It's a shame licensing and ip management keeps some of our works under lock. Imagine books and scientific papers being kept in vaults. It's another good reason to start projects in the open without giving up ownership to a company or some organization. The FSF or INRIA could pull an Oracle and branch off into a closed code base, but that of course won't happen. Just illustrating the dangers of giving copyright ownership to a single entity like FSF or Google for that matter. Sorry for the rant, but INRIA's CLA rubs me the wrong way because they license OCaml as LGPL with the option to relicense under a liberal license exclusively to Caml Consortium members it seems: https://www.reddit.com/r/ocaml/comments/46fiox/ocaml_compile... They are in the right to do so and have valid reasons but it's not a great idea for a project with not that many external contributors.
Rather than point to any particular language feature or design aspect of the language (which are what originally drew me to Dylan), the thing that keeps me there now is that it is a green field.
If one has newer or different ideas about how things could be done or structured, this can't really be introduced coherently and consistently across a language ecosystem that is already big. I think Node did well at the start in part due to being able to build everything new with non-blocking I/O in mind. That's unlike the use of Twisted in Python which had a number of caveats when working the standard library (and now there are a number of other non-blocking I/O libraries).
The other side is that I do it because I enjoy it and we're building something good.
We do have some good language features (like multiple dispatch as someone else has mentioned), we have some pretty good documentation, our upcoming LLVM compiler back-end is generating good code, we have a good debugging story.
People start languages all the time. I find it best to just pretend that Dylan isn't an old language, but something new that is being created on the grave of Open Dylan. We're working on changes to the type system, the compiler, the libraries, and soon, I'll be starting in on some stuff that takes advantage of our green field status. We just didn't go and start a new language from scratch, but decided to build upon the massive amount of work and design that went into Old-Dylan.
I'm glad to see it. My hobby is programming languages and its amazing how many of the older languages have concepts and constructs superior to modern languages. We keep forgetting things we learned in this profession, and its nice to see someone dusting off the old ruins and rebuilding with an eye to some new understandings.
Maybe? (I'm going to leave where I am shortly on a 6+ hour drive. I'm on holiday in the US for another several days.)
I was talking with someone else last night that has worked on and with Dylan for the last 20 years or so over dinner.
He commented "I'm sometimes afraid to use Dylan as I don't know if someone will be supporting the compiler." I replied that "I'm afraid to support the compiler sometimes as maybe no one will use it."
That said, I've put some years of effort into it and have been actively maintaining the compiler for a while now. Now I'm building up libraries that I need for my green field project and working on some language changes to support that.
I'm now working on a 2-5 year time frame.
That said, if we got another like-minded hacker out of any attention, I'd fall over from joy. We have so many things that we need help with, especially things like type system work, but also plenty of easier things.
Also, I need to get back to using your LittleLogs! I sort of traveled a few times too many last year and in the process, fell out of the habit. I will set a reminder to start it again once I'm back home on the other side of the world.
Thats a very nice find, thanks for the link. I'm not entirely sure about putting everything into a header file -- and marking load of pretty big functions as 'inline' but well, it simplifies the build a lot it seems!
In Open Dylan (http://opendylan.org/), we have a library of our own written in Dylan that lets us write out LLVM IR in binary files. We have to update it as LLVM changes, but that typically isn't all that bad.
We have some macros and a bunch of functions then that make emitting LLVM IR simpler. For example, the "ins--iterate" and "ins--if" / "ins--else" macros in this code handle phi nodes and so on:
This library is currently in the process of being updated from LLVM 3.5 to current HEAD as debug info has changed significantly upstream. After that, we will be landing some documentation for it as well.
If you're interested in learning or hearing more about this, we're typically around on #dylan on freenode IRC.
Dylan (http://opendylan.org/) does that via generic functions / multiple dispatch. The object system in Dylan is derived from CLOS from Common Lisp.
Dylan allows sealing of generic functions to limit extensibility where needed and can use that information (along with other information) to optimize, generate warnings, etc.
define class <weapon> (<object>) end;
define class <sword> (<weapon>) end;
define class <wand> (<weapon>) end;
define class <person> (<object>) end;
define class <wizard> (<person>) end;
define class <warrior> (<person>) end;
define method wield (who :: <wizard>, what :: <wand>) => ()
...
end;
define method wield (who :: <warrior>, what :: <sword>) => ()
...
end;
I had parts of Deuce up and running as a terminal-based editor at some point. Well, I didn't do input which is clearly a very important thing ... but I'd made good progress on the output side of things. :)