May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Recommended Scripting Papers


  1. Selected quotes
  2. Scripting: Higher Level Programming for the 21st Century --by John K. Ousterhout. Classic paper by designer of TCL.
  3. The Rise of  "Worse is Better'' by Richard P Gabriel
  4. Worse Is Better by Richard P Gabriel
  5. [PDF] Curing Those Uncontrollable Fits of Interaction by Don Libes in Proceedings] (1990) Proceedings of the Summer 1990 USENIX Conference
  6. A. Aho, B. Kernighan, and P. Weinberger. AWK -- A pattern scanning and processing language. Software Practice and Experience, 9(4):267--280, 1979. Also available as text
  7. J. R. Mashey Using a command language as a high-level programming language pdf formatPdf (925 KB) International Conference on Software Engineering  archive Proceedings of the 2nd international conference on Software engineering table of contents San Francisco, California, United States Pages: 169 - 176   1976
  8. Schwartz, Jacob T., "Set Theory as a Language for Program Specification and Programming". Courant Institute of Mathematical Sciences, New York University, 1970. Later book The SETL Programming Language by Dewar and Smosna is available.

Selected Quotes

Scripting languages are higher level than system programming languages, in the sense that a single statement does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions, whereas a typical statement in a system programming language executes about five machine instructions. Part of this difference is because scripting languages use interpreters, which are less efficient than the compiled code for system programming languages. But much of the difference is because the primitive operations in scripting languages have greater functionality. For example, in Perl it is about as easy to invoke a regular expression substitution as it is to invoke an integer addition. In Tcl, a variable can have traces associated with it so that setting the variable causes side effects; for example, a trace might be used to keep the variable's value updated continuously on the screen.

John K. Ousterhout
Scripting: Higher Level Programming for the 21st Century

Most people are surprised when I tell them what language we use in our undergraduate AI programming class.  That's understandable.  We use GAWK.  GAWK, Gnu's version of Aho, Weinberger, and Kernighan's old pattern scanning language isn't even viewed as a programming language by most people.  Like PERL and TCL, most prefer to view it as a "scripting language."  It has no objects; it is not functional; it does no built-in logic programming.  Their surprise turns to puzzlement when I confide that (a) while the students are allowed to use any language they want; (b) with a single exception, the best work consistently results from those working in GAWK.  (footnote:  The exception was a PASCAL programmer who is now an NSF graduate fellow getting a Ph.D. in mathematics at Harvard.) Programmers in C, C++, and LISP haven't even been close (we have not seen work in PROLOG or JAVA).

Why GAWK for AI?
 draft of article by Ronald P. Loui. (1996)

Scripting: Higher Level Programming for the 21st Century

Scripting: Higher Level Programming for the 21st Century by John K. Ousterhout. Classic paper by designer of TCL. Highly recommended

...Scripting languages such as Perl and Tcl represent a very different style of programming than system programming languages such as C or Java. Scripting languages are designed for "gluing" applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.

...Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages. However, several recent trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming languages used primarily for creating components.

...The second difference between assembly language and system programming languages is typing. I use the term "typing" to refer to the degree to which the meaning of information is specified in advance of its use. In a strongly typed language the programmer declares how each piece of information will be used and the language prevents the information from being used in any other way. In a weakly typed language there are no a priori restrictions on how information can be used: the meaning of information is determined solely by the way it is used, not by any initial promises

...Scripting languages such as Perl, Python, Rexx, Tcl, Visual Basic, and the Unix shells represent a very different style of programming than system programming languages. Scripting languages assume that there already exists a collection of useful components written in other languages. Scripting languages aren't intended for writing applications from scratch; they are intended primarily for plugging together components. For example, Tcl and Visual Basic can be used to arrange collections of user interface controls on the screen, and Unix shell scripts are used to assemble filter programs into pipelines. Scripting languages are often used to extend the features of components but they are rarely used for complex algorithms and data structures; features like these are usually provided by the components. Scripting languages are sometimes referred to as glue languages or system integration languages.

In order to simplify the task of connecting components, scripting languages tend to be typeless: all things look and behave the same so that they are interchangeable. For example, in Tcl or Visual Basic a variable can hold a string one moment and an integer the next. Code and data are often interchangeable, so that a program can write another program and then execute it on the fly. Scripting languages are often string-oriented, since this provides a uniform representation for many different things.

The strongly typed nature of system programming languages discourages reuse. Typing encourages programmers to create a variety of incompatible interfaces ("interfaces are good; more interfaces are better"). Each interface requires objects of specific types and the compiler prevents any other types of objects from being used with the interface, even if that would be useful. In order to use a new object with an existing interface, conversion code must be written to translate between the type of the object and the type expected by the interface. This in turn requires recompiling part or all of the application, which isn't possible in the common case where the application is distributed in binary form.

...It might seem that the typeless nature of scripting languages could allow errors to go undetected, but in practice scripting languages are just as safe as system programming languages. For example, an error will occur if the font size specified for the button example above is a non-integer string such as xyz. The difference is that scripting languages do their error checking at the last possible moment, when a value is used. Strong typing allows errors to be detected at compile-time, so the cost of run-time checks is avoided. However, the price to be paid for this efficiency is restrictions on how information can be used: this results in more code and less flexible programs.

...Scripting languages are less efficient than system programming languages, in part because they use interpreters instead of compilers but also because their basic components are chosen for power and ease of use rather than an efficient mapping onto the underlying hardware. For example, scripting languages often use variable-length strings in situations where a system programming language would use a binary value that fits in a single machine word, and scripting languages often use hash tables where system programming languages use indexed arrays.

