Cybernethics / Cybernéthique

Boston Lisp Meeting: Monday 2009-07-27 - Bruce Lewis, Richard Kreuter

Sat, 18 Jul 2009 14:59:40 GMT

A Boston Lisp Meeting will take place on Monday, July 27th 2009 at 1800 at MIT 34-401B, where Bruce Lewis will speak about OurDoings, and Richard Kreuter will speak about defsystems and deliverables, or, unary REQUIRE for the win!

Additionally, we are still accepting proposals for up to two volunteers to each give of a 5-minute Lightning Talk (followed by 2-minute Q&A).

Also, there will be a buffet offered by ITA Software. Registration is not necessary but appreciated. See details below.

Bruce Lewis will speak about OurDoings http://OurDoings.com/, a web site that solves the problem faced by people who take a lot of pictures, but don't have much time to share them online. Its approach to the problem is straightforward, but unique. In this talk, Bruce will use the OurDoings web site as context in which to explain how macros enable a kind of abstraction that functions do not, and how this form of abstraction is useful in common problems that thousands of programmers face.

Bruce Lewis left the Lisp world after completing MIT 6.001 (Structure and Interpetation of Computer Programs) in Spring, 1987. Ten years later, seeking a better way to write database-driven web applications, he created BRL, the "Beautiful Report Language", an alternative to Perl ("Practical Extraction and Report Language") that dominated web development at the time. Bruce lives in Beverly, Massachusetts with his wife and three children.

* *

Richard Kreuter will speak about Defsystems and deliverables, or, unary REQUIRE for the win! Common Lisp users have employed a succession of system construction tools ("defsystems") over the years. Howsoever good a defsystem tool might be, overuse of system construction tools creates needless technical and social problems in the community and confounds newcomer and professional alike. This presentation will cover some of the drawbacks of the traditional uses of defsystems, and proposes some approaches to deploying Lisp software intended to make Lisp library usage more tractable than defsystems make it.

Richard Kreuter is a software developer in the Boston area. He has worked on Steel Bank Common Lisp, driven himself nuts by too much reading of the Common Lisp standard, and is likely to be the last person on earth who thinks CL's pathnames still are a good idea.

* * *

Having observed the success of the formula at ILC'2009, we have instituted Lightning Talks at the Boston Lisp Meeting. At every meeting, before the main talk, there are two slots for strictly timed 5-minute talks followed by 2-minute for questions and answers.

The slots for next meeting are still open. Step up and come talk about your pet project!

* * * *

The Lisp Meeting will take place on Monday July 27th 2009 at 1800 (6pm) at MIT, Room 34-401B.

As the numbers indicate, the room is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

Thanks also to David Crawford, who accepted to be the Master of Ceremony as I won't be able to attend, being abroad on that day.

* * * * *

We appreciate it if you let us know you're coming, and what food taboos you have, so that we can order the correct amount and kind of food. Tell us by sending email to boston-lisp-meeting-register at common-lisp.net. We won't send any acknowledgement unless requested; importantly, we'll keep your identity and address confidential and won't communicate any such information to anyone, not even to our sponsors.

* * * * * *

The previous Boston Lisp Meeting on June 29th had about 40 participants. Eli Barzilay gave quite a talk about Implementing Domain Specific Languages with PLT Scheme.

In the near future, we expect to have Emmanuel Schanzer on 2009-08-31 about bootstrapworld.org, and on some undetermined dates, Christine Flood about Fortress, and Ravi Nanavati about the relative advantages of static and dynamic typing.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html Volunteers to give Lightning Talks are also sought.

For more information, see our 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

Please forward this information to people you think would be interested. Please accept my apologies for your receiving this message multiple times. My apologies if this announce gets posted to a list where it shouldn't, or fails to get posted to a list where it should. Feedback welcome by private email reply to fare@tunes.org.

Why I Returned my G1

Fri, 19 Jun 2009 11:47:13 GMT

For many months over, I've been getting tired of my old Verizon phone with its dying batteries, and fantasizing about buying a Google Phone. A few weeks ago, I lost the old phone, and finally got myself the T-Mobile G1 to replace it. Priced $180 with a 2-year contract of $65 a month with unlimited data, 600 minutes and 400 messages a month, it was pricy but still attractive: a phone designed by Google around Open Source software, with all the features of phone and of a PDA -- shouldn't that make the geek in me drool? Yet before the end of the trial period, I went back to the store and returned the long fancied device. Here's why.

The Good	The Bad	The Ugly
Full Internet access anytime, anywhere!	With incomplete support for web standards or javascript and no flashplayer, a lot of useful sites won't display properly. The edge and 3G networks are horribly slow, so you'll stare at your device waiting, yet you can't switch to another task least the G1 stop downloading. Sure it can use WiFi, but then why need a phone? Also turning WiFi on/off is a pain whereas leaving it on drains batteries. Last but not least, T-mobile will do its darndest, with Google's complicity, to prevent you from tethering your computer to the net through the G1, so you're locked into the atrociously inefficient interface of your phone.	You get all the real-time distraction of connecting to Internet websites but without the ability of being productive at it. It's not the internet being available to you, it's you being available to it! "On-line, adj.: The idea that a human being should always be accessible to a computer."
The Operating System is based on Open Source Software.	You don't have root access unless you buy an expensive developer version separately from Google; even then some drivers are closed. To program the device, you have to use a limited virtual machine and its special purpose libraries that are incompatible with anything else and are restricted in their system access.	For all practical purposes and despite the buzz, the G1 is a closed platform on which you are not the master. It might be better than your average phone, but it's a long shot from a truly open platform.
It has built-in GPS.	The GPS is not well integrated to Google Maps. Don't expect real-time guidance instructions. You'll have to painstakingly retype your position and/or destination everytime you want an update on the itinerary, and then wait a minute for the device to go over the slow network and have the server recompute everything from scratch. GPS is a pain to deactivate or reactivate, yet you have to do it all the time because it drains too much power.	It is not at all a replacement for a half-decent GPS device.
It has a decent camera for a phone.	The camera software sucks. The interface is not quite WYSIWYG. The capture latency and delay are long and unpredictable. The quality of pictures is not so great. And how do you transfer the files to my Linux machine?	It is not at all a replacement for a half-decent pocket camera.
Uses a standard USB connector.	Earphones also plug through the USB, exclusive with power. You'll have to bleed your precious little battery power while using your device hands-free.	Sure it's way better than other phones with proprietary connectors and gratuitously expensive accessories. That doesn't make it good.
It can play youtube videos.	The position isn't saved when you switch apps, and it isn't very practical to move in the video; it sucks to watch long lectures. You can feel the latency of the network. If you're only/mostly interested in the sound, you still have to leak batteries at the pictures. You can't play the sound loud enough to share with friends. Videos make the device heat up and the batteries drain very fast.	It's not useful for viewing serious videos, only for wasting time.

The G1 has alluring hardware specifications and does everything you could expect a small computing device to do. Alas, it doesn't do any of it well. It is not by any means a decent Internet access device, a decent digital assistant, or even a decent MP3 player. What is worse, it is a computer on which you are not the one in control. It may be an excellent phone, but only because by the telecom industry has set very bleak standards indeed for what a phone may be expected to do. Moreover, if you use any of its advanced functionalities, then the battery situation is even worse on the G1 than on my old dying phone. All in all, it is a luxury I'd rather not afford.

I'm now the happy owner of the cheapest phone (marginally free) with the cheapest plan ($30 a month). This brings me 95% of the satisfaction of the G1 with none of the extreme frustration, for less than half the price and half the weight.

I am looking forward to a future of telephony over decentralized WiFi networks where government-backed telecom companies can no more force consumers into buying outrageously priced plans that can only be used with inferior locked down devices.

Boston Lisp Meeting: Monday 2009-06-29 - Eli Barzilay

Wed, 17 Jun 2009 04:19:03 GMT

A Boston Lisp Meeting will take place on Monday, June 29th 2009 at 1800 at MIT 34-401B, where Eli Barzilay will speak about Implementing Domain Specific Languages with PLT Scheme.

Additionally, we are still accepting proposals for up to two volunteers to each give of a 5-minute Lightning Talk (followed by 2-minute Q&A).

Also, there will be a buffet offered by ITA Software. Registration is not necessary but appreciated. See details below.

Eli Barzilay will speak about Implementing Domain Specific Languages with PLT Scheme.

Many problems call for domain-specific languages (DSLs) to express them and their solutions; such languages enable a dialogue between domain experts and software developers. The Lisp and Scheme community has a decades-old tradition of creating and embedding special-purpose languages via macros. Over the last twenty years, we PLT Schemers have continued to develop this technology to the point where making up new languages is so quick and easy that PROGRAMMERS CREATE A LANGUAGE FOR WRITING A SINGLE PROGRAM.

Embedded DSLs are appropriate for a whole range of domains and applications -- in both academia and industry. Notable examples include research languages, teaching languages, and application-specific languages like our text-friendly documentation language.

In this talk Eli will demonstrate how to implement embedded practical DSLs in PLT Scheme.

Eli Barzilay is a Researcher in the PLT group at Northeastern University. He has been a core PLT Scheme developer since 2003, and has used PLT's ability to implement new languages to an extreme. For his Programming Languages undergraduate course, he creates nearly one language per week. In addition to writing new languages, he is involved in helping PLT develop into a multi-lingual environment.

His website is at http://barzilay.org/

* *

