Cybernethics / Cybernéthique

Idiocracy

Sun, 04 May 2008 04:48:11 GMT

University is a plot to prevent bright people from having kids.

Welfare is a plot to encourage stupid people to breed.

We know where the State stands with respect to eugenics.

Nationalistes socialistes de tous les pays, unissez-vous!

Fri, 02 May 2008 13:42:15 GMT

Dans son numéro du 20 janvier 2008, le Soleil "Le quotidien de la capitale" (de Québec) faisait sa propagande habituelle en faveur de la politique nationale socialiste du Québec et d'autres pays. En couverture et à nouveau en page le monde, photos d'une Hillary Clinton radieuse. En éditorial, soutien au bureaucrate local en chef (le maire de Québec) dans ses choix de dépenses contestés (par un fournisseur délaissé); là encore photo sérieuse, et pour compléter, autre photo joviale dans un autre article. Décidément, avec le Soleil, pas besoin de savoir lire pour savoir pour qui voter.

En nouvelle principale, petit article et grosse photo pour reprendre la propagande officielle sur la maladie d'Alzheimer; et de justifier des recherches mal inspirées aux résultats désastreux, basées sur une hypothèse falsifiée présentée comme vérité officielle (le rôle clef des bêta-amyloïdes), sans doute financées par l'argent public. L'important dans ces campagnes de sensibilisation, c'est de compatir et de ressentir ensemble - tous doivent partager les soucis officiels et nuls autres, et accepter sans discuter les solutions officielles proposées. Ensemblons! Beeeeh. Suivez le troupeau, il est bien guidé.

Mais entre faits divers et divertissements, appels à davantage d'intervention de l'État, et glorification du socialisme national et international, un entre-filet me choque profondément: page 10, au rayon alimenterre, Annie Morin reprend un communiqué du journal officiel du Zimbabwe expliquant badinement que le gouvernement y vendra de la viande d'éléphant séché, et qu'abattre 6000 éléphants par ans sera une bonne chose pour l'environnement étant donné la surpopulation d'éléphant.

Le Zimbabwe se meurt de faim à cause d'une dictature nationale socialiste, un pays autrefois riche est devenu pauvre par l'effet du communisme appliqué, la répression politique bat son plein, l'inflation galope, et voilà les seules nouvelles que nous rapporte de ce pays meurtri la propagande nationale socialiste québécoise: sa glorieuse politique environnementale.

Bravo.

Notons aussi les soucis environnementaux à deux vitesses de nos amis national socialistes. L'environnement, ça veut parfois dire sauver nos amis les bêtes des balles des méchants chasseurs. Mais une fois les bébêtes nationalisées, ça veut dire des gentils chasseurs en uniforme gouvernemental qui abattent les nuisibles bestioles maintenant déclarées trop nombreuses. Ah le prestige de l'uniforme! L'environnement ça veut surtout dire un bon prétexte pour justifier tout et n'importe quoi pourvu que ce soit le gouvernement qui le fasse, et qu'il nous balance le mot environnement dans ses explications. L'environnement c'est le nouveau refuge des totalitaires de tout poil. Mot-clef suscitant une réaction émotionelle pavlovienne d'approbation sans critique chez les citoyens préprogrammés.

D'ailleurs, après avoir fait deux fois la publicité du maire, le journal dans un de ses billets lui fait la leçon et lui explique pourquoi au nom de l'environnement, il aurait dû choisir un tramway plutôt qu'un train. Nulle élaboration n'est nécessaire: le mot se passe de justification, il est lui-même la justification universelle et sans appel de tout projet que soutiendra un publiciste parlant en son nom. Ah, si seulement le monde était dirigé par nos parfaits journalistes donneurs de leçons!

Vivement que le Québec devienne indépendant et rejoigne le Zimbabwe parmi les paradis nationalistes socialistes où le gouvernement s'occupera si bien de l'environnement!

Next Boston Lisp Meeting: Tuesday May 27th 2008, 6pm at MIT 34-401B

Tue, 29 Apr 2008 18:45:19 GMT

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

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

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

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

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

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

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

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

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

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

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

Warsaw 2008-06-28

Mon, 14 Apr 2008 11:52:08 GMT

I will be in Warsaw on June 28th and 29th to speak at the Libertarian International 2008 Spring Conference.

Since I don't want to preach to the choir what they already know or will soon know anyhow, I chose to tackle the topic I think is most missing from such conferences. That's why I announced the title of my future speech to be The Art of Living Free.

Now I have to find a great speech to put under this great title.

Simple Systemic Argument Why Democracy Can't Possibly Work

Thu, 10 Apr 2008 03:07:29 GMT

In a democracy as such, the total feedback control from the governed to the ruling is in the order of a few bits per year at most. Certainly, any process to satisfy millions of people with diverse preferences requires much more information than that. What is worse, the ruling class itself largely gets to define what those bits encode. And what damns the whole system, the individual incentives are for the ruled to not acquire such costly useless (to powerless them) information, and for the rulers to spread propaganda that will extend their power.

In other words, the powerful are pretty much out of control of the citizens. Certainly, a few bits per year of information might sometimes be better than none at all. But not for long, since the meaning of those bits is soon to be controlled by some variant of a two party system. The knobs controlled by those few bits will never allow to change the one thing that matters mosts: the irresistible growth of the power exerted over you, the fact that whoever is likely to be elected is a power hungry bastard backed by an organized predation system. Preserving and extending the power of politicians and bureaucrats upon citizens is a bi-partisan issue.

Inasmuch as some democratic societies work and others don't, it isn't due to democracy as such, but to other institutions completely independent of democracy, disconnected from it, and actually slowly but surely corrupted by it and destroyed by it as well as by any other form of political power: individual rights (as opposed to collective claims), common law (as opposed to statute), the rule of law (as opposed to the arbitrary power of politicians and bureaucrats), a culture of honesty (as opposed to having to weasel around imposed regulations), widespread self-reliance (as opposed to a sense of entitlement), and other personal moral values (as opposed to compulsory submission to "moral" rules edicted by others). These are the institutions of a market society, one where each one earns his living out of mutually voluntary cooperation.

Creationist programming vs Evolutionary programming, part VI

Wed, 09 Apr 2008 14:15:16 GMT

Here is the sixth installment in this series for my essay Creationist programming vs Evolutionary programming. Previous installments: Part I (Creationist programming, The Devil), Part II (Intelligent Design, Polytheism), Part III (Unintelligent Design, Lamarckism), Part IV (Supernatural Selection, Teleological Evolution), Part V (Natural Selection, Inside Evolution).

The Relevance of Paradigm Evolution

This evolution of programming paradigms is a nice story, but what is its relevance for software developers? After all, the tools described above already exist; they have been created, they have been engineered, they have been selected or they have emerged, without any of these paradigms being explicitly stated, much less used as a conscious guide. Do these paradigms correspond to anything real, or are they but a nice-sounding rationalization? Do we gain anything by spelling them out?

Well, as Daniel Dennett wrote, There is no such thing as philosophy-free science; there is only science whose philosophical baggage is taken on board without examination. This is true of computer science and computer engineering as of any other human endeavour. Just because you don't state your assumptions doesn't save you from the consequences of following them when they are erroneous, not anymore than putting your head in the sand would save you from predators you can't see. These paradigms do describe assumptions implicitly followed without a conscious decision, and each step in their evolution describes relevant phenomena to which earlier paradigms are blind. And those who make unconscious decisions are but surer victims of the problems they are blind to.

