Forgot your password?
typodupeerror
Perl Programming

Larry Wall on the Perl Apocalypse 121

Posted by CmdrTaco
from the great-stuff-to-read dept.
raelity writes "Larry Wall provides some insight into the design of Perl 6 on www.perl.com. "People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter." " This is a really interesting article and worth reading if you're at all into Perl. Full of Wallisms, entertaining and insightful.
This discussion has been archived. No new comments can be posted.

Larry Wall on the Perl Apocalypse

Comments Filter:
  • by Anonymous Coward

    "pragma shutthefuckup", to eradicate those annoyingly mandatory warnings. ;-) I seem to recall that one only needed "use namespace std;" if you wanted to use the STL libraries in C++ btw.

  • by Anonymous Coward
    Shoeboy, I love you. -- Heidi
  • by Anonymous Coward on Tuesday April 03, 2001 @02:53PM (#317299)

    Hey, that's cool. It does what Microsoft .net does, but better. At least it might.

    One of the major ideas of .net is not SOAP (dunno why MS marketing makes such a hype about that), it's that you can write code in one language and use it in another because all languages use the same framework. So you can write an object in C# and use it (even subclass it) in another .net-enabled language. In .net, data types and class libraries aren't part of a programming language, only syntax and concepts are. Actually the framework is quite powerful, it can even be used for functional programming languages etc. (the downside is that only a limited subset will become a standard). That's Java, but better, if Microsoft gets things right.

    How's that related to perl?

    First, Perl will support multiple syntaxes that map onto a single semantic model. Second, that single semantic model will in turn map to multiple platforms. [...] It must be able to run in other kinds of virtual machines, such as those supported by Java and C#.

    Hmmmm. Now what's that? If the semantic model is powerful enough (i.e. provides enough support to implement different programming language concepts on top of it), that's .net, but better.

    I was already worried that a large part of the open source community would ignore .net, but it seems that they're about to accidentally develop an alternative that's even better. I seriously hope the Perl developers realize this possibility :-)

  • ...and it will be posted again.

    http://detonate.net/matrixse/?page=18 [detonate.net]

    Bottom two frames.


    --
  • Actually, the main problem with my Topaz project was that I was limited to reimplenting the same old Perl language, because only Larry can think like a Perl language designer, and I'm not Larry. I'm very, very glad that Larry is revisiting the design of the language, because that needed doing too.

    And with the language changing, maybe we can get away from reference counting, and then there won't be any need for the C++ features that led me down that path in the first place.

    PS: There are no 't's in my name.

  • You mean Perl and Python coming together to become Parrot was just a joke??

    I mean, come on. I knew it was a joke as soon as I read the stuff on the front page.

    "The power of Perl and the sanity of Python."

    WHAT sanity? If I ever need to obey the line breaks and whitespace rules of Python when writing Perl code, you'll soon find me at the nearest asylum... =)

    (Not intended as a flame bait. Both are good languages. =)

  • Having read the article, I didn't get this at all. He is planning on forcing it for those who write modules and classes, but for the quick-n-dirty, it won't be forced.

    And I imagine that once you get up to the level of project where you need to write your own modules, you probably would be using strict and -w anyway, for sanity sake if nothing else.
  • Chip Saltzenberg was trying to have Perl 6.0 be in C++.

    Think of the disaster that would have been.

    "What do you mean, Perl will no longer install on my Solaris box? I don't have space for C++ as well as C. ARGH!"

    C++ is still not protable across platforms in any sort of reasonable sense. It would have been nice if it was.

    Luckly Chip got talked out of it. (Probably with a big stick.)
  • Sometimes its refreshing to be able to choose your own way to do things, and to know that other people like you just want the damn program to work, with a minimum of futzing with things vaguely related to the problem you are solving (i.e., memory management ala C++ -- just how to exceptions and delete interact in a class hierarchy?) Who cares - every app I have written in the past 2 years has not needed to worry about these sorts of vaguely related things - why FORCE me to?

    Add a garbage collector to C++ and you'll never need to delete. You may think Perl does the same, but if you introduce a circular reference...oh dear, there's a leak. (I know Perl 6 promises to fix this though.)

  • *Complete* fluency in C++ and Perl? If you mean "solid knowledge of the practical working set of the language and a good idea of where to look for the less common stuff," sure, I'm fluent in both and I have several friends who are. If you mean "knows every little detail and interaction," no. Of course, do you know anyone who could claim complete fluency in english under that definition.

    Perl was designed to mirror human languages, not computer languages. (C++ may not have been designed in this way, but it certainly has evolved in a very similar direction.) You're not expected to completely understand the language, you're expected to quickly learn a fairly small working set of features, then slowly grow that knowledge as you grow in the language. Like english, or any other human language, both you and the language constantly grow to handle new problems and solutions. This is part of the reason Perl and C++ are so popular, they're living languages with practical goals. They don't force certain designs and strategies on you, they try to let you work with them as you will.

  • But wouldn't it make the language a lot more readable to start with a new line like:

    perl 6.0

    Since when has readability been a priority for Perl?

  • You are misrepresenting .NET here. SOAP is an XML-based distributed programming protocol that is also cross-language compatible. It is more analogous to DCOM, CORBA, EJB, or RMI. The power and beauty of SOAP is that it will be fully supported by Sun ONE, IBM, and Microsoft .NET. And, of course, it's very easy to use.

    Intermediate Language (IL) is what provides the COM-like capabilities to extend classes from one language to another. The two are very distinct. IL does not require a roundtrip conversion to XML. IL is more analogous to Java Bytecodes, except that there will be multiple languages mapped to IL. IL will require "managed" subsets of languages like Visual Basic, Visual C++, and Perl.

    As for this comment:

    Hmmmm. Now what's that? If the semantic model is powerful enough (i.e. provides enough support to implement different programming language concepts on top of it), that's .net, but better.

    I was already worried that a large part of the open source community would ignore .net, but it seems that they're about to accidentally develop an alternative that's even better. I seriously hope the Perl developers realize this possibility :-)

    I believe you have this 180 degrees backwards. The idea for the semantic model isn't so that other languages can be mapped to Perl. It's so that Perl can be mapped to other languages (namely, Java Bytecodes and .NET's IL). I'm not really sure what the benefit would be of mapping other languages to Perl, when so much effort is being placed on optimizing the runtime environments for Java and .NET. I think Larry's got the right idea.

  • The problem is .NET is not the glue. IL is. Or, if you want to really stretch it, SOAP is. .NET includes these technologies. But these technologies are *not* .NET. Furthermore, the goals of Perl aren't to become this said "perfect glue". Quite the contrary. Perl intends to be able to used as another language as part of someone else's "perfect glue" (namely, IL and JVM).
  • he talks at length about how Perl 5 code has certain keywords that make it known as Perl 5 and how DEC changed BASIC to use "extend" at the top of all their code to use long variable names (and how this was bad). Well, that's all fine and good.. He seems to want to break from this tradition yet what does he do? He begins talking about "module or class" (same as Perl 5 and DEC BASIC).

    The article was great if you are a Camel lover but some of us aren't (I use it for web stuff, but I am not Perl junkie :))

    I am glad to see Perl continuing development, but I still think that Perl/Parrot would have been best ;-)
  • by waldoj (8229) <waldo@nosPaM.jaquith.org> on Tuesday April 03, 2001 @01:58PM (#317311) Homepage Journal
    I guess I don't understand why people need to call other people "funny" because of they're beleifs.

    It's my belief that I should quack like a duck while juggling bowling balls while completely naked, in the middle of Times Square.

    That's funny. It might be my belief, but it's still funny. The two are not mutually exclusive.

    I also think it's funny to take "apocalypse," which is commonly defined as the end of the world, all living things die, etc., etc., and redefine it to be a good thing. In the strict sense, Larry Wall is right. Merriam-Webster says:

    apocalypse
    Etymology: Middle English, revelation, Revelation, from Late Latin apocalypsis, from Greek apokalypsis, from apokalyptein to uncover, from apo- + kalyptein to cover -- more at HELL
    Date: 13th century
    1a: one of the Jewish and Christian writings of 200 B.C. to A.D. 150 marked by pseudonymity, symbolic imagery, and the expectation of an imminent cosmic cataclysm in which God destroys the ruling powers of evil and raises the righteous to life in a messianic kingdom b capitalized: REVELATION 3
    2a: something viewed as a prophetic revelation b: ARMAGEDDON


    But I think it's funny to take the opportunity to take what everybody thinks of as a bad thing and turn it into a good thing, in the Christian definition. That's the Christian thing to do, I guess, is recruit more Christians. Larry Wall took advantage of an unusual opportunity to do so, and I think it's funny.

    -Waldo
  • Um, "steeped"? He mentioned it, what, once? Or are you unhappy with "Apocalypse" in general? See etymology at http://www.m-w.com/cgi-bin/dictionary?va=apocalyps e [m-w.com].
  • > "You must use warnings and strict everywhere except your main module" is not free and fun.

    Oh please. You don't have to use the warnings or strict. Most one-liners don't. You can still express conditionals and looping in at least a half-dozen different ways. You practically have to use strict in CPAN modules (though there's no hard requirement) because it's widely distributed code that could choke if someone did use strict and you code didn't conform.

    This is nothing like Python, a language that has never heard of a pretty-printer, and thus hardwires one into the language definition itself.
    --
  • by scrytch (9198) <chuck@myrealbox.com> on Wednesday April 04, 2001 @03:06PM (#317314)
    If you like the signals/slots idea of Qt and other such interesting extensions to the language, check out OpenC++ here [tsukuba.ac.jp]. It lets you extend the C++ compiler in C++ (plus a little). ColdStore uses it to implement orthogonally persistent and runtime-introspectable classes by simply declaring a class as cold class foo instead of simply class foo. You can change damn near any aspect of the language, including adding extra member access declarations -- like "signals:" and "slots:"

    MUCH cleaner than moc.
    --
  • You're right. I was thinking to myself: "What, ANOTHER Perl Apocalypse????"
  • by PD (9577)
    What is the name of the library? I love the signals and slots from Qt, but haven't gotten into GTK programming.
  • by orabidoo (9806) on Wednesday April 04, 2001 @01:22AM (#317317) Homepage
    He's just talking about the defaults; you can always put 'no strict;' after your module or class declaration.

    All in all, this first introduction to LW's ideas for perl6 sounds pretty good. I'm looking forward to more details about what he plans to do with references. Blurring the difference between an array and an arrayref, as he proposes, seems like it could be either the biggest fuckup, or the biggest improvement to the perl language. I can't wait to read the proposed new semantics and see how it's going to work.

    This probably goes together with giving prototypes and typed arguments to functions and methods; I wonder if perl6 is going to need an 'apply' function, to pass a list of arguments to a function (as opposed to passing the list as a single argument), like Python does. As a perl programmer, at first it sounds bad to me, but I could possibly be convinced that it's worth it.

    Finally, I'm a bit skeptical about the idea of compiling perl into jvm or C#/IL. Despite all claims to the contrary, I don't see these bytecodes being generic enough to implement all of perl's functions (including its amazingly extended regexp engine) with reasonable efficiency. The OO side (integrating objects and mapping methods and properties) isn't really the problem, but I just don't see a JVM-compiled perl module using C-based extensions from CPAN, and I don't see all CPAN modules giving up C integration either. All in all, I think the perl interpreter should remain C, with a good C-based extension model (more like SWIG, and losing the "XS" obfuscated lossage), and work together with the JVM and IL interpreters, supplementing them at the C level to run perl code.

  • Even when perl runs on a palm you won't get the whole module set--that's just too darned big. What you'll likely see is a smallish runtime that can execute perl bytecode, and that's it. You'll need to generate the bytecode elsewhere.
  • But wouldn't it make the language a lot more readable to start with a new line like:
    perl 6.0

    I guess you can still do a
    require 6.0;
    if that's what you're after. Require and version numbers have worked for quite some time, I think.

  • you grab perl-6.0-i386.rpm and rpm -U it... problem solved

    You got the command wrong. It's

    apt-get upgrade

    :-)

  • Ah, but they die to be reborn into the kingdom of god/heaven/etc.

    I'm not a xtian, I don't play one on TV..I just felt it necessary to point this out -- it *isn't* a bad thing (they way they wrote it)

  • So I know some members of the perl 5 porters list will be reading this, and I'd like you to relay this question to Larry:

    Larry,

    How do you feel about having me as a son in law? I know that having a troll in the family can be a bit traumatic, and I'd like to know upfront if this will cause any problems. I'd like to work through them before the wedding, so that everything can go smoothly.

    I know that you're a little disturbed by Heidi's recent spate of trolling here on /., but that was none of my doing. It wasn't until after she began trolling that we met.

    You are probably also thinking that maybe your daughter can do better than a shiftless layabout who got fired from AtomFilms.com for sexual harassment, but c'mon. Think about it. Look at my flowing, golden mane, my high cheekbones, my chiseled jaw and my piercing eyes. Could any young woman possibly do any better? If you're still not convinced, you can look at my broad shoulders, barrel chest, washboard stomach and manly bearing. Now you can go have a cold shower, you probably need it.

    Later,
    --Shoeboy
  • >So you would swear about perl a bit and then you give up. That's how it goes pretty much isn't it?

    No, then you grab perl-6.0-i386.rpm and rpm -U it... problem solved
  • Did you catch Larry's explaination as to why?

    Language design is a trade-off. He's trying to avoid instanly breaking 90% of the one-lines out there, and keep the freedom the Perl is famous for, while moving on.
    As he himself states, forcing folks to "use perl 5" would break everything. Settling for "use perl 6" (and, understand that there will be ways to get around this -- note his comments about "use policy") lets us get on with the concept of coding, and not with the concept of re-coding. Going to be hard enough to re-write all these modules...

    ----Woodrow
  • by hugg (22953) on Tuesday April 03, 2001 @01:21PM (#317325)
    Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl? I have a feeling that these two languages are too large to be contained in a human head at the same time.

    Perhaps we will have to evolve super-intelligent Khan-like coder clones in the future, using nanotech, Beowulf clusters, and in-dash Atari 2600 emulators.
  • I think Larry's solution to the problem of flagging Perl 6-ness in a program is pretty clean for modules and included libraries (ie defining a 'module' as a 'package with strict turned on'), but I would be very unhappy about a "use Perl 6" pragma. The problem is that by putting a specific Perl version number in a pragma like that you are tying the features being invoked to the particular version of Perl, which is going to look a bit dumb when we move up to Perl 7.

    I know this isn't really any different than requiring a particular version of a library, but it just seems ugly to me. Still, very much looking forward to reading the rest of the Revelations of Larry.
    --
    Dunx

  • Stay clear of Shoeboy people. The buckshot spray from Larry's shotgun could potentially injure others!

  • by EvlG (24576)
    But thats what Weak references are for:

    http://search.cpan.org/search?dist=WeakRef [cpan.org]
  • by EvlG (24576) on Tuesday April 03, 2001 @05:05PM (#317329)
    FINALLY someone who agrees with me about the needless additions to C++

    Every time I go into a bookstore to read about C++ (every 4-6 months or so) I find out about more and more "features" that were added since I learned the language in 1995 or so. Stuff like 3 different versions of new and the namespaces.

    IMO C++ has grown from being a useful extension of C to becoming a massive, horrible mess with too many features. Lots of people I know and work with talk about C++ in terms of being hard to learn and use well because it is extremely intricate. This is a good thing?

    I'm disturbed by some of the more recent proposals for C++. Whitespace overloading?!? ho are we kidding?

    I'm just glad that other people find solace from the insanity of C++ in Perl. Sometimes its refreshing to be able to choose your own way to do things, and to know that other people like you just want the damn program to work, with a minimum of futzing with things vaguely related to the problem you are solving (i.e., memory management ala C++ -- just how to exceptions and delete interact in a class hierarchy?) Who cares - every app I have written in the past 2 years has not needed to worry about these sorts of vaguely related things - why FORCE me to? Preaching the "paradogma" (great word Larry :) is just annoying.

    There are certainly a number of cases when you NEED to care about those mundane, tedious details. Real-time programming and other systems level work are good examples.

    I guess all I am saying is, thank you Larry, for freeing programmers like me from the tedium of malloc and free, sizeof and screwy arrays. You have added 20 years onto my lifespace, at least.
  • In apocalyptic literature, 7 is the number representing perfection, while 6 is the number representing imperfection.

    Larry, I think number theorists would crack that, contrary to general belief, the number 6 is one of those most significant and rarest of numbers belong to the perfect number category. Those number have their divisors added up to themselves (6=1+2+3). The other perfect number is 28 (28=1+2+4+7+14). Perhaps someone will be able to point out the others.

    But whatever the perfect number, I am sure that Perl 7 will be more pearly than Perl 6 :)

  • Armageddon (the field of Meddigo, site of an especially bloody historical battle) is the location of the final battle. Apocalypse is synonymous with revelation, e.g. Revelation of John == Apocalypse of John in the Bible.

  • by yomahz (35486) on Tuesday April 03, 2001 @01:37PM (#317332)
    he talks at length about how Perl 5 code has certain keywords that make it known as Perl 5 and how DEC changed BASIC to use "extend" at the top of all their code to use long variable names (and how this was bad). Well, that's all fine and good.. He seems to want to break from this tradition yet what does he do? He begins talking about "module or class" (same as Perl 5 and DEC BASIC).


    I think you may have read it wrong. He was simply stating the way that perl6 modules would be declared is different than perl5 modules.

    Nothing was added, just changed.

    The quote follows:


    A closely related question is how Perl is going to recognize when it has accidentally been fed Perl 5 code rather than Perl 6 code. It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6.

    Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good.

    A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that.

    I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does.

    --

    A mind is a terrible thing to taste.

  • Too bad that was anon - it was funny. When I finished the next major revision of my script for rapid porn downloading I would have sent it to you.

    It doesn't work right now, because I'm in the middle of revising the core fuzzyfying functions for searching on variants of, for example /yoursisterstits/images/poolbabe1.jpg to find backup files and additional images not listed in the thumbnail gallery, plus revising the user interface for declaring the method of fooling mod_referer, but who am I kidding. I don't have that much time to look at porn.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.

  • I think this article is interesting in that it gives some rare insights into language design. You always hear people complaining about why didn't x (where x is C++, Java, Perl, etc) do this or that? Why this feature or syntax? Here Larry points out some trade off that may not be obvious to "end user". And all written in a easy to understand language called English too ;-)

    I'd recommend that you read "The Design and Evolution of C++" by (who else?) Bjarne Stroustrup if you're interested in this kind of non-academic language design. The book's a bit old, so it's missing some of C++'s newer features, but it's a fun read if you like that sort of thing.
  • by pos (59949)
    Right on!

    IMHO, they should have been addressing some of the design patterns that are harder to implement in C++.

    I mean just look around at what people *want* to do with the language. Look at Qt and their .moc files. Why not add that to the language and save Qt and everyone else some time? Most people who have tried signals and slots agree that it's a pretty good, straigtforward implementation.

    just my 2 cents...

    -pos

    The truth is more important than the facts.
  • Well I don't mean to brag but I am completely fluent in C, C++, Delphi, Assembly, Perl, Python, English, Spanish, ...ugh. Who the hell am I kidding...

    Mike.

  • You're cynical. O'Reilly doesn't do what they do just for the money. If that was their only motivation, they'd publish porno and run virtual blackjack tables. Publishing tech books is sometimes profitable, but it's extremely labor-intensive.
  • by mcjulio (68237) on Tuesday April 03, 2001 @04:26PM (#317338)

    First of all, it's sad that Slashdot couldn't hold notable members of the Perl community. Makes me a bit wistful to look over the nearly content-free posts on this topic and remember Abigail's scathing and 100% accurate flames, and Tom Christensen's odd and brilliant posts. Assholes, maybe, but their minds are unparalleled and their writing incisive. They're sorely missed in a discussion like this.

    In any case, Perl is in good hands. Require strict and warnings for modules makes sense. Leaving room for Perl to grow is a good thing. Making everything an object that is free to return in scalar context adds flexibility while giving functions the freedom to behave as they see fit.

    Most of all, these principles are in place before the major work of adding full Unicode support and meta-languaging begins. There's a firm hand on the tiller, and Larry seems as up for the work as he ever has been.

  • It will be worth people's time to write real compilers for (Perl/Python/Ruby/whatever) when there are real, non-platform-specific specifications of what the languages mean, so compiler writers have something to aim at that won't move out from under them.

    This is the fundamental reason why languages defined by portable implementations have problems growing beyond those implementations. The implementation actually specifies too much of the langauge's behavior - a real spec says explicitly what behavior is implementation-dependent, which tells implementors and users both exactly where the boundaries are.

    The Common Lisp and Scheme communities wrote real specs for their languages (ANSI and IEEE, respectively). The user communities routinely beat up implementors and vendors who don't conform to the spec. As a result, they can write portable programs that compile to native code, without getting stuck in the C/C++ quagmire.

    Someday there may be a way to answer these questions:

    Are JPerl and Perl the same language?
    How about JPython and Python?

    that doesn't boil down to "ask Larry/Guido". A year or two after that, you might see real compilers for those languages.
  • He is planning on forcing it for those who write modules and classes,

    No, he is planning (suggesting?) that that should be the default. Perl rarely forces anything.

    perldoc -f no

  • the "module / class / package" thing is very similar to the change in LaTeX [tex.ac.uk] from v2.0.9 to v.2e, where files changed from starting with \documentstyle to starting with \documentclass. It was easy to start using 2e and backwards compatibility was easily maintained

  • We have that already, though - require 5.04; will cause pre-5.04 versions to drop dead, while allowing 5.04 and all subsequent versions of perl to carry merrily onwards...
    --
  • "You must use warnings and strict everywhere except your main module" is not free and fun.

    Unless I misunderstand, I think that nothing stops you from saying:

    no strict;
    no warnings;

    after your module or class or whatever statement if you really want to. Frankly, I think "encouraging" module writers to be -w safe is a great idea. One of my favorites is hideously noisy with -w, (unless it's been rewritten recently); every time I use it I have to look at the output and remember whether this means it failed or if it's just the usual noise.

    --
  • You can't even wait for the *design* to be complete before you flame it? Amazing. Larry was pretty smart for perl5, but dumb for perl6? How did that hapen?

    --
  • Example: Perl's pitiful documentation compared to Python's rich, perfect, strait-from-the-mounth-of-god, Guido himself documentation.

    Either you jest or you display ignorance. The perl distribution comes with tons of doc. Try issuing perldoc perldoc. You can use perldoc -f function_name_here to get information about any perl function and perldoc module_name_here to get documentation about any module for which the author has provided it (which is most of them if not damn near all of them).

    More to the point, try man perl - each of the 70 sections is its own extensive man page, covering references, objects extensions in c - you name it it's probably there.

    Oh, and how extensible is Perl? I never heard of an applet written in Perl.

    What do these 2 sentences have to do with each other? many meabytes of perl extensions can be found at CPAN [cpan.org] - I don't believe I've ever wanted to do something that wasn't made much easier by something that was already there. What does writing applets have to do with exensibility? perl is quite extensible in both perl and c. And there is a project to compile perl source to java bytecode, tho I'm not sure if it's still active. But client side applets aren't my main concern. I don't think they're flavor of the week anymore, anyhow.

    --
  • beware perl v 6.66!!!!!!!
  • I'm getting there....gimme about 1.5 years.....
  • Maybe he/she/it was suggesting that the .NET framework equivalent be built in Perl..perfect glue..
    I'd be up for that..
    ..anyone know of a project going, let me know...
  • The essence of Perl is really context sensitivity, not just to syntactic context, but also to semantic, pragmatic, and cultural context.

    This is a really big part of Perl for myself. After learning a certain amount of the language, I was able to start guessing at how perl would work, and it would usually work that way. Where the more designed languages seem to have just mandated the way things are done, Perl tries to interpret as many ways as a user might think of doing them. This is not an easy task, and once accomplished can yield some very ugly, bad code.

    It goes something like this: I say, "I wonder what would happen if I tried xxx." Perl will do it the way I want. C doesn't work that way. Java will surely have deprecated the useful way of doing it because it wasn't supported on a common architecture like the Timex Indiglo.

  • He begins talking about "module or class" (same as Perl 5 and DEC BASIC).

    I think the point was that the EXTEND keyword at the top of the DEC BASIC programs served no purpose other than to say "I am a new program", whereas the (proposed) Perl 6 method merely replaces the "package" keyword with something else. The keyword has to be there anyway. Changing from "package" to "class" just overloads the meaning.
    --

  • wont oreilley benefit by selling new perl books ?

    Sure they will. So what?

    wont the profit generated be more than enough to cover the salary they pay him ?

    Perhaps. So what?

    isnt oreilley as a business simply existing to generate profits ?

    Ahhh, not necessarily. There are plenty of businesses that exist for reasons besides simply making a profit.

    Habit #5: Think Win-Win [amazon.com]. Try it some time.

    Not all positive decisions have to be at the expense of others. O'Reilly helps the computer biz, and it helps improve their own market, and Larry gets a job making bucks doing what he loves. What's wrong with that?
    --

  • I dropped an email to Larry and to Tim O'Reilly thanking them for the work that Larry's been doing on Perl.

    I think it's great that Larry is taking the time to be the visionary and leader on Perl, and providing so much of himself in what goes into Perl 6.

    And I think equally important is that O'Reilly [oreilly.com] are basically paying Larry to do it. As far as I know, Larry's been getting a paycheck from ORA for just doing the Perl stuff that he does, not unlike Damian Conway getting a paid year sabbatical to be Damian.

    That salary for Larry has to be some of the best investment in the community and infrastructure of software development yet, and I cheer Tim & co. for doing it.
    --

  • Where I work, we use perl for just about everything - and almost none of it is web work. We use perl for most of our database stuff (I just wrote a simply badarsed little program, too.. happy sigh..) using oraperl and it's sweet loving. Frankly, ever since I started using perl for non-web stuff, I can't even imagine using perl for the web. I suppose it's nice, but it just has so much more potential uses.
  • Microsoft's ".NET" appears to be designed primarily to increase Microsoft's control over the customer base and to make Java go away. This hardly seems like a good direction for Perl to follow.
  • He was right on, Java is an extremely well designed language with many built in features taken into account at the languages' inception, that would be tacked on libraries in other languages.
  • I have thought about this sometimes and haven't come up with a definite solution because there eally isn't one. But I think that most languages in widespread use are good, but have some flaw in them.

    I think that java approches being a really great language, but stops short because it is so god awful slow. It is also very verbose and although I like it, it doesn't go as fast as perl,python, or php. What it does have is stability, consitency, and standard libraries that come with every runtime environment. If perl 6 had classes remenicent of pythong, came with a full featured standard GUI (TK is quick,dirty, and fast but doesn't compare to the feature set of swing), standard thread, standard complex sound IO, and standard socket set that's more straightforward, I would never use anything else. I know its alot, but if that was there, then I think the language would be much more complete, then other stuff could be added with modules.
  • you must be a Python user
    --
  • by washirv (130045) on Tuesday April 03, 2001 @01:15PM (#317358)
    You mean Perl and Python coming together to become Parrot was just a joke?? I had totally believed it seeing as it was on Slashdot and all....
  • I also get the impression that even if using warnings and strict is the default behavior, it will still be possible to turn it off if that's desirable. IIRC somebody suggested that there be something like a use loose pragma that would turn off default strict behavior, and it's already possible to selectively turn off warnings for particular blocks of code. I don't think that anyone has seriously suggested making Perl a Bondage and Discipline language where everything must be done just so.

  • I never heard of an applet written in Perl.

    Which just means that you're not looking. In fact, there is currently a reference to an article on writing Gnome panel applets [perl.com] in the Perl slashbox here on slashdot. Your lack of knowledge does not mean that it isn't being done.

  • There's already a use [version] pragma that requires that the Perl in use be [version] or higher. IOW, use 6.0.0 would not prevent the code from working in a hypothetical perl7.

  • Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl?

    It just so happens that I know exactly one such person--and he is (without a hint of exaggeration) a mind of genious caliber. Hmm... Well, I guess you've taught me that I should forget about becoming a C++ expert. Thanks!

  • I once was lost... but now I see!
  • Some things aren't good. They should be changed. But some people wouldn't like that and it would break backwards compatibility. Maybe it shouldn't be changed. Who knows?

    Is it just me or does that pretty much sum up the article? Not being a troll, but for being articles that are supposed to define what direction Perl will be headed, they don't seem to give any definite answers.

    I think that Larry took on a much bigger job than he anticipated when he decided to completely rework the language. Making a language that is entirely perfect, yet all things to all people is impossible and he will have to realize that before any real work will get done!
    --
    (Mountain Dew == Canned Code)
  • Like most good jokes, this one has a serious side. Wall's article provides us with many examples. Consider:
    People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people.
    Naturally, Wall uses English the same way he designs Perl language constructs. Few people would use the word "Apocalypse" this way. But Wall's usage makes sense, if you stop, think about it for a few minutes, and maybe go consult a reference book. How many times have you had the same experience while reading Perl code?
    The essence of Perl is really context sensitivity, not just to syntactic context, but also to semantic, pragmatic, and cultural context.
    Gawd, that's a lot to lay on a simple programming language! But of course this is why so many Perl constructs have complex, subtle behaviors.

    In a way, this is a variation on Microsoft's Always-Second-Guess-The-User mentality. The difference is that MS assumes all users are idiots, and Wall assumes all Perl programmers are like him: gifted creative people who prefer non-linear thinking.

    OK, this is nothing wrong with this. I'm not part of the Perl culture, but I respect it. Just try to remember that the ultimate purpose of all software is for somebody to use, not just to show how clever you are.

    __

  • it starts with non package?

    Sure that works. Sure.

    But wouldn't it make the language a lot more readable to start with a new line like:

    perl 6.0

    Then newbies would be more likely to guess why their perl5 compiler/interpreter croaks??

    No of course not. That would make no sense. They wouldn't have to buy a book from a certain well known publisher to use Perl...

    So I'm cynical. Call me cynical.
  • Yes, but with linux the sys admin usually IS the user. And you download this fantastic neato perl app thing over the internet and... and... it doesn't work.

    Of course your perl came bundled with the OS and is a version behind.

    So you would swear about perl a bit and then you give up. That's how it goes pretty much isn't it?
  • Yes. So you leave perl 6.0 out and... the system defaults to perl 5.0 syntax or if you're really being crude it just runs perl 5.0 instead. And this is hard because?

    To a reasonable approximation either the 6.0 system understands 5.0 syntax or it doesn't. If it doesn't its going to come unstuck anyway when people try to run it on legacy code. If it does, and Larry seems to imply that it does to some extent, then there's no excuse for making this harder for users.

    A language should beg people to use it. It sells more books too.
  • Man, did you -read- the Apocalypse?

    Larry wasn't talking about making functions return the current, bloated implementation of objects -- he was, instead, talking about adding a new implementation of object (based on a C struct) to perl, and having them return those -- implemented well, this shouldn't be much slower than the current (parsed) implementation such things, especially since often what you'll lose in having to make sub calls for stringify and numify you'll win by not having to translate the original structs in the first place.

    An object is just a concept, not an implementation.

    Josh -- (of NY.pm)
  • Java is a great language with mediocre implementations

    Huh? Java has a totally retarded language design that at best is an imperfect improvement over an even larger kluge, C++.

    Of course, some of the "improvements" to Java aren't improvements at all. Everything is a class? No templates?

    There is a reason all the implementations of Java are crappy - you can't make a cake out of shit.

  • I think history shows that Larry will retain as much backward compatibility as he can while producing a truly evolutionary new version of Perl.

    Perl is as much a culture as it is a programming language.

    I personally do not like the idea of using the existence of "package" as a way to distinguish perl5 from perl6. While this works for the modules, what about non package applications?

    There's already a require VERSION convention established. The new version of perl could require that this be supplied to activate perl 6 functionality. Scripts without this would be assumed to be at 5.x.

    - Pat
  • I think that java approches being a really great language, but stops short because it is so god awful slow.

    Don't confuse design with implementation. Java is a great language with mediocre implementations and monolithic amounts of class library rushed out the door to feed the ravenous programming public at large. Java has enormous room for improvement in the realm of performance.

    The java language itself is rather elegant, right down the the bytecode operations.

    However, at the moment, we're talking about Perl.

    Before Perl, I would have defined a great language as one with a straightforward and clear design. Java qualifies, however, Perl is none of these in my opinion. Perl can't be described in BNF -- it requires a magical context sensitive tokenizer sprinkled with magic Wall-ian pixie dust. Yet, without question, Perl is a great language too.

    Perl has forced me to redefine my definition of a great language as one which effectively fulfills the needs of it's users. This is something which even the angriest python evangelist would have to agree that perl does well.

    There are tasks I can accomplish in a 1/2 hour of perl coding which would take me days to accomplish in java. Programming perl is also more fun to me...I don't know why. Perhaps this is due to it's "more than one way to do it" philosophy which provides me with countless options. Perhaps it's the unix based culture that I love. Or perhaps it's the overall goodhearted spirit behind the majority of the Perl community that Larry has carefully fostered.

    I wouldn't, however, want to manage a million lines of perl code. One of the things I've noticed is that the better the perl programmer, the harder it is to read their code.

    Perl is the language which allows you to do in 1 line, what you should have done in 20.
  • First, since "basic" data types in perl are internally complex data structures, returning objects does not make such a big difference in perl as it does in c++.

    Second, Perl5 is already ebject oriented. But the OO stuff is kind of kludgy and particularly unieldy when dealing with class hierarchies. I cannot see how moving OO features to the core, as I understand is planned, and cleaning up the way inheritence is handled based on Perl5 experience can make Perl6 worse than Perl5. This is not adding features, this is correcting suboptimal design.

  • C++ is slower to compile, but you only compile once. You see there'll be a penalty for perl every run and not just once. So in perl the fact that it becomes OO has longer lasting consequence.

    Seems to me the opposite is true. Right now using objects and packages incur high overhead. Moving the inheritence code from the interpreter to the core ( which is compiled) should eliminate some of it and improve performance of OO perl code. The basic issue is that we are not talking about adding OO to perl but about correcting a faulty OO implementation. You ask what is wrong with thingies and packages. basically, IMHO, performance and the inhereritence mechanism. If Perl 6 improves on these issues it will be a Good Thing.

    I certainly see the danger of screw-up, and simulating java performance will be a disaster. But we ought to give Larry Wall some credit ;-)

  • 0
    6
    28
    496
    8128

    then it gets hard.

    anyone know a proof that all perfect numbers are even? :)
  • I don't think it is "better for web work, period". What you think of as an advantage (100 ways to do templating) some people think of as a liability.

    In any case, I don't care much for the kind of data acquisition slash web proposition you're describing anymore. But if Perl is helping you to develop an exciting application, more power to you.

    In fact it might be illuminating to hear, from your application's point of view, what you reckon might be the most exciting new feature in Perl 6.

  • Indeed, who doesn't love Perl for it's ability to churn out simply badarsed little programs!

    Still I can't help but feeling that the language has somehow aged (rather than matured) over the last couple of years. People just don't seem to be as enchanted with Perl as they used to be, and "Perl 6" in places seems motivated by a strong sentiment to regain this lost sense of wonder, instead of by concrete applications that Perl could be or should be targetting.

    But, I know nothing.

  • At the time when I first encountered Perl, around 1996, I thought it was wonderful. But it was wonderful, because I could easily see, what with it's powerful text processing, easy networking and platform independance, how it could play a major part in doing wonderful things on the budding web.

    But nowadays, I'm bored stiff with (programming for) the web, and likewise, my interest in Perl has waned. Also not unimportant, stuff like PHP has basically taken the crown from Perl where it comes to web development.

    This is not to say that Perl doesn't have a place. Perl lends itself extremely well to perlish things. It's just that the excitement surrounding Perl seems to have diminished.

    And so sometimes I cannot help but wonder whether this longish and rather dramatic prelude to the start of the preliminary design for Perl 6 is really not just a way to try and summon some lost Perl spirit; to try and recapture some of the excitement of yore.

    Does the world really need another Perl? And if yes, what should it provide? The answers to that last question seem to oscillate wildly between grand visions of syntax independance and mundane matters such as thread support.

    Frankly I think neither answer is very exciting. Grand visions are a dime a dozen, and thread support is just thread support.

    The bottom line, I guess, is whether Perl 6 will succeed in targetting an application, or whether it will just succumb to change for the sake of change.

    Let's just hope for the former.

  • Well...americans were pretty smart for Clinton now how did THIS happen?

    Making one great piece of software that needs little or no change does not mean the next to come will be an improvement.

    Of course, you might argue, presidents have little to do with software.

  • First, since "basic" data types in perl are internally complex data structures...

    I understood what you tried to say, but let me tell you one thing, C++ objects are little more than complex structures.

    C++ is slower to compile, but you only compile once. You see there'll be a penalty for perl every run and not just once. So in perl the fact that it becomes OO has longer lasting consequence.

    What is amazing about OO in C++ is the mangling of names that end up in libraries with 200 character identifiers. In perl we got packages and blessed thingies - why change that? You saw the part on perl5/6 compatibility? I dropped java because there is more than one version, the best browsers won't run the code from the latest SDK's(whatever, JDK) and I felt Sun was messing a great idea up. Also I can't think of anything slower than the latest java machines.
    So back to perl, I fear perl will be slower, clumsier and unstable just like java.
    The CPAN is becoming a mess, and that is leaving me perl-paranoid - am I loosing my favorite language?
    See for example the Gtk modules. Doing a CPAN installation with the shell you get Gtk. Then you have to go to your .cpan/build dir to make Gnome. Otherwise you don't get Gnome.
    See the Net::IRC module, it has some code by Nat Torkington, or so the authors claim. Everyone knows Nat is a great perl programmer, but I took the time to read the source and geez....what a mess....is that the kind of libraries being allowed in CPAN?

    I think we might be loosing it. I want a snapshot of perl and CPAN from January 2001, I don't need more than that....like I said perl will be perl5.
  • Yeah I read it....but listen this isn't perl! So perl will not be perl and we just broke one RFC...

    As I don't know how thingies get casted from one type to the next in perl guts I don't know how much faster the objects will be for type conversion. If I had to take a shot, I'd say slower.

    Anyway, I hate to see perl go true OO and "fix" all the little things that don't need fixing. Do you want to be geeky like python programmers(oh man, I'm outta here now...)?

    Blah! Enough writing on /. today.....but yeah I hope Larry makes the right choices there... JF
  • Some things don't change whether they're in core or out of it. Think instantiation of classes. There will be an instance for every object/package and an interpreter core region for each. I might agree that since the OO is in core it is loaded sooner, but not faster.
    I agree that perl inheritance is one huge patch, but exactly does it do wrong? Use an array to find parents and children? What's wrong there, really? It is different and Larry always bragged about perl OO being just different. Java won't allow multiple inheritance, C++ will, and perl uses and array for inheritance and the word "class" isn't there, it's different but how is this going to be corrected when there's nothing wrong with it.

    I do give Larry all the credit in the world, and who I am to be the critic, but I don't think perl needs changing. It needs improvement on what's already there. Make it faster, provide better compiling support for commercial applications, add functions, make some extremely popular and well tested modules a part of the core, and so on.... Please let it be clear that although I started this thread saying "Larry is out of his mind" I do respect him and have chosen perl for more than the language, I also chose it for the people that use it and for the discussions that it brings about :))
    I just hope this doesn't end up like java, really....

  • by jfonseca (203760) on Tuesday April 03, 2001 @03:37PM (#317383)
    Larry is out of his mind. He's creating perl++ and he's accepting the anti-UNIX pro-BLOAT RFC's. I confess I never expected that from him.

    - Everything will be an object.

    This is ridiculous. I always chose C over C++, now I'm choosing perl5 over 6. Period. I'm a perl5 monger(brasilia.pm.org) now. There'll be perl6 mongers. I'll call them the PERL BLOATERS. I can write better perl with perl5.

    - 'package' means perl5 otherwise 'use perl6';

    A FCKING PATCH. MICROSOFT STYLE, LARRY. Go for it.

    - Perl will stay perl.
    Uhuh. And we're all stupid and can't tell. Perl 5 is PERL, 6 is PERL++.



    Conclusions

    Yeah, just like Samba we're going to see 2 perls from now on. I'm sticking with 5. Most will move to 6.

    Fine with me. Just glad I dig perl 5. If others agree just show you do by writing better perl 5!!!!
  • by X-Dopple (213116) on Tuesday April 03, 2001 @01:28PM (#317384)
    "People get scared when they hear the word Apocalypse"

    Some people get scared when they hear the word Perl... [bbspot.com]
  • Well, I don't know about Palm, but there is a Perl port [rainer-keuchel.de] for the Pocket PC.

    Haven't tried it yet. May get around to it tonight.

  • Imagine introducing namespaces in Perl and adding "use namespace std;" to every Perl program that uses e.g. printf.

    That would be the real Perl Apocalypse.

  • by Schwarzchild (225794) on Tuesday April 03, 2001 @11:21PM (#317387)
    To me, things will get interesting once one of these languages actually starts delivering a non-trivial, high-performance native code compiler. I don't mean the kind of simple translation to C code that exists for Perl and Python, but something that actually genuinely increases performance and figures out stuff about data types. Will anybody be up to the challenge? That remains to be seen.

    I am disappointed by the fact that Perl can not deliver compiled code. The help blurb on the Perl executable says that the compiler option is experimental! When will this not be experimental?

  • by Codeala (235477) on Tuesday April 03, 2001 @02:25PM (#317388)

    I think this article is interesting in that it gives some rare insights into language design. You always hear people complaining about why didn't x (where x is C++, Java, Perl, etc) do this or that? Why this feature or syntax? Here Larry points out some trade off that may not be obvious to "end user". And all written in a easy to understand language called English too ;-)

    While this is not a complete redesign, it is not everyday you get to see just exactly one design an programming language used by millions of people. Good stuff, definitely stuff that matters. This is a must read for people interestined in programming language. I am really looking forward to the next one.

    OT: The design of Perl6 is somewhat similar to the kernel: anyone can submit rfc (patch) and Larry (Linus) has the final say on what goes it. (No, I don't know where I am going with this either :-)

    ====

  • C, although often abused and maligned, it the perfect language. It is well suited for writing compilers and device drivers. It is equally well suited to writing full blown applications. Does anyone remember WordPerfect for Dos or Word for Windows that ran in under 300K of memory?

    As for classes, they are certainly easier to impliment in C++, but well structured C code can be made to behave very similarly, and without much extra effort. The class implimentation in perl seems rather odd and unintuitive.
  • by Anoriymous Coward (257749) on Tuesday April 03, 2001 @05:54PM (#317390) Journal
    I believe whitespace overloading was Bjarne's april fool joke of a few years ago.

    OTOH, why not? Python does it [ducks]

    --
  • by Dancin_Santa (265275) <DancinSanta@gmail.com> on Tuesday April 03, 2001 @01:51PM (#317397) Journal
    I have to agree. The amount of extra baggage thrown into C++ in its last rev is enormous and much of it is extraneous, IMO.

    The most notable, for me, is the addition of namespaces. While I understand and agree with the idea that unused functions shouldn't pollute the global namespace, I find that moving all of C++'s standard functions into a separate namespace overkill. It isn't like C++ programmers were having trouble coming up with function names that clashed with strcmp(), for example. What this leads to is the extra line

    use namespace std;

    in many programs. In essence, the moving of all these functions into a separate namespace just forced developers to create a rote workaround, not unlike the issue Larry brought up with class or module.

    Perl itself has grown over the years, and while many changes have benefitted the programmers and opened up many doors (references, objects, etc) the core language has changed little. Larry seems to be moving away from the spirit of TIMTOWTDI and more towards the BSDM style of language exemplified by Java (or insert a language you love to hate). "You must use warnings and strict everywhere except your main module" is not free and fun.

    There is no doubting the efficacy of -w and use strict;. I use it in all my own Perl programs, but many don't. This used to be okay. When I used to answer questions on clpm, I always chided querents for not using them. It was good advice (just turning on warnings can help nail a problem in many cases), but they could always take it or leave it. Now in Perl 6 it seems that this attitude that what goes on between programmers and the language is none of our business is done away with, and a school marm with a quick ruler is the new paradigm.

    I grew up in Perl during Perl 5 and always laughed at the backwardness of those who touted Perl 4's abilities (Alaskan electrician, Purl Gurl, etc.), but now I find myself wondering if I am exhibiting the same stubbornness. If I am, am I right in this? Perhaps I need to change with the language?

    Dancin Santa
  • by duskus_maximus (310094) on Tuesday April 03, 2001 @01:30PM (#317401) Homepage
    As a perl scripter, I should probably keep up on perl development. A few `features' I hope I find in Perl 6 are:

    Threading - MP3::Napster, a popular module written by Lincoln Stein requires a threaded perl interpreter; I happen to use this module for my project [no-ip.com] (spam, spam [grin]).

    More perl ports - I would like to see perl ported to PalmOS; some nodes on PerlMonks [perlmonks.org] reveal that there is a lot of interest in this; Although I sometimes wish they would take a look at the projects on handhelds.org [handhelds.org].

    Dusk begins to realize that he is ranting....

    Anyway, I am sure that I will be pleased with the results; Saint Larry will not let us [perlmonks.org] down :)

  • by Anna Mouse Cowherder (323205) on Tuesday April 03, 2001 @01:20PM (#317402)
    Hopefully the rewrite will make it possible to port Perl to Palm devices (that outta be a tongue twister.) The core install of modules that come with Perl this days are far too large to fit into the memory footprint, and I'm looking forward to the day when I'll be able to script on a Palm device (using a foldout keyboard of course.)

    My guess it that Python porters were able to overcome this obstacle by writing much of Python in Python itself, hence Pippy. [endeavors.com]

    Once Perl 6 is released, though, the Perl community will be able to quickly play catch up, and get a port out rapidly. Woohoo!

  • I think there are other reasons as well. CommonLisp is a real mess in some areas and some of its designers had such disdain for UNIX that it seems to try hard not to live well in a UNIX environment. Both CommonLisp and Smalltalk were pushed along for many years by greedy companies with big dollar signs in their eyes, killing any possibility of grassroots adoption. Dylan and Self missed the boat compared to Java and Python because they did try to be so much more.

    I have to say, though: of the currently popular scripting languages, Python seems to closest to becoming a real programming language, and it's still retaining its original utility and simplicity. What Python is missing at this point is a new implementation that provides incremental compilation to efficient native code, plus a few language cleanups to go with that.

  • And the sad reason that the great technically superior languages aren't used by more people is basically because not many other people using them. Face it, the average programmer is basically a herd animal. With the adoption of new languages we have the chicken and the egg problem... which is very hard to escape from (except through superior marketing (as in the case of Java) or with an 800 kilogram gorilla promoting the language (i.e. Microsoft and their ridiculous languages). To paraphrase Guido "Dylan is like Python, but so much more".
  • Wouldn't you rather have me?
    I know I'm better then Heidi just ask my ex boyfreind


    I fucked Heidi's camel once!!

Uncompensated overtime? Just Say No.

Working...