The slots for next meeting are still open. Step up and come talk about your pet project!

* * *

The Lisp Meeting will take place on Monday June 29th 2009 at 1800 (6pm) at MIT, Room 34-401B.

As the numbers indicate, the room is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

* * * *

* * * * *

The previous Boston Lisp Meeting on May 26th had 40 participants. Norman Ramsey gave a talk about Using Higher-Order Functions and Continuation-Passing Style to Make Dataflow Optimization Simple.

In the near future, we expect to have Bruce Lewis on 2009-07-27 about BRL and ourdoings.com, Emmanuel Schanzer on 2009-08-31 about bootstrapworld.org, Christine Flood on some undetermined date about Fortress.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html Volunteers to give Lightning Talks are also sought.

Boston Lisp Meeting: TUESDAY 2009-05-26 - Norman Ramsey

Thu, 14 May 2009 06:15:27 GMT

A Boston Lisp Meeting will take place on Tuesday, May 26th 2009 at 1800 at MIT 34-401B, where Norman Ramsey will speak about Using Higher-Order Functions and Continuation-Passing Style to Make Dataflow Optimization Simple.

Additionally, we are still accepting proposals for up to two volunteers to each give of a 5-minute Lightning Talk (followed by 2-minute Q&A).

Also, there will be a buffet offered by ITA Software. Registration is not necessary but appreciated. See details below.

Norman Ramsey will talk about Using Higher-Order Functions and Continuation-Passing Style to Make Dataflow Optimization Simple.

Norman Ramsey's research spans theory (a foundational model for probabilistic programming languages) and practice (methods for making code generators reusable). While he has contributed to a variety of topics in programming languages and software engineering, his primary interests lie in functional programming and programming-language infrastructure. His introduction to functional programming came on a Symbolics Lisp machine, but shortly afterward he was seduced by the beauty of algebraic data types and pattern matching. These days his favorite programmable programming systems are Haskell (look! it has Prolog in the type checker and will generate your code for you!) and Lua (the best of scripting, metaobjects, and C rolled up into a tiny package). He is currently Associate Professor of computer science at Tufts University, a job which he enjoys tremendously except that it does not leave him time for enough programming.

His website is at http://www.cs.tufts.edu/~nr/

* *

The slots for next meeting are still open. Step up and come talk about your pet project!

* * *

The Lisp Meeting will take place on Tuesday May 26th 2009 at 1800 (6pm) at MIT, Room 34-401B.

Note that the meeting will not take place as usual on the last Monday of the Month, but on the next day, Tuesday. Indeed, that last Monday of May is Memorial Day, a holiday, and the next day thus makes do as a "Virtual Monday".

As the numbers indicate, the room is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

* * * *

* * * * *

The previous Boston Lisp Meeting on April 27th had 35 participants. Noah Goodman gave a talk about Lambda the Ultimate Gamble. Alan Bawden also gave a Lightning Talk about a better proposed representation for quasiquotes.

In the near future, we expect to have Bruce Lewis on 2009-06-29 about BRL and ourdoings.com, Emmanuel Schanzer on 2009-08-31 about bootstrapworld.org, Christine Flood on some undetermined date about Fortress.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html Volunteers to give Lightning Talks are also sought.

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

Please forward this information to people you think would be interested. Please accept my apologies for your receiving this message multiple times. My apologies if this announce gets posted to a list where it shouldn't, or fails to get posted to a list where it should. My apologies for the lateness of this announcement. Feedback welcome by private email reply to fare@tunes.org.

Hell of an Ending

Wed, 06 May 2009 22:28:23 GMT

"Heavenly music... hell of an ending" said the flyer. Yesterday, Lucìa and I went to the last performance of Don Giovanni by the BLO. It was quite enjoyable, but I have a few objections to the production.

Mozart wrote great music, and though I am sometimes disappointed about which bits it he and Da Ponte chose to develop or not develop, it's a bit too late to change the already very entertaining score. And so I'll direct my criticism to the current interpretation. The set, which was the same for both acts, was rather poor in features; the direction made do with excellent lighting tricks, as well as occasionally veering into symbolism, especially so and somewhat disappointingly in the finale. However, considering the strictures of the budget and the limitations of the Shubert Theater, I will not object to such choices. The singing was honorable, though of the cast only Susanna Phillips distinguished herself, as Donna Anna. Kimwana Doner on the other hand was way too serious in each of the revealed aspects of the ultimately fickle Donna Elvira. Matthew Burns is passable but fails to shine as Leporello, notably in his main piece Madamina, il catalogo è questo.

But what really bothered me was Christopher Schaldenbrand's portrayal of Don Giovanni as a cheap loser, someone who isn't even the hero of his own drama, but the victim of events. Violence, money and luck seem to be his only weapons, and his confrontation of the Commendatore seems inspired mainly by the abuse of alcohol. From the way he acts, you wonder how he seduced all those women; maybe his catalog of female conquests is itself a lie. Yes, Don Giovanni is a truly evil character, who isn't above rape, murder and fraud. However I like to think of him as someone who isn't afraid of anyone or anything, not even ghosts, not even hell. Not a loser, but a go-getter, who knows what he wants, will do anything, anything, to get it, and usually does get it, for he is master in his own specialty. A bad guy, certainly, but a most competent bad guy, who will certainly not go down without putting up a good fight, and won't lose unless he finds a hero great enough to vanquish him.

And so for all I know, his eventual abduction by a ghost may be Don Giovanni's latest invention, staged by himself to get rid of all these former victims who are now running after him and spoiling his fun, all the while silently mocking their superstition and gullibility from behind as they sing their final moralizing Questo è il fin in the front of the stage. At least, that's how things would turn out if I had a say in a production of Mozart's masterpiece. Certainly it would bother me a bit to let the scoundrel get away with murder scot-free, but after all unhappy endings are par for the course in Opera.

Lightning Talks

Mon, 04 May 2009 22:27:44 GMT

Lightning Talks are series of short strictly timed five minute talks each followed by two minutes for questions and answers during which the next speaker gets prepared (by e.g. disconnecting the previous speaker's laptop from the projector and connecting his own instead). The formula was used at ILC'2009 in sessions of 4 to 8 talks, and was a tremendous success.

Indeed you don't need to have that much to say to give a Lightning Talk, and so the formula lowers the barrier to entry and allows for a wider diversity of ideas to be presented at such events. At the same time, the strict constraint forces the speaker to be more concise, maybe even poetic, in conveying his ideas. Several participants remarked that since Lightning Talks were both so short and precisely timed, you could rehearse them many times before you gave them, making delivery more powerful. Additionally, some argued that the short duration limits the potential for either speaker humiliation or listener boredom, once again giving incentive for people to participate on both ends of the communication, promoting the exchange of ideas.

And so, I instituted such Lightning Talks at the Boston Lisp Meeting; so far, they have been well-received, and many people have subsequently volunteered to give one -- which makes me hopeful about their positive impact on the exchange of ideas within the community.

Cowardice, yes — Stupidity no

Mon, 04 May 2009 02:39:51 GMT

As an addendum to my previous Ode to Surrender, I'd like to dispel misconceptions about the proper role of Cowardice. Says an English proverb, "He who fights and runs away, lives to fight another day". However, he who is a clever coward runs away well ahead of any bloodshed. The clever coward won't wait for things to get nasty; he won't go to war only to surrender; he won't uselessly waste resources at preparing losing battles; he won't even engage the superior enemy; and even the inferior enemies, he'll find someone else to handle.

Of course, time and again, fighting might be an absolute necessity. There are times when running away is not an option, when surrendering will result neither in your life being spared, nor in the well-being of those you love being preserved. There are enemies who have the murderous intent to take away your life rather than merely the thievish desire to take away your belongings.

But if you're clever enough in your cowardice, you'll avoid those times. You'll stay out of reach of such deadly enemies. You'll accept the dominion of a stronger but less parasitic enemy that you can pit against a more parasitic but weaker enemy. In the last extremity, but way in advance of the actual conflagration, you'll prepare for the actual fight, in such a way that you can win -- and since no retreat is possible (or else it wouldn't be the last extremity), you'll then use the leverage of commitment to increase the power of your strike. In other words, you'll carefully pick your battles so you can win them all.

My great grandfather was a war hero: he succeeded at getting killed "for his country" at a war in which he hadn't been forced to partake -- for no benefit whatsoever to his country and to the great detriment of his family. His son my grandfather on the other hand is a failed hero: he twice took the initiative to cross great distances to join the battlefield and fight "for his country", and twice failed to arrive on time to be part of any battle. His son my father was an unsuccessful anti-hero: he didn't avoid being drafted in a war he didn't call for, and got poisoned with amibiasis for his service (ah, if only he were like his mates a drinker of beer, not water). But he was clever enough to fight where he ran the least risks: amongst paratroopers. And happily the heroes in the shock troupers to which he was detached were kind enough to leave him behind when they ultimately rushed to their heroic failure. As for me, I hope to be a successful coward: one who manages to stay way clear of any combat zone.

Of course, I'm willing to fund those who will fight battles for me. Considering that warring is an activity that requires specialized skills, it is much more efficient indeed to pay a professional than to partake myself as an amateur. But I'll contribute, in money or in kind, only to those battles that I think are worth fighting, and only if I believe my marginal funding can actually contribute to victory. What more, I strongly believe that corruption not force, dishonesty towards the unjust laws not honor in enforcing their supremacy, are what will eventually make peace prevail. It is tautological that justice, peace and prosperity can't win against the interest of the mighty -- but they can probably win more easily by making the mighty interested in justice, peace and prosperity than by trying to rise those interested in justice, peace and prosperity against the mighty.

