|
|
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 | |||||||
| Prev | Up | Next |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
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.
|
|
|
http://www.scriptsearch.com -- all sorts of scripts/programs and is searchable
http://www.cgi-resources.com -- also good...
|
|
|
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)
|
|
|
|
|
|
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.
|
|
|
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.
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.
|
|
|
A look at scripting performance and project feasibility.
|
|
|
... 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.
|
|
|
...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.
|
|
|
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.
|
|
|
|
|
|
October 15, 1999 | Linux Magazine
Perl Opener
"Eventually the revolutionaries become the
established culture, and then what will they do?"–Linus Torvalds
They say one should never start with an apology, so here goes: I'm sorry, but
this essay will be all over the map. But then, given that I too am all over the map (and by
extension, so is Perl), this kind of wandering is entirely inevitable. So I'll do my best to keep
this story roughly organized in a chronological order because the history of Perl is suggestive of
various principles that you may see in operation elsewhere.Or maybe not…
PERL 0
Gestation
Sex makes babies.
Like the typical human, Perl was conceived in secret, and existed for roughly nine months before
anyone in the world ever saw it. Its womb was a secret project for the National Security Agency
known as the "Blacker" project, which has long since closed down. The goal of that sexy project was
not to produce Perl. However, Perl may well have been the most useful thing to come from Blacker.
Sex can fool you that way.Not only was Perl born of a sexy project, but its early design came from heavy
cross-pollination.Parents
Genetically speaking, of course, Perl has many more ancestors than that simple diagram above
indicates. (I've left out theology and biology, for instance.) I am a synthesist at heart, and can't
help throwing a little bit of everything into the pot all at once. Just in the realm of computer
science,Perl draws inspiration from many languages. One could draw a similar diagram just for thatMore Parents
That also is an oversimplification, since Perl has drawn from many other languages over the
years. (Lisp and Ada, for instance.) But the four languages in the diagram influenced Perl the most
at the beginning of its development. Well, those four, and BASIC-PLUS…At this point, I'm talking about Perl, version 0. Only a few people in my office ever used it.
In fact, the early history of Perl recorded in O'Reilly's Camel Book (Programming Perl) was
written by my officemate of the time, Daniel Faigin.He, along with my brother in law, Mark Biggar, were most influential in the early design of
Perl. They were also the only users at the time. Mark talked me out of using bc as a backend
expression processor, and into using normal, built in floating point operations, since they were
just being standardized by the IEEE (Institute of Electrical and Electronics Engineers). Relying on
that standard was one of the better decisions I ever made. Earlier scripting languages such as REXX
didn't have that option, and as a result they tend to run slower.As with a human fetus, the last several months of Perl's gestation did not produce any large
differences in the appearance of Perl. Rather, Perl simply put on some weight as it prepared for the
real world. I recognized that acceptance of Perl hinged on the ability of people to leverage what
they already knew, so I didn't release Perl until I'd written two translators: s2p
(sed to Perl) and a2p (awk to Perl).I made one major, incompatible change to Perl just before it was born. From the start, one of my
overriding design principles was to "optimize for the common case." I didn't coin this phase, of
course. I learned it from people like Dennis Ritchie, who realized that computers tend to assign
more values than they compare. This is why Dennis made = represent
assignment and == represent comparison in his C programming language.I'd made many such tradeoffs in designing Perl, but I realized that I'd violated the principle
in Perl's regular expression syntax. It used grep's notion of backslashing ordinary
characters to produce metacharacters, rather than egrep's notion of backslashing
metacharacters to produce ordinary characters.It turns out that you use the metacharacters much more frequently than you do the literal
characters, so it made sense to change Perl so that /(.*)/ defined a substring that could be
referenced later, while /\(.*\)/ matched a sequence inside literal parentheses.This change broke all of Dan Faigin's scripts. I think he's forgiven me by now, even if he won't
admit it.As you might expect, another decision at this time was whether to release Perl as free software.
This was essentially a no brainer. I'd already done most of my thinking about this topic earlier
when I released the rn and patch programs. Occasionally people ask me whether I was
surprised that Perl caught on, and then they're surprised when I say "no." But you have to remember
that I already had several open source projects under my belt, and had a pretty good notion that
anything I liked, other people might also like.But it wasn't as easy deciding to do an open source project back then. These days, you can
actually go to your company and make a case for releasing the source code. Back then, you had to
believe in it enough to take some risks.I knew that I didn't dare ask the company lawyers for permission, because they'd have
thought about it for something like six months, and then told me "no." This is despite the fact that
they wouldn't be interested in peddling it themselves. In the old days, a lot of free software was
released under the principle that it's much easier to ask forgiveness than to seek permission. I'm
glad things have changed - at least to the extent that the counterculture is acknowledged these
days, even if it's not quite accepted. Yet.But Perl was actually much more countercultural than you might think. It was intended to subvert
the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that
said that every tool should do only one thing and do that one thing well.The problem with that philosophy is that many of the tools available under Unix did not, in
fact, do things very well. They had arbitrary limits. They were slow. They were non-portable. They
were difficult to integrate via the shell because they had different ideas of data formats. They
worked okay as long as you did what was expected, but if you wanted to do something slightly
different, you had to write your own tool from scratch.So that's what I did. Perl is just another tool in the Unix toolbox. Perl does one thing, and it
does it well: it gets out of your face.I released Perl to the comp.sources.misc newsgroup in 1987, and that was the end of Perl
version 0.But Perl was also intended to subvert some attitudes in computer science. More on that
later.PERL 1
The Baby
Perl Tim O'Reilly
A Class Act: Larry Wall's boss at O'Reilly & Associates, Tim O'Reilly.Perl was born at an early age. I mean something specific by that.
Humans do not come from the womb with the ability to drive a stick shift. Neither did Perl. This
was
intentional. I've always been smart enough to realize how stupid I am, and one of the things I'm
stupid about is predicting how my programs will develop over time. So Perl was equipped to learn,
and have a long childhood.We value the maturing process in our own species, but for some reason we don't like it as much in
computer programs. In the absence of a handy Zeus, we like to think that computer programs should
spring fully formed from our own foreheads. We want to present the world with a fait
accompli. In modern terms, we want to build a cathedral.Now let me just say that I think cathedrals have gotten a bum rap lately. Open Source advocate
Eric Raymond has likened the commercial software development model to a cathedral, while he compares
free software development to a bazaar.Eric's heart is in the right place, but I think his metaphors are a little off. Most cathedrals
were built in plain view with lots of volunteer labor. And most of the bazaars I've seen have
produced little of lasting architectural value. Eric should have written about artists who insist on
having an unveiling when their sculpture or painting is finished. Somehow I can't imagine anyone
pulling a shroud off of a cathedral and saying, "Voila!"An open source programmer is more like a public mural painter. An artist may have some idea of
what he's about, but anyone walking by can make suggestions, or even help paint if the artist is
agreeable. If not, he can always go paint a better mural on the other side of the freeway if he
wants.Anyway, when Perl version 1 arrived in the world, it knew it was the new arrival, not the world.
It recognized that there are depths of wisdom in the world that have not yet been plumbed by
computer science, let alone by Perl. So Perl played the role of a baby, and grew. Various nurturing
individuals adopted Perl, and helped to raise it, because Perl was cute, and they became
irrationally attached to it.Besides, cute is cool. See penguins.
PERL 2
The Toddler
Theory is good, in moderation.
One of the ways Perl subverts computer science is by adopting theoretical axes without grinding
them. The theory of regular expressions is highly developed, but typical users just want to get
their work done. Perl 2 had a more powerful regular expression engine under the hood, but the idea
was to make things easier for the user, not harder.So, to effect this, I introduced many redundancies in regular expression syntax that have come
to be a large part of what nowadays are known as Perl 5 regular expressions, even when they're being
called from Java or Python. Yes, in Perl \d means the same thing as[0-9]. So what? I can say "digits" in English to mean 0 through 9, without
saying "0 through 9″ every time. Why not in Perl too?Moderation is good, in theory.
If you want to have a thriving open source project, then you must build a culture around it; and
to build a culture, you must encourage cultural identity. That is, you must encourage a certain
amount of immoderation. Call it "religion" if you will, though I think religion has gotten a bum rap
too. After all, immoderation on behalf of a good cause is how saints are made.Hence, we were immoderately evangelical about Perl. In particular, because we wanted to build a
new culture, we had to pull people in from many different cultures, which oddly enough meant we had
to avoid being classified as a culture ourselves for a little while.Consequently, I refused to create a newsgroup for Perl for a long time because I wanted people
to talk about how to solve their shell problems in Perl, and I didn't want Perl to become ghettoized
right off the bat.So when people would ask in the shell newsgroups how to do something, we could give them the
"how to do it in Perl" answer without enduring chants of, "Take it to the Perl newsgroup!" In this
way, we subverted Usenet.(Later on, and for similar cross-cultural reasons, I started scanning my entire Usenet feed for
Perl references - I basically invented my own form of Kibology (http://www.kibo.com/) about the
same time as Kibo came up with his religion of the Internet, but he got to name it. Drat. Perhaps
it's just as well. "Wallogy" just doesn't quite have the right ring to it, does it?)Anyway, I did some sneaky things to make sure Perl developed a healthy culture. While we took
ourselves very seriously in some ways, we also tried to laugh at ourselves occasionally. Perl not
only stands for the Practical Extraction and Report Language, but it also stands for the
Pathologically Eclectic Rubbish Lister.Anyone who can't laugh at himself is not taking life seriously enough.
PERL 3
The Child
Perl Larry Wall
Striking A Subversive Pose: Larry Wall.I remember that when I was a child, I thought there was nothing I couldn't do if I tried hard
enough.Perl 3 was when Perl started trying harder. The early design goal of optimizing for the common
case was okay as far as it went, but it didn't say anything about what to do for the uncommon
case. One common solution is to say you're not going to do anything about it, and in fact, that's
what I once said about binary data, based on the precedent of many Unix text processing tools that
could not handle binary data. When Perl 2 was out, I said to myself, "Perl is just a text processing
language. If I make Perl handle binary data, who knows where it will stop?"Well, Perl now handles binary data, and who knows where it will stop? That's the rub - people
don't want Perl to quit just because the going gets tough. So the earlier design goal evolved into
our current goal: "Easy things should be easy, and hard things should be possible." Sure, Perl is
mostly a text processing language, but every time we add the ability to do something else, we make a
way to solve gobs of problems that are 90 percent text processing and 10 percent something else.Another way Perl 3 tried harder was by adopting the GNU General Public License, known as the
GPL. (The copyright statement on the first two versions was woefully inadequate.) More on the GPL
later…I've been talking about the advances that marked major versions, but you should realize that
most of the development of Perl was not at the version boundaries. Development was continuous between
major versions, and the typical patch file would contain bug fixes mixed together with
enhancements.It's a sign of the robustness of the design of Perl that people didn't rebel at using a
development version for all their work. In large part, this was because Perl has always had an
extensive set of regression tests, and users could be confident that, even if they installed a new
development version, at least the functionality tested by the regression tests was guaranteed not to
break. And that was good enough for many, because most Perl scripts don't use the fancy stuff. I
take it as a compliment that many people still use Perl 4, because that means I put a lot of the
right stuff into Perl early.PERL 4
The Preteen
It's an odd thing, but nothing much changed between Perl 3 and Perl 4. Or, I should say, between
the end of Perl 3 and the beginning of Perl 4. Just as it's hard to say when a child becomes a
preteen, the transition from Perl 3 to Perl 4 was rather arbitrary. What really happened was that we
wrote the first edition of the Camel Book, and then changed the version number on Perl so that we
could say that it documented version 4.But there is actually a qualitative difference between how a child thinks and how a preteen
thinks. There comes a time at about the age of ten when suddenly a child doesn't just think about
things, but starts thinking about thinking about things. So I guess you could say that producing the
Camel Book was our version of thinking about thinking about Perl. Certainly it helped a lot of
people understand more about how I think about Perl. Or at least, about camels.People keep asking me, "Why a camel?" And I have a standard litany of answers. (I'm allowed to
give more than one answer, of course, because of the Perl Slogan: "There's More Than One Way To Do
It!") But the fact is, there's no single left-brained answer. If I'd wanted a left-brained animal on
my book, it would have been an oyster. But I wanted a right-brained animal, and the camel was it for
various reasons:A camel is ugly but useful; it may stink, and it may spit, but it'll get you where you're
going.A camel is self sufficient in a dry place. You don't need to take along food and water for your
camel. You don't need a toolkit to keep your camel going. You don't need tracks or roadways, or pipes
to other processes.A camel is a horse designed by a committee. Or at least it looks like one. But appearances can
be deceiving, and a camel is well adapted to its ecological niche. So is Perl. Despite the fact that
it is designed by a committee.Camels have vague Biblical associations with caravans and treasure, such as Pearls of Great
Price, not to mention Pearls of Wisdom, and not to mention Pearls before Swine. Or the Pearly
Gates.Finally, no animal has a better attitude than a camel. Presuming you're looking for an animal
with an attitude.Frankly, I wanted a camel
because it was countercultural. Camels aren't modern, therefore they have to be either premodern or
post-modern. Maybe even both. Fortunately our postmodern culture is based on the happy contradiction
that any decent culture must be countercultural. If you can't deconstruct your own program, you
aren't really with the program.Another way to look at the Camel Book is that it was a kind of bar mitzvah for Perl. Perl
wasn't a real grown up language before it had a book. I remember being shocked the first time I was
told that half the desks on Wall Street had a Perl book on them. I shouldn't have been. The book is
what legitimized Perl in the eyes of many.Another thing that helped legitimize Perl was the addition of the Artistic License to stand
beside the GPL. Perl 3 used only the GPL, but I found that this didn't do quite what I wanted. I
wanted Perl to be used, and the GPL was preventing people from using Perl. Not that I dislike the
GPL myself - it provides a set of assurances that many hackers find comforting. But business people
needed a different set of assurances, and so I wrote the Artistic License to reassure them.The really brilliant part was that I didn't require people to state which license they were
distributing under, so nobody had to publicly commit to one or the other. In sociological terms,
nobody had to lose face, or cause anyone else to lose face. Most everyone chose to read whichever
license they preferred, and to ignore the other. That's how Perl used psychology to subvert the
license wars which, as you may or may not be aware, are still going on. Ho hum.Yet another thing that helped legitimize Perl was that there was a long period of stability for
Perl 4, patch level 36. The primary cause of this was that I abandoned Perl 4 to work on Perl 5.PERL 5
The Adolescent
Shortly after a preteen starts to think about thinking, the raging hormones enter the scene,
causing a total brain meltdown and, hopefully, eventual reconstruction.For Perl, the meltdown happened because I decided to follow the rule: "Plan to throw away your
prototype, because you will anyway." Perl 5 was nearly a total reorganization. I have in times past
claimed that it was a total rewrite, but that's a bit of a stretch, since I did, in fact, evolve
Perl 4′s runtime system into Perl 5′s. (Though if you compared them, you'd see almost nothing in
common.) The compiler, though, was a total rewrite.You only get one shot at raising your kids. Similarly, I figured that this was my first and last
chance to raise Perl right. So I thought of all the buzzwords I wanted Perl to be compliant with,
and heroically set out to make it so. By and large, I think I succeeded. As with the typical
adolescent, Perl 5 is significantly, um, sexier than Perl 4.Among other things, Perl became more readable and more extensible. It also became more
unmanageable, not because it was a bad design, but simply because it was growing up, and had too
many interests of its own. With Perl 5, I began to realize something I was learning with my kids: I
had to let them learn to make their own way in the world. Not that I don't still give them all a lot
of advice. But the process of letting go is gradual; if you let go all of a sudden, they tend to
land hard.One manifestation of this was that I had to learn to delegate most of the work of Perl
development and documentation to other people. We've developed a system of "pumpkin holders" who are
responsible for the various aspects of Perl development and maintenance.But that's not good enough. I also realized that, while the open source community is good at
some things, it's lousy at other things. If Perl was to be useful to as many people as possible, I
had to learn to delegate some things to the business community as well. In particular, we really
needed to have a commercially packaged version of Perl for the Windows folks, because many of them
were (and still are) clueless about open source. It's almost like we're doing Windows users a favor
by charging them money for something they could get for free, because they get confused otherwise.
(This is Linux Magazine, so I can get away with saying this, right?)But beyond that, I was looking around for someone with some business sense to cooperate with,
when lo and behold I found out that Tim O'Reilly (as in O'Reilly & Associates, my publisher) was
having the same ideas about establishing a more symbiotic relationship with the open source
community.Tim is a class act. He's also a bit of a rarity: a brilliant (but not greedy) entrepreneur. His
slogan is "Interesting work for interesting people." We hit it off right away, and Tim offered to
pay me to take care of Perl, because anything that is good for Perl is good for O'Reilly. And from
my perspective, lots of what O'Reilly does happens to be good for Perl.But it goes beyond even that.
Tim and I both felt that there was something larger than Perl afoot. Free software has been
around in various forms as long as there has been software, but something new was beginning to
happen, something countercultural to the counterculture.The various open source projects were starting to realize that, hey, we aren't just a bunch of
separate projects, but we have a lot in common. We don't have a bunch of separate open source
movements here. We have a single Open Source movement - albeit one with lots of diversity of
opinion as to how best to move the bandwagon forward to where more people can hop on.In short, our counterculture was beginning to count.
When Tim hired me on three years ago, that was very much on our minds. We were preaching it a
year before Netscape released the Mozilla browser code under an open source license.Of course, both Linux folks and Perl folks recognize that Linux and Perl were here long before
the bandwagon, and will (hopefully) be here long after the bandwagon has broken an axle (or more
likely, has been hijacked). But in the meantime, both Linux and Perl have been growing up, and they
are now mature enough to understand the utility of a bandwagon in inciting a revolution.Frankly, I'm glad that Perl isn't competing against Linux. Quite the contrary - now that both
Perl and Linux are growing up, Perl is going out with Linux. I suppose that, as the father of Perl,
this should make me nervous, but it doesn't. They have my blessing. May they prosper. May they have
many happy years together. May they be fruitful and multiply. And dominate the world.Larry Wall is the creator of Perl. He works at O'Reilly & Associates and can be reached at
[email protected].
Society
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
Quotes
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
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
History:
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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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-Month : How 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-2021 by Softpanorama Society. www.softpanorama.org 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 |
Disclaimer:
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 updated: March 12, 2019
