

Open Dylan 2013.1 released - BruceM
http://opendylan.org/news/2013/07/11/new-release.html

======
sspiff
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?

~~~
BruceM
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 at this point in time, it has the freedom to evolve in new directions whereas an existing Lisp is already defined and tied down to what it is (for the most part). (Coroutines would be a nice addition for example.)

* You can produce executables from it and don't have to have a running image.

* The integration of the type system is, for the most part, nice. It is nice to have the ability to have a mix of dynamic and more static typing. (The type system could be better, and that too is an interesting possible future direction.)

* Always using multi-methods and everything being an object and the more powerful dispatch capabilities are quite handy.

* It has a condition system like Common Lisp rather than exceptions.

* The macro system is okay.

* It is nice having multiple return values, #rest parameters and keyword parameters, all cleanly integrated.

* The C-FFI is good.

* Some people like the syntax. I enjoy how readable the code is to me.

* I'm not tied into using the JVM.

Some Lisps have some of the above, some don't. Not everyone might like all of
the above, but for me, it is a comfortable fit.

~~~
sspiff
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?

~~~
BruceM
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-compilation tools, but we
haven't quite tried it out yet ourselves (the person doing the port is getting
married this weekend and going away for a couple of weeks).

If you would like to help out with Dylan on ARM/Linux, drop by #dylan on
FreeNode IRC and I'll work with you. (The hack-a-thon this weekend is a great
time for that.)

Otherwise, we plan to have this in the 2013.2 release (whenever that is).

~~~
sspiff
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!

------
BruceM
We're also having our hack-a-thon this weekend (July 13-14). We're expecting
around 15 people to participate on IRC and perhaps a Google hangout.

Hopefully we'll be making some good headway on things for our next release
(which will include ARM Linux support among other things).

~~~
mmariani
Here's the task list for this hackaton. [https://github.com/dylan-
lang/opendylan/wiki](https://github.com/dylan-lang/opendylan/wiki)

Things that stand out to me are the LLVM back end, Coroutines support,
Postgres library, and uWSGI binding.

~~~
BruceM
The LLVM backend and Coroutines support are a bit more than would fit into a
hack-a-thon. The LLVM backend is actually making good progress with someone
who has been working on it for a long time (with some breaks).

The postgres client library and uWSGI bindings are probably doable within a
weekend. Feel like dropping by? :)

------
krautsourced
Just out of curiosity, is there a reason for allowing operators in variable
names? I've just glanced over the introduction, so if I got something wrong
here, sorry. But it seems like this would work?

    
    
      let shoe = 5;
      let size = 3;
      let shoe-size = 10;
      shoe-size := shoe-size;
    

Now what? Is shoe-size 10 or 2?

~~~
BruceM
White space is required around operators. This allows the names of bindings
(variables, methods or whatever) to be very flexible. Things that represent a
boolean can end in '?'. Operations that mutate can end in '!'. In the
Objective C bridge that I'm working on, I make use of '/' like: 'objc/class-
responds-to-selector'.

Type names are typically enclosed in '<...>' like '<integer>' (but that's just
a convention used everywhere).

~~~
krautsourced
Ah, ok, I had not seen the part about the mandatory whitespaces. I still think
it has the potential to confuse, so if I were to write in languages that allow
dashes, I'd probably still avoid them where possible (can't see the advantage
over using underscores instead). Anyway, thanks for the info.

~~~
gecko
Having plenty of experience both with languages that do and do not allow
"operators" in variable names, it's not actually confusing in practice. You
quickly learn that whitespace is very significant in those languages, and then
you read them differently. This isn't any different than indentation in
Python, line breaks in Ruby, or sigils in C++.

~~~
Someone
I haven't really programmed in Lisp or Dylan, but the code I read certainly
seemed the better because of the punctuation in function names. It gets
denser, but stays readable. A question mark signals 'returns boolean' just as
strong as a "Is" or "Has" prefix, and there AFAIK is nothing in other
languages that signals "modifies its arguments" as strong as a ! suffix.

I also find that Dylan's convention of using brackets in class names rapidly
grows on you. But maybe that requires working in Forth as a warming up.

And of course, hyphens not only look better than underscores, they are easier
to type, too :-)

------
rcb
Congratulations! I'm downloading my copy now. Thanks

------
jackhammer2022
Congratulations Bruce!

------
mross462
No hot fire?
[https://www.youtube.com/watch?v=Z9lg6HqJeY0](https://www.youtube.com/watch?v=Z9lg6HqJeY0)

