Speak for yourself! (or maybe, for annoying coworkers???)
It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though.
For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstraction, and just shove all the details in-line. In which case, the language of mandate doesn't matter much.
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:
> 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.
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.
I can read Perl, but the only way you'll get me to read it is to write a script with bugs in it and force me to debug it. It's fun in a masochistic sort of way. Anyway, Python and Haskell are my languages of choice now.
Perl has always been the butt of write-only jokes within the PL community; just imagine Perl as Rodney Dangerfield complaining that it "gets no respect." APL is of course, the canonical write-only language, but it is completely honest and accepting about it.
I programmed in Perl for CGI in the mid 90s and didn't see anything wrong with it. It was weird, but I had programmed with much worse before then (Lotus Notes Script...whew), so I wasn't really bothered by it. That being said, I see no reason ever to write another line of Perl again.
It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though.
For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstraction, and just shove all the details in-line. In which case, the language of mandate doesn't matter much.