Slash Boxes

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Thursday December 18, 2008
08:03 PM

Optimized For "Hello, World!"

[ #38118 ]

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

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

More | Login | Reply
Loading... please wait.
  • May be it's time to really deprecate some things in perl5.
  • 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 thin

  • 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'

    • 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 ca

      • 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 trivi

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

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

    So what mak

    • I mentioned @INC, not @ISA in the use 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.

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