Scripting languages are higher level than system programming languages, in the sense that a single statement does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions, whereas a typical statement in a system programming language executes about five machine instructions. Part of this difference is because scripting languages use interpreters, which are less efficient than the compiled code for system programming languages. But much of the difference is because the primitive operations in scripting languages have greater functionality. For example, in Perl it is about as easy to invoke a regular expression substitution as it is to invoke an integer addition. In Tcl, a variable can have traces associated with it so that setting the variable causes side effects; for example, a trace might be used to keep the variable's value updated continuously on the screen.

A scripting language is not a replacement for a system programming language or vice versa. Each is suited to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language; system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster than a scripting language because it makes fewer run-time checks.

Most of the major computing platforms over the last 30 years have provided both system programming and scripting languages. For example, one of the first scripting languages, albeit a crude one, was JCL (Job Control Language), which was used to sequence job steps in OS/360. The individual job steps were written in PL/1, Fortran, or assembler language, which were the system programming languages of the day. In the Unix machines of the 1980's, C was used for system programming and shell programs such as sh and csh for scripting. In the PC world of the 1990's, C and C++ are used for system programming and Visual Basic for scripting. In the Internet world that is taking shape now, Java is used for system programming and languages such as JavaScript, Perl, and Tcl are used for scripting.

Scripting languages have existed for a long time, but in recent years several factors have combined to increase their importance. The most important factor is a shift in the application mix towards gluing applications. Three examples of this shift are graphical user interfaces, the Internet, and component frameworks.

The third example of scripting-oriented applications is component frameworks such as ActiveX, OpenDoc, and JavaBeans. Although system programming languages work well for creating components, the task of assembling components into applications is better suited to scripting. Without a good scripting language to manipulate the components, much of the power of a component framework is lost. This may explain in part why component frameworks have been more successful on PCs (where Visual Basic provides a convenient scripting tool) than on other platforms such as Unix/CORBA where scripting is not included in the component framework.

Another reason for the increasing popularity of scripting languages is improvements in scripting technology. Modern scripting languages such as Tcl and Perl are a far cry from early scripting languages such as JCL. For example, JCL didn't even provide basic iteration and early Unix shells didn't support procedures. Scripting technology is still relatively immature even today. For example, Visual Basic isn't really a scripting language; it was originally implemented as a simple system programming language, then modified to make it more suitable for scripting. Future scripting languages will be even better than those available today.

One final reason for the increasing use of scripting languages is a change in the programmer community. Twenty years ago most programmers were sophisticated programmers working on large projects. Programmers of that era expected to spend several months to master a language and its programming environment, and system programming languages were designed for such programmers. However, since the arrival of the personal computer, more and more casual programmers have joined the programmer community. For these people, programming is not their main job function; it is a tool they use occasionally to help with their main job. Examples of casual programming are simple database queries or macros for a spreadsheet. Casual programmers are not willing to spend months learning a system programming language, but they can often learn enough about a scripting language in a few hours to write useful programs. Scripting languages are easier to learn because they have simpler syntax than system programming languages and because they omit complex features like objects and threads. For example, compare Visual Basic with Visual C++; few casual programmers would attempt to use Visual C++, but many have been able to build useful applications with Visual Basic.

Scripting languages have been mostly overlooked by experts in programming languages and software engineering. Instead, they have focused their attention on object-oriented system programming languages such as C++ and Java. Object-oriented programming is widely believed to represent the next major step in the evolution of programming languages. Object-oriented features such as strong typing and inheritance are often claimed to reduce development time, increase software reuse, and solve many other problems including those addressed by scripting languages.

...How much benefit has object-oriented programming actually provided? Unfortunately I haven't seen enough quantitative data to answer this question definitively. In my opinion objects provide only a modest benefit: perhaps a 20-30% improvement in productivity but certainly not a factor of two, let alone a factor of 10. C++ now seems to be reviled as much as it is loved, and some language experts are beginning to speak out against object-oriented programming [2]. The rest of this section explains why objects don't improve productivity in the dramatic way that scripting does, and it argues that the benefits of object-oriented programming can be achieved in scripting languages.

...The reason why object-oriented programming doesn't provide a large improvement in productivity is that it doesn't raise the level of programming or encourage reuse. In an object-oriented language such as C++ programmers still work with small basic units that must be described and manipulated in great detail. In principle, powerful library packages could be developed, and if these libraries were used extensively they could raise the level of programming. However, not many such libraries have come into existence. The strong typing of most object-oriented languages encourages narrowly defined packages that are hard to reuse. Each package requires objects of a specific type; if two packages are to work together, conversion code must be written to translate between the types required by the packages.

Scripting languages, on the other hand, have actually generated significant software reuse. They use a model where interesting components are built in a system programming language and then glued together into applications using the scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable, and there are well-defined interfaces between components and scripts that make it easy to use components. For example, in Tcl the components are custom commands implemented in C; they look just like the builtin commands so they are easy to invoke in Tcl scripts. In Visual Basic the components are ActiveX extensions, which can be used by dragging them from a palette onto a form.

Scripting languages represent a different set of tradeoffs than system programming languages. They give up execution speed and strength of typing relative to system programming languages but provide significantly higher programmer productivity and software reuse. This tradeoff makes more and more sense as computers become faster and cheaper in comparison to programmers. System programming languages are well suited to building components where the complexity is in the data structures and algorithms, while scripting languages are well suited for gluing applications where the complexity is in the connections. Gluing tasks are becoming more and more prevalent, so scripting will become an even more important programming paradigm in the next century than it is today.

