Plans

Tom Novelli 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 
> Scheme?
>
> 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 
Schemes....

> 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 
> Ubuntu.
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 
use Ubuntu.

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.

- Tom



More information about the TUNES mailing list