Results tagged “work”

Help! Help! I need help!

I’m giving a talk at YAPC 2010 on telecommuting as a software developer. For the talk to be successful, I’m going to need more than just my own experience to pull from. If you are a telecommuter and have a moment, I would appreciate your help in filling out this survey.

The goal of the talk is two-fold:

1. I want to explain the benefits and risks of telecommuting as a Perl developer.
2. I want to provide some practical tips to help fellow telecommuters.

I want the format to be oriented towards telling a number of stories about telecommuters with practical advice interspersed.

Perl Telecommute Survey

This morning I had an epiphany about a difference in project management style between the two major development jobs I’ve held. One style was like driving an empty bus and the other was like riding in a clown car. I am going to examine both as anecdotes from my perspective and try to avoid grandiose analysis.

The Empty Bus

So, I start the job and the first thing the company does is hand me the keys to the bus. Actually, they dither on what kind of bus to give me for several months before getting me a suitable one and give me a loaner to drive in the meantime. However, once on the bus driving, I am pretty much on my own. I have a destination to reach that has been vaguely described on a scribbled piece of paper. The directions are unclear and no one in the company has been there before. They keep changing the directions. But I get to drive. That is fun.

Every now and then, I pick somebody from the company up, they make changes to the directions and then they get off again before I go very far. Every six months, everybody climbs on to the bus and sits in the very back. They do a lot of yelling while I park and then they take away my scribbled directions and give me new scribbles to follow and a new destination to reach. But I get to drive. That’s usually fun.

All in all, I am asked to develop software with very little cooperation or direction. I am left on my own to make almost all the decisions. Even though I have weekly meetings with my manager, I am not really given much feedback on whether I’m going the right way. He’s not a developer, so he doesn’t really know enough about what I do to give me useful feedback. My quarterly reviews aren’t very cooperative or helpful, they are more about the manager wishing I would drive faster and make fewer mistakes (mutually exclusive goals when you think about it).

I nearly get into a wreck a couple times, but there’s no one on the bus to help me out. Don’t get me wrong, I’m not an excellent driver. I’m still learning, but some help should help things go faster in process, you’d think. Usually, though, my directions are so unclear and difficult to follow that I am directed to get into wrecks. This is not actually all that fun as time goes on.

The Clown Car

Clown cars are funny. They drive around in circles and then the doors pop open and an absurd number of hilarious characters hop out of the little car. This job is not quite like this. It’s actually more like a really crowded minivan, like the trip I took the other day with my wife, son, dad, mom, brother, sister, and her boyfriend, all crammed into our little Pontiac Montana. But now, imagine, that all of these people have a stake in where the van goes and have a slightly role and different idea about how to go about getting there. Now, we’ve got a good analogy. Clown cars are fun, though.

The CEO’s seat is next to mine and he gets in and out of the van whenever he feels the need. He’s a busy man: lots of vans to help. Usually, he gets in right before we wreck or near the major turns to make sure we drive carefully at those point and turn the right direction. Directly behind me sits an analyst whose job it is to navigate. He tells me where to go and annotates those instructions pretty regularly. Beside him sits another analyst whose job it is to talk to the customer and figure out what they want. He then tells the first analyst and me where we need to think about going next. I get to drive, though, they keep reaching from the back for the wheel and the pedals. That’s annoying, but still fun.

Behind the analysts sit a whole team of project managers, executives, sales people and between them and between the front seats sit a bunch of other engineers. Sometimes the other engineers help drive, make suggestions, and they often critique or commend my driving. There are a lot of people in this minivan, sometimes there’s a lot of yelling about what to do next. All the activity does make for quite a bit of fun, even if it gets a bit distracting at times.

I get to drive. As I mentioned, sometimes the analysts and engineers have their hand on the wheel and help push the pedals for me. This is pretty fun too, unlike the car though, this actually gives us a lot more control. We seem to be getting places in a much more controlled way, though we do have to control our speed much more carefully. It might take us longer, but the drive is fun along the way.

Software development in this style takes away some of my freedom as a coder. That’s a bummer in some ways, not as much fun. I like control. Yet, it also lets me focus on my strengths while others worry about talking to customers, making sure we have a plan that does what the customer wants, and while the constant feedback makes it hard to see the big picture, I usually have a lot of warning before I drive off the road or get into a wreck. Overall, this is more fun.

So far, I prefer the “clown car”/stuffed minivan to the empty bus. It’s less bipolar and more slow, steady, and directed.

