Cybernethics / Cybernéthique

ITA Software, a fine employer of Lisp hackers (full disclosure: I work there), has kindly offered to sponsor a dinner for our Monthly Boston Lisp Meeting. Please send mail to boston-lisp-meeting-register at common-lisp.net with a list of attendees so we may order the correct amount of food.

Ivan Krstić will give a 25' talk about Security and Programming Languages. Ivan Krstić http://radian.org/ is notably the prized author of Bitfrost, the security architecture for the OLPC XO laptop.

Greg Cooper will give a 50' talk about FrTime: A Dataflow Extension of DrScheme. Dataflow programming extends functional programming with time-varying values called signals. Signals provide a simple, declarative mechanism for expressing event-driven programs without callbacks or explicit side-effects. This talk will present FrTime, an extension of PLT Scheme with dataflow evaluation. The language's distinguishing features include an event-driven evaluation model, transparent reuse of Scheme code, support for reactive data structures, and integration with the DrScheme programming environment. The talk will include a demonstration of the language and programming environment, along with a discussion of the key design decisions and main ideas underlying the implementation strategy. Greg Cooper developed FrTime while he was a graduate student at Brown University, working with Shriram Krishnamurthi. He now works for ITA Software.

Please note that the meeting is taking place at an unusual date, to accommodate for the availability of our main speaker.

The Lisp Meeting with take place at MIT, room 34-401B. As the numbers indicate, this is in Building 34, on the 4th floor.

MIT map: http://whereis.mit.edu/bin/map?selection=34

Google map: http://maps.google.com/maps?q=50+Vassar+St,+Cambridge,+MA+02139,+USA

PS: The previous Boston Lisp Meeting on April 22nd was a success with 40 participants, despite a few organizational glitches for which I apologize. Thanks a lot to all those who came. I hope we'll meet again and have more of those interesting conversations.

PPS: We're still looking for speakers. We have a lot of potential speakers, but not enough confirmed speakers at scheduled dates. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html

PPPS: Please forward this information to people who would be interested. Please accept my apologies for your receiving this message multiple times.

For more information, see our new web site boston-lisp.org. For posts related to the Boston Lisp meetings in general, follow this link: http://fare.livejournal.com/tag/boston-lisp-meeting or subscribe to our RSS feed: http://fare.livejournal.com/data/rss?tag=boston-lisp-meeting

ITA Software, a fine employer of Lisp hackers (full disclosure: I work there), has kindly offered to sponsor a dinner for our Monthly Boston Lisp Meeting. Please send mail to boston-lisp-meeting-register at common-lisp.net with a list of attendees so we may order the correct amount of food. No registration, no food.

Peter Dillinger will give a 25' talk about Theorem proving with ACL2s. ACL2, "A Computational Logic for Applicative Common Lisp", was recognized with the 2005 ACM Software System Award for its power and usefulness in verifying safety-critical applications. New users, however, found it difficult to use for a variety of reasons. ACL2s < http://acl2s.peterd.org/acl2s/ > is an Eclipse-based development environment we have made to make ACL2 easier to learn and use. Peter C. Dillinger is a Ph.D. Student at Northeastern University, Panagiotis Manolios, advisor.

Hans Hübner will give a 50' presentation of The BKNR Common Lisp web application development environment. BKNR < http://bknr.net/ > is a one-stop repository of open source Common Lisp modules used to develop and deploy web applications, featuring a pure Lisp transaction based persistence layer. Hans Hübner has been a hacker for over 20 years, and has discovered Common Lisp as his favourite programming language in 2001. He is a freelance consultant whose research interests include persistence systems and hardware to support dynamic programming.

Please note that the meeting is taking place at an unusual date, to accommodate for the availability of the main speaker, who is coming from Berlin (Germany) to talk to us.

The Lisp Meeting with take place at MIT, room 34-401B. As the numbers indicate, this is in Building 34, on the 4th floor.

MIT map: http://whereis.mit.edu/bin/map?selection=34

Google map: http://maps.google.com/maps?q=50+Vassar+St,+Cambridge,+MA+02139,+USA

PS: The previous Boston Lisp Meeting on March 31st was a big success, with about 70 participants. Thanks a lot to all those who came. I hope we'll meet again and have more of those interesting conversations.

