Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is not recommended :-)

Larry Wall Articles and Interviews

Perl has an interesting historical path: from a language for elite system administrators to mass Web development  language and back to the tool for elite system administrators.

NEWS CONTENTS

• 190921 : Programming Perl ( Programming Perl, )

Old News ;-)

2004

Programming Perl

The first thing you notice about the Perl book is the camel. The hardy beast is standing nonchalantly and grinning ever so slyly. This is not just any old desert dwelling dromedary. This is a camel with an attitude. And that's the way Perl creator and Programming Perl co-author Larry Wall wanted it to be. Wall likens the camel-with-an-attitude to his free Practical Extraction and Report Language -- Perl. ``It's ugly but useful,'' he says.

Since 1986 when Wall first developed Perl -- an interpreted data reduction language -- to solve a problem that awk could not handle, the language has grown to include a variety of built-in functions, associative arrays, regular expression handling, object-oriented features, and some of the most useful bits of several other programming languages. It is now a popular tool for system administrators and programmers who want to develop code to manipulate strings, files, and processes. Recently it has become the language of choice for programming interactive applications on the World Wide Web.

As Wall has developed and improved Perl, utility has always been a higher priority than theoretical elegance. He criticizes other modern languages that have been developed by people who ``try to define their languages such that you can't do anything bad.'' As a result, he says, ``the act of programming becomes joyless.'' But, not so with Perl. ``The thing that people really like about Perl is that they have fun.'' This is perhaps why Perl has become so popular.

With the help of volunteers from around the world, Wall put the finishing touches on Perl version 5 in mid-October. Perl 5 introduces not only new features -- including simple object oriented ideas and a more readable syntax -- but also a new philosophy. Wall explains that as Perl developed, new features were continuously added, causing the language to change constantly. ``With Perl 5 I've sort of come to the realization that we need to actually stabilize the language itself and provide an official way of extending it.'' Therefore, Perl 5 includes mechanisms that allow programmers to add reusable modules to extend the Perl language. The object-oriented features were necessary to add this extensibility. In addition, they allow Perl and C++ to be easily used within the same program.

As with versions 1 through 4, the new features of version 5 have been designed so that they can be learned incrementally. Unlike other computer languages ``where you have to practically know the whole language before you can use any of it usefully,'' Wall says that new Perl programmers can learn the subset of Perl they need to solve a particular problem without having to learn the rest of the language. Because of this property, Wall suggests Perl might be a good introductory language for beginning computer science students.

While Wall hopes the new philosophy will help Perl will remain stable for a while, he predicts the continued development of new programming languages, particularly those that make programming accessible to ordinary people. ``I think to the extent that ordinary people are going to be programming, they're not going to be programming in C++ -- because you practically have to have a degree in computer science to do that.'' However, he says that simply adding more English syntax to programming languages is not likely to make programming easier. ``When they first came out with Cobol they said `this is a very English-like language,' but I think they confused the process of just throwing a few English phrases into the language and ending their sentences with periods with some of the deeper aspects of natural language. Our computer languages will start functioning more and more like natural languages, but there is a large amount of misunderstanding in the current computer science community about how natural languages actually work.''

And Wall, a linguist by training, is certainly qualified to talk about natural languages. In fact, he says his background in linguistics and his observations about natural language have influenced his programming language development work. ``Linguists realize the limitations of language and realize that when you are trying to solve a problem in a natural language you sort of whack at it until you get the thing into the shape that you want it to be,'' he explains. ``I think people program similarly. They rough things out and hack things in. I think a lot of computer scientists believe programmers are omniscient and can figure out before hand all the design criteria, get all the ducks in a row -- and then magically the program just writes itself because it will be obvious. I don't think real people think that way. I don't think they talk that way, or write that way.''

Wall also credits his linguistic background for his views on ambiguity in programming languages. ``My view on local ambiguity is that it's okay because people deal with it well. On the level of phrases and sentences people are very good at figuring out exactly what's going on -- so I think a computer language ought to be allowed to have ambiguity at that level.'' He adds that humans use various natural language clues to disambiguate sentences. In Perl, special characters serve to disambiguate variable types. For example, variable names that begin with a $ refer to singular variables (scalars) while variable names that begin with a @ or a % refer to plural variables (arrays). As with English where a member of a group is described with singular words, an array element is referenced with the singular $.

In addition, Wall has observed that unlike most computer languages, ``natural languages don't have any `theoretical axes' to grind.'' He adds, ``Natural languages typically don't have any shame in borrowing things from other languages, unless of course you're French.'' He pauses for a moment and looks through his notes for a statement he likes so much he has it written down: ``For most people the perceived usefulness of a computer language is inversely proportional to the number of theoretical axes the language intends to grind.''

But while Wall intends Perl to be useful, he does not intend it to replace other programming languages that are also useful for solving certain types of problems. ``I've tried not to reinvent any other language with Perl. So if you see some particular problem that C is good at, I've not tried to make Perl that good in that realm. For low level bit diddling, C is still going to be better. For very large, difficult to manage projects, C++ is going to better. For just starting and stopping processes, shells are going to be better. These are all sort of LegoLand type problems. The place where Perl excels is not where you want Legos, but where you want glue -- where you don't want Lincoln Logs so much as you want pipe cleaners. Its sort of officially a chewing gum and baling wire language.''