Cheers.

Sorry for the Sir Mixalot reference there. Ahem. Anyway, I just had a coworker walk by my desk and say something like, “Don’t you just wish we could get rid of all these glitches and be done with them?” She left before I could answer and I think it was rhetorical (it’s hard for me to switch gears to interpret social signals while in the midst of concentrating on code). My answer was going to, “Uh, no. I like finding bugs.” In this sense, I’d agree with what Nat Torkington twittered recently (edited for language, I try to run a PG rated blog):

acid test of whether I’m still a hacker: do I think “oh goody!” or “oh [skittles]!” when I find a bug?

Not only this, but a few years back I worked for a company, NRG, that shared office space with another company owned by John Devore. John and I were chatting one afternoon and we were talking about debugging things. He said that when he finds a bug, he doesn’t just want to fix it. He wants to know why he didn’t find it before: why does the bug work so well except here? That’s certainly my passion.

Debugging is an interesting opportunity to learn. Not only can you learn from the mistake, but you can then use that mistake to actually become an enhancement in the future if it happens to be interesting in some way. Sometimes, you can even end up turning a bug into a feature if it happens to do something really cool with a slight change.

Anyway, I just wanted to post that I enjoy debugging and when I get to the point where I say, “Ah crap” when I need to fix something, it’s time to switch careers.

Cheers.

If you ask my wife when I work, her answer would almost certainly be, "All the time." She means a couple different things by that. One, she doesn't really like it when I work away from the house, which I do when I work in my cube three days a week. Bee, she means that I work in the shower, while eating breakfast, when I'm playing with my son, when I'm relaxing in the evening, always. I eat, sleep, and breathe work. This is what I am calling, "Stream of Consciousness Work Style."

Round Peg, Cubicle Hole

The first aspect of what Terri, my wife, has described is a bad thing. When I work in the office, I'm conformed to work from my cubicle. There's no creative workspace in our finely decorated offices at Boomer Consulting. That's not a knock against the company, but a sign of the company's origin, as a department of a CPA firm. CPAs are more creative than they'll admit, but they don't always need creative workspaces. They need orderly workspaces. They need workspaces that impress clients. Boomer has posh looking, orderly workspaces.

Not only am I constrained to my cubicle, I'm constrained in my work hours. I am expected to work from 8 to 5 or 9 to 5 or 9 to 6 or 7 to 4 or something. There's something in the Human Capital arena called "flex time" which is neither flexible nor timely, in my estimation, but for a well-ordered firm with top-down management, it's the rule. You can work flexible hours (i.e., not the typical 8 to 5), but those hours should be set in a regular schedule and your coworkers/supervisors should be aware of deviations in advance, etc. For a guy who found college hours to his liking (i.e., whenever as long as you and your project team got the job done), this is hard for me. I try, but I'm very bad at it. I try not to resent it too much. I try to conform, but I seem to fail regularly.

Finally, I'm nearly always in the middle of something when five o'clock rolls around. This is because I usually finish a task around 4:15, 4:30, or 4:45 and then it's not yet 5:00. I could leave before 5pm, but appearances are what they are and where would I draw the line if not 5pm? Thus, I pick up something else I hope won't take long, if I can. That generally pushes me to 5:10, 5:30, or 6:00 before I'm done. Terri no likey. Me no likey. Fortunately, my drive home takes 12 minutes, but I still don't like working late at the office. When five rolls around, I must make one of two choices: (1) drop what I'm doing in the middle and risk the mess that leaves things in or (2) complete the task and get home after dark. I despise both of those options, but I choose one or the other regularly depending on how long I estimate the task will take or how troublesome dropping it in the middle will be.

That's the negative aspect of "working all the time." It's a bummer, but that's life and while I work to slowly move my life away from work schedules that interfere with my work process, I deal with it in the meantime. This traditional office life is traditional for useful reasons as well. It is not without value. I'm not really knocking it. I am basically saying that I, as a round peg, find the cubical hole an uncomfortable fit.

Stream of Consciousness

The other aspect of "working all the time" revolves around my creative thought process. An article I recently read from A List Apart discusses the difference between the hat heads and the bed heads
. I definitely fall into the latter category. The bad news is that I'm difficult to manage, tend to work on my own, and don't necessarily communicate clearly all the time. The good news is that I'm a creator and I get stuff done.