PPS: We're still looking for speakers. We have a lot of potential speakers, but not enough confirmed speakers at scheduled dates. The call for speakers and all the other details are at < http://fare.livejournal.com/120393.html >.

PPPS: Please forward this information to people who would be interested. Please accept my apologies for your receiving this message multiple times.

For posts related to the Boston Lisp meetings in general, follow this link: http://fare.livejournal.com/tag/boston-lisp-meeting or check our RSS feed: http://fare.livejournal.com/data/rss?tag=boston-lisp-meeting

You have till March 31 to apply for funding for the Google Summer of Code. Here's a project I'd like to mentor. Apply at Google, thanks to the LispNYC. (If you're interested but not eligible for the Google SoC, please contact me directly.)

Erlang-in-Lisp

I am really missing a robust higher-order message-passing process algebra for Common-Lisp. The challenge is: can you do as well as Erlang? And the proof of the pudding is: can you actually run Erlang code?

PLEASE REGISTER FOR FOOD! ITA Software has kindly offered to sponsor a dinner for our Monthly Boston Lisp Meeting. Please send mail directly to me fare at tunes (dot org) with list of attendees so I may order the correct amount of food. No registration, no food.

Alexey Radul will speak about What I hate most about Scheme and what I'm doing about it. Alexey Radul is a graduate student at MIT. He uses the Scheme programming language, for which he has written an extension for probabilistic programming.

Rahul Jain will present DefDoc. DefDoc is a lisp-based document description and processing system. Both macros and object-orientation are available so that the description of a document can be focused as much as possible on content and structure. Rahul Jain is a New York based consultant who programs in Common Lisp for fun and profit.

The Lisp Meeting with take place at MIT, room 34-401B. As the numbers indicate, this is in Building 34, on the 4th floor.

MIT map: http://whereis.mit.edu/bin/map?selection=34

Google map: http://maps.google.com/maps?q=50+Vassar+St,+Cambridge,+MA+02139,+USA

PS: The previous Boston Lisp Meeting on March 3rd was a big success, with about 40 attendants. Thanks a lot to all those who came. I hope we'll meet again and have more of those interesting conversations.

PPS: We're more than ever looking for speakers. We have a lot of potential speakers, but few confirmed speakers at scheduled dates. The call for speakers and all the other details are at < http://fare.livejournal.com/120393.html >.

For posts related to the Boston Lisp meetings in general, follow this link: http://fare.livejournal.com/tag/boston-lisp-meeting

(Please forward this message to interested people. Apologies for message received multiple times. Permanent URL so far: http://fare.livejournal.com/120393.html for this call and http://fare.livejournal.com/tag/boston-lisp-meeting for the monthly meeting in general)

I will be organizing a monthly Boston Lisp Meeting.

By "Lisp", I mean any programmable programming system. However, speakers and attendants will be welcome to discuss any ideas relevant to programmers using or developing such a programmable programming system, whatever language was or wasn't previously used to express those ideas. (Note how I specifically avoided including or excluding any given system as Lisp. Anyone programming a programming system is welcome; people writing COBOL with parentheses will probably get bored.)

The meetings will usually take place on the last Monday of every month at 6pm. (Not the first Monday, which conflicts with the meetings of Grey Thumb, not the 4th Monday which is harder to figure out, not on Tuesdays, and not according to any of the other rules that were or weren't considered. Exceptions will be made to accommodate speakers or organizers.)

I am pleased to tell you about the new release 1.74 of CL-Launch, that small infrastructure I wrote to make your Common Lisp software easy to access from a Unix command line.

Since I initially announced cl-launch on this blog, it has grown a variety of features making it more usable, such as the easy execution of cl-launch from a script, a short notation for common cases (read-eval-print of single form), the ability to dump Lisp images for fast startup, support for more implementations (sbcl, clisp, cmucl, openmcl, gcl, allegro), a small library of Lisp functions, extensive documentation, debian packages, and more.

To make it more usable, I even officially adopted the shorter alias cl to invoke cl-launch. Enjoy!

I am pleased to announce the availability of Exscribe, a document authoring tool programmed and programmable in Common Lisp. It currently only targets the web, but it's extensible, so who knows?

I am glad to announce my latest piece of semi-useful software, CL-Launch, an infrastructure to easily make your Common Lisp software launchable from a Unix command line.

And now, in your XML documents, instead of typing the tedious <apply><sin/><apply><plus/><ci>x</ci><ci>y</ci></apply></apply> that you must type in MathML (at best -- and I didn't invent it, at least not as bad as it ended up), you'll be able to just do the whole thing with <SEX> and type (sin (+ x y)) instead; alternatively you may use <MEX> and type sin(x+y), and similarly you may use <RPN> and type x y + sin. Any of these tags make things much shorter and much more readable than they were in XML. However, SEX, like XML, has this advantage over MEX and RPN that it works well even in absence of a grammar definition (DTD, etc.): you can exchange SEX services with foreigners or be an intermediate in their SEX transactions without having to learn any of their foreign languages; SEX is a universal means of communication!

Derisive comments are often made about the syntax of Lisp, as witness some reproaches on my previous blog entry. Thus the half-joking, half-serious backronym of Lots of (Insipid | Irritating | Infuriating | Idiotic | ...) and (Spurious | Stubborn | Superfluous | Silly | ...) Parentheses, and accusations that Lisp syntax would make code incomprehensible to read and error-prone to write. I will take exception to this general kind of comments, and I will argue in defense of the Lisp syntax.

Lisp has this particularity that (1) there are distinct syntaxes for data structures and for program code, that (2) code syntax is a subset of data syntax (code can be seen as data), and that (3) data syntax can be embedded easily into code syntax (by enclosing it in the QUOTE special form). It is then possible to write in Lisp a small program that executes Lisp programs seen as data structures, EVAL. The discovery of such a simple canonical correspondance between code and data is what made Lisp so great. Alan Kay called it Maxwell's Equations of Software.

So you think there is nothing interesting to say at the intersection of Computer Science and Political Economics? Well, Feynman said that Everything is interesting if you go into it deeply enough. And going deeply into it is precisely what I've been doing for ten years now. So there below are some things I have to say about Computer Science and Political Economics.

That is, things beyond the fact that both Computer Science and Political Economics are completely fallacious albeit traditional names: indeed, the former is not a Science (it is an Art, or an Engineering Enterprise, which is one and the same) and to quote Dijkstra it is no more about computers than astronomy is about telescopes, whereas the other is both against Politics and beyond Economics (in either the original Aristotelian meaning of husbandry, or the modern statist meaning of taxable monetary transactions). Good Computer Science is actually Lisp Lore and Craft; good Political Economics is Libertarian Human Action.

Note that if you're not too much into computing, you may skip directly to the paragraph that mention Political Economics and Education. Yes, this is also about Education.

The Evil of Academic Curricula in Computer Science
Chapter I
Parsing Considered Harmful

Now that I have a newly working Lisp development system running Debian, complete with XEmacs, CLISP, SLIME, SSH and CVS, I have taken time to publish my Common Lisp software in the updated form of asdf packages, ready to be installed with asdf-install. Yup, that packaging software is named ASDF. Not SHRDLU.

At the request of an Indian student, I have worked out a formal document containing my term project proposals for students completing a Masters in Computer Science, specializing in Distributed Systems: http://fare.tunes.org/computing/term-project-proposal.html.

For a long time, I've considered it an awful practice that students should have term projects consisting of toy programs and rigged demos following the MWRO principle: many write, run once. Instead, they should be encouraged to systematically participate in actual useful real-world projects, and if possible free software projects, that make academic peer review possible. I never could do anything about it when in French universities, so maybe this is a godsend opportunity to move things in the right direction.

I went to Boston so as to attend LL4. I was disappointed to find that none of those great PLT guys could or would come this year, but all in all, it was a nice event, with nice people, and the last session was particularly entertaining, with presentations about gooze and frink.

What was even better, I got to meet two friends that I find truly impressive, each in his own way: Jay McCarthy and Denis Auroux.

My oh my! Couldn't they pick a better name than CLRFI? I mean, if they are to pay homage to SRFI, they had better emulate the spirit of this cool acronym, instead of its letter that gets bland when out-of-context. CLRCT, for Common Lisp Request for Common Terms, or something like that, would be more appropriate acknowledgement of the aforementioned inspiration.

Yeah, sure, I'd better be contributing running software than silly advice. But I'm reminded of these theories about why manufacturers of thriving industries have to use cool marketing gimmicks to differentiate their products: because the base product is standardized enough and the quality well-encoded enough in the price system so that marketing is all that's left to convince potential customers that your product is indeed better. Well, CL is far behind in marketing and the only consolation to lispers will be that this is because the market of programming languages in general is in a real sorry state. Of course, that's an opportunity.

Everyone having studied science has met Fibonacci numbers somewhere or another in his curriculum. And everyone having studied recursion in programming languages has at one moment or another been taught how to "optimize" an exponentially slow recursive implementation of the Fibonacci function into a linearly slow iterative loop. Except they were lied to. For that loop they learnt as a model to emulate is far from "optimal". There exists an algorithm that is (asymptotically) infinitely faster. And to understand how this algorithm may be devised allows us to explore a few ways that expressive languages like Lisp can open your mind to horizons unconceivable using such inexpressive and awkward languages as are mainstream in the industry. Have a look at fibonacci.lisp

Here are a few things I'd like to say about dynamic software development, after I've just had the opportunity to test first hand with CTO what I had been studying in theory and through the experiences of other people.

Now is a good time to announce that the software behind Cliki.Tunes.Org, aka CTO, has been noticeably improved.

I wanted to write an article on the evolution of LISP programming style, from LISP 1.0 to the latest advances in Common Lisp and beyond. But I find I haven't got time for that, so I just write a meta-article suggesting that someone could write such an article. Maybe there already exists descriptions of LISP style evolution between the 1950s and the 1970s, from FORTRAN-style to functional and object-oriented programming styles?

SEXP is not the answer. It is the question, and the answer is T.

All the lispers who don't know about it yet may be interested in Planet Lisp, an aggregator of news from various Lisp blogs and related sources.

When discussing epistemology, and particularly when disparaging Karl Popper as a half-wit (which still makes him waaaay ahead of the usual crowd of witless zeroes who are paraded as philosophers), I often like to tell about Solomonoff Induction, this compelling solution to the problem of induction. Popper believed such solution was impossible (and redefined "induction" so as to prove his point with Hume's argument), even though all humans (nay, mammals) had been showing him wrong for millenia, and though a formal solution had been hinted as Occam's Razor (tell me about Diogenes the Cynic's response to Zeno's Paradox).

Well, it so happens that Ray Solomonoff has written a nice historical account of his discovery (kudos to CiteSeer). Lots of reflective epistemological insight there -- and a lot of other great heroes who played a role in this story, including (surprise!?) a key contribution by the founders of LISP.

Of course, Solomonoff Induction is not meant to formalize exactly the way we either think or ought to think. Most importantly, it doesn't take into account the cost of thought, which limits the depth and precision of our probability computations. But that's not the point. The point is that we can formalize the way that induction is being done, and capture in an understandable way the essence of understanding -- and its limits, as Chaitin would no doubt remark.

PS: of course, there exist or can be invented infinitely many variants of Solomonoff Induction, that will take into account constraints on computation such as costs, reversibility, etc. These variants can help serve a variety of purposes, from modelling human learning processes to building machines that learn and otherwise mine data. But the details of these variants is secondary and comes naturally; the great discovery was in Solomonoff Induction.

In a c.l.l discussion about TAOUP (see also this LWN review), Dan Barlow of cirCLe fame (and who also has a nice diary) neatly summarizes the difference between the Unix way of programming and the Lisp way: Re: LISP & "The Art of Unix Programming". (As for Dan's final remark, how do you signal an exception over a pipe? You can't. And here's yet another place where the Unix way breaks apart.)

There are many interesting Lisp Weblogs, among which the one by Rainer Joswig to whom I owe a lot (the opportunity to purchase my LispM, among other things).

If I were more of a programmer, there would be more Lispy stuff here. However, I don't program enough to be called a programmer, and I don't unprogram enough to be called a non-programmer. So I'm a non-non-programmer, which, in intuitionistic logic, is weaker than a programmer.