reading SICP for fun and profit

Adrian Colyer, the lead of the AspectJ project, discusses the beauty of Lisp and SICP in his latest blog post.

So at the end of the day, this is the thing that really impresses me about Lisp (and about the approach to teaching programming taken in the book). The language is so simple, and yet constructed in such an elegant way that it just doesn't get in your way - whatever abstraction you need to build, Lisp lets you do it in a very direct manner. Java just feels plain clunky when you put it alongside :- lacking in power, ease of expression, and beauty.

On the worship of SICP

I really love SICP. I'm even using it to teach computer programming to high school kids. It's a beautiful work, and I think it's going to get a lot more popular before interest wanes.

Having said that, Java has some advantages over Scheme in constructing particular types of abstractions. You know that Carl Sagan quote (paraphrased), "in order to bake a cake you must first create the universe"? Well designing a decent class hierarchy is like that with Scheme. That's *fantastic* for the purposes of SICP, where they want to explain to you *how* something like a type system works from the bottom up. But once you know that (and if you're programming something other than compilers in the "working world"), you don't need a language that allows a million different types of type systems, all of which are just a little bit different.

That rigidity that dooms Java is exactly the quality that the business world values.

By Kalani at Thu, 2004-12-23 17:01 | login or register to post comments

Business world and short-sightedness

That rigidity that dooms Java is exactly the quality that the business world values.

Well, except that as software complexity increases, the probability of java's object system appropriately matching that of the business rules approaches zero. Then, you have no choice but to start kludging together classes that aren't really supposed to be classes, etc.

Features of languages like Scheme, ML and Haskell help the programmers get the level of discourse in the source code closer to the level of discourse of the problem, while features in Java force the programmers to limit the scope of their level of discourse. This only takes you so far.

Add to that the fact that in decent languages, object systems are really tiny in terms of source code size, specially when compared to the whole set of business rules, etc, and you see that the effort to get a decent (ie. one that matches the rules properly) abstraction layer really does pay off. Notice that you don't have to actually build one object system yourself. As long as you're able to tinker with it, a la Smalltalk, and PLT's object system, you should be good to go. (assuming, of course, that 'objects' are the proper abstraction on which you want to build your software)

Can you tell I really really love SICP and EOPL? :)

By Carlos Scheidegger at Thu, 2004-12-23 18:28 | login or register to post comments

Well ...

Maybe you missed the part of my post where I too said that I really love SICP.

I completely agree that conforming the language to the problem domain is a nicer approach than conforming the problem to the language. I appreciate the value of this approach.

But in a large organization where N groups might work on essentially the same problem domain, coming up with N different incompatible object systems compounds integration problems. And that doesn't even touch the issue of the damage that poor programmers do (again, I'm not arguing that I like Java -- I don't -- but I'm trying to explain why it exists and is so popular in the first place).

By Kalani at Thu, 2004-12-23 19:01 | login or register to post comments

N groups

(First: based on your first paragraph, I apologize if I sounded harsh. Stupid non-native language issues. It wasn't my intention at all)

The way I see it, those N groups will necessarily have to agree on a certain protocol to communicate with each other. Java forces them to do it with classes. If, for example, they used a language that allowed first-class modules, true closures, etc, they could actually build the right thing, rather than kludge it with classes, the best way they can.

Regarding poor programmers: They're gonna jeopardize your projects either way. Implying Java is a protection against them is dangerous, because it assumes that the language is imbued with decent mechanisms for communicating and enforcing "contracts". If we were talking about Haskell or ML, I'd (maybe) agree. But Java? I don't think so.

Some people argue that popularity should influence the language choice toward Java and friends, but I've read at least a couple of times that going with non-"mainstream" languages can even work to your advantage (DARCS and Haskell, Paul Graham's essays and Common Lisp, and I think Kent Beck talks about the advantages of Smalltalk's nonpopularity too) In my opinion, Java's popularity comes from 1) a tremendously succesful marketing campaign, 2) a huge library and 3) a garbage collector. It's really unfortunate that the real reason Java should be praised (bringing GC to the "unwashed masses") is by far the most overlooked.

By Carlos Scheidegger at Sun, 2004-12-26 19:37 | login or register to post comments

Learning curves...

On the outside looking in, Scheme equals Lisp. I know that's naive, but it's an opportunity to point out this stuff is 40+ years old.

John McCarthy, the father of Lisp, claims Lisp has become simpler over time. I can't attest to this, but do wonder if Lisp's "simplicity" keeps it on the shelf. Modeling the world with lists of atoms is pretty uncomfortable for the uninitiated.

Maybe Java is successful because it mimics an ontology that people (even the unwashed) can related to. Put another way, Java's initiation process is shallower than Lisp's.

Consider Lisp's "eval". "eval" permits a program to define a new function and then execute it as part of the original program. Simple enough from the outset, but this feature really deserves a "Wow!". Imagine teaching beginning Java students about Universal Turing Machines...Offhand, I think it would make relating the class/instance paradigm seem trivial.

- Levi

PS> You know the full text is on line, right?
http://mitpress.mit.edu/sicp/full-text/book/book.html

By levicook at Tue, 2004-12-28 19:49 | login or register to post comments

Reflection on Eval

I write code in Scheme and Lisp on a daily basis. I'm not convinced I've used eval this year. Off hand, I think eval is best compared to Java's Reflection capability: a powerful and quite specialized tool, but rarely used.

Lisp's other abilities to dynamically create procedures whose text is never seen by the programmer -- macros, first class functions -- are used all the time.

By bts at Thu, 2004-12-30 18:39 | login or register to post comments

Lisp vs. Scheme, Re: Reflection on Eval

My impression is that Schemers tend to avoid eval but that Common Lispers find functions like EVAL, LOAD, and COMPILE indispensible. I'm thinking of the contrast between SICP and EoPL's style of writing whole interpreters or compilers with the way PAIP and [Steele constraints] just change the host environment instead. (The new DSL community have terms for these styles I believe.)

I have seen Scheme code using the same techniques so maybe the biggest difference is in the literature.

And a note to newbies: SICP is great for mind-expansion, but whatever you do don't mistake it for a book on software engineering. It's really hard to debug when there's no proper error checking and everything just looks like a #<procedure>. :-)

By Luke Gorrie at Thu, 2004-12-30 22:10 | login or register to post comments

SW Eng.

A long time ago I asked here what an EOSE (Essentials of Software Engineering) book would look like (i.e., a book of that depth and educational value) .

No such book exists, and as far as I can tell looking at the field of SE none will be available anytime soon.

So while I agree that SICP (and CTM) won't teach you about building big real life projects, I think your best bet is to expand your mind as much as possible, and then learn by watching more experienced programmers ("hackers") and by working with them on real projects.

By Ehud Lamm at Thu, 2004-12-30 22:23 | login or register to post comments

Case studies

I'm with you. I also think that some case studies (by e.g. Norvig, Steele, Brinch Hansen, Wirth) do a good job of teaching techniques that you'd normally have to learn on-the-job. I'd like to read more books like these (recommendations welcome).

Happily I recently joined an exciting new Erlang startup and have lots of interesting code to read. :-)

By Luke Gorrie at Fri, 2004-12-31 15:30 | login or register to post comments

Aye

Case studies are useful. Alas, writing good case SW design case studies is very hard. Perhaps we need to set up some case-studies writing workshops, like the ones for patterns. I have some hopes for the Architecture Handbook (Booch), but we'll have to wait and see.

Congrats on the new job...

By Ehud Lamm at Fri, 2004-12-31 15:40 | login or register to post comments

Lambda the Ultimate

User login

Navigation