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.