Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Perl Programming

Larry Wall Announces Perl 6 228

Chris Nandor wrote in to tell us that Larry Wall has announced his vision for perl 6 as part of this keynote at the O'Reilly Open Source Convention. You can read an announcement at Perl.org or read Chris's summary of things (like information about the from-scratch rewrite being planned!)

The following was written by Chris "Pudge" Nandor... Perl Guru, Slashcode Guru, and all around swell guy.

Perl 6 To Be Complete Rewrite (But Not What You Think)

Larry Wall and other active Perl porters and Perl helpers met on Tuesday afternoon at Perl Conference 4.0 and mapped out a what is planned to become a complete rewrite of Perl that will become Perl 6 in 18 to 24 months, with a prerelease targeted for next year's conference.

Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.

The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it. Salzenberg started the Topaz project two years ago, to reimplement Perl in C++. Though Topaz itself will not be the basis for Perl 6, Salzenberg noted that the lessons learned in the experience will be very helpful to the new effort.

Torkington led the three-hour meeting, starting off by saying what was wrong with Perl. Much of the focus on the problems with Perl centered around how increasingly difficult it was to improve, extend, and embed Perl. A rewrite and redesign are needed, he said, and maybe it is time for a hard change. So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.

Some of the primary (and still vague) goals of the effort will be to reimplement the core so it is better, stronger, and faster; improve syntax; add new features where appropriate; have better version and installation management for perl and its modules; and have a clear and automated migration path, which may include a backward compatibility mode. Some old features may be removed, like typeglobs. Others will be improved.

The group hopes to re-shape Perl community, too. Instead of one all-encompassing perl5-porters list, tightly focused mailing lists with a terminal lifespan will be formed. To start off, the mailing list bootstrap at perl.org will be for discussion of the beginnings of the project. Like most, if not all, other new lists, when it has fulfilled its purpose, it will be closed.

Wall said, "Perl 5 was my rewrite of perl ... I think this should be the community's rewrite of perl, and the community's rewrite of the community."

Specifics have not yet been ironed out. A group has been formed to begin the work, which will primarily consist of planning the work to be done. No coding is to be done at this stage, only planning and support. Roles were determined for the group, and then they were filled. They now include the perl 5 maintainer (Jarkko Hietaniemi and Nick Ing-Simmons), the language design pumpking (Larry Wall), the internals design pumpking (Dan Sugalski), the documentation manager (Adam Turoff), the system administrator (Ask Bjoern Hansen), the quality assurance bloke (Michael Schwern), the spokesdroid (brian d foy), the customer relations person (Dick Hardt), and the project manager himself, Nathan Torkington. Other porters, such as Chip Salzenberg, volunteered to consult when needed.

Some of the short term goals of this group are to draft a language specification, start an RFC channel, get feedback, and set up mailing lists, a documentation repository, and a web site. Hansen will be setting up the mailing lists. The bootstrap list will be open to the public, while the list for the intial small group of people will be closed for posting by anyone not on the list. All lists will be readable by the public, through the web, and perhaps through email. Turoff is going to be preparing the notes for the morning meeting, and foy will be posting the notes and the mailing list links on the www.perl.org web site.

This discussion has been archived. No new comments can be posted.

Larry Wall Announces Perl 6

