Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Perl Programming IT Technology

Perl 6: Apocalypse 6 Released 247

Posted by CmdrTaco from the dodging-a-pack-of-camels dept.
data64 writes "The latest Apocalypse talks about subroutines. Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5."
This discussion has been archived. No new comments can be posted.

Perl 6: Apocalypse 6 Released More

Perl 6: Apocalypse 6 Released

Comments Filter:

  • Apocalypse Now (Score:3, Funny)

    by nizcolas ( 597301 ) on Monday March 10, 2003 @06:09PM (#5480214) Homepage Journal
    I love the smell of sub routines in the morning

  • More Information (Score:3, Informative)

    by Anonymous Coward on Monday March 10, 2003 @06:15PM (#5480264)

    The Previous Apocolypses [perl.org] as well as some more info (who's who, list summaries). Read up!

    On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)

    • Re:More Information (Score:3, Insightful)

      by jbolden ( 176878 )
      I don't know the other two but fro what I've heard:

      Python --
      Similar to Perl. Tighter syntax, slightly less flexable

      Ruby --
      Much better OO implementation much smaller library.

      So Perl 6 should be way more flesable than either of the other 2. We have to wait another 4/6 apocylopses to see about the comparison of the object orientation.
      • Actually, my experience is quite the opposite. Python is much more flexible then Perl. I keep trying to do things in Perl that are easy in Python, and they are either difficult, impossible, or too dangerous due to other side effects. One biggie I wanted recently was to wrap a method in an object with something else. In Python like this:

        o = SomeObject() # with method "method", let's say
        def method_wrapper(self, *args, **kwds):
        print "I'm a wrapper!"
        self.method_orig(*args, **kwds)
        o.method_wrapper = o.method
        o.method = method_wrapper

        Perl wouldn't let me do that. So I went a different route with anonymous subs and it's fine, but this is just an example of a general principle, which is that in the (useful!) tricks department, I'm usually stuck in Perl when in Python it'd be easier. (Metaclasses, anyone? I'm not even certain it could be done correctly in Perl.)

        Now, that shouldn't be a shock. There is a price to pay for Perl's flexibility, as well as gains. There is a price to pay for Python's "tighter" syntax, but gains as well. (Python is also much easier to mentally model, for what it's worth; I feel I could re-implement Python in a reasonable amount of time, I don't feel like I could ever quite match Perl's quirks.) Both languages have their place.
        • I don't agree with you about less flexible. I'll certainly agree that Python notation is less confusing but that is a different issue.

          Anyway I'm having a little trouble understanding what you wanted to do. It seems like you wanted to temporarily replace a function with another function with the same name. The easiest way to play these sorts of games in Perl is by using globs.

    • Re:More Information (Score:5, Interesting)

      by Skald ( 140034 ) on Monday March 10, 2003 @11:59PM (#5482361)
      On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)

      If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.

      More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.

      More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.

      If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.

      To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.

      But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.

  • In Star Trek, they always call new functionality as 'subroutines', which leads me to think that the LCARS system was written in Perl (Perl 2000 Xtreme?). A scary thought indeed...
    • Other languages have subroutines too, you know, like BASIC? LCARS in Visual Basic, now _THAT_ is a scary thought. I'd rather debug it in C or in perl.

  • Perl is turning into a completely new language (Score:4, Interesting)

    by siewsk ( 603269 ) on Monday March 10, 2003 @06:22PM (#5480323)
    I remenber the days of perl 5.004 and boy was that good and compact! Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth. As perl 5.004 it is PERFECT for replacing bourne shell, sed and awk. But instead of being stable (and not changing), it kept on changing. This is bad from a system admin point of view because you want to be sure that the script you wrote in 1999 will work in 2019 without any changes (just like bourne shell).

    Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.

    Perhaps they should have kept Perl 5 as /usr/bin/perl5 and make sure that it stays static for all eternity. There are values in things which do not change, things you can depend on year after year without fear.

  • ughgh (Score:3, Interesting)

    by Anonymous Coward on Monday March 10, 2003 @06:23PM (#5480331)
    This is why I hate Perl

    multi *caller (?$where = &CALLER::_, Int +$skip = 0, Str +$label)

    my brain can't grok that

    • Re:ughgh (Score:4, Insightful)

      by SuuSt ( 151462 ) on Monday March 10, 2003 @06:49PM (#5480513) Homepage Journal
      Heres the thing though, sure I have no idea what that says, but that's just because somebody decided to be very clever/brief/or both. Half my job is to write Perl scripts and sure there are about a million neato tricks that I could use to make my code really short and impossible to read but I never learned them and have no intention to. If you want, Perl can look more or less exactly like C, or if you want it can look like the above. It's all a matter of what you want out of perl.

      When they say theres more than one way to do it, syntax is included in there too.

    • Re:ughgh (Score:3, Insightful)

      by vadim_t ( 324782 )
      I think I have been trolled, but I'll reply anyway.

      Once I was bored and wrote one line of C code that iterated over an array, and printed its elements separating then with commas, and printed an "and" instead of a comma for the last element. The code consisted of a for, a printf, and ? :'s in it.

      Now, don't try to tell me it was readable. Every language can be used to write horrible code.

      Besides, that doesn't even look as Perl. "?$where" makes no syntactical sense, variables have names like $where and that's it, "Str + $label" makes no sense either, unless Str is a constant, and "Int +$skip = 0" makes about as much sense as in C, because supposing it's comparing an addition with 0 it should be using ==.

      • Re:ughgh (Score:3, Informative)

        by Eimi Metamorphoumai ( 18738 )
        If you'd read the Apocalypse, you'd know that that line was taken directly from it (although it was an example of a possible implementation of a bit of the internals of perl).

        • Re:ughgh (Score:2, Interesting)

          by vadim_t ( 324782 )
          It's ugly indeed. But internals are rarely pretty. Just take a look at files in /usr/include, stdlib.h, for example. I wanted to paste here an example, but darn slashcode asks me to "Please use fewer 'junk' characters".

    • Re:ughgh (Score:2, Insightful)

      by fanatic ( 86657 )
      your objection might have some legs if you had at least used vlid perl code.

      I can make ANY language look bad if I can break the rules.

    • Re:ughgh (Score:3, Informative)

      by wideBlueSkies ( 618979 )
      Yeah, but you don't have to write that way.

      There's more than one way to do it.

      You can write totally obfuscated/clever crap in any language. Or not. It's up to you.

    • A quick check reveals that doesn't compile as perl. And, frankly, it doesn't look like proper perl anyway. It's really irritating when people pick up obfusicated code and use that as an example from a language. Sure, you can write perl programs that are impossible to read, but you can do that with any language.

      It's not the language, it's the programmer. A good coder will make beautiful code in whatever language s/he uses. Remember, There's More Than One Way To Do It.

  • Don't forget Parrot (Score:5, Insightful)

    by Ars-Fartsica ( 166957 ) on Monday March 10, 2003 @06:25PM (#5480346)
    The VM is showing 10x speed improvements in preliminary tests. Couple that in with Moore's law and Perl (or any languages that compiles to the Parrot VM) becomes a very attractive language for more types of problems.
    • 10x speed improvement over what?

    • Re:Don't forget Parrot (Score:3, Interesting)

      by evronm ( 530821 )

      I agree. When parrot comes out, there will essentially be 4 development platforms:

      • JVM
      • MS.NET
      • Parrot
      • low level (I'm lumping C and ASM here for the sake of brevity)

      The fourth will be used for applications where speed is really key (real time, database engines, OS's, etc.)

      For all other apps, it will be a matter of choosing one of the other 3 environments, and a language.

      This choice will be particularly interesting given the fact that some languages (e.g. perl) will work with more than 1 of these environments (.NET and Parrot).

      It's going to be an interesting world...

  • Perl, the new ADA (Score:5, Interesting)

    by ajm ( 9538 ) on Monday March 10, 2003 @06:29PM (#5480371)
    I used to think that perl might become the new COBOL. Now it looks like it's going to be the new ADA. Lots of nice features but such complexity and cleverness that even the people who use it don't like it. ADA's a good language, but no one uses it. It would be a shame if perl 6 went the same way.

    Perhaps the cleverness of the ideas are not being tempered by real use at this point. A language does not become great by adding new syntax and semantics for each feature but by refining it to the essential units needed to express all the rest. We should not celebrate the fact that "will" and "is" are very similar ways to express traits in perl 6. We should ask instead why do we need both? Further, is it possible for me to define a new "wont" statement in perl, or are "will" and "is" special things only language designers can implement?

    • Re:Perl, the new ADA (Score:2, Informative)

      by TimToady ( 52230 )
      The entire syntax is redefinable, including removing will if you hate it.

      • Re:Perl, the new ADA (Score:3, Insightful)

        by j3110 ( 193209 )
        and that's a good thing?

        I don't know about you, but I like my languages to be pretty static. You can't really learn a language that's different everyday. Also, I don't like languages that let you do things 80 different ways. There are enough fights over where the curley braces go. Perl is not a team sport. Open source perl scripts are slightly less open than open source programs.

        Now, if Parrot has only one instruction for things like "until" and "while", and someone wrote a decompiler that supported each person's own style of programming, then we may be in business :) (assuming it saves as much info as Java does in the byte-code)

        This is kind of like the whole .Net issue. If the program can be converted between the languages that the CLR supports, it would be infinitely more useful. If Perl can convert between any of the million dialects that any given user will use, then it stands a chance of making it much easier for people to share perl code.
    • Lots of nice features but such complexity and cleverness that even the people who use it don't like it.

      IME, Ada is exceptionally well-liked by the people who know it (note: use != know). I've seen far fewer complaints about it from Ada programmers than I've seen from, e.g., C++ or Perl programmers about those languages.

      ADA's a good language, but no one uses it.

      Right, just like how no one uses Linux on the desktop.

    • Re:Perl, the new ADA (Score:3, Insightful)

      by gse ( 68728 )
      Ada is, in fact, a really great language. It's not really that complex (though Ada compilers are) or clever; in fact, it reads more naturally than most languages I've used. (and much more naturally than most perl -- talk about cleverness.)

      I attribute Ada's glorious failure to a few things, and none of them are the language itself:

      • It was developed by the gov't. Nobody likes the gov't.
      • The compilers are, like I said, really hard to write. So it took a long time for them to get implemented right, and there sure weren't any free (or even "affordable") ones for a long time.
      • And the big one: no standard set of class libraries. No Java-like API, no STL, nothing. If you wanted a linked list you had to write it yourself. The Java API is half the reason that Java is so great to work with, and IMO has a lot to do with the language's success.
      I really liked programming in Ada. I hated it at first (coming from being a C hacker in college) but in hindsight, it's the only language I've used that left me a better programmer.

  • Perl 6: Replacing old cruft with new cruft! (Score:4, Insightful)

    by wackybrit ( 321117 ) on Monday March 10, 2003 @06:55PM (#5480554) Homepage Journal
    I am a Perl fanatic. I love Perl. But what is going on with Perl 6? The guys working on the Parrot [parrotcode.org] VM for Perl 6 are doing such an amazing job, but I'm pretty dismayed about the language development on Perl 6 itself.

    Perl 6 was meant to be a total rewrite. Nothing was meant to be sacred, cruft could disappear, and we'd be left with a mean language, true to its roots, and working on a hot new VM.

    Instead we get stuff like this:

    sub *print (*@list)

    Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

    Each page of this Apocalypse presented me with a new piece of cruft to look horrified about. Slurpy arrays!? Oh my god. Wall even goes on about 'psychological reasons' for syntax! 'Default values' and 'Rules' are things that are easily done with existing code.. it's not even as if they result in particularly crufty code in Perl 5.

    I'm still looking forward to Perl 6, but it really does seem as if Parrot is where the true action is. Perl 6 really does look as if it is being designed by committee.

    • Use what you need (Score:5, Insightful)

      by Ars-Fartsica ( 166957 ) on Monday March 10, 2003 @07:07PM (#5480679)
      Perl 5 already contains enough crap to confuse even perl "experts", yet this doesn't stop adoption. Take Bjarne's advice and only use the parts of a language you need, ignore the esoterica. Something else confuse you? Ignore it. Chances are you don't need it anyway.

      Perl has always had a lot of esoterica. Don't let it bog you down. You can be amazingly productive in perl without ever knowing what a typeglob is.

    • Re:Perl 6: Replacing old cruft with new cruft! (Score:4, Interesting)

      by gmuslera ( 3436 ) on Monday March 10, 2003 @07:38PM (#5480919) Homepage Journal
      Instead we get stuff like this:
      sub *print (*@list)
      Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

      Perl is more based in natural languages than in "traditional" programming languages. In natural languages, what you are saying depend on the context, the same words say different things if they are used in diffeerent situations or positions inside a phrase.

      Well, in perl that also happens (in perl 5 you'll find a lot more examples of this, starting with the "$" in $a, $a[1] and $a{"red"}).and I think that it was more common in the previous versions (at least in Perl 6 I believe you'll have $a, @a[1] and %a{"red"})

    • The interesting thing about Larry Wall is: he is a linguist. That is a scientist researching how the human mind works with language, how language is structured and how language works.

      I have heared that he explained in his first books how perl works from natual language point of views.

      In the Apocalypses I saw also a lot of reasoning about how something is seen by a the human mind.

      I can not help myself. But PERL transforms even more into a unreadable language.

      I wrote a lot of perl scripts in Perl 4, about 300k LOC. After not looking at them after 1 or 2 years C++ coding, most of the tricks I used I did not understand anymore ... erm, thats 6 years ago, Perl4 is nealry 10 years ago.

      Every time when I see a post about a new language I jump on it as I was a language geek when I started programming.

      As soon as I see more than one $ or % or # sign in a sinlge line of code, I just trash the language.

      I simply can not get why this is needed. I fully agree with the one who said programming languages should approach english. (probably because I learned Pascal as first true programming language, after BASIC and assembler)

      I think a programmer should be able to read any program in any language. Or at least should be able to get a clue about what a program does, and how it does it.

      Thre are so few constructs: variables, declarations, definitions, statements, structures, arrays.

      Around that some programming concepts are woven .. imperative, declarative, functional ....

      Why to make that more complex by silly abreviated keywords? (sub in perl, def in python) By useless and meaningless (for a uneducated reader) $ and # and % signs?

      Perl is a language you an not learn by examining perl programs. You need a geek explaining it or time to read ALL docs. Thats a true draw back .... everybody who knows Pascal, C, C++, Ruby, Python, Ada can read Java.

      Thats basicly why I stopped using perl. When Perl4 emerged I thought, better than C-shell definitly ... now I write bash ...

      Well, and I left C++ and went to Java :-) With Java 1.5 I have all a language needs, except multiple inheritance :-/

      angel'o'sphere
    • Larry Wall does seem to have taken seriously the "Nothing is sacred" bit. Earlier in Apocalypse 5, he wrote (about the earlier (?...) regex syntax decision) "It's not correct now, since the Perl 6 approach is to break everything that needs breaking all at once."

      So, I wouldn't worry too much about it. Perl 6 will be different from 5. It appears that it should be better when you look at it from certain directions, and worse from others. Paradigm shift? Sure. I think lwall just got bored with where Perl 5 was going, and wanted to do something different.

      Anyway "* signifies a glob" is one of those sacred things that was to be examined carefully. I'm guessing that most useful existing Perl 5 code doesn't use "*" that way except for filehandles. Several other 'modern' languages use "*" for type definitions, so it might make sense from the point of making it easier for a new Perl6 programmer to learn.

  • Will Perl 6 lead to Slashcode 3? (Score:3, Insightful)

    by mhesseltine ( 541806 ) on Monday March 10, 2003 @07:01PM (#5480602) Homepage Journal

    Considering all the features available, it seems like this would be the ideal time to freshen up slashcode. Then, maybe we'd see valid HTML 4, CSS support, layout without n-level deep tables, etc.

  • Seeing the forest through the trees (Score:5, Interesting)

    by RichDice ( 7079 ) on Monday March 10, 2003 @07:06PM (#5480667)
    On first glace, the P6 syntax looks... scary. And I'm even someone who's been into P6 (at least marginally) for a few years now.

    What I think though is important to remember is that if all you look at is the syntax, you won't appreciate the power -- and simplicity -- of the idioms. Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.

    That vast majority of all this new syntax will be applied in the vast minority of programming cases. Much of it will get sucked up into modules, classes, etc., that you'll use without worrying about what's actually going on under the hood. And "the rest of us" will just have an incredibly powerful language that is actually easier to program.

    Cheers,
    Richard

    • Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.

      Probably so...though a lot of this is because individual Perl programmers will each learn their preferred subset of Perl6, and will use it. Woe, woe unto the maintenance programmer who has learned a different dialect of Perl6! Woe unto the maintenance programmer when you have redefined the language syntax for your own convenience!

      And "the rest of us" will just have an incredibly powerful language that is actually easier to program.

      Easier to write, harder to read once written. Languages with a lot of syntax are the Dark Side of the Force.

  • Write Only Language (Score:2, Flamebait)

    by Opiuman ( 172825 )
    This is not meant as flame-bait -- I've really tried to learn Perl. Even though I'm a 'real' programmer, I am not biased against scripting languages -- in fact, I think that the so-called 'duct-tape' languages are super-useful and important to technology in general.
    Having said that, IMHO:
    a) Perl, in the quick-and-dirty sense, is too dirty and not quick enough.
    b) Have you ever seen C-obfuscation championship code? Now have you seen a Perl program that does anything more than "Hello World"? Notice the similarities?
    Now I know that you can write bad code in any language, but bad-code in Perl is what I call 'job-security encryption' as you will never be able to fire the person who wrote the code, no matter how bad it is, because no one else will be able to read it. Either you re-write completely it or you keep that hacker...
    On a side note, speed optimization in Perl tend to create spaghetti code with weird symbols for meat-balls. And I love meat-balls.
    • Perl provides syntactic shortcuts and people use them. You do not need to use them. You can write Ada/Java-like incredibly verbose muck in Perl if you like. No one is forcing you to take the shortcuts....yet people do. Why is this? Because time is more valuable than code to many people.
    • Now I know that you can write bad code in any language, but bad-code in Perl is what I call 'job-security encryption' as you will never be able to fire the person who wrote the code, no matter how bad it is, because no one else will be able to read it.

      I've seen job-security code written in quite a number of languages. Even Java, which was clearly put together with the idea that a compiler could force conformance to 'proper' approaches.

      If you are worried that somebody is writing crappy, unmaintainable code, the solution doesn't lie in tools. If you want to be sure that code can be maintained by other people, then you should have other people try to maintain it. Extreme Programming's practice of collective code ownership is one great way to do that. Other ways include mandatory rotations, code reviews done by people who will have to maintain the program, and code audits done by trained auditors.

      There are also some automated design and code analysis tools that can help (like SmallWorlds [thesmallworlds.com] or the handy copy/paste detector [sourceforge.net]). But tools and audits are never a perfect substitute for the real thing.

  • GCC Larry.pl -Wall (Score:3, Interesting)

    by smittyoneeach ( 243267 ) on Monday March 10, 2003 @07:29PM (#5480852) Homepage Journal
    I'm waiting for Perl6 before I get too serious about Perl, as I don't want to have a lot of unlearning to do
    Got about 10 pages into it before the /.ing. What a provocative language.

    Question regarding:
    my %pet is Hash of Array of Array of Hash of Array of Cat;

    why not:
    typedef my Hash of Array of Array of Hash of Array of Cat %pet;
    IMHO, without typedef, C++ would be lost, particularly when the STL is on the loose...

    Larry, your Boss is as good as mine... ;)
    • I'm a thorough perl evangelist, but I usually end up telling coworkers to wait on Perl 6. As soon as they start dipping their toes in the water, they run across some weirdness that's not very intuitive to them. Invariably perl6 has changed that feature to be the way the newbie initially thought it should be.

  • Forget the interpreter... (Score:3, Insightful)

    by jkauzlar ( 596349 ) on Monday March 10, 2003 @07:46PM (#5480969) Homepage
    When does the book come out? Larry Wall's Perl 5 manual was the most fun I've had reading a computer book. Is he going to top it with the Perl 6 book?
  • I took a class in Java once, and I remember something about JavaDoc, which would let you comment your code in a special format, and you could run something that would produce automated documentation based on your comments. I LOVE this idea, and have been wondering if there's something similar for Perl.

    I started putting my comments in a particular format, and wrote a Perl script to grab them all and generate an HTML page, which I can print and tape to my wall for reference. When you've got 3,000 lines of code in custom modules, it's nice to have a reference when you forget what order a sub takes its arguments in. I shouldn't have to write my own documentation script. Nor should I have to maintain documentation in a seperate file, and worry about it getting out of date when I make changes.

    Can somebody point me in the right direction? If there is no such thing for Perl 5, will there be for Perl 6?

  • he's insane (Score:2, Funny)

    by erikdotla ( 609033 )
    my %pet is Hash of Array of Array of Hash of Array of Cat;

    which might really mean:

    my %pet is Hash(keytype => Str,
    returns => Array(
    returns => Array(
    returns => Hash(
    keytype => Str,
    returns => Array(
    returns => Cat)))))

    or some such.

    Larry's losing it. He's going to snap at any moment. Nobody can keep this up for long. If you're near him, grab a raincoat, he's going to explode at any second.

    Seriously though, Larry, you're a genius.

    Do not read the paragraph below:

    This comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. So I did, by adding this paragraph, hoping to throw it off.

  • A completely different kettle of fish (Score:5, Insightful)

    by ralphclark ( 11346 ) on Monday March 10, 2003 @09:48PM (#5481743) Journal
    The Perl 6 feature lineup even as it was two apoocalypses ago made it clear that the goal this time is a mature and fully-featured object oriented language that also retains all the neat high level features of perl-as-we-know-it.

    This will make Perl an attractive contender for serious application development; something which it came reasonably close to in late Perl5 but didn't quite get there because while you could do most things in a consensually "proper" way, the roll-your-own methodology just wasn't convincing enough for pointy haired project managers.

    The primary difference with Perl6 is that it will have full support for strict(ish) typing and object orientation which makes it suitable for large projects where it's impractical to expect programmer A to know anything about how programmer Z's module is implemented internally and vice versa.

    The new feature set (together with Perl's availability on a wide range of platforms and the huge range of freely available interfaces on CPAN) means that Java and .NET will be facing some stiff competition in just about every conceivable application niche.

    If the speed improvements are genuine then (assuming that one were in a position to choose) for probably the first time ever we will be in a position where there is hardly any real need to maintain skills in multiple languages as Perl will be at least adequate for the vast majority of implementations. It's not unreasonable to suppose the list of exclusions being limited to CPU bound code in high-performance content servers (eg RDBMS, HTTP) and real-time and embedded apps requiring hand-coded assembler or at least tightly optimised C.

    Whether you agree with that or recoil in horror at the thought of your favourite language being marginalised, Perl is clearly not just a "glue" language any more. It's about to become a fully-fledged enterprise application development platform.

    I'm sure you've already guessed, but for the record I am very much looking forward to this.

    There is one fly in the ointment I guess. Perl, like C, is very free-form in terms of what it lets you do but the flip side of that coin is that such languages also let you write dangerously unstructured and unmaintainable code. They require good training and a degree of self discipline to use well. Self taught programmers who didn't have strict typing and nested scoping enforced on them at the beginning of their coding career almost inevitably tend to grow up writing code that is less secure and harder to read than do those who learned back in their college days to associate variable declaration at the wrong level of scope with lower assignment grades and some stern finger wagging from their tutor.

    The new Perl will continue to make the impossible possible and the merely hard very easy, but for the first time it will provide support for a more formal structure where that is considered a good thing.

    Remember though that Perl is still very much a grassroots phenomenon. Whether this hits anybody's radar screen out in the real world has to depend on how well and how rapidly it is taken up by the Perl community. i.e. upon the willingness of existing Perl code monkeys to grab the inevitable (presumably three-humped) Camel Book, learn the new features and use them deliberately to adopt a more structured and more scalable coding style.

    It's on this point I think that Perl6 will succeed or fail. We will need plenty of real world examples out there so that new users have something from which to learn righteous coding principles, and so that sceptical project managers will see successful implentations from which to draw confidence and inspiration.


  • So, I read through the recent Apocalypse and I come to a sentence a bit like this:

    '...but Perl will dwim silently if the context is a list that starts with a pair or hash.'

    Admittedly, by that point I'd already seen enough sequences of punctuation marks that I wasn't really feeling very hopeful.

    So it seems I will be living with the limitations of Ruby for quite a few years yet! Banzai!

    Can someone please make a Ruby that compiles to Parrot code? Pretty please? I volunteer to do the SVG library.

  • Perl is a Write-Only language (Score:4, Insightful)

    by Yossarian45793 ( 617611 ) on Monday March 10, 2003 @10:50PM (#5482024)

    One problem with Perl, is that it's very hard to read somebody else's Perl code. Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers. If you've ever maintained a large Perl program written by someone other than yourself, you know what I'm talking about.

    Adding more features to the language will only make this problem worse. Very few Perl programmers know more than a fraction of Perl's syntax. More syntax means more stuff that your average Perl programmer doesn't understand! This is a huge impediment to writing a large project in Perl.

    Languages like C and Java stay alive precisely because they're not very expressive. You can write huge behemoth-sized projects and still have some hope of maintaining them, because there just aren't that many ways to obfuscate the code.

    • Re:Perl is a Write-Only language (Score:4, Informative)

      by thoughtstream ( 140380 ) on Monday March 10, 2003 @11:24PM (#5482169)
      That's exactly why we made it possible to modify Perl 6's grammar. As paradoxical as it sounds, adding that flexibility gives us a way of overcoming the downsides of Perl's TMTOWTDI philosophy.

      It will be comparatively simply for a coding team to create a "policy" module (say, Policy/Our/Preferred/Style.pm) that restricts coders to an agreed-upon subset of the language's syntax and features. Thereafter, so long as every module begins with use Policy::Our::Preferred::Style, the rest of the module simply won't compile unless it conforms to the team's coding standards.

      And I suspect that enough groups will want to do this that it will make sense for someone to write a front-end module that simplifies the creation of such policies. So all your team will need to write will be something like:
      module Policy::Our::Preferred::Style;

      use Policy::Specification
      blocks => 'K&R',
      elses => 'cuddled',
      disallow => << unless until statement_modifiers junctions>>,
      # etc.
      ;
      • That's exactly why we made it possible to modify Perl 6's grammar.

        Bad idea. Look back at the history of "extensible languages" which allowed dynamic modification of the grammar. It was tried in the 1970s and early 1980s, in forgotten languages like EL1, BALM, and SPEAKEASY. Some dialects of LISP had such extensibility, with painful results.

        The proposed solution doesn't deai with maintainability. It only addresses project organization.

        A tool that converted existing Perl code into a standard format, changing the syntax without affecting the results, would actually do what the post claims. That would make code much more maintainable, if the tool was smart enough to understand the idioms of the language.

        For example, the ugly hack used to do object oriented programming in Perl 5:

        • sub buildtable($ $ $) {
          my $self = shift;
          my $item = shift;
          my $index = shift;
          my $headercontent = $self->findbefore($item,\%stoptags);
          $self->{'headercontent'} = $headercontent;
          my $captioncontent = $self->findcaption($item);
          $self->{'captioncontent'} = $captioncontent;
          ...
        ought to be automatically converted into whatever object syntax is used in Perl 6. Is anything like that coming?

        • The proposed solution doesn't deal with maintainability. It only addresses project organization.


          Huh? The only way to deal with maintainability is via project organization.

          Even the most B&D, only-one-way-to-do-it language will permit obfuscated programming. The simplest way is by the (in)judicious use of De Morgan's laws on conditionals. For the more advanced obfuscator, just write a "subtract and branch if negative" function and code the entire algorithm using nothing but that. Every programming language, no matter how strict, provides an unlimited range of choices -- of identifiers, of data structures, of algorithms.

          Coding is fundamentally about making such choices, and syntax is just the very lowest level at which they can be made. Human beings make (and disagree on) these choices, which inevitably means that maintainability is a social issue, not a technical one. So technical fixes alone can never solve the problem.

          What we're proposing instead is a tool that can support in the necessary social processes by allowing you to reward adherence to, and punish transgressions of, your preferred syntactic style. But that's still ultimately a social solution because you have to convince your team to use the tool in the first place and ensure that they don't quietly turn it off when you're not watching.

          And it still won't address the problem of getting them to choose meaningful variable names, or a sane data structure, or an algorithm that mortals can understand. No tool -- except possibly a big stick -- will do that.

          Of course, we are also offering a complete parser for Perl, written in Perl. So if you do want to grab the parse tree of a program and reformat it (applying whatever artificially intelligent refactoring you can muster), the necessary support structures for that will be there too.

    • Re:Perl is a Write-Only language (Score:4, Insightful)

      by Fastolfe ( 1470 ) on Tuesday March 11, 2003 @11:39AM (#5484602)
      Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers.

      Concede the likelyhood that this is due to one of two things:

      1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code.
      2. "other skilled Perl hackers" are not very good at reading Perl code.

      Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.

      In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.

  • Sand (Score:3, Interesting)

    by ajs ( 35943 ) <ajs.ajs@com> on Monday March 10, 2003 @11:28PM (#5482186) Homepage Journal
    Perl 6: The reason I've finally gotten off my butt and am writing Sand.

    Sand is a programming language I've been planning for a long time, but its timetable has picked up as I'm more and more convinced that Perl 6 is going to fill a niche that I don't work in. Plus, I've really never been comfortable with bytecode interpreters.

    That's not to slight Perl 6. I'm sure it will be a fine language, but I'm looking at moving on to a design that focuses on maintainability and compilability (that is: to machine code). Since none of the languages out there satisfy my desire for these attributes plus the flexibilty that I've come to love in Perl, I have to write it myself. ;-)

  • Type declarations already in perl5? (Score:3, Interesting)

    by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday March 11, 2003 @06:07AM (#5483263) Homepage
    In Perl 5 you can say:

    my Cat $felix;
    to declare a variable intended to hold a Cat object.

    You can?

    Why didn't anyone say so before? I've never seen this in Perl code until now.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close