Designing Software under the Influence

Fri, 01 May 2009 21:32:47 GMT

beach reported on IRC "In fact I agree with a French colleague of mine who works for the water company, that you have more and better ideas when under the influence, but then you need to be totally clean when working out the details. Luckily, grad students work out the details these days :)"

My answer was that I fell in the wine barrel when I was a kid, and the effects on me are permanent. Maybe that's why I have all these ideas, but can never work out the details.

rsynnott remarked that he normally attributes that to laziness, in himself. I suppose that could be a valid other name for that. In any case, that's why I'm now working towards getting minions to work for me.

Reisner's Rule of Conceptual Inertia: If you think big enough, you'll never have to do it.

Confusing constants and variables in Political Economics

Fri, 01 May 2009 02:13:11 GMT

If many top notch computer programmers, in a field where people are largely selected for their ability to understand causes and consequences, fail to understand the difference between a constant and a variable with respect to a given choice, how can you expect people from professions that don't thus select their members to fathom the difference?

And so most people, most bright people even, have the greatest difficulty understanding the difference between variables under their control, and variables not under their control -- be them variables under someone else's control, hypotheses of a given thought experiment, natural phenomena, or universal constants.

Actually, the people who are trained to understand and explain the nature of a choice, its benefits and costs, are economists. And even most economists fail (cám ơn, Constant). Only austrian economists are properly trained, but they are marginalized in academia and media by statist economists whose very raison d'être is to produce cover stories for the depredations of the State, by denying of the very basic principles of economics.

This is how otherwise intelligent people believe that taxes and prohibition can abridge the consumption of services or goods with inelastic demand -- when by definition of inelastic demand, it will instead displace other consumption, and lead the victims of prohibition to poverty and crime when desperate measures are required to indulge in the inelastic behavior. What is constant is the inelastic demand for addictive drugs, that depends on the will of the people targeted by the prohibition, rather than the propensity of said people to abide by the law when the law is changed. And so what the prohibition law does is introduce more crime and law enforcement, displacing peaceful and productive activities at a huge cost to society.

The same people may believe that raising taxes and prohibitions (such as minimal wage) on services or goods with elastic demand will help them increase transfer of wealth from the designated victims (taxpayers, employers) to the designated beneficiaries (tax consumers, employees). But once again, what is constant when you enact laws is not the behavior of the victims, but their will, goals, desires and preferences. And so the consequence will instead be that less productive employees will not find a job, that taxed capital will either run away or be exhausted, taxed work will be less intensive, and black market activities will increase.

All in all, the only people who benefit from laws are for the professionals who specialize in either enforcing or countering the law: scammers, whether legal (politicians) or il-, racketeers, whether legal (bureaucrats) or il-, and their goons with guns, whether legal (cops) or il-.

Oppression thrives on people being systematically unable to properly understand the nature of choice and to apply this understanding to Political Economics. And yet, most anyone can be trained into understanding it. If you want to stop Oppression, start by extirping the seeds it sows inside you. Learn (Austrian) Economics. Knowledge will make you free -- and others with you.

Constrained by Reality and Society

Tue, 28 Apr 2009 19:43:34 GMT

Statists will argue that individuals on a free market aren't really free to choose, because they are constrained by reality and society. Then they propose Government as the solution. But Government isn't above reality, and neither is it above society. Its choices are just as constrained. All Statists actually argue is that they support the arbitrary use of force by rulers to coerce citizens into doing their bidding.

Confusing constants and variables in Computer Programming

Mon, 27 Apr 2009 19:36:09 GMT

I am always amazed when people fail to distinguish between constants and variables. I am all the more amazed when the victims of such confusion are the otherwise brilliant implementers of programming languages. You'd think that if anyone knows the difference between a variable and a constant, it would be a programming language implementer.

For instance, a CLISP maintainer explicitly based his argument for making some backdoor compulsory on the belief that the behavior of his hypothetical source-closing adversary will remain the very same after the backdoor is created. But what is constant here is the hypothetic adverserial will of said antagonist, not his behavior; the known backdoor will be trivially circumvented by this adversary, and will only remains as a constant hassle to all the friends.

In another instance, the respected creator of Python argued against proper tail calls because they allegedly lose debugging information as compared to recursion without tail call elimination. But as said hacker implicitly acknowledges without making the explicit mental connection, in programs for which proper tail calls matters, the choice is conspicuously not between proper tail calls and improper tail calls, it is a choice between proper tail calls and explicit central stateful loops. And the absence of debugging information is constant when you transform tail calls into stateful loops. Stateful loops precisely make it harder to get debugging information, whereas proper tail calls are trivially disabled or wrapped. In addition, state introduces a lot of problems because of the exponential explosion of potential interactions to take into account. But more importantly, proper tail calls allow for dynamic decentralized specification of a program in loosely coupled separate modules by independent people, whereas loops force the static centralized specification of the same program by a one team of programmers in one huge conceptual gob requiring tight coupling. Finally, loops are trivially macro-expressible in terms of tail-calls (i.e. through local transformations), whereas it requires a global transformation to transform arbitrary programs requiring tail-calls into programs using loops - and if we allow for such transformations, then who needs Python, INTERCAL is the greatestest language ever designed.

Brilliant operating system designers have argued that microkernels can simplify software development because factoring an operating system into chunks that are isolated at runtime allows to make each component simpler. But the interesting constant when you choose between ways to factor your system and compare the resulting complexity is not the number of components, but the overall functionality that the system does or doesn't provide. Given the desired functionality, run-time isolation vastly increases the programmer-time and run-time complexity of the overall system by introducing context switches and marshalling between chunks of equivalent functionality across the two factorings. Compile-time modularity solves the problem better; given an expressive enough static type system, it can provide much finer-grained robustness than run-time isolation, without any of the run-time or programmer-time cost. And even without such a type system, the simplicity of the design allows for much fewer bugs, whereas the absence of communication barriers allows for higher-performance strategies. Hence HURD being an undebuggable joke whereas Linux is a fast, robust system.

In all these cases, the software designer enforces some kind of hurdle that doesn't help honest people; the only beneficiaries are the specialists who get job security at handling the vast increase in gratuitous complexity.

These people, though very intelligent, fall for an accounting fallacy. They take a myopic look at the local effect of one alternative on some small detached parts of the system where they can indulge in some one-sided accounting whereby the alternative they like has benefits at no cost, whereas the other one has costs at no benefit. And they neglect to consider the costs and benefits in other parts of the system outside of their direct focus though they are necessarily being changed by the switch between alternatives to preserve the actual overall constants that make the choice meaningful.

It is possibly the individual interest of these experts to promote labor-intensive solutions where their expertise is the development bottleneck. Conscious dishonesty isn't even necessary when the rational incentive is for the experts to ignore the real costs of their choices, because they don't bear these costs. And so ultimately, the laugh is on the users who follow the advice of these experts.

In a choice between proposed alternatives, what needs be evaluated is the economic cost of each alternative, i.e. its relative cost to other alternatives with respect to the overall system. And before you may even evaluate this cost, you must determine what is constant and what varies when you make the choice.

Woo be on software designers who confuse constants and variables!

On a Proposed Scheme for a Programmers' Guild

Mon, 27 Apr 2009 03:26:29 GMT

Arguing that the current average experience and proficiency of programmers is pretty low, and that programming malpractice incurs huge costs including the risk of occasional death of end-users, MIT Professor and Scheme co-inventor Gerald J. Sussman has proposed at ILC'2009 and on several other occasions [Update: as a joke] that programmers should be certified before their are allowed to practice. I heartily agree, but for the small prevention that follows.

Indeed, before we start certifying programmers, considering how even lower is the current average experience and quality of programmer certifiers, how much more rests on the shoulders of these programmer certifiers, and how much costlier and riskier is a malpractice in programmer certification, I propose by the same argument that programmer certifiers be themselves certified. Then again, the same argument applies recursively, and before we start certifying programmer certifiers, we must properly certify the programmer certifier certifiers, etc.

Quis custodiet ipsos custodes?

We haven't nearly started looking for all the programmer(certifier)^n's necessary for this Scheme to actually work, and so I propose that in the interim, each and every individual should continue to be his own programmer(certifier)^n for the n's of his choice, allowed and required to choose for himself whether to program computers himself or to confide his programming tasks to someone else, following the opinions of whichever certifiers, certifier certifiers, etc., he chooses to trust.

Of course, gjs in your naïve haughtiness, you may imagine yourself a programmer certifier. But my dear, you fail certification as such. Following Peter's Principle, you have reached your Level of Incompetence. Go back to your ivory tower with your corporatist Guild out of the Dark Ages! [Update: As for me, I have reached my Level of Incompetence in the detection of irony.]

PS: Have no fear. All existing Government licenses and certifications are valid, from Medical Titles to Gun Toting Privileges, from Financial Certification to Academic Degrees, and this argument cannot possibly apply to them. The Government itself is valid because of the Constitution (whether it follows it or not), and the Constitution is valid because... because the Government says so -- and has bigger guns than does anyone who disagrees.

Update: My apologies to professor Sussman, who told me that he proposed this as a joke. He is serious about the need to assess the proficiency of programmers, especially programmers who are assigned life-critical software, but he is not actually calling for any monopolistic certification bureaucracy.

