Because Perl uses syntax and specialized operators to differentiate its types, Perl's type system is necessarily extremely limited. Furthermore there are things you sometimes would like to do which you either can't, or have to do a lot of extra work to do, because the type system gets in your way.

The language that convinced me of this is Ruby. There everything is an object, and the syntax that exists is just syntactic sugar around method calls. Provide the right methods, and the syntax will work for your objects.

The example that I give to illustrate why this is nice is tie. In Perl you can't directly make your objects into data types other than scalars. The solution is tie. (Which relies on magic, and because of how this is internally implemented it has been a common source of bugs.) But what if you want to create something that is almost a hash, but has a couple of extra methods? (For instance you have a dbm, and you want to expose some locking methods.) In Perl you either have to use a scalar and have people use -> often, or they have to resort to tied to get your extra methods.

By contrast in Ruby there is no need for something like tie. Just create an object with the right methods and it can be used like anything else with those methods. Want a hash that has locking methods? You can easily write one! The syntax is nicer than Perl. Conceptually it is simpler so people don't get so confused. Furthermore because this isn't implemented with if statements everywhere in the code, it isn't buggy.

What does Ruby give up for this? Autovivification can't be made to work. So Perl gets some convenience in return for a barrier to scaling in complexity.

What does Ruby give up for this? Autovivification can't be made to work.

It's not clear to me from what you wrote what the barrier to autovivification in Ruby is. Can you elaborate?

the lowliest monk

Here is an example.

In Ruby when you write x[foo] then Ruby calls the [] method on x with foo as an argument. Unless that is followed by an = in which case you call the []= method instead. So by providing those two methods, that piece of syntax is supported. And lots of core data types provide those two methods.

The result is that x[foo][bar][baz] might be the equivalent of $x[$foo][$bar][$baz] in Perl, or perhaps $x{$foo}{$bar}{$baz} in Perl, or perhaps $x{$foo}[$bar]->($baz) - and that is before you get into user-defined types!

In Perl the first one of those might create anonymous arrays, and the second might create anonymous hashes. In Ruby if you're accessing something that isn't there it has to be an error because there aren't enough syntactical hints around to guess what the programmer meant.

The flip side of that is that in Ruby to create something that, say, acts like a hash backed by a dbm, all that you have to do is define a class with those two methods, and make those methods do the right thing. If you also want to add a locking method for your dbm class, you just have to add the locking method. And it works.

tie in Perl only looks impressive because Perl's syntax is constantly setting up expectations about what the syntax does. Therefore causing that syntax to do something other than what it looks like it should do is very surprising. Ruby's syntax sets no such expectations, and so making the syntax do something new does not look impressive. Until you sit down and realize that making something sophisticated look routine is a pretty impressive accomplishment!

Hmm, I'm hard-pressed to argue that point. If I were to come up with something else, I would argue that the lack of multi-method dispatch is a pretty big problem. Of course, that's sort of cheating because if you get that, it automatically implies proper argument handling and I therefore get two for the price of one :)

Unfortunately, I've seen those who have not had a chance to work extensively with MMD aren't terribly impressed by its benefits. My suggestion to them would be to take a program written in a language which supports this and try to port it to Perl. It leads to monstrosities like the constructor for AI::Prolog::Term:

sub new {
    my $proto = shift;
    my $class = CORE::ref $proto || $proto; # yes, I know what I'm doi
+ng
    return $class->_new_var unless @_;
    if (2 == @_) { # more common (performance)
        return _new_from_functor_and_arity($class, @_) unless 'ARRAY' 
+eq CORE::ref $_[1];
    }
    elsif (1 == @_) {
        my $arg = shift;
        return _new_with_id($class, $arg)     if ! CORE::ref $arg && $
+arg =~ /^[[:digit:]]+$/;
        return _new_from_string($class, $arg) if ! CORE::ref $arg;
        return $arg->_term($class)            if   CORE::ref $arg && $
+arg->isa(Parser);
    }
    require Carp;
    Carp::croak("Unknown arguments to Term->new");
}
[download]

That constructor was buggy for a long time because Perl doesn't support MMD. It was very frustrating.

