Hacker News Reader

Comment by ldesegur | Hacker News Reader

With all due respect for people who've been working on this: Isn't it too late (by at least 5 years)? What's the point of reviving Dylan if it doesn't bring something radically new?

And reading the project status: "No support for threads yet"; Than, isn't it too early to re-release it yet?

Erlang, Clojure, Haskell, and Scala have been fueling my interest in DSL. I don't see what Dylan would bring to the picture that the other languages provide already.

View on HN

Too late for what? It's a programming language, not a racehorse.

Dylan offers something very different from the languages you mentioned; even Clojure, a fellow Lisp, rejects OOP while Dylan embraces it. There's definitely room for Dylan in the language landscape.

Too late as being able to bring to the table something that enough developers would care about so their efforts don't fall quickly into oblivion. I've seen so many times projects like this trying to resurrect a "passe" technology just for nostalgia sake. Without a decent community of motivated supporters and a real solution to current issues developers are facing, I fear that Dylan will follow the same path. In the specific case of Dylan, I remember that its infix notation didn't support very well one of best LISP features, namely macros. And while studying the language in the late 90s, I also learned that David Moon, one of the original designers, moved to work on something else. I took it as a sign. Don't get me wrong, I liked Dylan over Common LISP at the time, becauee they did a great job at simplifying the mess with collections and its notation would mean greater adoption. That was obviously not enough to succeed. As for embracing OOP, so does Scala, although at the cost of some compromises. But at least with Scala, the platform is here to address real projects. Do you really have the time and energy to start rebuilding all the libraries that are required to develop anything beside a toy project?

>And reading the project status: "No support for threads yet"; Than, isn't it too early to re-release it yet?

Surely it supports some other form of concurrency?

Every modern flavor of concurrency, be it STM, Actor Model or why not, will abstract threads and locks but won't remove them underneath. There is no magic. So if this Dylan implementation doesn't even support the foundation yet, that doesn't seem likely.

The thread support depends on the compiler backend. It works on 32 bit FreeBSD, Linux and Windows. The thread support in the C backend is broken, but it nearly fixed and will be in place for the next release, bringing the thread support to OS X and 64 bit Linux / FreeBSD.

I would be curious to find out if you guys ever consider LLVM since you mentioned backend work. How much work do you think it would take to switch your C backend to LLVM?

We're actually working on replacing the HARP native backend with one based on LLVM. The HARP backend is currently x86 only and is what we use on Windows, Linux and FreeBSD. (But not OS X, there we use the C backend for both 32 and 64 bit.)

The LLVM backend will also improve our platform support. I talked a bit more about this in the thread on reddit: http://www.reddit.com/r/programming/comments/n8d6o/open_dyla...

Reply on news.ycombinator.com