Realizing that some phenomena are not accidents happening during development, but constitute an essential part of it is necessary to properly address them. Failing to plan is planning to fail. If you assume say, the Intelligent Design paradigm, even though you may benefit from tools developed with latter paradigms, you will systematically waste resources trying to intelligently design what is beyond the reach of any intelligent design, or aiming at the only solutions reachable by it despite their being inferior to competition. However, if you go beyond intelligent design, you will come to better solutions naturally by letting them grow. By embracing a more primitive paradigm, you will introduce a lot of unnecesary nasty bugs by not taking seriously the systematic processes of weeding them out early with dedicated tools; you will systematically fail to consider cheap solutions that are at hand, but that do not lend themselves to a perfect algorithmic description, etc. Those who stay behind in terms of software development paradigm will be incapable of doing what will appear to them as clever lateral thinking, strokes of genius or unreachable fantasy, whereas those who master further paradigms will casually achieve feats previously deemed impossible by a simple systematized application of their more evolved paradigms.

To those who understand the relevance of such paradigms, the important open question is: what is the next paradigm, if any? Is the above Inside View of Evolution the be-all, end-all of programming paradigms? Is the refinement of existing tools our only hope? Or will some further paradigm catch on? Can one identify and adopt this paradigm early on, and thus get an edge over competition?

What then, if anything, is next on our road as far ahead of the current paradigm as that paradigm was of previous ones?

Paradigmatic Optimism

The simplest view about future paradigms is that there will be no new ones, at least none that works. Our understanding of software development is mature and as good as it can get as far as the big piture goes, though there may always be a myriad of minor details to get right. This is Present Optimism: the theory that we've already reached the limit of knowledge.

Of course, assuming there is finite understandable information about the big picture of software development, there will be diminishing returns in understanding the field and eventually not enough new relevant information to possibly constitute a new paradigm change for the better. And so we can be confident that this theory of Present Optimism will some day be true about software development paradigms as about many things.

On the other hand, considering how new the field of software development is and how fast it has changed in just the last few years, it seems premature to declare that we fully understand how software is developed and will not find new deep insights. If indeed our understanding of software development was to remain unchanged for, say, five to ten years, and all developers were to settle towards a finite set of well understood unchanging methods, then we could assert with much more confidence that indeed we have reached the acme of software development. But this hasn't nearly happened yet, and the case for Present Optimism is rather slim.

Another kind of optimism and a common idea about the future of software paradigms has always been that computers will somehow become more intelligent than men and will take over the menial task of programming, like djinns to whom you will give orders and who will grant your wishes. This is Extreme Future Optimism, or Millenarism: the theory that soon(er or later), we'll reach a Millenium where all our worries will be taken away.

However, this Optimism is based on a misunderstanding of what progress is about, a misunderstanding that is best dispelled by confronting it with the equal and opposite misunderstanding: the claim that such a future is bleak because it means machines will be taking all our jobs away. Hopefully the errors will cancel each other in a collision from which light will emerge.

Yes, computers in many ways have replaced humans for many tasks, and will replace humans for more tasks to come. The building of tools that replace human work in software development is what our whole story of paradigms was about. But competition by computerized tools does not destroy human jobs, it only displaces jobs towards new areas not covered by tools. Useful tools provide some of the same positive satisfactions as before and some more, while reducing the negative efforts; the goal of some previous jobs is fulfilled without the associated costs. The human resources previously used toward that goal are not destroyed but liberated; they are made available to be redirected to new useful endeavours that couldn't previously be afforded.

Furthermore, as long as humans and machines do not have the same relative performance in all activities, the law of comparative advantages ensures that the tasks relatively better done by meatware than by software will remain a domain of human activity. And even if machines do it better than humans, nobody prevents you from programming without machine help, or from choosing to sponsor a human rather than a machine for the programming tasks you need. Just like automation in other industries made these industries vastly more productive and mankind at large vastly more wealthy, so will automation in programming make software a more profitable industry and better serve mankind. Through all the software development tools already mentionned in the article above, automation already serves mankind, to a tremendous degree. Continuing to program in Java will no more provide job security than did programming in C++, COBOL or Assembly before; it will only guarantee a lot of wasted effort and ultimately failure in the Luddite refusal of automation.

What machines can neither possibly create nor destroy is on the one hand the desire for ever more, ever higher satisfactions, and on the other hand, the ability to adapt and work towards these satisfaction: in other words, human life, its drive and its spirit. Machines displace this life for the better, turning feats into chores, chores into menial tasks, menial tasks into assumable commodities. As our past worries are taken away, we worry about new often loftier tasks that become our focus. Ultimately, the only persons who create human jobs are human parents, and only illness and death destroy jobs away; the rest is a matter of organizing existing human resources. The fear of Artificial Intelligence is a lifeformist stance wrapped in the usual protectionist fallacies, and its narrowmindedness should inspire the same spite as racist or nationalist arguments before it.

Conversely, blind faith in Artificial Intelligence is yet another mystic superstition by millenarists dreaming of being saved from having to live their own lives. This blind faith is a cop out, in that it wishes away the very nature of programming and its intrinsic difficulties. Indeed, even if intelligent machines are to replace humans in the activity of programming, said machines won't be able cop out of a programming paradigm that way; the buck will have to stop somewhere, and the issues will have to be addressed. One of the main features of digital computer software as we know it is that it behaves, combines, and can be understood according to rigorous formal semantics in perfectly well-defined logics, whereas intelligence seems to be about dealing with fluid concepts, incomplete information, creative solutions, under misunderstood external pressures. Bridging that gap, if possible, can't be achieved by hand-waving. It requires a paradigm shift that the cop out precisely prevents from knowing.

The legitimate cop out is not to assume knowledge but to admit ignorance: my previous investigations didn't lead to any firm conclusion to this question, and I don't know have enough combined care for the matter and trust in the remaining available venues to investigate to afford further investigation. But are we reduced to this ignorance? Are there not things we know or can guess about the directions that the future may take?

TO BE CONCLUDED...

Databases vs Programming Languages

Thu, 03 Apr 2008 03:49:33 GMT

Rahul recently pointed me to a nice 1998 review of datamodels in the database world by Stonebraker and Hellerstein: What comes around goes around. This paper is quite insightful, and I believe a good overview of the field, but it falls into the usual traps shared by most database practitioners. This got me started to think about what programming languages and databases have to learn from each other.

Unlike most people (and not just in the field of databases), Stonebraker and Hellerstein also have a uncommonly good understanding of human factors in communication of meaning and economic factors in adoption of software, and how they often override technical concerns. They show particular insight in their discussion of Schemas, XML, and the inadequacies of "semantic web" concepts when automating business transactions.

Like most database people, these authors understand the importance of Data; they understand that Data is both precious and fragile against loss, corruption and bit rot. Meanwhile, most computer scientists are still struggling with the concepts of Persistence, Robustness and Evolution: schools teach how to program with self-contained one-off toys that have short-lived data and that no one depends on; all the focus is on the (important) immediate algorithmic aspect, but little is said about the (equally important) long-range aspects of software engineering. Precious Data needs to persist across runs of individual programs, across power cycles of the machine; it needs to survive crashes of individual programs, crashes of the machine; it needs to resist corruption by buggy programs or by race conditions amongst programs accessing it; its shape itself will evolve to meet new requirements, and although this phenomenon is much slower than the evolution of programs modifying data, the old data needs to be preserved through these changes, and somehow the system must continue to run all along. Yet by and large, programming languages and operating systems, even when they offer concurrent programming capabilities, do not offer proper support for transactions on the persistent data; whatever support exists for transactions often comes in clumsy and brittle libraries, and evolution is almost never supported at all (even less so with statically typed language).

However, like most database people also, these authors are not trained in semantics, and they can't seem to fathom the notion and the possibility of abstraction as a general concept. Instead, they speak here of queries to operate on sets of records, there of logical vs physical data independence, there again of keeping things simple, of user-defined types and functions, of standards, etc., and they seem to think of language expressiveness as a cute feature but not all that important (or at least they are content registering that the market values it little). More generally, they do not understand the notion of a programming language, and think they can get away with throwing together features for their database interface and achieve a satisfactory design that will be used by application writers in a language independent way. Yet, the whole notion of language independence boasted by database designers (as well as designers of operating systems and other infrastructure) is but the pride by these self-ignorant mono-linguists to not call their own barking a language. To them language is a slur for what application programmers use. Little do they realize that the database interfaces they are offering are programming languages indeed and that their ignoring the hard-earned lessons of programming language design imposes a high cost upon themselves and their users.

Most importantly, most database people deliberately try to ignore the dynamics of the algorithms that manipulate data, but instead have mostly read-only views of data for which they design fancy query sub-languages; they fail to recognize the importance of concepts of ownership, of intensionality vs extensionality, etc. Because of the limitations they impose, application writers have to retrofit these concepts in ways the consistency of which is not taken into account by the otherwise sacrosaint integrity management of the database. The whole discussion about datamodels is thus poisoned by an attitude based on the wholly absurd premise that a datamodel is a modular aspect of an application that can be factored away from the rest of the system.

This attitude is not so problematic in the case of database gurus like the authors of said article, who are able to adapt the internals of the databases they develop to extend their datamodels to fit the needs of application writers. But lesser database specialists, who do not develop and extend databases, reduce all data to some poor datamodels, where data relationships as something static and cast in stone; they consider computations that will happen on the data as something unfathomable, irrelevant, unworthy of interest, modularized away. As a result, they insist on alleged simplifications, normalizations and representations, that only simplify, normalize or represent but the small part of the system that they oversee, at the expense of hugely increased complexity in the rest of the system, and communication problems between developers.

The worst kind of datamodellers is those data bureaucrats who code neither application nor database infrastructure, but who imagine themselves the masters and keepers of some datamodel that has a value independent of the rest of the system. They spend their time slowing down development with bureaucratic processes and time wasted using their pitiful tools and pseudo-languages, contributing nothing but complications and gratuitous dependencies for those who manipulate the data, have the domain expertise, and actually understand what the data is all about.

To be fair, blindness and bureaucracy are not the exclusive attribute of Data guys. There is plenty of such horrors amongst Code guys. Blind Coders will lightly consider data persistence as well as all I/O to be architecturally unimportant ancillary tasks that can be factored away from code. Code Bureaucrats will insist that everyone should use their one blessed Language and Implementation, strictly respect their Object Model and Programming Methodology, and follow canned templates or graphical tools to export and document interfaces or models that they have to bless. The worst amongst them will declare that they own the API and create additional hurdles and gratuitous compatibility backwardness to the already difficult task of developing software, without contributing anything to the bottom line of building a working system. None of these people will understand the big picture, the social issues of development, the burden their decisions impose upon others, the cost of their folly to the group, and least of all the possibility to automate away all the rigid and stupid rules that constitute the cherished meat of their own petty bureaucratic job.

In the end, the fields of programming languages and databases contain complementary lessons. Software engineers should learn from both. And more importantly, they should expand their views to the dynamics of the whole system rather than a small static aspect of it. That, and avoid bureaucrats.

Next Boston Lisp Meeting: Tuesday April 22nd 2008, 6pm at MIT 34-401B

Thu, 03 Apr 2008 00:09:32 GMT

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

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

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

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

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

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

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

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

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

Jackson's Mary

Fri, 28 Mar 2008 18:48:10 GMT

At a recent talk at BU about Consciousness, Steven Horst, a professor of philosophy at Wesleyan advanced an apparently well-known argument by Frank Jackson. The argument uses the thought experiment of a woman named Mary, kept in a controlled environment of black, white and grey, and at the same time made to know everything that the most advanced future (omni)science of the physical world can possibly tell her about the brain. Now, argues Frank, when she is made to see something red at last, she learns something new that could not be contained in such knowledge. And thus, concludes Horst with Frank, there is something beyond the physical world that is necessary for this experience to happen.

Of course this vulgar mystical argument is based on a typical confusion between object and representation -- the ultimate source of insanity according to Korzybski.

If Mary does have only a theoretical knowledge of her own brain, any information she has is about a model of her brain, a representation disconnected from knowledge of herself; making her see something red is then a new experience indeed, by which Mary may relate her representation (of her brain) to the object. On the other hand, if Mary's scientific source of knowledge really allows her to know everything about the physical state of her own brain, then amongst that "everything" is the ability to inspect the effect of observing the effect of actually firing her own red neurons. In other words, the interactive knowledge of her own physical state indeed includes her being able to simulate and register the effect of seeing red by manipulating her own brain. The absurdity of the situation is entirely due to Frank and Horst using a fallacious semantic shift between knowledge of the object and knowledge of a disconnected representation in the everything that Mary knows or doesn't know. No argument for or against physicality is actually present in this fallacy.

In fact, when we go to the bottom of the argument, we find not an indictment of the scientific experimental method, but a glorious vindication of it. Indeed, experiencing is something essential that goes beyond abstract knowledge: it is only by experimenting with physical phenomena that we can tie any non-tautological theoretical proposition to reality. Theoretical knowledge is not knowledge before it is somehow made to map actual physical interactions with the world. Certainly, theory, deductive logic, praxeology, induction, are necessary tools to allow for any kind of understanding of facts that would otherwise be but meaningless sound and fury. But only interaction with reality may allow to distinguish which amongst consistent theories are to prevail and which are to be rejected.

In the end, Horst is correct of course in his further claim that physicalism isn't an experimental scientific statement: it is an epistemological statement. But it isn't a matter of faith or revelation like mystics would have it, it is a provable epistemological truth. If we can know a phenomenon through interactions with the physical world, then it's physical indeed, and not supernatural. And if we can't, then any claim that it exists and that we know of it are preposterous. It is precisely the experimental method that may allow us to tie representation to the world: can you or can you not interact with the phenomenon and thus experimentally establish any reproducibly predictable regularity about it? If yes, then it is anything but supernatural, it is the valid subject of scientific knowledge. Show us the reproducible experiment, and we'll include this regularity amongst the known physical laws of nature. If you can't, then how can you speak of a phenomenon to begin with?

The utterly unspeakable is utterly irrelevant. And whatever speakable claim there is that mystics make of phenomena that would exist beyond knowable nature and may override or contradict the laws of nature, is actually the claim that random assertions by them must be accepted despite the lack of supporting evidence and the availability of contradicting evidence. These are but lazy and dishonest claims by which some pseudo intellectuals draped in pompous academic or religious titles try to smuggle unjustified and unjustifiable claims without having to pass any elementary test of validity. Rejecting such claims is not even a question of reason and science. It's a matter of basic intellectual honesty.

Erlang-in-Lisp project proposal

Thu, 20 Mar 2008 03:15:53 GMT

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

Erlang-in-Lisp

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

The previous attempts failed to produce a complete workable solution:

cl-muproc - full erlang-style programming, not stable on all platforms, intraprocess threads only
gbbopen - distributed blackboard (linda-style?) rather than erlang-style, works stably on many platforms (requires threads)
philip-jose - server spawning clients via ssh, server has transactional threads via green continuations (could notionally have one server per system thread).
NetCLOS - implements actors on top of CLOS, allegro 5 only
ABCL/R - implements actors, applicability to issue at stake unknown.
ParGCL - GCL only, uses MPI that allows for fancy message passing in a restricted managed context.
Erlisp - stalled in early stage.

