Hacker News new | past | comments | ask | show | jobs | submit login
Open Dylan (opendylan.org)
67 points by brudgers on Jan 2, 2016 | hide | past | web | favorite | 12 comments

I do a lot of the work on and with Open Dylan.

So, why?

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.

So, an approach much like the previously discussed Modula-2 reboot https://news.ycombinator.com/item?id=10797147

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.

Hi Bruce! Good to see Open Dylan getting some attention on HN :)

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.

I had a quick lock at the website, the 'history' page, the 'old.' website etc., but I still didn't get an answer to a very basic question for a programming language which is: why?

Somewhere in a post from a couple of years ago I read "a vision of a different world: one with the flexibility of Smalltalk, the power of Lisp, while still allowing for compilation to efficient code", but as someone said in a comment to the link of that post in HN these these are already covered (and if not, they have a lot of people working on them) by other more popular (and more friendly imho, from the few examples I had a look to) languages..

So again, why Dylan?

Nostalgia. Software archeology. Language hobbyists wishing to keep it in a working state.

Besides that there is little reason to use Dylan, nowadays.

(But see BruceM's comment about using this Dylan as a foundation for further development.)

It was once developed by Apple to replace Object Pascal and C++ for application and also systems development. But with NeXT bought by Apple that was the role of Objective C and many years later now also for Swift.

This particular version of Dylan was developed by Harlequin - the product name was DylanWorks. Harlequin was bought by Globalgraphics. Globalgraphics used the Postscript raster image processor developed by Harlequin and spun off the LispWorks system into its own company. Years later DylanWorks and even later MLWorks were open sourced. One idea of Harlequin was to develop a range of modern programming languages, implementations for those and development environments: Postscript, Common Lisp, Dylan, ML, ... The implementations were closed source and proprietary. When Apple announced their Dylan, Harlequin hoped to follow a market leader by providing an implementation for platforms Apple would not cover: Unix, Windows, ... Also Harlequin might have hoped to use their Dylan themselves for development of software applications.

But Harlequin in this forms does not exist anymore, DylanWorks has been open sourced and Apple has long ago lost interest in Dylan.

On the positive side: this Dylan is free and open source and interested persons can study and, maybe, use it.

Lisp users might be interested to study the prototyped implementation of Dylan for LispWorks. This implementation was not their shipped product, though.


That particular version is another example of a non-trivial programming language built in Lisp - especially given that it also has a non Lisp-like syntax.

The 'killer app' of Dylan is (IMO) multiple dispatch. I believe that it changes significantly (in a good way) how the behaviour of programs can be modelled. But the 'Why Dylan' document fails to do a good job of putting that front and centre and explaining its utility and excellence.

We would welcome help from fresh eyes on improving that sort of material on the website.

Because Apple.

From the perspective of a hobbyist programmer, the compiler seems very "enterprisey": it doesn't look like you can just stick a program in a file and run it or put some functions in a file and load them into a REPL. Instead it seems you have to make an "application" with some specified directory structure and several files indicating where to find things and so on. I guess that's what a serious programmer would do anyway, but it's a little off-putting to people like me.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact