in reply to Tim O'Reilly on Perl

Was I the only one who found Tim's criticism to be right on?

Do we always have to make excuses?

Replies are listed 'Best First'.
Re^2: Tim O'Reilly on Perl
by TimToady (Parson) on Jul 14, 2005 at 02:28 UTC
    No, but some of us would like to understand if any parts of the criticism are actually useful to us today. One can make all sorts of statements about things that might or might not have been, and one can throw around terms like "snobbery", but the simple fact is that the people in charge of Perl in 1996 weren't interested in or capable of turning Perl into PHP. And it's not at all clear that if we'd tried, we'd have succeeded. Or if we'd succeeded, that we'd be happy with the result today. I'm pretty happy with where Perl 5 actually got to, considering its limitations.

    But progress depends on the seesaw between the better-is-better approach and the worse-is-better approach. The first 14 years of Perl were mostly built on the worse-is-better approach, and eventually you run into the inevitable fact that a large enough pile of worse things ends up stinking. So you can view the Perl 6 effort as an attempt to introduce a better-is-better cycle into the mix, where part of that cycle is to design intentionally for the next worse-is-better cycle. Only time will tell if we're succeeding in that.

    But let me tell you that from the inside it doesn't feel like a case of computer science envy. It feels a lot more like a heavy commitment to make Perl 6 the best language we can for keeping programming fun in the 21st century. That's a commitment in time, in money, and in the realization that we'd have to take a lot of cultural flack to get where we want to go. That's okay--we knew that going in, though perhaps we underestimated the scale of those commitments. But we're in this for the long haul, and over the long haul, I think the sacrifices will be worth it, one way or another.

[reply]

      But progress depends on the seesaw between the better-is-better approach and the worse-is-better approach. The first 14 years of Perl were mostly built on the worse-is-better approach, and eventually you run into the inevitable fact that a large enough pile of worse things ends up stinking.

      I'm very intrigued by your post. Can you give an example of "worse-is-better" in the design of Perl before Perl 6?

      Update: Clarified the wording.

      the lowliest monk

[reply]

        Perhaps not having strict and warnings on by default in programs (that is, everything except for one-liners) counts.

[reply]
        Can you give an example of "worse-is-better" in the design of Perl before Perl 6?

        Not that I can speak for Larry, but I'd see Perl 5's OO model as an example of worse is better backfiring. While it was an elegant and simple way to shim OO into Perl 4 with the minimal of additional baggage, it made other stuff tricky in the longer term.

[reply]
      ...the better-is-better ....the worse-is-better
      Hi,
      Can you explain what do you mean with those two terms?
      Regards,
      Edward
[reply]
[reply]

In Section Perl News