The Rise of  "Worse is Better''

The Rise of ``Worse is Better''

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

Worse Is Better by Richard P Gabriel

Worse Is Better by Richard P Gabriel

The concept known as “worse is better” holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this “piecemeal growth.” This is the story of the evolution of that concept.

From 1984 until 1994 I had a Lisp company called “Lucid, Inc.” In 1989 it was clear that the Lisp business was not going well, partly because the AI companies were floundering and partly because those AI companies were starting to blame Lisp and its implementations for the failures of AI. One day in Spring 1989, I was sitting out on the Lucid porch with some of the hackers, and someone asked me why I thought people believed C and Unix were better than Lisp. I jokingly answered, “because, well, worse is better.” We laughed over it for a while as I tried to make up an argument for why something clearly lousy could be good.

A few months later, in Summer 1989, a small Lisp conference called EuroPAL (European Conference on the Practical Applications of Lisp) invited me to give a keynote, probably since Lucid was the premier Lisp company. I agreed, and while casting about for what to talk about, I gravitated toward a detailed explanation of the worse-is-better ideas we joked about as applied to Lisp. At Lucid we knew a lot about how we would do Lisp over to survive business realities as we saw them, and so the result was called “Lisp: Good News, Bad News, How to Win Big.” [html] (slightly abridged version) [pdf] (has more details about the Treeshaker and delivery of Lisp applications).

I gave the talk in March, 1990 at Cambridge University. I had never been to Cambridge (nor to Oxford), and I was quite nervous about speaking at Newton’s school. There were about 500-800 people in the auditorium, and before my talk they played the Notting Hillbillies over the sound system - I had never heard the group before, and indeed, the album was not yet released in the US. The music seemed appropriate because I had decided to use a very colloquial American-style of writing in the talk, and the Notting Hillbillies played a style of music heavily influenced by traditional American music, though they were a British band. I gave my talk with some fear since the room was standing room only, and at the end, there was a long silence. The first person to speak up was Gerry Sussman, who largely ridiculed the talk, followed by Carl Hewitt who was similarly none too kind. I spent 30 minutes trying to justify my speech to a crowd in no way inclined to have heard such criticism - perhaps they were hoping for a cheerleader-type speech.

I survived, of course, and made my way home to California. Back then, the Internet was just starting up, so it was reasonable to expect not too many people would hear about the talk and its disastrous reception. However, the press was at the talk and wrote about it extensively in the UK. Headlines in computer rags proclaimed “Lisp Dead, Gabriel States.” In one, there was a picture of Bruce Springsteen with the caption, “New Jersey Style,” referring to the humorous name I gave to the worse-is-better approach to design. Nevertheless, I hid the talk away and soon was convinced nothing would come of it.

About a year later we hired a young kid from Pittsburgh named Jamie Zawinski. He was not much more than 20 years old and came highly recommended by Scott Fahlman. We called him “The Kid.” He was a lot of fun to have around: not a bad hacker and definitely in a demographic we didn’t have much of at Lucid. He wanted to find out about the people at the company, particularly me since I had been the one to take a risk on him, including moving him to the West Coast. His way of finding out was to look through my computer directories - none of them were protected. He found the EuroPAL paper, and found the part about worse is better. He connected these ideas to those of Richard Stallman, whom I knew fairly well since I had been a spokesman for the League for Programming Freedom for a number of years. JWZ excerpted the worse-is-better sections and sent them to his friends at CMU, who sent them to their friends at Bell Labs, who sent them to their friends everywhere.

Soon I was receiving 10 or so e-mails a day requesting the paper. Departments from several large companies requested permission to use the piece as part of their thought processes for their software strategies for the 1990s. The companies I remember were DEC, HP, and IBM. In June 1991, AI Expert magazine republished the piece to gain a larger readership in the US.

However, despite the apparent enthusiasm by the rest of the world, I was uneasy about the concept of worse is better, and especially with my association with it. In the early 1990s, I was writing a lot of essays and columns for magazines and journals, so much so that I was using a pseudonym for some of that work: Nickieben Bourbaki. The original idea for the name was that my staff at Lucid would help with the writing, and the single pseudonym would represent the collective, much as the French mathematicians in the 1930s used “Nicolas Bourbaki” as their collective name while rewriting the foundations of mathematics in their image. However, no one but I wrote anything under that name.

In the Winter of 1991-1992 I wrote an essay called “Worse Is Better Is Worse” under the name “Nickieben Bourbaki.” This piece attacked worse is better. In it, the fiction was created that Nickieben was a childhood friend and colleague of Richard P. Gabriel, and as a friend and for Richard’s own good, Nickieben was correcting Richard’s beliefs.

In the Autumn of 1992, the Journal of Object-Oriented Programming (JOOP) published a “rebuttal” editorial I wrote to “Worse Is Better Is Worse” called “Is Worse Really Better?” The folks at Lucid were starting to get a little worried because I would bring them review drafts of papers arguing (as me) for worse is better, and later I would bring them rebuttals (as Nickieben) against myself. One fellow was seriously nervous that I might have a mental disease.

In the middle of the 1990s I was working as a management consultant (more or less), and I became interested in why worse is better really could work, so I was reading books on economics and biology to understand how evolution happened in economic systems. Most of what I learned was captured in a presentation I would give back then, typically as a keynote, called “Models of Software Acceptance: How Winners Win,” and in a chapter called “Money Through Innovation Reconsidered,” in my book of essays, “Patterns of Software: Tales from the Software Community.”