And then of course, you can find inspiration in Termite, Dreme, Kali, Tube, things by Queinnec & co, etc. (see the readscheme bibliography on Distributed, Parallel, and Concurrent Programming.

As far as I know, all these systems assume a trusted network and are otherwise insecure. A better system would route messages via SSL. Nah. A better system would allow to plug in new methods for exchanging messages onto the IOlib event loop. Thus project would thus be:

develop a few low-level message-passing handlers on top of the IOlib event loop; to be supported:
- a simple protocol on top of an arbitrary stream (TCP socket, unix pipe, SSL).
- unix sockets, with their fd-passing goodness
- a protocol on top of HTTP/HTTPS requests
- a protocol on top of UDP (with or without a layer for managing timeouts or message acknowledgment)
if needed, generalize an API to plug-in message handlers on top the IOlib event loop
on top of low-level message-passing and/or mixed in with it, implement
- some trivial protocol for messaging for testing (take or adapt it from philip-jose)
- some easy text protocol that precisely and safely implements Erlang semantics
- possibly a compatible implementation of the Erlang wire protocol
develop robust fork-based concurrency
- fork and manage children the right way, don't try broken SIGCHLD handling, use waitpid
- implement a portable run-program with every feature a shell spawner may have, from fd redirection to setsid - use it to spawn local and remote processes
- implement a protocol for talking to children using point-to-point unix sockets.
develop protocols for routing messages between processes
- handle broken connections and (in the abstract case) reopening connection
- handle brokers, directories, name service (to support the abstract case)
manage processes
- know how to probe a process status, kill a process (see philip-jose)
- learn about load-balancing, process niceness, processor affinity, etc.
support multiple concurrency models
- adapt cl-muproc to allow for Erlanging using native threads concurrency.
- adapt philip-jose to allow for Erlanging using green threads.
- in either case, take special care for proper handling of asynchronous interrupts, as they actually require clever synchronization under the hood.
Actually implement Erlang on top of this Lisp system
- implement enough of the Erlang semantics to run simple examples
- implement a parser front end for Erlang syntax
- implement enough of Erlang syntax semantics and basic libraries to run standard libraries, test suites and benchmarks
- make sure we can interoperate with existing Erlang implementations
Support additional programming styles on top of the previous framework
- implement mobility in the style of the Tube
- port some variant of NetCLOS or ABCL/R2

There's more than enough work for two interns, maybe three. Some of the tasks can be started in parallel, others depend on previous tasks, so three is a stretch and more is probably too much. One intern could focus on the messaging protocol while the other one would focus on the concurrency. Mr Concurrency would start with fork, run-program, and if the other one is late or fails to deliver, would continue implementing a CLSH variant on the SCSH pattern. Mr Messaging would implement various messaging and if the other one is late or fails to deliver, would continue implementing various protocols to interoperate with existing software. A hypothetical third intern would start from the other end, parsing Erlang, transforming it into forms runnable in Termite or some such project, identifying what primitives are needed, maybe trying to build a bridge between C modules for Erlang and Lisp, possibly working on interfacing with Erlang internals. Hopefully, all interns would deliver in a timely fashion and cooperate towards a full-fledged Erlang-in-Lisp implementation.

Obviously there isn't enough time to implement and fully debug everything in the list above; depending on the intern's preferences, more time could be spent perfecting some of the previous features, or they could be left done just well-enough to go on the next features.

Yes, I would eagerly mentor such a project. Actually, I may even fund such a project if there are more good applicants found than are accepted by Google.

Next Boston Lisp Meeting: Monday March 31st 2008, 6pm at MIT 34-401B

Mon, 17 Mar 2008 05:38:34 GMT

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

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

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

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

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

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

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

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

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

Monthly Boston Lisp Meeting - Call for Speakers, Participants and Sponsors

Sat, 16 Feb 2008 00:28:52 GMT

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

I will be organizing a monthly Boston Lisp Meeting.

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

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

The regular format of these meetings would be a one hour conference followed or preceded by free-for-all discussions around drinks and food.

Conference meetings would include one or two speakers, on a strictly timed schedule, typically one 50' presentation + 10' Q&A, or two 25' presentations + 5' Q&A each. Additional slots of 3' flash presentation + 2' Q&A would be available for project updates, demos or calls to the public. We may give more time to exceptional speakers, especially those who come from afar.

We encourage both veterans and newbies to come and meet, maybe becoming collaborators, mentors or disciples on some Lisp project, whether as a hobby, as an academic endeavor, as a paid job, or as a startup. Lisp users and gurus are invited to socialize and chill out with a group of fellow-minded other lispers.

I am seeking corporate or academic sponsors to host the event, offer drinks, offer food, cover travel expenses for remote speakers, keep up a website, fund free software community projects. I have a few leads but no definite answer yet. The event will take place with or without such sponsorship.

I am also open to suggestions for improvements about these meetings: different timing, food before the conference, etc. Also, I'll adapt the meetings to the availability of interesting speakers. If we are short in speakers, we may include such a conference only bimonthly or quarterly, and skip directly to the drinks and food the rest of the time. If we are overwhelmed with great speakers, we may have conferences more often.

The mailing-list boston-lisp from common-lisp.net will be revived as the place to discuss these events. You can subscribe at http://common-lisp.net/mailman/listinfo/boston-lisp

The mailing-list boston-lisp-announce maintained by Neil Van Dyke will carry announcements but without lengthy discussions. You can subscribe at http://www.neilvandyke.org/boston-lisp-announce/

To contact the organizers, use the mailing-list boston-lisp-organizers at common-lisp.net.

The next meeting will be on Monday, March 3rd 2008. We'll meet at 1800 at the CBC ( http://www.cambrew.com/ ). No conference is scheduled at this time, only a meeting for Lispers to have fun and for potential conference organizers to prepare the future meetings in April and beyond.

The first meeting with a conference will be on Monday March 31st 2008.

Topics to be discussed include but are not limited to:

Programming languages: How to use, implement or combine programming language features such as metaprogramming, macros, modules, non-determinism, security, concurrency, reversibility, persistence, resource management, competing strategies, etc.
Domain-specific languages: interesting ones, how to implement and combine them.
Program synthesis: overcome issues in software engineering by providing adequate programming semantics, aka "Paradigms".
Program analysis: types, proofs, tests, abstract interpretation, using formal semantics or clever statistics, etc.
Declarative Programming: How to concisely express abstract programs, view data as programs, distribute semantics, etc.
Implementation: code generation conventions, garbage collection, debugger hooks, concurrency control, interfaces with alien environments, etc.
Systems Evolution: How programming languages and systems evolve, and Lisp systems in particular.
Lisp Communities: How Lispers can better help each other.

Whether you are an academic, an industrial programmer, a student or a hobbyist, you are invited to join us at these meetings.

If you have something interesting to say or know someone else who has, please suggest a potential talk by sending mail to boston-lisp-organizers at common-lisp.net.

I am also looking for co-organizers to make sure these meetings will be of better quality than I could achieve on my own, and will survive my eventual temporary or permanent unavailability or disinterest. A Lisp web developer to maintain a site would be a good organizing team member, too.

Finally, I request the intended audience to send me feedback so as to know what best date and time to pick, how big a room to reserve, and how much food and/or drink to beg sponsorship for. For the latter reason, I may even require (free) registration of participants so as to make sure to not order too much or too little.

Paris again!

Sun, 03 Feb 2008 15:59:47 GMT

I came to Paris for a Surprise Party celebrating my father's 70th birthday. It was a tremendous success. I'm leaving next saturday morning. If you are around, I hope to meet you before then!

Je suis venu à Paris pour une Sauterie Surprise en l'honneur des 70 ans de mon père. Et quelle surprise ce fut! Je repars le matin de samedi prochain 9 février. Si vous êtes dans les environs, j'espère vous revoir d'ici là!

Creationist programming vs Evolutionary programming, part V

Thu, 03 Jan 2008 14:25:58 GMT

Happy new year to you, faithful readers! 2008 brings the continuation of my series, Creationist programming vs Evolutionary programming, of which this is the fifth installment. Previous installments: Part I (Creationist programming, The Devil), Part II (Intelligent Design, Polytheism), Part III (Unintelligent Design, Lamarckism), Part IV (Supernatural Selection, Teleological Evolution).

Natural Selection

As far as paradigms for understanding software development go, the notion of evolution under godly guidance was an improvement over that of direct design by purposeful gods, which was itself an improvement over the notion of immediate creation. But in each case, this was only pushing back one level the assumption of a driving intent external to the world. Real evolutionary theory does away with this assumption. Survival of the fittest does not suppose an external criterion of fitness to which living creatures are submitted; rather, survival itself is the only criterion, tautological and merciless. Survival is its own purpose: those programs that survive, survive; those that don't, don't. Changes that improve the odds that their host software should survive and propagate, thus statistically tend to propagate themselves and colonize their respective niches. Changes that decrease the odds that their host software should survive and propagate, thus statistically fail to propagate themselves and eventually disappear. The cumulative result of this natural selection is an evolutionary process that favors bundles of traits that tend towards their own reproduction. This freewheeling evolution necessitates no godly intervention, neither by an intelligent conscience, nor by madmen. More remarkably, programmers are no gods above it, and their actions are no such interventions. They are but machines like others, bundles of self-reproducing traits competing to exploit the resources of the universe. As compared to other machines in this programming universe, certainly programmers are unique and different -- we're all unique and different; that doesn't exempt them from the laws of natural selection. Programmers are machines trying to survive in a wild machine-eats-machine world; their actions are their attempts to survive and reproduce by gaining an edge in the race for ever more efficient acquisition and use of reproductive resources. If God exists, then ever since He created the world, He has just been relaxing, sitting back and enjoying the show. Evolution is not guided by God, it is God's Spectator Sport. Such is the paradigm of Natural Selection.

With this new understanding of the world of software development emerge new tools to improve our development processes. We think in terms of self-sustaining systems, evolving and competing based on their ability to survive and spread. We understand that the hosts and actors of this memetic competition are humans as well as machines, or even more so. We may then notice that systems are never born big, and that the only big systems that work are those that were born small and evolved and grew in a way that they were kept working at every step. We explain the spread of ideas in terms of generations of humans and machines passing on their forking and mingling traditions. We understand that pieces of hardware, software and wetware survive as part of ecosystems, with cycles of development and use by various humans, where economic and legal aspects have their importance as well as technical and managerial aspects. We realize that these systems compete on a market ultimately driven by economic costs, of which technical aspects are but a small part, sometimes not decisive, though they are what the technicians obsess about.

Because the forces opposing creation are no devil but malicious humans indeed, we use of computer cryptography and cultivate networks of human trust to achieve security. A Third Wave of Cybernetics attempts to re-create artificial life and life-like phenomena through the emergence of behaviour from many software agents.

Natural Selection provides a big picture that puts haughty programmers down from their godly pedestal and back into the muddy real world. It doesn't offer direct solutions to design problems so much as it dispels our illusions about fake solutions and unearned authorities. No one is a god, above the others, to predict what will work and dictate what to do; our experts' dreams are often but vain obsessions, whereas some rare amateurs' successful experiment may start a revolution. Life is the ultimate judge -- accept no substitute, and respect its sanction.

Inside Evolution

Natural Selection may appear to look down on the world as a soulless marketplace. It will only appear soulless if you imagine yourself in the seat of that laissez-faire God above the world. But face it, you're no god, you're not outside the world and above it. There may be a god, who may or may not be intervening in this World, but you have to come to the realization that He's definitely not you. You're one of us earthworms, trying to make the best out of what you have (or not trying, and thus probably failing and promptly disappearing into irrelevance). Evolution is not something for you to enjoy watching, it is something you are part of, willy nilly. You can't just let nature decide, you're part of the nature that will decide. Whichever genes and memes you carry may or may not survive -- it is largely up through your actions that they will succeed or fail. You're in the experimental set of changes that may or may not work out well, or you're in the control set of the obsolete that will surely be replaced. Such is the view from Inside Evolution.

The tools that matter are those that are available to you. Your resources are limited, and you should invest them wisely. Which tools will make you most productive personally? Opportunities are there to be seized; if not by you now, by someone else later. On the other hand, it may be too soon to invest in some ideas, and too late to invest in others; timing is key. Specialization will help, and can be a long-term investment that provides compound interests. As for cooperation with other non-gods, you can only go so far with your own efforts, and success lies in being able to leverage the efforts of other people. Which tools allow you to reuse as much as possible of these people's efforts? Tools can be technical, or can be social. Not just software libraries, but software communities, software market niches, software business contracts. Of course, you always need some kind of exclusive resource to ensure a revenue stream; free software or not, your combined proficiency, trustworthiness and time are ultimately the only such resource you have, and ample enough to live well if you can market it, though it will probably not make you super rich. On the devil side, intellectual frauds will try to have you adopt their bad ideas, and other scammers will try to divert your resources in their favor; you must learn to avoid them.

As you fully grasp the fact that all actors are individuals, not just yourself, and you take into account incentive structures. Incentive structures will put you and your associates in a position to productively cooperate at your full potential, or to work at a fraction of it; so carefully watch both your legal and business arrangements. You may see that proprietary software destroys incentive from anyone who doesn't fully trust the software owner, and that trust can last but until the eventual catastrophe inevitable in any centralized management; any proprietary software has a suspended death sentence. On the contrary, you may see that free software creates an insurance against disagreement with associates, and ensures pereniality of software investment. With a systematic view of incentives, you stress the importance of contracts and accountability as a way to structure human interaction, re-uniting liberty of means and responsibility for results in complex software arrangements. For instance service-level agreements will allow to robustly build larger, more complex structures than direct command chains. You may recognize the value of free markets as a way to organize people and to evaluate ideas, rewarding those able to invest their resources in the good ones rather than the bad ones. You may celebrate startup companies as light innovation structures with highly motivated personel.

The Inside view to Evolution restores the soul in the market place for software. This soul is yours. You're the entrepreneur of your own life.

TO BE CONTINUED...

Creationist programming vs Evolutionary programming, part IV

Sat, 15 Dec 2007 16:29:46 GMT

Here is the fourth installment in this series for my essay Creationist programming vs Evolutionary programming. Previous installments: Part I (Creationist programming, The Devil), Part II (Intelligent Design, Polytheism), Part III (Unintelligent Design, Lamarckism).

Supernatural Selection

Though Unintelligent Design helps further the field of software engineering, one may realize that while small parts of software are understood, software at large is not understood, much less designed. Lamarckism, by shifting the spotlight to the change process, leads to asking why and how programmers lacking complete understanding choose to keep or change some or some other parts of the software. The immediate answer is that as god programmers write, they stumble upon good or bad features that they winnow by propagating the good and by eliminating the bad. The software writing process is thus some kind of artificial selection, under the careful, intelligent guidance of the programmer God. The programmer God impresses upon the process a definite direction, Progress, and otherwise lets software evolve organically in this divine order. This software paradigm is Supernatural Selection.

Under this paradigm, new tools are selected into prominence. Prototyping tools help the programmer God flesh out as many ideas as possible as quickly as possible, so he may select the correct ones. Formal specifications help define what software should be doing, without worry about how it will be doing it. Heuristic search algorithms use intelligently designed strategies to systematically explore spaces of potential solutions too large to be explored by the programmer themselves. The combination of these two approaches leads to declarative programming, where the programmer God focuses on the intent, and delegates the implementation to the machine. From one phase to the next, programs are transformed through systematic metaprograms. To prevent the devil from corrupting software, formal proofs are developed that perfectly exclude undesired behaviour. To coordinate multiple programming gods, software modules separate interface from implementation, allowing for experimentation and adaptation separately in each part; rational developer communities are created, conferences are given, journals are published.

This whole approach has also been called the First Wave of Cybernetics, combining an understanding of the natural dynamics of software with a faith in the ultimate power of an intelligent and purposeful programmer god, culminating with expert systems using explicit knowledge representation in an attempt to solve complex real-world problems.

Teleological Evolution

The paradigm of Supernatural Selection obviously suffers from the same shortcoming as did the theory of Intelligent Design before it, in that it supposes that the programmer God (or at least some of them) are supremely intelligent. The only reason this shortcoming was not immediately grasped is because these successive paradigms were adopted without ever being articulated as clear theories. Now, an immediate improvement over the previous paradigm is to stop believing that the programmer Gods are intelligent. Gods may guide the evolution of software, but their contribution to the process is hardly an overall intelligent coherent purpose; rather it is through a number of interventions based on partial knowledge, intuition, randomness, towards a progress that can be felt but not defined. Such is the theory of Teleological Evolution.

With the transition from intelligent guidance to unintelligent guidance, we are lead to the appearance of new tools, that roughly correspond to the Second Wave of Cybernetics. Genetic Algorithms, connectionist neural networks, probabilistically approximately correct learning methods allow to mine information from large databases without any explicitly designed representation of knowledge. Weakly structured computations allow to manipulate data despite limited understanding. At a smaller scale, programmers are satisfied with randomized algorithms that have good enough performance in practice despite having dreadful worst case guarantees. To protect from the devil, checksums and probabilistic proofs can be more useful than unattainable formal proofs. To synchronize multiple gods, user communities come to prominence, as users, though the least proficient, are those who possess the best distributed knowledge of what makes the software useful or not.

The paradigm of Teleological Evolution loosens the strictures of Design or Supernatural Selection, and opens the space for practical software solutions to problems beyond the full grasp of the programmers. While it reckons the importance of reasonable endeavor, this importance is de-emphasized; indeed, even reason can be seen as but a fast-track internal process of random production and selection inside the programmer's mind, as guided by his godly intuition. In the end, Teleological Evolution embraces an unfathomable mystical intuition as the ultimate divine source of creation.

TO BE CONTINUED...

Creationist programming vs Evolutionary programming, part III

Fri, 14 Dec 2007 02:52:59 GMT

Third installment in this series, here is Part III of my essay Creationist programming vs Evolutionary programming. Previous installments: Part I (Creationist programming, The Devil), Part II (Intelligent Design, Polytheism).

Unintelligent Design

Intelligent Design was once a great progress in how to approach software creation, but sooner or later, you must realize that it doesn't describe reality accurately. The design of most software is just really bad; the issue isn't that errors creep in that corrupt a perfect understanding, it is that the understanding was far from perfect to begin with. We must recognize that all too often, the programmer God is just plain stupid. And so, the next stepping stone on the way to better programming paradigms is: Unintelligent design.

God may have an intent, but he's a blind idiot who doesn't know exactly what it is he wants or how to achieve it. He not only makes gross mistakes, he writes plainly erroneous code that can't possibly work. Tools to help him design programs will thus include helpful messages from his compilers for error diagnostic and recovery: their role isn't to tell an intelligent programmer the devil crept in while you weren't looking, just have a look, you can obviously see him and chase him, it is to tell the unintelligent programmer what you did was stupid, here is the explanation why, for it would be hard for his limited intellect to figure it out all by himself. Syntax checking, type checking and various kinds of advanced semantic checking are invented to catch the more or less obvious errors and converge more quickly towards what the programmer would mean if only he were capable of forming coherent intent. Interactive help, manuals and hints constantly remind the programmer God of the things about which he should know better. Integrated development environments help God play with the code and get faster answers as to whether or not his ideas make sense. All the software interfaces are made idiot-proof by making languages more abstract and completing them with ample compile-time and run-time checking. Tools do most of the work and clever interfaces try to present things so that complexity is managed away for the stupid user, and all decisions may be done based on a shallow limited view of the world, the only kind that fits the programmer God's tiny brain. There is no shortage of imaginable tools and prosthetic devices to help the programmer God cope with his mental disabilities; and these tools are themselves limited mainly by the inability of their own godly program designers.

When a devil adds machine malfunction to operator dysfunction, testing becomes something to take seriously and systematically. When multiple gods are involved, the many resulting processes running at the same time must be protected from each other; the many parts of the software are tested separately, and contracts for what happens at their interface are attemptedly defined and enforced. Because the programmer gods cannot be trusted to remember all the issues with the software, some software must be used to systematically track those bugs and issues. When some of the programming gods are malicious, you're glad they are idiots, too, and you bury them under the weight and complexity of security features that will catch each of the more obvious malicious types of behaviour.

Lamarckism

Whether software is designed by intelligent or stupid gods, or something else altogether, we importantly may understand that software changes to adapt to new circumstances, and focus on the nature of this change. That's Software Lamarckism.

Filesystems may remember many versions of the files they hold, each with a different version number. Software releases are numbered too. Because many gods may be working at a time, a piece of software may exist along many different development branches. To understand the differences introduced, whether they were intelligent, stupid or malicious and what to do of them, tools computing differences between files are created. To merge the intelligent changes and the fixes to the stupid and malicious ones along the many different branches, tools are created to apply computed differences to branched files. Revision control and change management is born, and continuous backup remembers all previous versions of tracked files.

Lamarckism is not a complete theory of why and how change happens, but it introduces a useful focus on change. It is thus the starting point for more elaborate theories that will explain the development of software in the terms of this incremental process of change.

TO BE CONTINUED...

Creationist programming vs Evolutionary programming, part II

Thu, 13 Dec 2007 02:51:10 GMT

Second installment in this series, here is Part II of my essay Creationist programming vs Evolutionary programming. Previous installment: Part I (Creationist programming, The Devil).

Intelligent Design

Even with the Devil variant, the pure Creationist approach to programming soon proves insufficient to explain how Software comes into existence, and why programming is such a difficult activity. As projects grow bigger, it becomes obvious that a whole software system cannot be completed in one go. The sheer volume of it makes it impractical. But it is possible to create the software in many steps, starting from foundations and building layers upon layers, bootstrapping complex structures from simpler ones, shaping tools and tool-making infrastructures, replacing parts with better ones as the need and opportunity arises, building scaffolding that may get destroyed later possibly leaving fossils along the way, all according to a carefully designed master plan. This programming paradigm has a name: Intelligent Design.

Intelligent Design is a most common paradigm amongst software professionals and amateurs, whether in the industry or in academia, if only because it flatters them. Programmers realize that software problems are big, complex beasts, but have faith in their godly brainiac powers to tame those beasts through the reasonable, intelligent, systematic endeavour of well-trained specialists creating well-designed programs.

Within this paradigm are created and elaborated such tools and concepts as assemblers, formula translators, source code, operating systems, compilers, compiler-compilers, compilation management utilities, etc. Top down design, flow charts, modelling tools, hierarchically layered systems, the waterfall design process, and all kind of neat engineering practices follow from this paradigm.

Now of course, this paradigm has a devil variant: Intelligent Design with a Devil. Based on this enhanced paradigm, according tools are engineered into existence to counter the devil's work: editors to modify programs and remove bugs (based e.g. on line numbers), loggers, tracers and single-steppers to help locate bugs. Some small amount of reviewing and testing is added to the design process.

Polytheism

Another useful mixin for software engineering paradigms is the polytheism mixin. According to this partial theory, there isn't one God, with one Master Intent and consequent actions, but a lot of gods, each with his own intent and actions. It may be that many programmers are each a god partaking in some part of designing the Software; it may be that some God takes multiple roles to address the multi-faceted endeavour of Software design; it may be that God's intent changes with time, that God is moody and has tantrums.

God's ways are impenetrable, but enhanced theories of what God is lead to the design of new tools. To address the multiple programming gods, files are invented; as gods get organized in hierarchies, so are files organized in directories. Machines are time-shared, operating systems grow to manage multiple users, and eventually multiple users at the same time, each running multiple processes. Communication protocols are developed to exchange data between machines. Source code comments and formal documentation serve to convey intent and content between programming gods.

The devil mixin can also be combined with the polytheism mixin. The devil may have multiple aspects that each have to be addressed separately. The apparent or actual polytheism could be explained as a one God's multiple personality disorder, and the devil as a symptom of His schizophrenia. The devil may be a God himself -- a malicious programmer. Any of these explanations for errors in God's Design can lead to new techniques to address the identified sources of error. User accounts are protected by passwords; files and other resources have usage restrictions, and will be backed up; redundancy checks are added to communication; errata complete documentation, and pages are intentionally left blank to prepare for them.

TO BE CONTINUED...

Creationist programming vs Evolutionary programming, part I

Wed, 12 Dec 2007 08:26:50 GMT

I'm writing an essay Creationist programming vs Evolutionary programming, based on a speech given at ENS in october 2005, and redacted, extended and polished under the purview of the loveliest of lovelies, my wonderful and everinsightful Lucía. In the hope of pushing myself to finish it, quick, I'll be publishing it in a series, of which this is the first installment.

I was once asked to summarize the main TUNES concept in a few words. My reply was that the central idea behind TUNES is the evolutionary paradigm for programming. What is this evolutionary paradigm? The opposite of the creationist paradigm. (Duh!) Now, what is...? Wait, let's examine paradigms for the appearance of software on earth: start from the initial naive paradigm of software creationism, and watch how it has evolved since.

Creationist programming

At first there was nothing; then, God zapped code into the computer, and Software came into existence.

The belief in this simple story is Software Creationism. The programmer is a God outside and above the machine; the program is his creation, implemented in the machine. The programmer God is perfect, and has a perfect program in mind; the actual program may not be perfect, but that's because it's a rendition of His platonic idea on an imperfect Machine. Though its form might be limited by the limits of the finite physical computer, the program is the expression of a perfect intent.

Software Creationism is not only the naive belief that non-programmers naturally form when confronted with the apparition of software, it is also the programming paradigm taught to students at most schools: in exercises and in tests students are expected to produce from scratch and on paper a perfect solution to a perfect specification; in assignments and projects, they otherwise have to write standalone pieces of code to be run and evaluated once by the teacher, software that should not rely on any code by anyone else or contribute to such, except through the documented interface provided by the system.

No programming tools are necessary in this paradigm; just a switchboard to insert the program into the machine. Who needs tools when you're a perfect god directly playing with memory at the binary level (or base ten, if that's your kind of machine). Programming the machine is best done in binary, directly from God to Machine, although it can be done in a whichever write-only language suits the expression of God's will.

