Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Softpanorama Scripting News, 1999

[July 17, 1999] Serious programming doesn't have to be difficult - SunWorld - July 1999

Still, DBMS vendors regard scripting as "slow, ugly, and a hack," in Poindexter's words. Several vendors have responded to their ease-of-use problems, but with the wrong answer. They offer so-called "fourth-generation (access) languages," generally proprietary variations on BASIC. Almost without exception, these are inflexible, syntactically confused, and, perhaps worst, useless for the database administration that always complements real-world DBMS developments.

So, from the start, savvy programmers have abstracted their own higher-order methods. Ten years ago, we often worked in isolation, coding in homegrown combinations of awk, DCL or sh, and sed. Despite the lack of vendor support, scripting bindings have now become commonplace. Most scripting languages support the most popular DBMSs well.

PHP is a particular leader in this. The PHP community has proven itself expert at the craft of extending the base language to encompass new DBMSs. Last month's Regular Expressions (see link in Resources below) focused on the way intelligent use of JavaScript and PHP makes a sophisticated, customized point-of-sale application feasible for a small development group. 

See also It's a good time to be a polyglot.

[Jan. 31, 1999] script search sites:

• http://www.scriptsearch.com -- all sorts of scripts/programs and is searchable

• http://www.cgi-resources.com -- also good...

• http://www.worldwidemart.com/scripts/

Programming Wisdom Center

• Scripting Language Options

Dave Winer's Scripting News Weblog

Choosing a scripting language - SunWorld - October 1997  -- a very good article

Perl, Tcl, Python. The odds are that you have used or at least heard of one of these popular scripting languages. We introduce you to the basic concepts in scripting and tell you how the "big three" languages compare. If you see a scripting language
somewhere in your future or if you're looking for an overview of what's out there, you should read this article. Also, be sure to check out the sidebar for quick definitions of such lesser-known languages as Rexx, Scheme, Guile, Forth, S-lang, Yorick, and Icon (3,000 words)

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:

• Though the syntax is a little different, Python has classes and inheritance very much like C++. This gives it both power and brevity of expression.

• The special syntax for list (array) operations is both simple and powerful.

• Integers are like C long ints.

• Unlike most languages, Python's long integers have unlimited size. Want to count the national debt in pennies? No problem in Python. Floating point in Python is handled like a C double.

• Dictionaries are associative arrays that allow objects to be stored and fetched by key.

• Python has exception handling much like the latest C++.

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 http://www.python.org. 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 fp.read(blocksize)
	    if not buf: break
	    conn.send(buf)

In Perl, that would be

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

... ... ... 

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. 

[January 15, 1999]: 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."

There's a big world beyond scripting, of course. The O'Reilly & Associates catalog has strong entries in traditional system languages such as C and Java. However, as humans and digital processors come together, more and more of our interactions will model the abbreviated, idiomatic, introspective conversations scripting languages enable.

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.

• 1998 Breakthrough year for scripting - SunWorld - August 1998

• Plenty of headroom left for Perl - SunWorld - September 1998

• Technology News from Wired News

• Patterns for Scripted Components

• comparison of Python and LISP by Joe Strout

• brief outline of the differences between Python and Scheme by Moshe Zadka

• Informal Notes from an MIT Programming Language Exploration Seminar by Thomas P. Minka evaluating and comparing Python, Self, Sather, Haskell, Lambda-Prolog, and Life (!-)...