Slashdot Mirror

there seems to be no other major technical programmers' magazines left standing.

There is: The Perl Review. (And like The Perl Journal before it, is has nice cover pictures too).

Strange enough, I now remember that my first memory of Dr.Dobbs is an interview of Larry Wall, which I read there in the nineties...

Well, Web Techniques was a great magazine - until it became "New Architect" (puke) and died a death. The Perl Journal was another great read - until it got swallowed up by DDJ. These days, there's still a few good ones - The Perl Review for example, but yes, most are just humungous adverts. These are great for the bathroom/commute (not if you're driving though!) - two places where I won't use a laptop :) So I can continue to geek when not at the PC. So there is a small market for them :)

Here's a review I wrote of this book for The Perl Review, issue 2.0:

There's a lot of good writing in the world. Some of that has to do with software. So hey, why not put some of it in a book?

Therein lies the apparent purpose of The Best Software Writing I, brought to us by software bloggerexpertpundit Joel Spolsky. Beyond that broad categorical relationship, it's hard to see how everything in the book relates, either to each other, or to the reader.

I like tables, but I don't buy a book with various articles written about tables. If I want to build a table, I buy a book on building tables. If I want to look at antique tables, I'll buy a book about antique tables. I won't buy a book about tables and hope it has something I am interested in.

I don't want to say this is a bad book, because that might imply the content is bad, and hardly any of it is. Some of it to me is quite boring--which highlights my main problem with the book--but most of it is quite good.

The opening chapter by Ken Arnold on why languages should enforce strict whitespace use at the compiler level was useless. And the final chapter, by "why the lucky stiff," which attempts to teach Ruby with a few short guidelines and cartoon foxes, had me skimming the pictures before gratefully reaching the conclusion.

But in between there was some really good stuff, including Paul Graham's OSCON 2004 keynote address about what makes a great hacker, Raymond Chen's piece on why Windows retains backward compatibility for broken apps, and danah boyd's article about social software. There's an insightful piece by Clay Shirky about how to encourage good discussion and discourage bad discussion online, a perceptive article by John Gruber about how the browser's location field is the new command line, and an amusing PowerPoint presentation outline by Aaron Swartz about why you shouldn't use PowerPoint.

And you know they are good, because each piece has an introduction by Spolsky, telling you not just how good they are, but that Spolsky thought of it first. Some of the articles even refer back to Spolsky, which is nice, in case you forgot how great he is. Not that other people don't engage in similar practices: the last three pieces I mentioned above are related to me, in that Shirky favorably mentions Slashdot (where I work), and Gruber and Swartz are my acquaintances, and that's a big part of why I singled them out for mention. It just seems to me that Spolsky shines the light far too much on himself, to make the book almost as much about himself as the writing.

What's especially odd is that this book couldn't appeal to people who are not already into software, who don't already know who some of these people are, or who are familiar with the issues they are writing about. They won't get any of it. Yet the book is littered with footnotes from Spolsky explaining things like "iTunes" ("Apple's online music store") and "dev" ("Dev = developer = an actual computer programmer").

Which brings me back to the point of the book. It's not for non-software people, and it is not for software people, including those who enjoy this sort of thing so much that they already read it when it went online.

So what is the point? I don't know. Maybe it is just to make more of a name for Apress, by saying they published a book by known software bloggerexpertpundit Joel Spolsky.

Perl has been gradually tacking on closures, declarative programming, metaprogramming and other lisp-like features to the language, in a piecemeal fashion. But Perl will NEVER have a powerful, simple macro system like Lisp, since Perl's fractal syntax makes that totally impractical.

-Don

Interview with Mark Jason Dominus

The Perl Review: Why did you write Higher Order Perl?

Mark Jason Dominus: My main reasons were as I explained in the preface of the book: It had become increasingly clear to me that most Perl programmers seemed to be writing C programs in Perl, and that it was possible to do a lot better than that. We have a really good tool, and it's a shame that we're using it the same way that we have to use the old crappy tool.

[...]

TPR: At the start, you compare Perl, Lisp, and C and say that Perl is more like Lisp than C. Do you think Perl would be as powerful if it was closer to C? Could it be more powerful if it was closer to Lisp?

MJD: I don't think anyone thinks that Perl would be more powerful if it were closer to C. In the 1980s, Unix sysadmins wrote in C and in Bourne Shell, and Perl has largely replaced both of those for those sorts of tasks, leaving C a fairly small niche.

In the preface of Higher-Order Perl, I said that Perl shares six of Norvig's "seven features that make Lisp Different". The seventh one is the one that Norvig calls "uniform syntax". That's the one that led Larry to say that Lisp looks like oatmeal with fingernail clippings mixed in. But it enables language features that are so powerful that they're almost unimaginable to people who haven't studied Lisp. It's really hard to do justice to the huge benefit that Lisp gets from its simple and uniform syntax, which Perl just doesn't have at all. Any attempt to construct Perl code dynamically is fraught with error, and we take it for granted that it won't work. For example, in the documentation of the Perl6::Subs module that was recently released, Chip Salzenberg says "This module is a source filter. Source filters always break." And I think that's true. But source filters in Lisp are easy to write, and they never break. Lisp's main assignment operator, "setf", is implemented with a source filter. So if Perl were more like Lisp in that sense, I think it might be more powerful. On the other hand, I don't think it would be very Perl-like.

Sam Tregar's Writing Perl Modules for CPAN is an excellent introduction to the world of modules, and the community of Perl and open source software in general. Tregar surveys all aspects of module installation, creation, documentation, testing, packaging, distribution and maintenance in a clear, readable style.

Sam Tregar's Writing Perl Modules for CPAN is an excellent introduction to the world of modules, and the community of Perl and open source software in general. Tregar surveys all aspects of module installation, creation, documentation, testing, packaging, distribution and maintenance in a clear, readable style.

If you want you can code directly in PASM (Parrot Assembler) or help write some of the tools that parse real languages and emit PASM. It's not a particularly small assembler like 6502 (but it can be if you really want!) but still has that small-system feel.

I got my Assembler fix this past spring with Parrot BASIC (link is PDF).

The Perl Review is exactly what you describe: a Perl journal, distributed only as PDF at the moment. The publishers hope to get it on paper one day, but they wanted to get it started., so the first 5 issues are already available.

The Perl Review is exactly what you describe: a Perl journal, distributed only as PDF at the moment. The publishers hope to get it on paper one day, but they wanted to get it started., so the first 5 issues are already available.