If you try to implement a design that relies on MMD without having MMD, you will have difficulties.

You have not convinced me that designs that rely on MMD are a good idea. Particularly not in a language like Perl where the way people usually use the language will lead to people expecting you not to do that.

To be convinced I'd need to see a problem which interests me that I have trouble solving without MMD, which has a very nice solution using MMD that I think would not pose a maintainance problem. I've yet to see such a problem. (Admittedly I also haven't looked very hard.)

tilly wrote:

You have not convinced me that designs that rely on MMD are a good idea. Particularly not in a language like Perl where the way people usually use the language will lead to people expecting you not to do that.

Hmm, that's a rather interesting way of putting it. Let's play with the wording a bit and see if we can clear that up, shall we?

You have not convinced me that designs that rely on closures are a good idea. Particularly not in a language like Java where the way people usually use the language will lead to people expecting you not to do that.

While certainly not an exact quote, that's pretty darned close to a rebuttal a Java programmer gave me in response to my arguments about the merits of closures. No offense Ben, but those two sentences are orthoganal to each other. Just because people aren't used to X doesn't mean that X is not a good idea.

Now that we have that out of the way, let's consider MMD. MMD should not be overused, but when it's necessary, it simplifies the code and is a better solution than a bunch of similarly named methods or forcing the programmer to write code to simulate it. However, MMD and proper argument processing go hand-in-hand, so much of the following assumes we're talking about both.

For example, if you look at how dispatch tables are frequently implemented in Perl, you'll find that they're often used to dispatch on type. Thus, the programmer has to write some code similar to this:

my %dispatch = (
  Foo => \&_foo,
  Bar => \&_bar,
  Baz => \&_baz,
);

sub process {
  my ($self, $thing, $data) = @_;
  my $type   = ref $thing || '';
  my $method = $dispatch{$type} || die "Can't find method ...";
  $self->$method($data);
}
[download]

That, of course, it ugly, but it's a lot less ugly than the faux switch statements or if/elsif/else chains people come up with (and less error prone, too). To compare with MMD:

multimethod process (Foo $thing, String $data) { ... }

multimethod process (Bar $thing, String $data) { ... }

multimethod process (Baz $thing, String $data) { ... }
[download]

Not only is that shorter, it's more likely to be correct. Forcing me, the programmer, to write code to handle a common idiom that so many modern languages never have to worry about is silly. Heck, how many times have we seen the following bug?

sub name {
  my ($self, $name) = @_;
  $self->{name} = $name if $name;
  return $self->{name};
}
[download]

Now, if you need to clear someone's name, it's very difficult to do. That bug is virtually impossible to write when using MMD. What a beautiful thought. An entire class of bugs eliminated. (Of course, MMD introduces a completely different class of bugs, but in my experience, they bite far less often.)

And let's not forget that MMD potentially allows compiler optimizations that aren't possible when dealing with all of the potentiall buggy programmer alternatives. And while we're on the topic of optimizations, notice that traditional Perl code requires two sub calls for the dispatching instead of one. Perl's subs are slow enough that this could be a significant performance bottleneck on some systems. I've been hit by this and working around it can be very painful.

However, let's take a look at my dispatch code. If I want to add an extra event, I add another entry to the dispatch table. But what happens when someone does this?

$object->process($foo, $data1, $data2);

Oopsie. The code silently fails. Perl's poor argument handling strikes again! However, if I need to actually allow that, my dispatch code can get awfully ugly. With MMD, that can easily throw a nice, fatal error, letting the programmer know that no such method exists. Otherwise, I just write another method. Nice and easy either way.

And while we're thinking about argument handling, I see (and have written) plenty of code which doesn't verify the number arguments to a method. In fact, this is a debate that regularly comes up in the Perl community: how much sanity checking is required? Many hackers do very little checking and, if we're really lucky, they have test suites to catch stuff. Some put sanity check everything and then moan in horror about how slow their system is.

Guess why Java programmers don't debate this too much? Because, ironically enough, in the case of MMD and proper argument handling, they have the language doing something that the programmer shouldn't be forced to do.

PS: When you show up for OSCON, let me know and I'll buy you a beer. Or you can buy me one. Or four. I know how to dispatch them properly.

Cheers,
Ovid

New address of my CGI Course.

The lack of a common, standard packaging/deployment mechanism. Something like PAR, but... core.

Also, PerlScript and Win32::GUI not being standard (on windows platforms).

The lack of a common, standard packaging/deployment mechanism. Something like PAR, but... core.

That's because "common" and "standard" are not in the Perl lexicon.

There's a common, standard Perl lexicon?

What do you see as Perl5's greatest limitation?

For me it's the lack of de-facto standard reliable encapsulation / information hiding mechanisms for OO code.

While there are many mechanisms that can get you decent encapsulation/information hiding they all suffer one or more of:

• Being more complicated that the "standard" hash mechanism.
• Relying on external CPAN modules
• Not work well with the other N methods of doing it

• threads are not lightweight: Things you need to know before programming Perl ithreads
• Many keystrokes when working with files, esp. File::Find

I never buy the "many keystrokes" argument, for Perl or Java or AppleScript or anything. Editors for programming have been around for a LONG time. Learn to use them effectively, as they will compensate for any lack of typing skills or energy. Autocompletion tools are not a new science. Notepad is not a programming editor.

I will argue the companion point, but this again is not just Perl: way too much syntax in most of the code I see. Too much ->{} and ${@{$$x}} and \($!) in high-level code. People get in the habit of typing while they're thinking in terms of the implementation, instead of thinking in terms of expressing the solution to a problem.

I try to write my libraries such that the caller doesn't have to write a lot of syntactic noise just to get things done. In other words, the lower level code should take it on themselves to make literate programming possible at the higher levels.

--
[ e d @ h a l l e y . c c ]

Many keystrokes when working with files? Ever had to do anything file related in VBScript? That's what I call many keystrokes. Set FS = Server.CreateObject("Scripting.FileSystemObject") anyone?

Jenda


XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

you're right: perl is better than VBScript.

But it is worse than perl6, where it is allowed to do my $contents = "filename".slurp;

Currently there are limitations, but moving to right direction :)

