This blog was viewed about 41,000 times in 2010.There were 7 new posts, growing the total archive of this blog to 148 posts.
These are the posts and pages that got the most views in 2010.
A Haskell bookshelf March 2006
7 comments
A Scheme bookshelf January 2007
18 comments
Scheme lectures, mostly December 2009
7 comments
Programmers go bananas March 2006
23 comments
Geiser May 2009
35 comments
From R2RS:
Data and procedures and the values they amass,
Higher-order functions to combine and mix and match,
Objects with their local state, the messages they pass,
A property, a package, the control point for a catch–
In the Lambda Order they are all first-class.
One Thing to name them all, One Thing to define them,
One Thing to place them in environments and bind them,
In the Lambda order they are all first-class.
(Hat tip Mark H Weaver over at guile-devel)
I guess this is old hat for most of you, but, anyway, here‘s a mildly amusing page by Jamie Zawinski (he of the amusing homepage) on the “sanitization” process that Netscape’s code suffered prior to its release. Says Jamie:
When we created mozilla.org and released (most of) the source code to Netscape Confusicator 4.x, Netscape’s lawyers made us go through a big “sanitization” process on the source code. [...] they also made us take out all the dirty words. Specifically, “any text containing vulgar or offensive words or expressions; any text that might be slanderous or libelous to individuals and/or institutions.”
There follows a list of heavy swearing code snippets and comments. Strikingly, one of the censored words is hack. WTF?
I’ve just stumbled upon (via a post in John Cook’s blog) an old article back at kuro5hin entitled the greatest program ever written. It describes 1k chess on the ZX81, a program capable of playing chess on the Sinclair ZX81, a computer endowed with a total memory of 1024 bytes, and written by David Horne. I didn’t believe it either, until i saw it by myself. Kids these days!
Update:I’ve just learnt, thanks to a comment below, that there’s actually an earlier chess program, written by Peter Jennings, of similar characteristics: Microchess for the Kim-1 computer. The linked webpages contain lots of information about the program, including listings. Pretty fun stuff.
Today is the anniversary of programming musings: it’s been 4 years, 141 posts, 429 comments and almost 300,000 visits since i wrote my first post. A drop in the web ocean, i know, but enough to make waves in my local pond, and much more than i expected. These are the twelve most visited entries so far:
Thanks!
If you’re still thinking about reading SICP, here’s an article, written by Abelson and Sussman shortly after publishing the first edition of the book, that may dispel your doubts: Lisp: A language for stratified design. It’s a quick distillation of some of the central themes discussed at length in SICP, with accompanying code. Some of them may seem old hat these days (the article was published in 1987), but they’re as relevant as they were back in the day, and it’s difficult to find them exposed in as good (let alone a better) a way. Its dozen pages are full of quotable pearls of wisdom. For instance, right from the start:
Just as every day thoughts are expressed in natural language, and formal deductions are expressed in mathematical language, methodological thoughts are expressed in programming languages. A programming language is a method for communicating methods, not just a means for getting a computer to perform operations–programs are written for people to read as much as they are written for machines to execute.
and later on
[...]if a methodology is to be robust, it must have more generality than is needed for the particular application. The means for combining the parts must allow for after-the-fact changes in the design plan as bugs are discovered and as requirements change. It must be easy to substitute parts for one another and to vary the arrangement by which parts are combined
The examples include Henderson’s picture language, which motivates a discussion of metalinguistic abstraction (or DSLs, as rediscovered these days):
Part of the wonder of computation is that we have the freedom to change the framework by which the descriptions of processes are combined. If we can precisely describe a system in any well-defined notation, then we can build an interpreter to executed programs expressed in the new notation, or we can build a compiler to translate programs expressed in the new notation into any other programming language.
There’s also a synopsis of the implementation, in Scheme, of a rule language geared at simplifying algebraic expressions, and the accompanying interpreter. The conclusion is that you want to write languages and interpreters, in a variety of paradigms; and that you probably want to write them using Lisp:
The truth is that Lisp is not the right language for any particular problem. Rather, Lisp encourages one to attack a new problem by implementing new languages tailored to that problem. Such a language might embody an alternative computational paradigm [...] A linguistic approach to design is an essential aspect not only of programming but of engineering design in general. Perhaps that is why Lisp [...] still seems new and adaptable, and continues to accommodate current ideas about programming methodology.
As true today as it was twenty odd years ago, if you ask me.
Last Wednesday, FLIB’s kick-off meeting took place at Oblong’s Barcelona lab, with a dozen deliciously crazy people attending.
Due to lack of time and seriousness on my side, the main talk was given by Jos, who gave us an overview of his work with PLT Redex to model lambda calculus. Redex provides an embedded DSL to create context-sensitive term-rewriting systems, if you’ll pardon my buzzwording. In a hand-waving nutshell, term-rewriting systems are syntax-rules on steroids: one specifies a set of rules for transforming (rewriting, or reducing) terms to other terms according to their structure, possibly depending on context. Jos has a very nice example of such a system taken from GEB (Best. Book. Ever.), the MIU formal system, whose formal rules can be expressed in Redex as:
(--> (‹symbol› ... I) (‹symbol› ... I U)) (--> (M ‹symbol› ..) (M ‹symbol› ... ‹symbol› ...)) (--> (‹symbol›_0 ... I I I ‹symbol›_1 ...) (‹symbol›_0 ... U ‹symbol›_1 ...))
that is, if you find a trailing I, you can append U; if you find M, you can duplicate the rest of the string; and three consecutive Is can be reduced to a single U. Now, you can start with a given string (or axiom) and apply the rules to produce new ones (theorems). Note how the rules are contextual, and how there’s in general more than one that is applicable. Redex will do that for you, creating a tree with all possible reductions.
Of course, there’s more to Redex than this simple example. For instance, it’s been used to provide an operational semantics for R6RS. Jos’ work is somewhere in the middle: while the reduction rules in lambda calculus are even simpler than in MIU, issues of scope quickly complicate things; moreover, Jos explores classical topics in lambda calculus, such as reduction to normal form, fixed point combinators or Church numerals to name a few, always using Redex (the staggering conceptual richness embodied by the humble premises of lambda calculus always amazes me). All in all, a beautiful 32-pages long paper, with accompanying code, that serves as a nice hands-on introduction to both lambda calculus and Redex, and which you can get at Jos homepage.
After the presentation, we devoted some time to talk about the future of FLIB. Monthly presentations, lightning talks on demand and a reading group. I like the latter a lot, because having a physical meeting among readers every month is an excellent way of keeping reading groups alive. We’re still deciding on our first book, but PLAI followed by LiSP seems to be gaining momentum right now. Another nice thing about the reading group is that it opens the possibility for people not able to come to the meetings to participate: just subscribe to our mailing list and join the discussions about the book du jour.
And then we just sat down around a table with some beer and snacks, and start talking about life and programming languages. I found it very stimulating because of the varied people’s backgrounds: we had guys from academia and industry; ones just starting their graduate courses, others with twenty years of teaching under their belts; people from several different countries; schemers obsessed with call/cc, smalltalkers, python experts, C++ loathers and programmers who secretly enjoy it, perlmongers and ruby or haskell aficionados. But, they all, people with a passion for programming: i think everybody was happy to have found a bunch of keen souls.
Perhaps it was inevitable that much of the discussion gravitated around our frustrations as programmers and teachers, given the sad state of computer science in both industry and academia, and the insurmountable barriers for adoption faced by the kind of languages we like. But, with that out of the way, here’s hope (as expressed by Andy after the meeting) that future meetings will concentrate on brighter fields.
A great evening, and no mistake. I hope you’ll join the fun next July 22nd!
Update We’ve moved the date of our first meeting to June 17th, so you’re still in time to join us! If you want to follow our adventures, you can also ask for an invitation to our mailing list.
The other day, Andy and I met Jos, an experienced schemer who lives near Barcelona, with the idea of having lunch, talking about Scheme, and create a Scheme Users Group. After a bit of discussion, we agreed on widen the group’s scope, and start what we’re calling Fringe Languages In Barcelona (FLIB). The plan is to conduct periodic meetings with a main presentation followed by some lightning talks (the latter were a complete success at ILC, and we’d like to try and see how they work for us), with as much discussion interleaved as we see fit. We’ll have some refreshments available and, since we’re meeting in the very center of the old city, visits to pubs or a restaurant for dinner and further socializing are to be expected.
As i said, we’re expecting much discussion about Scheme and Lisp, but we’re not ruling out by any means other fine languages. For instance, the talk for the inaugural session (scheduled June 10th17th, 7:30 pm) is entitled The implementation of FUEL, Factor’s Ultimate Emacs Library, and it will include a short introduction to Factor (yes, i am the victim speaker). Jos will come next, the same day, with a lightning talk about PLT Redex. We have free slots for more lighting talks: you are invited not only to come, but to give one if you’re so inclined. This being our first meeting, there will be also some time for logistics and organisation.
So, if you’re near here by then, by all means, come in and join the fun:
Calle del Pi 3 Principal Interior (first floor)
Barcelona
Not really needed, but if you’re thinking about coming, sending me a mail beforehand will help us to be sure that we’ve got enough food and drinks.
We’re looking forward to getting FLIB started, and we’re sure that at least grix more fringers are coming! Don’t miss it!
Back at the PLT Scheme blog, Matthias Felleisen has just posted an entry on the rationale behind the limitations imposed to DrScheme’s REPL, namely, the inability to evaluate individual expressions. If you’ve read this blog before, you won’t be surprised to know that, as much as i respect Matthias, i totally disagree with his rationale. Well, not totally: let me explain. Matthias’ point is that allowing on the go redefinitions often leads to inconsistent states of the running image, which in turn leads to confusion and much head scratching, even when that head belongs to, say, Dan Friedman (let alone Matthias’ students’ heads, or mine, for that matter). Therefore, we’d better ban the offending feature from the development environment, right?
I’m willing to concede that evaluation of individual expressions is as dangerous as Matthias’ experience suggests, or even demonstrates. But i strongly take issue with his conclusion. Incremental development might be dangerous, but it’s also a powerful tool, and incredibly fun (all three come together most of the time, don’t they?) as any Common Lisp, Factor, Smaltalk, Scheme48 or Guile (to mention a few) hacker will tell you. As yours truly has been telling you since this blog started. Or PLT hackers, for that matter: Matthias’ post originates in this interesting email exchange, with people giving good reasons on behalf of an incremental REPL (think, for instance, of manipulating large chunks of intermediate data). I want this power. I want the fun. I’m willing to take the risk.
In my opinion, this is a good illustration of one of the points that Gerry Sussman was making in his talk on robust systems at ILC. For instance, injudicious use of generic functions will quickly paint you into a corner; but, at the same time, this sharp knife will cut for you beauties such as the scmutils library used in SICM, or help you in taming evolving requirements. Should we be deprived of generics for our own good?
Now, don’t take me wrong. I immensely appreciate the warnings and advice of people who, as Matthias, have much more experience and knowledge under their belts than i’ll ever have. I’m willing (eager, even) to learn from them. But i don’t understand why warnings should become prohibitions. I’m not dissing the work of Robby implementing DrScheme’s ‘restart-the-world’ functionality: it’s great to have it there (in fact, having it there as a safety net is yet another reason for allowing the incremental REPL variety). And i would have no objection if not having an incremental REPL were due to technical implementation details. What i fail to see is why undercutting the functionality of my tools in the name of ‘my own good’ is the right thing to do. I hated it when my parents did that to me ;-).
Let me start this new programming musings epoch with a personal (and, fear not, short) note: since last Friday, i no longer work at Google. The reasons are basically the same as other people’s and can be summarised with one of my favourite quotations:
Always have a vision. Why spend your life making other people’s dreams?
-Orson Welles (1915-1985)
As it happens, Google’s vision is not my vision and i don’t share their dreams. I guess cults make me feel uneasy too. Starting on August, i’ll share a nice office in Barcelona with hacker extraordinaire Andy Wingo in an exciting new adventure. Stakes are high, plans are to change the world (only plans likely to fail are worth trying; travels to Ithaca, you know the drill).
I’ll miss the city and some of the people (too old for caring about perks), but the decision was not that hard. I just hope that, many years from now, i’ll open a new blog post citing Robert Frost:
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I –
I took the one less traveled by,
And that has made all the difference.