You might think that by the year 2000 I would have settled what I think of worse is better - after over a decade of thinking and speaking about it, through periods of clarity and periods of muck, and through periods of multi-mindedness on the issues. But, at OOPSLA 2000, I was scheduled to be on a panel entitled “Back to the Future: Is Worse (Still) Better?” And in preparation for this panel, the organizer, Martine Devos, asked me to write a position paper, which I did, called “Back to the Future: Is Worse (Still) Better?” In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called “Back to the Future: Worse (Still) is Better!” which was in favor of it. I still can’t decide. Martine combined the two papers into the single position paper for the panel, and during the panel itself, run as a fishbowl, participants routinely shifted from the pro-worse-is-better side of the table to the anti-side. I sat in the audience, having lost my voice giving my Mob Software talk that morning, during which I said, “risk-taking and a willingness to open one’s eyes to new possibilities and a rejection of worse-is-better make an environment where excellence is possible. Xenia invites the duende, which is battled daily because there is the possibility of failure in an aesthetic rather than merely a technical sense.”

Decide for yourselves.


  1. Why GAWK for AI? - draft of article by Ronald P. Loui.
  2. Source code as human language -- interview with Tim O'Really
  3. The Secret Life of Game Scripting
  4. In Praise of Scripting:  Real Programming Pragmatism by Ronald P. Loui  
  5. Java Makes Scripting Languages Irrelevant by Diomidis Spinellis

[Loui1996] Why GAWK for AI? - draft of article by Ronald P. Loui. (1996)

Most people are surprised when I tell them what language we use in our undergraduate AI programming class.  That's understandable.  We use GAWK.  GAWK, Gnu's version of Aho, Weinberger, and Kernighan's old pattern scanning language isn't even viewed as a programming language by most people.  Like PERL and TCL, most prefer to view it as a "scripting language."  It has no objects; it is not functional; it does no built-in logic programming.  Their surprise turns to puzzlement when I confide that (a) while the students are allowed to use any language they want; (b) with a single exception, the best work consistently results from those working in GAWK.  (footnote:  The exception was a PASCAL programmer who is now an NSF graduate fellow getting a Ph.D. in mathematics at Harvard.) Programmers in C, C++, and LISP haven't even been close (we have not seen work in PROLOG or JAVA).


There are some quick answers that have to do with the pragmatics of undergraduate programming.  Then there are more instructive answers that might be valuable to those who debate programming paradigms or to those who study the history of AI languages.  And there are some deep philosophical answers that expose the nature of reasoning and symbolic AI.  I think the answers, especially the last ones, can be even more surprising than the observed effectiveness of GAWK for AI.

First it must be confessed that PERL programmers can cobble together AI projects well, too.  Most of GAWK's attractiveness is reproduced in PERL, and the success of PERL forebodes some of the success of GAWK. Both are powerful string-processing languages that allow the programmer to exploit many of the features of a UNIX environment.  Both provide powerful constructions for manipulating a wide variety of data in reasonably efficient ways.  Both are interpreted, which can reduce development time.  Both have short learning curves.  The GAWK manual can be consumed in a single lab session and the language can be mastered by the next morning by the average student.  GAWK's automatic initialization, implicit coercion, I/O support and lack of pointers forgive many of the mistakes that young programmers are likely to make. Those who have seen C but not mastered it are happy to see that GAWK retains some of the same sensibilities while adding what must be regarded as spoonsful of syntactic sugar.  Some will argue that PERL has superior functionality, but for quick AI applications, the additional functionality is rarely missed.  In fact, PERL's terse syntax is not friendly when regular expressions begin to proliferate and strings contain fragments of HTML, WWW addresses, or shell commands. PERL provides new ways of doing things, but not necessarily ways of doing new things.

In the end, despite minor difference, both PERL and GAWK minimize programmer time.  Neither really provides the programmer the setting in which to worry about minimizing run-time.

