Tim Daly, Axiom’s lead developer, has a couple of things to say about building large applications in Lisp and on picking a language:
Measure your OODA loop [observe, orient, decide and act loop] in all the languages you know. See which one cycles fastest. I’d bet that’s your favorite language.
I also happen to like the movies he recommends ;-)
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!
I’m back from ILC 09, slowly digesting all i lived there. This was my first Lisp conference and my first visit to MIT, a place marked with red big letters in the atlas of my private mythology. And it wasn’t only about places: suddenly realizing that you’re sitting next to Richard Greenblatt, or enjoying Gerry Sussman’s talks in the flesh, was quite an experience, with an almost eerie feeling attached to it.
There’s a problem in meeting your myths: real life is almost never up to the task of meeting one’s idealizations. But this was not the case; i enjoyed every minute, not a tinge of disappointment to be felt. Lisp has been around for quite a while and its history is an important part of computer science’s history. That history comes life in the ILC, and you get a chance to share with the people that were there back in the day, the people you read about in books… i’ve wished many times i was there, and these days in Cambridge i’ve been as close to those halcyon days as i can expect to ever be. Living history, what a feeling.
Had i to single out just one speaker, that’d have to be Gerry Sussman. I just kept finding myself resonating in a deep way with his thoughts. For instance, during the panel on the future of Lisp, conversation revolved around how to keep the language popular and apt for commercial applications. Gerry stepped out to point that that was all very well, but that we shouldn’t forget that one of the key aspects of programming languages is to what extent they allow us to extend our problem-solving abilities by providing new ways of expressing and talking about problems (as Dijkstra once said: Lisp has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts). Dead on, if you ask me, although unfortunately nobody seemed to have anything else to add, and the debate returned to the far less interesting popularity issues (well, yes, the conference wasn’t perfect after all).
Next day we were in a kind of tongue-in-check debate provocatively entitled Are macros a menace?. Richard Gabriel was on the wrong side, and arguing along the lines that macros were akin to language design and that he’d rather not suffer the consequences of letting your average software engineer undertake such a complex task. Gerry’s intervention at this point made me nod again: if we cannot trust our software enginneers to proficiently use the tools of our trade, there must be something wrong in the way we educate them; only those able to judiciously use them should get a diploma, to begin with. That’s exactly how i felt during my period as a CS teacher, as i tried, rather clumsily, to explain in one of my first rants in this blog. It feels great to be in such a good company.
Then there was this unplanned mini-talk on why MIT has replaced the SICP-based introduction to programming with something about robots using Python. You can read a nice synopsis of the reasons Sussman gave in Andy’s blog (together with summaries and comments of many other talks). It was nice in a kind of sad way: at the end, while answering a question, Gerry mentioned that this new computing world was not his, and it wasn’t one that he liked [0]. ‘But’, he said, ‘that’s because we’re old farts’. Although i’m younger than him, i like much better the kind of world that gave rise to SICP, and spent the rest of the evening feeling like a sad, old fart. I must say, however, that the ideas SICP grew upon, that simple world where you built up complexity out of small pieces and system that you understood completely, have much to offer to new generations. We should not dismiss them in the name of modernity.
Besides those cameos, Gerry had two official appearances in the regular conference programme, namely, one invited speech on robust systems design and a lightning talk. (The latter were 5-minutes long presentations–with Guy Steele and his chronometer strictly ensuring that that was actually the case–followed by a 2 minutes Q&A part, while the next speaker was setting up her laptop. This formula worked great most of the time, forcing the presenters to squeeze their brains in order to capture as much content, sense and, in most cases, fun as possible in such a short time. We had a living confirmation that working under severe constraints is a great creativity boost.)
In the invited speech, we had the opportunity of hearing more about Gerry’s ideas on what makes a system robust. I say ‘more’ because he made public a paper on the subject some time ago, and, actually, his ideas on these issues can be traced back to, for instance, the SICP video lectures, where he already exposes the general strategy to tackle the problem: in order to make a system robust, you don’t want to solve a strict, narrowly specified problem, but a whole family of them (or, if you have a very crisp specification, a class of problems in its neighbourhood). That way, when the problem to be solved varies in small ways, your whole solution accommodates to the new situation by small variations. The solution is not brittle. To attain such a flexible behaviour, we need to build our system upon components that are lenient on the inputs they accept and as sharp as possible in the outputs they produce. Ways to attain the above goals include metalinguistic abstraction (creating a language tailored to the problem domain), use of generic interfaces, degeneracy or non-deterministic search in the solution space.
Generic functions were nicely demonstrated with examples from the library used in SICM (and the delicious Functional Differential Geometry). We got the warning that using generics this way is dangerous. But they’re powerful, and one needs powerful methods to solve challenging problems; one needs to know what one’s doing, but that’s part of what we’re supposed to be good at, right? Sussman kept smiling and saying ‘beware, this is a very dangerous thing to do’. There was also an almost off-the-record comment to the effect that one of the missed opportunities in Lisp’s design was its not defining all its primitive forms as generics (converting it definitely in the most dangerous language around).
Degeneracy (using completely different ways for computing the same result) was illustrated, as much of Sussman’s thinking on robust programming, by examples drawn from biological systems (in this talk, it was frogs most of the time). You can find many other examples of this sort of parallelism between computing and biological systems in the paper linked above, a line of thought that i find mixes well with the handful of metaphors i use to reason about my job as a programmer. In particular, it sort of connects with my bias towards living systems such as Lisp or Smalltalk’s, where one is evolving more than designing and implementing the program; which in turn mixes well with the ideas of latent typing and late binding, present in those highly dynamic environments (Self, Factor, and APL (as demonstrated in this game of life video (unintended pun intended)) are in the same league). Much more than with beautiful but extremely rigid ones based on static typing, such as Haskell’s. (That’s why i keep coming back to Lisp after my Haskell excursions, or why i find R6RS so disappointing. Or, if you’ll pardon my keeping on mixing methaphors, why i prefer healing rather than practising autopsies.)
Another venue to flexibility mentioned in the talk are constraint propagation networks in which multiple sources contribute to defining the values of each state variable. You get that way the possibility of partially defined values, that can be nonetheless useful by themselves, depending on the computation you’re performing. Propagator networks also work as additive computation machines able to refine coarse inputs into correct solutions for problems specified as a set of constraints. One of Sussman’s students, Alexey Radu, is actively working on propagators, building on work inititated back in the day by Guy Steele. You can find an extensive report and nice, working Scheme code here.
Finally, Gerry gave a lightning talk with yet another piece of food for thought. The rub of it was drawing our attention to the possibility of exploiting a posited parallelism between the theory and methods to solve differential equations on the one hand, and programs on the other. There’s a way of approaching solving a differential equation that is, if you will, algebraic in nature: one manipulates algebraically expressions to simplify and eventually obtain a closed form solution, or, if that’s not possible, creates numerical approximations to evolve the boundary conditions in the state space as a function of discrete time steps. You end up that way with something that works as a solution, but, most of the time, without a deep understanding of the traits that make it a solution: in the spirit of the robust design ideas sketched before, we should probably be asking for more qualitative information about how solutions behave as we change the boundary or initial conditions of our problem. As it happens, matematicians have a way of analyzing the behaviour of solutions to differential equations by studying their Poincaré maps and sections, which are views into the orbits followed by the solutions in their state space. Many times, you don’t have to solve exactly the differential equation to predict its qualitative behaviour (e.g., is it bounded? is it periodic?) in state space, and get insight on how it changes in presence of perturbations. The analogy with computing processes is clear: most of the time, we narrow our efforts in finding, so to speak, algebraic solutions to our computing problems: the program-as-text is the analog to the process of finding an exact formula for the solution of a differential equation. What we’re missing, according to Sussman, is a way or reasoning about the qualitative features of our programs à la Poincaré, i.e., a way or reasoning about programs in the state space of their outputs, beyond the mechanistic algorithmical details. Gerry admitted that he didn’t know how or in what form this kind of reasoning would proceed, only that his hunch is that it must possible, and exhorted us to find the way.
ILC09 would have been worth it only for those talks, but there was much more: don’t miss the next one!
–
[0] As rightly pointed out by Dan Weinreb in his comment below, Sussman endorses the changes in the new curriculum, though. His post on this issue is worth reading too.
My first seven moths in Zürich have been packed with pleasant surprises. Among them, having the opportunity to meet two developers of two of my favourite lisps: Martin Gasbichler, of scsh‘s fame, and Juho Snellman, of sbcl‘s. I’ve already enjoyed several pleasant discussions with them (as well as with some co-workers interested in lisp), and it was only natural to go one step further and found the Zürich Scheme/Lisp Users Group.
The zslug will have its inaugural session next Monday 25th, 18:30 at The Lion. Besides beer (the raison d’etre of any users group), Juho will talk about the implementation of sb-cover, a code coverage tool for Common Lisp. If you happen to be in Zürich or whereabouts by then, just come in and join the fun!
Update: The actual address of The Lion is Oetenbachgasse 24. Hope to see you there!
Another Glitch in the Call
(Sung to the tune of a similar Pink Floyd song.)
(Contributed By Knappy 8350428 @ UWAVM)
We don’t need no indirection
We don’t need no flow control
No data typing or declarations
Hey! You! Leave those lists alone!
Chorus:
All in all, it’s just a pure-LISP function call.
We don’t need no side effect-ing
We don’t need no scope control
No global variables for execution
Hey! You! Leave those args alone!
(Chorus)
We don’t need no allocation
We don’t need no special nodes
No dark bit-flipping in the functions
Hey! You! Leave those bits alone!
(Chorus)
We don’t need no compilation
We don’t need no load control
No link edit for external bindings
Hey! You! Leave that source alone!
(Chorus, and repeat)
Babar Kazar has compiled an awesome (and i mean awesome) list of Classic Texts in Computer Science. There one finds almost every paper to read if one is serious about computers. The list is too long to put it all here, and virtually all of them are interesting in one way or the other, so i won’t make a selection right now: just take a look at them, and try to pick one: i bet you’ll have a hard time deciding!
Although it’s a bit late for new year’s resolutions, here is mine: i plan to at least skim through all these texts, read many of them, and, of course, keep you informed.
On December 3 and 4 of 2004, the Computer Science Department at Indiana University hosted a conference on the occasion of Dan Friedman’s sixtieth birthday. It brought together many of his former and present students, colleagues, research collaborators, co-authors and friends. That is, it brought together many of the big names in the Lisp/Scheme community (not in vain Shriram Krishnamurthi once imagined the Scheme community “a brotherhood of Dan”). Guy Steele delivered a one hour keynote, which was followed by more than twenty half-an-hour talks by people like Sussman, Dybvig, Shivers or Kiselyov, just to name a few.
The extremely good news is that, in the conference’s webpage, one can find the videos for almost all these talks! So, don’t be surprised if i’m missing during a few days! Besides the obvious interest in their contents, i’ll also find amusing to connect names with faces (it’s funny how one makes up fictitious faces for the authors of papers one reads and re-reads)… how many of them do you recognise?:
(I admire the work of many of these people, and i was convinced i wouldn’t be able to single out one among them… but to my surprise, and with all due respect to all schemers, i can: to my amusement, one of the participants is one of my few personal heroes. I’m not sure about the connection between him and Dan, but i’m very pleased to know there’s one. Surely you can spot this (to me, at least) rara avis?)
Please don’t assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list.