Boston Lisp Meeting: Monday 2009-04-27 - Noah Goodman on Lambda the Ultimate Gamble

Thu, 23 Apr 2009 04:50:45 GMT

A Boston Lisp Meeting will take place on Next Monday, April 27th 2009 at 1800 at MIT 34-401B, where Noah Goodman will speak about MIT-Church, a non-deterministic Scheme.

Additionally, we are still accepting proposals for up to two volunteers to each give of a 5-minute Lightning Talk (followed by 2-minute Q&A).

Also, there will be a buffet offered by ITA Software. Registration is not necessary but appreciated. See details below.

Noah Goodman will talk about Church: a language for probabilistic modeling, or, Lambda, the Ultimate Gamble. He will describe the probabilistic programming language Church. Probabilistic generative models have exploded in recent years, becoming central to machine learning and AI. These models are usually described with a mixture of informal english, math, and box-and-arrow diagrams. Such descriptions can be error prone and are difficult to scale in model complexity. Church is a formal language for probabilistic generative models, derived from the pure subset of Scheme and extended with probabilistic constructs. As a description language Church is a convenient and powerfull way to construct models; in this talk I will show several examples drawn from recent machine learning research. Beyond mere description, Church makes it possible to automate the process of inference in probabilistic models. The MIT-Church implementation of Church is a universal inference engine based on Markov chain monte carlo. I will indicate the design of this implementation and highlight some of the unique challenges of probabilistic programming languages relative to standard languages. I will close with some examples of MIT-Church in action.

Noah D. Goodman is a research scientist in the Department of Brain and Cognitive Sciences at MIT, and a member of the Computer Science and Artificial Intelligence Laboratory. He studies the computational basis of human thought, merging behavioral experiments with formal methods from statistics and logic. He received his Ph.D. in mathematics from the University of Texas at Austin, several years later he joined the Computational Cognitive Science group at MIT, working with professor Joshua Tenenbaum. Goodman has published more than twenty-five publications in psychology, cognitive science, and artificial intelligence. Goodman is project leader of the MIT-Church probabilistic programming project.

His website is at http://www.mit.edu/~ndg/

* *

The slots for next Monday are still open. Step up and come talk about your pet project!

* * *

The Lisp Meeting will take place on Monday April 27th 2009 at 1800 (6pm) at MIT, Room 34-401B.

As the numbers indicate, this is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

* * * *

* * * * *

The previous Boston Lisp Meeting on March 30th had between 30 and 40 participants. Carl Eastlund gave a talk about Modular ACL2. We also had our first Lightning Talks: François-René Rideau talked about "Better Stories, Better Languages", and Dan Stanger spoke about BRL. (Matt Knox couldn't be there to speak about GoaLoC as previously announced.)

In the near future, we expect to have Norman Ramsey on 2009-05-25 about purely functional dataflow optimization in Haskell, Bruce Lewis on 2009-06-29 about BRL and ourdoings, Christine Flood on 2009-08-31 about Fortress.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html

Please forward this information to people you think would be interested. Please accept my apologies for your receiving this message multiple times. My apologies if this announce gets posted to a list where it shouldn't, or fails to get posted to a list where it should. My apologies for the lateness of this announcement. Feedback welcome by private email reply to fare@tunes.org.

Ode to Surrender

Sun, 12 Apr 2009 19:44:19 GMT

While discussing with fellow libertarians about the foolishness of sacrificing one's own welfare for the sake of avoiding State taxes and control, I remarked that as a Frenchman, I well knew the blessings of unilateral surrender.

In France, our paleolithic Neanderthal ancestors surrendered to the Cro-Magnons. Our neolithic ancestors accepted the yoke of the Celts and became Gauls. As Gauls, we surrendered to the Romans and adopted their language and laws. As Gallo-Romans, we embraced the Christian bandwagon rather than being persecuted as infidels. As Christian Gauls, we greeted the Visigoths as protectors, and negotiated rather than fought with Attila the Hun. We then became servants to the Germans and eventually took from our new masters their name "French". As French, we surrendered to the Normen a whole province (now Normandy) rather than fight. We were happy to honor "English" (Norman) as well as "French" (German) contestants to the throne of our Kingdom. We eventually crowned a Navarrean. We sat out the first Communist Dictatorship ever (the Terror), and hailed a Corsican midget as our savior. We welcomed back a King with the Russian army that brought him and elected another Corsican Emperor. We left Alsace and Lorraine to the Prussians without much resistance. When they invaded again, we were letting them pour in except that the English and the Americans threw them out, twice. We were actively getting ready to receive the Russians a second time, but they never came. Nowadays, we'd happily surrender to our new Islamic invaders, if only they had a well-defined chief at whose feet we could grovel. In the meantime, we bow reverently to our overlords in Brussels.

Now, some of you will argue that there were always resisters, from Vercingetorix to Jean Moulin through la Rochejaquelein. But vae victis, they died in the shame of defeat and subjection, and by and large, we are not their descendents. No, we the French descend from a long line of cowards and traitors, who knew when to switch side, to flee, to surrender, to serve and pay taxes. And what's to be ashamed of? At least our country is not a backwater reduced to ruins, like Chechnya, where lives the prototypical people who'll never surrender but to the most extreme force, and then some.

No. In France, we know that Power is to be respected; and we also know that Powerlessness is to be trampled upon, and that the best way to detect the difference between the two is to walk the fine line that separates them, all the while avoiding to pass the breaking point. A fine art that we've developed to perfection. We will accept any master who will let us enjoy the good life, with good food, romance and long vacations; and we'll use that good life to corrupt whoever will rule us into embracing our way of life. Yet we'll abandon him for a stronger master the moment that his weakness is apparent.

Who cares whether the master is Roman, German, Corsican or Belgian? Whether the priests follow Jupiter, Jesus, Robespierre or Mohammed? Taxes are due to the political master and lip service is due to the dominant ideology; we Frenchmen didn't have to be taught to render unto Caesar what belongs to Caesar, and to God what belongs to God. We have learned to count our losses, and to focus on what is left for us to actually possess and enjoy -- including whatever we can grab back from our masters while they're not paying attention.

Note that we do not confuse surrender with victory, subservience with freedom. But while victory and freedom can hardly be overrated, they are often misidentified, their cost under-evaluated; the risk of defeat and the instability of permanent supremacy are dismissed too quickly. You're not victorious just because you're a slave soldier in the victorious army. Your people hasn't won the war if half of it is dead and the survivors are more miserable than if they had surrendered early on. And while Victory is sweet, its winds are changing, victors come and go. You'll only stay on top so long before you get old and are crushed by newcomers. So ask yourself whether the necessary ascetic military discipline is worth it all, when instead you could be enjoying yourself at the cost of an occasional bow. What makes you think that Caesar is a harsher master than Mars Himself? Do conquering soldiers bow and obey less than conquered civilians?

Therefore as a permanent relationship with Power, we choose unilateral Surrender. And we don't mean some half-hearted surrender with a permanent spirit of revenge. Neither do we mean a down-hearted surrender with the gloom of eternal defeat. We mean a whole-hearted surrender with the enthusiastic welcome of the victor. We won't incur the wrath of the master with constant hit-and-run guerrilla tactics. We will actively staff his bureaucracy, lobby his office, offer our wines, sell our perfumes, seek his friendship, marry our daughters to him. We'll happily pay taxes on everything that we can't hide. We'll eloquently support the candidate to the master's succession who'll give us more from his loot, without making enemies of other potential future victors.

Power is a fact, and we'll make the most of it. But it is also a fact that Power has limits, and we'll just as much make the most out of that. You can never vanquish rodents and roaches by killing them all off; but you can easily learn to store your grain where rodents and roaches won't be able to see it or reach it. In France, we have such proverbs as "Vivez heureux, vivez caché" (to live happy, live hidden), or "Cultiver son jardin" (to grow one's own garden). We don't fight against power in the open, but thrive at home behind closed walls. We are well warned at school and in the media to not flaunt our riches like a Fouquet and to not openly revolt against the masters like a Duviau. Whatever the law says, it is only ever forbidden but to get caught -- the latter not the former is what the law is, and that is the law we respect. Remember: it's only illegal if you'll actually get caught and punished for it; getting caught won't happen where there is neither victim nor witness; and getting punished may not happen if it is not explicitly forbidden.

In conclusion, our motto is: Long live our Masters! And longer shall we live.

The Democracies of the Ring

Sun, 05 Apr 2009 20:51:26 GMT

In this recently unearthed posthumous book by J.R.R. Tolkien, the fantasy world filled with dragons and magicians has evolved from warring medieval times to peaceful modernity; furthermore, in the second volume, it is resolutely entering post-modernity.

Dragons, formerly a bane of the world universally hated and chased down to the point of going nearly extinct, are now a small but thriving race of individuals fully integrated with the economy; with their great physical prowesses, heat resistance and long lives, they earn their living as demolition workers, glassblowers, or historians.

What used to appear to ignorant people as "magic" defying the laws of nature has now been formalized as a systematic use of previously unidentified laws of nature. People who in old times would have been called magic-users usually have a day-job repeatedly casting whichever are their most valuable spells in an industrial production setting. Those most adverse to said drudge become engineers devising new spells or researchers furthering the field.

