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.
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.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| 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 |
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Build a Skype Server for Your Home Phone System
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
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?





41 min 56 sec ago
49 min 57 sec ago
3 hours 4 min ago
5 hours 34 min ago
15 hours 37 min ago
20 hours 4 min ago
23 hours 39 min ago
1 day 12 min ago
1 day 2 hours ago
1 day 2 hours ago