The Devil

The story of software creation by a superior God is beautiful; however, anyone who has ever tried to program soon realizes that he can seldom get his programs to run perfectly at the first try, or even the second. Bad things happen: Bugs, typing mistakes, mismanipulations, cosmic rays, hardware malfunctions, errors in the program, etc. Happily, the simplest explanation suffices to account for it: The Devil.

There is a devil that modifies things in a way that counters God's intent. Whether this Devil is a personality defect within God, an opposing force outside God, or an artefact of the laws of Nature that God created is unclear and might really not matter. What is clear and matters is that the bad things that happen are the symptoms of the presence of dark forces of Evil. This Devil introduces imperfections in the way the machine works, and causes it to fail to perfectly receive the perfect message from the perfect God and thus to fail to embody His perfect platonic idea.

To keep this devil under control, appropriate tools pop into existence: punched cards or display consoles are used that can be read by the programmer God as well as written. Thus programs can be double checked, fixed, retried, stored, despite the attempts by the devil to make them fail. Programs must be read as well as written, decoded as well as coded, and thus come into existence all kinds of languages to express computation. Many software development practices are invented, to be followed religiously.

From a better (or less bad) paradigm for programming, we thus get better (or less bad) tools that allow us to improve software engineering and cope with the difficulties of the endeavour. This will continue to be true as we improve our software engineering paradigms.