There are further simple answers.  Probably the best is the fact that increasingly, undergraduate AI programming is involving the Web.  Oren Etzioni (University of Washington, Seattle) has for a while been arguing that the "softbot" is replacing the mechanical engineers' robot as the most glamorous AI testbed.  If the artifact whose behavior needs to be controlled in an intelligent way is the software agent, then a language that is well-suited to controlling the software environment is the appropriate language.  That would imply a scripting language.  If the robot is KAREL, then the right language is "turn left; turn right." If the robot is Netscape, then the right language is something that can generate "netscape -remote 'openURL('" with elan.

Of course, there are deeper answers.  Jon Bentley found two pearls in GAWK:  its regular expressions and its associative arrays.  GAWK asks the programmer to use the file system for data organization and the operating system for debugging tools and subroutine libraries.  There is no issue of user-interface.  This forces the programmer to return to the question of what the program does, not how it looks.  There is no time spent programming a binsort when the data can be shipped to /bin/sort in no time.  (footnote:  I am reminded of my IBM colleague Ben Grosof's advice for Palo Alto:  Don't worry about whether it's highway 101 or 280. Don't worry if you have to head south for an entrance to go north.  Just get on the highway as quickly as possible.)

There are some similarities between GAWK and LISP that are illuminating. Both provided a powerful uniform data structure (the associative array implemented as a hash table for GAWK and the S-expression, or list of lists, for LISP).  Both were well-supported in their environments (GAWK being a child of UNIX, and LISP being the heart of lisp machines).  Both have trivial syntax and find their power in the programmer's willingness to use the simple blocks to build a complex approach.

Deeper still, is the nature of AI programming.  AI is about functionality and exploratory programming.  It is about bottom-up design and the building of ambitions as greater behaviors can be demonstrated. Woe be to the top-down AI programmer who finds that the bottom-level refinements, "this subroutine parses the sentence," cannot actually be implemented.  Woe be to the programmer who perfects the data structures for that heapsort when the whole approach to the high-level problem needs to be rethought, and the code is sent to the junkheap the next day.

AI programming requires high-level thinking.  There have always been a few gifted programmers who can write high-level programs in assembly language. Most however need the ambient abstraction to have a higher floor. 

Now for the surprising philosophical answers.  First, AI has discovered that brute-force combinatorics, as an approach to generating intelligent behavior, does not often provide the solution.  Chess, neural nets, and genetic programming show the limits of brute computation.  The alternative is clever program organization.  (footnote: One might add that the former are the AI approaches that work, but that is easily dismissed:  those are the AI approaches that work in general, precisely because cleverness is problem-specific.)  So AI programmers always want to maximize the content of their program, not optimize the efficiency of an approach.  They want minds, not insects.  Instead of enumerating large search spaces, they define ways of reducing search, ways of bringing different knowledge to the task.  A language that maximizes what the programmer can attempt rather than one that provides tremendous control over how to attempt it, will be the AI choice in the end.

Second, inference is merely the expansion of notation.  No matter whether the logic that underlies an AI program is fuzzy, probabilistic, deontic, defeasible, or deductive, the logic merely defines how strings can be transformed into other strings.  A language that provides the best support for string processing in the end provides the best support for logic, for the exploration of various logics, and for most forms of symbolic processing that AI might choose to call "reasoning" instead of "logic."  The implication is that PROLOG, which saves the AI programmer from having to write a unifier, saves perhaps two dozen lines of GAWK code at the expense of strongly biasing the logic and representational expressiveness of any approach.

I view these last two points as news not only to the programming language community, but also to much of the AI community that has not reflected on the past decade's lessons.

In the puny language, GAWK, which Aho, Weinberger, and Kernighan thought not much more important than grep or sed, I find lessons in AI's trends, AI's history, and the foundations of AI.  What I have found not only surprising but also hopeful, is that when I have approached the AI people who still enjoy programming, some of them are not the least bit surprised.

R. Loui ( is Associate Professor of Computer Science, at Washington University in St. Louis.  He has published in AI Journal, Computational Intelligence, ACM SIGART, AI Magazine, AI and Law, the ACM Computing Surveys Symposium on AI, Cognitive Science, Minds and Machines, Journal of Philosophy, and is on this year's program committees for AAAI (National AI conference) and KR (Knowledge Representation and Reasoning).  

Source code as human language -- interview with Tim O'Really

Source code as human language -- interview with Tim O'Really

...O'Reilly sees the excitement of the future attaching to "infoware." While waves of consultants periodically proclaim that content is king, O'Reilly has in mind a category more dynamic and active than online movies or digitized paintings. For him, as he explains in a piece called "The Open-Source Revolution," "infoware embeds small amounts of software in a lot of information." Those little, but well-integrated, pieces of intelligence make Amazon and comparable "information applications" the winners they are.

..That architectural vision of small, well-integrated pieces of software is the central theme of scripting, of course. O'Reilly is right to characterize current infoware as "HTML plus scripting." 

...He understands the rules well enough to be consistently profitable, but the most distinctive aspect of O'Reilly's vision of software is to see it as expression more than product. His delight is evident when he describes the progress the Electronic Freedom Foundation is making in its legislative goals by presenting software as speech rather than invention. He consistently talks about applications in the language of the theater or gallery.

... scripting is often dismissed as "quick and dirty stuff that is somehow less significant than the programming behind compiled commercial applications." Rather than fighting this aspersion, he inverts it, and explains that scripting is simply "closer to what people need ... Most speech is extemporaneous, not prepared. Conversation would be pretty stilted if everything one said was prepared, formal speech." Scripting is an extension of speech that powerfully matches the way people really learn and accomplish what they want when relating to computers.

...Duct tape is perfect for stuff at the edge." Crews specializing in performance or experiment setup know how to use throw away components to get a concert hall or laboratory in shape for special events. Scripting's flexibility also fits the temper of current management literature, which emphasizes quick response and not-necessarily-perfect solutions.

... Scripting in general, he said, "will find itself more and more interwoven" with the infoware that has begun to define how people relate to computers. Their high-level expressivity, openness to other technologies, and "failsoftness" will keep scripting languages on a steep growth curve.

One of the motivations for O'Reilly's Unix Power Tools, for instance, is the "natural progression" in Unix from the command line to simple scripts to more powerful languages. Perl creator Larry Wall describes the linguistic thinking underlying Perl as a progression that mimics the way people learn and use natural languages.

As Wall puts it, languages that follow this natural "speech" progression are fundamentally more accessible -- more democratic -- than "languages that don't let you speak at all until you have the equivalent of a college education."

..."Once you start thinking of computer source code as a human language, you see open source as a variety of 'free speech.' Free speech is not just a political ideal. It is the currency of science and of western civilization. It is a truism in the Western academic tradition dating back to the Renaissance that exposure to criticism and dialogue are the surest ways to refine ideas," O'Reilly said.

While such familiar open source products as "Linux, Apache, Sendmail, and BIND have had an enormous effect on the computer industry," O'Reilly argues that "scripting languages make the open source ethic even more universal. Because scripting languages are interpreted, their 'source code' is almost by definition open. This makes the community of discourse enabled by 'HTML-plus-scripting'... orders of magnitude greater than the community of hard-core developers working in higher-level languages."

[Loui2005] In Praise of Scripting:  Real Programming Pragmatism by Ronald P. Loui  

The real shock is that the academic programming language community continues to reject the sea change in programming practices brought about by scripting.  Enamored of the object-oriented paradigm, especially in the undergraduate curriculum, unwilling to accept the LAMP (Linux-Apache-MySQL-Perl/Python/Php) tool set, and firmly believing that more programming theory leads to better programming practice, the academics seem blind to the facts on the ground.  The ACM flagship, COMMUNICATIONS OF THE ACM for example, has never published a paper recognizing the scripting philosophy, and the references throughout the ACM Digital Library to scripting are not encouraging.

... ... ...

Part of the problem is that scripting has risen in the shadow of object-oriented programming and highly publicized corporate battles between Sun, Netscape, and Microsoft with their competing software practices.  Scripting has been appearing language by language, including object-oriented scripting languages now.  Another part of the problem is that scripting is only now mature enough to stand up against its legitimate detractors.  Today, there are answers to many of the persistent questions about scripting:  is there a scripting language appropriate for the teaching of CS1 (the first programming course for majors in the undergraduate computing curriculum)?  Is there a scripting
language for enterprise or real-time applications?  Is there a way for scripting practices to scale to larger software engineering projects?

[Spinellis2005] Java Makes Scripting Languages Irrelevant by Diomidis Spinellis. This can be considered as classic Java apologetics. Problems with high cost of development, slow debugging, java class libraries hell, etc are swiped under the carpet.  That author claim that "The gap between system programming languages and scripting languages is slowly closing.  For example, some scripting languages are capitalizing on Java’s infrastructure by having their code compile into JVM bytecode.   However, there is still a lot of ground in the middle that is up for the grabs.  New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day.  The issue of the result’s quality remains an open question on both fronts."

Rumors of the death of scripting languages ...

Notice, how most of  the nice features applications obtain through the use of scripting languages are now offered by Java:

In addition, in applications written in Java what can be considered as an API already comes for free as part of their object-oriented design.  One only needs to allow an application to dynamically load user-specified classes, expose its API by providing access to some of the application’s objects, limit the application’s exposure through the security manager and exception handlers, and the need for a separate scripting language vanishes. 

In fact, many modern Java applications that support beans, plugins, and other extension mechanisms, follow exactly this strategy.  Eclipse, Maven, Ant, Javadoc, ArgoUML, and Tomcat are some notable examples.  Even on resource-constrained embedded devices, such as mobile phones, which are still programmed in a system programming language, configuration and customization is currently moving toward the Java direction.

... are greatly exaggerated

Does the trend of customizing applications through a Java interface make scripting languages irrelevant?  Yes and no.  As an application configuration and extension mechanism, Java is probably the way to go.  The cost of marshalling and unmarshaling data objects and types between the application's code written in Java and the conventions expected by a different scripting language is too high for the limited incremental benefits that the scripting language would offer.  On the other hand, scripting languages still have an edge in a number of areas, offering us a number of distinct advantages.

A more flexible or imaginative syntax. Think of Perl's numerous quoting mechanisms and its regular expression extension syntax, or Python's use of indentation for grouping statements.  These make some program elements a lot easier to read.  As an example, variable substitution within Perl’s or the Unix shell’s double quoted strings is by far the most readable way to represent a program’s output.

Less fuss about types. Most scripting languages are typeless and therefore easier to write programs in.  For example, Perl makes writing a client or server for an XML-based web service a breeze, whereas in Java we have to go through a number of contortions to implement the same functionality.  Of course, the robustness and maintainability of code written in a typeless language is a different question, as many of us who maintain production code written in a scripting language later discover.

A more aggressive use of reflection. Consider here Perl's eval construct and Python's object emulation features.  These allow the programmer to construct and execute code on the fly, or dynamically change a class’s fields.  In many cases these features simplify the construction of flexible and adaptable software systems.

Tighter integration with command-line tools. Although Java 1.5 comes with an API containing over 3000 classes—with thousands more being available through both open source and proprietary packages—many operations can still be performed in a more reliable and efficient manner by interfacing with venerable command-line tools.  The Unix scripting languages provide many facilities for combining these tools, such as the creation of pipelines, and the processing of data through sophisticated control constructs.

Viability as a command language. Many scripting languages, such as the ones of the operating system shells, can also double as a command language.  Command-line interfaces often offer a considerably more expressive working medium than GUI environments (we’ll expand on that in another column).  Coupling a command-line interface with a scripting language means that commonly executed command sequences can easily be promoted into automated scripts; a boon to developers.  This coupling also encourages an exploratory programming style, which many of us find very productive.  I often code complex pipelines step by step, examining the output of each step, before tacking another processing element at the pipeline’s end.

A shorter build cycle. Although for many systems a build cycle that provided time for an elaborate lunch is now sadly history, the tight feedback loop offered by the lack of a compilation step in scripting languages allows for rapid prototyping and exploratory changes, often hand-in-hand with the end-user.  This is a feature that those using agile development methodologies can surely appreciate.

So, where do we stand now?  The gap between system programming languages and scripting languages is slowly closing.  For example, some scripting languages are capitalizing on Java’s infrastructure by having their code compile into JVM bytecode.   However, there is still a lot of ground in the middle that is up for the grabs.  New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day.  The issue of the result’s quality remains an open question on both fronts.

We developers, as avid tool users, enjoy viewing the battle from atop, reaping the benefits.

Diomidis Spinellis is an associate professor in the Department of Management Science and Technology at the Athens University of Economics and Business and the author of Code Reading: The Open Source Perspective (Addison-Wesley, 2003).  Contact him at

Comparing Python to Other Languages

Comparing Python to Other Languages by Guido van Rossum

An evaluation of various free programming languages  by  Keith Waclena . I

A Language Collector Comments On: Java, Perl & Python, by David Rook, in the Oct, '97 issue of a Navy computing publication, Chips.

Comparisons of Tcl with other systems

extensive discussion by  Wayne Christopher focused around Tcl.

Python/Tcl comparison (postscript) produced in the course of evaluation of interpreted languages for use in Alice (originally from U. VA.), a virtual-reality modelling engine which uses Python.

Sjoerd Mullender created a comparison of Python and TCL.

Frank Stajano's paper, Implementing the SMS server, or why I switched from Tcl to Python, was presented at the Seventh Internation Python Conference. (Also available in PDF.) -- read, but do not believe the author  :-)

What's wrong with Perl

One of the first things I discovered I didn't like was the syntax. It's very complex and there are lots of operators and special syntaxes. This means that you get short, but complex code with many syntax errors that take some time to sort out.

It also means that reading someone elses code is difficult. You can't easily understand someone elses scripts and adapt them to your own needs, nor can you easily take over the maintenance of someone elses program.

Some have argued that Perl is more like natural languages than most programming languages, and this certainly seems correct to me. And to me that is a disadvantage: natural language is extremely complex, ambiguous and full of subtle nuances and meanings. I certainly don't want my programs to be like that, but it seems that some do. I guess the reader will have to find out for him/herself which category s/he belongs in.

Many of Perls features are built right into the language core itself, instead of being placed in separate libraries. One example of this is the handling of regular expressions, for which there is a special syntax. This has the advantage that there are some convenient ways of doing the things that are done most often, but it also means that you don't get the advantages of objects.

In other words, you can't precompile a bunch of regular expressions and stick them in a list. You can't return a precompiled regular expression from a function or set a variable to a regular expression. (I've been told that this has changed in Perl 5.005, but have not seen any example code. I would be grateful if anyone could provide this.)

Another major disadvantage to Perl is that of function (or subroutine, in Perl lingo) signatures, or rather, the lack of signatures. In most programming languages when you declare a function you also declare its signature, listing the names of the parameters and in some languages also their types. Perl doesn't do this.

Although object-orientation is not as fantastic as many would like us to think, Perl actually does support it. However, it does so only half-heartedly, since objects were added rather late in the life of the language.

The result of this is that files, sockets, hashes and lists are not objects, and that you cannot create objects that behave like these built-in types, which is a real pity and rather awkward at times.

 A Language Collector Comments On Java Perl & Python

Python. From the outside Python looks like C++ and has many OOP (object oriented programming) features, but without much of the complexity of C++.

For instance, Python is a self-typed language. Assign a string to a variable and the variable is assigned storage as a string. If you later use the variable in an arithmetic expression, you get a compile error. You also get a compile-time error if you try to do arithmetic with uninitialized variables. The reason is that uninitialized variables don't have a type, and some data types can't participate in arithmetic expressions.

Once you stop using a variable, it gets reclaimed (garbage collected) automatically. This is important because C++ programmers tend to devote a large portion of code (10 to 20 percent) to preparation for and execution of the memory allocation/reclamation process. While C++ makes the setup/tear down process easier than with C, Python makes it unnecessary.

Grab-bag of Python features:

While none of these features are really earth-shaking, the concise, consistent architecture is a welcome relief.

Another feature is that Python is both compiled and interpreted. When you run a Python program it's automatically com piled to pycode (aka pseudocode, like Java's bytecode) and then interpreted. Pycode generally runs about 100 times slower than native code, but now we get to another interesting feature. It's relatively easy to mix and match Pycode and regular C or C++. The typical scenario is to develop in Python then convert modules that don't run as fast as you want to C or C++. C can be called from Python and vice versa!

The ability to support RAD (Rapid Application Development) with Python is the key to its success. The most concise description of Python I can think of is, "Python is executable pseudo-code". This is exactly what I wanted for my human-friendly firewall logs.

It's impossible for me to detail all the neat things I've found in Python in a page or so. If you're interested in programming (and you must be or you wouldn't still be reading this...) check it out for yourself at You can find WIN95, WINNT, Unix and other flavors of Python interpreters there.

The 881 page Programming Python by Mark Lutz (O'Reilly & Associates Inc.) provides a good tutorial on Python, but to get the true flavor of the language you need to see some real-world source code. Fortunately, the Python source code (in a combination of Python and C) is available free on the Internet.

The What Why Who and Where of Python

Do-it-yourself benchmarking - SunWorld - January 1999

Line counts in C or Java are about three times more than those in Tcl for the same activity. This difference is crucial: experimentation in these languages seems like a chore, while the comparable work in Tcl is entertainingly easy.

Do-it-yourself benchmarking - SunWorld - January 1999 -- A look at scripting performance and project feasibility.

Tom Christiancen compared Perl and Python

... Python does not resemble C very much, nor in fact does it resemble awk, sh, sed, or any other Unix utility really at all (whereas Perl does). It doesn't have assignment operators or autoincrement operators or anything like that, all of which seem to deeply confuse non-C programmers. Both have an interactive mode for easy debugging. Python was designed ab initio to be object-oriented and have clear module semantics (although I think some folks find the namespace games messy). It is nearly as fast as Perl, but doesn't have so powerful regular expression stuff as Perl, nor does it have function pointers with deep binding (read: closures), and a variety of other things I forget right now. The Unix interactions Perl is so good at can probably be taken care of in Python using the proper extension module (beware though, as that's what they'll say about extended tcl in incrtcl as well, and down that path lies madness). I'm pretty sure there's no way to take a pointer to something: it's all implicit, for both good and bad. I'm not sure what if anything at this point Python has that Perl doesn't.

One of those most annoying things about Python for many people is that it intuits block structure from indentation alone.

Its loops look like this

    while 1:
	    buf =index.html
	    if not buf: break

In Perl, that would be

    while (1) {
	$buf = $fp->read($blocksize);
	if (not $buf) { last } 

... ... ... 

Don't screw up on indentation though, or you'll screw up on blocks! Perl at least fixes C's ambiguity by REQUIRING curleys for blocks. This seems to help a LOT of people.

Python also tolerates newline as a statement separator. That means that you're going to have to do some surprising things at times. For example this:

    a = 3 * 5
	- 12;

won't work.

In summary, there's a great deal of overlap in functionality between the two. The extent to which you prefer one over the other will probably depend on how comfortable you already are with C and Unix shell programming in general. It may also depend on whether they're already a library written (or a primitive) to do what you want, like database manipulation, math stuff, forms entry, graphics (windows or pixels) extensions. Perl is also a bit older and far more widespread than Python, and Perl ships with a number of vendor systems. 


New choices for scripting - SunWorld - February 1999

...Even after years of confronting it, the popular belief that scripting is "unsafe" or "only for toy problems" continues to surprise us. Part of the difficulty is that many of the specific details for which critics fault such languages are in fact strengths or, at worst, non-issues. (Example: Yes, there are far fewer software engineering utilities sold for Perl than for C. Any dispassionate observer, though, would agree it's a good thing that Perl semantics don't permit memory violations, and thus don't deserve all the checking that is a practical necessity when coding in C.)

...Beside algorithmic expressiveness, one of the best things about scripting is that it encourages practitioners to exploit code-data dualities. This is crucial in such examples as Tk's remarkable success as a cross-platform, cross-language graphical toolkit. The same principle of communication through exchange of simple, human-readable encodings, has powered scripting's dominance in network domains like CGI and exploitation of new protocols.

...The problem seems to be this: High-level coding is so easy and even fun that programmers quickly become expert at it. They become expert at clever and supple construction of subtle algorithms. Designing robust architectures, though, is very different, and many of the same programmers never learn the necessary skills. Their instinct is to just keep programming until a problem gives up from exhaustion.

...Scripting, especially string-oriented languages such as Tcl, have the potential to merge stored and loaded data "formats", and get rid of this whole mess. The missing link is the ability to reorganize live data. ...


XOTCL - an Object-Oriented Scripting Language Accepted for publication in:
Proceedings of 7th Usenix Tcl/Tk Conference (Tcl2k), Austin, Texas, Feb 14-18, 2000

This paper describes the object-oriented scripting language XOTCL (Extended OTCL), which is a value added replacement of OTCL. OTCL implements dynamic and introspective language support for object-orientation on top of TCL. XOTCL includes the functionality of OTCL but focuses on the construction, management, and adaptation of complex systems. In order to combine the benefits of scripting languages with advanced object-oriented techniques, we extended OTCL in various ways: We developed the filter as a powerful adapation technique and an intuitive means for the instantiation of large program structures. In order to enable objects to access several addition-classes we improved the flexibility of mixin methods by enhancing the object model with per-object mixins. We integrated the object system with the TCL namespace concept to provide nested classes and dynamic object aggregations. Moreover, we introduced assertions and meta-data to improve reliability and self-documentation.

The safety of scripting - SunWorld - October 1998

When language theoreticians and proponents write about "safety," their first thought is usually about the kind of semantic questions Java's exception-handling addresses. Suppose you're coding an application, and you mistakenly ask for the thirteenth element of an array or vector with 10 members...... ... ...

Less coding yields fewer errors in coding. The incidence of errors in programming seems remarkably constant, at a few per hundred lines of finished source...

...the expressiveness of scripting encourages source studies. Peer review is one of the surest paths to quality in implementation, and so anything that encourages colleagues to read source code is likely to yield large returns. Scripting languages are designed to be easy to use. The consequence is that they're also relatively easy to read...

Scripting's encouragement of "glueing" gives an under-appreciated safety benefit...

...While C mostly reuses individual functions, scripting languages emphasize encapsulation of whole processes at a time. Most scripting languages present a variety of "glues": hooks to connect processes, CORBA or DCOM components, client/server pieces, and so on, all the way down to individual C functions. This makes it a straightforward matter to "move the boundaries" of an architecture, even after a prototype has been accepted. Stewart Brand's How Buildings Learn: What Happens After They're Built is a marvelous essay ("the best book I've ever done," Brand says) in which he argues that the best buildings are those that match their occupants' lives. It's good to be able to tear down walls, reroute plumbing, or build other walls. Scripting is in the spirit of Brand's human-scale building. Scripted solutions adapt through their life cycle with relatively little trauma.

... Java is good for building monuments -- architectures destined to endure without change. Scripting languages tend to yield something more like "temporary school buildings" put up in emergencies which are still in use a half-century later.

So, which philosophy is a safer choice for your next project? With scripting languages, the nice thing is that you don't have to choose. You can use scripting's glueing capability to rely on as much or as little of a scripting language as is best for your situation. Scripting languages cooperate well with a formal approach (several have interfaces to Ada), and yet remain easy to use for beginners. Pick the mix of characteristics you need, and you're likely to find a scripting language that fits the bill





Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2020 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019