RFC on an online book

Hello.

I feel like I'm entering the lions den here, but for the past couple of years I've been working on an online book: Exploring Programming Language Architecture in Perl and I'd be very grateful for any comments, criticisms or suggestions on it.

It's purely a hobby project, not for profit. I feel that it may be pitched a little high for your average perl programmer, and it's far too "folksy" for a serious academic text, but I've had fun writing it and I learnt a lot in the process too.

So far it covers basic lexical closure, objects and inheritance, continuations, trampolining, and logic programming using failure continuations and backtracking. I plan to add chapters on garbage collection, types, and Compilation.

Please don't jump to conclusions from the first couple of chapters that it is a lame implementation of Scheme, I get to a proper cons cell structures and the like later on. The purpose of the first chapters is just to get a working interpreter in terms that the average Perl programmer can understand with little effort.

I freely acknowledge that it leans rather too heavily on the classic SICP and EOPL, hopefully I can remedy that in subsequent iterations.

I'm currently working a compiler (not yet on line) targeting a virtual machine also written in Perl. I fully realize that "my first compiler" is not a fit topic for a book, so I'll be throwing that away as a learning exercise and starting it again at some point.

Please be kind.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

No offense...

... but whenever I read the title I get visions of "Exploring Building Architecture in Rubber Bands and Chewing Gum".

Surely there must have been something better than perl that you could have used?

Perl 6?

A book like this seems like a great way to explain some of the interesting aspects of Perl 6 (and why not do it using Perl 6 instead of plain old 5?), rather than (and I mean this in the nicest possible way) implementing bits of Scheme again.

Scheme Again

Perl6 will be great if it ever arrives, I know there are some trial implementations of it, but I wanted to use a language that most programmers would have readily to hand.

Re "Scheme again", I feel a little misunderstood. As I mentioned in a reply to another post, the point of the book is to bring some of these wonderful programming language concepts to a much wider audience. I fully admit to just re-hashing old and (academically) well-known ideas, but by using Perl I can get the message across to people who might not otherwise rise to the challenge. I jokingly refer to the book as "Programming Language Architecture for Dummies" but perhaps that is not too far from my real intention.

In defense of rubber bands...

My choice of Perl was an easy one.

I'm very comfortable with that language. It is by no means my only language, but all of the constructs that I needed to discuss in the book found convenient expression in Perl.

The audience is much larger. There are far more programmers out there familiar with Perl than with ML, Haskell or even Scheme.

I've often been asked to recommend a good book on programming languages, but when I point to SICP or EOPL the response is almost invariably "but I don't know Scheme".

I'm perfectly willing to accept that Scheme, Haskell, ML etc. are better vehicles for expressing programming language concepts, the point is that very few people know (or are willing to learn) those languages.

This book really is an attempt to bring all these wonderful language concepts to the attention of a much wider audience, so the choice of a mainstream highlevel language seems a perfectly reasonable one to me. I would even have considered PHP if PHP had closures.

P.S. Although I don't want to get into a language war per se, I feel that your categorization of Perl as "Rubber Bands and Chewing Gum" is a little unfair. Perl certainly is a pragmatic language (its author describes it as "pathologically eclectic") but it is perfectly capable of the tasks set for it. It has no single underpinning philosophy other than being practical.

Don't forget concurrency!

I'm very happy to see nice chapters on nondeterministic programming and logic programming. But your thread chapter needs a bit of work! If I may make a suggestion, you have the opportunity to say good things about concurrency if you handle things right. Concurrency is not just threads and state. You can talk about message passing and declarative dataflow. One approach that I can recommend is to use the examples and abstractions of CTM as guidelines. For example, a Python programmer defined active objects by following the definition in Chapter 5 of CTM. Declarative dataflow is simple too. Just add single-assignment variables with three operations: X={NewVar} creates a new variable X, {Bind X V} binds X to V, and {Wait X} waits until X is bound. If you put these operations inside other operations (like arithmetic) then dataflow becomes transparent. If you put them in functional and list operations (like the ones in your book) then you get all the advantages of declarative concurrency.

Re concurrency

You are right of course. That short chapter on threads came out of an "oh wow this is so easy!" revelation just after I'd finished the previous chapter on continuations, I hadn't thought to fill it out and take it further. I'll certainly take a look at CTM (this shows the level of my expertise -- I wasn't aware of that book) and see where it takes me.

Thanks!

[edit]P.S. having bought the book I realize you're one of the authors. My comment about not being aware of the book was not intended to sound disparaging, just an indication of my limited knowledge. The book is very good by the way.