Huh. I submitted this as a link to a story about Stripe starting a limited UK beta. Then it morphed into a dup of a previous submission of mine! (And if I try to re-submit the Stripe thing, I end up here.)
On Windows, we have a full IDE, including debugging, but it is a bit difficult to get running correctly as it requires having PellesC on the path (or a really outdated version of Visual C 6). The next release or two will simplify and improve this some.
There's some information about why the IDE is on Windows only and the status of our Windows support on the Dylan Foundry blog:
Despite the IDE itself being Windows only, a lot of the backend code to support the IDE is part of the command line tools, but without a UI. This can be seen by a prototype web-based IDE that Bastian Muller was working on as a university project:
One of the interesting tools that Apple had was one called Creole which was for making it easier to produce bindings for libraries in C, etc. The Gwydion Dylan team at Carnegie Mellon University produced a similar tool called "melange". I recently wrote about using melange to produce bindings for the nanomsg library:
As for the future ... it would be entirely possible to build some nice SublimeText integration, improve the emacs integration, build a web-backed IDE, get our UI toolkit (DUIM) up and running on Linux or OS X and start making the IDE work on those platforms, or many other possible projects in this area.
I've also been looking at writing some extensions or Python scripts to use with lldb and the binaries that we get from the Dylan compiler's C backend. That looks pretty promising and will be even more promising once the LLVM compiler backend is up and running.
The foundations are there and in general are pretty strong. We just need some help.
I'm glad this got to the front page. I encourage everyone to look through the new documentation. BruceM is leading the OpenDylan revitalization project, I just got on board with it too. You could learn a lot, the language has been rapidly updated in the last year or so.
(Apologies to the OpenDylan folk, I find I wrote this in the past tense. Just my POV.)
A Historical View of Dylan
Back in the day we used Dylan heavily for generating enterprise middleware for the C++ programers, writing X11 applications, and generating web pages when the web finally arrived.
It was like a Lisp with a world class object system, neatly disguised in a Pascal feeling syntax so you could grab commodity programmers and get them up and running. Any programmer with eyeballs could read the code. To many eyes it looks verbose, but with a nice editor mode it typed quickly, e.g. you never typed "define variable", you hit a key, expanded the statement, filled in the blanks, and headed on.
Multimethods, value based dispatch, multiple inheritance, and open ancestor classes all together without warts is a lot of power. Of course, don't point that fully armed and operational object system at your foot.
Ah yes, you say, but how do you do eval and all those Lisp macro things from a Pascal syntax? We didn't. While many smart people struggled to make spectacular Dylan compilers, we happily used Mindy, the tiny byte code interpreter. It was the mid '90s. 32MB RAM in a 66MHz i386. What we lost in CPU efficiency we picked back up in memory footprint. In those days you did something else while building your software, (not surf the web of course, maybe poll ftp sites to see if there was a new "init" to compile for your Linux machine since distributions weren't really invented yet), g++ had a 1 in the first version digit. If C++ had templates, they were so ludicrously bloated that you couldn't afford the RAM to use them. egcs hadn't forked then eventually killed the abomination that gcc 1 had become. With Mindy our builds were instantaneous and it ran pretty well too. Even the "stop the world and copy everything" garbage collector worked well in our GUI programs once we figured out to detect and force impending collections at times when the user wouldn't notice, like right after they selected a menu item, rather than letting the GC trigger automatically in the middle of a button draw.
Sadly, after a promising start, Dylan languished. Apple refocusing away from Dylan was a big part of it, but I think there was a bigger problem, perhaps part of the reason Apple moved away (plus timing issues, Dylan missed the Newton moment). The macro system was so insanely difficult to understand that I don't think more than 5% of our programmers could have fully understood it. I'm being quite literal here. It was a language that anyone could read and understand combined with a macro system so byzantine that statistically speaking no one could comfortably use it. You could define whole new Pascal looking syntax constructs, flow control, or whatever you wanted with it… probably… after somehow altering you brain into some transhuman construct capable of understanding the macro system. Notice how in the linked book, "Macros" is the last chapter? Clearly the author went mad and was no longer able to communicate with humans.
Edit: Added this little forward looking section
Given a “do over” on Dylan, I would whisper “packrat parser” in the ear of the language designers. Replace the macro system with the ability to dynamically augment the parser. This gives you a model that a reasonable number of programmers will understand, an opportunity for meaningful error messages, and essentially unlimited potential, for both good and evil. It wouldn't have worked in the '90s, too much memory required, but we aren't there anymore. Want to add SQL support? Add a module. Give your language a "select" statement. Make it a loop construct if you want to stream process the results. Your SQL statements get syntax checked at compile time. Screw pasting up commands and substituting placeholders. Write SQL right there in the middle of your code and use your language variables willy nilly.
Just one comment about the above ... Mindy didn't really support macros and while d2c did, they were relatively broken. And I'm not really sure that there's anyone left in the world that understands all of the details of the macro expander in Open Dylan.
I do think that that chapter of the book made them relatively clear though ... but it might only seem that way to me since I already have a pretty good understanding of them.
Edit: response to your edit:
But we're interested in evolving the language. We're looking at adding an s-expression syntax. Hannes and I are both interested in extensions to the type system. We'd love to see some of our internal macro machinery that is available within the compiler more broadly available. It takes someone identifying something they'd like to do and championing it ... we'd welcome you (or others) to drop by #dylan on Freenode and chat with us.
