Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Wall and Conway Answer Perl 6 Questions 24

Posted by michael from the reading-the-tea-leaves dept.
mbadolato writes "Use.perl is running an interview with Larry Wall and Damian Conway, in which they answer questions about Perl 6. Questions were selected by the ten highest rated questions posed by readers last week."
This discussion has been archived. No new comments can be posted.

Wall and Conway Answer Perl 6 Questions More

Wall and Conway Answer Perl 6 Questions

Comments Filter:
  • The exact way that the questions are selected? Do they get modded up or are they selected by the editors? I assume a little of both.

    Thanks,

  • in an article linked from the interview, damian conway explains that argv is being replaced because it's hard to explain its latin origin. since i've always been told that argv was short for "argument vector" i kind of agree.

    is damian pulling people's legs? he seems like a rather prolific hacker, surely he's not that clueless.
    • I remember it as
      argc = argument count
      argv = argument value
      Yes, Damian was joking.
      • Damian is usually joking, about something. :-)
      • Hey, I am C guy here (meaning, I don't even use perl for regexes,I know how to
        use lex ;) but C doesn't require you to name them argc and argv respectively, it
        is just a tradition.
        However, some libraries expect such symbols and some (specially frameworks) might
        provide a encapsulated versions for you.

        Does perl really make that a requirement? Can't it just do type checking, and leave
        the naming of symbols to the user's immagination?

        Please tell me this is not so, as that would mean "there is only ONE way to do it" :-(

        • Since perl doesn't have a main function per se, you can't change the parameters the same way you would a C program. OTOH, I'm quite sure that timtowtdi stands and there is at least some other way to refer the argc and arv :)
  • I for one would love to see perl6 OO and Apache 2 module chaining combine to make a web development platform I could really like! And non-painful OO is key to this. I only wish it didn't seem like 5 years off!

  • Perl 6 is a mistake (Score:5, Insightful)

    by keesh ( 202812 ) on Tuesday May 21, 2002 @11:24AM (#3558578) Homepage
    I know I'll get modded down for this. It'll sound too much like a certain *BSD post. Ah well...

    I've been using perl since the Pink Camel. I've been using it a lot. Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal.

    One of the goals of Perl 6 is to remove this problem. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same.

    The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at a hash inside a hash, for example), and the changes proposed for 6 are just making this worse. Perl was only designed for the three data types, and adding more is a mess.

    Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat, but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one.

    I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster.

    Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options [ruby-lang.org] (and if that link didn't get me a -1, Troll I don't know what will...), which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying.

    Okay, I'm done, you can mod me down now :)
    • I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster.

      My, my. Such bold statements about a language that's not even completely designed yet. :)

      I, for one, am very excited about the changes in Perl 6. I don't see the "complete mess" that you refer to. In fact, I have two main impressions from reading the Apocalypses and Exegesises:

      1. Perl 6 is going to be much cleaner. Modules, the class keyword, everything-is-a-closure, better subroutine argument passing, etc.
      2. Perl 6 is going to be much cooler. The new pair type, the smart-match operator (=~), the given and when constructs, possible inclusion of superposition (any and all), Pythonesqe saved bytecode, etc.

      I've read the Perl RFCs [perl.org], most of what Larry, Damian, and Dan have written about Perl 6, and the Perl 6 mailing lists. From what I've seen so far, the language (and the design and implementation of Parrot) are looking very cool.

      --Bruce

    • The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at a hash inside a hash, for example), and the changes proposed for 6 are just making this worse.


      Have you looked at any of Larry's Apocalypses? The sigil-switching is going away in Perl 6. A hash -within-a-has will be accessed like: %hash{value}{value}. As it should be :)


    • Reading this, Sure, my const int $var = 27; may look neat, but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. Makes it clear that you don't know what you are talking about. The "what" is that Perl is a RAD(Rapid Application Development) language, and you use "really" as if that has any meaning in a RAD language.What has been call "scripting" or RAD Languages make simple contracts with the programmer.The programmer gives the interpreter/run-time general instructions, and it gets the work done.What constitutes a "real" constant or integer is meaningless. Guess what? If you declare "my const int $i = 27;" then follow that with "$i = 1;" you will certainly get a runtime error and probably a compile time error.

      The first thing I haven't liked about Perl is that it didn't use exceptions and try/throw/catch syntax EVERYWHERE. I do network programming, and you can NEVER trust the network. And try/trhow/catch is better than "if (defined $rv) {...}" after every single last simple itty bitty stupid little elementary function call. Halleluha! Perl6 will have this.

      The second thing I haven't liked about Perl (re: has bitten me on the ass) is doing compile-time checking of the arguments of functions and methods. Sub signatures work for functions but not for methods. BTW, there are other things like named arguments, and default arguments that would be good RAD thing to have. Halleluha! Perl6 will have this!

      For other things, like switch statement (given/when), sigels for variable types are not gonna be context dependent, run-time hinting with attributes, switching '->' dereferencer to '.', and explicit declaration of classes (rather than manually creating them with package/new/bless) ... well I like them, but they weren't on my hit list. However, I am sure someone else might disagree.

      Perl6 is really going to address the elements of Perl5 that tripped up and slowed down my developement time. Hence, Perl6 looks like a new more powerfull tool for me to actually get work done with.

      I think python and ruby look very interesting (well ruby more than that special education language called python). The problem. NO CPAN. CPAN is to Perl as Ports is to *BSD; as pkgs is to Debian; as MFC is to M$; as javax.* is to java. NO CPAN == NO GOOD. CPAN is the kluged up brilliant half baked promise of open source. Half the modules are sheer utter crap, but the other half...

      • I think python and ruby look very interesting (well ruby more than that special education language called python). The problem. NO CPAN.

        Ruby has RAA [ruby-lang.org] (Ruby Application Archive). It is already as messy as CPAN, even though CPAN has lived much longer...


    • Perl 6 will be nice, but I'm guessing it will be the end of Perl.

      And what if the next perl is truly a diamond, and smokes your Ruby?

  • moving target (Score:2, Insightful)

    by Anonymous Coward
    I bought the camel book.

    Then Wall said no no no. That book is outdated. You need a new camel book.

    Ok, but then later, and not even much later, after that, he said wait, I was wrong; you need another camel book,
    a third camel book, the one true camel book.

    I didn't buy the last camel book. It has become a racket. Don't you all smell a 4th camel book in the pipes?

    Compare with a true genius like Bertrand Meyer. He designed the Eiffel language. It was a design so clean
    that only one book ever has been needed to explain the language. Not weekly revisions a la Perl.

    Larry Wall, you are a marketing genius. That is true. But as a language designer, you suck.

    • Re:moving target (Score:4, Insightful)

      by msouth ( 10321 ) on Wednesday May 22, 2002 @02:16PM (#3566804) Homepage Journal
      A large part of what has changed about Perl has been due to what (gigantic) numbers of people have wanted to do with it. It is a living language, by design, and living languages change.

      Larry's attitude rocks. I think you might be overestimating (a) what he makes on books and (b) how much he cares about how much he makes. I have no idea about (a), but I am pretty sure that (b) is not what you seem to think. Larry is one generous, genuine, and genuinely humble person, as far as I can tell.
    • I am afraid I must disagree with your assessment of Bertrand Meyer. In fact there is a striking similarity between Perl and Eiffel on (at least) one issue.

      Back when Eiffel was mainly described in BM's book _Object-Oriented Software Construction_, Eiffel had no case statement (like Perl5) and was a rather simple language, although it turned out, not flawless. And of course, like Wall, Meyer argued that the absence of the case statement was a Good Thing that Made Life Better. Enter _Eiffel, the Language_, with complicated semantics/validity rules - and! - a case statement! I have both books, but I like OOSC much better, and I will never program in Eiffel. With Perl6's introduction of the case statement, I see history repeating itself. I strongly doubt I will ever program in Perl6.

      I am just reading Fred Brooks' _Mythical Man-Month_ for the first time, and I think both Wall and Meyer suffer from some kind of Second System Effect.

      As for Perl, I now try to do all my sysadmin script hacking with Korn shell, sed scripts and other Unix tools. I don't feel less productive that way.

      -Lasse

  • Malleable syntax, closures, better OO, better exception handling, wow...

    ...who knows, someday Perl may become a Lisp. [paulgraham.com] Just like Python, Ruby, and friends.

  • I really couldn't care less about any of the other stuff -- the thing that's really going to be cool is having Parrot to hook Perl and Python together, and also easier interfacing with C.

    Parrot also has the potential to make Perl/Python into what Java was supposed to be: a write-once, run-anywhere lingua franca. Perl, unlike Java, is a real open-source project, so it's potentially immortal, and immune to MS-style shenanigans.

Slashdot Top Deals

The hardest part of climbing the ladder of success is getting through the crowd at the bottom.

Close