Heroes with extraordinary survival or regeneration skills are employed in deadly jobs such as mine exploration, search and rescue, dealing with wild animals (including in circuses, zoos and research), being guinea pigs for new medical drugs and surgical procedures, testing new planes and rockets, etc.

More generally, anyone with unusual powers or talents finds a market for the uses of his abilities. Some powers previously thought of as useless are now valued, such as the ability to change the color of your hair at will, which found a market in the sale of raw material for wearable display devices. On the other hand, powers previously thought to be awesome are now devalued, such as car invisibility, for which the first prototype was crushed in a deadly collision a few seconds after going out of its garage.

People of various races have different abilities, and systematic trade routes exist whereby dwarves buy crops and sell processed mineral goods, elves buy all kinds of materials and sell technology or luxury goods, hobbits grow quality crops and do precision craftmanship, and so on, in a perfect illustration of the Law of Comparative Advantages.

Trolls, Orcs, Goblins, etc., who for a long time had terrorized the world under the leadership of Sauron, the prophet of Morgoth, have been vanquished for good, at the end of bloody wars in which superior technology and the rule of law prevailed over brutish savagery and despotism. Having been subdued, they now live peacefully, most of them growing traditional crops in their home countries and caverns. Their number vastly increased since they don't incur the cost of incessant warfare anymore, and instead have some access to human technology and medecine. An increasing number of them move to human territories where they sell their unskilled brute labor. Most frequently, these darkness-seeking creatures happily work night shifts in factories, optimizing the use of modern machinery without the problems associated to human night workers

And that's how in a few centuries of dominion by Just Kings imposing the respect of law, property and individual rights to savage and uncivilized races previously led by fanatic criminal warlords, a bleak world of war and poverty has been turned into a paradise of health and wealth.

* * *

However, with time, Just Kings ended up having not-so-just successors. Kingship by unanimous election of the ablest (a somewhat heritable trait) degenerated into a hereditary dynasty by birth right, and the dynasty itself degenerated into tyranny as a Marcus Aurelius was succeeded by a Commodus. Succession wars split the Kingdom into many warring Provinces, until finally Kings have now been overthrown and replaced by Democratic regimes as improved military technology displaced aristocratic rule by mob rule.

And in our new Age of Democracy, the inequality between races is no longer ideologically acceptable. Happily, it is now being corrected thanks to recent ongoing progress.

The lands that Sauron once conquered from Gondor, and that Aragorn dared to claim back as he defeated Him, have now been returned to Orcs as their birthright, as affirmed to be so by their most sacred traditional religion. Native governments have replaced the former imperialist foreign rule; human oppressors of the past have been toppled, and their foreign rules have been replaced by laws that better fit the Orcish culture, and its traditional appreciation of the relationship between clan members. Theirs is a religion of peace proclaims the Elvish elite in newspapers, who add that the Holy War of killing and raping they previous waged was actually but an obsolete interpretation of what is actually a spiritual mystic endeavor around the universally shared values of Peace and Love. The Dark Lord Sauron the Orcs worship is but another respectable prophet of the creator God Eru Illuvatar (who otherwise doesn't exist). Orc priests concur or don't -- who's to learn orcish grunts and regularly follow the sermons to disagree with how the Elvish elite says the Orcs worship?

In human countries, immigrant goblins now have civil and voting rights, and there is affirmative action in their favor. It was found that the low number of goblins in the arts and sciences is not due to their inferior intellect but to prejudice, and massive funds are spent to encourage their studies, including reserved seats in universities, where they now displace dwarves (who would have been unjustly privileged as being "brighter" according to previous criteria imposed by human imperialists). Under penalty of harsh punishment for race discrimination It is forbidden to fire a goblin, or to pay him according to any kind of "objective" measurements of his intellectual or physical ability or productivity; after all the meaning of numbers out of such measurements is a social construct, whereas the equality of races is an axiom (recently) given by the God of love Eru Illuvatar (who, we are reminded, doesn't exist unless by that name you mean Sauron's Morgoth, who does exist and is the same God, since goblin traditions are equal to human traditions, except that the latter should be ditched).

Protectionists combat globalization and insist on trade barriers to protect countries from the unfair competition of foreign countries that create the same goods for cheaper (in a blatant violation the essential equality of productivity between races, which constitutes a proof of the continuation of human oppression). At the same time, they insist on "fair trade": a handful of goblins should be heavily subsidized for continuing the production of low-value-added traditional goods by inefficient methods; the others should be barred from trade with the human world, and should leave their kids starving and tilling the soil rather than employed by human exploiters using foreign capital and methods.

Protectionists obtained tariffs and subsidies so that hobbits should forge their own metal goods from recycled ore, while dwarves should grow their own hydroponic pipeweed under artificial lighting in their dark caverns. Of course, pipeweed itself is heavily taxed and heavily restricted; only government-approved varieties are allowed, and only if grown at government-licensed farms. A war on illegal pipeweed growers and smokers is being waged, and we're hopeful that it will bear success imminently, especially considering the success with which the police catches a great number of inner-cavern orcish youth who drive the traffic. At the same time, any poverty and criminality amongst this orcish population should be interpreted as a fruit of continued psychological human imperialism, for which humans should atone by subsidizing single-motherhood amongst orcs.

The Hobbit Shire, continuing the isolationist policy made Law by early Kings, have very strict laws against immigration. Even tourists find that accommodation is hard, as is communication with these people with their own language and tiny high-pitched voices. Unlike most other developed countries, the Hobbit Shire doesn't have access to imported Orcish workers for jobs requiring brute force; they don't even use human workers; the Shire is to remain exclusively hobbitic. What they do is develop their own combinations of elven magic and dwarvish craft to build robots.

Foreign orcish countries are to educate their own doctors and engineers. Surprisingly, the few good students come study in human universities, and most try to not come back to orcish caves. They seem to prefer life in human societies ruled by human laws where their traditional culture is celebrated, than in their newly democratic societies ruled by native governments where dissent is repressed -- even though we know this repression is equally valid to our "liberties", and much more befit to their national traditions and innate nature than said so-called "liberties" that humans previously imposed upon them so imperialistically (and the proof that those "liberties" are bad is that we failed to respect them perfectly in this attempt of imposition).

And this, my friends, is our glorious Democratic Era, organized according to principles so much superior to those of the reactionary rule of Kings.

(Tout) Contre Picasso!

Mon, 30 Mar 2009 03:13:39 GMT

Dans la série "je décode l'art pour vous", après vous avoir livré le secret de Lovecraft, je vous propose la clef de Picasso, que j'ai découverte il y a quelques années.

Pour le peintre classique, le but était de produire une oeuvre telle qu'en regardant le tableau, le spectateur fisse l'expérience visuelle qu'il aurait pu avoir s'il avait assisté à la scène dépeinte. La photographie, en achevant ce but, rendit cette peinture classique inutile en tant qu'art de reproduction de scènes réelles, et libérait en même temps les peintres des contraintes de ce but. Le génie des impressionistes avait été de mettre en peinture la texture de la scène non pas telle que le spectateur pourrait la percevoir mais telle que l'artiste l'avait effectivement perçue. Le résultat est frappant chez Van Gogh, qui était très vivement sensible aux couleurs et flux lumineux, et a transmis ces sensations de manière magique.

C'est en poussant ce principe à fond que Picasso en est arrivé aux portraits déconstruits qui ont fait sa renommée.

Prenons comme exemple la prostituée en bas à droite du tableau qui a lancé sa période cubiste en 1907 quand il avait 26 ans, "Les Demoiselles d'Avignon"; ou pour une oeuvre montrant son art consumé, ce portrait cubiste de sa dernière compagne, Jacqueline, peint en 1967 et maintenant accroché aux murs du LACMA. Dans un cas comme dans l'autre, on retrouve ce style charactéristique qui a rendu l'artiste célèbre: les deux yeux ne sont pas à la même hauteur; le nez est largement déformé; il y a un vide à la place de la bouche, sauf peut-être pour un coin de lèvre; les seins sont vaguement présents; le bas du corps est grossièrement représenté. De quoi s'agit-il?

Eh bien, simplement de ce que l'artiste perçoit, étant donné la pose du modèle et la distance de l'artiste. Si vous ne voyez pas, recrutez un modèle, et mettez-vous à la place du peintre. Le paragraphe précédent correspond-il à votre perception? Non? Alors, rapprochez-vous. Toujours pas? Rapprochez-vous encore. Encore. Davantage. Et si vous y êtes presque, peut-être devrez-vous ajuster délicatement la position de la tête du modèle avec votre main droite. À quelle distance l'artiste se trouve-t-il du modèle? Quelles sont les positions respectives et relatives du modèle et de l'artiste? Où se trouve la bouche du modèle, pour être hors du champ de vision de l'artiste? Quelle est cette grande main caressant le visage du modèle?

Une fois que vous avez répondu à ces questions, vous comprenez d'où vient le style de Picasso. Picasso comme Lovecraft, d'une situation érotique banale fait non pas une vulgaire illustration graveleuse, mais le point de départ d'un style nouveau, qui transcende cette origine pour ouvrir un nouvel espace créatif.

Chapeau donc au vieux satyre. Il a certes souvent pratiqué la quantité au détriment de la qualité; il s'est essayé à une diversité de styles et de média souvent peu convaincants; professionnel de l'autopromotion plus encore que de l'art, il a su vendre du vent à prix d'or à un public fort peu critique; non content de se faire défenseur auprès des masses des pires régimes génocidaires de tous les temps (qui le payèrent en retour en faisant mousser sa renommée), il s'est conduit envers ses proches en narcissiste abusif (en plus d'amant inconstant et mari volage). Picasso était un salaud de premier ordre, dans sa vie publique comme dans sa vie privée. Mais malgré tout cela, saluons un maître!

