10
Sep
09

a small guide on choosing a scripting language



I hate posts that start with an introduction of what they’re about. If this were one of those posts, it would have started by describing what a scripting language is, and how it can make your life easier.

I’m gonna skip that and go right into a language comparison:

  • Perl
    1. every major company has at least a few scripts written in it
    2. decent speed
    3. you can debug code with/without an IDE ( you can use the Enbugger module to stop your script at runtime, and debug )
    4. there is more than one way of achieving a task ( you can find a lot of modules on CPAN )
    5. unless you have a pretty good working knowledge of Perl, writing good code may be hard. Also, writing object-oriented code is a bit more difficult in Perl than in other languages. EDIT:Moose probably is a great alternative.
    6. some of the cool modules you might want to use are very likely to be outdated ( for example Http::Recorder )
    7. you have source filters ( which means you get to create your own syntax )
    8. Perl REPL’s are not that user-friendly.EDIT:A REPL update from one of the comments Devel::REPL
    9. depending on the way you implement your objects, introspection can be a nasty task. You could, however use the Data::Dumper module to inspect any object.
    10. no support on the JVM or CLR ( or at least, not actively maintained ones ) EDITInline::Java may be something users should have a look at.
    11. I have no experience with making stand-alone executables from Perl code, but people say it can be done. See Par::Packer
  • Python
    1. you can place debugger calls in your code and the interpreter will stop there when it reaches them ( you use the pdb module
    2. great mature libraries
    3. almost everything is well documented
    4. if you don’t have access to an internet connection, and you don’t have documentation available, good libraries will provide documentation through the docstrings
    5. OO is pretty simple to do
    6. the language is pretty strict, and Python guys insist on one way of doing stuff
    7. ipython is a great REPL
    8. good code is pretty easy to write ( and maintain )
    9. the Python guys keep saying this phrase repeteadly “We’re all adults here”. This sucks, because anytime you’d like to do something in a more unusual/cool way, they will say that. Most of the time it’s “their way or the highway”.
    10. if you’d like to inspect an object, you can use the dir function:
      
      # let's assume we have an object named x, and we don't know anything about it
      for meth in dir(x):
         print meth # this will print all the methods/attributes the object has
      
    11. you can find a lot of modules here
    12. Jython covers the JVM aspect, and IronPython covers the CLR.
    13. You can easily turn scripts into stand-alone executables. One way of doing this is with py2exe
  • Ruby
    1. everything can be manipulated in any way you’d like. It’s pretty easy too.
    2. like Python, Ruby has a debug gem, ruby-debug you can use to place debugger calls in your code.
    3. even though some of the libraries Ruby has are great ( see WWW::Mechanize), a lot of them are very poorly documented
    4. Ruby has no docstrings, but has a great introspection mechanism:
      
      # let's say that the variable x is an object you know nothing about
      x.methods.each {|m| puts m}
      

      and this will show you all the methods an object has.

    5. OO code is a lot easier ( and more logical too ) than in Python/Perl. I mean, come on, decorators for static methods? And we really need the self parameter ( in Perl/Python )? I can see how that parameter would be useful when writing object oriented C code, but … people use it, and apparently, they are happy with that.
    6. you can find a lot of modules here
    7. non-technical persons can read most Ruby syntax ( and understand what it does )
    8. JRuby covers the JVM aspect, and IronRuby the CLR.
    9. There are a lot of tools to create stand-alone executables from your scripts. I’ve had great success with exerb and rubyscript2exe
  • Groovy
    1. you get to work with everything Java has to offer
    2. some nice alternatives/enhancements to Java tools , for example gant
    3. you kind of have to work with an IDE. As far as I know, there’s no way to debug code without an IDE, or other external tools. This makes things VERY hard to debug if you can’t use an IDE.
    4. if you work along with Java classes you have to be sure you’re working with updated class files.
    5. it’s a lot less verbose than Java, and pretty fun to write
    6. there is a GroovyConsole you can test code in. Almost all Java code is valid code, and can be ran from there. I use the console all the time.
    7. if you ever wanted to modify Java’s final classes, Groovy makes that possible.
    8. not being able to debug code without an IDE really sucks. Groovy people, please fix this.
    9. OO code is easy to do. If you know Java, you can get around in Groovy.
    10. My personal opinion is that Groovy code is kind of hard to maintain. Your mileage may vary.
    11. I have no idea how one would go about turning a script into a stand-alone executable.

Even though every language has it’s strengths and weaknesses, I suggest you learn at least 2. You should use the right tool for the right job, but try to limit the number of languages involved in a project to about 2-3. These are my conclusions after working with each of the languages mentioned above. Maybe you’ll find them useful if you’re trying to decide which scripting language to learn.

About these ads

5 Responses to “a small guide on choosing a scripting language”


  1. September 10, 2009 at 21:37

    Your knowledge of Perl is a few years behind.

    - For OO programming you will want to take a look at Moose (http://moose.perl.org)

    - For REPLs you will want to look at Devel::REPL (http://search.cpan.org/dist/Devel-REPL/)

    - While some modules might be outdated or abandoned (this is just Open Source and not something specific to Perl) the CPAN is steadily growing (http://stats.cpantesters.org/trends.html).

    - Use of source filters are heavily frowned upon in Modern Perl.

    - While there is no Perl implementation on the JVM, there is a lot of high quality modules that do interface with the JVM (http://search.cpan.org/dist/Inline-Java/ is one of many)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Blog Stats

  • 173,306 hits

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: