Archive for the 'perl' Category

07
Dec
09

stuff i hate about perl


This would have probably been better as a tweet … but here it goes. Have you ever tried to install a module that uses something Moose-related? What do you think about the whole installation experience?

I f***ing hate that. I installed half of CPAN just to use one module. Perl guys, have you ever seen easy_install? Seen how little it takes to install something using it? You should do something about those installation times, I mean … come on! More than 30 minutes for a module? rly?

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.

31
Aug
09

nice article


I really liked this article. Maybe I’ll join Perl Ironman.

10
Jun
09

didn’t think I would say wow while reading perl code


Browsing around in stackoverflow, I found a link to MooseX::Declare. How about that perl code ? Nice, right? You bet !

Here’s a small sample from the CPAN page :


    use MooseX::Declare;

    class BankAccount {
        has 'balance' => ( isa => 'Num', is => 'rw', default => 0 );

        method deposit (Num $amount) {
            $self->balance( $self->balance + $amount );
        }

        method withdraw (Num $amount) {
            my $current_balance = $self->balance();
            ( $current_balance >= $amount )
                || confess "Account overdrawn";
            $self->balance( $current_balance - $amount );
        }
    }

25
Mar
09

perl headshot

Perl was the first programming language I learned. It felt great to be so productive with so few lines of code. Trying to provide code for this stackoverflow answer was pretty cumbersome. My first impression was : this is an easy task for File::Find, but it turned out I was wrong.

I may be wrong, but I think File::Find does something like this :


get a list of all files in directory passed as argument
foreach file
  call the supplied callback with the file as it's argument

Let me give you an example why this is not the desired output in this particular case, consider the following directory structure:

a/
a/first.txt
a/b/
a/b/another_file.txt
a/b/c/

So, let’s assume this is the order in which we will get the files in File::Find’s wanted callback. We first receive the “a/” directory, which we capitalize as the question asked, so, after we’re done processing, the directory’s name will be “A/”. The next arguments the wanted function will receive will be “a/first.txt”,”a/b”,”a/b/another_file.txt”,”a/b/c/”, and not “A/first.txt”,”A/b”,”A/b/another_file.txt”,”A/b/c”. If we keep getting the arguments like that, we would have to split the path, check and see if the directory name has been capitalized, and then apply the rename.

Hard, right? It would have been easier to get the files while keeping count of the renamed directories. So, after 9 revisions to my post, I gave up on perl, and I rewrote everything from scratch using ruby. I could have accomplished the same thing in perl pretty easy,and I’m not blaming File::Find for this, but, overall, I felt that the language wasn’t working with me anymore.

… so, it turns out I’m not productive in perl anymore. I’m won’t use it anymore. No more perl references, globs, hashes, arrays, contexts, objects etc. I’ve got to the point where they just get in my way, and I don’t find them cool anymore.

Good luck, Perl! And thanks!

P.S: I’m pretty confident that this is the behaviour the author of the question wanted :). The ruby code can be found on the question’s page




Blog Stats

  • 221,522 hits