235575 (4) [Avatar] Offline
#1
in the above section you make comparison of a Perl subroutine with your implementation of similar in Python

Your implementation in Perl is one that is in my opinion quite verbose. There are much quicker / more readable ways of doing this - see Modern Perl book (free) http://modernperlbooks.com/ and Perl Best Practices ( O'Reily ).

This said, if you want to poke at Perl, feel free. I as a >10 year developer using Perl know only too well its strengths / weaknesses and one that is a 'two edged sword' is TIMTOWTDI or 'timtoady' as people say it ( there is always more than one way to do it ).

You see, our lovely Larry Wall ( who is the initial author of Perl and totally great guy by the way ) favors linguistics as a part of the languages design. He and others since have incorporated this as a part of the language spec from the go get which means that you have an extremely expressive language that can used to write code in a number of ways and still get a functional piece of code.

The downside is that you can express yourself as you wish up to a point and write code like your version of a Perl function. The way you illustrate can be done, true but I would not follow this pattern and many other Perl coders would not either.

I think if your going to compare in this way, you need to make this distinction. I am sure I could find code written in Python that is equally as obfuscated and confusing to read.

This said, I am myself a pragmatist and as a systems programmer am moving pretty much over to the Go programming language due to its feature set that addresses some of the shortfalls of Python that you also refer to in this section, one in particular, its support of multi-core. Go's asynchronous capabilities are 'built in' and are a 'first class citizen' in the language.

There is now a project I believe called 'Grumpy' which converts Python into Go and is being used by Google to replace Python where they can and to move to Go.

Perhaps this also could be mentioned in your comparison section and 'why should you learn Python' bit. It could be that in a few years Python is less prevalent and Go has taken over. so when deciding on a language to learn, this also could be a consideration.
Robert (1) [Avatar] Offline
#2
I agree that Python is often easier to read than Perl, but I also agree there are problems with the Perl example. I'd go with this:

sub pairwise_sum {
    my ( $list1, $list2 ) = @_;
    my $result = [];
    for my $i ( 0 .. scalar @{$list1} - 1 ) {
        push @{$result}, @{$list1}[$i] + @{$list2}[$i];
    }
    return $result;
}
naomi.ceder (74) [Avatar] Offline
#3
Thanks, both, for the comments. I'll freely admit that I'm not much of a perl programmer and I don't defend that code.

But you're right - the invidious comparison with perl is probably not very helpful. I'll think about how that might be changed.

As to Python being replaced one day by Go... that's possible, certainly in domains like web applications and systems work, but less likely in areas like data science and scientific computing.

Cheers,
Naomi
wfischer (5) [Avatar] Offline
#4
A little more on the Perl/Python comparison (which is more credible if the Perl is idiomatic).
Here is a more concise example, which keeps the same logic, and supports the "fewer inscrutable symbols" argument:
sub pairwise_sum {
    my($arg1, $arg2) = @_;
    my @result;
    for(0 .. $#$arg1) {
        push(@result, $arg1->[$_] + $arg2->[$_]);
    }
    return(\@result);
}


or less scrutably, but even more concise:
sub pairwise_sum2 {
    my($arg1, $arg2) = @_;
    return [ map { $arg1->[$_] + $arg2->[$_] } 0 .. $#$arg1 ];
}


... or, finally,
sub pairwise_sum3 {
    return [ map { $_[0]->[$_] + $_[1]->[$_] } 0 .. $#{$_[0]} ];
}
naomi.ceder (74) [Avatar] Offline
#5
Many thanks! I agree that your example is better.

Cheers,
Naomi