Wherefore Art, Thou?
I don't know whether a picture is really worth a thousand words (most pictures seem to be considerably larger these days), but when I give talks about Perl, I often put up a picture showing where some of the ideas in Perl come from.
I usually make a joke about Linguistics not really being the opposite of Common Sense, and then proceed to talk a lot about both of them, with some Computer Science thrown in for good measure. But last December as I was giving a talk in Stockholm, someone asked me how Perl got its inspiration from Art. I was stumped. I mumbled something semi-irrational (always appropriate when discussing Art) and went on to the rest of my talk.
But the question continued to bother me; or more specifically, it continued to bother my left brain. My right brain continued to be perfectly content with the purported connection. Unfortunately, it's also not at all forthcoming with the verbiage necessary to explain itself. Right brains tend to be like that. So let me see if my left brain can make something of it all.
Art is first of all based on the notion that there exist amoral decisions, that is, choices you can make either way, without feeling like you're being naughty or nice. So let's presume that the Artist has free will of some sort or another, and can therefore behave as your ordinary, everyday Creator.
Now, it's more or less immaterial whether your Artist creates because of a liking for Deluxe Designer Universes or merely because of a liking for caffeine. The simple fact is, we have Artists, and they do Art. We just have to deal with it. We really do. You can make life miserable for the Artist, but the Artist has ways of getting revenge. (Of course, if you don't make an Artist miserable, they'll make them selves miserable, but that comes into a different story.)
We can further subdivide the Artists into those who enjoy getting their revenge by being more than properly miserable, and those who prefer to get their revenge by being less than properly miserable. Artists of the first sort will prefer to work in a more formal medium, one that inflicts extra pain on the Artist, such as composing sonnets, dancing ballet, or programming C++. Artists of the second sort tend to be much more fun-loving, free-wheeling and undisciplined, whether the verb in question is composing, dancing, programming, or slinging. (Especially slinging. There's nobody quite so joyful as a B.S. artist. I should know...)
There is, of course, a third category of Artist, the one who oscillates between the two extremes.
Perl was written first of all to let the Artist make amoral decisions. That's why the Perl slogan is “There's More Than One Way To Do It!” Perl doesn't really care whether you use cobalt blue or burnt umber in a particular spot in your painting. It's your choice—you're the Artist. You're responsible for the overall effect. Indeed, your boss will hold you responsible for the overall effect, so why should Perl?
But more than that, Perl is intended to be a medium for those who are tired of composing in a formal computer language and want to write some “free verse” without arbitrary restrictions. Sure, from a motivational point of view, arbitrary restrictions are challenging to work with, but when's the last time you saw a gleeful COBOL programmer?
On the other hand, with Perl 5, we've made strides in making life wonderful for those Artists who oscillate. You can have your cake and eat it, too. When you're in a manic mood, you can pour forth unstructured, unreadable (but expressive) code to your heart's content. Later on, when you are in a dour mood, you can put a -w and a use strict at the top of your script and greatly increase your level of discipline (read “pain”). Next you can prototype your function definitions. While still in your somber state, you can go back and put white space in all your regular expressions and comment every last little bit as penance for your past indiscretions. You can restructure all your code into modules and unit test it in a jiffy because the Perl interpreter is so handy to invoke. Then as you swing back into a more carefree frame of mind, you can cheat by tweaking all those carefully encapsulated variables in all those painstakingly restructured modules. Ain't it the life.
Now, Linguistics may not be the opposite of Common Sense, but it's certainly the case that over the last twenty years or so, many Computer Scientists have come out in opposition to the Art of Programming. In trying to make programming predictable, they've mostly succeeded in making it boring. And in so doing, they've lost sight of the idea that programming is a human pursuit. They've designed languages intended more to keep the computer happy than the programmer. Was any SQL programmer ever happy about having to declare a value to be varchar(255)? Oops, now it's a key, and can't be longer than 60. Who comes up with these numbers?
They've also lost sight of the idea known to any Artist, that form and meaning are deeply interdependent. One of the ideas I keep stressing in the design of Perl is that things that are different should look different. The reason many people hate programming in Lisp is because every thing looks the same. I've said it before, and I'll say it again: Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in. (Other than that, it's quite a nice language.)
A large part of the design of Perl is driven by the dictates of visual psychology. That's why Perl lets you structure your code with the condition on the left or on the right, depending on which part you want to look important. That's why the large nested structures like while loops require an explicit beginning and end, while the small ones like list operators don't. That's why scalars start with $, arrays with @, and hashes with %. That's why filetest operators look like “-M”, while numeric tests look like “==”, and string tests look like “eq”. Perl is very much a What-You-See-Is-What-It-Does language. You can talk about readability all you like, but readability depends first and foremost on recognizability.
Like many computer geeks, much of my artistic training has been in music. Of all the arts, it most clearly makes a programmer/interpreter distinction, so perhaps it's natural for a musician to think about how interpreters work. But the interpreters for a computer language are located both in the computer and in the human brain. I don't always know what makes a computer sad (or happy), but I do have a pretty good idea what makes a person mad (or sappy). Er, sorry.
Anyway, when I was young, I was taught that music has progressed through four major periods: Baroque, Classical, Romantic and Modern. (The other so-called fine arts have also gone through these periods, though not necessarily at the same rate.) I always thought it rather curious that we called the current period Modern, since definitionally the idea of modernity seems to be a permanently latched-on state, bound to the cursor of time, so to speak. But that was because the word “modern” still meant something back then. This was, after all, the 1960s. Who could have guessed that Modern period would be followed by the Post-Modern?
If you're willing to concede by now that the design of computer languages is an artistic medium of sorts (and searches), then it's reasonable for us to ask ourselves whether programming languages have been progressing through the same sequence of artistic development. Certainly, people have occasionally claimed that Perl is “baroque”, to which my usual retort is, “Thanks, I like Bach, too.” But this is merest rhetoric (on both sides).
So what do we really mean when we talk about these periods? Let's start at the beginning, which is the Baroque period. Of course, it's not really the beginning. People were producing music long before they ever invented the bucket in which to carry the tune. But before and during the Baroque period, there was tremendous technological progress in both the production and publication of music. Composers and performers could make a name for themselves. Innovators were rewarded, but the forms of expression were heavily influenced both by cultural expectations and by available hardware. People were expected to improvise. What we got was more or less the Cambrian explosion of music.
Similarly, at the dawn of the computer era, there were new opportunities to innovate. The geniuses of that period improvised many forms of assembly language. To them, these languages all looked very different. But nowadays we tend to see all assembly language as the same, just as a lot of Baroque music seems the same to us, because the music tends to follow particular forms and sequences. Baroque music is structured like a weaving on a loom, and it's no accident that punch cards were invented to run looms before they were used to run computers.
It's easy to take a superior attitude toward these innovators, but this is unfair. We owe a great debt to these people. They invented the algorithms we use, even if the music does seem a bit limited at times. (Except for Bach, and Backus, of course.)
The Classical period was a time of standardization. Most of our modern instruments took their current form during this period, and this continued the trend of turning virtuosity into a marketable and portable commodity. Being able to program in FORTRAN was like being able to play the piano forte. It was a skill you could use on someone else's machinery. Mozart could now go on tour.
The Romantic era was a time of seeing how far the classical forms could be stretched. And considerably stretched they were, in Beethoven and Mahler, as well as PL/1 and COBOL. The word “excessive” has been applied to all of them, as it will always be applied to anyone or anything that attempts to sling the entire universe around by any of its handles. But this is difficult at the best of times.
Finally, the typical overreaction took place, and we arrived in the Modern era, in which subtlety and minimalism were mandated, and antiquated cultural expectations were thrown over and thrown out. Reductionism and deconstructionism were the order of the day, from Bartok to Cage, and from Pascal to C. Music wasn't allowed to be tonal, and computer languages weren't allowed to do fancy I/O. All the gadgetry had to be visible and exposed. Everything had to look difficult, so we got stuck in the Turing Tar Pit.
Of course, this is all oversimplified, and every language has aspects of each of these periods in it. And languages specialize in other ways: BASIC is like pop music. Tune into REXX for your easy listening classics. Tcl is fuzzy like jazz—you get to improvise a lot, and you're never quite sure who is interpreting what. Python is like MTV—it rocks, but it gets to be much of a sameness after half an hour or so.
Lisp is like church music down through the ages, adapting to what ever the popular culture is, from organ to electric guitar to synthesizer. That would make Scheme a kind of cult music, sung simply but with great fervor to an acoustic guitar.
C++ is like movie music, of titanic proportions, yet still culturally derivative by and large. Especially large. Sometimes it's hard to sit through the whole movie. And yet, as an intentionally Post-Modern language, it's kinda fun, and gets the job done.
As for Java, using a subset of movie music, it's attempting to be the basis for every good feeling everywhere, the ground of all emotional being. Muzak. It's everywhere you want to be.
Shell programming is a 1950s juke box—great if it has your song already.
And of course, any language touched by ANSI starts to sound distinctly operatic.
So where does Perl fit in to this glorious mess? Like C++, Perl is a Post-Modern language by design, unashamedly reconstructionist and derivative. Perl is neo-Baroque, neo-Classical, neo-Romantic, and even, in spots, neo-Modern.
What musical genre encompasses so much? Where can you find every thing from Wagner to “Shave and a Haircut, Two Bit”? Where can you find multiple levels of abstraction, accessible to newbies and oldsters alike? What kind of music admits everything from harmonica to accordion to pipe organ? What music is object-oriented, in good one-to-one correspondence with the main action? What music is good for programming in the small, but can be expanded to feature length as necessary? What music parodies every thing in the world, yet leaves you feeling good about the world? What music is Perl?
Why, cartoon music, of course. That's all folks!
Larry Wall doesn't mind being blamed for the invention of Perl, to the extent that you can blame any one person for it, which you can't, so there.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- another very interesting
20 min 14 sec ago
- Reply to comment | Linux Journal
2 hours 13 min ago
- Reply to comment | Linux Journal
9 hours 7 min ago
- Reply to comment | Linux Journal
9 hours 23 min ago
- Favorite (and easily brute-forced) pw's
11 hours 15 min ago
- Have you tried Boxen? It's a
17 hours 6 min ago
- seo services in india
21 hours 38 min ago
- For KDE install kio-mtp
21 hours 39 min ago
- Evernote is much more...
23 hours 39 min ago
- Reply to comment | Linux Journal
1 day 8 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?