In fact, Wall says, ``The Perl slogan is, `There is more than one way to do it.' People have often taken that to mean that there is more than one way to do it within Perl. But I apply the same thing outside of Perl also. I know a lot of people use Perl for what it's useful for. But I don't expect them to take themselves off to a monastery and just write Perl scripts all day.''

Wall says Perl's biggest competitors -- REXX, Tcl, Python, and Scheme -- are useful for similar things that Perl is useful for. Although he prefers Perl because of it's efficiency, language structure, and lack of theoretical axes, Wall says he will not engage in language wars. ``I have a firm policy against making enemies,'' he states.

Despite his training as a linguist, Wall turned to computer science because of its more lucrative job prospects. However, this was not a major career change, as Wall had spent three of his eight years as an undergraduate at Seattle Pacific University working at the school's computer center. And although he met his first computer (a PDP-11) at Seattle Pacific, Wall began programming in 1972 when his high school got a programmable calculator. ``You could program 120 steps into [it] and I very nearly taught it to play tic-tac-toe -- but I just couldn't get that squeezed down to 120 steps.''

While at Seattle Pacific, Wall says he ``was vaguely acquainted with Bill Gates.'' Wall explains, ``[Gates] was still programming for the experimental college at the University of Washington and they had been jacking up the computer rates on him. So he came over and was using our little PDP 11 because we'd give him cheaper computer time.''

Since graduating from Seattle Pacific, Wall attended graduate school at U.C. Berkeley and U.C.L.A., and worked at Unisys and the Jet Propulsion Laboratory. In his spare time he developed several free UNIX programs, including the rn news reader, metaconfig, and Perl. He currently holds the position of Senior Scientist (``oldest hacker'') at NetLabs and resides in Mountain View, California with his wife, Gloria, and their four children.

Wall says there have been a number of people who have inspired him or served as role models throughout his life. Among them are 19th century writer George Macdonald, his grandmother who earned her Ph.D. in comparative literature when she was 77, his parents, and his wife.

Wall describes himself as ``one of these people who's been interested in too many things.'' It may be his diverse sets of interests that have led him to take on the development of Perl and other programs. Or perhaps it is what he refers to in Programming Perl as the ``three great virtues of a programmer: laziness, impatience, and hubris.'' But Wall says there are three things that have motivated him to invest the enormous amount of time and effort necessary to keep improving Perl. Besides a simple desire to help people and to create something with some lasting significance, Wall says he is motivated by his notion of creativity and how he believes God views the world as a work of art. ``If its okay for [God] to make certain kinds of amoral decisions than it's okay for us to be artists also and sling some paint around and make some pretty pictures. I think that I just feel deep down that its fitting in with the overall scheme of things.'' He pauses before adding, ``No pun intended.''

Copyright 1994 by Lorrie Cranor

2002

Slashdot Larry Wall On Perl, Religion, and...

3) Structured programming and perl
by slashnot007

The reason I like perl is it is not a structured programming language. In my work I find it is 50% a get the job done parsing language and 25% sequencer of programs and deamons and 25% major ojbect oriented programming effort often a cgi.

Thus I worry that perl has Python-envy. I've tried to use python several times but always go back to perl. The reason is my daily need for a parser dominates my choice of language and maintains my fluency, since I dont want to have to be fluent in both, perl becomes my language of choice for advanced tasks too, even though python might be better for strcutrued programming.

So my question is, is perl6 making make perl a structued language like python? Would it be a good idea if perl did not develop any further for fear of becoming too complicated and thus disorganized? (witness the evolution of java from clean slate to giant mess with intricate redundant libraries half of which are deprecated).

A:

Er, what do you mean by "structured"? 25 years ago all of these languages would have been considered "structured", in the sense that a block generally has only one entrance point. (There were also people who thought that a block should only have one exit. Thankfully these folks did not prevail, since functions representing decision trees often have one entry but multiple exit points.)

But you obviously mean "structured" in a different sense, or perhaps several different senses. Syntax is structure, and different languages have different syntax, but I don't think that's what you mean.

I'll assume you mean "structured" the way a grade school teacher means it, as in "structured play time", as opposed to "free play time". Python's slogan is "There's only one obvious way to do it." That's fine from the computer's viewpoint, but kinda sucks from the human viewpoint. "You can play any game you like, as long as it was organized by the teacher."

Java was, in that sense, much less structured than Python, I think. That's part of the reason for Java's success, but it came at a price. One of the problems with Java is that they swept a bit too much of the innate complexity of life under the carpet of the libraries. And so now they've had to replace the carpets several times.

So, yes, Java started with a "clean slate", but it was a rather undersized slate, methinks. But as for "structured play time" in Java, the structure has been imposed more by cultural norms than by the language itself.

As for Perl, it has never been "structured" in that sense, though it has always been structured in the sense that you can create as much structure as you like. The whole point is that the structure is optional, not imposed externally. If you're playing with your schoolmates at recess, you can always choose to organize a football game, but the teacher isn't making you do that.

Playing football is like programming in the large. You have to agree on a lot of rules to do it with other people. Perl5 doesn't make it terribly easy to agree on a set of rules, and we hope to make that easier in Perl6. You have to have discipline to do programming in the large, but you'll choose the discipline by turning up the big discipline knob yourself, not by having someone else turn it up for you. Perl6 will give you the big knob.

I am philosophically opposed to turning up the knob for you, because I don't know how fast you want it turned up. (Perl6 will turn it up for you a little by default--if you write a module or class, it'll automatically default to a stricter mode than it uses for your main program.) But the reason I don't like doing it for you is that you know how fast you want to learn, and I don't. As Gildor says, you haven't told me enough about yourself for me to give you advice. If I don't know how hard you can paddle, I can't tell you how big of a wave to try to catch. We all have to start with the small waves.

We find the same problem in teaching reading to kids. Some people shout "Whole language!" while others shout "Phonics!" Well, guess what, they're both oversimplifying. You have to learn some phonics, and then you learn some larger bits based on that, and some larger bits based on that, and eventually you find that you're intuiting whole language. The whole language folks fall into what I call the "Expert Fallacy". You look at how experts do something, and assume that's how everyone should do it. There are some people who are natural readers. They naturally figure out the bits and pieces themselves. But if you try and teach everyone that way, half your kids never figure out the phonics.

Programming is the same way. Language designers tend to look at how experts program and then think that everyone ought to learn to program that way from the start. That's a bit like expecting a new surfer to do well on 40 foot waves. Some will make it, but most will wipe out.

Perl is designed to help people learn the bits of programming they need right now without forcing them to learn the techniques they aren't ready for. But when they are ready for them, Perl tries to be there too. We just don't tell the beginners that the speedometer on their golf cart wraps around several times.

5) perl vs other languages by larry bagina Whenever perl pops up in slashdot, there are plenty of language zealots claiming perl is obsolete and you should really be using php or ruby or python instead. What are your thoughts on these other scripting languages? What do you like about them, what do you dislike?

I also liked Ruby's unary splat operator, so I borrowed it for Perl6.

The main problem I see with Ruby is that the Principle of Least Surprise can lead you astray, as it did with implicit lexical scoping. The question is, whose surprise are you pessimizing? Experts are surprised by different things than beginners. People who are trying to grow small programs into large programs are surprised by different things than people who design their programs large to begin with.

For instance, I think it's a violation of the Beginner's Principle of Least Surprise to make everything an object. To a beginner, a number is just a number. A string is a string. They may well be objects as far as the computer is concerned, and it's even fine for experts to treat them as objects. But premature OO is a speed bump in the novice's onramp.

I confess, I have a soft spot in my heart for inside-out languages like PHP. The first real compiler I ever wrote was for a sort of text-processing macro language in which the commands were embedded in the data. This is part of a more general class of programming languages in which a peculiar form of processing is assumed by default, such as the pattern/action syntax of awk that assumes an invisible outer loop.

Perl can do that, but it's not the default. I think languages like awk and PHP hobble themselves in the long run by attaching themselves to a particular ecological niche, particularly when a generalist like Perl can effectively occupy the same niche. So I've never felt tempted to even try PHP. I'd only be speaking second-hand if I said that PHP has some serious namespace and extension mechanism issues. So I won't say that. :-)

Python is cool to look at small bits of, but I think the "outline" syntax breaks down with larger chunks of code. I'm with Aristotle on the structure of discourse--a story should have a beginning, and middle, and an end. So should blocks.

There's something to be said for forcing everyone to code in the same style, but that's not the Perl Way. At least, it's not the default Perl Way. But all is fair if you predeclare. It's perfectly fine for you to import a pragmatic module that enforces a certain style policy. It's even fine if your company forces you to import that pragma. Of course, if you want real programming discipline, I'd suggest you use Damian's Klingon module...

2001 LWN interview Larry Wall

... ... ....

Amazon.com Interview Larry Wall The father of Perl talks about XML, Unicode, the Win32 port, and the philosophy behind the language

Larry Wall, the father of Perl, stopped by Amazon.com's Seattle offices to field questions about XML support, Perl's Unicode implementation, the Win32 Perl port, the ActiveState visual Perl debugger, and the guiding philosophy behind the language.

Amazon.com's interviewers were Douglas Beaver, Jennifer Buckendorff, Alex Edelman, Tom Mace, Cristina Vaamonde, and Alex Yan. Wall was joined by Gina Blaber from O'Reilly Software.

---

Amazon.com: Thanks for taking the time to visit Amazon.com. It's no secret that we're a big Perl shop, and you've got a lot of devoted fans here to grill you. So what brings you to Seattle?

Larry Wall: I came to give a talk at the XML conference. The basic gist of what I'll be saying is that Perl has always been pretty much the language of choice for text processing, but what's been happening in the last 10 years is that the definition of text has been changing out from under Perl. It used to be that it was just ASCII, and then we got these various national character sets that were eight-bit, and Perl supported those rather easily. But with Unicode, and now with XML, we have definitions of wide characters that are pretty much universal and definitions of structured text that look like they will become pretty universal. So Perl really needs to support those. That's my project this year: making sure that happens.

Amazon.com: Do you see a clear implementation, or is this still at the exploratory stage?

Wall: It's actually pretty clear. As far as Unicode support goes, Perl will, at least for the initial cut, take Plan9's Unicode implementation. Essentially, they just said, well, that most of our interfaces to the real world are still going to be ASCII with a little bit of Unicode thrown in. It makes a whole lot of sense if our internal representation is not wide characters but actually a thing called UTF-8, which is a flexible representation, so ASCII remains single eight-bit characters and then the higher-order characters become longer sequences of bytes. So Perl's initial implementation of Unicode will do the same thing. Which makes a lot of sense, actually, in a text-processing language that is dealing mostly with flexible text. Regular expressions really don't care what the boundaries are, if they come on even or odd boundaries. It may be that down the road a ways, there may be some architectures that are natively wide characters, where it would make sense to have a Perl that uses wide characters natively, internally, but I'll cross that bridge when I get to it.

Amazon.com: Is the syntax for regular expressions clear in a Unicode implementation?

Wall: Yeah, it should be, pretty much... I mean, the only thing that's strange about the implementation of regular expressions is that the character classes suddenly get a lot bigger, potentially. If you're just looking for eight-bit characters and you have a table inside that has 256 entries, you just do a direct look-up. You can't really afford to do that if there are potentially 65,000. But there are ways of having multiple-level tables to deal with that sort of thing. As far as representation goes, the representation of the Perl script itself will be UTF-8, so there are already ways of specifying in the text of your program if you've got a higher character. You know, how that looks to the programmer depends on whether you've got a UTF-8-aware editor or a Unicode-aware editor. If you've got an editor that spits out 16-bit Unicodes, then what we can do is use Perl's facility called "source-filtering" so we'll recognize that if it's a pure Unicode file, we'll just translate it to UTF-8 coming in. But it should all be pretty straightforward. There are several goals to putting Unicode support into Perl. First of all, old scripts must not break. That is, they continue to work exactly the way they have if you don't change them. Also, old scripts must be very easily convertible to scripts that will deal with Unicode, hopefully just by a single declaration of a file that says "use UTF-8" or something like that. And then the same Perl code that you have right now will just magically start working with the UTF-8 code. There are a few little glitches in there having to do with how pack and unpack work. And if you actually want to match against specific Unicode characters, then you'd have to, of course, modify your program. But by and large, you should be able to make it very easy to make the transition. And of course, as additional goals, you'd like to keep Perl running as fast as, if not faster than, it's already running, and you'd like it to still stay as intuitive as possible. That's basically the Unicode story.

Amazon.com: Do you see Perl being part of the XML standard or simply being in friendly cohabitation?

Wall: Perl has always lived in the interstices. It's too fluid an entity to be stapled down to anything so solid as a standard. It's not that I don't think standards are valuable--I think they're very valuable--but Perl's abilities complement things that are legalistic. Perl sort of goes the other way and is a little bit libertarian. And so if you want to look at the things that Perl works best at, it's actually the places in the world that are most restricted in various ways, and then Perl gives you a way to get from here to there. You expect a glue language to glue things together, not just to glue glue to glue. You glue it to other interesting things that aren't like glue. People ask me if Perl will ever be standardized, and I say that people are free to do whatever they want--after I'm dead.

Amazon.com: No standard as long as you're with us?

Wall: Well, you know, it's unlikely. I'm not going to rule it out entirely. You know, I might live a long time! But I don't see a need for it yet. One reason we don't need a standard for it yet is that we've explicitly embraced the idea that the implementation is the standard. It's very important to us that there be only one implementation of Perl. One of the fallacies of language design is that the specification is good enough. You know, that happened to Ada. It's happening to Java. And no matter how good your specification is, you get divergence, which we're starting to see in the split in the Java world. In the Perl world we started to see a split between the Windows version and the Unix version last August after the first Perl conference. We jumped on that and got all the principals in the same room and knocked their heads together and said, "We're going to have one Perl here."

Amazon.com: It wasn't that painful? They were willing?

Wall: Yes, they were willing. And so version 5.005 of Perl will be a single-source code, basically.

Amazon.com: Can you describe how you keep on top of the implementations and enforce the uniformity across all the platforms?

Wall: I'm not sure "enforce" is quite the right word there. There is a mailing list called perl5-porters, and I rely on them heavily to do the porting of their architectures. And they actually do much more than porting. They're the chief forum for discussion of changes to the language and how to reconcile semantic differences between various operating systems. It's interesting how the governance of the Perl community has evolved over time. It has actually turned out to be somewhat like the United States federal government. It used to be, way back in the Dark Ages, that I just ran the whole thing. I was Mr. Perl--judge, jury, and executioner. But these days the perl5-porters mailing list serves as the legislature. And we have an executive--which is not me, actually. It's whoever is currently the integration manager, essentially--the patch manager. We call that person the Patch Pumpkin Holder. That's the executive, and so that title moves from person to person, and that leaves me to be the Supreme Court. So I get to rule on what's constitutional or not. In fact, there are three or four appeals outstanding that I have not ruled on yet. After I'm done with this XML conference, I will be taking under consideration some of the things that people have put under my nose.

Amazon.com: Is the Win32 port particularly problematic?

Wall: Well, it's been problematic in that there was the source-code divergence, which we have now converged. For the most part, though, the semantics of what will or won't work cross-platform are pretty obvious. You're just not going to get "fork()" to work on Windows unless you happen to be in the Posix universe -- in which case nothing else works. But Windows itself has not really been a big problem that way. I mean, there are some cultural differences, sure. And one of the things I had to rule on lately was how we deal with line endings that appear not to be from our system. At the moment, with the current Perl that's out there, if you're on a Unix system and it sees a line ending with a line feed like a Windows system, it blows up and says, "You didn't convert the script to Unix format." That's really kind of antisocial, because, you know, a lot more people are using remote NFS or Samba file-sharing setups, and the same file needs to run on both Windows and on Unix systems, not to mention on Macs. So I decreed that, essentially, any Perl ought to accept any line ending consistently. It really ought to do the right thing, whatever the right thing is. There are some arguments against doing that, but they're weak, so that's why I made that rule.

Gina Blaber, O'Reilly Software: Also, every two weeks or so there's a Win32/Unix teleconference. Larry's in on it, and I'm in on it, and Dick Hardt in Vancouver, and a couple of people from the U.K. and Germany. So basically there are a number of people who are more from the Unix Perl world, and then Dick Hardt, who is from more the Win32 Perl world. We started doing these teleconferences back in September to make sure Win32 Perl really does get integrated back into core Unix Perl. It meant putting aside all the cultural and philosophical differences and just getting down to technical stuff.

Wall: I'd say that we could not have done this without the support from O'Reilly. We used to have the commercial software community, and then the freeware community came along, which was sort of an overreaction, in some ways, to the commercial community. There's always a kind of natural tension between the two. But at the current time, a lot of people are trying to find models where the commercial and freeware communities can cooperate. That's why I hired on with O'Reilly two years ago--seems like just yesterday--because Tim O'Reilly was interested in looking for those cooperative symbiotic models. Before that, the commercial people looked at the freeware people and the freeware people looked at the commercial people and each thought the other was a parasite.

Amazon.com: They were both right!

Wall: Yeah. But if it's mutual parasitism, that's symbiosis! So it's been encouraging to me to actually see this working out in practice, with the way that O'Reilly can bring their strengths to helping the freeware community get its act together. This recent Netscape announcement [of the publication of Navigator's source code] is sort of... One has mixed feelings about it, because we've been preaching this freeware, cooperative gospel for a couple of years now, and nobody has much been listening. Now Netscape comes out with one little announcement, and suddenly everybody wants to know, What's this freeware thing? But that's good, and it's healthy, and anything that fosters more discussion and that frees up more people to pursue different models, I think that's great. When I first started out, you really couldn't do that. You had to go to your company and say, "Can I distribute such-and-so?" and they would send it to their lawyers, and their lawyers would sit on it for six months, and then they'd come back and say, "No." And then you'd say to the company, "Well, are you going to sell it?" And they'd say, "No. We're just going to put it on a shelf, because we might sell it someday." Which is for the birds, you know? So the only choice I had back then was just not to ask. It's better to ask forgiveness than permission [Laughs]. It also helps to be the sort of person that doesn't make enemies, because then nobody wants to get you in trouble for it, especially if you're in the good graces of your immediate boss. As long as they know what you're doing, then you're probably fine. That's the way it was back then, the only way you could do the freeware.

Amazon.com: "Back then" was when?

Wall: Well, 10 to 15 years ago. Now, with the Netscape announcement and other publicity that freeware is getting, it's now possible for someone to come to their manager and actually make a case that the best model to release some particular piece of software under is a freeware model, that there are other ways to make money on freeware than just by selling the freeware.

Amazon.com: How has this worked with O'Reilly?

Wall: O'Reilly is sort of a one-of-a-kind publisher, and I guess maybe I'm sort of a one-of-a-kind guy, too. But I did an awful lot of really careful work in introducing people to the notion of commercial cooperation with the free model. Like I say, I'm not the sort of person who makes enemies, and part of that is realizing what things I might say that people would take out of context and want to fight over, when it's something I'm really not interested in fighting over. So I eased into it carefully, and in a sense I'm almost grateful that Netscape waited as long as they did to make their announcement, because now the world is readier for some of these concepts. In April we're going to be having a Open Source summit at O'Reilly's headquarters in Palo Alto [California]. Linus [Torvalds] and various other freeware authors will be there. You know, we really don't have much of a set plan for what we're going to do. We're just going to get together and see what happens. And that's not to say that every freeware project has to use the same model. Different kinds of programs need different kinds of models. Perl, being a language as well as a computer program, needs a certain kind of design oversight that something like Apache doesn't necessarily need. So Apache can get away with an oligarchy; Perl needs more of a monarchy.

Amazon.com: Says the monarch! [Laughter] How about the state of tools on the Win32 side? Windows programmers are used to having groovy visual IDEs and all of that. Are you involved at all with people developing such tools for Perl programming, in particular the visual debugger?

Wall: If I had thought you were interested in that, I would have brought it [the ActiveState visual Perl debugger] to show it off to you! Yeah, it's pretty slick. I think that particularly in the Windows space is a good place for people who want to build useful tools that, you know... Windows users are not used to dealing with freeware, and they'd almost rather buy something, something on a CD that they can download with a credit-card number or whatever. And so it's almost doing them a favor to charge money for a tool like that. [Laughter] My involvement with the debugger has been only in a controlling role at this point. But the visual debugger that ActiveState has is actually based on the regular symbolic debugger, the line-oriented debugger, which is written in Perl. But what they've done is, instead of talking to the command line, they've just opened up a connection to some operating-system objects so you get these snazzy windows. You can move around and redefine what to do and have all the bells and whistles of a visual debugger. The fact that it's running a Perl script which is running a Perl script is sort of transparent.

Amazon.com: Do you see the Unix side of the world working on something like that?

Wall: I think that would be cool. I don't think I have time to do that. You want to do it?

Amazon.com: What about compilers? Are you involved at all in compiler development?

Wall: Not a whole lot. I've played with it. Malcolm Beattie has been doing that, and the compiler will be a part of version 5.005. I actually smile when I say "compiler," because Perl has always had a compiler--it just compiles down into an internal form and then interprets from that. What people mean by compiler, though, is a back end that will spit out C, which you can compile down to machine language.

Amazon.com: Do you think Perl is going to become a standard administration language for Microsoft Windows NT? Something that it's really never had?

Wall: I think it's well-positioned for that to happen, yeah. But Basic is pretty religious at Microsoft. We are officially not competing with them.

Amazon.com: What do you think about Perl as a beginner or occasional language?

Wall: One of the ways in which Perl is like natural language is that many different levels of competence are acceptable. We don't expect a 5-year-old to speak with the same diction as a 50-year-old. So why do we expect computer programmers to learn an entire language before they start doing anything? So Perl is specifically designed so that you can use whatever subset of it you know is going to be useful.

Amazon.com: Do you have any fantasies about where you want the language to go?

Wall: I'm kind of thinking that Perl might stick at version 5 like Unix did. In a sense, there have really only been two versions of Perl. Perl versions 1 through 4 were all sort of just an evolutionary path. At the end of Perl 4, I realized it was time to scrap the prototype and rewrite it. So Perl 5 is really pretty near a total rewrite. And at that point I realized it was both my first and last chance to do it right, so I put a lot of effort into defining an architecture that would be extensible and scalable and all the good buzzwords. Maybe even respectable. That was a big deal, and I don't really want to go through it again anytime soon. When Perl 2 was out there, it was just a text-processing language. It didn't handle binary data. And I said, you know, if I make Perl handle binary data, who knows where it's going to stop? Well, Perl version 3 handled all binary data, and who knows where it's going to stop? But the reason I decided to do that was, I realized both a specific thing and a general principle from it. The specific thing was that there are a lot of problems out there that are 95 percent text and 5 percent binary data. And if you make it merely possible to deal with binary data, not necessary even easy, then you increase your potential problem domain by more than twice as much. And the general principle is sort of the secondary Perl slogan. The primary Perl slogan is: "There's more than one way to do it." The secondary Perl slogan is: "Easy things should be easy, and hard things should be possible." So text processing is what Perl really tries to make easy. But as a glue language it also has to make hard things possible. My project last year was hooking Perl up to Java. My project this year is hooking Perl up to XML. Doing the Unicode things. So we want everything to be possible and some things to be easy. And I actually want to get past making XML and Unicode possible and make those easy, because as I think I mentioned earlier, I think the definition of what text is has been changing out from under Perl over the last 10 years, and I want to make sure it keeps up with the definition of what text means.

Salon 21st The joy of Perl

... Yahoo, wrote Filo, could never have been started without Perl, the all-purpose programming language Wall invented. So would Larry like to buy some cheap, pre-IPO stock?

... Wall may be frugal, but he's not stupid. He accepted the offer and bought some Yahoo stock for his 14-year-old daughter -- enough to pay for her college education. A better example of the Internet's old "gift economy" ethic could hardly be imagined -- give unto the Net, and you shall receive.

... Without Perl and Larry Wall, Perl's advocates argue, the Net would be but a pale shadow of its current self.

Wall has played an important role in spurring forward not only the Web's evolution but also the burgeoning free software/open source movement responsible for so much of the Internet's structure and plumbing. But even though his peers hail him as one of the "paramount chiefs and wise elders" of free-software culture, Wall's version of leadership is utterly self-effacing -- a character trait that sets him apart from some of the other leaders of the movement.

...Wall is himself a religious man. His mission... is to act on his belief "in people working together. He projects his inner vision of selfless work for mutual benefit onto Perl." But he won't allow himself to be drawn into the petty "religious" wars that plague the world of programming -- the endless disputes over such issues as whether one programming language, or operating system, is inherently better than another...

...duct tape is valuable not because it offers a perfect solution to your plumbing problems, but because it gets the job done. Perl, to some eyes, may not seem elegant. But that's not Wall's concern...

...no accident that Perl, which Wall first invented more than a decade ago, didn't really start to explode until the Web took off in 1994. The Web is a hacked-together, messy, ad-hoc creation that requires fast thinking and faster reaction times. Perl is a Web hacker's best friend

Wall's professional background is as a system administrator, rather than as a software engineer. "Sysadmins" tend to take a utilitarian attitude toward programming and technology -- they focus on keeping balky networks running, solving pressing problems now, hacking on the fly. Wall's whole life as a programmer has been devoted to solving those kinds of problems -- Perl is just the most recent tool in his personally crafted arsenal. Years before he dreamed up Perl, he had already achieved hacker renown by writing "rn" -- a program for reading Usenet newsgroups.

Rn was an early prototype for what is now called the free software or open source model for software development -- in which far-flung programmers collaborate across the Net on improving products whose code remains accessible to all. Wall wrote the rn program, released the source code to the Internet and then started work on an upgraded version that incorporated suggestions and bug fixes from fellow hackers all over the then-fledgling universe of cyberspace.

But back in the mid-'80s, it wasn't easy to distribute upgrades across the Net. Often, people would be connecting via slow 300- or 1,200-baud modems, and they simply could not fling megabytes of source code back and forth in the carefree manner that is now commonplace.

So Wall wrote a tiny program called "patch." Patch took a compact new code upgrade and applied it to old source code. Patch could bring that old code up to speed, and was even smart enough to take into account changes that had been hacked into the old code.

As hackers go, Wall is a reasonably circumspect man, but that doesn't mean he is unfailingly modest. "Patch," says Wall, "changed the culture of computing."

..."Patch may just be the most successful hack of all time," says Raymond. "Larry effectively created, or at least critically enabled, the modern style of highly distributed development exemplified by Linux."

..."I realized at that point that there was a huge ecological niche between the C language and Unix shells," says Wall. "C was good for manipulating complex things -- you can call it 'manipulexity.' And the shells were good at whipping up things -- what I call 'whipupitude.' But there was this big blank area where neither C nor shell were good, and that's where I aimed Perl."

...One doesn't have to be the kind of programming genius who can think in Java or C++ to be able to use Perl, although its own flexibility can make it confusing -- especially to hard-core programmers who are accustomed to having just one right way to do something.

... Before he committed to a lifetime of systems administration and associated hacking, he and his wife were graduate students in the linguistics department at UC-Berkeley. Their plan, says Wall, was to become field missionaries dedicated to assisting Bible translation. They would go live with a tribe that had no written language, learn it from scratch, write it down and then help translate the Bible into that language.

He and his wife abandoned that mission, but he replaced it with another -- assisting other people in the ever-relevant goal of connecting with one another to do useful things. When it came to creating a programming language, instead of building something totally new from the ground up, Wall -- inspired by his linguistics training -- chose to build something that replicated how real humans thought and acted.

...First and foremost, that meant providing a number of different approaches to solving every possible problem -- which led to the Perl battle cry, "There is more than one way to do it."

"If you think of a human language as an artistic medium," says Wall, "it has to give you room for creativity. If you want to be able to optimize for different things -- if you want to be able to write recipes and poetry and newspaper columns or magazine articles in the same language -- then there has to be flexibility. This is the antithesis of what people are taught in computer science. People are taught that if there is any redundancy at all that that is evil, wicked. Coming from a natural language perspective, I just don't buy it."

...Despite Perl's popularity, the language is not without its detractors. Marc Ewing, chief technical officer at Red Hat, the leading distributor of commercial versions of Linux, prefers working with Python; and Infoseek, the Internet search engine company, uses Python for its internal development work.

PERL.COM - 2nd State of the Onion Aug. 25, 1998.

... ... ...

A lot of my thinking this year has been influenced by working with Unicode and with XML. Ten years ago, Perl was good at text processing. It's even better at it now, for the old definition of text. But the definition of "text" has been changing out from under Perl over those ten years.

... ... ...

Of course, in Perl culture, almost nothing is prohibited. My feeling is that the rest of the world already has plenty of perfectly good prohibitions, so why invent more? That applies not just to programming, but also to interpersonal relationships, by the way. I have upon more than one occasion been requested to eject someone from the Perl community, generally for being offensive in some fashion or other. So far I have consistently refused. I believe this is the right policy. At least, it's worked so far, on a practical level. Either the offensive person has left eventually of their own accord, or they've settled down and learned to deal with others more constructively. It's odd. People understand instinctively that the best way for computer programs to communicate with each other is for each of the them to be strict in what they emit, and liberal in what they accept. The odd thing is that people themselves are not willing to be strict in how they speak, and liberal in how they listen. You'd think that would also be obvious. Instead, we're taught to express ourselves.

... ... ...

Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.

... ... ...

These are virtues of passion. They are not, however, virtues of community. The virtues of community sound like their opposites: diligence, patience, and humility.

Gluing the Web Together: An Interview with Larry Wall By Alicia Dougherty, April 17, 1998 (ZD Internet User)

Let's talk about the strengths and weaknesses Perl derives from its close relationship with UNIX. Do you ever regret not embracing Win 32 more closely?
I don't regret that--at least, not much. It happened when the time was right.

The strengths that come from UNIX are that it's a worldview where easy things are easy and hard things are possible, and Perl has taken to that idea in particular. There's a really old UNIX idea that if something could be represented as a simple flat text file it ought to be, because then you can edit with regular tools rather than going into a database or something [similarly cumbersome and proprietary].

Perl is similarly biased towards text processing because -- not only are there many things that are 100-percent text processing -- but there are also very many that are 90-percent text processing and 10-percent something else. This is why Perl was used to prototype the Web - because the Web is based on text processing. That other 10 percent tends to be about gluing into other programs like databases. Perl has two main attributes: it's a text processing language and a glue language.

When you ask whether it's trying to compete with other languages, Perl tries to compete by cooperating as often as possible. For example, last year's project was getting Perl and Java talking to each other. Many academic computer science languages have failed because they failed to communicate with other languages.

People will accept a new thing much better if it already resembles something they're familiar with or the way they are already thinking about things. A musician would say "A musical piece lays under the fingers -- it looks hard but it is easy to play." Another way of thinking of it is [by analogy:] At the University of California at Irvine, when they first built its campus, they just planted grass. Then they waited a year and looked at where people had made paths in the grass and built the sidewalks there.

I did the same thing with Perl. I looked at the paths people liked to traverse in UNIX, and distilled them down to a language that still in many ways contains the essence of UNIX. The real driving force behind porting Perl to Windows and Macs is primarily disenfranchised UNIX programmers who want to have a little bit of the old country, and with Perl they get that. On a Windows machine, we make sure there are Windows-specific interfaces, but the notion of being able to hook everything up to everything else in a simple manner is really shoving a wad of UNIX glue into the middle of the works. [It's about] taking a system where "you can't get there from here" and letting you get there from here.

I tend to think that porting Perl over is not so much that Windows is doing Perl a big favor but that Perl is doing Windows a big favor.

You've long been a champion of freeware -- possibly the first champion of freeware. Tell me a little bit about your freeware philosophy.

It's important to Perl in particular because it couldn't have succeeded had it been proprietary.

Perl wanted to fill a niche where it's being the ground of all being for some subset of programmers and it wanted to fill a niche where it had widespread use across most architectures. (I almost wanted to say "all" but I don't think you could get Perl to run on an old PDP11.) The last language that anyone's been able to sell and make money on was probably back in the 1960s. People have tried since then, but haven't succeeded. In a couple of instances I have seen ads for languages similar to Perl but they died out.

Because people would prefer to have something for free rather than to pay?
Yes, if it has same capability. Or, like with Perl, if it doesn't have the capability it's easy to extend the capability, so people do.

How did you feel when you heard Netscape would give away its source code? Mixed emotions, but mostly positive. The downside is simply that for the last two years or so Tim O'Reilly and I have been talking about how there need to be new models of cooperation between freeware and commercial entities. That's essentially why I hired on at O'Reilly two years ago -- we both had this vision that antagonism between freeware and commercial was unnecessary. We thought we could look for a symbiotic model rather than mutual parasitism. When Netscape made their announcement we said, "Oh man, how come we don't get all this press?" [laughs]

But that's outweighed by the positive benefits of what they've done in terms of opening up possibilities for people. It's fine for consumers -- they'll get better products and be able to evolve Navigator into what they want it to be. It's good for managers because they have new ways of doing business. But in particular it's good for developers because before they didn't have the flexibility of going to bosses and saying "Hey, I think we should give this away; we can get more out of not being proprietary." And there are many levels of being proprietary. Perl is still proprietary [in one sense] because I keep a copyright on it.

I did not have that flexibility when I started out. When I was first developing Perl, and before that rn and patch -- rn was the first thing I released as freeware -- I saw someone else at the company say they had created something they wanted to distribute and sell. And they handed it off to the lawyers, and 6 months later the lawyers said no, and [the developer] said well, if you're not going to release it, can I, and they said no, and put it on a shelf and there it will sit. I looked at that and said I'm not going to ask - it's easier to ask forgiveness than permission -- and it wasn't the sort of thing the company would've been interested in any way.

So you just went for it? I just went for it and made sure my manger knew what I was doing. And it helps to be the sort of person who does not make enemies. You really could not do this if you were a person who made enemies because that personality would get you in trouble. Now it's opening up to where this can be done through official channels.

Do you think Netscape will see the same kind of grass roots community spring up?
It will if Netscape allows it to. Netscape is in the same position as I am as an individual, and you have to walk a fine line between too much control and too little. Netscape has the handicap that they have already made enemies.

Will they have to woo developers?
They're not having much trouble. There's quite a ferment around it, which is healthy. Of course, your authority to lead a freeware movement is granted by the followers. It's not something to take to the bank without earning it.

Do you think there's a genuine industry trend towards freeware, or is this just the latest marketing strategy for some of these companies?

There's always hope. [laughs]

There are different models that have succeeded. There's the Apache model -- they don't have a single person in charge, it's sort of an oligarchy. There there's Linux, where Linus Torvalds is really a lot like me - he has absolute control at the center, and then on the periphery there's more autonomy. It's interesting how Perl has evolved. There's a mailing list called Perl5_porters that is really the legislature; then the executive branch - that's not me by the way -- that's too much work for one person to do too long, so we have a rotating system integrator-kind of person. We pass the baton now and then - only we call it the patch pumpkin -- and that leaves me to be the Supreme Court. And providentially I am appointed for life.

In this role as the judicial body have you ever made the wrong decision? Any mistakes?
Most of those mistakes were back when I was judge, jury, and executioner. I fixed a lot of that when I rewrote Perl for Perl 5. It was apparent that things that worked well for a small program don't work as well for large programs with lots of modules. There were some variables that changed out from under people and so on. But now, the Perl5_porters will thrash an idea to death and beyond, and hopefully reach consensus -- and then we're home free -- or [they'll reach] an either/or and then I decide. Now by definition it's not a mistake, but a choice.

How do you feel about the prices ActiveState is charging for their new Perl Win32 tools like PerlEX and Perl Debugger? Is it good or bad that these things aren't free?
I think people have to make a living. I think information wants to be valuable and we have to have an economy. It's very idealistic to think all information should be free.

Where do you draw the line?
I draw the line at "what you can get away with" -- and I mean that in the nicest of possible ways. If you're commercial and you write something trivial then someone's going to implement it as freeware and you get what you deserve: no business. If you do something that's not being done in the freeware community, then that's a service and people will pay for it. I guess take a very Darwinian view of the division of freeware vs. commercial [offerings].

I do not approve of unethical behavior at any level. I don't think someone should take something that [doesn't] belong to them and do something that someone things is wrong. If it's intended as freeware with no commercial use, then commercial use of it is wrong. If it's a commercial tool with its own licenses, then you shouldn't be using that either.

As I said at the end of my keynote at the Perl conference last summer: People should give it away because they want to, not because they're coerced. I would like to develop a culture where people are valued more for what they give away than for what they acquire, and the thing has to be of value. If I would write it and you would claim it anyway, then what's the point? I guess that's the dark side of communism.

Evolutionary Changes in Freeware , Web Review. Apr. 10, 1998 (edited excepts from the keynote address)

Many years ago, all we had was commercial software, by and large. Sure, we all rolled our own software too, but there wasn't a good mechanism in place to share software, and you certainly couldn't get your company to distribute free software officially. Then along came the free software movement. Of course, we all think of Richard Stallman at this point. He was certainly the chief lightning rod of the movement, but the fact is that the time was ripe for it, and many of us were publishing free software at the time. We had to do it in spite of the commercial interests of the time, and we had to invent our own infrastructure, so naturally there arose an antagonism between the commercial software community and the free software community. It was a natural overreaction that continues to this day, and there are some of you sitting right here who are on opposite sides of that battle.

Some of you believe that free software has its place in spawning new ideas, but that a piece of software isn't really successful until it has been taken over and commercialized by industry. Others of you sitting here believe that once any commercial entity takes interest in a piece of freeware, you might as well kiss
it goodbye, because they're gonna hoard it, piss all over it, and spoil it.

These two ideas are dangerous. They're dangerous, not because they're false, but rather because they're both partly true, and you're afraid that they might be totally true. But a year and a half ago, I began to suspect that they didn't actually need to be true. I'm even surer of that today than I was then. I'm here to tell you that we can at least begin to think about negotiating a cease-fire between
the commercial world and the freeware world.

I want to tell you to put aside your fears and your preconceptions, and help us do something new. A new model of cooperation is emerging. A new breed of entrepreneurs is arising that understands the dynamics of the freeware community.

There has to be a new, intermediate model in which the freeware community does what it is good at, and the commercial community does what it is good at (apart from screwing people), and both communities are better off
for having cooperated with each other. If you believe that's impossible, then you can stop listening now, and go out into the hallway, and start fighting with each other.

If you believe in evolutionary metaphors as I do, then perhaps you can see that not all relationships have to be predatorial or parasitical. How 'bout let's evolve a symbiotic relationship instead. We really do need to learn to depend on each other.

Believe it or not, there are things that the freeware community cannot do well. Believe it or not, there are things that the commercial community cannot do well. But we can do those things for each other.

Before we get to the theological metaphor, I should first state for the record that I am not very religious about free software, per se. Ethically, of course, I believe that if someone gives something away, nobody else should be trying to make a quick buck on it. And if you ever feel like that's happening to you, you have the right to squawk -- and squawk loudly.

But I do not fundamentally believe that information wants to be free. Rather, I believe that information wants to be valuable. Now, providing information for free is one way of increasing its value to you, the consumer. But I'm not a communist when it comes to information, and if we're to build an information economy, then information must have some value to me, the producer.

The theological metaphor I want to leave you with is simply that it is better to give than to receive. In western culture, we tend to value a person by what they have acquired. Instead, we really ought to emulate the American Indians of the Pacific Northwest, who invented what they called "potlatch." In that
culture, you were valued not by what you acquired, but rather by what you gave away. Out please note: You have to get it first to give it away. We can give things away because we've invested our time and money, and often our company's time and money, and we've produced something of value. Only if
we have the fundamental right to own information do we also have the fundamental right to give information away, freely and without coercion. Simply because we want to, not because we have to.

Perl Culture

Read a very unusual interview by Feed magazine (late 1998). Divine Invention Author Erik Davis talks to Perl creator Larry Wall

FEED: Let's say I am an alien anthropologist, studying computer languages, and I came across Perl. What's going to grab me?

WALL: One of the things that's going to grab you as an anthropologist is the fact that there really is an anthropological story here. Most other computer languages are pretty sterile. They're about technology. The difference with Perl is that I decided to create the culture at the same time as I was creating the language. My background is in both computers and linguistics... I put more ideas from linguistics into Perl than is typical in computer science.

FEED: What are some of those ideas?

WALL: The first and foremost is that natural [spoken] languages are not minimalistic. They are optimized for expressiveness rather than for simplicity. Right off the bat, that's something that's anathema to the typical computer scientist.

FEED: 'Natural language' implies a kind of messiness that allows for different users to arise, depending on different needs and circumstances...

WALL: ...Especially by virtue of the fact that many people have bent it to their own task. Since it was not designed by a single person, nobody enforces a single design philosophy on it. But by the same token, it's rich enough that you can bend it to optimize for many different things. You can write poetry, you can write manuals, you can write recipes, you can write love letters. You can call plays in a football huddle, and you can babble.

... [With Perl], I was trying to encourage what I call diagonal thinking. Traditionally computer languages try to be as orthogonal as possible, meaning their features are at all at right angles to each other, metaphorically speaking. The problem with that is that people don't solve problems that way. If I'm in one corner of a park and the restrooms are in the opposite corner of the park, I don't walk due east and then due north. I go northeast -- unless there's a pond in the way or something.

I am told that when they built the University of California at Irvine, they did not put in any sidewalks the first year. Next year they came back and looked at where all the cow trails were in the grass and put the sidewalks there. Perl is designed the same way. It's not just a random collection of features. It's a bunch of features that look like a decent way to get from here to there. If you look at the diagram of an airline, it's a network. Perl is a network of features... It's more like glue than it is like Legos.

FEED: And that's reflected in the culture that has developed around Perl?

WALL: I not only want Perl to be a good 'glue' language, I want Perl people to be good 'glue' people.

FEED: What makes a good 'glue' person?

WALL: Let me distinguish two different kinds of joiners. You have people who will join a movement and be totally gung-ho about it. That's great. We need the cheerleaders.

But that's merely a form of tribalism. What we also try to encourage are the kind of joiners who join many things. These people are like the intersection in a Venn diagram, who like to be at the intersection of two different tribes. In an actual tribal situation, these are the merchants, who go back and forth between tribes and actually produce an economy. In theological terms we call them peacemakers.

In terms of Perl language, these are the people who will not just sit there and write everything in Perl, but the people who will say: Perl is good for this part of the problem, and this other tool is good for that part of the problem, so let's hook 'em together. They see Perl both from the inside and from the outside, just like a missionary. That takes a kind of humility, not only on the part of the person, but on the language. Perl does not want to make more of itself than it is. It's willing to be the servant of other things.

FEED: In one of your keynote speeches to the Perl community, you note that you've tried to model the Perl movement on another movement that you're a member of: Christianity. How so?

WALL: That's more difficult to talk about, not because it's embarrassing but because it works at a lower level in my psyche. I was born and bred to it at that level. I've always been on the church scene, and I've seen healthy churches and I've seen sick churches. I have a low-down feel for when things are being healthy and when they're not, particularly in terms of the relationships between people...

FEED: You have said that, "We need God, the ultimate in control, and we need evolution, the ultimate in chaos." A lot of people are content with the evolution. What is missing from the universe of the selfish gene?

WALL: Any notion of purpose. Any notion of morality. Any notion of obligation.

FEED: Many hackers think in strictly evolutionary terms, which tends to hedge against or even deny the kind of "morality" and "purpose" you describe. Has the pervasiveness of that worldview resulted in some of the less seemly aspects of the software scene?

WALL: The chief proponents of atheism in the 20th century were perhaps the communists. They produced a culture that was very coercive at some level. There are aspects of software culture that are very coercive. Certainly on the commercial end, there's a great deal of coercion that everyone recognizes. But also on the opposite extreme. For the folks who believe that information should be free, or shared among all, it's a communal thing. I view them as the people who want to gather all the farmers onto a collective. My take on giving away software is that this sort of thing should not be coerced. I much prefer the U.S. model, where if I want to help somebody out I can donate to them of my own free will, not at the point of a gun.

FEED: You want to find a middle way between these very different collectivist extremes.

WALL: Yes, I'm not into a hive mentality. What the extremists sort of want is this notion that we are all workers in this hive, and we all contribute, but we don't have any individual rights -- except the right to everything, whatever that means. The theological notion that we are each individually valuable in the sight of God puts a different viewpoint on what humans really want and how they should treat each other.

To me, the whole core of the Christian message is that God, who is this cosmic author, wrote himself into his own story, and proved himself to be more humble, and a better man than any of the rest of us. Anyone who aspires to be a cosmic artist, or a not so cosmic artist, really ought to be looking into the same system of doing things.

FEED: Your role as the artist-honcho of the Perl movement involves both control and loss of control. What guides your hand?

WALL: I definitely try to exercise as little control as possible. I am reminded of Tolkien in his preface to the Lord of the Rings, where he writes that he prefers manufactured history to allegory, because allegory is the purposeful domination of the author. Any good leader who is actually trying to encourage good sub-leadership will try to exercise as little power as possible. If I were a domineering sort of person, then people would not feel comfortable taking positions of leadership within the Perl community. The fact that I don't abuse my power is what lets me keep my power.

FEED: In one of your speeches you quote Jesus: "He who wishes to be greatest among you must become the servant of all." You link that idea to the "onion" of the Perl community, where you are at the center but the real action is along the periphery...

WALL: I can be up here in front of the Perl community and kind of be their demigod, and I can make jokes about getting a swelled head, and I don't have to not be that kind of leader merely because I think that I have to be humble. That's not what humility is. I think God put me here for a reason. I remember walking down the halls in my high school and getting this tremendous sense of destiny. Like I was supposed to do something really great. It was a really weird feeling. I feel like if I have an accurate view of myself, it frees me to be both humble and a megalomaniac at the same time.

Dr. Dobb's Journal February 1998 A Conversation with Larry Wall The creator of Perl talks about language design and Perl. By Eugene Eric Kim

... ... ...

DDJ: Is Perl 5.005 what you envisioned Perl to be when you set out to do it?

LW: That assumes that I'm smart enough to envision something as complicated as Perl. I knew that Perl would be good at some things, and would be good at more things as time went on. So, in a sense, I'm sort of blessed with natural stupidity -- as opposed to artificial intelligence -- in the sense that I know what my intellectual limits are.

I'm not one of these people who can sit down and design an entire system from scratch and figure out how everything relates to everything else, so I knew from the start that I had to take the bear-of-very-little-brain approach, and design the thing to evolve. But that fit in with my background in linguistics, because natural languages evolve over time.

You can apply biological metaphors to languages. They move into niches, and as new needs arise, languages change over time. It's actually a practical way to design a computer language. Not all computer programs can be designed that way, but I think more can be designed that way than have been. A lot of the majestic failures that have occurred in computer science have been because people thought they could design the whole thing in advance.

DDJ: How do you design a language to evolve?

LW: There are several aspects to that, depending on whether you are talking about syntax or semantics. On a syntactic level, in the particular case of Perl, I placed variable names in a separate namespace from reserved words. That's one of the reasons there are funny characters on the front of variable names -- dollar signs and so forth. That allowed me to add new reserved words without breaking old programs.

DDJ: What is a scripting language? Does Perl fall into the category of a scripting language?

LW: Well, being a linguist, I tend to go back to the etymological meanings of "script" and "program," though, of course, that's fallacious in terms of what they mean nowadays. A script is what you hand to the actors, and a program is what you hand to the audience. Now hopefully, the program is already locked in by the time you hand that out, whereas the script is something you can tinker with. I think of phrases like "following the script," or "breaking from the script." The notion that you can evolve your script ties into the notion of rapid prototyping.

A script is something that is easy to tweak, and a program is something that is locked in. There are all sorts of metaphorical tie-ins that tend to make programs static and scripts dynamic, but of course, it's a continuum. You can write Perl programs, and you can write C scripts. People do talk more about Perl programs than C scripts. Maybe that just means Perl is more versatile.

... ... ...

DDJ: Would that be a better distinction than interpreted versus compiled -- run-time versus compile-time binding?

LW: It's a more useful distinction in many ways because, with late-binding languages like Perl or Java, you cannot make up your mind about what the real meaning of it is until the last moment. But there are different definitions of what the last moment is. Computer scientists would say there are really different "latenesses" of binding.

A good language actually gives you a range, a wide dynamic range, of your level of discipline. We're starting to move in that direction with Perl. The initial Perl was lackadaisical about requiring things to be defined or declared or what have you. Perl 5 has some declarations that you can use if you want to increase your level of discipline. But it's optional. So you can say "use strict," or you can turn on warnings, or you can do various sorts of declarations.

DDJ: Would it be accurate to say that Perl doesn't enforce good design?

LW: No, it does not. It tries to give you some tools to help if you want to do that, but I'm a firm believer that a language -- whether it's a natural language or a computer language -- ought to be an amoral artistic medium.

You can write pretty poems or you can write ugly poems, but that doesn't say whether English is pretty or ugly. So, while I kind of like to see beautiful computer programs, I don't think the chief virtue of a language is beauty. That's like asking an artist whether they use beautiful paints and a beautiful canvas and a beautiful palette. A language should be a medium of expression, which does not restrict your feeling unless you ask it to.

DDJ: Where does the beauty of a program lie? In the underlying algorithms, in the syntax of the description?

LW: Well, there are many different definitions of artistic beauty. It can be argued that it's symmetry, which in a computer language might be considered orthogonality. It's also been argued that broken symmetry is what is considered most beautiful and most artistic and diverse. Symmetry breaking is the root of our whole universe according to physicists, so if God is an artist, then maybe that's his definition of what beauty is.

This actually ties back in with the built-to-evolve concept on the semantic level. A lot of computer languages were defined to be naturally orthogonal, or at least the computer scientists who designed them were giving lip service to orthogonality. And that's all very well if you're trying to define a position in a space. But that's not how people think. It's not how natural languages work. Natural languages are not orthogonal, they're diagonal. They give you hypotenuses.

Suppose you're flying from California to Quebec. You don't fly due east, and take a left turn over Nashville, and then go due north. You fly straight, more or less, from here to there. And it's a network. And it's actually sort of a fractal network, where your big link is straight, and you have little "fractally" things at the end for your taxi and bicycle and whatever the mode of transport you use. Languages work the same way. And they're designed to get you most of the way here, and then have ways of refining the additional shades of meaning.

When they first built the University of California at Irvine campus, they just put the buildings in. They did not put any sidewalks, they just planted grass. The next year, they came back and built the sidewalks where the trails were in the grass. Perl is that kind of a language. It is not designed from first principles. Perl is those sidewalks in the grass. Those trails that were there before were the previous computer languages that Perl has borrowed ideas from. And Perl has unashamedly borrowed ideas from many, many different languages. Those paths can go diagonally. We want shortcuts. Sometimes we want to be able to do the orthogonal thing, so Perl generally allows the orthogonal approach also. But it also allows a certain number of shortcuts, and being able to insert those shortcuts is part of that evolutionary thing.

I don't want to claim that this is the only way to design a computer language, or that everyone is going to actually enjoy a computer language that is designed in this way. Obviously, some people speak other languages. But Perl was an experiment in trying to come up with not a large language -- not as large as English -- but a medium-sized language, and to try to see if, by adding certain kinds of complexity from natural language, the expressiveness of the language grew faster than the pain of using it. And, by and large, I think that experiment has been successful.

DDJ: Give an example of one of the things you think is expressive about Perl that you wouldn't find in other languages.

LW: The fact that regular-expression parsing and the use of regular expressions is built right into the language. If you used the regular expression in a list context, it will pass back a list of the various subexpressions that it matched. A different computer language may add regular expressions, even have a module that's called Perl 5 regular expressions, but it won't be integrated into the language. You'll have to jump through an extra hoop, take that right angle turn, in order to say, "Okay, well here, now apply the regular expression, now let's pull the things out of the regular expression," rather than being able to use the thing in a particular context and have it do something meaningful.

The school of linguistics I happened to come up through is called tagmemics, and it makes a big deal about context. In a real language -- this is a tagmemic idea -- you can distinguish between what the conventional meaning of the "thing" is and how it's being used. You think of "dog" primarily as a noun, but you can use it as a verb. That's the prototypical example, but the "thing" applies at many different levels. You think of a sentence as a sentence. Transformational grammar was built on the notion of analyzing a sentence. And they had all their cute rules, and they eventually ended up throwing most of them back out again.

But in the tagmemic view, you can take a sentence as a unit and use it differently. You can say a sentence like, "I don't like your I-can-use-anything-like-a-sentence attitude." There, I've used the sentence as an adjective. The sentence isn't an adjective if you analyze it, any way you want to analyze it. But this is the way people think. If there's a way to make sense of something in a particular context, they'll do so. And Perl is just trying to make those things make sense. There's the basic distinction in Perl between singular and plural context -- call it list context and scalar context, if you will. But you can use a particular construct in a singular context that has one meaning that sort of makes sense using the list context, and it may have a different meaning that makes sense in the plural context.

That is where the expressiveness comes from. In English, you read essays by people who say, "Well, how does this metaphor thing work?" Owen Barfield talks about this. You say one thing and mean another. That's how metaphors arise. Or you take two things and jam them together. I think it was Owen Barfield, or maybe it was C.S. Lewis, who talked about "a piercing sweetness." And we know what "piercing" is, and we know what "sweetness" is, but you put those two together, and you've created a new meaning. And that's how languages ought to work.

DDJ: Is a more expressive language more difficult to learn?

LW: Yes. It was a conscious tradeoff at the beginning of Perl that it would be more difficult to master the whole language. However, taking another clue from a natural language, we do not require 5-year olds to speak with the same diction as 50-year olds. It is okay for you to use the subset of a language that you are comfortable with, and to learn as you go. This is not true of so many computer-science languages. If you program C++ in a subset that corresponds to C, you get laughed out of the office.

There's a whole subject that we haven't touched here. A language is not a set of syntax rules. It is not just a set of semantics. It's the entire culture surrounding the language itself. So part of the cultural context in which you analyze a language includes all the personalities and people involved -- how everybody sees the language, how they propagate the language to other people, how it gets taught, the attitudes of people who are helping each other learn the language -- all of this goes into the pot of context.

Because I had already put out other freeware projects (rn and patch), I realized before I ever wrote Perl that a great deal of the value of those things was from collaboration. Many of the really good ideas in rn and Perl came from other people.

I think that Perl is in its adolescence right now. There are places where it is grown up, and places where it's still throwing tantrums. I have a couple of teenagers, and the thing you notice about teenagers is that they're always plus or minus ten years from their real age. So if you've got a 15-year old, they're either acting 25 or they're acting 5. Sometimes simultaneously! And Perl is a little that way, but that's okay.

DDJ: What part of Perl isn't quite grown up?

LW: Well, I think that the part of Perl, which has not been realistic up until now has been on the order of how you enable people in certain business situations to actually use it properly. There are a lot of people who cannot use freeware because it is, you know, schlocky. Their bosses won't let them, their government won't let them, or they think their government won't let them. There are a lot of people who, unknown to their bosses or their government, are using Perl.

DDJ: So these aren't technical issues.

LW: I suppose it depends on how you define technology. Some of it is perceptions, some of it is business models, and things like that. I'm trying to generate a new symbiosis between the commercial and the freeware interests. I think there's an artificial dividing line between those groups and that they could be more collaborative.

As a linguist, the generation of a linguistic culture is a technical issue. So, these adjustments we might make in people's attitudes toward commercial operations or in how Perl is being supported, distributed, advertised, and marketed -- not in terms of trying to make bucks, but just how we propagate the culture -- these are technical ideas in the psychological and the linguistic sense. They are, of course, not technical in the computer-science sense. But I think that's where Perl has really excelled -- its growth has not been driven solely by technical merits.

DDJ: What are the things that you do when you set out to create a culture around the software that you write?

LW: In the beginning, I just tried to help everybody. Particularly being on USENET. You know, there are even some sneaky things in there -- like looking for people's Perl questions in many different newsgroups. For a long time, I resisted creating a newsgroup for Perl, specifically because I did not want it to be ghettoized. You know, if someone can say, "Oh, this is a discussion about Perl, take it over to the Perl newsgroup," then they shut off the discussion in the shell newsgroup. If there are only the shell newsgroups, and someone says, "Oh, by the way, in Perl, you can solve it like this," that's free advertising. So, it's fuzzy. We had proposed Perl as a newsgroup probably a year or two before we actually created it. It eventually came to the point where the time was right for it, and we did that.

DDJ: Perl has really been pigeonholed as a language of the Web. One result is that people mistakenly try to compare Perl to Java. Why do you think people make the comparison in the first place? Is there anything to compare?

LW: Well, people always compare everything.

DDJ: Do you agree that Perl has been pigeonholed?

LW: Yes, but I'm not sure that it bothers me. Before it was pigeonholed as a web language, it was pigeonholed as a system-administration language, and I think that -- this goes counter to what I was saying earlier about marketing Perl -- if the abilities are there to do a particular job, there will be somebody there to apply it, generally speaking. So I'm not too worried about Perl moving into new ecological niches, as long as it has the capability of surviving in there.

Perl is actually a scrappy language for surviving in a particular ecological niche. (Can you tell I like biological metaphors?) You've got to understand that it first went up against C and against shell, both of which were much loved in the UNIX community, and it succeeded against them. So that early competition actually makes it quite a fit competitor in many other realms, too.

For most web applications, Perl is severely underutilized. Your typical CGI script says print, print, print, print, print, print, print. But in a sense, it's the dynamic range of Perl that allows for that. You don't have to say a whole lot to write a simple Perl script, whereas your minimal Java program is, you know, eight or ten lines long anyway. Many of the features that made it competitive in the UNIX space will make it competitive in other spaces.

Now, there are things that Perl can't do. One of the things that you can't do with Perl right now is compile it down to Java bytecode. And if that, in the long run, becomes a large ecological niche (and this is not yet a sure thing), then that is a capability I want to be certain that Perl has.

DDJ: There's been a movement to merge the two development paths between the ActiveWare Perl for Windows and the main distribution of Perl. You were talking about ecological niches earlier, and how Perl started off as a text-processing language. The scripting languages that are dominant on the Microsoft platforms -- like VB -- tend to be more visual than textual. Given Perl's UNIX origins -- awk, sed, and C, for that matter -- do you think that Perl, as it currently stands, has the tools to fit into a Windows niche?

LW: Yes and no. It depends on your problem domain and who's trying to solve the problem. There are problems that only need a textual solution or don't need a visual solution. Automation things of certain sorts don't need to interact with the desktop, so for those sorts of things -- and for the programmers who aren't really all that interested in visual programming -- it's already good for that. And people are already using it for that. Certainly, there is a group of people who would be enabled to use Perl if it had more of a visual interface, and one of the things we're talking about doing for the O'Reilly NT Perl Resource Kit is some sort of a visual interface.

A lot of what Windows is designed to do is to get mere mortals from 0 to 60, and there are some people who want to get from 60 to 100. We are not really interested in being in Microsoft's crosshairs. We're not actually interested in competing head-to-head with Visual Basic, and to the extent that we do compete with them, it's going to be kind of subtle. There has to be some way to get people from the slow lane to the fast lane. It's one thing to give them a way to get from 60 to 100, but if they have to spin out to get from the slow lane to the fast lane, then that's not going to work either.

Over the years, much of the work of making Perl work for people has been in designing ways for people to come to Perl. I actually delayed the first version of Perl for a couple of months until I had a sed-to-Perl and an awk-to-Perl translator. One of the benefits of borrowing features from various other languages is that those subsets of Perl that use those features are familiar to people coming from that other culture. What would be best, in my book, is if someone had a way of saying, "Well, I've got this thing in Visual Basic. Now, can I just rewrite some of these things in Perl?"

We're already doing this with Java. On our UNIX Perl Resource Kit, I've got a hybrid language called "jpl" -- that's partly a pun on my old alma mater, Jet Propulsion Laboratory, and partly for Java, Perl...Lingo, there we go! That's good. "Java Perl Lingo." You've heard it first here! jpl lets you take a Java program and magically turn one of the methods into a chunk of Perl right there inline. It turns Perl code into a native method, and automates the linkage so that when you pull in the Java code, it also pulls in the Perl code, and the interpreter, and everything else. It's actually calling out from Java's Virtual Machine into Perl's virtual machine. And we can call in the other direction, too. You can embed Java in Perl, except that there's a bug in JDK having to do with threads that prevents us from doing any I/O. But that's Java's problem.

It's a way of letting somebody evolve from a purely Java solution into, at least partly, a Perl solution. It's important not only to make Perl evolve, but to make it so that people can evolve their own programs. It's how I program, and I think a lot of people program that way. Most of us are too stupid to know what we want at the beginning.

DDJ: Is there hope down the line to present Perl to a standardization body?

LW: Well, I have said in jest that people will be free to standardize Perl when I'm dead. There may come a time when that is the right thing to do, but it doesn't seem appropriate yet.

DDJ: When would that time be?

LW: Oh, maybe when the federal government declares that we can't export Perl unless it's standardized or something.

DDJ: Only when you're forced to, basically.

LW: Yeah. To me, once things get to a standards body, it's not very interesting anymore. The most efficient form of government is a benevolent dictatorship. I remember walking into some BOF that USENIX held six or seven years ago, and John Quarterman was running it, and he saw me sneak in, sit in the back corner, and he said, "Oh, here comes Larry Wall! He's a standards committee all of his own!"

A great deal of the success of Perl so far has been based on some of my own idiosyncrasies. And I recognize that they are idiosyncrasies, and I try to let people argue me out of them whenever appropriate. But there are still ways of looking at things that I seem to do differently than anybody else. It may well be that perl5-porters will one day degenerate into a standards committee. So far, I have not abused my authority to the point that people have written me off, and so I am still allowed to exercise a certain amount of absolute power over the Perl core.

I just think headless standards committees tend to reduce everything to mush. There is a conservatism that committees have that individuals don't, and there are times when you want to have that conservatism and times you don't. I try to exercise my authority where we don't want that conservatism. And I try not to exercise it at other times.

DDJ: How did you get involved in computer science? You're a linguist by background?

LW: Because I talk to computer scientists more than I talk to linguists, I wear the linguistics mantle more than I wear the computer-science mantle, but they actually came along in parallel, and I'm probably a 50/50 hybrid. You know, basically, I'm no good at either linguistics or computer science.

DDJ: So you took computer-science courses in college?

LW: In college, yeah. In college, I had various majors, but what I eventually graduated in -- I'm one of those people that packed four years into eight -- what I eventually graduated in was a self-constructed major, and it was Natural and Artificial Languages, which seems positively prescient considering where I ended up.

DDJ: When did you join O'Reilly as a salaried employee? And how did that come about?

LW: A year-and-a-half ago. It was partly because my previous job was kind of winding down.

DDJ: What was your previous job?

LW: I was working for Seagate Software. They were shutting down that branch of operations there. So, I was just starting to look around a little bit, and Tim noticed me looking around and said, "Well, you know, I've wanted to hire you for a long time," so we talked. And Gina Blaber (O'Reilly's software director) and I met. So, they more or less offered to pay me to mess around with Perl.

So it's sort of my dream job. I get to work from home, and if I feel like taking a nap in the afternoon, I can take a nap in the afternoon and work all night.

DDJ: Do you have any final comments, or tips for aspiring programmers? Or aspiring Perl programmers?

LW: Assume that your first idea is wrong, and try to think through the various options. I think that the biggest mistake people make is latching onto the first idea that comes to them and trying to do that. It really comes to a thing that my folks taught me about money. Don't buy something unless you've wanted it three times. Similarly, don't throw in a feature when you first think of it. Think if there's a way to generalize it, think if it should be generalized. Sometimes you can generalize things too much. I think like the things in Scheme were generalized too much. There is a level of abstraction beyond which people don't want to go. Take a good look at what you want to do, and try to come up with the long-term lazy way, not the short-term lazy way.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Community: Larry Wall Visits Cincinnati on Jan. 22(Jan 15, 2001)
PaulaGordon.com: Free Software (RealAudio Interview with Larry Wall)(Nov 26, 2000)
Perl.org: Larry Wall's Altanta Linux Showcase Talk: Camel Lot #6, The Once and Future Perl(Oct 31, 2000)
ZDTV: Perl 6: What I Did This Summer [Interview with Larry Wall](Sep 10, 2000)
Feed: LARRY WALL: Divine Invention(Feb 11, 1999)
Salon Magazine: The joy of Perl(Oct 13, 1998)
TPI: Larry Wall wins Free Software Foundation Award(Oct 10, 1998)

Perl the challenges ahead - SunWorld - August 1997 -- one of the most interesting and important interview with Larry Wall. deserve to be read in its entirety.

The Taming of the Camel

The "Artistic License"

Three Great Virtues of a Programmer

Gluing the Web Together An Interview with Larry Wall (his thoughts on Perl 5.005 XML freeware)

Amazon.com Interview Larry Wall

Web Review--The Virtues of Perl

TechWeb Internet Larry Wall Interview about the significance for Perl of Netscape's offering to release its source code to the public

Web Review - Interview with Larry Wall and Tom Christiansen

Programming Perl an Interview with Larry Wall from Crossroads 1.2 December 1994 (ACM student magazine)

XML.COM - XML and Perl -- interview with Larry Wall. Requires RealPlayer 5.0

Etc

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

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: September, 21, 2019