Comment by ghshephard | Hacker News Reader

Comment by ghshephard | Hacker News Reader

I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product).

And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then.

There were two personal reasons why I left Perl.

First - I would write some code, it would do what I wanted, but then I would come back in a week (or even a few days) and have no idea how it worked. This is code that I wrote. Yes, I know this is a personal failing (I said these were personal reasons) - but, on the flipside, I've never had anything I've written in Python that I didn't completely understand how it worked any time in the future. Perl just let me write code that was too complex for my brain to comprehend. I blame implicit variables. [edit - and perhaps an over reliance on regex.]

Second, If I hadn't used them for a month or so, I used to struggle with Arrays of Hashes and Hashes of Arrays. Once I eyeballed my template, it all came back, but the syntax imposed enough cognitive overhead that I struggled with that data structure (which is one that you use a lot).

On the flip side - the very first day I was learning Python, I thought to myself, "What if I just drop an array (list) as an object in this hash (dict), or a dict in this list? Will this work?

And it did. Close to zero cognitive overhead.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

Will this work?...And it did. Close to zero cognitive overhead.

This notion of cognitive overhead (or any other kind of overhead) and how it scales (as programs get larger, applications get older, and/or systems become more interconnected) is really what's important to language and system design.

Yet most of what gets bandied about between programmers seems to involve what is nifty or what can save you some kind of overhead on mostly rather small scales. Even if a library or language feature can save you from typing another line of code 1200 times throughout a project, that doesn't necessarily mean it's a no-brainer. Ask yourself: What other kinds of costs are incurred? If your nifty doodad increases compile times by a factor of 10, or completely kills the cache across large parts of your application, or makes large swathes of the code hard to debug, it may not work out cost-benefit wise.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

Ironic in the Alanis sense, because one thing that drew me to Perl in the first place was the bog simple use of Dictionary, as compared to writing the same thing in C.

A consideration to you:

You spent 4 years of learning Perl, 4 years in which you likely also massively improved your skills as a programmer, regardless of the Perl angle. Then you went to Python, bringing in your programmer experience, probably started off with a good book and had a much happier time.

So, do challenge yourself and ponder how much of that come from having spent 4 years programming, and how much from actual differences in the languages?

It's an interesting perspective, but, seriously - for the life of me, I struggled every time I wanted to declare/parse/initialize an AoH or HoA on perl. And I'm not engaging in hyperbole when I said that my code was basically completely foreign to me a week after writing it.

Obviously developers (which I am not), and people with more discipline and structure, and write eminently readable and maintainable perl code - but as my day job was network engineering, I was just looking for the lowest cost path to get the job done.

I really did love CPAN though.

That's interesting, because defining an AoH or HoA in Perl is almost identical to how you would do it in Javascript, which is to say it looks a lot like JSON.

If it was the access and assignment semantics, the normal case is also fairly straightforward; use curly braces for hash/dict keys, square brackets for array indices.

E.g.

    my %data =  (
        foo => [
            { bar => 10, baz => 12 },
            { bar => 20, baz => 13 },
            { bar => 30, baz => 14 },
        ],
    );
    print $data{foo}[2]{bar}; # 30
    push $data{foo}, { bar => 40, baz => 15 };

Given, using array and hash references with the built-in push,pop,shift,unshift,keys,values and each used to require some annoying dereferencing that could be confusing.

Do you still find that confusing?

I'll admit to not having looked at it for about 12 years, and, of course, I'm not saying I couldn't figure out after 2-3 minutes over looking over the pattern, but it just never flowed the way it did with Python for me.

   data ={}
   data['foo']= [
      {'bar':10,'baz':12},
      {'bar':20,'baz':13},
      {'bar':30,'baz':14}
   ]
   print data['foo'][2]['bar']
   data['foo'].append({'bar':40,'baz':15})

   for x in data['foo']:
      print x['bar']

Maybe it had something to do with indices always being [] brackets and {} only being used to define the dict structure. Or maybe it got easier sometime in the last 12 years? Or, maybe you could onto something, and having come pre-primed with knowledge hashes/arrays, I just picked up python more quickly.

Anyways, it was just a personal story told as well as I could remember it.

I felt much the same way, except in reverse - perl data structures did exactly what I meant, python data structures didn't.

I don't think this is a compliment or complaint about either, just a question of different people thinking different way.

I must admit that Perl's autovivification can be nice.

Reply on news.ycombinator.com