First, I am always thinking about something. My brain almost never shuts off. The only time it really shuts down is when I read a book right before bed. This is a habit I've cultivated to avoid insomnia. The goal of the book, even if it is intellectual or stimulating is to put my brain into the right mode to sleep. It takes about an hour for my motor to get up to speed in the morning, but after that, I'm again full on working. I begin thinking about work before I step into the shower, while I eat breakfast, when I drive to work (or walk upstairs to my home office), while I'm officially working, while I eat lunch, etc. If I'm not in front of a computer, white board, or tablet of graph paper doing what looks like work, I'm still working somewhere in the back of my mind.

Next, I'm not always working on work. I have several hobbies, most of which look like work, but aren't what I get paid to do. For example, I keep a blog, which feels the same as work since I write articles and blogs for work. I build web sites, contribute to Open Source projects, and do other computer science stuff, which feels like work, but might be projects I like on my own time rather than stuff Boomer pays me for. I study theology and my Bible, which is really not much different than studying whatever latest technology I need to know to get my job done.

As a really excellent article, The Nerd Handbook
, points out I see everything and everyone as a project. That's not far from the truth. Even wrestling with my son is something I see as a task to be completed. That doesn't at all diminish the preciousness of the experience, but after I put Gabe to bed, a little check box gets ticked off in my head next to, "Had a significant amount of quality time with the Goober Pants." (At least, it usually gets marked, sometimes I'm not satisfied and that box takes on a larger font in the tag cloud floating in my brain for tomorrow night.) The same goes for time with my wife or playing video games or any other form of fun and recreation. It all falls into the same category as work.

The interesting thing about this way of living is that work is no longer work, but it's life. I don't take a vacation from work to get away from work, but so that I don't have to structure my time to fit the needs of my coworkers. We have this mystical thing we talk about at Boomer called the "Work-Life Balance." I say "mystical," but I should say "mystifying to me" because work and life are synonyms as far as I am concerned. I will work until I die. I will live until I retire. I could say I'm a workaholic because I'm never "off", but that wouldn't really be accurate. That would be missing the point. I'm never off because I never need to be because sometimes my on-time is the same as my off-time. That really means that my vacation days are merely on-time where my time is structured according to my choice even more so than usual.

Another Boomer doctrine is that of Free Days versus Buffer Days versus Focus Days. Everyone should take Free Days (like weekends) to recharge, Buffer Days to get the crap work done, and Focus Days to get the really cool stuff done. My life doesn't work that way. That's just another set of boxes to constrain my work style. I see every day as a Freefercus Day. Part of my day is spent working on my job doing fun stuff, not fun stuff, and whatever other stuff needs to happen to keep everything moving towards my goals. I spend another part of my day working on eating while I think about my job or fun projects. I spend another part of my day focused on my family. I spend another part of my day working on paying the bills or taking out the trash. I spend another part of my day dinking around on a fun work and/or personal project, etc. All of this blends together in my brain without strict delineation.

If I really had my way, I would give myself over to this work style. I wouldn't constrain myself to a certain set of hours. I wouldn't put myself into a cubicle box. I wouldn't announce my work hours ahead of time (mostly). In order to satisfy my team members, I could seek a compromise position of having regular meetings or daily office hours or something, but even that would be part of this unstructured system of work/life I lead. The structure of my life/work would center around getting stuff done rather than following some pre-programmed formula of time management.

For the most part, I would work day or night on my job whenever it best fit to do so. I would spend time with my wife or work on fun projects or play with my son whenever it fit, even if it happened in the middle of the day. I would work in an environment that supported my creativity rather than constrained it. I would balance the work that recharges me (fun projects, hard tasks, family time, etc.) with the work that drains me (paying taxes, data entry, meetings, etc.) The nature of the structure of the time would morph over time as well.

What works to keep me organized this month rarely works six months from now. My life would be systematically unstructured, evolving from period to period depending on my current projects, team and family needs, and other factors in my life at the moment. This is what I call Stream of Consciousness Work Style. You can like my idea of work and life or not, but that's how I roll.

Cheers.

Neat. ~Sterling has been rebuilt using the latest CMS to take the Open Source world by storm...er something. Okay, so the "secret" project I've been working on for years is finally doing something because I decided to stop being "elegante" and decided to JustMakeItWork(tm).

What have I done? Well, I wrote a little tool to help me manage the CIS Support Site for work. This little tool is a combination themer/indexer for static pages. It also does some on-the-fly generation of HTML from reStructuredText, which is what we write most of our docs in. It seemed pretty useful and is similar to the software I was using to run this site before October 2004, called Blosxom, which is a lightweight file-based blogger.

Anyway, when I had some trouble getting access to K-State Online for my course last semester, I decided to try and dump my course data into it on ~Sterling. With a few modifications it worked quite well and quickly supplanted any previous ideas I had about the content management systems I'd been toying with for the past several years.

Most of the work is already done by HTML::Mason. My system just took advantage of the features already present to add indexing and theming and generation of content from other formats. ~Sterling took it a bit further by adding the ability to generate even more complicated content (especially, ripping apart zipped Keynote "files" and using XSLT to generate HTML outlines).

At this point, I ran into a few issues:

1. Adding new generators was requiring lots of custom code and my indexing code was becoming convoluted.
2. New content had to be added with care, otherwise Mason would try to interpret files it had no business touching. When this happened, my indexer would basically bring the entire site to it's knees with a single exception.
3. Some content is just better stored in a database. Blog entries, news items, and simple records are just a few examples. The system had no way of coping with any of these.

Thus, since about the time I put Drupal on this site, I've been working on a replacement. Drupal is merely a temporary expedient. I started completely from scratch, but have dragged in a lot of the bits from the existing "knowledge base" system to build this new system, which I am dubbing as Contentment (superceding all the predecessors I'd created and called this).

This system currently features a lot of unused features, but most of the good ones are employed currently. One of the best features I just added this week and after just a few days it's practically remade the quality of the system. Specifically:

1. It features a (largely unused, as yet) forms handler that can help design forms and wizards with a fairly small amount of effort. I borrowed a lot from the kinds of work that Everything has done in this area.
2. It uses the SPOPS object-mapping system to provide a database API. It's not required that new plugins use this API, but all the existing database pieces use it.
3. The system automatically provides for context, sessions, and logins. The user accounting system is completely pluggable, so new support for LDAP or other login types could be added with a little effort.
4. The system provides a basic permissions system. All of these features have been designed to make adding database-based plugins possible, but there really aren't any yet.
5. The major feature that has really made the system work despite the lack of any database plugins is the VFS system I've put together. I've debated whether or not this should be forked into a separate project, but I'm going to leave it where it is for now. Anyway, this enhances Mason's abilities by quite a bit and allows for a much more general way of looking at files. This way, Mason no longer has primary control of generating files, but passes that control off to other plugins.
6. Right now the system works via CGI, but I'd like to put together a mod_perl front-end to take advantage of those features. I've designed everything to this point with mod_perl in mind, so it should work with minimal effort.

That's a pretty bad mish-mash summary of the features. There's a lot more I could say, but I'll save that for documentation. I'm going to admit that I've had a SourceForge project for this for eons, but that it'd never really worked until now. I'm so excited about how this is going now, that I have registered Contentment.org and will be posting information and documentation there. I'm going to, for now, use the mailing lists, bug trackers, announcements, and CVS repository at SourceForge. (Though, I'm hunting hard for a way to keep it in Subversion as I strongly prefer it, despite it's performance and other issues.)

Anyway, I wanted to announce that and say that Drupal may be saying farewell to this site soon---if I can get the plugins written and translate all of my Blosxom and Drupal entries into my new plugins.

I am told that this is a fairly insane position for a real Computer Scientist to take. In an age where static checking, managed runtimes, virtual machines, etc. are king, Perl doesn't make sense. Even during my defense last week, Dr. Mizuno asked, "So, why did you do this in Perl? This language is very strange to me." So, I'm going to try and give a defense of my language of choice.

Flexibility. If there's anything a Perl programmer is looking for, it's flexibility. Perl's motto is, TMTOWTDI, or There's More Than One Way To Do It. In Perl, there are more like 10,000 ways to do anything. For example, all of these are common expressions for saying the same thing:

# TMTOWTDI #1
if ($x == 2) { $a = "Hello World!"; }

# TMTOWTDI #2

$a = "Hello World!" if $x == 2;

# TMTOWTDI #3

$x == 2 and $a = "Hello World!";

# TMTOWTDI #4

$x != 2 or $a = "Hello World!";

# TMTOWTDI #5

unless ($x != 2) { $a = "Hello World!"; }

# TMTOWTDI #6

$a = "Hello World!" unless $x != 2;

# TMTOWTDI #7

$a = $x == 2 ? "Hello World!" : $a;

# TMTOWTDI #8 (not exactly the same on false)

$a = $x == 2 && "Hello World!";

# TMTOWTDI #9 (ugly)

goto EVIL unless $x == 2;

$a = "Hello World!";

EVIL:

I could probably have come up with more, but we start exhibithing worse and worse style if we do. My point is, I can think in Perl. I don't have to reorder my neurons to operate in one style or programming or another as enforced by a language. Perl gives me the opportunity to program in multiple styles simultaneously depending on what suits my need at the moment: procedural, functional, object-oriented (there are actually several OO styles available), spaghetti (via goto), whatever.

Features: Perl has most of the same features as Sun Java, Microsoft .NET, and other "modern" languages/language platforms. Perl, despite popular belief, is a compiled language rather than interpreted. However, Perl is usually compiled from source on every build. This isn't a requirement, however, as it does have the ability to build objectcode and bytecode executables. In fact, there are tools to translate Perl into forms acceptable for both the Java Virtual Machine and Microsoft .NET—I've never used them, so I can't attest to their efficacy. Perl supports garbage collection. This garbage collection is performed via reference counting, so it's far from perfect (make sure you break any reference loops). It is a heckuva lot faster than the stop-and-copy style of garbage collection used by Java (ever notice Eclipse or JEdit just stop doing anything for 60 seconds or that a Java program takes up twice as much memory as necessary?).

Static Checking: This is a strong sucking point for Perl. However, my collegues often tout the beauty of Python and yet, Python suffers under the same problem. The problem is that both Perl and Python allow for runtime modification of the symbol table. Therefore, I can, as a Perl/Python programmer, create new functions, removing existing function, and replace functions while the program runs. It isn't a good idea to make a habit of doing this, but it provides a great deal of power when it comes to coding.