Interestingly, anytime we find a new and hopefully better such paradigm, we will always be able consider a variant of it where some dark forces conspire to undo or corrupt what the creative forces strive to achieve. Thus, the idea of such opposing forces is a universal mixin for software engineering paradigms, the devil mixin.

TO BE CONTINUED...

Il n'y a rien à attendre de Sarkozy ou de la politique

Wed, 12 Dec 2007 07:56:14 GMT

Excellent politique, administrateur exécrable. En tant qu'homme politique, notre président est hors pair. Et c'est exactement pourquoi en tant qu'administrateur, il prolongera et accentuera l'oppression pesant sur les créateurs et la ruine du pays.

Sarkozy est un excellent homme politique. Il sait placer ses amis et ses ennemis, créer de la popularité, du consensus, former des alliances, concilier des opposants, récompenser ceux qui lui apportent un soutien, punir ceux qui le lui ont refusé. Il maîtrise la politique, cet art du possible. Du politiquement possible, s'entend...

C'est-à-dire qu'il maîtrise l'art de tisser des coalitions qui vaincront toute tentative de coalition opposée, dans leur emprise sur le pays, et pourront ainsi vivre sur le dos du contribuable. Et c'est pourquoi ceux qui attendent de Sarkozy ou de tout autre remplaçant qu'il atténue leurs souffrances se mettent le doigt dans l'oeil. Le but et le moyen de toute coalition au pouvoir, c'est d'obtenir une part plus grande de la tonte des politiquement opprimés. Ni Sarkozy ni personne ne peut changer ce principe. Et si Sarkozy ou tout autre libérateur rêvé allait contre ce principe, il serait par définition incapable de créer une coalition victorieuse, de se faire élire et réélire, de réunir les soutiens nécessaires à l'action, de gouverner -- il chercherait vainement à trouver un art de l'impossible.

