tnovelli at gmail.com
Sun Sep 30 11:17:15 PDT 2007
M. Edward (Ed) Borasky wrote:
> About the platform -- Common Lisp? Why not Gambit Scheme? You get:
> 1. Scheme, of course, both compiled and interpreted
> 2. Termite -- Erlang-style concurrency embedded in Scheme.
> I don't know how efficient Gambit is relative to the other C-based
> Scheme implementations, although I think it's slightly slower than
> Chicken on average. It's probably more efficient than SBCL, though --
> doesn't SBCL compile to bytecode rather than real code or C?
> Or -- since you're "borrowing" from PLT Scheme, why not just use PLT
> But then, if it must be Common Lisp for some reason, SBCL is clearly
> the one to use.
If CL is the first choice, Scheme is a close second. Fare used to favor
Scheme, but he favors CL now... he's written a lot about the merits of
each over the years, on the list, his blog, and elsewhere. He uses CL
at ITA. Tril's "Max" reflection project is in CL... Slate was
bootstrapped in CL... and there are other Tunes members who prefer CL.
It seems like this is one thing we can agree on.
I don't want to drive away talented people who happen to hate CL,
however. (I'm a reformed Lisp-hater myself.) We're trying out ideas,
and anything that works in another language ought to work in CL; and if
not, that's a shortcoming we'll eventually need to address in our HLL.
I like PLT Scheme. It's friendly, complete, and runs on all the major
operating systems (unlike the *free* Common Lisps). While friendly, the
IDE is a little clunky... I'd get frustrated using it for serious
programming, but it's a good starting point.
Scheme is too minimal and perfectionist, with very different
implementations -- like Forth. We could easily get bogged down in
compatibility issues if we base our work on Scheme. That said, the
Scheme community has a lot of good ideas, here and there, that should
eventually find their way into Tunes.
SBCL, like CMUCL, compiles to native code. Not that it matters, as it's
a complex monolithic system, and Fare assures me that we can't use the
"compembler method" to extend it at the machine code level -- or rather,
it would be even more work than building a clean *reflective
environment* (TUNES itself) from scratch.
Maybe we could write a "Tunes compatibility layer" for CL and a few
> On the OS -- Debian is OK for me, although I prefer Gentoo. I don't
> like Ubuntu -- never have and never will. I'd even pick Fedora over
I ran Gentoo until 6 months ago... I was spending too much time
re-compiling & configuring programs... I wanted something that *just
works*, so I tried Ubuntu and I'm happy with it. In particular, Lisp
and Emacs work great with little configuration; under Gentoo this was a
pain in the butt. Gentoo scared me away from Lisp/Emacs. Debian is OK,
but it does lag behind... the "stable" release is *obsolete*, "testing"
still lags, and if you need something in "unstable" you might as well
I'd recommend Ubuntu or Debian for a new Tunes hacker who doesn't want
to be bothered with the gory details of Unix... or an old Unix hacker
who's sick of it!
> By the way, since you haven't asked, what am *I* currently working on? :)
> 1. I've got a dual-core 4 GB Athlon64 X2 and I'm using AMD's
> "CodeAnalyst" to tune the Ruby interpreter on it. It's no great
> difficulty to install Gambit, Dr Scheme and SBCL (they're all in
> Gentoo and up to date) and profile them as well.
I've got the same thing, just because it was cheap... I'm not exactly
pushing its limits. Anyway, I guess you'll just let us know which
implementation takes advantage of the dual-core best?
> 2. When that's done, I'm going to build a Markov chain analyzer in
> pure Ruby. Speaking of Summer of Code, one of the Ruby projects this
> year was some more matrix routines, and that's exactly what I needed
> to build this.
Cool.. let us know how it turns out.
More information about the TUNES