Skip to main content

Perl or Python?

Recently at work, we have been discussing the question of Perl versus Python for file copy, ftp, email and other daily, weekly or monthly automation / integration tasks. We considered Perl because some existing tasks had already been written in it, and Perl has a reputation as the System Admin's language of choice.

I took a task that needed automated and wrote it in Perl 5.8, then refined it using CPAN (sweet CPAN) for ArgvFile, Log4Perl, Carp, and Date::Calc. I find Perl to be very functional and completely able to meet my needs, but very quirky or perhaps unsettling. You see, I have been an object oriented programmer for a while now, and Perl's class system just feels "bolted on" to me. And I really had to jump through hoops to do a try/catch, but using eval with a return flag and an END block to test the return worked acceptably. I didn't test the exception module, as I did not discover it in time.

Next I tried Python 2.5. After a quick brush-up on the language, I was able to write about half of the task, and I moved on to the refinement. Python has exception handling, logging (based on Log4J just like Log4Perl is), fair argument parsing (I still like Perl's implementation), and lots more built in. The language is much more readable, and I find it very easy to write clean code as long as I steer clear of the crufty old-school classes. Oh yeah, we also have an experienced Python developer on staff (that can't hurt!).

I really wanted to recommend Ruby, as it is an awesome up-and-coming language with the same quick one-liner hack capabilities as Perl combined with a modern language design that makes me smile. The problem was, we want to use the same language for our admin tasks and for automated GUI testing of a system we integrate with, and it didn't have a functional Win32::GUI-Tester class. If we had a Ruby guru on staff, we may have risked it. But No, I have learned the hard way that projects fail if you throw too many unknown or untested technologies together. In my quick review, it seems that Ruby is slipping into a web-language niche. I really hope it doesn't become another PHP.

So, for us the answer was ...
PYTHON!

Reference Links:
ActiveState Perl
ActiveState Python
Komodo Editor
ONLamp.com: Python Dev Center
Labels:

Popular posts from this blog

Updated ActiveRecord Code Generator

Today, I updated the ActiveRecord Code Generator a bit. I checked in changes to use primary and foreign key details from INFORMATION_SCHEMA. The original code used naming conventions to decide what various fields were used for - ID = Primary Key, Field_ID = Foreign Key to table Fields. If you want to use naming conventions, let me know and I can add a setting in App.Config to allow this (along with any "real" key constraints).
4 comments
Read more

How does Rails scaffolding select HTML input tags?

Recently, a reader saw my fix for SQL Server booleans, and asked me a followup question: why does Rails display a yes/no selection instead of a checkbox? The short answer is look in {RUBY_HOME} /lib/ruby/gems/1.8 /gems/actionpack-1.10.2 /lib/action_view/helpers, but your path may vary depending on whether you are using gem, "edge rails", etc. Anyway, look in the file "active_record_helper.rb" for a method called "all_input_tags", and notice that it calls "default_input_block" if you don't supply an input_block. Now notice that "default_input_block" creates a label and calls "input(record, column.name)" which in turn calls "InstanceTag#to_tag" which finally looks at the datatype and maps boolean to a select tag. Perhaps a wiser Rails explorer can provide us with the rationale for this, but I guess we could add a MixIn for InstanceTag that redefines the to_tag() method, or just do a dirty and unmaintainable hack l...
2 comments
Read more

Features of the Code Generator

I just updated my code generator to optionally generate validation attributes. This simple change includes App.config file entries for all check boxes, and a new checkbox for "Validation" - aka validation attibute generation. While I was making this change, I realized that I really need to pass a CodeGenerationContext object to the DbTable, DbField and ModelGenerator classes. The requester can populate the context, and pass it to the code generator. Anyway, enough about the code, let's talk about the templates. I made a simple template this weekend to generate a DataGridView column array, suitable for databinding. I'm sure my new template will need some tweaks to handle Foreign Keys better (it currently just displays them as TextBox). Let's look at a template. ##FILENAME:PR_${table.GetClassName()}_Insert.sql ## ## Generate a SQL stored procedure to insert a record into the ## specified table and return the newly created primary key ## ## FUTURE: The generat...
3 comments
Read more