Peu importe à un bon politique ce qui est bon pour le pays: raisonner, trouver des explications à ce qui va ou ne va pas, proposer des solutions qui marcheront, pour un politicien, c'est de l'idéologie, tout juste bon à créer de la propagande. La bonne idéologie, pour un politicien, c'est celle qui crée de la propagande qui marche pour lui, c'est-à-dire celle qui l'aide à étendre son pouvoir: celle qui convainc facilement des masses d'ignares, celle que l'on peut propager efficacement par l'éducation nationale et les mass-médias. Vrai ou faux ne sont pas des catégories qui intéresse le politicien. Puissant ou impuissant, source de pouvoir ou d'opposition, voilà ce qui l'intéresse. Le politicien n'est pas là pour créer de l'adéquation entre vrai et puissant, il est là pour exploiter les sources de pouvoir existantes, et intensifier celles sur lesquelles son pouvoir repose.

Or, tout pouvoir repose d'abord et avant tout sur l'oppression écrasant les créateurs payeurs d'impôts, par la force et la tromperie, au profit d'une classe de parasites receveurs d'impôts. Une armée de bureaucrates officiels maintient le pouvoir officiel, prélevant et répartissant l'impôt, opprimant les citoyens sous des réglements abrutissants, punissant ceux qui veulent échapper à l'extorsion et l'oppression. Une autre armée de commissaires politiques officieux (fausses associations grassement subventionnées, journalistes privilégiés, enseignants nationalisés) cultive les sources du pouvoir en propageant les idéologies victorieuses; une troisième armée, de socialement proches (criminels) actifs, crée la pression ordinaire contre les citoyens opprimés, et les jette dans les rets du seul secours qui leur est autorisé, le Pouvoir politique (toute tentative de créer une alternative à son monopole étant plus sévèrement réprimée qu'aucun crime). Enfin, une dernière armée, faite de petits privilégiés oisifs (syndicalistes, chomeurs, étudiants en rien, etc.) fera des coups de mains illégaux mais jamais sanctionnés contre tout opprimé qui voudrait se révolter: démonstrations de force, grèves, occupations, blocages, sabotages, vandalisme. Les travailleurs productifs, les créateurs de richesse, sont opprimés. Les parasites improductifs, les destructeurs de richesse, sont privilégiés. Par la tromperie idéologique, les rôles d'opprimés et privilégiés sont confondus voire inversés dans l'esprit de la majorité, et le pouvoir se perpétue. Le pouvoir est le contraire de la liberté, la politique s'oppose à l'économie. Il n'y a rien à attendre d'un bon homme politique, et aucun espoir de voir au pouvoir un mauvais homme politique.

Si vous voulez un espoir de vaincre la politique, il est bien mince. Les rares antidotes à l'idéologie du pouvoir, le socialisme, ne fonctionnent que sur une minorité infime de dynapenseurs; la pensée dynamique semble limitée par l'éducation et la génétique, toutes deux sous contrôle, direct ou indirect, de la politique; en important massivement des bas-QI statipenseurs, et en propageant systématiquement la pensée statique via l'éducation nationale et la presse privilégiée, le système politique en place assure la pérennité de son assise idéologique. D'aucuns rêvent qu'un jour l'ingénierie génétique ou mémétique permettrait un jour de généraliser de tels remèdes, en créant des générations de gens plus intelligents et/ou d'antidotes plus convaincants à la propagande politique. C'est oublier que l'État a accès plus que quiconque à ces technologies, et a les moyens et la motivation pour contrôler et la génétique (via réglementations et subventions) et la mémétique (via propagande et censure). Dans cette bataille improbable, l'État reste favori, et de loin. Seule la concurrence entre États permettrait peut-être la propagation lente de tels progrès génétiques et mémétiques. Et encore.

Reste l'espoir d'échapper personnellement au pouvoir politique. Il existe des espaces de libertés, des zones autonomes temporelles, des vides juridiques, qui n'ont pas encore été envahis et mis en coupe réglée par l'État. Ces espaces ne sont par définition qu'un refuge temporaire, et toute documentation excessivement complète et/ou publique de ces espaces ne ferait qu'accélérer leur invasion par l'État -- toute source de subversion efficace du pouvoir politique identifiée dans une telle zone hâte aussi l'annexation par l'État. Aussi devrez-vous chercher et tâtonner dans l'ignorance pour trouver un tel espace, et abandonner l'espoir qu'un tel espace puisse permettre de vaincre le Minotaure.

L'État est là pour rester, et il n'est pas votre ami. L'un dans l'autre, votre sort à ce titre n'est pas plus mauvais que celui de vos ancêtres opprimés par des maîtres plus stupides et cruels. Comprenez cette réalité, acceptez-la, et agissez en conséquence.

Party! 2007-12-08_T1800 @ Cambridge, MA

Tue, 04 Dec 2007 06:10:35 GMT

Dear friends,

if you are reading my blog and are or can be in the Boston area on the evening of next Saturday December 8th 2007, you are cordially invited to join me at my place for a party to celebrate the passing of my 34th birthday (better than J. H. Christ!) and the upcoming Solstice, Saturnalia, Gravmas, etc.

Send me email for details.

I understand that many of you do not live in the Boston area, require earlier notice, have other obligations, etc., and can only be there by spirit or by video conferencing if at all (congrats to Joseph Glanvill (yay for (nested) parentheses))). You'll be missed.

