Plans

M. Edward (Ed) Borasky znmeb at cesmail.net
Sun Sep 30 12:22:52 PDT 2007


Tom Novelli wrote:
> 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 don't hate CL ... as long as Termite can be ported to SBCL, I don't 
see any reason not to go with SBCL.

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

If SBCL doesn't run in Windows, it's pretty close. I assume you are 
referring to *native* operation on Windows, not "MinGW/MSYS" or Cygwin 
operation! The other "major operating systems" (Mac OSX, Solaris, Linux 
and *BSD) shouldn't be a problem for any open source package.

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

You should only have to write two compatibility layers -- one for ANS 
Common Lisp and another for the "prevailing" Scheme standard. The Gambit 
people voted against the latest Scheme standard, so it's probably "N - 1".

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

The Gentoo Lisp/Emacs setup was derived from Debian's. However, the main 
Gentoo Lisp developer "retired" and I'm not sure who's watching the 
store now.

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

When I first got the machine, I tried them all -- Etch, Ubuntu (Feisty, 
IIRC), CentOS 5, Fedora 7, and Gentoo 2007.0. They all pretty much were 
new releases concurrently with my getting the hardware. I was prepared 
to hate Fedora, but I was pleasantly surprised. Fedora (Core) < 7 is 
useless. Etch and CentOS were both rock-solid, stable, boring, etc. 
Either one would make a fine production machine, although I'd give the 
edge to CentOS for that because there are more Red Hat trained sysadmins 
than there are Debian trained ones.

But for a scientific workstation, the choice is really between Fedora, 
Gentoo, or Ubuntu/Lenny/Sid. Normally my ranking would be Gentoo, 
Ubuntu/Lenny/Sid, Fedora. But I just couldn't work with Ubuntu. I don't 
remember all the gory details, but it ended up being a dead tie between 
Fedora and Gentoo. I didn't want to switch my brain from Gentoo to 
Fedora, so I went with (stayed with) Gentoo.



More information about the TUNES mailing list