I'm sure Dr. Banerjee and Dr. Stoughton can probably prove that such constructs are unnecessary and that by using static code we can achieve much of the same power if we reduce these patterns down logically. Bah! I am not a mathematician, just a logician. I'd much rather have the Stoughton's and Banerjee's of the world make my code safe by creating new and better compiler technology than have to reshape my mind to fit some mold. (Yes, that's an emotional argument, get over it.)

On the other hand, static checking doesn't guarantee your code works. This is the common misconception the incoming freshman has when s/he says, "It compiled without errors, so it must be right!" Wrong! Static checking can verify that your code doesn't contain any typos and that did in fact make sure that you only used your numbers like numbers. It cannot say, "Aha! Your code does what it's supposed to!" No, only humans can do that. The guys working on verification software or ways to prove that code fits a specification are closer to finding the truth on this subject. The only way to verify that your code is correct is to either logically prove that your code does what it's supposed to and/or provide exhaustive test cases for all code. Since the latter is generally impossible (unless you have the next 40 trillion years to run your tests), proving the correctness of your code is your only fully correct recourse. On the really delicate parts of my code, that's generally what I will do. However, for the more general bits (input/output especially), I will create unit tests.

Unit tests are the only way to really make sure your code is generally safe. The more tests, the better. Using good testing strategies is also important. Anyway, it doesn't matter if your code is statically checked C++, OCAML, Standard ML, or loosely checked Perl, Python, or Ruby: You must either proof or test all of your code! Thus, I see static checking as helpful, but not the ultimate answer to coding problems.

Unit Testing: Perl has a built-in unit test framework called the Test::Harness. All you have to do is create your Perl Makefile (ExtUtils::MakeMaker) or Build script (Module::Build) and then dump a bunch of test scripts in the ./t directory. On more complicated systems, you may have to use a web server or web client or some other such thing to test your code. In this case, you can use Test::Harness directly to run the tests and write in any extra stuff you need. Unit tests in Perl are easier to write than any other testing framework I've used—I've not used Python's, so I cannot attest to it's abilities.

POD: Perl uses a documentation format called POD. This language is not powerful, but it is very simple. It's superior to Javadoc because it allows for the creation of complete documentation, not just API docs. I can write POD and have it translated into man pages, HTML documentation, printable documentation, or plain text. I can have it translated into custom formats relatively easily because the language is so simple. I've also used Python's docutils reStructured Text format and have to admit it is cool because it is so flexible, but the parser itself is not. If you want something else besides LaTeX or HTML, you're SOL.

Ugly: Perl is ugly. I will agree to that. However, are there any "pretty" languages out there? I haven't met one. I happen to think that Java is really, really, really ugly (do I have to cast back and forth to and from Object every time?). C++ is pretty ugly (ever use templates?) and Java 1.5 will earn the same ugliness with it's generics too. Python is just queer without any brackets or braces to start and end your statements, but is probably prettier than most (Mr. Idiot-Programmer can't format his code badly 'cause it won't run if he does). C is completely disgusting. OCAML and SML look like Calculus equations to me and I've already told you I'm not a mathematician.

I'm sorry, but this just isn't an argument that holds much water with me. The sigils ($/@/%) are the major intimidation, but once you know what those mean, it becomes worlds easier. Perl does have a context-sensitive grammar, which is a little scary as one statement can take on different meaning based upon which construct it's placed in. But that's the scariest part. Given this:

$x = 1 if $a == 2 and $b == 3;
$a == 2 and $b == 2 and $x = 1;

The context sensitive aspect of the grammar causes both of these to work as expected, even though the and might normally throw us off. For those who don't know, Perl has two "and" operators, and and &&. The former is the ultra-low precendence version. Therefore, in general, it is the very last part of a statement to be executed. The if here modifies the context of the and though, causing both of the above statements to be treated the same, parsed as if:

($x = 1) if (($a == 2) and ($b == 3));
((($a == 2) and ($b == 2)) and ($x = 1));

That is, the and in the first statement is executed before the if rather than after, as would be expected in a context-free grammar, but counter-intuitive to human reasoning. Anyway, Perl tends to do a lot of dwimming to help out the programmer. This can get a person into trouble sometimes, but I've found the rules to be intuitive more often than say the strict grammar rules of most other languages.

All of this to say: I think Perl is ugly, but no uglier than any other language once you understand it.

Perl 6: I'm holding out for Perl 6. Perl has a long history. As such, it has grown quite a bit and inherited much that is evil from it's earlier days. Many of the objections folks have had with Perl 5 are resolved with Perl 6. It looks like 2005 may see the debut of Perl 6 and it will be a good year if it does. Perl 6 rewrites Perl 5 from the ground up and includes (as I understand the writings of Larry Wall, Tom Christiansen, and the other Perl gods):

• Static checking: The new Perl will feature a complete type system and static checking. This checking will be as strong or as weak as you demand. This will make it's type checker as strong as C if you don't want to modify the symbol table after the fact, or as weak as nothing if you want all your checking to happen at runtime.
• Better Regexp: Regular expressions are a huge feature of Perl and have become huge features of most other languages because of Perl. Perl has raised the bar by creating a new readable regexp format that allows the creation of recursive descent grammars, in addition to plain regular expressions.
• Parrot: Perl 6 will run on top of a virtual machine named Parrot. Parrot is a VM optimized for dynamically checked languages and is decidedly different from the Java VM or the .NET CLR. It is similar to the CLR in that it allows multiple languages, C++, Java, Python, and Perl to extend and use each other's code as natively as if code were written in each its own language.
• Better Coding: They've improved the syntax and general features of objects and classes. They've improved the subroutine, methods, and functions are defined and executed. These will make Perl 6 faster and better. One of the coolest new features is that every block in Perl is a closure, so there will never again be confusion as to what value was bound to a variable when executing a subroutine. Blocks can be handed around like any other value.

Finally, I do need say something about agnosticism. Language is something akin to religion for most programmers. Typically, a programmer will try one or more languages and will become and expert and follower of one or two particular languages. Mine tend to be Perl and C++ (but I do use some Bash, Java, and C too). Unlike religion, however, I don't believe there to be a one true language. (I don't really like to make Christianity a religion, but for the sake of this argument...) I am a linguistic agnostic and believe that language preference is just that, a preference. I think all languages have value, though perhaps some are much more valuable than others. I don't assume anyone is an idiot based solely upon their language choice (though, Visual Basic programmers come close). I'd appreciate if you would give me the same courtesy. Playful jest is fine, I'd just rather not be insulted. However, (dramatically) as with being a Christian, I can accept the Perl pogroms as part of my fate—along with the insults that I'm an idiot for believing in a seven-day creation. Anyway...

Those are the major reasons (I can think of right now) that I like Perl. This isn't a real review, just my opinion. The information here was drawn from my memory, so I may have stated something wrong. In general, I think Perl is cool, but you're free to think whatever you like.