Pick the language with which you're most comfortable. That's our advice to reader John Wiersba, who asked us several weeks ago where he should concentrate his study.

Selection principles

For the most part, Regular Expressions concentrates on general principles or concepts that are likely to apply to several scripting languages: inter-process communication, character encodings, graphical toolkit bindings, concurrency, and so on. Three and a half years ago, though, we did a feature article, "Choosing a scripting language," when Unix Insider was still SunWorld. It's time to update that piece.

Wiersba's question is a good one. He wants to make the most of his education and experience, so he's looking for a language that won't limit him. Rather than learn several poorly, he's out to concentrate on one and get to know it well. Which one deserves his time and attention?

The technical capabilities of most of the popular modern scripting languages have converged remarkably, even over the three years that we've been writing Regular Expressions. You can largely expect to be able to do the same things with Perl, PHP, Python, Rexx, Scheme, Tcl, and other such languages: script dynamic Webpages, build administrative utilities, prototype graphical user interface applications, glue together legacy data and processes, and so on. You can code in procedural, object-oriented, or functional styles. You can expect to be able to run your scripts on Mac OS, Unix, or Windows. You can manage other processes, and script Java and COM objects. You have limited access to hardware such as serial ports, but you can extend built-in capabilities with C or other languages. Internationalization is possible and often practical. You can freely reuse any of a staggering number of modules other programmers have written.

Therefore, our first answer is to use what feels comfortable to you. If Python's use of white space makes your skin crawl, learn Ruby instead. If you want to get along with your coworkers without having to explain your Tcl or Forth mentality, you might find them ready to accept Perl or Pike. You'll be able to create roughly the same functionality no matter which language you use.

Collect your own data, talk to the natives

The successes in language choice are often instances in which a programmer gets along well with the other natives. What's most important about Perl is probably not the syntax of the language or its constellation of command-line arguments, but the cultural system of the Comprehensive Perl Archive Network (CPAN) -- maintained perldocs, good conferences, local PerlMonger meetings, and so on -- that makes practitioners feel they've found a home.

One of the most pleasant aspects common to these languages is that you can take them out for a spin inexpensively. Locating a language processor and documentation, downloading them to a host you control, and writing your first sample program usually fits within a conventional lunch break. There are extensive online information archives available for all these languages. Rather than flip a coin

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine