Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Dylan 2013.1 released

opendylan.org

Post reply on HN
Print view View original

1–10 of 28 posts

Re: Open Dylan 2013.1 released

#2

Post by 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).

Re: Open Dylan 2013.1 released

#3

Post by 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?

Re: Open Dylan 2013.1 released

#4

Post by mmariani »

BruceM wrote: post #2

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).

Here's the task list for this hackaton. 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.

Re: Open Dylan 2013.1 released

#5

Post by BruceM »

sspiff wrote: 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 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.

Re: Open Dylan 2013.1 released

#6

Post by BruceM »

mmariani wrote: post #4
BruceM wrote: post #2

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).

Here's the task list for this hackaton. 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.

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? :)

Re: Open Dylan 2013.1 released

#8

Post 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?

Re: Open Dylan 2013.1 released

#9

Post by seanmcdirmid »

krautsourced wrote: post #8

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?

If they allow dashes in names, then they probably tokenize binary operators using mandatory whitespace.

Re: Open Dylan 2013.1 released

#10

Post by BruceM »

krautsourced wrote: post #8

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?

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 '' (but that's just a convention used everywhere).

Post reply on HN