"I object to doing things that computers can do." --Olin Shivers

"I start getting the shakes real bad around 10am, right before my advisor meetings. A 10 oz. Jack 'n Zac helps me get through the meetings without one of my students winding up with his severed head in a bowling-ball bag. They look at me funny; they think I twitch a lot. I'm not twitching. I'm controlling my impulse to snag my 9mm Sig-Sauer out from my day-pack and make a few strong points about the quality of undergraduate education in Amerika." --Olin Shivers, from the scsh manual "acknowledgements"

If I thought anyone cared, if I thought anyone would even be reading this, I'd probably make an effort to keep up appearances until the last possible moment. But no one does, and no one will. So I can pretty much say exactly what I think.

Oh, yes, the acknowledgements. I think not. I did it. I did it all, by myself.

The acknowledgements of the scsh manual is one of the most entertaining pieces of a technical manual I've read.

It's funny to hear how Lisp implementors of the day thought Scheme was too dynamic to be implemented efficiently.

Greenspun's experience with Scheme performance, including a startling confession from Sussman (as remembered by Greenspun, anyway): http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...

This article is both inspiring and depressing. Depressing because it reminds me of how little I truly know about computing. :(

Maybe a brave professor will set down a Team of 6-7 skilled graduates and hack out a language of the future again. It is about time it happens. When I see around the world of academia I am not seeing that happen that much though as good old software engineering on creating a good compiler will not produce any articles.

It is sad though.

This essay reminds me of the HOPL papers (http://en.wikipedia.org/wiki/HOPL).

As a younger hacker it provides insight to what was going on in the LISP and Scheme communities in the 80s. (Thanks PG!)

Johnathan Rees' T project page has a list of errata to Shivers' article.

http://mumble.net/~jar/tproject/

Is anyone using T currently? Or anything directly T-derived?

Some schemers on #scheme on irc.freenode.net are toying with it I believe.

It would also be interesting to compare it with Arc.

comparison: T is Scheme with an optimizing compiler that was the state of the art that also served as a backend for a few other languages

Arc is a few syntactic rewrites layered on top of dr scheme with some relatively unique libraries that could easily be ported back to dr scheme.

The test of a language is what it gives the user, not how many lines of code it is. JMC's original Lisp is about 50 LOC.

Imagine if I spent the next year writing an immensely complicated optimizing compiler for Arc, and succeeded in making it 2x faster than code generated by the compiler the MzScheme guys have spent so many years writing. A lot of people would be more impressed with Arc then. And yet I'd have pretty much wasted my time. Arc is already acceptably fast. So at the end of this exercise I'd have produced a language that was better in ways users didn't care about, and no better in the ways they do (language features).

Instead I work on language design. Like JMC's code, this kind of thing is easy to copy-- once someone has already shown it to you.

You know, when I write about how one should work on the problems that really matter instead of the ones that are prestigious, people read those essays and think "yes, obviously, that's exactly what I'd do." But it's not till you try working on unfashionable problems that you see how immense the pressure is to work on fashionable ones.

Just as well I've avoided saying most of the "things you can't say," or 90% of the people who read that essay and think "hear, hear" would hate me instead....

so why aren't you using Dr Scheme directly? [edit in response to pg's edit] to be specific, why don't you have arc include the various high level modularity and semantic abstractions that Dr Scheme exposes? eg 1) a powerful high level macrosystem 2) ways of specifying / enforcing module interfaces 3) everything else that i'm forgetting

1) Because I don't think you want anything more "powerful" than defmacro-style macros. 2) Because at this stage I'm focusing mostly on making programs shorter.

fair enough. On that note, http://www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz is probably the best formal treatment concision in a programming language.

Are you still working on Arc? You've been absent from the Arc forum for a long time...

Yes, I've been working quite a lot on various bits of the code this summer. In the last couple weeks I've been working on speed improvements and protection against voting rings and spammers in news. (The stories on the frontpage now seem visibly better, at least to me.)

At RubyFringe, Giles Bowkett conjectured "Maybe a programmer is a how, not a what." Although I'd read this before, it shook me. Things in a language's implementation are hows, while things in its design are whats.

Doug Kaye: The second chapter of the book, which is in fact entitled Hackers and Painters, draws parallels between hacking and painting. In what ways do you think to program is more like painting than it is like some of our more common metaphors such as engineering?

Paul Graham: One big difference between painting and engineering is engineers.in buildings for example there is this distinction between architects and engineers. Architects decide what the building is going to look like basically and then they say to an engineer, "Can I do this? And then how?" And the engineer figures out how. So architects figure out "what," engineers figure out "how." Well painters do both. Painters decide what to paint and then have to paint it. And hackers in the best case also do both. They're not merely engineers who just figure out "how." The great hackers decide "what" and then figure out "how." And in fact the two can influence one another in a cycle in the best case. In the best case, you figure out "what" by trying various "hows."

http://www.thelinguist.com/en/en/library/item/10593/

So to get the terminology right, Dr Scheme is a "programming environment" (think of it as the IDE) for PLT Scheme. Arc runs on MzScheme, which is PLT's implementation of Scheme (plus a lot of other things too).

I haven't heard of anyone using Dr Scheme as an editor / IDE for Arc.

I've used Dr Scheme with arc (technically anarki-arc). It worked with no problem on Windows XP / Windows Vista / Ubuntu / Mac OS X (10.5). It's probably the single easiest way to demo it to someone that isn't familiar with lisp/scheme. (java heads, .net programmers, etc.)

Demoing it with a eclipse / visual studio like IDE really does make a difference. There a a surprising number of people who dislike VI/VIM and emacs.

When I'm actually doing arc development I use emacs and inferior-arc.

http://github.com/nex3/arc/tree/master/extras/inferior-arc.e...

by Dr Scheme in my case I mean plt scheme, which is pretty nice as schemes go

I wonder if PG will incorporate the dataflow portions of his dissertation in a future Arc compiler?

Computers have changed since the 80's. A lot. Micro-optimizations at the instruction level only help code that can run out of L1 cache. Typical tasks these days (c.f. web development, both server and client) use huge data sets, and are frustratingly resistant to this kind of trick.

I'm not a big fan of either scheme or arc, frankly, but pg's decision to leave the optimization to the underlying scheme interpreter sounds spot on to me.

Any links anywhere to some sample applications or code snippets written in T?

Sounds like an interesting variant of Lisp.

You can get the last versions of T here - http://mumble.net/~jar/tproject/

Haven't checked if there's any sample code.

it looks like there is more recent stuff available at: http://people.csail.mit.edu/riastradh/

also of interest: http://web.archive.org/web/20070205145001/mumble.net/~campbe...