Comments Filter:
  • by sparks ( 7204 ) <acrawford@@@laetabilis...com> on Wednesday July 19, 2000 @11:42AM (#919923) Homepage
    Building on the success of previous versions of Perl, with its famous "line noise as syntax" philosophy, Perl 6 is to borrow heavily from a certain other scripting language and introduce syntactically significant whitespace.

    In keeping with the spirit of Perl, heavy use will be made of default variables in this new system. So for example, the commonly used "print" command will be replaced by:

    And the almost-as-common "if" will become:

    Instead of "foreach" it will be possible to use:

    And lastly, any reference to "$_" or "($_)" can be replaced by:

    So a typical Perl 6 program segment might look like this.



    Larry has expressed his gratitude to the Python developers for their initial work in this area.

  • [Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]

    I feel...a module coming on. Except that I'm certain that somebody else has already written a chunk of perl code to slashguard (new verb?) an arbitrary chunk of perl code. And then they probably used slashguard.pl to post the contents of slashguard.pl onto slashdot.

    So, anybody got that URL handy? :-)

  • by Signail11 ( 123143 ) on Wednesday July 19, 2000 @11:42AM (#919925)
    C was based on B, which was designed almost entirely by a single person. K&R literally wrote the book on the pre-ANSI C language. C89 codified most of original C. C99 represents only minor changes to the specification of the language (restrict, long longs, and implicit casts to UDTs in actual parameters being the more important changes). C++ was designed by Stroustroup, but unfortunately the committee made some elephantine changes to the language. STL and namespaces is about the only good things, IMHO, that came out of standardization. The latest ISO C++ standard has certain flaws (limits on access of friends, among other things) that I think severely degrade the usefulness of the language.
  • The talk about rewriting Perl in C++ is misguided. C++ is not necessarily better for all projects than C. C++ helps with large systems, yes, but can also provide more portability problems and many more traps for programmers. "Rewrite system X in pet language Y" is the standard hacker move, though it may not have any point whatsoever.

    Just coming off of a large project written in C++, I'm not sure I would do it again. C++ used lightly (variable declarations in for statements), or used with full Object Oriented Design can be a boon, but is just so much rope for you to hang yourself if just look at C++ as a language with lots more features.

    This is irrelevant, of course, and I see myself starting a C vs. C++ battle, so I'll shut up. The bottom line is that rewriting an existing, working, and reliable program in another language--for no real reason--doesn't make sense.
  • Your example of some Perl code:


    The problem isn't so much Perl as the syntax for regular expressions. They are designed to describe patterns of characters in as little space as possible. Perl actually helps things. For example:

    # Remove any HTML tag in the submitted code
    # that is not in the list of okay HTML tags.
    $submitted_code =~ s
    # search for ...
    < # start of HTML tag
    (?!$okay_tags) # do NOT match $okay_tags
    [^>]* # any number of characters EXCEPT the HTML close
    > # end of HTML tag
    # ... and replace with nothing
    # globally, ignore case, eXtended regexps

    You can write bad code in any language. Perl is just about the only place you can write clear, well-commented regexps.

    [Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]
  • O.K. a Perl anti-zealot

    Now if your concerns are aestetic and are bothered by the overuse of symbols I doubt there will be any change in Perl 6 that will convince you.

    For example the data type differentiators ($,%,@) are kinda central to the language. And like almost any unfamiliar language dialect, it looks odd at first glance. Symbols are symbols and all languages are built from symbols. Take an uninitiate and give them some C++ code, Perl code, Pascal Code and and maybe some Greek and ask them which is more intuitive and aestetic - to them it would all look like line noise.

    You could look at this way Python enforces indention style with mandatory whitespaces. Perl enforces variable nameing style with a built in variable naming convention ( $ -> scalar data, @ -> arrays, % -> hashes).

    BTW, your original complaint about Perl's loose typing is also true with Python. For alot of programming chores its a feature not a deficiency.
  • I suppose it's true that if I were a typical perl programmer (ie - stupid) I would find writing writing that Java code over and over again pretty tedious, and I would prefer the one-liner approach to everything.

    Fortunately, I'm not, so I don't write the same code over and over again. I write it once, and make use of it for years on end. It's called good program design - maybe you should try it.

  • That isn't because of the type system being too strong in Java, it is the lack of the concept of a tuple, or of multiple return values and simaltanious assignment.

    The language Dis is very strongly typed, but it has a tuple type, and you could do this:
    int z, z;
    string y
    x,y,z = function();
    Or you could so long as 'function' was declared to return 'tuple(int,string,int)'.

    Yes, that would require a 'rowFetch' for each kind of row, but I'm not sure that is a bad idea.

    There are other strongly typed languages with 'vartype' escape hatches, which let you have the advantages of strong types when you want them, and the advantages of weak types when you want them, with the disadvantage that the compiler is more complex, and you might have to maintian code from someone who used weak types everywhere....

    P.S. Dis is really a cool language. It has full GC so objects with cycles won't hurt it (like they do Perl, at least Perl5), but reference counts so non-circularly referenced objects have a predictable destruct time allowing you to use the C++ style "resource allocation is object creation" idom which makes exception handling and the like so much less painful. Alef is similar in some ways, and has some other intresting concepts.

  • by Saucepan ( 12098 ) on Wednesday July 19, 2000 @01:10PM (#919938)
    You don't actually need an explicit return:

    sub foo { "bar" }

    This is actually how "use constant" works internally: it fakes up a subroutine that (implicitly) returns the requested value.
    Since the subroutine is defined at compile time, and the compiler sees that it returns a constant value, the constant value is inlined in place of the subroutine call.

    So, constants work and are exactly as fast as you'd expect, even though it may seem odd to people without backgrounds in functional languages that a constant is really a special case of a function, but with a built-in performance hack. :)
  • by Anonymous Coward
    I hope 'faster' is not in fact one of the top three, or even top twenty, design goals. Right now, $2,000 worth of Linux/Intel server can handle CGI-driven sites that do tens of thousands of page views a day without rolling interpreters into Apache or optimizing the CGIs. (I build such sites in Python, which is by most accounts roughly comparable in speed to Perl--Perl believers would probably say slower.) By tuning the software, performance gains of up to an order of magnitude can be wrung out. Relatively small increases in hardware budget also have dramatic effects on your performance ceiling.

    If a "preview release should be available by next summer," significant amounts of production software can't be expected until 2002 at the earliest. By that time, current software will perform 3-5x faster on equivalent hardware.

    Given Perl's huge installed base, I have no doubt that there are dozens, hundreds, maybe even a few thousand programmers who could benefit from a faster Perl two years from now. But for the majority of the world, the speed that matters is programmer productivity. I hope the Perl 6 team focuses on that.

  • by sandler ( 9145 ) on Wednesday July 19, 2000 @11:43AM (#919944) Homepage
    PHP isn't really a competitor to Perl in the CGI space. PHP is embeded in an HTML page, whereas a Perl CGI is more likely to be in the backend, or at most generating HTML. There are HTML::Embperl [apache.org], ePerl [engelschall.com], and maybe other embeded perl options, but probably the way most people use Perl is not comparable to PHP.
  • A complete rewrite? This, from the man who advocates laziness in programmers? :)

    The problem I have is that Perl interpreters seem to be pretty low on most companies' upgrade lists. My current employer still runs 5.005, on both AIX and Solaris. If I can't convince them to upgrade to 5.6, 6.0 seems right out. "There's a chance of older scripts breaking, right? 5.005 works for us now, right? So why bother?" Bah. It sucks that businesses are run by businesspeople. ;) Oh well, I've seen worse... a web hosting company (which advertises on Slashdot, btw) runs 5.004 on Linux boxen. It somehow seems worse that Linux people not be up-to-date on this stuff.

    Question for anyone who knows: which version does /. use?

    It sucks that any cool new things I could do with Perl 6 are pointless if I can't use them at sites with older interpreters. I think the next Slashdot poll should be,

    Which version of Perl?

    [x] 5.6, the latest and l337est
    [ ] ($version < 5.6) || ($version > 5.0)
    [ ] ($version < 5.0)
    [ ] Whichever comes with Red Hat 6.2
    [ ] Uh, ActiveState 95?
    [ ] I use Python, fool!
    [ ] CowboyNeal, painted blue, thinking about the number "1", eating a rare steak


  • Actually, to write a basic cat, all you have to do is:

    print while <>;

  • "We can rebuild it. We can make it '...better, stronger, and faster...'"

    Now all I want to know is if those funky Lee Majors sound effects are going to happen any time I access a page with a .cgi extension...

  • The Perl Power Tools: The Unix Reconstruction Project [perl.com] appears to be as complete as it's going to get.

    The " Doneness [perl.com]" listing indicates that virtually all of the commands are done, and the last date that something was updated was in June 1999.

    It may well be effectively complete. I don't think PPT has taken the world by storm, though...

  • by Shoeboy ( 16224 ) on Wednesday July 19, 2000 @11:46AM (#919957) Homepage
    Hey, I like my C++ short and terse too, but I don't care for entire subroutines mostly written in punctuation.
    This is a myth. You can right perfectly readable and maintainable perl. I currently prototype web pages in perl using cgi.pm and hand it off to an asp developer who translates it into VBscript asp's and cleans up the user interface. The guy had close to zero perl experience when he started, but was able to read an understand my perl almost immediately.
    You can write unreadable perl, and that's a godsend for 1 shot scripts, but you can also write very readable perl. It's a language of acceptable subsets.
  • by EvlG ( 24576 ) on Wednesday July 19, 2000 @11:46AM (#919958)
    I really think that one of the reasons that the Perl modules are SO useful is due to the lack of strong typing ala Java.

    A PERFECT example of this is the DBI library. In Perl, it's simple. You can even do

    ($id, $firstname, $lastname) = $sth->fetch_row();

    In Java, with the JDBC, you have to do this:

    (assuming rs is a ResultSet object)
    int id = rs.getInteger(1);
    String firstname = rs.getString(2);
    String lastname = rs.getString(3);

    (forgive the syntax if it isn't 100% correct; you should be able to understand the point though.)

    The point? Because of Perl's lack of strong typing, it's a hell of a lot simpler to get what I need done: extract a userid, first and last name from a database.

    Lots of other modules are like this as well. The result? A looseky bound language that makes it really simple to put different modules together to get something done. In my years of experience in using C++, this is pretty difficult to do: everyone does the data storage differently, leading to a variety of problems. This is still true in Java, but to a much lesser degree.

    This is why Perl will never be burdened with strong typing.
  • You've not played with mod_perl much have you?

    I guess I should really qualify these things. Every other person asks me this. Yes I've used mod_perl, and I've even found better solutions ( such as FastCGI ). This was really the type of general purpose solution I was talking about. The PHP comment had to do with how quickly you get get a dynamic web site up. A Cold Fusion engine referred to a potentially higher throughput engine.

  • Perl is great, until you work with C for a while, come back, whip up a quit solution involving multidimensional arrays, find it doesn't work, and spend half the day trying to figure out the right syntax to get it to work with references and all.

    Also, structures would be nice. It's easy to do using hashes, but it's a pain to type. I'd suggest the dot notation, but it would break concatenation. Are there any symbols left for this?
  • Trust me on this.

    Wait for 5.6.1 (which will be out fairly shortly).

    If you must use the new features, then figure out how to get the current development version of Perl and use that.

    Otherwise you will get burned.

    (Hint to the wise. Saying that *.0 releases are stable is a marketing label. This is definitely the case with 5.6.0.)

  • Will perl 5 source be 100% ok with perl6 or will i have to rewrite code?
  • by Broccolist ( 52333 ) on Wednesday July 19, 2000 @01:40PM (#919970)
    I agree that weak typing in Perl is a good thing. But you make it sound like it's a panacea, which imho it isn't. The thing about strong typing is that though it slows down initial development time and is generally a pain, every so often it helps you catch an obscure type-related bug at compile-time. When you have a 500k-line project in constant evolution, catching those bugs is much more important than saving a bit of initial development time. In a 500-line perl script, the initial development time is more important. So the strength of a language's typing is really a tradeoff.

    Also, strong typing can be more efficient. When you say getInteger(), the compiler doesn't have to waste cycles trying to figure out if it's an integer, string, float, etc.

    BTW, C++ allows you to emulate weak typing where it's appropriate, using operator overloading. Say I've created a SpecialInt class that contains an int, plus does some other special stuff I need for some reason, I can make it interchangeable with an int, like this:

    class SpecialInt

    SpecialInt(int i);
    operator int() const;
    /* ... more stuff */

    void f()
    function_that_takes_a_SpecialInt(5); /* legal because of the constructor that takes an int */
    int bar = foo; /* legal because of the operator int overload */

  • It's simple: Perl parses and compiles regular expressions at compile time. In C it has to be done at runtime. Now, compiletime == runtime in Perl for the most part ... except if the script persists, as in mod_perl or fast_cgi or any daemon for that matter, as opposed to plain old CGIs and commands.

  • by EEEthan ( 41747 ) <emh26@columbiaNETBSD.edu minus bsd> on Wednesday July 19, 2000 @11:12AM (#919974) Homepage
    Change is scary. But it sounds like this change will be pretty transparent to programmers; perl will continue to get faster and better, still stay easy to use, and Larry Wall is still a little crazy. Well, it sounds like everything is right in the world.
  • Sure... I just go and buy myself some Perl books for the "old" version and then they have to go and make a new one. :)
  • Perl's text algorithms were designed and coded by experts and optmized over time. The adhoc regex function Joe Coder writes will NOT be nearly as smart. Thus Perl can be [much] faster than C in some instances.

  • by ajs ( 35943 ) <ajs@nOspam.ajs.com> on Wednesday July 19, 2000 @11:49AM (#919982) Homepage Journal
    The above is also found in it's original form at use.perl.org [perl.org]. use.perl.org is a great site, and also based on Slash (the slashdot.org engine).
  • by BlueLines ( 24753 ) <slashdot&divisionbyzero,com> on Wednesday July 19, 2000 @11:50AM (#919983) Homepage
    First of all, here's a list of things i don't like (just so you know i'm being fair):

    1) The lack of constants: The only way to do constants is to create a subroutine that returns whatever value you want to be constant, ie: sub foo{ return "bar";}
  • Here's a regexp I saw in some perl yesterday:


    Think it's unreadable? What about this sentence:

    "Cette phrase en francais est difficile a traduire en anglais." (From Douglas Hofstader's "Metamagical Themas")

    The point is, it's impossible to read anything until you know the language. I know that the above perl reads "zap all html tags not in the list of ok tags. " (Of course, I have the benefit of knowing what the context for the line was).

    So, yeah - perl is ugly unless you know it.... just like any other language. Also, I think C++ uses all the punctiation that perl does, just not as often :)

    -Dave Turner.
  • >Err, that's not even vaguely true.

    I am going to assume that you've dealt with the perl core code, so I'm not going to debate with you. But to defend myself to others, let me say this: Scalars are a dynamic type which encompases integers ( in optimized cases ), floating point, strings and references ( which are the basis of most perl complex datatypes, including objects ). When in doubt, perl makes something a string. To my knowledge, DBI reads come in as strings ( I could do a test, but frankly I don't care enough ). Flags in the scalar object specify if it is currently in int/float/string/pointer form, and it's possible to flip flop around in most directions ( even from a pointer ). Because of this, you can always treat the scalar as a string. Hense my comment.

    I think your biggest reaction had to deal with the defamation of perl sophistication, perhaps likening it onto something like COBOL, which uses pseudo-ASCII numbers ( 4 bit digits, if I recall ).

  • Hm.

    print while <>;

    How about one better?

    print <>;

  • Wrong, Perl excels at text manipulation and the web is mainly...text. Try doing text manipulation in C or Java and see how much more quickly it can be done in Perl.

    C does'nt really have to suck at string manipulation, it just happens to, thanks (or no thanks at all) to the crappy, insecure, C library.

    It's a shame nobody cared to spec out a standard text handling library in C? Or it has been done but I'm not aware of it. I know of DJB's effort ... as used in Qmail ... it's funky though, and not exactly standard by any means.

    C++ is k3wl in that respect, but I used to get a bit alarmed at the the ASM code I was getting ... oh wait that was a long time ago. 68k assembler. Duh. Nobody does that anymore. Oh forget it.

  • Actually, the example doesn't show at all that you can only do that due to the lack of strong typing. Strong typing doesn't forbid list assignment! I could well imagine a weakly typed language with a syntax like:
    (int $id, string $first, string $last) = $sth->fetch_row();
    Or a strongly typed language that has functions returning tuples and has tuple assignment.

    -- Abigail

  • by Abigail ( 70184 ) on Wednesday July 19, 2000 @09:25PM (#919995) Homepage
    What'd be really great is if 'use strict;' were the norm

    If you put export PERL5OPT='-Mstrict' in your profile, then it will already happen.

    -- Abigail

  • by Abigail ( 70184 ) on Wednesday July 19, 2000 @09:30PM (#919996) Homepage
    ActivePerl is just the version of Perl for Win32 that was compiled by Activestate. Perl compiles out of the box on Win32, for multiple compilers even. Unfortunally, most Win32 users don't have a compiler, or don't know how to compile. Hence the popularity of precompiled versions (something the Perl community usually doesn't recommend - you won't find a long list of precompiled Unix versions on CPAN for instance). ActiveState is not the only one making precompiled versions of Perl available; it's just the most marketed.

    -- Abigail

  • You just KNOW there's gonna be a perl script that will convert your old perl scripts into your new perl scripts. The only question is... will it be a one-liner?


  • Hi. Read this: http://www.kuro5h in.org/?op=displaystory&sid=2000/7/18/122257/231 [kuro5hin.org]. Please don't b-slap me; this is important! Mkay?

  • by Anonymous Coward on Wednesday July 19, 2000 @02:03PM (#920000)
    I'm at the perl conference right now (using their wireless connectivity which is pretty cool), and I saw Larry Wall's keynote speech. He said "I hope we have 100% compatability with all Perl 5 scripts, but I don't think that will happen [with Perl 6]. If we have 100% compatability with 80% of the scripts out there, that's good in my opinion. If we have 95% compatability with 100% of the scripts, that's good. As long as we're in the ballpark, it's ok. You have to break a few...umm..somethings to make an omlette."

    .anonymous coward.
  • I've never much cared for the way variables are declared and used in Perl (scalars?). Too much use of symbols, not enough grammar.
    Hmm... I like it. When the language has built in support for complex datatypes it's useful. Take T-SQL for example:

    DECLARE @bob varchar(255)
    SELECT @bob = max(bob) FROM tbl_bob

    It's unfathomably useful to be able to tell at a glance whether you're dealing with a variable or an attribute of a tuple.
    Perl is the same way. I find it nice to be able to tell at a glance whether I'm using a scalar or a list.
  • LOL... sure, it'll work. Just sort of throw some mental hints to the stuffed camel on your monitor while you bang on that space bar, and the interpreter will figure out what it needs to. :) That, and Perl 6 will introduce "impressionist" programming. Example: here is my impression of what a database call "feels" like.
    #@%(&) .. #)%*(-#%(#_(_

    *&#$//\\D)(*# Come on baby, CONNECT ';][@_(#';';

    Hmmmm... funny, that looks just like Perl 5.



  • (ack. I'm sure IE was written to piss vi users off. Pressing Escape shouldn't clear the text box, FFS)

    > about a kajillion different ways to do the same
    > thing
    Otherwise known as "There's More Than One Way To Do It", one of the central mantras of Perl :-)

    The way I see Perl is that if you have a messy mind, you'll create crappy perl. If you've got a focussed mind, you'll create focussed perl. You impose the discipline on perl, it doesn't impose the discipline on you. It's the most direct and natural way I've ever seen for transferring thoughts to real code. (Painting By Numbers doesn't count).

    > language-based improvements
    I don't see what improvements there could be.

    When I learnt to program in BASIC, I felt there were things missing, although I only had a vague idea of what they were. I moved on to C and found lots of the gaps filled, but still that nagging feeling something was missing.

    I found perl, and I've *never* thought "Hrm, I wish Perl did " or "Why does it do it like that? It'd be much better like ?" about Perl...
  • Perl really doesn't have a way to declare a constant

    And neither does C for that matter, but you never hear someone complain about that. Pascal does have constants though.

    Of course, you might argue that C has

    # define FOO 1
    well, that isn't C, that's the C preproccessor. And you can use the same C preproccessor with Perl; just use the -P option.

    -- Abigail

  • I find Perl especially aesthetic, especially those dollar signs -- the ones in front of the multiple digits on the checks my employer gives me for writing Perl code.
  • I bet you like hungarian notation, too, you moron.
    Don't complicate the language with functionality that belongs in the class/object browser.

    Class/object browser? My copy of vi doesn't have this thing.

  • Yeah I noticed that a few months while browsing p5p's archive ... and I was quite shocked. Larry Wall was commenting on a poster's obfuscated perl and told him that it took him only a split second to figure out what it meant ... "but you have to keep in mind that I won the IOCCC both times I entered". Hell, me thinks he's been playing a bad joke on us for all that time ...
  • see www.python.org :-)
  • No... The question is, which version of perl will it run in.
  • by ajs ( 35943 ) <ajs@nOspam.ajs.com> on Wednesday July 19, 2000 @12:01PM (#920027) Homepage Journal
    I see a lot of standard "I don't like Perl 'cause it's ugly" and "Perl is line noise" sort of comments that I've been seeing since before anyone had ever heard of the language (back in '91). The following links are places that y'all should prowl before trying to discuss what perl "should be". You certainly don't have to like the language, but before discussing the things that make the language usable you should understand what it's TRYING to do.

  • I've been speaking French about as long as I've been learning Perl. I understood the French instantly. I still don't really comprehend the Perl.
  • This is the reason I believe Perl needs work before being used for anything serious. The above example though contrived shows one of the dangers of Perl. In a strongly typed language if I do

    String ssn = rs.getFloat(4);
    String firstname = rs.getString(2);
    String lastname = rs.getString(3);
    float cash = rs.getString(1);

    I will get an error or thrown Exception for trying to convert a float to a string without a cast while in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.

    PS: Automatic initialization of variables thus causing typos to be treated as variables is another pet peeve of mine. Besides that Perl is really good at quick-and-dirty text manipulation which is what it excels in.

  • Too much use of symbols, not enough grammar.

    The way I've expressed this thought is:

    "Perl is APL on LSD"

  • by pudge ( 3605 ) <slashdot AT pudge DOT net> on Wednesday July 19, 2000 @12:23PM (#920032) Homepage Journal
    Yes, there is. Most of the core Perl developers call "5.005" "5.5".
  • use constant foo => "bar\n";
    print foo; # or foo() under strict 'subs'

  • by Iron_Slinger ( 126682 ) on Wednesday July 19, 2000 @12:24PM (#920034)
    You can also use the following.

    use constant FOO => 1;

    I believe the following also works. Check out "Advanced perl Programming" from the only Publisher out there for more info.

    *PI = \3.1415927;

    I've had probs with the last though.

  • I agree with Shoeboy, Perl isn't that hard to read. I'm not even a Perl-Master or anything. Perl is one of the easiest languages I've ever had the pleasure of learning, you can start writing useful programs in about a day. Sometimes it's hard to read the regular expressions, and most of the time, when I'm reading code, looking for bugs, I glance past the regular expressions, keeping note that there was one, if I don't find a bug, I then go back and examine them. They're easy to pick out, once you spend a week or so on them, they aren't so hard to decipher.. that's actually how I learned regexps, by looking at an parser which I knew worked and I had the original data file handy. An O'Reilly book or the Perl Documentation page [perl.com] at your side helps too.
  • Perl MAY have strong typing, but it would certainly be optional.
  • Ooh. Message for the perl gods then:
    call it something else...please
    Wasn't it just a few months ago that Larry Wall was saying he was going to leave Perl alone for a while? I welcomed that, this is a bit more ominous. Great to develop a 'new thing inspired by perl' but if it's not perl, don't call it perl...

    WWJD -- What Would Jimi Do?

  • I've got enough to last me a lifetime, really... Which is the entire point. :) (Barring a bitchslap, of course.)

    --Enoch Root, the Human Karma Torch

  • Why put a comment next to it? Why not in the regexp?

    < (?# Match the beginning of the tag)
    (?!$okay_tags) (?# Match all non-ok tags)
    .* (?# Match anything after them)
    ?> (?# But only until the first >)

  • Most likely there will be pragmas that turn on the new syntax.

    For example.. The new regular expression package can only be used by typing
    use re;

    Most likely there will be a requirement to say
    use 6.0;
    To make sure of the new engine. The older engine will probably be linked out for use in compatibility scripts. For example. the use of '&' in a reg ex makes the entire perl engine react differently; Likewise, finding a module that makes use of the new syntax would affect which interpreter / library is loaded in memory.

    I hope that they find a clean way of doing this. A rewrite really should not feel like bolted on code.
  • Actually, Perl 5.005 allows typed variables. I tried designing with it, and it really gets combersome.

    # Class A; Class B inherits Class A

    my A $obj1 = new B;
    my B $obj2 = $obj1;

    I liked it because of the supposed optimization of the pseudo hashes, but I found myself typing 3 times as much to do incredibly simple tasks. Personally I like building OO libraries ( makes my work easier down the road ), but the "bolted on" perl OO model takes a lot more work when an attempt is made to be clean and concise, which you need to do every now and again.

    That said, I definately agree with you about how powerful perl is when it comes to data manipulation such as in databases. I can throw together a complete CGI/DBI web site in minutes, for prototyping, then go back later and structure all the function calls when there's time.

  • My ASCI interepretation: beuwwahhhhwahhweewummwummm.... bummmmwwahhwahhhweewummwuummwummm... Thank you, I'll be here all week!
  • I think they should call the new Perl version gperl2, just so they can follow suit with the confusing libc5->glibc2 shift.
  • Hey, no fair! Firstly, I'm not a Python zealot. I don't even really know Python too well yet.

    My point was, I just don't find Perl to be particularly aesthetic, and was wondering if anything is going to be done to fix that in the rewrite...

  • Larry Wall - home page unknown, EMail address unknown

    Grand prize in most well-rounded in confusion (1986/wall.c)

    Most Useful Obfuscation (1987/wall.c)

    From ioccc.org [ioccc.org]

    And you people WONDER why it's hard to read PERL code?

    And yes, I have written readable PERL code. I have also written a regex script to parse my VB code and alter function parameters as a global find and replace... If you can't read regex, you won't be able to read well written PERL code that uses it. I find that most people who accuse PERL of being dirty and hard to read simply can't read regex.

  • The way I see Perl is that if you have a messy mind, you'll create crappy perl. If you've got a focussed mind, you'll create focussed perl. You impose the discipline on perl, it doesn't impose the discipline on you. It's the most direct and natural way I've ever seen for transferring thoughts to real code. (Painting By Numbers doesn't count).

    This is a good point, well received.

  • by cps42 ( 102752 ) on Wednesday July 19, 2000 @12:36PM (#920065) Homepage
    Direct financial support was for ActiveState, the folks that ported Perl to the Win32 platform, and continues to port Python for Win32 as well. In fact, it's noted that ActiveState will be in VStudio 7.0 on the front page.

    As another aside, I'd say this is a Good Thing (tm) for those of us that have to admin PC's running Linux, Solaris, Win2K, WinNT, and Win98, Sun boxen, and Mac's all in the same campus. That's the advantage of Perl. And thanks to M$ for finally supporting something that someone else wrote without trying to take it over. They should get credit where credit is due.

  • by Phrogman ( 80473 ) on Wednesday July 19, 2000 @12:37PM (#920066) Homepage

    Depends on what you mean here. I use PHP scripts to present information drawn from my mysql database as webpages definitely. But I also use it to publish static html pages, create text files, ftp files from one server to another, verify data values in my database etc - all tasks that could have been done in Perl (and perhaps more effectively) but which I have done using PHP simply because I am more familiar with it than I am with Perl. In this sense, it is a competitor with Perl, in the sense that most sysadmins will not be writing their maintenance scripts in PHP, no it is probably not in competition with Perl.

    Overall I find PHP scripts are easier to decipher when you return to them 6 months later to make a change, I think it has a simpler syntax and some very logical improvements over some aspects of Perl, and for these reasons I prefer it. Mind you there are some older scripts written in Perl that I still occasionally have to tweak, but most of these have been replaced by PHP scripts whenever the need arose.

  • Yes, I realize that PERL was written in C. I also realize that nasm (the assembly compiler) was written in C, and that C itself was written in C.

    Still, Slashdot did post a "benchmark comparison" study a couple months ago, which found that text parsing "as written by experienced, competent programmers" in C didn't hold up against Perl's text parsing.

    I agree that it's a little weird to benchmark something against its parent. Maybe what they meant is "PERL handles text better than YOU."
  • by Christopher Thomas ( 11717 ) on Wednesday July 19, 2000 @11:15AM (#920071)
    Will perl 5 source be 100% ok with perl6 or will i have to rewrite code?

    The impression I get from the article is "mostly compatible":

    So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.

    You'll probably be ok, but no promises, assuming they don't change their minds during the next year or so (remember, they're just _entering_ the planning stage now).
  • Over the years, I've hacked around in Perl, never really caring much to fully learn it properly in the same way that I've learned C/C++/Java and more recently, Object Pascal (Delphi). I've got 4 pretty good Perl books on my shelf, and haven't really even bothered to get more than a few pages in ... using them mostly as references for when I inherit a Perl project from some other poor soul.

    It always comes off to me as being a sort of a 'dirty' language in that there are about a kajillion different ways to do the same thing - and I've never much cared for the way variables are declared and used in Perl (scalars?). Too much use of symbols, not enough grammar.

    The limited Perl I have written has filled me with nothing short of a maniacal desire to become a darned good Python programmer.

    I understand that Perl ties a lot of the web together, and it definitely has its uses, but my initial reaction to the news that Perl was getting a rewrite was "about time, coz it's a gnarly language" ... I guess however, that this rewrite will address the engine more than the language itself, no?

    What language-based improvements will this rewrite address, any of you Perlverts know?
  • by sandler ( 9145 ) on Wednesday July 19, 2000 @11:20AM (#920079) Homepage
    He announced his vision for Perl 6. Please try to keep the headlines from being completely misleading....
  • Theoretically, you could link to the perl reg-ex library. You could also use it's kick-ass memory manager ( due to double indirection ) to help prevent massive memory cluttering due to allocs and frees for all the tiny strings. But at that point, you'd be using perl. And what's the point, since it's quicker to code and debug a perl program than a C one. Dynamic systems, such as web pages require a development environment with a fast turn-around time.

    My point is that perl had a nich back in it's day, and that way string parsing. It's libraries were optimized to do so. Many of the types of optimizations ( such as self modifying code, in the case of variable substitutions for reg-ex's or even the eval '' statement ) are hard to do in a low level language. Not that it isn't possible, but just that to do so would take an enormous amount development effort, which doesn't fit into the web-model.

    Perl isn't really the best web-model for most situations either. A heavily loaded web site would be better used by a massive C-engine with customizable pages. Or a PHP/ASP setup might get pages out the door faster ( especially with new developers ). But Perl is a very good general purpose tool for text processing ( as well as other fields ).
  • Blockquoth the poster (italic-quoting the original article):
    Larry promises that Perl 6 will be "better, stronger, faster"
    This is very much like NASA's promise of "faster, better, cheaper" , although they usually get only one or two right.
    Actually, it sounds like they should be calling this "bionic Perl". :)
  • If you need perl on a rescue disk, you can replace the commands with perl scripts (since perl is there anyway) and save some space.

    And yes, I know I'm reaching.

  • Hehe.. Isn't this why all database fields should be declared as text? Laugh.. All kidding aside. I've rarely ever had fields in a DB that perl cared about. It was almost always a medium to read from a CGI form and write to a DB ( validating fields there ) or reading from the DB and displaying on the screen. I'm sure there are cases that the information is more sensative, but I've never encountered one.

    Another point of view is that because strings are so versitle in perl. It wouldn't matter if you read it in as a string, float or int, since it could easily internally type-cast to the appropriate type when used. The worst that would happen is that you'd convert a string to a zero, which should signal a warning somewhere.

    As for initialization.. YOU MAKE BAD PERL JUJU, since you obviously don't use -w. If you did, then you'd know that it's impossible to use a variable without first initializing it. Perl allows you to make the command line -e '...' without any type checking, but allows you to be anal man with -w and "use strict". Trust me, when I started using -w, I'd get really pissy because I loved the default case of undef becomming an empty string. Now I have to
    $str ||= "";
    everything that I know is printable even when null.

    -May you do good things with Perl
  • Another reason Perl holds the web together is that even though its benchmarks suck for number-crunching, it out-performs both Java and C (Yes, C, and I found that unusual) when it comes to parsing text. In fact, if I remember the "Benchmark" story on Slashdot from a couple months ago, Perl was six times faster than Java for text-based stuff.

    And since the web's content is so heavily text-based (because plain text is a universal standard, HTML is text-based, and because most pages' content is text), it's easy to see why PERL dominates.

    Different tools for different jobs. If you want to write a first-person shooter or operating system, use C. If you want to write a script that converts newlines in text files between \r\n and \n, PERL would probably be the best choice. If you want to write an ASCII game, I'd go with QuickBasic 5.

    In conclusion, PERL rules, and if this upgrade is good, that's cool, and if it isn't, no one is going to force us to upgrade our interpreters.
  • I don't think it will be very transparent. I think a lot could and perhaps will change. Now, your old programs will still run, under perl 5 or some comaptibility mode in perl 6. But perl 6 will be different.
  • it has been my impression that perl has been slipping.. losing its position as "the best for cgi

    you could more accurately say that CGI has been losing its reputation as the best (or normal) way to do dynamic webpages, and *that* is a great thing in itself, since CGI (one fork/exec per page, yay!) sucks rocks. Perl has very good support for the CGI model, wiht the CGI.pm module, and mod_perl for Apache has two very good CGI emulations (Registry and PerlRun, with different tradeoffs in how much faster they are, and how much cleaner they require your code to be). However, emulating CGI is *NOT* the only, or the best way to use build dynamic pages with Perl.

    The web-dev world has already pretty much come to the conclusion that URLs must be mapped to their content, not to a directory of scripts. As usual with Perl, There Is More Than Way To Do It; you have modules to embed stright Perl code into html pages (Embperl), modules that implement a higher-level componentized model (HTML::Mason, Apache::ASP, the Templating Toolkit, and others), and buzzword-compliant modules that go the XML/XSL way (AxKit).

    As for perl6, I don't think it'll have a very direct impact in the way people do web development with perl. Perl 6 is going to be a complete rewrite and cleanup of the language, possibly with changes as fundamental and far-reaching as those between perl 4 and perl5. It will reorganize the whole perl world, not just the "perl on the web" part of it.

  • You make it sound like everyone cannot go to the perl mailing lists now ... they can. It is harder now, and yes, the barrier of entry is intended to be lower for perl 6.
  • While the rest of your argument is pretty solid,
    PS: Automatic initialization of variables thus causing typos to be treated as variables is another pet peeve of mine.
    Always, always, always, use strict; and run with -w, at least for anything more than 20-100 lines long. What'd be really great is if 'use strict;' were the norm, and 'no strict;' were the exception, in Perl6... but then probably only 20% of older code would fly, and -e would be horrid.

  • by daytrip ( 25725 ) on Wednesday July 19, 2000 @11:23AM (#920108) Homepage
    This should be interesting to watch develop. Since this one is going to be design by open source, I wonder if they'll ever be able to release an upgrade.

    It seems that the past has shown that language by committee ends up over-burdoning the language. Are they're any previous examples of language design by committee that worked? It seems that all of the successes programming languages have made have been because of one or two evil geniuses who were able to see a project to completion, design to code.

    I wonder if it's just revisionist history, but weren't c, c++, python, perl, and tcl all works of very small teams (excluding the standardization committees).

    This should prove to be a great example for university programming language courses.

  • Just out of curiosity: how many perl programmers here upgraded old perl scripts to use Perl 5 features when Perl 5 came out? I know that where I work, most scripts are run with perl 5 but are written (with the exception of the occasional chomp) in Perl 4 syntax. Are people fully utilizing new functionality?
  • It's kinda like when I figured out that FORTH implemented on a 6809 assembly could be 'faster' than native Assembler -- It's not that you could (oxymoronically) do something faster than it could be done -- It's that the "standard way" of doing things is slower than a well designed special implementation.

    For the FORTH case, the 'faster' result would come where you had a program that consisted almost entirely of lots of calls to short subroutines That's what FORTH (as a threaded language) is all about. In standard assembler it would normally be implemented as:

    call sub1

    call sub2
    call sub3
    In forth, as a threaded language, it would be implemented as a list:
    ( &sub1, &sub2, &sub3 ....)
    In 'standard' assembly, each subroutine would return to the main routine which would then call the next subN. In forth, each subroutine would simply Jump to the next subroutine in the list:
    JMP [REG:Call_list++]
    On the 6809, this would be implemented by pointing the secondary stack pointer at the threaded list, and doing a
    RET SP2 (secondary stack)
    This effectively saves the one instruction per subroutine call (!!!!). Not much of a savings, but if you're calling lots of short subroutines, it can add up.

    Similarly, perl does lots of string manipulation-type work in ways that are fundamentally different than the way that 'standard' C does them. Just like the 6809 example, there's nothing to stop you from doing things the PERL way, it would simply take

    • a rethinking of the way you do things,
    • being willing to risk confusing any maintainer who looked at your code.
    • a willingness to abandon all/much of the standard code base built up over time
    • a willingnes/ability to train everybody who came after you.
    As somebody else said -- by the time you do all that, you'd be programming perl in C. In that case, why bother to do it in C at all?
  • It always comes off to me as being a sort of a 'dirty' language in that there are about a kajillion different ways to do the same thing

    But that's the whole point of PERL.. :-)
  • Well, many things on CPAN _will break_ with perl 6. This is assumed. I apparently did not emphasize that enough in the original piece. Work will be done to make perl 5 stuff run in one way or another, but there will be breakage (probably would be greater between 5 and 6 than between 4 and 5).
  • It is simply a matter of testing. We have not fully tested it, and it is not a high priority. We are planning to have bender, the development Slash, run on perl 5.6 (and in some future release, it might even require perl 5.6). But I wouldn't necessarily count on it happening, just because the priority for it is relatively low. There have been some accounts of breakage with some of the modules Slash uses (mod_perl, for instance), but I cannot say if anything in particular is broken.
  • Perl is never going to become a strongly-typed language, if that's what you're gunning for. This is part of what makes quick scripting in Perl possible. You don't have to make your code impossible to read, either. "use English" if you like clearer default variables, for example, and don't rely on $_. But I love that I can quickly and easily parse a web form or a data file without having to start malloc'ing and casting my way around.
  • Sarathy is still involved (as mentioned on use Perl [perl.org]). I personally expect Tom to be involved with Perl, and would be surprised if he left. I have a sneaking suspicion that Ilya might be involved with it, too. He was at the meeting on Tuesday and seemed intrigued.
  • I'm not sure what your point is here. Since there are no floats or strings as such, only scalars, you'll never have a type mismatch. In the example you give above, I assume the correct code would be something like
    $ssn = $rs[1];

    $firstname = $rs[2];
    $lastname = $rs[3];
    $cash = $rs[4];

    but that would be both inefficient and probably wrong. I say "probably" because unless you have an $rs[0] element your variables are all going to be off by one position -- a mistake you could just as easily make in C. This should become evident as soon as you start seeing people with no (actually, undefined) cash with social security numbers of "Fred" and names like "Flintstone 225.62". And it's inefficient because it'd be much easier to say
    ($ssn, $firstname, $lastname, $cash) = @rs;

    No subscripts to worry about there, and I may have been staring at Perl code too long, but to me it doesn't look like line noise.

    If you're relying on typing as a first check of the validity of your data, admittedly that's something that Perl doesn't do. However it would probably take about ten minutes of looking at the regular expression of Programming Perl to see that, for instance, you could check the validity of a Social Security number with
    $ssn =~ /^\d\d\d[ -]?\d\d[ -]?\d\d\d\d$/ or die "Bad SSN ($ssn)";

    assuming that the database application you're getting the SSN from isn't already doing it for you.
  • I believe your example could be written much more clearly. This:


    should do the same thing, and is more readable. You can make any language obfuscated, especially when the language is flexible.

    I mean, honestly, can you think of a faster way to "zap all html tags not in the list of ok tags"? It may be a little hard to read when you are done, but if you put a comment next to it saying what it does, it's not hard to understand.
  • Don't see how it's misleading since the nature of perl is to make everything a string unless otherwise specified. DBI and JDBC are similar from what I understand.
    The argument isn't for a better DB interface but how to handle arbitrary data-types. A good reasoning for this is that I might not care how the database was designed. Was it a 32bit int or 64bit ( possibly 32/64 bit date stamp, etc ). Changing the database means changing the Java / C code. In Perl, I don't think I've ever had to change a line of code because I've redefined types for table columns.
    This allows me to quickly get a proto-type database up ( possibly with all text fields ), then later optimize the row lengths. More importantly, if the DBA needs to lengthen a VARCHAR, he can do so without risk of affecting the perl code. The only issue that should ever come up is the formatting of the resultant HTML.

    Arguably, you could create a Java DB interface that returned everything as a pointer to type "Object", then use to_string for display purposes. I think that we'd all agree, however, that this would be undermining Java and bad programming practice.
  • I looked on perl.com's website and 5.5 was the development version of 5.6 (surprise) so that makes your point wrong, and the guys original point even stupider.


    A mind is a terrible thing to taste.

  • A complete rewrite? This, from the man who advocates laziness in programmers? :)

    Yeah - he's lazy enough to have the public do most of the work as far as figuring out what to keep, get rid of, modify, etc. He's letting us do the harder work of figuring out what to change, while in his laziness, he and other developers will actually only do the implementation. Seems like a perfect lazy-man's plan to me :)

    Smokedot [baked.net]
    Drug Info, Rights, Laws, and Discussion
  • It wasn't flamebait (at least I didn't intend to flame), and thanks for the link to Icon.

    Something to digest this evening.

  • by Dast ( 10275 ) on Wednesday July 19, 2000 @03:32PM (#920130)
    O'Reilly is funneling massive kick backs to Larry Wall in exchange for making millions of O'Reilly Perl books obsolete. This way they get to "totaly rewrite" the books and sell them to you again all over again. Think of the children!! ;) Or something.
  • This is the reason I believe Perl needs work before being used for anything serious. . .I [expect to] get an error or thrown Exception for trying to convert a float to a string without a cast

    String ssn = rs.getFloat(4);

    float cash = rs.getString(1);

    These are the errors? You're still thinking in Java if you can't see that the perl equivalent would simply be

    ($ssn, $cash) = @results;

    which presents no float / string conversion problems.

    in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.

    The only way this bug (confusing the order of results returned by the SELECT) will creep up to get you is if you don't unit test your methods...

  • Microsoft gives money to ActiveState to make Perl work better on Windows. ActiveState employs some key, core perl programmers.
  • Yes, well, that's the point. Filehandles already are, for the most part. In perl 5.6 you can do:

    open my $fh, $path or die $!;

    Formats, well, formats might go away entirely from the core and move to a more manageable, easy-to-use, sensical module.
  • by devphil ( 51341 ) on Wednesday July 19, 2000 @11:35AM (#920144) Homepage
    I have avoided learning Perl for a couple of reasons. One of them (not the most important reason, obviously) is that the syntax looks vaguely like a memory dump. You know that Dilbert joke where Dilbert instructs Ratbert to dance on the keyboard so that Dilbert will have more bugs to fix, but in doing so Ratbert creates a web browser instead? I think it was written in Perl.

    I'm really hoping Perl 6 will give us some more readable syntax. Hey, I like my C++ short and terse too, but I don't care for entire subroutines mostly written in punctuation.

    Yeah, I know that syntax is a lame reason to like or not like a language, but I'm the one who has to stare at it. It's the little things that make the difference.

"No, no, I don't mind being called the smartest man in the world. I just wish it wasn't this one." -- Adrian Veidt/Ozymandias, WATCHMEN