Drinking will proceed starting at 1800, and the last ambulance will leave around 2300 to take the guests defeated by the vietnamese food.

Please do not hesitate to bring friends, mates, family, but tell me if you come and how many of you to expect. If you know common friends who didn't receive a message, they are invited too, it's my mistake to not have their email address.

Taboo topics to be kept undiscussed will include aging, anti-aging, immortality, death, taxes, government, stationary banditry, real estate, property rights, intellectual property, computer software, computers, robots, space conquest, extropy, liberty, rationality, intelligence, superstition, black magic, psychology, seduction, male-female relationships, family, my japanese nephew, learning languages, writing, music, my vaporware projects, Tunes, Lisp, software evolution, AI, Egbert Gebstadter, literature, comic books, french comic books, France, french cuisine, vietnamese cuisine, american cuisine, american lack of cuisine, food in general, food in particular, nothing in particular, and things you'd like to discuss in defiance of this taboo.

Slogan of the Day

Mon, 26 Nov 2007 12:48:21 GMT

When all lawful citizens are disarmed, will we have an omnipresent police state to protect us from armed criminals?

The Magic Power of Words

Mon, 12 Nov 2007 05:12:13 GMT

The True Communist: scandal! In Russia, due to Capitalism, 25% of the riches in the country are now in the hands of 36 families!
Me: Despite the KGB still being in power, what a great progress since the times when a one single man (Stalin) controlled 100% of the riches in the country!
The True Communist: surely you a liberal economist should know the difference between State property and private property?

I guess, as long as it's in the name of the people, it's justified. Well then, whatever I do, be sure that I do it in the name of the people.

Random slogans of the day

Sun, 11 Nov 2007 08:59:33 GMT

Mail addiction is a malediction.

Let's take compulsion out of compassion.

Black Magic has anchors, not beliefs

Fri, 09 Nov 2007 13:16:31 GMT

One of the more stimulating blogs I am following this days is Unqualified Reservations. Its value is more aesthetic than scientific: it is about formulating a new point of view on politics, which the author, Mencius Moldbug, calls neocameralism, against the currently prevailing views that he calls Universalism.

A critic of Moldbug's views contested that Universalism fails to actually denote anything coherent, because there is no well-defined set of beliefs that can be unequivocally associated to said Universalism. But that's missing the point.

Universalism, despite its claims to the contrary, is not a rational philosophy; it is an emotional religion. And so, its basics tenets are not concepts that can be rationally articulated; they are anchors that are emotionally expressed. Liberty, Equality, Fraternity, Democracy, Universal Rights, Peace, Love, Everyone, People, etc. -- all these are the Good Things, but not in any rational concept, always as emotional anchors, as Sacred things beyond discussion.

And so it doesn't matter that the Universalist's vague and evolving concepts of Democracy should be inconsistent, and that Universalists should demonize elected politicians who do not embrace their beliefs openly enough, and admire dictators who spew out the propaganda they like. It doesn't matter that the liberty propounded by Universalists is but a pretext for slavery in the hands of an almighty State (or whoever they claim legitimately represents Society). etc. What matters is that you should feel and speak correctly. Politically correct is not about the content of what you say, it is about adherence to those taboos derived from the Sacred character of the Universalist anchors.

Parti Révolutionnaire Institutionnel

Fri, 09 Nov 2007 11:14:31 GMT

Quand les privilégiés rebelz monopolisent la révolte et l'institutionnalisent, les opprimés sont dépossédés même de la rébellion. Il ne leur reste que le nihilisme -- la haine.