--- 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!

> 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.

> 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]);

> 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.

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

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

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.

> 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.

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

Your reply makes no sense to me I'm afraid.

> And I didn't realize the well written Perl code compiles equally better.

Equally better?

> And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class.

Come on, seriously. Here's how I open files in Java:

    import com.google.common.io.Files;

    List<String> lines = Files.readLines(new File("/foo"), Charset.UTF8);

Why do you insist on straw-men to back up your arguments?

On the one hand, that's a pretty cool library. (with a function to emulate back-tick into an array)

On the other hand, now I have to go to the Enterprise Committee with a Permission To Install Library Form to get it, since it's not part of the base language. It might well be worth it to use Google's jar, but it's a delaying nuisance.

java 8 has

http://docs.oracle.com/javase/8/docs/api/java/nio/file/Files...

Stream<string> Files.lines("/foo", StandardCharsets.UTF_8)

java 7 has http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files... but it's not lazy.

> On the other hand, now I have to go to the Enterprise Committee with a Permission To Install Library Form to get it, since it's not part of the base language. It might well be worth it to use Google's jar, but it's a delaying nuisance.

Argh, same straw-man again mate.

Dude, this ain't no straw man, this is my life! :-)

("only the names have been changed, to protect the guilty")

Not sayin' it's a universal problem, but it's a problem for me.

So, I actually have no love for Java, and am greatly enjoying the higher proportion of scripting irb been up to lately. But I had to comment on a couple things:

> Why only that library...? I've seen it all when a Perl developer is calling out a Java developer regarding TMTOWTDI. Nice library though.

>I would like to execute some shell commands Not sure comparing to a language with an explicit complicit compilation step is fair.

FWIW, I do more Java than Perl at work, though a fair amount of both. I guess I have written both "in anger", depending on the situation.

I guess the thing that gets under my skin about Java is that it is the mandatory one true language at so many workplaces.

1) It's a library, there's no need for One True Library. Especially not in a Perl thread (CPAN is awesome). You use whatever works best for you. 2) Caught and re-thrown as a RuntimeException by the library. 3) No idea, but if I need that low level of control, I wouldn't be using a readLines convenience method. 4) Like you can pass files as a parameter, and create lists of them to iterate over.

5 - 8 are a different problem domain. But I was merely answering your hundreds of lines to read a file straw-man. I never suggested Java be used as a scripting language, if you really want to script on the JVM, use Scala, Groovy, Clojure or Kotlin.

But personally, I script in Python. Let's resurrect that old pissing match with Perl. ;)