Boston Lisp Meeting 2009-03-30 update: Lightning talks, etc.

Wed, 25 Mar 2009 14:04:45 GMT

As previously announced, there will be a Boston Lisp Meeting taking place Next Monday, March 30th 2009 at 1800 at MIT 34-401B, where Carl Eastlund will speak about Modular ACL2. http://fare.livejournal.com/140695.html

Additionally, having observed the success of the formula at ILC'2009, I'm instituting Lightning Talks at the Boston Lisp Meeting. At every meeting, before the main talk, there will be two slots for strictly timed 5-minute talks followed by 2 minutes for questions.

Our first Lightning Talks will be given by Matt Knox and François-René Rideau. http://fare.livejournal.com/140960.html

Matt Knox has been hacking on Ruby and Scheme for the last 3-4 years. Looking at Rails, and how to fundamentally improve it, he came up with GoaloC (Generate on a Lot of Crack).

I, François-René Rideau, am a story-teller who dream of myself as a software author. I will address designers of computer languages and systems about Better Stories, Better Languages.

Dinner: ITA Software, is kindly purchasing a buffet to accompany our monthly Boston Lisp meeting. Anyone who attends is welcome to partake. However, we appreciate it if you let us know in advance you're coming, and what food taboos you have. Tell us by sending email to boston-lisp-meeting-register at common-lisp.net (you remain anonymous, no spam, no ack unless requested).

Finally, our next next meeting will happen on Monday 2009-04-27, and will feature Noah Goodman on MIT-Church, a non-deterministic Scheme. The previously announced speaker, Norman Ramsey, will hopefully be speaking in May, on purely functional dataflow optimization (in Haskell).

Next Boston Lisp Meeting: 2009-03-30 1800 at MIT 34-401B - Carl Eastlund on Modular ACL2

Wed, 04 Mar 2009 05:55:30 GMT

Carl Eastlund will give a talk about Modular ACL2.

ACL2 is a Common Lisp-based fully automated theorem prover. It was originally based on the Boyer-Moore theorem prover (Nqthm), and is currently developed by J Moore and Matt Kaufmann at the University of Texas at Austin. ACL2 has been used to verify critical hardware and software systems by companies including Intel, AMD, Rockwell-Collins, and Sun Microsystems, and won the 2005 ACM Software Systems award. This talk presents Modular ACL2, an extension of the language of ACL2 to include a module system supporting reusable proof components, external specifications, and separate development/verification.

Carl Eastlund is a Ph.D. candidate at Northeastern University's Programming Research Lab. His past research has included hardware description languages, models of object oriented programming, functional GUI representations, and the Fortress programming language. His current work contributes programming tools and language extensions to the ACL2 theorem prover.

His website is at http://www.ccs.neu.edu/home/cce/

The Lisp Meeting will take place on Monday March 30th 2009 at 1800 (6pm) at MIT, Room 34-401B.

As the numbers indicate, this is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

* *

We appreciate it if you let us know you're coming, and what food taboos you have, so that we can order the correct amount of food. Tell us by sending email to boston-lisp-meeting-register at common-lisp.net. We won't send any acknowledgement unless requested; importantly, we'll keep your identity and address confidential and won't communicate any such information to anyone, not even to our sponsors.

* * *

The previous Boston Lisp Meeting on February 23rd had 40 participants. Dimitris Vyzovitis gave a demonstration of his powerful toolkit to build distributed systems in PLT Scheme, Gerbils: http://web.media.mit.edu/~vyzo/gerbil/

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html

Creationist programming vs Evolutionary programming - Epilogue

Thu, 19 Feb 2009 12:08:25 GMT

Back in December 2007, I started publishing in a series my essay Creationist programming vs Evolutionary programming: I, II, III, IV, V, VI. The essay was itself based on a speech I gave at ENS in October 2005, and served as the basis for another conference I gave before the MSLUG in January 2009. I have now at long last completed that essay, that now counts about ten thousand words. Shame on me for the delay as well as the bad quality that doesn't justify it. I hope that at least the contents will inspire you.

You can now find on my web site my essay From Creationism to Evolutionism in Computer Programming, subtitled The Programmer's Story: From Über-God to Underdog. As compared to the previous MSLUG conference (see slides), the essay contains a vastly expanded second part on the prospective future of the evolution of programming, and my vision for TUNES. Enjoy!

Abstract: Programming tools imply a story about who the programmer is; the stories we tell inspire a corresponding set of tools. Past progress can be told in terms of such stories; Future progress can be imagined likewise. Making the stories explicit is a great meta-tool... and it's fun!

Good News for the Anti-Darwinist!

Thu, 12 Feb 2009 14:56:30 GMT

If you don't care for your survival-or-not, I have good news for you: your survival-or-not doesn't need your care; thanks to this free voucher your survival-or-not will take care of itself, picking the "not" branch by default.

This Special Darwin-Day Voucher, is valid for any "you". We do not discriminate against individuals, races, genes, memes, or life substrate. You may print or photocopy this voucher at will. Redeem at your nearest cemetery.

Next Boston Lisp Meeting: Monday February 23th 2009 at 1800 at MIT 34-401B

Wed, 11 Feb 2009 17:07:06 GMT

Dimitris Vyzovitis will give a talk about Programming gerbils: Distributed programming with PLT-Scheme.

vyzo will talk about gerbil, a little language for distributed programming using PLT-Scheme. Gerbil is a macro language that provides facilities for actor-based distributed programs and transparent network simulation.

vyzo is a PhD student at the MIT Media Lab who suffers from a severe scheme addiction.

His website is at http://web.media.mit.edu/~vyzo/

The Lisp Meeting will take place on Monday February 23th 2009 at 1800 (6pm) at MIT, Room 34-401B.

As the numbers indicate, this is in Building 34, on the 4th floor. This is the usual location, on 50 Vassar Street, Cambridge.

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

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us.

* *

Dinner: ITA Software, a fine employer of Lisp hackers (disclaimer: I work there), is kindly purchasing a buffet to accompany our monthly Boston Lisp meeting. Anyone who attends is welcome to partake. We appreciate it if you let us know you're coming, and what food taboos you have, so that we can order the correct amount of food. Tell us by sending email to boston-lisp-meeting-register at common-lisp.net. We won't send any acknowledgement unless requested; importantly, we'll keep your identity and address confidential and won't communicate any such information to anyone, not even to our sponsors.

* * *

The previous Boston Lisp Meeting on January 26th had over 30 participants. David O'Toole gave a wide-ranging overview of the hacks he uses as an infrastructure to write Rogue-like games in Lisp.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html

Who's responsible for that moving part?

Tue, 10 Feb 2009 18:25:54 GMT

Common Lisp pathnames have long been a source of frustration for users and implementers alike. I'll argue that the deep reason for this frustration is that the Common Lisp standardization process resulted in declaring as fixed an interface to a moving functionality, preventing users' needs to be addressed with no one in charge of addressing the discrepancy.

The Common Lisp standard was built in the 1980's by gathering language experts, most of them representing implementation vendors, describing what was common practice, bringing some uniformization where there were arbitrary differences, and cleaning up the easy or obvious problems. Any irreconciliable differences were simply left as unspecified implementation dependencies.

What that means for the programmers is that if they restrict themselves to those behaviors that are specified in the standard or a widely accepted extension of it, they can write programs that are portable from one implementation to other existing and future implementations. If they don't care too much about portability, then the standard is a wholly irrelevant document to them; they are better off reading directly the manual for the particular implementation they are using. But if they do, it is important that they avoid unspecified non-portable situations.

Most of what the language standard describes is basic tools to build algorithms; this is a somewhat self-contained field, and it allows for arbitrary decisions that become correct by fiat. Should (CAR NIL) return NIL, signal an error, or remain unspecified? Common Lisp says "return NIL", and tries to make other choices consistently with that decision; it could have gone another way (and does, in other languages), but there's not much point arguing about it. On the one hand, it allows for a lots of programming puns; and Common Lispers enjoy punning. As Henry Baker puts it, "[A] Computer [programming] language is inherently a pun -- [it] needs to be interpreted by both men & machines." On the other hand, it makes it harder to distinguish meaningful programs from nonsense; but Common Lispers don't care to make that easy, which isn't today's issue. One could also reproach Common Lisp not being declarative enough, but most programming languages are based on operational semantics anyway, so this is also not to be debated today.

What matters today is that some parts of the programming language are not an arbitrary choice left to the language designer. They represent the need that programmers have to designate programming concepts that describe things outside the program being written: interfaces to the rest of the world, I/O devices and the routines that drive them, programming conventions and the libraries that implement them. That such interfaces are needed is an unescapable fact of reality; yet that fact is often blanked out in discussions about programming language design: interfaces to legacy systems, foreign-functions, existing libraries, are often thrown in after-the-fact without much thought, careful design, or understanding of their impact on the formal properties otherwise claimed to be achieved by using the designed programming language.

