Live data from Hacker News

Open Dylan 2013.1 released

opendylan.org

21–28 of 28 posts

Re: Open Dylan 2013.1 released

#21
post #16
post #5

Earlier quoted context omitted.

This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us. For me, some of the important things are: * The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization). * Because it has a smaller community and installed base…

Point 1 & 3 are nice enough to convince me to try it out, but I kind of miss the bracey syntax. Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?

There are two backends, including a C backend. Porting to a UNIX-y platform is pretty easy as I recall. I think I had it running on OS X/PPC after a week of fiddling.

Re: Open Dylan 2013.1 released

#23
post #21
post #16

Earlier quoted context omitted.

Point 1 & 3 are nice enough to convince me to try it out, but I kind of miss the bracey syntax. Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?

There are two backends, including a C backend. Porting to a UNIX-y platform is pretty easy as I recall. I think I had it running on OS X/PPC after a week of fiddling.

It has all gotten easier since then. :)

I've also written most of a porting guide in our Hacker's Guide as well: http://opendylan.org/documentation/hacker-guide/porting.html

Re: Open Dylan 2013.1 released

#24
post #19
post #14

Earlier quoted context omitted.

Apple designed the language to ease the move of experimental (typically Lisp or Smalltalk) code into production (where it had to run faster, in less memory, etc). Tey wanted a Lisp that ran as fast and as memory efficient as C, so that they could write the OS in Lisp. That's why they put a lot of thought into the sealing functionality ( http://jim.studt.net/dirm/interim-36.html ) and into limited types. For example,…

> And no, that didn't work out. There was a prerelease development environment, but they never managed to get this mainstream. This was due to internal Apple politics, as Dylan was planed to be the system language for Newton, I don't remember any longer the full story but other group ended up getting the project.

It's been a while since I've read the paper, but technical aspects like runtime size of binaries led to a bytecode compiled language like Smalltalk, leading to NewtonScript.

Re: Open Dylan 2013.1 released

#26
post #5
post #3

I've been seeing OpenDylan pass by on /r/lisp and HN the past few months. I've installed it, and it looks nice, but it could use some maturing and I'm not sure what the advantage over other LISPs is. Can someone explain it to me?

This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us. For me, some of the important things are: * The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization). * Because it has a smaller community and installed base…

How does it do threading?

Does it support native OS threads or green threads?

Re: Open Dylan 2013.1 released

#27
post #5

Earlier quoted context omitted.

This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us. For me, some of the important things are: * The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization). * Because it has a smaller community and installed base…

How does it do threading? Does it support native OS threads or green threads?

Native OS threads.

Re: Open Dylan 2013.1 released

#28
post #17
post #16

Earlier quoted context omitted.

Point 1 & 3 are nice enough to convince me to try it out, but I kind of miss the bracey syntax. Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?

The compiler has multiple backends. The "HARP" backend outputs native code for x86-linux, x86-freebsd and x86-windows. The C backend outputs C and works on x86_64-linux, x86_64-freebsd and Mac OS X. We have an in-progress LLVM backend that will support all of the above platforms and more. As for ARM/Linux, we have a port in progress for the C backend. In theory, it should work after a cross-compile or using cross-com…

I would love to help, and I'm really interested in compiler development etc, but I have the habit of promising to help out and concluding that I don't have the time to follow through.

I might have a few weeks between projects in August, and if so, I'll try to see if I can help out (but no promises! ;)) I'll definitely join #dylan tomorrow though!

Post reply on HN