#!/usr/bin/perl -w
use strict;

this();
[download]

And that's a problem that's impossible to solve in any perl program that uses eval STRING, AUTOLOAD, objects, require, do, symbolic references, typeglobs and probably more constructs that make perl such a nice and flexible language.

If you're really worried about missing a subroutine, you are going to need some good tests, because there are loads of problems just like it that can't ever be detected at compile-time.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

There are a number of things. Most of them, such as the object model's limitations, are being fixed in Perl6, so I don't worry about them long-term. The thing I worry about is the thing that, AFAIK, Perl6 is probably not fixing. Namely, Perl does not include a reasonably-easy-to-use cross-platform GUI library that uses the native look and feel on each platform. I'm not sure whether any other language includes such a thing, but that's irrelevant; I want it in Perl anyway. I know it is theoretically implementable.

I haven't used it yet, but http://www.wxwidgets.org looks like it fits the bill. Opensource. Win, Linux and Mac GUI framework.

perl interface: Wx

Namely, Perl does not include a reasonably-easy-to-use cross-platform GUI library that uses the native look and feel on each platform.

The keyword here is library. It doesn't need "fixing" by Perl. It can be "fixed" by anyone. You want a cross-platform GUI libray on each platform? Write one. Or port an existing one. It's a library after all.

GTK2 seems pretty good on windows, but I haven't seen what it looks like on other platforms.

I think (some of) the problems with P5OO could be adaquately addressed if methods calls and ties were faster.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

A lot of people have said what they don't like, but I haven't seen any limitations yet. Sure, you have to write more code, but Perl still hasn't stopped you from doing anything.

What is the method call performance stopping you from doing? I've found a lot of other things that are a lot slower than that, so I haven't had to worry about it. When I code Perl, I don't even think about the number of subroutines. It's not even an issue.

For anyone else who cares to post, I'd like to see a specific story about what you couldn't accomplish because Perl didn't have the power to do it. There are things that are annoying, but remember how good you have it. Merely being annoyed would be heaven to people working in other languages.