If all the software in the world were to be written in said language, on top of the functionality provided by the standard, then indeed it wouldn't be necessary to interface with other software, for there would be no such other software (but it would be all the more necessary to have a good way to program in a modular way in said language). People who try to program everything in an autarkic world may ignore the notion of interface, at the cost of having to mind all the possible issues ever minded by anyone else whose code they could have used but have to do without, and doing away with features they don't have time to code themselves. But for most programmers, and every day more so as code gets written to handle an exponentially increasing number of things that one may want to handle, ignoring other software is not an option. And so it is important that their programming language should handle interfaces to foreign (and native) functionality.

Now, file system access is precisely an example of such foreign functionality, as the Common Lisp standard never claimed to encompass operating systems, to specify the precise semantics of how data persists, or any such thing. Quite the contrary, the standard tried to accommodate to the fact that Lisp programs would run under such vastly different environments as Unix, Genera, VMS, MSDOS, Windows, Multics, embedded systems, and any future operating system. The goal is all good and fine; but the bone of contention lies in how to properly implement this goal.

The Common Lisp standard contains three chapters specifying in great detail the structure of pathnames used to designate files, the semantics of opening a file, the operations permitted, etc., yet at the same time leaving plenty of leeway for implementations to match or not match the respective underlying operating systems.

Because the standard only specifies a "greatest common denominator", programmers who strictly adhere to the discipline of only using portable behavior find themselves unable to use any but the most basic filesystem functionality available to users of other programming languages. Because the specified functionality is relatively abstract, there is a gap between what the underlying operating system provides and what the language implementation exposes; language implementers have to spend a lot of resources bridging that gap one way; and language users who accept implementation-specific extensions to go beyond what the standard offers have to spend just as many resources bridging that gap the other way around when they want to interact with both the underlying system and the standardized services. Language implementers and users are thus pitted ones against the others in a huge waste of resources. Because there is a degree of arbitrariness in the way the gap is bridged, multiple language implementations on top of the same operating system are not interoperable and the work of abstraction and reversion has to be done twice for each pair of language implementation and operating system.

The Common Lisp standard includes a lot of things that don't mean much in modern operating systems, such as file versioning (people nowadays choose from a wide range of versioning tools available in user-space, that have much more functionality, in a much more flexible way, than what filesystems used to provide in a hardcoded way), a now murky division of pathnames in host, device, directory, name and type that non-portably gets in the way of handling actual pathnames (each component may or may not make sense depending on the system), or a mostly useless crippled "logical pathname" facility (the only portable use of which lies in abstracting somewhat the location of source code in Lisp-only projects), or some semi-useful "wildcard" mechanism. All of it both over-specified in the concrete representation of pathnames and under-specified as far as the syntax, semantics or extensibility mechanisms are concerned (which for the portable user equates "specified to be unusable"). The same standard crucially lacks support for binary filenames that don't obviously map to or from characters in the day of Unicode, for pathnames that are not yet known to be pointing to files or directories, for symlinks especially, for multiplexing between many I/O channels, for advanced globbing and pathname selection techniques, for all kinds of security permissions and additional attributes that files have in modern operating systems and that one has to care for, etc. Many of these evolutions indeed the standardizers couldn't possibly have anticipated, though many already were well underway when the standard was finally stamped. What the standardizers could and probably did anticipate was that evolutions would happen that would make their document obsolete.

It is a fine and honest thing to humbly admit incompetence. But from this statement of incompetence, the conclusion should not have been to specify a half-baked version of a file system interface in their standard. The conclusion should have been to omit file system access from the standard, and to either explicitly delegate it to an existing competent authority, or call for other such future authorities to complete the standardized work. Maybe the standards committee could have acquired competence by spawning a permanent subcommittee to constantly keep that aspect of the language up-to-date with technological progress in that field to ensure that user's needs are always covered. But admitting incompetence and then claiming authority notwithstanding this admission of incompetence was a great disservice done to the whole community.

The correct way to not standardize would have been to acknowledge that each operating system offers its own interface, and to recommend that each Lisp system should provide a direct access to such interface. Inasmuch as such interfaces may themselves be expressed in other programming language, the correct way to standardize would have been to standardize on foreign function interfaces that allow to call arbitrary such functionality from Lisp, instead of requiring a new extension to the standard with every new library written in a foreign language.

Happily, where the language standard committee has failed, free software projects have recently (decades later) taken the relay and done the Right Thing(tm). CFFI standardizes interfacing to foreign (C) language functions across all implementations and platforms. IOLIB gives you direct access to operating system functions on many platforms, with the intent of supporting all meaningful platforms and building meaningful portable interfaces where they actually make sense. Hopefully, IOLIB will standardize for each platform on the operating system's native representation for pathnames as the one single concrete representation that makes sense (i.e. under Unix, wrapped foreign C strings), and provide accessors that abstract away the concrete representation and allow for implementation-independent (but somewhat OS dependent) syntax and semantics for dealing with pathnames.

Using such tools, instead of having to implement your desired functionality once per implementation per OS, you only have to implement it once per OS. Instead of having to use detached abstractions that correspond to nothing and are unable to express either what you want or what the system wants, you can build the simplest path from what you actually want to what the various systems you need to use actually want. Along the way, you will most certainly build simplifying constructions that better factor the system considering the actual constraints; but these will not be detached abstractions, but abstractions anchored in reality.

Providing the building blocks on top of which users could implement themselves the missing bits that necessarily exist in any language: such would be following the principle of user-driven language extensibility. Unhappily, whereas the Common Lisp standardizers got it mostly right for syntax, they got it completely wrong for system access.

Standards are tools in a wide-ranging social phenomenon of coordination between many programmers. They are contracts separating the partaking programmers into two sets with well-defined responsibilities: implementers and users of a programming language. They are contract you can opt in if you think they will bring you value, and opt out without penalty if you think they won't. Because not everyone has the same expectations about value, people will prefer some contracts to others, resulting in a wide variety of standards. (Note how much better this variety of contracts is than the forced uniformity of statute, whereby the same binding terms are imposed to everyone, whatever their static and dynamic expectations. Uniformity isn't good in itself, but Statists don't quite understand.)

Because some people understand that expectations change, fast, as situations evolve, they constantly adapt the contracts they use. Java Specification Requests, Python Enhancement Proposals, Scheme Requests For Implementation, etc., are ways in which some programming language communities try to keep their language relevant with respect to the wide-ranging and moving challenges of programming. (That's why you shouldn't be afraid of service companies changing their terms of service as such; but you should be afraid of legislators and judges widening the meaning of implicit consent or enforcing privileges of intellectual "property" upon you). That's how some programming languages may be extremely rigid when you consider static snapshots of them, yet remain relevant because the languages communities are somewhat flexible in their dynamic adaptation. This, combined with open-source implementations that allow one to experiment with what one cares for until the community follows (or doesn't), can bring enough adaptability to unextensible languages, to make them more bearable to one than easily extensible languages that lack actual libraries and extensions to deal with one's real world concerns.

Once you understand programming language documents not as mere technical documents, but as social tools to coordinate people, you can critique them from a new perspective. Who promises to whom to take responsibility for what in exchange for what? What about the contract brings value to both parties, and what doesn't? These are questions you should be asking when working on programming language design. Contracts are useful when they promote an efficient division of labor, whereby the more competent in a specialized field easily take responsibility for work in said field at the benefit of others, at low cost. Contracts are harmful when they create unnecessary work, when they assign responsibilities to the wrong people, when they impede future improvement in division of labor. Design your contracts carefully; include what works, exclude what doesn't.

Denying moral agency to justify Cosmic Sacrifice

Fri, 06 Feb 2009 03:28:46 GMT

Once in a while, I visit the blog Overcoming Bias where Eliezer Yudkowsky and friends of his sometimes have interesting articles on rationality. At the same time, reading this blog leaves a feeling that there are some deeply flawed assumptions behind it. And so, reading a piece of science-fiction that Eliezer wrote was a good opportunity to examine what these assumptions are: fiction lets you see what aspects of reality the author considers essential, what aspects of reality he omits. The dilemma proposed by Eliezer made me post several comments on the kind of mistakes that even some obviously extremely intelligent people make. If you enjoy reading such short a piece of Science Fiction, do it before you read my comments below.

I'll gloss over the part of political hero-worship where the life-and-death destiny of whole societies, species, galactic collections of species even, is decided exclusively through the individual interactions between each party's great leaders. I'll also forgive an author's hubris of obviously projecting himself as the great leader who ultimately decides the fate of mankind. Who doesn't have such grandiose fantasies? And where better than in a Sci-Fi short story to indulge in them? I don't expect himself or anyone else to fall in the trap of taking these aspects of the story seriously. Such defects are par for the course, and come with the genre. On the other hand, since the story is meant as a fable on morality, I will discuss mercilessly the flaws in its ethical assumptions.

Eliezer poses as universally accepted the notion of a moral duty for everyone to altruistically minimize the unhappiness of everyone else. All sentient beings in the universe known or unknown count more or less equally in the total unhappiness than one must minimize. That total may be optimized in the long run at the cost of a few temporary victims to be sacrificed for the common good. Notably parents may be sacrificed in the alleged interest of their children, and whole classes/races/species may be eradicated because they are not a good fit for the Happy Future.

