Why Lisp Will Never Win (2003)
perl.plover.com
perl.plover.com
Personally, I don't even know what it means for a language to 'win'. I would be fine with Lisp/Scheme being marginally popular and acceptable when you're in the company of clever colleagues that could reasonably be expected to grok Lisp after a short while. Nevertheless it isn't. The reasons why that is currently the case would go a longer way towards explaining why that may never be the case.
It is "the Lisp community" in the sense that there is no other widely known, recommended way to get in touch with people using Lisp. The community may exist somwhere else, but they are hidden from newbies, whose first contact with the community still is the cesspit that is c.l.l, often by the spam ridden Google Groups interface.
A college kid looking for assistance with lisp these days is likely to hit up StackOverflow or /r/lisp or /r/scheme or one of the clojure communities depending on what they're using. Any of these are less 'hidden' than usenet, which happily has fallen into enough obscurity that c.l.l.'s toxicity will slowly die for lack of new blood.
I think this is ultimately always a problem between ultra-smart people who live in something of an abstracted world that frequently approaches fantasy and the reality of industry, which generally doesn't care about how pretty something is unless someone will buy it because it is pretty. That's a pretty large gap, and, while in my opinion there is no need for arrogance, it is pretty clear why most of the smartest people in history end up on the former side of that divide. They want to contemplate some sort of eternal idea which usually they ascribe beauty to (e.g. Bohr, Einstein, etc.) -- and yet hackers, unlike theoretical physicists, are halfway between the people probing the mysteries of the universe and those putting together blueprints for the atom bomb.
In my opinion that's just life. Einstein hated the bomb and rightly so in my opinion -- but that doesn't mean that it was any less a necessity for the Manhattan project to go forward. The sad thing, however, is that lots of brilliant people trying to navigate this divide end up with a huge chip on their shoulder. PG talks about this in H&P; the jocks were popular and (surprise!) the nerds were not. So you go out and get a few million and say, "ha, screw the jocks." Fine, generally speaking I think that is a good idea, but let's not turn it into a wanker fest since there are lots of needed functions in the world that should probably be performed by those who can't understand Lisp -- and I don't just mean cleaning toilets, I mean politics.
Abstraction, which is really what lisp is about in many ways, is only ever IMO one pole. You have to zoom out to see the bigger picture and zoom in to address the minutia. Generally people miss the forest for the trees, so I have every sympathy for those who stick with the forest and ignore the trees. But when it comes down to it, someone has to re-write your code in blub to make a functional product (even true with Viaweb) so have some sympathy for the little man who has to do a sh't job, probably his mother never gave him fairy tales to read and he only vaguely knows who Godel, Escher, and Bach are. That's sad, but that's life and we who are Americans should especially expect it as an immigrant nation.
Anyways, I'm one who discovered Lisp rather late despite and not because of the Lisp community as it is usually presented. I think it is beautiful and esp. I think SICP is a fantastic book to introduce one to computer science concepts and I think that industry should serve great passions and ideas and not vice versa. Hell, I even think lisp machines are a great idea and hope someone builds new ones and they take over the world. But despite all of that, I would never hang out with "the Lisp community."
Why? I want to build great products. Great products need to scale. If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral.
The thing that irks me the most about all of this whining is that America used to be capable of building automobiles and space shuttles and (omg!) computers. It was amazing. Now it is hello Taiwan, goodbye America. People talk about "Rework" and how they can't imagine being in a company with more than ten people and glorify the life of tribes in third world countries without contraception or toothpaste (or, in pg's case, the lifestyle of lions on the African prairie).
I know it may be nuts to say this, but I think we need to build cool stuff for the sake of building it, and that our tools should be our tools -- not some magic fairy dust. Use whatever works to solve the problem. Get your hands dirty. A parentheses is not a hammer if what you've got in front of you is a nail.
And if what you've got in front of you is a problem bigger and nastier than that, build a bigger and better tool. There's no problem that can't be solved if people put aside their differences and work together.
The moon is not that far away from orbital flight. These two guys might disagree with you: http://www.copenhagensuborbitals.com/
The orbit part seems the most complicated.
Every single system you name is made up of a large number of complex sub-systems designed and built to exacting requirements, and any one of them can still break at any time. Thinking you "got it right" just because it didn't break one time in one set of circumstances is unbelievably naïve. There's a reason all man-rated launch systems have redundant backup systems, and even the fallbacks don't always work right.
By the way, let me know when you get micrometeoroid shielding "right" -- every space agency on Earth will want to talk to you. You might even win a Nobel Prize.
You're also completely ignoring navigation. Just because you can fire up a rocket doesn't mean shit if you're at the wrong point in your orbit, or pointed in the wrong direction.
You're also failing to distinguish between "I can get THIS rocket into orbit" and "I can get a rocket big enough to carry people and a useful payload into orbit and/or to the moon". Think you can just "scale up"? You're wrong. Effects that were too small to measure before will suddenly kill you. Materials that could handle the strain of the smaller rocket will crumble under the increased forces.
Oh, by the way, every time the weight or configuration of your spacecraft changes, you're gonna have to rework your navigation assumptions.
Might I suggest playing with Orbiter for a while? Once you've done that, spend a few minutes thinking about the fact that you've just been overwhelmed by a vastly simplified simulation in which nothing ever goes wrong. Now picture the real world.
Oh, by the way, your heat shield is cracked, but nobody noticed because your budget didn't allow for more than one guy to inspect it, and he was too drunk. Have fun getting home.
Micrometeorites? Did Apollo have that? I am not implying it's easy - I'm implying LEO is the hardest part when it comes to a moon-orbit trip.
And in the case of an unmanned craft, it's easier: you don't have to bother with life support, atmospheric braking and most of the radiation shielding.
"If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral."
Followed by sedachv saying some guys who are trying to launch humans on suborbital flights would disagree.
Nothing you've said explains what suborbital flights have to do with going to the moon. On the contrary, you seem to be admitting they have nothing to do with going to the moon, so I still have absolutely no idea what sedachv's point was.
But, then, this discussion is completely unrelated to the point regarding emacs and an open source notebook (whatever that is). In general, Jd's rant felt confusing. I am not sure how Lisp and spacecraft are related, BTW. He (or she) implied somehow that you couldn't go to space with something simple and elegant like Lisp, but I can't be sure.
I'll make the relation very clear. There is a segment of the Lisp community, which most certainly includes Paul Graham, that maintains that projects with large team sizes are bad. There is a certain logic here, as it is hard to maintain a high average intelligence distributed across a large number of people. Most true geniuses were loners. Regardless, projects of a certain scope (i.e. building a space shuttle) require large teams. You simply can't do it with two guys in a basement.
In a certain sense the computer language employed is irrelevant, except that the lisp community has never, largely because of the facts that should be obvious but are apparently not to the introverted "genius" types they pray on, produced good and extensive enough libraries to be viable for most real world tasks. In case you didn't notice, for example, it took what, 4 years for Hacker News to get HTTPS support.
I don't want to rib anyone too badly, because I am a strong supporter of what YCombinator is doing in general and in the incorporation of lambdas and closures in newer languages, but I think generally speaking it is clear that the Lisp culture is not to cooperate but to position one's self as some sort of genius and thus to create one's own dialect, etc.
I'll give you an example that will probably irritate some people, but is relevant here. Microsoft Word is, in my opinion, one of the greatest architectural marvels of modern civilization. The feature set of that single app is truly extraordinary, and there are all sorts of wonky ways that you can do lots of tasks that makes millions (and potentially even billions) of people's lives better every day. I understand that there is a point to OpenOffice and "fighting the man" and whatever since Microsoft certainly crushed some competitors in mean ways, but realistically there is nothing in the world that competes.
Now you might say, oh sure but I can just use vim and use latex for formatting (or even google docs). And in a certain sense you might be right too, but sooner or later you will find a feature that is not accessible to you (I recently noticed that change tracking still absolutely blows in Google Docs compared to Word).
Why do I bring this up? Well, even if you are right that "the hardest part of going to the Moon is achieving Earth orbit," you still have to have all of those other things. You need life support or you dead; this is non-negotiable, just in the way that mail merge is not negotiable for millions of people at millions of office worldwide. And if you want life support (or mail merge), you need to work with the people who design these other systems.
By the way, I'm not saying you need to like any of this. I'm simply saying that if you want to build something great, you have to at times slog through the mud. My experience with Lispers is they are frequently afraid to get their hands dirty. And that doesn't cut it except in a pretty-ditty fantasy castle.
The shuttles are not engineering successes. Most large projects (large as in "lots of brains required to think about how they are going to work") usually aren't either. I'll side with pg on this. Humans cannot organize that well and less ambitious steps are a better approach to solve really big problems.
Languages are tools you use to express and think about problems. There are problems that are more amenable to be expressed in terms of Lisp and others that are more suited for C. Or SQL, or Forth.
It may be hard to express mud in Lisp, but I don't think the whole thing is as bad as you do.
But I have to wonder... Does anyone still use mail merge?
It is interesting that you describe language as a tool to think about a problem. Is it really so? Is it only because you have the language that you think about the problem in terms of the language?
Humans cannot organize that well? Well, I guess Cape Canaveral in 1969 was smoke and mirrors -- or what do you mean? I think you probably mean that the cost of organizing at a large scale like that is not a cost you are personally (or, collectively in terms of the culture of elites in the West) willing to bear. I would even suggest that it very well could be in actuality an unwillingness to bear any sacrifice for the sake of a collective goal.
"Less ambitious steps" for "really big problems." Sounds great. What steps do you mean and what problems are you possibly hoping to solve? How the private sector might be able to get someone in space -- an "engineering success" that was already accomplished approximately 50 years ago, now potentially finally accomplished by the private sector, so long as individual Russian tycoons are able to pay for $100M tickets with money stolen from starving peasants.
A brave new world indeed. As for mail merge, I have very little interest in the common man. I live in Silicon valley and watch the world burn from a carefully-cultivated distance.
That attitude, to me, is a large turn-off.
I disagree with your notion that Lisp code has to be re-written into another language to address the minutia. I address minutia in Scheme a lot.
A more useful exercise is to consider the factors that go into people choosing a language in the first place. I don't think people usually think hard about how powerful or elegant the language is, at least when they're starting out, rather they pick it up when they need to solve a specific problem. For example, here's how I ended up using the languages I've learned in the past:
QBASIC - Because I wanted to make video games when I was a kid, and things like functions and classes and scopes confused 10 year old me. The idea of executing a sequence of commands was simple enough to grasp.
C - Because that's what all the "real" programmers used, and I had reached the limits of what I could do with basic.
VB - Because writing a GUI in C sucks.
Perl - Because that's just what you used for web pages at the time.
Java - Because of college.
C# - Because VB was pretty lame.
Python - Because I needed something better to write small programs in, and the entirety of perl would regularly fall out of my head because it's too complex.
F# - Because C#'s verbosity gets on my nerves and everyone was all up on functional programming; but I found the library support in most other functional languages lacking.
Ruby - Because it's kind of the lingua franca of web startups at the moment.
And on and on. I'd say about half the languages up there are actually pretty awful, and none of them are as good as LISP, but they did something specifically useful for me at the time I learned them. I can't really say that about LISP, because LISP doesn't really have a niche. The reason I ended up learning LISP (Clojure specifically) was because I wanted to be a better programmer, but I don't think that's really a strong enough argument for it if people want it to "win"
Boy I think I took that advise from the wrong source.
Math can make me a better programmer.
Statistics can make me a better programmer.
Accounting can make me a better programmer.
Biology can make me a better programmer.
Chemistry can make me a better programmer.
Building Macros and DSLs are the new Ivory Tower of software architecture.
I started out in 'scripting' languages, and I can even say that learning Java, in a group with some very skilled OO gurus, was a mind-expanding experience.
I have even seen it happen, en masse, at a company which was composed of various language partisans uniting under one roof. After exposure to each others' ways, I think we all become better programmers for it.
But on the other hand, the days where one could get away with treating 'LISP' as a proxy for 'Functional Programming' are long gone. Aside from the hoary old beasts from the 20th century such as Java, pretty much all the major languages have first-class procedures and suchlike nowadays. LISP is no longer distinguished by having good support for functional programming; it's distinguished by lacking good support for procedural programming.
Spend a few months to find a reasonable ecosystem (NB: the libraries, tools and community, not just the language), then move on.
But I did learn Haskell later, and I think that made me worse at the job (C++) I was doing at the time, because it gave me the habit of trying to write C++ in a functional style and made me more frustrated with C++'s type system.
I learned Basic because I had a C64 (show of hands: anyone else?)
I learned Fortran because my Running Start advisor didn't think 8 credits of C in a term would fit into high school credits well and I had to match HS and college credits according to an arcane formula. Ok, I still shiver at the thought of Fortran....
I learned some C years later because it was a "serious" programming language. Not very well though.
PHP because it seemed like a good idea at the time.
Perl because I wanted to apply for jobs using it.,
Python because I was unemployed for a bit and bored.
Ruby because a customer asked me to teach them (yes, I objected saying I didn't know the language. I was told "that's ok!")
and so on.
However the things that have made me better have not been knowing all these languages but knowing the human side of the problems I am solving. I taught myself accounting to run my own business, never knowing that it would become my life (I now write open source accounting software).
So if I were to give a new programmer advice, it would be:
1) Learn a few languages, because then you can learn new ones easily.
2) Learn about databases, not just SQL, but also as much about the low level implementation as you can.
3) Learn about problems and other unrelated disciplines so you can better solve the problems. So yes, math, statistics, accounting, biology, chemistry, permaculture, etc. are all good things to study.
Today, statistical learning is considered to be a better approach to building an AI. Much of the techniques of ML are expressed easily and efficiently using linear algebra for which Matlab (Matrix Labaratory) or Octave is much better suited.
I think Lisp fell out of favor as it is terrible when it comes to number crunching.
[1] The dramatic collapse of this ideology is chronicled in this wired article (Two AI Pioneers. Two Bizarre Suicides. What Really Happened?): http://www.wired.com/techbiz/people/magazine/16-02/ff_aimyst...
The first statement is true: statistical learning is considered to be the leading edge of current AI research, especially since it attacks combinatorial explosion head-on. However, linear algebra is the baseline of current work, rarely the driving force. While the 'pull eigenvectors out of shitloads of data" method has been very effective and profitable, it is a very shallow approach to AI (especially considering the problems attacked in the 60s). Luckily, more intelligent algorithms are being developed that combine symbolic and probabilistic reasoning in a more direct way: compare LSA to LDA for example; LDA has a more cohesive and explanatory structure. These kind of things demand flexible programming environments (such as Lisp): Matlab is where algorithms go once they've been proven useful for 'normal people;' it is the domain of the analyst who cares about the data instead of the algorithm itself :).
I thought C++ (.mex or .oct files) are where algorithms go once they've been proven useful for 'normal people'.
[1] http://bfrsblog.blogspot.com/2011/10/making-emacs-first-clas...
[2] How I miss the free Matlab license at the Uni. Last I checked a commercial license costs about $2000. So, now I've been forced to shift to Octave. Heck, if Octave is good enough for Andrew Ng, I guess its good enough for me.
No, what was amazing was how stupid the exercise was. The Common Lisp example was a perfectly reasonable translation of the AWK script, accounting for the fact that Common Lisp is a general purpose programming language that doesn't have the luxury of dedicating syntax to text-munging the way AWK does.
Also, the whole concept of Lisp "winning" is silly. Common Lisp isn't making a comeback. Nobody thinks that. But every day that passes, languages get more like Lisp. Take, e.g., Xtend. We've got:
LAMBDA: http://www.eclipse.org/Xtext/xtend/#closures TYPECASE: http://www.eclipse.org/Xtext/xtend/#switchexpression FORMAT: http://www.eclipse.org/Xtext/xtend/#templateexpression Open methods: http://www.eclipse.org/Xtext/xtend/#extensionmethods Multimethods: http://www.eclipse.org/Xtext/xtend/#multipledispatch Also: Statements as expressions, etc, implicit return, etc.
----
First off, the concept of a language #winning is a complete waste of time. Neither AWK nor Lisp is Charlie Sheen.
You use a particular language so that you can solve a problem. Some languages are better suited to solve certain problems than others. You also use a language because you like it. Using a language because it's popular, unless your job requires it, is probably the least sustainable situation.
Secondly, I'm inferring the author wants to spur Lisp's popularity by promoting new features, but encountered resistance by people on a newsgroup and gave up. This is pretty weak in my book. In what situation, both social or professional, would someone NOT encounter resistance to new ideas? To give up at the first sign of resistance, and call the people who didn't like your idea "sick" is the hallmark of a whiner.
If you want to do something, just do it. No one is stopping you. Fork the code. Make a prototype. Demonstrate it. See if you are right and they are wrong. You don't need the approval of a handful of faceless Usenet posters before you start a project.
Also, there are plenty of good things that come with a language being popular. The availability of libraries, a community to bounce ideas off and get help from, etc.
If you combine these two ideas, you come to the conclusion that if any other language is seen to be "winning", it should be simple to port that language's syntax and stdlib onto a lisp environment - after all, every facility the other language might need can be provided by the lisp runtime, and reader macros might be a suitable way to avoid an explicit compilation step, depending on the language being tackled.
I cannot think of a single case of this happening. Instead, we see precisely the reverse - clojure is implemented on the JVM, CLR and JS runtimes, and there are scheme implementations everywhere.
What does this mean? It means that it isn't languages which "win" or "lose". It's plaforms. "Lisp" isn't a platform, therefore it cannot "win". The question is moot.
Having libraries that provide system programming features and work across a wide range of implementations is the first step. CL is underspecified in terms of a lot of systems programming stuff.
The #1 priority in this space is integration with the Unix shell - scripting, having executables, stdin and out, command-line arguments. Not really any good libraries that combine all this into one thing that works well everywhere.
The second big thing is packaging and distribution - Quicklisp addresses that well. Next step beyond making Quicklisp better is a script for Linux that finds the Common Lisp implementation on your system (and installs one if not present), and loads whatever software you need - essentially a common installer for CL applications that bootstraps off of Quicklisp.
About other languages on Common Lisp, there is actually a large number: http://www.cliki.net/programming%20language
A lot of languages have been ported to run on various Scheme (Racket and Gambit) implementations.
(awk (begin (set FS ":")) (cond (== $6 "/sbin/nologin") (print $1)) "/etc/passwd")
(The awk macro itself is an exercise left for the reader...)
"People aren't using Lisp, so maybe we could make it usable for things AWK is good at and get people into it that way."
Ok.
"People aren't using Java, so maybe we could make it usable for things AWK is good at and get people into it that way."
Wait, they're not?
I am all for people have gut feeling likes/dislikes for what languages they personally use, but who cares what programming language, religion, politics, etc. that other people like?
I have been using Lisp since the early 1980s, and Lisp languages are great for some kinds of applications and research. Same can be said for many other languages.
da Silva does have a completely valid point. CL needs a library to make it easy to run your favorite implementation with your software as a Unix shell script. And more reader macros. I use so many my code is starting to look like Perl. I don't think that's a bad thing. Adding an APL reader macro for array processing would IMO be a wonderful thing for a lot of the Common Lisp graphics libraries.
I'm going to be one of the "stupid argumentative people" that he says are on comp.lang.lisp (which I had never actually heard of before) and say that Lisp users don't want Lisp to win. People who understand Lisp, as mentioned in another comment, that _they_ are going to be the ones winning in the end. Maybe this person wins with Perl. I don't. Ruby, Clojure, Prolog, and JavaScript meet my needs so I use them. Languages don't compete for adoption they solve problems.
But seriously, take a look at the two examples again. Are you really suggesting that the Lisp version is easier?
All you have to understand for the Awk example how field variables work, then you can read the whole thing at a glance. The Lisp version contains custom macros and is four lines long!
I can guess what 'with-lines-from-file' does, I can guess what 'string-split' does, i can guess what 'string=' does, etc. The only thing I might not understand is 'aref'.
With the AWK example, I have no place to start. Symbol-oriented languages, rather than word-oriented languages, are like that. They tend to be more concise for things very specialized tasks, like this, but that limits their generality. Show me a matrix multiplication routine in AWK versus Common Lisp.
1) text and file processing are very common tasks 2) Lisp is not especially suited at these tasks, though it is very well suited for some other tasks. 3) If a dialect of lisp more suited to these very common tasks were made, it would increase the popularity of Common Lisp for the tasks that it works well for by familiarizing people with it.
AWK is a purpose-built language for splitting lines into fields and doing stuff with the result, so of course there's not a lot of boilerplate for splitting lines into fields and doing stuff with the results.
Lisp for doing a lot of fancy work with s-expressions is going to be high density code that's a lot harder for newcomers to read than verbose, plodding Java code that is working with a simple LinkedList class or something.
Readability (Edit: to newcomers) just isn't the relevant benchmark here.
As far as I could tell they had much more difficulty with linked lists and trees in Java, which made them needlessly complex, than they did in Scheme. And this is with people who had actually learned about both concepts first in Scheme, so they had more experience when they came to Java.
At the same time, if you were writing a bunch of random awk-like one-offs as part of your normal lisp workflow, you wouldn't write 4 lines of code every time, right? You sit down and write some functions or macros that condensed it into something simple that allowed you to easily specify things like a split token, one or more filter-on fields and values (or better, a filter lambda), and one or more output fields, I bet. Because it's silly to write several lines for something you do a lot.
And while you might call it process-file-and-return-matching-results or something, the interface to the result might not be so different from the line of awk in the original post.
Like another poster mentioned, the lisp at least has recognizable functions, and an easy syntax structure which is easy to remember across infrequent visits to the language. AWK is so specialized and irregular, I'd have to consult a reference to do simple things even (and not just to lookup function names which is quick), which is why I eventually stopped using it.
Another reason to not use it is that it doesn't adapt readily to a problem that ends up being more difficult than first thought, or one that has additional requirements added. I've often regretted doing programming in specialized mini-languages (and I'd include bash in that category too), when requirements were added that made me wish I'd used a full power language from the start, like Python, so I wouldn't have to rewrite.
I've used awk here and there, and like programming in bash, I find it so irregular that I have to consult the manpage for simple things.
He then told me to not blame my weakness at reading code on Lisp.
awk -F: '$6=="/sbin/nologin" {print $1}' /etc/passwd awk -F: '$7=="/usr/sbin/nologin" {print $1}' /etc/passwd
awk -F: '$7 ~ /bin\/nologin$/ {print $1}' /etc/passwdI didn't run it when I posted the comment. I just copied it from the article.
Writing that interpreter is the first time JavaScript's scoping rules made sense to me viscerally--they're exactly the same as Scheme's. The OOP system we used was also really similar to what you can do with JavaScript; it just used closures to save state. It wasn't exactly the same, but it was similar.
Ultimately, I find that JavaScript is much closer to Scheme than other dynamic scripting languages I've used like Python and Perl.
Considering all this I think what Douglas Crockford said is completely accurate, JavaScript is Lisp in C's clothing. That would also make CoffeeScript Lisp with fairly nice clothing.
The reason this doesn't hold up is because there are a bunch of other languages that also have most of those features of Lisp, and some of them are older than JS. Python, Ruby, and Perl all have similar features. Every language has conditionals now so it's not even worth mentioning. Even Java has GC, broken closures, and reflection.
> JavaScript, is even a pretty solid tree processing language, because most JavaScript programs manipulate XML trees. XML is basically S-expressions with hundreds of pounds of useless clothing (end tags, attributes, etc) weighing it down.
You can manipulate XML in Java and C, does that also make Java Lisp in C's clothing, or C Lisp in C's clothing? Lisp macros manipulate code as trees, but that doesn't mean that any language that can manipulate trees is a Lisp. XML isn't JavaScript code, it's just data. The trees that Lisp macros manipulate is data and also Lisp code.
> Considering all this I think what Douglas Crockford said is completely accurate, JavaScript is Lisp in C's clothing.
It's not "completely accurate". It's mostly inaccurate. It's a cute pithy platitude, but it's not really helpful. Just Google "code is data" and see what kinds of confusion is out there about this.
Apology to Douglas Crockford, who does good work. I actually came back to Lisp through his JavaScript lectures, so I feel a bit bad being harsh.
It's not just the syntax that's different, but the semantics as well. The hallmark of Lisp is code-as-data, data-as-code; JavaScript certainly can't claim that. I like JavaScript (for the most part), but it's wrong to call it "Lisp in C clothing".
(I realize that it probably sounds silly to complain of learning "yet another" editor, when it's one of the two longest-lived for programming, but really, Emacs is extremely complex, and all I want to do is work through SICP)
As for the article, his description sounds like comp.lang.* .
Easy GUI IDE with debugging, etc.
It's annoying to learn another IDE< yes, but Scheme just needs an IDE that understands how to highlight/indent it properly.
It's a little obtuse to learn unless you're following along a course text with it, but nowhere near emacs' learning curve.
It's a package to support some code in the book that is some what implementation specific, drawing graphics for the picture language, for instance.
Although I like Emacs and have used Emacs every day that I have not been out of town for the last 19 years, I do not think it sounds silly for a programmer to complain of learning Emacs!
(My tips would be: ignore the menu bar and ignore the scroll bar, spend time figuring out how the C-h help works, and don't (yet) try to fight its tendency to crap new windows everywhere. Oh, and overall, don't expect it to be any easier to learn than vim. It is just as bizarre and alien, in its own way...)
More seriously, if I wanted to save few minutes per day, I'd rather remove Facebook account.