"Impossible" means different things to different people in different circumstances. I once wrote a (more or less) full-blown GA/GP framework in Perl that I ended up chucking because it simply ran too slow to be of any use in the real-world application for which I wrote it. I'd call that a real limitation. (I ended up using a similar framework in Java, which beat the pants of the Perl implementation, performance wise.)

Could it be that your Perl implementation simply sucked? I've often found that I'm the one to blame (not the language) for my sucky software. :)

What was the limitation though? What in Perl was making it unusable? Was it that you had coded it yourself? Was the Java implementation already ready for you to use? I'm looking for specifics. What did the profiler show as the slow part?

I've had a lot of opportunities to improve the performance of Perl programs by orders of magnitude. Simply saying Perl is slow sounds to me like "I didn't really try that hard".

--
brian d foy <brian@stonehenge.com>

Sure, you have to write more code, but Perl still hasn't stopped you from doing anything.

Surely you realize that you could substitute any Turing complete language (I prefer Unlambda) into that quote and you'd be 100% correct . Hell, you could probably acomplish 90% of what people use Perl for with regex only. See also, Turing tarpit.

1. An object system that's built into the language and makes sense. I think C++'s object system is better than Perl 5's. I have to dig through a sea of Class::* modules to write idiomatic OO. This is nonsense, it has got to stop.
2. Macros. You can laugh, but you can't hide... Lisp-power macros are very important, IMHO.
3. Standard deployment - like PAR. People must undrstand that the real fame for Perl will come when we'll easily install it for the "common people" who don't want to hear about PPMs and compiling modules, god forbid. They want an executable that works.

Luckily, all of the above will be fixed in Perl 6, it seems. So, I'm waiting patiently.

Perl5's greatest limitation is the lack of useable threads.

I guess I'm just naturally lazy.

Apache::ASP,

what excuse for abusing PHP will you invent now?

For embedding in pages you could take a look at Juerd's PLP: http://plp.juerd.nl

You can use ePerl with mod_perl and it is just like using PHP.

(Perl 5's greatest lamentation is supporting all the Operating Systems?)

Only half tongue-in-cheek if one considers all the developer cycles that have gone into OS support issues.

• Introspection and reflection are difficult
• SUPER:: is flaky
• No real macros (not source filters)
• No user available scoped $^H hints
• Common attitudes of non-Perl folks to Perl (write-only language, not a "serious" language, unix only,etc)
• Only perl can parse perl (AST access?)

Introspection and reflection are difficult

Could you elaborate on this one? How could it be any easier than eval $string?

Common attitudes of non-Perl folks to Perl (write-only language, not a "serious" language, unix only,etc)

I think the bigger "problem" is that Perl5 has enabled a large number of web designers to engage in programming. On the one hand, it is good to enable people to work with their machines. On the other hand, the programs that these people crank out are pretty crufty (and hence, the write-only/executable-line-noise monkier). I don't know if it is for good or bad, but I think Perl6 will likely cure this "problem". The quality of the average Perl6 program will be much higher (and lead to a better reputation for Perl6 among the CS literati), but this will be caused by a much larger barrier to entry for newbies.

Synopsis 12 on Introspection

The .meta.getmethods() method in Perl 5 would require symbol table scanning and @ISA chasing yet may still be incorrect given Perl's convention based OO and dynamic nature.

Difficult to maintain, which makes it less ideal for big applications.

What in particular do you find makes it difficult to maintain?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Here's an example from my experience. I wrote a perl script to do something via Telnet, and wanted to hide the password input. I downloaded Term::ReadKey which worked fine, but I had to go round every PC in the department installing the module on each one.

When I moved on to a new project, I took the script with me and found a use for much the same functionality, but Term::ReadKey would not install. It turns out that it needs a C compiler.

It's not exactly a weakness with the language, but if we were using C (admittedly with non-standard platform-specific extensions), I wouldn't have needed anything else as I would have hand-coded it pretty easily. In fact a hidden input routine was one of my personal library of C functions back in those days.