Cybernethics / Cybernéthique

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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...

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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

Erlang-in-Lisp

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

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

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

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

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

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

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

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

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

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

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

I will be organizing a monthly Boston Lisp Meeting.

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

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

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...

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...

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...

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...

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...

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.

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

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.

Mail addiction is a malediction.

Let's take compulsion out of compassion.

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.

Two years ago, I wore a Homer Simpsons mask. I was super popular. People in the streets would call me by my name and come greet me. But it was quite uncomfortable and I had to remove the mask to either have good vision or avoid overheating.

Last year, I wore the mask on a pillow attached to my shoulder and introduced myself as "Homer Beeblebrox". Two thirds of the people looked at me with blank eyes, and one third was rolling on the floor laughing. They had read the books or seen the then recent movie.

This year, I found the greatest costume ever. People were dumbfounded and really thought I was what the person I was impersonating: I dressed with a beret, a sailor's white shirt with horizontal stripes, and a red cloth around the neck, a nice blue jeans and my stars and stripes converse. Everyone thought I was an American dressed up as a Prototypical Frenchman, which was exactly what I was dressed up as: I was dressed up as an American dressed up as a Prototypical Frenchman.