Eliezer conflates pain with unhappiness, and presents as a serious option the complete elimination of pain for universal good, sentientkind thereafter living a life of perpetual pleasure. But pleasure and pain are signals that indicate we are on the right or wrong path to whatever our goals are. There's a point in making it a better signal that more precisely shows the path -- assuming you can somehow come up with such a statistically better signal. But it is absurd to claim to eliminate pain itself: that's eliminating the signal, and removing our guide to achieving our goals. It is about as absurd to claim to change people's neural systems to feel either more or less pain in the average: that's only bias the signal so it carries less information per feeling, making for slower, more expensive emotional feedback. Eliezer denounces the habituation that makes pain and pleasure disappear as some dulling of moral sense; on the contrary it is how we keep functioning at the margin, where the effort is needed, instead of obsessing on things we can't marginally improve. And that's why it is good to use painkillers for a disease that has already been taken care of as much as could be, but not for a disease that has not yet been diagnosed.

Worse than that, to forcefully arrange for others to never possibly have pain is to destroy their very moral agency; in the name of their happiness, you deny them as sentient agents, you disconnect them from reality, you anesthesize their moral sense, you pander to their every whims until reality strikes back despite all your shielding. And in the name of this Greater Common Good that is the annihilation of individual morality, the altruist justifies mass murder.

Eliezer fancies himself as a thinker for the morality of the future, but his vision of morality is the ancient rotting cadaver of collectivist egalitarian altruistic utilitarianism, as inculcated to him by his judeo-christian upbringing (judeo in this case). It is the same stinking collectivism that in the past inspired all totalitarian mass-killing regimes and their singers, from Ancient Egypt to North Korea, from Plato to Pol Pot. The same stinking collectivism that still poisons politics today, and serves as a pretense to justify all oppressions. Trampling on people's Liberties in the name of the Greater Common Good.

Yet those who seek a world of equal happiness for all are ultimately bound to find that Life is the worst of all social inequalities. To suppress inequalities, they must either resurrect all the dead people (and give life to all the potential living people), or exterminate all the actually living. Egalitarians, since they cannot further their goal by the former method, inevitably come to further it by the latter method.

A sane moral person shall not feel responsible for other person's pain, except when the first person indeed caused the pain by his own actions. And even despite any interference that one may suffer from other people, to claim that the primary responsibility on one person's fate lies in the acts of other people is to deny the fact that one is one's own moral agent. Temporarily denying one's responsibility on one's own fate is indeed to treat one as a child. Permanently denying one's responsibility on one's own fate is indeed to treat one as an animal. Those who deny this responsibility are not one's friends, but one's most mortal enemies.

Why should one be responsible for the fate of other people one has never interacted with? There is no reason, and cannot be one. On the other hand, there is a moral duty of justice, to not actively harm other people, to not violate on their life, liberty and property -- or to have compensate them for the trouble. And this basic duty specifically forbids us to sacrifice anyone in the name of any Grand Scheme.

Why Language Extensibility Matters

Thu, 29 Jan 2009 02:06:21 GMT

If you neglect some aspect of computation in designing your programming language, then the people who actually need that aspect will have to spend a lot of time dealing with it by themselves; and if you don't let them do it by extending your language, they'll have to do it with inarticulate barkings rather than civilized sentences.

So you think you can overlook such facts of life as having to support multiple concurrent isolated virtual worlds on a same machine, communicating with such other worlds on other machines? Forget to specify how concurrent activities can co-exist at all? Leave out persistence and retrieval of data outside of your language specification? Omit ways to interface directly with existing libraries and external programs? Or just do a shoddy job at it that is not robust or comprehensive enough to sustain serious use in software that matters to programmers?

Then programmers will retrofit into your language such crocks as threads, whereby user code may arbitrarily break the system invariants of your otherwise safe language (if at all). They will resort to brittle external tools such as shell scripts to bind together the pieces of your system. They will curse you as they scramble to reimplement the interfaces you left out, in as many different and differently fragile ways. They will waste countless months rebuilding infrastructure to properly talk to databases, and get crazy having to deal with persistence, transactionality and schema upgrades through manually coded conventions rather than automatically enforced mechanisms.

Now there are infinitely many possible aspects to programming, new ones being invented everyday and becoming popular every year; as a programming language designer, you can't be reasonably expected to have already provided a well-designed interface to all of them in your programming language. Handling all possible aspects of programming that anyone will ever imagine to care for not only requires more resources than you can ever provide, but also a wilder imagination than all you can ever have. And so, you can never design a system that does everything for everyone, all the time. Therefore there will be (infinitely) many things that your computing system won't be able to fully handle; even for the finitely many things that you handle, you will find that you lack the resources to update and maintain your system so it keeps handling those features as the related needs evolve.

But then, you should at least admit defeat, and do not try to fake having a solution: give your users direct access to the guts of the system with which they can build actual solutions, instead of providing any misdesigned partial "solutions" that can't possibly be made to fit their needs. Any half-assed pseudo-solution you offer will be treated as damage and be routed around. Programmers who need to get things done will bypass your puny file-system abstractions and directly use low-level system calls interfaces -- or they will just prefer better lang uages that don't introduce any superfluous impedance mismatch between them and the realities they have to deal with. Until of course such languages degenerate to the point that they do introduce an impedance mismatch once again! Which might be but a minor nuisance, or convince users to fork your language or migrate away, depending on how much that matters to them.

Your system can't be the be-all end-all for everyone all the time. That is why it is very important that your system should be extensible. Now, some systems are only extensible because the source code is available. That's already infinitely better than systems where the source code isn't. But one can do much better: you can design your system so that it can be extended from within, with some macro system as in Lisp or Scheme, or some grammar extension system as with camlp4 or pepsi.

The original Lispers had that principle that there should not be any system programmer privilege: any user of the language or system should be able to do anything that the system or language implementor can do. For instance, whereas in Pascal there was this magic multi-argument PrintLn procedure when all user-defined procedures had a fixed number of arguments, Lisp goes through great length so that all the magic available in any of its functions or special forms could just as well be reimplemented or done differently by language users with the available primitives. You can implement your own elaborate object system on top of the language, and that's even how the reference implementation of the Common Lisp Object System is itself written; that's also how in practice users implement say an automatically prefixing variant of with-accessors with the help of symbol-macros and/or setf-expanders.

Now when everything can be defined and redefined, there is the worry that you can't trust anything, because the most basic things might have been redefined. The worry is actually quite legitimate, as interesting malicious Javascript cross-site scripts have shown. But the solution is not to prevent language modification; the solution is to allow the user to abstract over and control which modified language variant he is using. Thus, anyone should be able to easily define a new language, create compilers, analyzers and processors for such a language, write programs in that language or program-generators targetting it. Any invocation of a program would make include the implicit or explicit specification of an appropriate processor, with sane defaults that can't cause unrelated programs to go wrong. This the Common Lisp community failed to do so far with its paradigm of side-effecting the read-time or compile-time environments. But PLT Scheme handles such language abstraction like a charm by letting each module declare what language it is written in.

To paraphrase Hayek, IndividuaLisp is thus an attitude of humility before the program languaging process and of tolerance to other opinions, and is the exact opposite of that intellectual hubris which is at the root of the demand for comprehensive direction of the program languaging process.

Beautiful Models

Wed, 28 Jan 2009 01:36:37 GMT

Suppose some causal relationship between some measurable phenomenon A and some measurable phenomenon B, through some undetermined positive feedback loop (respectively a constant statistical proportion, or some other simple mathematical construct). But how much does A depend on B? Well, do it scientifically, by computing with lots of experimentally measured numbers! You put some historical numbers in, you fit your model to those postdictions, and ask your simulation to make predictions about the future. What do you get? An exponential future growth of A due to B (respectively, a proportional growth of A, or whatever follows your causal law). And what happens if you force B to be higher or lower in the future? Then the growth of A correspondingly goes faster or slower. This establishes a clear dependency of A to B, doesn't it?

Well, yes, of course -- it establishes the dependency you introduced in the model, to begin with. The positive feedback loop is a conclusion of the model only because it was inserted as an explicit premise of the model. To wave around your model with lots of numbers and graphics as a proof that something alarming is happening and that production of B should be stopped (respectively started), is a fallacy: it is a petition of principle hidden under a lot of verbiage, it is intimidation using the usurped authority of "official truth", it is confusion of the layman by a mass of numbers and complex maths, it is numerology dressed up as science.

Unhappily, that kind of pseudo-science is what is taught in universities and used as the basis for public policy, in such domains as economics, sociology, and as of late, climatology. And it is pseudo-science precisely because it is used as the basis for public policy, in a positive feedback loop where government officials fund and establish intellectuals who justify their power.

Next time you're shown a model, skip all the numbers, all the mathematical formulas, the graphics, the computed projections, the "scientific" conclusions, and the policy recommendations. Ask what were the hypotheses on which the model resides; what are the relationships assumed between various phenomena, and why are these relationship assumed not to move in general, and in particular when the recommended policy changes the system?

More often than not, you'll find that the general conclusion was already assumed as a hypothesis to the model, and that the whole model is a swindle to smuggle the premise as if it had somehow been established by the model.

Sure, some keynesian economist will show you some beautiful equation, with aggregates that add apples and oranges, whose multiplicative relationship to some government-controlled variable is magically supposed to be constant, unlike simpler variables. "This equation is true by definition!" will he even claim. Sure. Just like it's true by definition that being hit by a magic long sword +2 will cause you 1d8+2 of hit point damage. That's also the definition, straight from the rulebook. The definition is tautologically true in the corresponding model. Now whether the model accurately describes reality, that's quite a different question. At least the D&D rulebook lets me have fun with friends and doesn't serve as a pretext to massive armed robbery.