[Roboprog]

--- Java ---

List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in <>

Map <String, String> aMap = new HashMap <String, String> ();

aMap.put( "name", "Joe");

aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy...

doSomething( aList, aMap);

...

void doSomething( List <Integer> aList, Map <String, String> aMap) {

System.out.println( "First: " + aList.get( 0) + ", Name: " + aMap.get( "name") );

}

--- Perl ---

&do_something( [ 1, 3, 5 ], { 'name' => 'Joe', 'ID' => '42 });

...

sub do_something {

my( $list_ref, $hash_ref) = @_;

printf "First: %d, Name: %s\n", ${ $list_ref }[ 0 ], ${ $hash_ref }{ 'name' };

}

------

I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

Of course Java doesn't require 500 line methods. But the bondage and discipline imposed is independent of whether or not readable code will be produced.

I actually like strongly typed languages for larger programs, but prefer something more fast and loose for smaller ones. TMTOWTDI!

[EdwardDiego]

> List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 });

You can drop the inner array, asList takes variable number of arguments.

> // I need to check if Java 8 has map literals a la Groovy...

Sadly not, IIRC they've backed off from literals towards a Guava style static factory methods, which I'm not thrilled about.

> I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

So let's say I'm a newbie Perl developer just exploring subs.

  sub stuff {
      my ($a, $b) = @_;
      print "$a and $b\n";
  }

  my $a = 1;
  my $b = 2;

  stuff($a, $b);

It works! Hurrah. Feeling clever, I move onto collections.

  sub stuff {
      my (@a, %b) = @_;
      print "$a[0] and $b{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(@a, %b);

And it doesn't work at all. @a has some additional values, and %b is undef.

So yes, let's use references.

  sub stuff {
      my ($a, $b) = @_;
      print "${$a}[0] and ${$b}{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(\@a, \%b);

Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

The difference I see, as a Perl newbie only working with it out of necessity, is that having (because you need it because of earlier design choices) more than one way of operating on data structures, violates the principle of least surprise.

[__david__]

> Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

It's not really two sets of sigils, it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much—once it sunk that references were just (safe) pointers, using them works almost exactly the same:

    int a = 1, *b=&a, **c=&b, ***d=&c;
    printf("%d %d %d %d\n", a, *b, **c, ***d);

    my $a = 1; my $b=\$a; my $c=\$b; my $d=\$c;
    printf("%d %d %d %d\n", $a, $$b, $$$c, $$$$d);

Perl even stole C's pointer syntax to make working with collections nice:

    my $a = [1,2,3];
    printf("%d\n", $a->[0]);

[EdwardDiego]

> it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much

Fair point. I guess what bugs me is that you can use collections merrily without references until you want to pass more than one collection to a function - or create a collection that isn't flattened - at which point you have no choice.

[__david__]

Incidentally, I find the -> operator more readable than the explicit dereference ${} stuff:

    printf "First: %d, Name: %s\n", $list_ref->[ 0 ], $hash_ref->{ 'name' };

[Roboprog]

I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier.

No final "right" or "wrong" choice for all use cases.

[EdwardDiego]

> I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier.

I would agree. It's the same issue Scala faces IMO - it doesn't have to be a complex maze of types and implicit conversions and implicit values, you can, if disciplined, write very understandable and clear Scala.

Sadly though, it seems a lot of developers aren't disciplined.

[mst]

With great power comes great capacity to write overly clever unmaintainable crap.