BruceM

Apart from the syntax and our current lack of a REPL outside of Windows, Dylan (http://opendylan.org/) sort of fits in that space. We're a lot like a slimmed down Common Lisp (designed by some of the same people that standardized CL), and bigger than a Scheme.

We're currently working on a lot of stuff, including an Objective C / Dylan bridge, a new build toolchain and an experimental REPL that may work outside of Windows until we can bring over the real one (once our LLVM backend is in place).

I like ReST as well. With Sphinx, it is great for producing documentation. A project that I work with has converted hundreds of pages of books of technical documentation over to Sphinx and a custom Sphinx extension.

What happened to research, investigation, profiling rather than just publishing snark, vitriol and guesswork?

This is pretty disrespectful to the Atom team and word is that they're not really happy about it.

They have the right to limit the distribution of their beta software.

I've maintained a 417 day streak despite taking multiple holidays / vacations. My overall rule for what I do is to always make at least a little progress each day. Even if that means I go and fix some grammar or spelling in docs, or file some bugs, merge pull requests. Maintaining a streak doesn't have to mean 8 hours of work each day. :)

But sadly that list is for people with more than a certain number of followers. I'm not on it (https://github.com/waywardmonkeys) despite having over 2000 contributions and a 417 day streak. :(

Running Open Genera in a VM is quite an eye-opening experience. Such a very different vision of computing and what is possible.

The person who answered you isn't associated with GitHub and has been trolling the channel (and apparently you).

IntelliJ is pretty nice on this point. You write a PEG-style parser and get a full AST. It is a lot of work, but the payoff is pretty nice and they have a lot of solid tooling to help you out.

We should get you to help us with the text on our website. :)

Hi Nick,

I have a branch that will soon allow using either Boehm or MPS on the various backends. That'll probably be the case for the LLVM backend as well.

Part of the reason that I'm doing that is to help gather some performance data on the MPS. (I'm actually doing that Dylan runtime work under contract.)

Thanks for your great summary. :)

Functional Developer and now Open Dylan also support debugging on Windows, have a REPL (on Windows) and many other features.

With the upcoming LLVM backend, we'll be able to bring those features to other platforms, but we'll need DUIM backends to support the user interface. That's a big part of why this call for help mentions several GUI related things.

With some luck and a lot of hard work, this will be a great year for Dylan.

Well, none of the things listed in our current call for help are issues with modifying the language. In fact, we spend a lot of time on improving things like the tools, libraries and documentation.

Lately, we've made our test framework integrate well with Jenkins (using Surefire output) and have been getting more and more of our libraries and tests building via Jenkins.

We've also been pulling out some chunks of code and turning them into useful and usable libraries. Our binary data library is an example of this (http://opendylan.org/documentation/binary-data/).

And one of our hackers has spent a large amount of time this week cleaning up and re-working a tool that he had for visualizing the compiler's optimizer. This will let us better perform bugfixes, ensure that the transforms are operating correctly.

We do have areas where we intend to improve the language. There are some extensions to the type system that we're looking at, improving Unicode support, and improving our numerics. But these aren't our main or daily areas of focus.

We want to bring our IDE to non-Windows platforms, we're improving our compiler backends, improving the GC integration, working on editor integration with CodeMirror, vim, emacs, and IntelliJ.

A Common Lisp-style condition system is a pretty key thing for me.

It is highly readable. And you can use '!' and '?' in names!

An optimized implementation of multimethods is always nice.

The ability to apply optional static typing is great for putting stuff into production and feeling good about it.

Having multiple return values, keyword arguments and rest arguments is nice (and yes, Python can do much of that).

Good thing we already have a compiler that does a pretty good job. :) (But yes, it is a pretty complicated beast in places.)

But at the time, the Apple Dylan IDE was pretty slow and buggy. It is amazing what a few years make much more feasible!

Al Jazeera has been covering it.

Over with Open Dylan (http://opendylan.org/), we've been building a new IDE using IntelliJ CE and it has been a joy. Even though we've gone the route of writing a whole new parser and doing new static analysis tools, it has been a pretty good experience so far. Can't say enough positive things about this.

This isn't the Clark GC, but if you're writing a lisp compiler and want to just use a GC (and not Boehm), give http://www.ravenbrook.com/project/mps a look. It is pretty nice.

We'd love to have an implementation of the functional datastructures in Dylan. This needn't even change the language definition as they could happen as a library. We just need a volunteer.

You're missing the optional static typing, the multimethods, the Common Lisp-style condition system, the ability to produce native and efficient executables ...

C could have meant a different syntax. Dylan is pretty well known for having macros without having s-expressions. And some pretty low level code can be written in Dylan. There's been some low level networking code by some Germans, as well as large parts of the Dylan runtime, including byte-level layout of method dispatch data. Looking through what he has so far in his repo (a quick look), a lot of it is similar to what we have in subject matter.

Any chance that you have seen Dylan, http://opendylan.org/ ?

Maybe too late to the party ...

I work on http://opendylan.org/ and have been working to revive it for the last couple of years. We've done new releases, improved usability of the compiler and some of the libraries, new website, updated all of the documentation to modern formats, including a couple of books.

We've also been creating a new IDE via a plugin to IntelliJ that is rapidly changing how I go about writing Dylan.

I think it is cool because it is a great substrate for experimenting with some features in programming languages and runtimes, like coroutines and numerics. It is great to start from a working and industrial strength system.

I think it is great to prevent things from being lost to history (and to hopefully have them be useful again). Dylan is a great combination of ideas from Common Lisp, Smalltalk but with a focus on creating native executables and libraries.

I've also got something that I'm building in Dylan that takes advantage of Dylan's strengths, but it is in very early days.

It is too bad they aren't looking at the very nice MPS: http://www.ravenbrook.com/project/mps

I aim for it. Clearly before the streak started, I was much more intermittent with some days passing without visible progress. :)

I'm currently on day 252 of a streak: https://github.com/waywardmonkeys/

Most days are pretty easy. Being that I maintain a large project (Open Dylan), there is almost always a simple bug to fix, documentation to improve, typos to correct, bugs to file, pull requests to merge from others.

It has been great for keeping things moving and making sure that every day, I make at least a little bit of progress. Every day, at least a tiny step forward.

Look at the PDFs on the final page of the article. They each have a date for when they were released.

Dylan doesn't have both single and multiple dispatch. Any method call is going to be using multiple dispatch.

Dispatch is dynamic, except where the compiler has determined (perhaps with hints from the programmer in the form of sealing) that it can be optimized into a static dispatch. One mode of the compiler extends this to help further eliminate runtime dynamic dispatch but that isn't enabled currently (as we aren't sure of the state of that code).

Dylan's OO isn't traditional OO at all in that it isn't like Java, Smalltalk, C++, Python, etc. Instead, it is CLOS-style OO. I wouldn't say that it was new and hot and had to be included as the OO in Dylan is a direct descendent of what was already in Common Lisp and going back from there to Flavors from Symbolics on the Lisp Machine and so on. (In fact, some of the same people were responsible...)

As for #2, I don't really see that at all. Dylan has a very intelligent and hard working compiler that tries to let you have the freedom that you want, but still be able to make things run efficiently. After all, it was targeted originally at hardware from 15-20 years ago.

I'm not a Julia expert, so I won't try to address the other points.

Check out the mixmaster anonymous remailers:

http://en.wikipedia.org/wiki/Mixmaster_anonymous_remailer

There's a lot of info around, especially documentation, but it isn't going to give a feel of actually using it. If you look around, you can find that you can run it yourself on a sufficiently old x86_64 Linux / in a VM, but it is a bit of a complex process.

I've asked someone else if they might respond to you with some further and more useful info. Hopefully they can!