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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide