Verbosity of syntax and semantics is a persistent criticism of Java. Why, look at the concepts you have to understand (or ignore) to write "Hello, world!" in Java:
public class hello
{
public static void main(String args[])
{
System.out.println("Hello, world!");
}
}
By rough count, you have to understand (or ignore) the connection between a class and its file, how to invoke the Java compiler, visibility of methods, methods, the distinction between class and instance methods, array syntax, typed arrays, and particular details of Java's internal class library before you can give a cheery greeting. Compare that to Perl's simplicity:
say "Hello, world!";
Even that trailing semicolon is optional. Those poor Java programmers don't know how great life can be -- except that we're deluding ourselves to think that Java programmers spend their days writing "Hello, world!" over and over. Perl programmers don't. Why would Java programmers?
What do Java programmers do all day? They write classes, for one. Maybe we should compare like to like. In Java:
public class Foo extends Bar
{
...
}
Hm, that's not too bad. You have to understand what a class is and Java's syntax for inheritance, as well as visibility modifiers, but syntactically speaking that's not overtly complex and it reveals the intent of the code fairly well. Now let's consider Perl 5:
{
package Foo;
use vars '@ISA';
push @ISA, 'Bar';
...
}
Hm. That could be clearer. You have to understand packages (and that
classes in Perl are packages, but not vice versa, except sometimes), package
scoping rules, global variables, the vars pragma, a magic package
global, and the order of inheritance in the face of open classes. How
about:
{
package Foo;
push @Foo::ISA, 'Bar';
...
}
Hm. That obviates the need to understand the vars pragma, but
it's still syntactically noisy. Maybe:
{
package Foo;
use base 'Bar';
...
}
That's slightly better, but it introduces the need to understand yet another
pragma and its implications if you don't have a file in @INC (yet
another magic global) named Bar.pm.
Of course, the default Perl 5 syntax can't ever change because we don't want to screw up our embedded base. Oh dear. This may be the sound of a wall against which I am beating my head.
(Before you tell me all I have to do is to use Moose/Mouse/Squirrel/Wombat/Ferret/Nematode/Whatever, allow me to indulge in one more list: the existence of CPAN, how to configure CPAN::FirstTime, how to set up a development environment on your box, how to use a CPAN module, reading the documentation of a CPAN module, installing modules and distributions locally, .... If you're really good, I'll tell you the story of how a feature deprecated fourteen years, two months, and one day ago made the semi-doomed class patch more difficult to write.)
The point isn't even that CPAN is hard to use, the point is that common tasks should be made simple and optimized when identified. Creating a class is becoming a common task, and should get optimized in the core language. Why should people new to Perl have to immediately learn about it's arcane "a class is a package, and a special variable defines inheritance" object system immediately? I learned it, I even like it, I wouldn't want to inflict it upon others without a more gentle ramp.
The whole point to things like Devel::Declare (and by extension MooseX::Declare) was to try out features to find out which ones worked well enough to get pulled back into Core. Complaining that it will break back compat is silly, 'our' broke back compat as do all of the features hidden behind 'use 5.010'.
I'm a big proponent of moving packages out of core and out of the need for p5p to maintain them, but I'm also a big proponent of growing the core language in sensible ways
It's late, I should probably stop rambling now.
Although I more or less accept your argument that we need to be bolder in evolving Perl 5, I think you've contradicted yourself a little bit.
You're trying to give examples that are real world, but in the real world (at least in Java and Perl), pretty much all code is going to need to rely on third party libraries, so you need some sort of dependency management system. Both Perl and Java have massive codebases to draw from, much of it open source.
So a real Java programmer is going to write classes, but they're probably also going to compose their app using Spring. Which means they either need to hack an Ant script, or configure a Maven project. Neither of which is trivial (well, configuring a basic Maven project is trivial, but trying to do anything outside the One True Maven Way is not).
The fact that so much of the Java world depends on Spring, and that most of the apps written using Java these days wouldn't be sane without it doesn't seem to bother the Java community. Why are some people so bothered that modern Perl apps need to depend on Moose (or some other framework, e.g. Catalyst, DBIx::Class, or what have you)?
Re:Third party modules
chromatic on 2008-12-19T18:46:08
Why are some people so bothered that modern Perl apps need to depend on Moose (or some other framework, e.g. Catalyst, DBIx::Class, or what have you)?
I don't understand the connection to what I wrote.
My question is, and remains, Is there no value in adopting Perl 6 syntax and semantics where they are clearer and more intention-revealing and simpler than Perl 5 syntax and semantics?
Yes, a novice Perl programmer can download and install Moose and autobox and this and that to make his life easier, and he can learn to use strict and warnings and 5.012 to enable non-default features, but should he have to? Why shouldn't Perl 5.12 enable these nice features by default? Do you believe that novices will (or should have to) spend a week learning how to configure their systems for a modicum of modern productivity and to avoid the most common traps?
Shouldn't a programming language under active development get easier to use over time?
Re:Third party modules
systems on 2008-12-21T13:50:37
The connection is obvious. Moose is optimized (or optimizes Perl5) for Object Oriented Programming.
So by using Moose you overcome the problem you talked about in your post: that Perl5 by default is not optimized of OOP.
And I would like to highlight one important characteristic of Perl, Perl is supposed to make things easy: Easy things -> Trivial, Hard Things -> Easy and Very Hards Things -> Reasonably hard.
Printing hellow world, is easy, therefore should be trivial. Java doesn't make it trivial!
OOP is hard, or I would say very Hard. Perl via Moose makes it reasonably hard.
And compared to what Moose have to offer, I would say, Java doesn't make OOP any less harder!Finally, Perl is a different game than Java, I like what people were able to build using Java, but I like Perl for what it make possible for me to build!
Re:Third party modules
chromatic on 2008-12-21T18:33:30
So by using Moose you overcome the problem you talked about in your post: that [Perl 5] by default is not optimized of OOP.
Moose isn't part of Perl 5 by default. I want nicer defaults.
Re:Third party modules
kjones4 on 2008-12-19T23:14:46
The reason I use Perl much more often than Java is that I dislike Java's complexity. However, one area where Java is easier for me is class programming. I'd like to see the base Perl 5 be as simple and easy when it comes to creating and using classes. It would be an important step forward and keep Perl in touch with the philosophy of keeping easy things easy. As for Java programmers using Spring for real world problems, I think that is a separate problem for Perl to solve; once it gets around to making simple class programming easy to learn and remember.
In your “say "Hello, world!"” example, the concepts of compilation unit, scope, filehandles, the default filehandle, and probably several more are implicitly there. But as you point out, one doesn’t have to know or think about them as long as the task is simple enough to fit the defaults.
However, then you go and say that even though there is no @ISA in sight in the “use base 'Bar'” example, one still needs to know about it before one can understand what base.pm does.
So what makes those cases different?
Re:I do not follow
chromatic on 2008-12-20T19:23:12
I mentioned
@INC, not@ISAin theuse base 'Bar';example. I still have trouble remembering that it tries to load a file from the filesystem, even if I've already defined the superclass in the same file.Re:I do not follow
Aristotle on 2008-12-20T21:00:45
Well, I read “introduces the need to understand yet another pragma” as implying that you need to understand everything from the previous examples plus the new pragma. Now that I read it with your response in mind, I see that it can be read both ways.