Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday March 01, 2007
04:45 AM

What We Can Learn From Other Languages

[ #32537 ]

I'm thinking that a talk about what we can learn from other languages would be extremely fun, though it would be tough to go to in-depth in an hour long talk. So here's a snippet of Java:

public static int someMethod (int foo) {
    // ... method 1 code

public static int someMethod (int foo, int bar) {
    // ... method 1 code

And here's how that might get replicated in Perl:

sub someMethod {
    my $self = shift;
    my $foo  = shift;
    if (@_) {
        # method 2 code
    else {
        # method 1 code

Needless to say, the Perl version has scope for plenty of bugs that the Java version is less prone to.

Or how about some SmallTalk?

hello: times say: text
    (times > 100)
        ifTrue: [ Transcript show: 'You will get bored!']
        ifFalse: [1 to: times do: [:i | (Transcript show: text) cr]]

ifTrue and ifFalse are messages sent to boolean objects. Once I grokked this, I started grepping my OO code for 'if' statements and finding subtle bugs all over the place.

Or some Prolog:

likes('Ovid', 'Perl 5').
likes('Ovid', 'Perl 6').
likes(alice, 'Perl 6').

Extracting information from those facts is trivial in Prolog, but in Perl, often involves annoying while loops and if statements.

In fact, many of my thoughts about such a talk seemed related to "here's how other languages avoid bugs by minimizing procedural code".

Other examples welcome.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'm not sure if the first example is fair. Simple method overloading in Java or C++ is generally used for functions that can take different parameter types, which isn't an issue in Perl, or to have functions with optional parameters which again isn't much of a problem in Perl:

    sub someMethod {
        my $self = shift;
        my $foo  = shift || 1;

    I think that method overloading is more tied to the fact the a language is statically typed and not necessarily something

    • Well, you say it's not much of a problem, but look at the snippet you posted:

      sub someMethod {
          my $self = shift;
          my $foo  = shift || 1;

      Can $foo be 0? Your code says 'no', but that might or might not be what you meant. Also, by the time you've finished the $foo line, you no longer can easily tell whether or not you even passed an argument for $foo.

      In my original example, the code might do strange things if too many arguments are passed, or if they're n

      • When I said that it wasn't a problem I meant that it wasn't a problem to implement. Which isn't to say that there won't be problems in the implementation.

        Some of these problems could be solved efficaciously with method overloading. Nevertheless, I still think that method overloading is mainly a necessity of static typing. Which for me is a more useful language feature and one that we have learned from since it will be included in Perl 6.


  • Off the top of my head...

    Pop-11: Assignment was done with the right-arrow operator.

    ;;; perl's $x = 10 would be written as
    10 -> x;

    Which has the advantage (as far as I'm concerned anyway :-) of reading naturally ("10 goes into x") and allowing us to use "=" to indicate equality as god intended, removing all of those "if x=10" type errors.

    Pop-11: The "updaterof" idiom (see this example []) that gave a nice way of separating access/mutate methods.

    Pop-11: direct access to the parser/compiler for the l

  • I still don't understand why the Smalltalk way of ifTrue: and ifFalse: is superior to if/else. Can you please explain?

    Other than that, one thing I can think of is the Scheme/SICP [] way of handling linked lists using car, cdr, cons, and recursion. This makes the code much more robust and much less error prone than using pointer games, as is often the case in C. Funnily enough, when I wrote similar code in Common Lisp, the people on #lisp on Freenode told me that I shouldn't use recursive helper functions

  • I recall that in "thinking in forth" there was a whole chapter about this :) Anyway I'd say: predicate dispatch, which encompasses both pattern matching, overloading/mmd, and eliminates the need for if statements and switch/case. The nice thing about predicate dispatch is that even your basic control structures remains open for change, it's the same shift from a huge switch/case and OO design. Already in perl6 afaict :).