Slashdot Mirror


Perl 6 Synopsis 5

XaXXon writes: "perl.com has Synopsis 5 for Perl 6 up. It's a brief overview of all the changes made in Larry Wall's Apocalypse 5. Lots of stuff about the new regex syntax. I must admit, however, that I'm getting tired of reading about perl 6 -- I want to start using it." We posted Larry Wall's 5th Apocalypse in May.

203 comments

  1. Does this mean... by geogeek6_7 · · Score: 2, Funny

    ... I'll finally be able to make sense of my perl code after I write it?

    ~geogeek

    1. Re:Does this mean... by Fjord · · Score: 5, Funny

      No. Perl is a write-only language. You aren't supposed to be able to read it ;)

      --
      -no broken link
    2. Re:Does this mean... by Xoro · · Score: 1

      I may be misremembering this, but my favorite new tool for perl obfuscation has got to be user-defined operators...in Unicode!

      "Well of course 'object1 [seated scribe] object2' means copy. It's a scribe..."

      --
      Kill, Tux, kill!
    3. Re:Does this mean... by jmb-d · · Score: 1

      Perl is a write-only language. You aren't supposed to be able to read it

      Ever seen APL?

      --
      In walking, just walk. In sitting, just sit. Above all, don't wobble.
      -- Yun-Men
    4. Re:Does this mean... by DGolden · · Score: 2

      I actually disklike "write only" language claims a lot - APL is/was one of my favorite languages -
      but, just as one does not expect to read Chinese without learning the language, one cannot read APL
      without learning the language - APL is a language based on familiar mathematical symbols, so it's not that hard (it's made much harder by (a) misguided attempts to ASCIIfy it and (b) non-APL keyboards)

      Similarly, most perl is actually quite readable once you have learned the language
      If one where to replace every $foo %bar @baz with scalar_foo, hash_bar, array_baz, it might be initially more readable for english speakers - but for the few minutes it takes you to learn the meaning of the symbols, you can save a lot of typing and increase the brevity of your work. A few things did annoy me about perl syntax - I dislike -> instead of . for member access, but guess what?, it's
      being fixed in perl 6.0...

      --
      Choice of masters is not freedom.
    5. Re:Does this mean... by Anonymous Coward · · Score: 0

      Thanks for point us to an APL sample code. Now that
      we saw the sample, I continue to think that Perl is at least
      one order of maginitude more horrible than APL.

  2. Perl 5 was nice by ObviousGuy · · Score: 0, Flamebait

    Perl 6 seems to be a whole new camel. This one's definitely uglier and has two humps.

    The Perl community seems to have become something of an inbred group where the only ideas come from people who have been using Perl exclusively for years. While this may be fine for a while, the end result is a jumble of personal preferences and half-baked ideas.

    --
    I have been pwned because my /. password was too easy to guess.
    1. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      either that, or you are lacking a clue. Much of the perl6 discussion is about cleaning up the jumble.

      hth. hand.

    2. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      Three character operators? No, the jumble is being added to, not taken away.

    3. Re:Perl 5 was nice by selectspec · · Score: 4, Insightful

      I don't pretend to know anything about Perl 6, and hopefully they are cleaning up Perl. However, I agree with your assessment of Perl 5: a thousand ways to do the same thing each using their own exclusive exotic ascii character combinations.

      One has to wonder about the relative success of Java, given its horrific performance and obscene installation complexity. However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library.

      Of course Java syntax is a simplification of C++, while Perl's roots are in shell scripts.

      I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.

      --

      Someone you trust is one of us.

    4. Re:Perl 5 was nice by Second_Derivative · · Score: 1

      I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.

      Would you like fries with that?

    5. Re:Perl 5 was nice by Q+Who · · Score: 1

      Damn, funny shit, I wish I had the mod points. :-))))

    6. Re:Perl 5 was nice by g4dget · · Score: 2
      One has to wonder about the relative success of Java, given its horrific performance and obscene installation complexity.

      Java performance is excellent--very close to C and C++. What gives Java a reputation for being slow is that it takes a long time to start up.

      Java is also one of the easiest systems to install: all you need to do is untar the archive somewhere, or run the installer (on Windows). Perhaps what you mean is that the Java runtime is big--but it isn't really if you compare it to other runtimes.

      However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library

      Initially, Java succeeded because it was simple and promised that people could deliver software as applets. Today, Java is widely used because it is well-supported, runs fast, has a huge library, and because it beats the alternatives for server applications.

      I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.

      Seeing how given you are to snap judgements, I doubt you would recognize such a shell if it bit you in the behind.

    7. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      Find me links for the following:

      Benchmarks of a free VM where Java performs equally on memory and speed to a myriad of equal C and C++ programs. Fine-grained analysis of things like exception handling performance, class instantion overhead, message dispatch overhead, as well as implementations of algorithms that are functionallty equivalent given paradigm differences.

      The only place where Java is popular is in the backend. Probably because a lot of these people were using Perl or unscalable C for software development, without utilizing any standard third-party libraries for simplifying development.Seeing as I've consulted for people that have moved to Java that had a policy not to use pointers in C (as they prefer arrays in a lot of industry that manages to make vast quantieis of money) and never used any third-party libraries for development. Some even would have several implementations of flat-file "databases" running over their colocated servers.

      If this sort of retardation wants to adopt Java, all the power to them. Hell, I'd almost suggest they use Smalltalk or VisualBASIC or a hammer to cave in their hollow skulls.

    8. Re:Perl 5 was nice by selectspec · · Score: 2

      Comparing Java performance to C is ludicrous, even with just-in-time native compilation of java byte code. The root cause is the extensive logical error checking in the VM's and the libraries. C code with propper compiler hints (i.e. restrict, etc) generates fewer instructions with an overall reduced cycle time.

      Installation and running of java as compared to perl is no contest (on unix). Java requires extensive and neverending twiddling aroung with your path.

      Java runs fast relative to the other super-high-level script languages used for web server.

      Don't get me wrong. I love Java. It's no C. Find me one high performance enterprize embedded appliance (router, switch, etc) with anything other than the mgmt software written in Java (if that).

      --

      Someone you trust is one of us.

    9. Re:Perl 5 was nice by mikec · · Score: 2
      Installation and running of java as compared to perl is no contest (on unix). Java requires extensive and neverending twiddling aroung with your path.
      Actually, they are almost identical in this respect. If you install all your Java classes in the extension area, you don't need a class path at all. Ditto for Perl. If you install them elsewhere then you need to fiddle with CLASSPATH or PERL5PATH, respectively.
    10. Re:Perl 5 was nice by g4dget · · Score: 2
      Comparing Java performance to C is ludicrous, even with just-in-time native compilation of java byte code. The root cause is the extensive logical error checking in the VM's and the libraries.

      Java requires array bounds checking, some null pointer checking, and a very small number of runtime type checks, roughly the same as most other high level languages. That does not impose a lot of overhead, in particular with dynamic compilation and optimization techniques. And, in practice, Java code written for efficiency runs close to C/C++ performance.

      What is true is that writing efficient Java code is cumbersome--the language does not make it easy, and most people don't know how to do it.

      Java requires extensive and neverending twiddling aroung with your path.

      So does Perl, and so do most other languages that load libraries at runtime. The only reason why you don't see it in Perl is because people usually put all libraries into the system directory.

    11. Re:Perl 5 was nice by g4dget · · Score: 2
      Benchmarks of a free VM where Java performs

      I didn't claim Java was free, merely that Sun's compiler produces good code.

      performs equally on memory and speed to a myriad of equal C and C++ programs

      On microbenchmarks (which is what you are thinking of), Java is a little slower than C/C++ because of mandatory error checking, but not significantly. Properly written, large systems are orders of magnitude faster and smaller in Java than in C/C++ because they don't need separate processes or IPC.

      If this sort of retardation wants to adopt Java, all the power to them.

      It is your sort of retardation that keeps people developing open source 300M desktops in C or C++ and live in the blissfully ignorant belief that it is "efficient".

    12. Re:Perl 5 was nice by JebusIsLord · · Score: 1

      suggesting that java is "orders of magnitude faster" at some things over C/C++ is patently obsurd because Java is written in C++.

      --
      Jeremy
    13. Re:Perl 5 was nice by g4dget · · Score: 2

      Because "X is written in Y", "X must be slower than Y"? Sorry, it doesn't work that way.

    14. Re:Perl 5 was nice by smittyoneeach · · Score: 2

      Properly written
      This is the discussion.
      You have to quantify what you mean by efficient. Ease of installation, learning, use, debugging, memory footprint, hard drive footprint, boot time, exception handling, integration, portability, what?
      While I've done no Java work, I begin to suspect that a large chunk of the people on /. touting a particular language are speaking to justify themselves more than edify the reader...

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    15. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      > I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.

      You moron.

      "bash" isn't portable, it is the Bourne language that you should have mentioned instead.

      In fact, programing "bash" instead of bourne is way to make sure your script is NOT portable.

    16. Re:Perl 5 was nice by ajs · · Score: 2

      Yep. Perl: The language for us. Java: The language for the rest of them.

      Java is nice if you want to pick up a programming language for the first time. It has the corners filed off and you won't poke your eye out with it. But, when you need the ultimate in flexibility it falls short. You can drop down to C (or C++) or latteral to Perl or Python. But, Java just doesn't give you the control over the environment that you need to cover the ground other languages do. For example, Perl is used for everything from OS installers to data modeling languages to graphics manipulation plugins for The Gimp. These are all areas in which Java is simply the wrong tool for the job.

      Now, if I were hiring a bunch of junior programmers to crank out a database app, I'd turn to Java without glancing over my shoulder!

    17. Re:Perl 5 was nice by jaypifer · · Score: 1

      One has to wonder about the relative success of Java, given its horrific performance and obscene installation complexity. However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library.

      Perhaps it was the multimillion dollar advertising campaign. Or the army of salespeople. Or the inflated consulting fees as a result of such.

      Almost any product can be successful if you throw enough money behind it.

      --
      Never go to sea with two chronometers; take one or three.
    18. Re:Perl 5 was nice by JebusIsLord · · Score: 1

      How is Java supposed to do something faster than C++ if the original Java source code to perform that function was in fact a C++ function? Java cannot be faster since it is still executing the same thing it would be were it native C++. See?

      --
      Jeremy
    19. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      For your sake, I hope you're trolling. Who are "you"? (A script kiddie?) How are you different from "us"?

      Perl is not the language of choice for anything. The reasons are almost too numerous to count.

      Perl's syntax makes it virtually impossible to read. Common sense suggests that when there are 100 ways of doing anything, the permutations are endless. Hope you didn't need to edit that program of yours, fella!

      Perl does not offer strong typing or a truly object-oriented model. As a structured programming language, Perl is a cruel joke. Hope you didn't need to write more than 100 lines... because it will turn into mush.

      The one thing that perl does reasonably well is operate on text files. But there are many other languages (awk, sed, Python, and bash scripting spring to mind) that do the same thing far less painfully.

      And anyway, who would consider scripting on the same level as programming anyway? Scripts are mostly used for cleaning up messes. Many scripts tend to be programmed assuming a certain implementation of things (example: I know the latest version of program x will spit out N lines of text that all begin with Y, etc. etc.), not to an abstract interface. Consequently they are brittle and difficult to maintain.

    20. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      Hmm... maybe it's the fact that Java is 10x more maintainable than perl? Or that it protects against common programming errors?

      And Java isn't that slow with a good VM.

    21. Re:Perl 5 was nice by elphkotm · · Score: 1

      I work for small shipping company, every webapp is Java besides tracking (that's C, of course). And there is a nice myth that Fortune 500 companies have huge amounts of cash to burn, which is... a myth. Everything is engineered be faster, cheaper, and better. Matter of fact, we have signs all of the place that say that :)

      --

      <Amanda`> I just went out to the parking lot in my bathrobe to exchange warez CDs.
    22. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      How is Java supposed to do something faster than C++ if the original Java source code to perform that function was in fact a C++ function?

      Because it was implemented in bad C++, while Java is implemented in good C++?

      For instance the Java code uses hash tables, while the C++ code loops on arrays? This is stupid, but happens all the times when people are coding in low level languages without using all the libraries.

    23. Re:Perl 5 was nice by g4dget · · Score: 2
      Java cannot be faster since it is still executing the same thing it would be were it native C++.

      Java gets translated into byte code, and the byte code gets translated into machine code. The machine code is then executed. C++ isn't involved in the execution at all.

      Think of it this way: the JIT compiler is like someone who gives you directions. How fast you get to your destination doesn't depend on what kind of car the guy giving you directions has, but it depends on how fast your car is and how good the directions are.

    24. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      Perhaps it was the multimillion dollar advertising campaign. Or the army of salespeople. Or the inflated consulting fees as a result of such.
      Almost any product can be successful if you throw enough money behind it.

      Or more likely, it was the fact that it was also really abetter C++, at a time people started to realize C++ sucked (having experimented it for a few years, at the time), and the C++ hype faded.

    25. Re:Perl 5 was nice by g4dget · · Score: 2
      Properly written. This is the discussion.

      No, it isn't. I made a specific claim about execution speed.

      While I've done no Java work

      So, what do you base your opinions on, then? I use both Java and C++ for my work.

      more than edify the reader...

      Your edification is your own responsibility; you can hardly expect a free education from Slashdot. What you can get, however, is people challenging your assumptions and sharing their own experience. And my experience is that, properly used, Java can be nearly as fast as C++ for compute-intensive stuff, and it can be a lot more responsive and a lot less resource intensive than a C++ GUI environment. Think for yourself. Think about why Windows and Gnome/KDE are so huge. Try to find some fast Java apps and pick them apart. Etc.

    26. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      ---
      Common sense suggests that when there are 100 ways of doing anything, the permutations are endless. Hope you didn't need to edit that program of yours, fella!
      ---

      This is called choice (that is why for example some ppl choose linux-over-win).
      And also Perl is much closer to the human language than the others...

      very, very simple example, why should I write :

      if ($x > 10) { print 'blah'};

      when I can write it more clearly and shorter :

      print 'blah' if $x > 10;
      or if u want (perl6) :
      if $x > 10 { print 'blah'};

      Why should I use :
      if (!....) {...}
      when I can use "unless".

      so again it is called CHOICE and I like a programmer dont want to write kilometic-lines (java) to do simple things, mumble with memory/pointer probs (C), use white space to distinguish when block start/ends (python)...etc..

      but again this is my choice and will not balme u if u dont use perl.

    27. Re:Perl 5 was nice by ajs · · Score: 2

      For your sake, I hope you're trolling. Who are "you"? (A script kiddie?)

      "I" am the author of numerous Perl modules and a contributor to various Perl-related publications and a professional Perl hacker. Not that it matters.

      Perl is not the language of choice for anything. The reasons are almost too numerous to count.

      The reasons that every language is not ideal are almost too numerous to count. Perl just happens to have a lot more going in its favor than most.

      Hope you didn't need to edit that program of yours, fella!

      I have no problem editing my Perl. In fact, my co-workers have no problem (except where I use features like the C-library interface or complex process control that would be difficult for others no matter what language you were using). Modules are a huge advantage for programming in the large.

      Perl does not offer strong typing

      Very true. Also a benefit. I would suggest that only LISP rivals Perl for the availability of truely generic data types.

      ... or a truly object-oriented model.

      It depends on how you mean that. It does not offer a strong OO model, in the sense that Perl5's object model is fairly loose. This reflects the state of OO when Perl5 was written. C++ was young and seemed to be a poor model, but it was the one most people were paying attention to. Java did not exist. Smalltalk was nice, but no one wanted to think that way any more.

      Now, Java has had its impact (I think Java's OO model is rather nice, though it has many problems that stem from its typing model) and other high-level languages like Ruby, Python, Eiffel, etc have changed the way we think about OO programming. It is now time for Perl to come in and do what it does best: deconstruct the best practices and adopt them as its own. This is one of the many things you have to look forward to in Perl6!

      Hope you didn't need to write more than 100 lines... because it will turn into mush.

      Counter-examples: LWP, PDL and many, many... MANY projects I have worked on alone or with others. PDL (Perl Data Language) is a prime example as it shows Perls ability to bring other components together. PDL is made up of Perl, Fortran and C. It offers one of the most complete scientific data languages available with high-performance transformations on low-level data such as binary streams, images, etc.

      Also keep in mind that because of very-high-level complex datastructure handling, Perl makes it possible to write LESS code than most other languages.

      The one thing that perl does reasonably well is operate on text files.

      Spoken like someone who doesn't use Perl in the large. The one thing Perl does well is just about everything. Check out CPAN (the other MAJOR reason to use Perl).

      But there are many other languages (awk, sed, Python, and bash scripting spring to mind)

      If you think of Perl as being on the same level of usefulness as Bash, then I'm not suprised you've never made use of it. I'm sorry.

      And anyway, who would consider scripting on the same level as programming anyway?

      And who would consider Perl to be a language only capable of "scripting"? Scripts are traditionally run-time interpreted (Perl is compiled into a syntax tree, optimized and then exectued just like many other high-level languages). They also lack complex data types (Perl programs routinely create very complex arbitrarily deep datastructures casually; lists of hashes of lists of objects are quite common and easy to create in a couple of lines of code). Scripts are also hard to debug; Perl comes with a built-in symbolic debugger.

      Learn the language; you may be suprised.

    28. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      Literature still shows Java (JIT) to be slower
      than C++, if only by a linear factor; comparing
      it to plain C is just wrong. If you are even
      remotely insightful you'll know why a commercial
      quality, highly optimizing compiler will always
      generate better code than a runtime JIT that
      has an added constraint that it must do its work
      fast enough not to kill the loadtime performance.

    29. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      so again it is called CHOICE

      In your example, you wrote exactly the same thing in 3 ways. And of course, while maintening code you'll find that someone chosed the more creative ($x > 10) && (...); instead.

      It wouldn't be a problem if it were 3 different unrelated concepts. But it's the exact same thing. Why can't design effort be spent in designing "class" properly, raising exceptions whenever you attempt to do something dubious (like adding a string to an int), have decent argument passing, instead of wasting code to do the millionth variation of such mudane thing. What's next? Allowing function names to be spelt backwards (like ftnirp) ? Allowing functions abbreviations? (like fpr.) ? Allowing lines to be shuffled with a given permutation ($$$3.0.1.2 {...} means line 3 should be taken first, then line 0, line 1 and line 2 and repeat module 4) ? Automatic initialisation of variable depending on name? ($a... to $j... are initialized to 0 by default, and $k... to $z... are initialized to 1 y default) ? Choice is such a good thing! - Not.
      Bloat is bloat, and Perl is to languages what Windows is to OSes. What is amazing is that people actually stand up to defend this monstruosity as a good thing. It's no wonder Bill Gates is rich.

    30. Re:Perl 5 was nice by Anonymous Coward · · Score: 0

      why not.. if u are shell-guy it can be better written in this way... I just wanted to show u that f.e. for me the best way is to write it :
      print $x if $x > 10;
      But if u are acustomised to C then the first variant may be better.

      It is a matter of company policy to choose and/or mandate some style it should not be the Language to do this 'cause even the cleverest man can be short sighted.
      See the Perl language designer Larry Wall is a linguist and Perl6 comes closer to the natural language than to machine-language. Say English is very ambigous but it evolved and is still used 'cause it is rich in expression. ...etc..etc...

      If anyone is dull enought of cource it can shut itself :"), but I'm okay with this and if u have some problem with many ways to do it u can write a filter (Perl5) or directly use the new Perl6 reg-ex and on the fly grammar changing to restrict yourself or your emploees to not do forbidden things...
      In fact U will be even able to easly change the Perl parser itself 'cause it is written in Perl.
      (you havent followed the Perl6 designing process but the ability to easly handle small-languages was one of the goals and it is handled very well with the new regexes).

      See may be for you and other posters this can be a bad thing but for me it is not... that is the main idea i try to express here, no one has to decide instead of me. The only time i may allow someone to tell me what to do is if it pays me well :"))
      Restriction sooner or later become DRAWBACK rather than ADVANTAGE.

      TO ALL : anyone not satisfied with the changes in Perl6 can freely contribute and participate in the process of designing and implementing of Perl6. There is many clever ppl out there on perl6-lists which will listen to U if u can give them a resonable reson why not to do something. It is not some closed project, so u should blame yourself for this not the pll which are doing it.

      And Perl has nothing to do with Windows ?! it is total nonsense what u said!

      keep using other languages I have nothing against that and of course u can use from time to time Perl1 'cause it has very simple syntax :"))

    31. Re:Perl 5 was nice by Anonymous Coward · · Score: 0
      If you are even remotely insightful you'll know why a commercial quality, highly optimizing compiler will always generate better code than a runtime JIT that has an added constraint that it must do its work fast enough not to kill the loadtime performance.

      It's the same as saying "you'll know why Transmeta stuff cannot work". Because they do exactly that... a JIT for x86 code. Of course, you are also proven wrong by JIT machine code specializers which can gain 10% compared to highly optimizing *static* compiler. Guess why? At runtime you have more information than at compile time. Thanks for playing.

    32. Re:Perl 5 was nice by g4dget · · Score: 2
      Quite to the contrary: a JIT has the complete program available for optimization (even dynamically loaded modules) and, in addition, can collect detailed runtime statistics. For compute-intensive programs, it can also spend lots of time optimizing inner loops. Furthermore, that optimization doesn't happen at load time at all (it would be stupid if it did, since the compiler has no runtime statistics yet). In contrast, a C++ compiler can perform no optimization between compilation units and it has no information about which code needs to be optimized. Batch compilers are very limited in the kinds of optimizations they can perform.

      In any case, the reason why systems written in languages like Java are often much more efficient than systems written in C/C++ is not because Java can be compiled well (which it can) but because Java is safe. In something like Gnome or KDE, every single desk accessory is its own process, using some inefficient IPC or DO mechanism for communicating with the rest of the system. In something like Java, all those can run in the same process and just pass data structures. Using C++ for such applications is penny-wise and pound-foolish; the resulting software systems are ridiculously inefficient.

      C and C++ have their uses and they are great languages for some problems. But 95% of all C/C++ applications would be faster, smaller, and work better if they were written in something else.

  3. Re:Perl Sucks by Anonymous Coward · · Score: 0

    you're on glue. php is useless as a general purpose language, even as a glue language.

    or are you one of those wannabes who think web scripting is what coding is about?

  4. So why don't you? by JoshuaDFranklin · · Score: 3, Informative
    I must admit, however, that I'm getting tired of reading about perl 6 -- I want to start using it.

    Well, go right ahead. From the Parrot VM, the Perl6 engine, page:

    Can I use Parrot today?

    Well, almost. :^) Parrot is in the early phases of its implementation. The primary way to use Parrot is to write Parrot assembly code, described in PDD6.

    Use Perl6--Write some Parrot assembly, and help out!
    1. Re:So why don't you? by freshmkr · · Score: 1
      But parrot isn't Perl 6. Don't believe me? Just scroll up:
      Is Parrot the same as Perl 6?

      No. Parrot is an implementation that is expected to be used to execute Perl6 programs.

      Parrot is likely to be the runtime for Perl 6, but it isn't the language. Conceivably many runtimes could be written for Perl 6, all different. Saying writing Parrot code is the same as writing Perl 6 code is like saying writing x86 assembly is the same as writing Visual Basic.

      --Tom

    2. Re:So why don't you? by 'The+'.$L3mm1ng · · Score: 1

      Is it just me? I thought Perl 6 will "simply" translate from Perl to Parrot Assembly language. A usable Parrot has nothing to do with a usable Perl 6. You can use Perl 6 when both Parrot AND Perl 6 itself are done. Right?

    3. Re:So why don't you? by Anonymous Coward · · Score: 0


      If you want to validate perl 6 code, you might want to check out:

      http://archive.develooper.com/perl6-language%40per l.org/msg10223.html

      --
      ralph

  5. PHP better than Perl by totallygeek · · Score: 3, Interesting

    php is better.

    Perl is not just for web programming! I doubt that web programming is mostly what people use perl for. Even the name perl suggests its strength is a report-generator or text parser (practical extraction and reporting language).

    I use perl for web and for just general-purpose Unix programming. I still use c for some larger coding projects, but am more and more finding myself coding with perl. And, I never use shell scripts anymore -- well, unless I am on an older Unix box.

    Perl rocks. PHP rocks. C rocks. Pascal rocks. Bash rocks. One just isn't any better than any other, if the one you are using gets you the desired results (speed, speed of coding, ease of use, correct answers to problems, etc.).

    1. Re:PHP better than Perl by darkonc · · Score: 2
      Perl rocks. PHP rocks. C rocks. Pascal rocks. Bash rocks. One just isn't any better than any other.....

      Until you got to the Pascal rocks part, I was right with you. Pascal was a teaching language with arbitrary restrictions that should have never made it out of the classroom. If you want a nice language along that line, try ALGOL/68.

      --
      Sometimes boldness is in fashion. Sometimes only the brave will be bold.
    2. Re:PHP better than Perl by bad-badtz-maru · · Score: 1


      Pascal, as extended in Delphi and Kylix, rocks...

      maru

    3. Re:PHP better than Perl by Anonymous Coward · · Score: 0


      Pascal does rock for what it was designed for -- teaching.

      Having seen the results of teaching first year students Java as compared to when they were taught Pascal, I can say with certainty that pascal rocks.

    4. Re:PHP better than Perl by zmooc · · Score: 2

      Which restrictions do you mean?

      --
      0x or or snor perron?!
    5. Re:PHP better than Perl by darkonc · · Score: 2
      It's been a very long time since I've used pascal (for obvious reasons, given my last post). The two obvious restrictions that come to mind are the inability to allocate variable sized arrays and an I/O system that's rather grotty.
      being forced to use begin and end instead of brackets didn't help me much either.

      You can use extensions, but then you lose the portability. At that point, what's the real purpose of using a high-level language? Pascal is fine for teaching, but it's not designed as a production language, and it shouldn't generally be used as one.

      --
      Sometimes boldness is in fashion. Sometimes only the brave will be bold.
    6. Re:PHP better than Perl by totallygeek · · Score: 2

      Until you got to the Pascal rocks part, I was right with you.

      At work, we still have to use RPG. So, RPG rocks for its purposes on that platform.

      In some situations, I have many Pascal tools that I must use, so Pascal rocks. The equivalent c code is extremely hard to implement.

      I still use Pick in some situations. I still use Assembly in others. To say one language is better than another in all instances cannot be justified. That is all I was saying.

    7. Re:PHP better than Perl by 'The+'.$L3mm1ng · · Score: 1
      Perl is not just for web programming!
      PHP neither. To me PHP seems to be about as specialized for web programming as Perl + CGI + DBI are...
    8. Re:PHP better than Perl by Maax · · Score: 1

      Brian Kernighan's well known 'Why Pascal Is Not My Favorite Programming Language'.

  6. Perl 6 Synopsis 5, 5th Apocalypse by Anonymous Coward · · Score: 0

    Looks like a reference in some holy book.

    1. Re:Perl 6 Synopsis 5, 5th Apocalypse by flonker · · Score: 3, Funny

      "And they wandered the desert for forty years, until they found the llama, and the llama led them to the camel of Wall." Perl 6:Synopsis 5,5th Apolcalypse.

  7. Re:Perl Sucks by Anonymous Coward · · Score: 0

    You're a moron. You couldn't "code" your way out of a paper bag.

    Go upstairs. Your mom is calling you.

  8. Re:Perl by Anonymous Coward · · Score: 0

    you are simply a fux0ring stupid so-called person.

  9. Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 2, Insightful

    For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.

    Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.

    I'd prefer to think of this as provocative rather than a flame, there is a difference you know.

    1. Re:Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 1, Insightful

      I find it amazing how many clueless people like you pipe up with the demise or Perl, or its unsuitability for X task, or some other random demerit. Slashdot is useless for Perl news because 9/10ths of the posts are clueless idiots writing about how awful Perl is, whereas those of us who actually use perl (to whom the information is pertinent) have to wade through it.

      Your article is nothing but vague hand-waving. I am a professional programmer, I want specifics if you want me to take you seriously.

    2. Re:Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 0
      Your article is nothing but vague hand-waving. I am a professional programmer, I want specifics if you want me to take you seriously.

      There was: "I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl."

    3. Re:Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 0

      Those are not specifics. The quote you just pasted just says "I don't like perl. I like these other languages better. I've been a professional programmer".

      "I say so" is not the same thing as specific arguments for or against a language.

      -- a different AC

    4. Re:Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 0

      How true. Perl was a great learning experience, but other languages have taken it a step further, such as Ruby and Python, to name but a couple. Perl folks should step out and check out the current landscape. It is richer than they could imagine. It's there for the taking. Come on down!

    5. Re:Perl's had it's day - It's become like COBOL by Tony+Hoyle · · Score: 2

      I started using perl many years ago. Back then I really liked it, then they started trying to turn it from a useful scripting language (Practical Extraction and Reporting Language, remember... It's for text processing and formatting the output) into some kind of OO wannabee.

      Read the old edition 1 camel book - it's clear and concise, easily readable and makes you want to go out and code. I have the latest edition... it's 4 times the size, rambling, and doesn't seem to ever get to the point. There's only 3 pages on the reporting side of perl now - it's like they're ashamed of it or something.

      Perl should have been left at what it was good at - there are other languages for large scale programming.

    6. Re:Perl's had it's day - It's become like COBOL by Anonymous Coward · · Score: 0
      Those are not specifics. The quote you just pasted just says "I don't like perl. I like these other languages better. I've been a professional programmer".

      Granted. Shall we go again enumerating step by step all the drawbacks of Perl? The main problem of Perl isn't even the individual problems, the problem is that overall it is clumsy, badly designed, because instead of taking the important language ideas and implementing them in a clean, orthogonal way and wasting less time on less important things, Perl seems to put everything at the same level, important language features, tricks, shortcuts, special cases ; and let everything grow while at the same time, trying here-and-then to patch some features to fix the design oversights.

      In short, Perl is badly designed... like Windows. Like Windows 2000/XP, it works ; like Windows, it improves ; like Windows, there is nearly hopeless mess in the core (the registry+many GUI only tools in Windows case).

      BTW, in my mind, the specifics were:
      ((The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl."))

      I challenge you to show which features are implemented in Perl with a better design than in those languages. Argument passing? Classes? Inheritance? Lambda? Nested scope? Iterators?...

  10. Re:Perl Sucks by blinov2000 · · Score: 0

    yes, imho php is better but what can I do if my prorgammers (here) used perl? if I want to use only php now must I rewrite perl modules or not?

  11. Good stuff by Starky · · Score: 2, Interesting
    I've been reading the Apocalypses with interest as well as the comments from the peanut gallery.

    For all of the hub bub and brouhahah, I think after it is released and people start to explore all the new (and old) features, folks are going to find Perl 6 an amazing tool that improves on an already amazing tool set.

    With all of the flame wars regarding Perl/Python/Ruby (like triplets calling each other ugly), it's good to see Perl continuing to innovate, improve and set a brisk pace for others to follow.

    --
    -- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
  12. Rename it, it isn't Perl anymore by ToasterTester · · Score: 4, Insightful

    Wall has changed the language too much and now more regex changes. Like Pascal when major updates became Modula or later Oberon. Original Pascal was left to evolve on it own. Same with Turbo Pascal when Borland heavily changed it they changed the name to Delphi. Call Perl 6 the new beast that it is.

    1. Re:Rename it, it isn't Perl anymore by Anonymous Coward · · Score: 0
      QA people have been trying for years to stop people from writing code like:
      while (x = *(*jigs.foo->bar++? jogs.foo->bar*2 : jags.foo->bar)++[3])) ...
      Nothing worked, until they invented Perl. Then all the guys who coded like the above
      example switched from C to Perl.

      Success!

    2. Re:Rename it, it isn't Perl anymore by m_ilya · · Score: 2, Informative
      It is still Perl. It is just better Perl :)

      If in doubt go and read article ...And Now for Something Completely Similar by Damian Conway.

      --

      --
      Ilya Martynov (http://martynov.org/)

    3. Re:Rename it, it isn't Perl anymore by Anonymous Coward · · Score: 0

      Nothing worked, until they invented Perl. Then all the guys who coded like the above
      example switched from C to Perl.


      Heh, nothing could be closer to the truth. I wrote horrible C code and I absolutely hated the strict syntax. I love Perl though since it's free flowing like my radical ideology. Hmph. :-)

    4. Re:Rename it, it isn't Perl anymore by Anonymous Coward · · Score: 0

      Perl has broken backcompatibility with each new version number.

      If we follow your advice, we will have to find a new name for Perl 5 as well; since, as it is not the same language as Perl 4 (references are a big difference, and there were some other non-back-compatible bits scattered here and there), it does not deserve to be called Perl?

    5. Re:Rename it, it isn't Perl anymore by Chester+K · · Score: 2

      Same with Turbo Pascal when Borland heavily changed it they changed the name to Delphi.

      Their compiler is still referred to all over their documentation as Object Pascal. Delphi is the name of the IDE, not the compiler; just as Visual Studio is the name of Microsoft's IDE, but not their compiler.

      --

      NO CARRIER
    6. Re:Rename it, it isn't Perl anymore by JebusIsLord · · Score: 1

      Thats what major version numbers are for: designating versions that break compatibility with previous versions. Find me a program that didn't break compatibility with a major rev and I'll show you a program that doesn't follow protocol :)

      --
      Jeremy
    7. Re:Rename it, it isn't Perl anymore by Anonymous Coward · · Score: 0

      I hereby dub thee Earl.

  13. Call me ignorant if you like... by Ignorant+Cocksucker · · Score: 0, Interesting
    But if Perl 6 is not backward compatible with perl 5, it should not really be called perl, should it ? And while we are on the subject, if Perl6 has all these features that python and tcl have had for years, why did Larry think it worth duplicating all that effort ? Why did he not simply e-mail Guido van Rossum and ask if he could contribute ?

    It seems to me like egos are getting in the way of efficiency here. After all, why re-invent the wheel when we already have python ? Why break all those working perl scripts ?

    Ego is the enemy of open source, and here we see why.

    1. Re:Call me ignorant if you like... by ZxCv · · Score: 2

      if Perl 6 is not backward compatible with perl 5

      Uh, Perl 6 IS backwards-compatible with Perl 5--at least to the point that your Perl 5 scripts will compile under Perl 6.

      I think its a ridiculous thing to say that Larry should have just contributed to Python or whatever instead of implementing the features in Perl itself. There are tons of things that can be done better, faster, or easier in Perl than in Python or Ruby, and ditching Perl just because someone else already came up with a particular feature is, IMHO, ludicrous.

      --

      Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
    2. Re:Call me ignorant if you like... by JebusIsLord · · Score: 1

      As i said in an above post, when you change major version numbers you are implying that backwards-compatibility could/will break. That is how versioning works, so with Perl6 we are getting arguably more than we should expect because it IS largely backwards compatible.

      --
      Jeremy
    3. Re:Call me ignorant if you like... by Fjord · · Score: 1

      Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;

      Having a pro-perl argument with that sig kind of defeats the purpose.

      --
      -no broken link
    4. Re:Call me ignorant if you like... by Anonymous Coward · · Score: 0
      There are tons of things that can be done better, faster, or easier in Perl than in Python or Ruby

      Except for parsing, name one.

  14. Re:C++ should be the only programming language by Ignorant+Cocksucker · · Score: 0

    Stolen from adequacy.org. I have passed your details along to legal@adequacy.org.

  15. Are you on the dope, son? by Anonymous Coward · · Score: 1, Funny

    If ya are I'd like some to try.

  16. Yeah..more RegEx fragmentation by Eol1 · · Score: 5, Insightful

    #sarcasm# Yeah!!! Just what we need more RegEx fragmentation #/sarcasm#

    Honestly, RegEx hasn't changed much since awk and when it did, Perl usually led the way. The changes though usually just added features or tweaks, my RegEx still basically looked the same though whether I used VIM, Python, ASP, C++, Perl, .

    Shortly after reading the changes, I was aghast. Sure some of the changes make sense but some are going completely against RegEx as we know them now (getting rid of character classes for one []) . Sure you can use the p5 modifier or do the funky syntax to use [] but the issue is its a radical change.

    This is a bad thing(tm). This is going to force all us RegEx people who currently using 4 or 5 different RegEx tools to not only learn minor differences based on each app, but we will be forcec to learn a COMPLETE DIFFERENT subset of RegEx syntax incompatible with anything else.

    Now wait you say, Perl has always led the way and other tools seem to use perl compatable RegEx libraries. Not so with Perl6. Have floated this question out on a couple developer lists (PHP for one) and everybody is saying, Perl 6 RegEx support isn't going to happen. They are all happy with the current state of RegEx's. This is especially go to cause hell with PHP's perl_regex functions. PHP has stated they are not going to support Perl6 RegEx. Real perl_regex compatible then huh.

    Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).

    My 2cents (who is glad at least Larry added the P5 modifier)

    --
    De Oppresso Liber
    1. Re:Yeah..more RegEx fragmentation by Elian · · Score: 1

      Go reread the Apocalypse. Character classes aren't going away at all.

    2. Re:Yeah..more RegEx fragmentation by Anonymous Coward · · Score: 0

      last time i checked, perl 5.6 worked pretty well. no one is making you change.

    3. Re:Yeah..more RegEx fragmentation by Eol1 · · Score: 1

      Clarification:

      Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.

      (well not really, because it soon starts looking completely unlike RegEx... [^a-b] compared to BUT character classes have alway as long as I have know been [] ... some syntax seems essential and such, should be unchanging .+*()[] and later {}? ... This modifiers seem to be the core basic syntax of all regex engines. What next, to much a single character we replace . with (not real code), or how about * with ... my point it [] is basic syntax, it doesnt' need changing.

      Now here is my fun Perl6 question.

      Before I could do [^[:alpha:][:num:].*] .... Perl 6 is what?

      isn't correct since that is not ONE character class.

      > maybe? (though it also doesnt' look right) ... this seems to me to look like [^[:alpha:]^[:num:]^.*] which is completely wrong (and doens't work)

      --
      De Oppresso Liber
    4. Re:Yeah..more RegEx fragmentation by Anonymous Coward · · Score: 4, Insightful

      Perl 6 "reg"exs are not regular anymore (neither were Perl 5's of course...).
      Perl 6 is now more of a concise parser builder. As Jaime Zawinski has pointed out,
      regexes are not enough for real parsing, though people used Perl ones for ad-hoc parsing all the time.
      The sweeping syntax changes are an indicator of the Perl folk mutating Perl to be better at what people actually use if for - by the looks of things, they'll even stop calling them
      regexes soon, preferirng the term "rule"

    5. Re:Yeah..more RegEx fragmentation by Elian · · Score: 1

      Clarification:
      Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.
      Erm.... you did. The last line of that posting was:
      Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).
      Still, they're not going away as they're useful. That you don't like the syntax change is a separate issue entirely.

      Character classes have changed to <[]> which isn't that big a deal. bare [] are used for non-capturing grouping. It's a reasonable choice--most people use non-capturing groups more than character classes.

    6. Re:Yeah..more RegEx fragmentation by Anonymous Coward · · Score: 0
      As Jaime Zawinski has pointed out, regexes are not enough for real parsing, though people used Perl ones for ad-hoc parsing all the time.
      The sweeping syntax changes are an indicator of the Perl folk mutating Perl to be better at what people actually use if for - by the looks of things, they'll even stop calling them regexes soon, preferirng the term "rule

      Well the problem is that general purpose parsing in itself is a difficult task (check all the grammar/compiler tools). This sounds like a second-system effect: Perl6 is giving up the simple frequent parsing syntax it has, in order to allow people to make more generic complex parsing. The problem is that most people won't have the time to properly code the complex parsing, so those "new" features will be mostly unused. What usually happens in complex parsing, is that people code mostly whatever is enough to parse the few data files they have, but don't test all cases... and then when in production, misparsing occurs often.

      Just because it's sounds like a popular good idea doesn't mean it is in the end. Complexity kills the cat in computing.

    7. Re:Yeah..more RegEx fragmentation by Anonymous Coward · · Score: 0

      A bit, perhaps, but if anything it looks like they're making writing proper parsers simultaneously very,very easy and more advanced than other languages- grammar FormalLetter is Letter { ... } - for once, languages like Common Lisp and Python probably stand to learn something from Perl...

    8. Re:Yeah..more RegEx fragmentation by Anonymous Coward · · Score: 0

      To me, the regexes are the best part of the new perl changes (I like the regexp changes more than any others, except maybe the "." operator).

  17. Code-names by Renraku · · Score: 1, Funny

    I guess the Christians are going to be waving banners over the naming of this one. Are they going to sue for false advertising when they realize this isn't the Apocalypse the Bible spoke of?

    --
    Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
    1. Re:Code-names by kmellis · · Score: 2
      "I guess the Christians are going to be waving banners over the naming of this one. Are they going to sue for false advertising when they realize this isn't the Apocalypse the Bible spoke of?"
      Wall is a very devout Christian. Visit his website.
    2. Re:Code-names by Anonymous Coward · · Score: 0
      From :
      apocalypse
      n.
      1.
      a. Apocalypse Abbr. Apoc. Bible. The Book of Revelation. b. Any of a number of anonymous Jewish or Christian texts from around the second century B.C. to the second century A.D. containing prophetic or symbolic visions, especially of the imminent destruction of the world and the salvation of the righteous.

      2. Great or total devastation; doom: the apocalypse of nuclear war.

      3. A prophetic disclosure; a revelation.
      This is not a code-name, it is a simple discription of what Wall's apocalypse documents are. See #3 above.
    3. Re:Code-names by Anonymous Coward · · Score: 0

      The word "Apocalypse" comes from Greek meaning "unveiling". Since the dictionary includes "any revelation or prophetic disclosure" under the definition, Christians have little reason to complain.

      *THIS* christian has no problem on this one.

      --- WARNING: opinionated views follow ---

      Whilst on the topic of the Apocalypse, lets through in an interesting snippet:

      Rev 1:1 The Revelation of Jesus Christ, which God gave unto him, to shew unto his servants things which must shortly come to pass;

      Two points:

      1. The "Revelation" was made to Jesus, not just to the world. Evidence is found in Mar 13:32:

      "But of that day and that hour knoweth no man,
      "no, not the angels which are in heaven,
      "neither the Son, but the Father.

      2. "shortly come to pass" is a poor translation, it would be better to say "come to pass rapidly" [in a short period of time].

      Particularly point #1 is interesting, because few christian know that. Go on, ASK THEM "Who is the book of revelation to?".

      And for those who want to flame me, read "God does not believe in atheists" by Ray Comfort *FIRST*. Goodnight

    4. Re:Code-names by kmellis · · Score: 2
      The word "Apocalypse" comes from Greek meaning "unveiling".
      Yes, but not quite exactly that. [1]

      Apocalypse is the English transliteration of hapokalu[psi]is [3] . hApo [3] is a very common preposition meaning something like away from or off; and kalu[psi]is [3] is formed from the root, kaluptw [6] [3] , meaning cover, or veil. So, "unveiling" is acceptable. The only problem is that "unveil" is a term not used very generically in English, it has strong literal connotations. That makes it good for poetic imagery; but the original Koine Greek was probably not intended to specifically evoke that particular image.

      Herodotus used hapokaluptw as uncover; Plato as disclose or reveal; and Plutarch as reveal one's whole mind, which I think is closer to what we're looking for here.

      As to your two points....

      1. The "Revelation" was made to Jesus, not just to the world. Evidence is found in Mar 13:32:
      The first is a bit strange. It's trivially true, as Revelations says as much in the first verse. As to Mark 13:32, it only indicates that Christ was unaware of the exact date, not the events. Indeed, Christ seems to be aware of some of the events in Mark 13:32. Also, of course, it's contestable that what Christ is describing in Mark 13 is the same thing as what is being described in Revelations. At any rate, yes, the revelation is to Christ, who then passes it along to John; and so in that sense it's quite correct to say that the revelation is to John. Your insistence that the revelations is "really" to Christ is either niggling or important. If it's important, then it's only important in your contestable interpretation of Revelations and the NT as a whole.
      2. "shortly come to pass" is a poor translation, it would be better to say "come to pass rapidly" [in a short period of time].
      Similarly, your second point is also quite dubious, as hev taxei [3] is in most cases in the NT unambiguously translated as "soon" rather than "fast". Here are all the incidents of hev taxei in the New Testament. It's also quite a stretch to claim that the writer of this book is keen on specifically mentioning that the events described take place quickly right there in the first sentence. It's far more sensible to interpret this as "revelation of events to come soon"; and, furthermore, the narrative that follows describes a sequence of events that are not particularly brief. In other words, pushing the "rapidly" translation is a function of an interpretation which attempts to reconcile this with the historical fact that these events did not seem to happen "soon". Which brings me to another point.

      As someone who studied Homeric and Attic Greek before Koine Greek [5] , I have a greater familiarity with Greek than the average layperson or non-academic who has studied the NT in Greek as a part of their bible studies. My sister, for example, is an evangelical minister and missionary; and although her understanding of Greek has improved over time, it is still enormously tainted by doctrinal teachings of Koine Greek biased towards a particular interpretation of the NT. As a result, I am very skeptical of many fundamentalist's "translations" of the NT.

      Finally, I am not at all offended by your post or the fact that you're Christian - as I noted, Larry Wall is a devout Christian and your post is marginally on-topic. But please don't assume that the sets of people that are offended by Christians and atheists are mutually exhaustive. They are not. I am an atheist. I also know a great deal more about Christianity than most Christians I've met. Stereotypes are not helpful.

      [1] Here is the beginning of Revelations in Greek.

      [2] There used to be a second footnote. Now it's gone. It involved how to display the Greek characters I originally tried to use that I eventually discovered that /.'s preview would accept, but that the submit would not. Sigh. (Addendum: it was a different problem.)

      [3] These are Latin character transliteration. We don't have a psi. Upsilon typically changes to "y" in English rather than "u" because the vowel "y" is actually closer to the presumed pronunciation. Kappa often becomes "c". Nu ["v" in my transliterations] becomes the English "n". The "w" is an omega, a long "o".)

      [4] Wish I could force Unicode in this post, somehow. Ironic since one of the biggest justifications for Wall's mods to regex is that 8-bit character classes are now archaic.

      [5] Koine Greek is much simpler than Homeric or Attic Greek. The New Testament was actually written in Koine Greek because it was the common language of the region. The original words, however, were probably mostly spoken in Hebrew and Aramaic. I should make it clear that I studied Greek more than ten years ago and sadly now all of my facility with it has completely evaporated. This post was constructed with frequent consultations with my Liddell & Scott. YMMV. It's also worth noting that Wall is a trained linguist as well as a studious Christian, so he means exactly what he's saying when he uses the word apocalypse.

      [6] Thus, Homer's "Calypso", the nymph who hid.

  18. Re:Perl Sucks by sputti · · Score: 1

    php may be better for web based solutions, but perl can be used for everything you can think of, for example GUI apps. and as usual its a matter of taste. use what you like to use. perl rocks! :)

  19. makes me glad I'm cutting back on Perl by g4dget · · Score: 5, Insightful

    I used to write a lot of Perl scripts and libraries. But I've been cutting back and using other scripting languages instead. Perl6 looks like it would not be a pleasant transition from Perl5; I don't want to have to learn a new, idiosyncratic language every major release. If some of the features in Perl6 turn out to be useful (like the new regex syntax), they will make it as libraries into other languages.

  20. Re:How is the revenue situation... by Anonymous Coward · · Score: 0

    Not at all! Thanks to the money my open source solutions provider is bringing in, I've almost got enough saved up for my very own can of gravy.

    Where's your can of gravy, Bill? LOL That's what I thought you Micro$oft loser! Open source rules, OK!

  21. Re:C++ should be the only programming language by Anonymous Coward · · Score: 1, Funny

    you passed his details? so is adequacy going to sue all ACs hoping they get the right one?

  22. I prefer command-line PHP to Perl these days by Anonymous Coward · · Score: 1, Flamebait

    I used to be a big fan of Perl, but I've found that I can typically code any particular application much more quickly using PHP compiled for command-line operation.

    Is it just me, or have other's found this? Also, the performance of command-line PHP is quite acceptable.

  23. No, it is not a matter of taste what you use. by Anonymous Coward · · Score: 0

    Only idiots believe that the design of programming languages and other tools, and the resulting choices among these tools, are matters of taste.
    Taste is a deciding factor only when everything else is equal, which it almost never is. The intelligent look at the inherent technical merits of a tool, and of course other considerations, such as quality and availability of implementations targetting a given set of platforms.

    Perl is, technically, a crap of a language, and everyone knows it. This is not a statement of taste, like someone ``dissing'' your favorite band.

  24. more RegEx fragmentation (corrected with Extrans) by Eol1 · · Score: 1

    Clarification:

    Never said they are going away. I said you now have to do some completely odd funky syntax to do character classes as we know them.

    <[a-z_]> <--sure its only the addition of <> (well not really, because it soon starts looking completely unlike RegEx... [^a-b] compared to <-[a-b]> BUT character classes have alway as long as I have know been [] ... some syntax seems essential and such, should be unchanging .+*()[] and later {}? ... This modifiers seem to be the core basic syntax of all regex engines. What next, to much a single character we replace . with <!.!> (not real code), or how about * with <%many_not_zero%> ... my point it [] is basic syntax, it doesnt' need changing.

    Now here is my fun Perl6 question.

    Before I could do [^[:alpha:][:num:].*] .... Perl 6 is what?

    <-alpha><-num><-[.*]> isn't correct since that is not ONE character class.

    <<-alpha><-num><-[.*]>> maybe? (though it also doesnt' look right) ... this seems to me to look like [^[:alpha:]^[:num:]^.*] which is completely wrong (and doens't work)

    --
    De Oppresso Liber
  25. Perl Rocks by Tsugumi · · Score: 4, Interesting
    There seem to be a lot of anti-perl flames, so until someone more intelligent, charismatic and pretty deigns to post, I may as well try to defend it...

    First - the myths, untruths etc that have sprung up so far.

    Perl6 is not backwards-compatible with Perl5 - uhm, yes it is. All your perl5 scripts will compile.

    Why not contribute to phython or [insert other language here] well, python will compile through Parrot too, so who cares? If you like Python, write in Python. I prefer $%&? syntax to whitespace-as-syntax, but each to their own, but that is the joy of Parrot. Think .Net CLR without the so-far unfounded feeling that M$ are doing something underhand and nasty that you can't put your finger on. Before someone replies with "Why not just use the CLR instead of Parrot"? bear in mind this has been done to death already. It's in the FAQ, read first, flame later.

    But why Perl? Okay, so it can be write-only. But this is only because of the flexibility, There Is More Than One Way To Do It. This includes obfuscated code, and plain unreadable alien transmissions. However - if you're writing code only you will ever see, then use the short-cuts. If you are writing code that needs to be maintained, then YOU the developer have the responsibility to ensure it is readable.

    Heck, you could always use english; - but this is perl, you can also code in Latin, or, uhm, Klingon.

    Perl is simply the most flexible language out there IMHO. If you're a sysadmin, you will have the Camel and the cookbook on your desk. Our entire environment is held together with Perl. Half the Internet is running on Perl. A dead language? Sheesh, Perl is dead, long live Perl.

    If there is anything that does worry me about perl6, it is that it is becomiung too powerful, and too encompassing - it is important that the balance is maintained whereby it remains the Swiss Army Knife of languages, that it remains as easy for the casual Perl programmer to keep getting their job done with simple scripts as it is to create large projects.

    1. Re:Perl Rocks by kubrick · · Score: 2
      Heck, you could always use english;

      from the perlvar POD:
      BUGS

      Due to an unfortunate accident of Perl's implementation, "use English" imposes a considerable performance penalty on all regular expression matches in a program, regardless of whether they occur in the scope of "use English". For that reason, saying "use English" in libraries is strongly discouraged. See the Devel::SawAmpersand module documentation from CPAN (http://www.perl.com/CPAN/modules/by-module/Devel/ ) for more information.
      So that might be a good idea for Perl 6, but not for Perl 5.
      --
      deus does not exist but if he does
    2. Re:Perl Rocks by Koschei · · Score: 2, Interesting
      I'm not sure when it was introduced (I suspect it's new to 5.8), but the English module lets you do this these days:
      use English qw( -no_match_vars );
      Which will import everything, except the saw-ampersand and the other problematic variables ($PREMATCH, $MATCH, $POSTMATCH. So you can have the English, and not at the expense of speed.

      --
      -- koschei
    3. Re:Perl Rocks by kubrick · · Score: 2

      Ah, great :) Sounds like the ideal solution. (I tend to keep my Perl to 5.004 level or below (i.e. 5.4 in the new naming scheme) as it may have to run on machines where I can't dictate that they have the latest version, so I hadn't seen this yet. And I only got halfway through the perldelta for the latest version before something more important came up. :)

      The other answer, even if you can't "use English;", is to comment your code properly, especially complex regexes. Of course no-one should need to be reminded of this, the same way no-one should need to be reminded to keep backups... right? :)

      --
      deus does not exist but if he does
    4. Re:Perl Rocks by Anonymous Coward · · Score: 0
      Why not contribute to phython or [insert other language here] well, python will compile through Parrot too, so who cares?

      It's unclear if Parrot will ever do this. Most of the bytecodes have different meanings ; the more efficient solution would be just to link Python and Perl code toghether and have inter-language calls. Some Perl and Python datastructures are not compatible in addition. There is no such thing as "universal bytecodes", except for machine code (which cannot be avoided).

    5. Re:Perl Rocks by Koschei · · Score: 1
      especially complex regexes
      Which makes it all the better that /x is the default in Perl 6. Anything that makes complex regexs more legible and more likely to be commented is good in my book.

      (Incidentally, Mastering Regular Expressions, 2nd edition, is out sometime this month.)
      --
      -- koschei
  26. Comic book guy dislikes the new regex format... by Cheetah86 · · Score: 1

    Worst...update...ever...

  27. Careful, Parrot != CLR by Ars-Fartsica · · Score: 4, Interesting
    PArrot will juice performance boosts at the sacrifice of built-in safety. This is by design. Dan Sugalski claimed as much in a Perl Review article - to paraphrase - "Parrot will execute the bytes sent to it by the native language compiler. IF the compiler writes improper Parrot, your app will crash.".

    He also goes on to note that the CLR could be a pluggable backend for Parrot to export to.

    1. Re:Careful, Parrot != CLR by Elian · · Score: 1
      Parrot will juice performance boosts at the sacrifice of built-in safety.
      You misunderstood my comments, apparently. Perl, python, and ruby all, right now, have unsafe interpreters. This isn't anything new--you feed in bad optrees or bytecode to most interpreters and they'll do horrible things. Checking for safety at this level, when running plain code for which you don't choose to be paranoid, is a drain on performance with no corresponding benefit.

      If you do choose to not trust your bytecode, you can run it in a safe interpreter, which will check to make sure everything is proper. You'll pay the corresponding performance penalty, but that's fine as you've asked for it at that point.

      Most of the code that most people execute is trusted code, and for that there's just no win in double-checking it at runtime. And for those rare (relatively) cases where you do care, you can be paranoid and run safely.

      (The CLR's certainly not safe either. Use some unchecked code, of which there's likely to be a lot, and you're just as unsafe)

    2. Re:Careful, Parrot != CLR by Anonymous Coward · · Score: 0
      The CLR's certainly not safe either. Use some unchecked code, of which there's likely to be a lot, and you're just as unsafe

      This needs to be qualified. Microsoft has gone to extreme lengths to discourage unsafe code segments. For its normally designed purpose, the CLR can be considered "safe"....in this sense it IS different than Parrot - Parrot has no safe operating mode.

    3. Re:Careful, Parrot != CLR by This+Is+Ridiculous · · Score: 1
      Parrot has no safe operating mode.

      Not yet, at least. Remember, Parrot is still under development. We'll implement the safe interpreter stuff eventually, but it's not a priority right now. We still have more fundamental issues to handle, like subroutines and symbol tables. :^)

      --
      Hey, you try to find an open nick these days!
  28. All languages are NOT equally good by Jay+Carlson · · Score: 2
    Perl rocks. PHP rocks. C rocks. Pascal rocks. Bash rocks. One just isn't any better than any other, if the one you are using gets you the desired results (speed, speed of coding, ease of use, correct answers to problems, etc.).

    What a wussy response. So what you're saying is that those languages are all good, except when they're not.

    I love Intercal because it destroys all the "they're all very nice" language relativity arguments. Here's a language that's specifically designed to be as annoying as possible. I dare you to advocate Intercal in the same way you did above.

    Both the PHP language and its implementation have significant problems. Regular users of PHP already have their own list of language design annoyances ("it has to be a global??") and you can see some of the implementation problems here. You will note PHP's implementation getting beaten by Tcl, gawk, xemacs, and njs. :-(

    PHP would have been better off if the implementors had used an existing language like Lua (80k of x86 code for standalone interpreter+core libraries!) and focused on the embedding features unique to the application area.

    1. Re:All languages are NOT equally good by Anonymous Coward · · Score: 0

      Perhaps if you read Doug's testing methodology you'll notice he doesn't configure PHP for performance. His reason being that most people won't.

      Well he might be right (I never underestimate stupidity anymore), but that doesn't reflect PHP's performance when configured properly.

    2. Re:All languages are NOT equally good by Jay+Carlson · · Score: 2
      (In case you're wondering where that PHP link went above, bounce through this link to defeat Doug's silly slashdot Referrer detection.)

      Perhaps if you read Doug's testing methodology you'll notice he doesn't configure PHP for performance.

      The suggested performance config changes Doug cites are:

      • --disable-debug. This is the default, so specifying it again doesn't matter.
      • --enable-inline-optimization
        "If you have much memory and are using gcc, you might try this."

      This does work, although you have to read to the end of the ./configure --help options to find it. It speeds up the Shootout tests by around 15%. Unfortunately, 15-20% isn't very much. PHP's ranking relative to other language implementations doesn't change, even with this improvement.

      FWIW, Debian doesn't configure with --enable-inline-optimization.

  29. grammar/regex == class/method??? by Anonymous Coward · · Score: 0

    Well, the grammar/regex isomorphic to class/method _is_ interesting - about the only other language where one could achieve that degree of cleverness and finish before the heat death of the universe is Common Lisp... At least in CL, it'd be readable. Lots of parentheses, but readable...

  30. Pros and cons of the /x regex modifier by amoe · · Score: 1

    I must admit to only just having gained a handle on some of the more esoteric features of Perl 5 regex. But I have a definite opinion on the use of the /x modifier on regex - contrary to (what seems like) popular belief, I find it makes regex harder to read, not easier.

    Having to mentally scroll a line after each token impairs my parsing of the regex as a whole. It seems much easier to me to compare a sample of the input to the regex, and see how it looks. I realise it won't be mandatory to lay regexes out like this in Perl 6, but it worries me that this is seen as good programming practise. Don't even get me started on people who comment after every token...

    Still, there's hope that the introduction of this modifer as the default will work against this mindset, rather than for it. Perhaps with its common usage will come enlightenment amongst the Perl posse. I also notice that Larry doesn't use the monstrously verbose regex form during his Apocalypse. So I'm not really sure whether this is a good or a bad thing - but I'm certain that people in the Perl community need to stop preaching that excessive commenting of regexes makes for maintainable code.

    (This probably should have been posted in response to the original Apocalypse 5 thread. Tough titty. BTW, I thought Slashdot would wait for the Exegesis, and how come this is a few days late. Bah, humbug.)

    --
    You look beautiful! Incidentally, my favourite artist is Picasso.
  31. Re:you're HOMOSEKULLE by Mark+Fenelli · · Score: 0, Offtopic

    LOL

  32. Out of control by Junks+Jerzey · · Score: 2

    Perl has always had ugly points, but regular expressions were always concise and well-known. And now Wall's ramblings about how he wants to change regular expressions are longer than the entire section about them in the camel book. Doesn't this strike anyone else as ridiclous? Perhaps too many special cases and too many borrowed extensions are being thrown into the language. What an ugly mess it is becoming.

    I'm not a big Python fan, but now I'm wondering why I shouldn't just switch to Python now and save myself the grief of having to switch to a completely new Perl-like language later.

    1. Re:Out of control by baka_boy · · Score: 2

      Perl's 'regexes' are, as Larry himself put it, already well outside the realm of what was originally considered a 'regular expression'. I still remember "pure" regexps from CS101: no capturing, no character classes, not even a '+' (1 or more) operator, since it can be emulated with something like 'xx*'. However, Perl 6's new pattern-matching rules look very interesting; it's really a full-blown parsing toolkit, complete with statful match objects, named (potentially recursive) rules, full closures within matches, etc.

      The only thing that concerns me, really, is the scale of what the Apocalypes have proposed. Yes, the Parrot VM is moving nicely along, but the actual implementation of all of Larry's new design decisions seems to be lagging well behind their creation. I have a lot of faith in the core Perl hackers' abilities, but the climb from here to Perl 6 is not going to be an easy one.

      Personally, I've started looking a lot more closely at Parrot and the Apocalypses (Apocrapha?) since I saw the regex article, and am hoping to be able to get up to speed to get involved in the project over the next few months. I recommend that anyone else who shares my interest (and has any background in parsing and compilation, test case management, VM tuning, etc.) do the same.

      (Note: I'm already a fairly dedicated Python user, but as a language geek, have grown pretty seriously tired of some of the limitation of the language, like one-expression lambdas, weird "special" variable names like '__init__' and '__name__', etc. Plus, if you're trying to do code generation, the whitespace-delimited syntax is a bitch.)

    2. Re:Out of control by WNight · · Score: 2

      Python is a nice language, but it's not a quick as Perl. Python enforces a lot of stylistic and linguistic structure that isn't always appropriate outside of a teaching language.

      For instance, a series of 'if' constructs in a row that all do a very simple thing (function call) are sometimes cleanest if they are all on one line ...

      example: if (foo) { bar(); }

      instead of spread across three. It makes the relationship between the condition and the action very clear, and also makes it easier to see more of the overall structure by providing more context for the same ammount of lines.

      Similarly, Perl will loop through an array with an implicit bounds check [foreach $var(@array) { }] which lets you do a common task very easily. Python is much more strict about making you check the array size and loop through, making sure not to test past the end. It's a good teaching function, to let people know what goes on behind the scenes in a high-level language so that they understand it better, but it's just as safe either way. Why make the programmer do it?

      I like C, and even enjoy the odd bit of ASM, but when I need to code a text handling application, quickly, I don't reach for those, I go for Perl. Python seems like a good cross between C and Perl, but I don't think it's a replacement for either.

      And, as for as having to switch to a new perl goes... Larry's realized that there's so much P5 code out there that will never be updated that P6 will be backward compatible. If you don't want to change, don't. Any Turing-complete language is capable of any task, there's nothing P6 does that P5 can't. If it's not worth learning, don't bother.

    3. Re:Out of control by Anonymous Coward · · Score: 0
      For instance, a series of 'if' constructs in a row that all do a very simple thing (function call) are sometimes cleanest if they are all on one line ...
      example: if (foo) { bar(); }

      Which in Python translates exactly into this one liner: "if foo: bar()"
      Notice the lack of spurious ";" "{" "}". People use this all the time, especially for short methods, i.e.:
      class A:
      ..def set(self,value): self.value=value
      ..def get(self): return self.value
      ..def add(self, value): self.value += value

      Similarly, Perl will loop through an array with an implicit bounds check [foreach $var(@array) { }] which lets you do a common task very easily. Python is much more strict about making you check the array size and loop through, making sure not to test past the end.

      I don't know what you are talking about. "foreach $var(@array) { ... }" is written "for var in array: ..." in Python and does exactly the same thing. Plus Python has list comprehensions like "[x+1 for x in array]" which returns a list holdings each element of "array" incremented by 1. Is it C?

    4. Re:Out of control by Anonymous Coward · · Score: 0

      You need to learn Common Lisp. It's like Python, wihtout the arbitrary stupidities and whitespace syntax.
      (N.B. Lisp isan OO-language via CLOS - t just happens to do functional programming too - as a resuly, thousands of compscis are under the misapprehension you can't use lisp for "normal" stuff)

  33. Re:C++ should be the only programming language by Ignorant+Cocksucker · · Score: 1

    No, most likely adequacy will sue slashdot, based on the 'follow the money' principle of legal action.

  34. Perl Bashers by mbrod · · Score: 2, Insightful

    Seems to be a lot of Perl bashers. Surprising.

    Where I work Perl helps us with System Integration, fast scripting, production reports, database connectivity where speed of writing the application and flexibility in changing that application quickly are important, web sites for change control systems, bug reporting systems, etc. and much much more.

    If speed of creating the application and flexibility of changing that application need to be blazingling fast Perl is the choice. If Perl is not going to provide the application speed you need then use C or C++. That is why Perl is written in C :-).

    If the Perl code you are reading isn't readible it probably had to be written too fast for the programmer to accout for that or else the programmer simply didn't care. Perl is the most flexible language ever and it can be the most readible if some care is taken. Especially in a smaller size applications.

    1. Re:Perl Bashers by Anonymous Coward · · Score: 0
      Where I work Perl helps us with System Integration, fast scripting, production reports, database connectivity where speed of writing the application and flexibility in changing that application quickly are important, web sites for change control systems, bug reporting systems, etc. and much much more.

      You miss the point. The point is that there are several (even dozen of languages if you include some "academic" ones) that can do the same thing ; often in a cleaner way. Heck, Smalltalk could even do the same back in 1980.

  35. just wait by raistlinne · · Score: 2

    If the perl 6 regex's have real benefits over the old style of regex's, then everyone else will switch over. Sure it will take a while, but then what improvements in life ever happened instantly?

    --
    They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
  36. Top 10 Reason to Adopt Visual J# .NET by Anonymous Coward · · Score: 0

    While there are countless reasons to adopt Microsoft Visual J#(TM) .NET, these 10 reasons top the list.

    Number 1

    Familiar Language Syntax
    If you are already familiar with the syntax of the Java language, why learn anything else? Microsoft Visual J# .NET can be used by Java-language developers immediately with almost no learning curve.

    Number 2

    Multi-Language Aware
    Integrate your applications directly with components, services, and classes written in other languages.

    Number 3

    Object-based Type System
    Visual J# .NET provides developers with a modern and intuitive object-based type system that eliminates the need for complex and error-inducing pointer and template features found in other languages.

    Number 4

    Access to the Microsoft .NET Framework
    Visual J# .NET provides developers with access to the Microsoft .NET Framework, a robust, thread-safe library of collection classes, networking functionality, data access classes, and more.

    Number 5

    Interactive XML Web Services
    Visual J# .NET allows developers to deploy and consume rich, interactive XML Web services that reduce development time by enabling software aggregation from any platform.

    Number 6

    Java Investment Protection
    Visual J# .NET provides a low-cost route to migrate your Java programs and programmers to .NET-connected technologies and applications.

    Number 7

    Visual Studio .NET IDE
    Visual J# .NET provides developers with the award-winning Visual Studio .NET integrated development environment (IDE), which includes support for Task Lists, Property Editors, Microsoft IntelliSense®, Forms Designers, and much more.

    Number 8

    Powerful Windows-based Applications
    The new Microsoft Windows® Forms Designer enables developers to get their desktop applications to market in less time. New features include control anchoring and docking to eliminate the need for complex resize code, the in-place menu editor to deliver WYSIWYG menu creation, and the tab order editor to provide rapid application development (RAD) organization of controls.

    Number 9

    Easy Web-based Application Development
    Using new Web Forms, you can easily build true thin-client Web-based applications that intelligently render on any browser and on any platform. Web Forms deliver a RAD programming experience for the creation of great Web-based applications. The new HTML Designer delivers IntelliSense statement completion for HTML tags and the separation of user interface (UI) and code enable more efficient team-based development.

    Number 10

    Simple Reliable Deployment
    "No-touch" deployment features make application installation as easy as copying software onto the disk drives of client machines or to the servers in your data center. New applications won't interfere with existing applications. Rich Windows interfaces, once an operational problem, can now be easily installed and serviced using the new Windows Forms technology.

  37. Re:Perl Sucks by JebusIsLord · · Score: 1

    i would just have them spend an afternoon transitioning their skills to writing good PHP, since they are so similar.

    --
    Jeremy
  38. I' also getting tired of reading about Perl6 by porky_pig_jr · · Score: 2, Informative

    and I'm about to drop it altogether - both 5 and 6. Franky, coding Perl can be fun, but maintaining and debugging the code written by somebody else - isn't. THis is the implication of having the language with 'the same thing can be done in a 1000 different ways' and the language whose design mostly depends on Larry's whims - and remember that Larry is a linguist by education, and apparently he has somewhat limited understanding of all the issues concerning the 'production quality' language. So - I'll be taking a closer look to apparently minimalistic and restricted Python. Cheers.

  39. Re:C++ should be the only programming language by Anonymous Coward · · Score: 0

    If they're following the money, Slashdot will be the last place they go!

  40. Perl is beautiful by Ender+Ryan · · Score: 4, Insightful
    I simply don't understand what is up with all the Perl bashing going on here. I think it is mostly a sign of ignorance, because most of the negative comments about Perl are simply false.

    Many people say Perl is too big, has too many features, is too complicated, etc. This is simply false. Perl has tons of features, but, more than any other language I have ever used, you can use as little or as much of it as you want. You can pick up a Perl book and start writing Perl code in 15 minutes.

    Perl is ugly, hard to read, "write only", etc. This is complete horseshit, probably stemming from lack of experience with using Perl. Perl is very easy to write and read. Where I work, I have a co-worker who is not a programer. He learned Pascal years ago, but did not do any real coding until recently. Despite this, he can fairly easily read and modify my code. Yet, he can't read or modify my C/C++ code at all, and it's usually very readable, very clean, simple and concise.

    PHP/Python is better. A lot of people like to compare Perl to PHP and Python. Neither are "better", there really is no such thing. PHP is for web developers, and Perl can do everything PHP can do in nearly the exact same ways. Take a look at CPAN, there are so many Perl modules for use with Apache and web development in general that Perl is far, far more capable of a web programming language than PHP(IMO anyway). And Python, I've seen some absolutely fantastic stuff written in Python, but I hate Python, because it gives me a frickin headache. I cannot read/write Python, the lack of braces, indentation as syntax is just horrible on my eyes. Perhaps I'm slightly dyslexic or something, but when I'm looking at a page of Python code it all starts to swim and I cannot tell where each code block begins and ends.

    Now don't get me wrong, Perl isn't perfect. There are some things that bother me about Perl 5. # for comments, not bad but I really wish I could use C and C++ style comments in my Perl code. A bunch of #'s just look rather ugly. Threads, Perl 6 will have decent thread support from what I understand, I wish Perl 5 did, luckily for me everything I use Perl for I can fairly easily use multiple proceses instead, still would be nice though.

    I for one am looking forward to Perl 6. There will definately be a learning curve, but at least it will run most scripts without modification, will make upgrading much easier.

    Oh wait... this is /., it's easier to get modded up for bashing something... ok... Microsoft sucks! ;-)

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
    1. Re:Perl is beautiful by MadAhab · · Score: 2
      Perl is ugly, hard to read, "write only", etc. This is complete horseshit, probably stemming from lack of experience with using Perl. Perl is very easy to write and read.

      gotta agree with you there. most people objecting to perl are straight programmers looking at code written by BOFHs who couldn't care less if you can read their code. But I've seen the code those programmers are writing in a variety of languages and it's no fucking better. And often it's just worse and less concise because of the straitjackets the language puts you in. One would have thought, for instance, that Java would have done better than to repeat all the tired design of the umpteenth homegrown C++ string class, but no such luck; no one else has anything to be proud of (object-oriented shouln't be a synonym for verb-deficient).

      I could go on and on but I expect to find Perl in 2023 (Perl 6.20936, btw), I have doubts about any other current language but C. Perl allows for elegance that other languages simply can't (e.g. "next if $foo;" at the beginning of a loop): bad programmers suck no matter what their language.

      I also have to agree that a block comment, say /# blah blah #/ is overdue.

      --
      Expanding a vast wasteland since 1996.
    2. Re:Perl is beautiful by dvdeug · · Score: 2

      I could go on and on but I expect to find Perl in 2023 [...], I have doubts about any other current language but C

      And what do you think is going to happen to Fortran? Millions of lines of code don't go away over night, and engineers and physicists who only know Fortran aren't going to bother learning anything else.

    3. Re:Perl is beautiful by Anonymous Coward · · Score: 0
      Perl is a stinking load of shit. And so are you.

      If you think the only languages in 2023 will be Perl and C, you're a complete idiot.

    4. Re:Perl is beautiful by This+Is+Ridiculous · · Score: 1

      He said the only currently available languages, not the only languages. Undoubtedly there will be other languages invented between now and then.

      --
      Hey, you try to find an open nick these days!
    5. Re:Perl is beautiful by This+Is+Ridiculous · · Score: 1

      He probably means languages with people actively learning and writing all-new stuff in them. FORTRAN probably won't go away, but I expect that it will continue to stagnate as the people who only know it retire.

      --
      Hey, you try to find an open nick these days!
    6. Re:Perl is beautiful by dvdeug · · Score: 2

      I expect that it [Fortran] will continue to stagnate as the people who only know it retire.

      My cousin, who got his PhD a few years back in Chemical Engineering, wrote his thesis in Fortran, I assume because he was most familiar with the language. Intro to Engineering Programming at OSU teaches Fortran 90. There are no other Engineering Programming classes at OSU. So there's both new writing in Fortran, and a body of new users.

    7. Re:Perl is beautiful by mrdlinux · · Score: 1

      It's not elegance unless Perl allows you to add constructs such as "next if $foo;" to the language yourself, via the language.

      Lisp does. Lisp has been around for 40 years. And I guarantee you that a Lisp will still be here 40 years from now. Languages like Perl, Python, and Ruby continually try to measure up to it, XML tries to imitate its data structure, and most people could learn a few lessons from it. Dynamic semantics and structured data/code aren't going to vanish on a whim, unlike certain other languages tied to a particular creator's looniness (not naming names, but you know who I mean).

      --
      Those who do not know the past are doomed to reimplement it, poorly.
  41. You can switch but it will not help by m_ilya · · Score: 1
    As many languages have borrowed Perl regular expressions thay will borrow new Perl regexps at some point. It just the matter of time. You may try to switch from Perl to Python but at some point Python will have new Perl regular expressions for sure as it has now PRCE. New regexps are just too good!

    I don't get why people whine about obvious improvment in regexp engine. First of all: there always p5 modifier to turn on compatibility mode. Moreover do not afraid of complexity of new regexps. You don't have to use all features! Simple things are still easy to do (and even easier). The best thing about new regexps is that they make previously impossible possible.

    --

    --
    Ilya Martynov (http://martynov.org/)

    1. Re:You can switch but it will not help by Anonymous Coward · · Score: 0
      As many languages have borrowed Perl regular expressions thay will borrow new Perl regexps at some point. It just the matter of time. You may try to switch from Perl to Python but at some point Python will have new Perl regular expressions for sure as it has now PRCE. New regexps are just too good!

      But at least it will be in a module (i.e. "import Perl6.re as re" instead of "import re").

  42. Perl: Experienced programmers only, please. by Anonymous Coward · · Score: 0

    All others stay away...

  43. Re:Perl Sucks by Tony+Hoyle · · Score: 2

    Perl for GUI apps? Save us!

    If you must script a GUI use somthing that's been designed for it like TCL (another language I hate but it has its uses).

  44. Re:more RegEx fragmentation (corrected with Extran by ajs · · Score: 2
    As always, TMTOWTDI
    <-<alpha><digit><[.*]>>
    Or were you looking for something more complicated like
    (\w)<($1!~/_/)>
    Of course, I've never treid running these through Larry's brain (the only currently functioning Perl 6 interpreter :-)
  45. Bologna by Anonymous Coward · · Score: 0

    What a load of crap. If it was to Jesus, why is some of it addressed to the seven churches?

    You should reread the whole book again.

  46. I don't use perl but... nice by Anonymous Coward · · Score: 0

    nice to see something so influential having a go at fixing regular expressions.

  47. Re:Both Perl and PHP Suck by axxackall · · Score: 1
    Both Perl and PHP are not really OOP lanuages. Both GUI and web tasks are UI at the end and therefore require OOP. Use Perl when you need write-only regexps readable only by maniacs. Use PHP for small pages, where you have to use programmers with VERY limited IQ. For UI - use either Java or Python or CLOS/Lisp. Or even C++, which is extremely unportable and thus I don't consider it as a choice.

    If you hate Java as unscalable proprietary lang then use either Python or CLOS/Lisp.

    For those who argue about security of object attribute access - that has nothing to do with OOP and with security either. It's just a marketing blob and nothing useful. Hence, Python and CLOS/Lisp are still the choice.

    Finally, CLOS/Lisp has not enough portable GUI libraries. Scheme is not OOP lang either. Thus we've left alone with Python. Portable open-source scalable stable-as-old and modern-as improved good OOP (and some FP!) lang Pyhton.

    --

    Less is more !
  48. Perl 5, the new COBOL, Perl 6, the new ADA by ajm · · Score: 2

    Just thought I'd rerun my previous comment producing post. Despite all of the ranting that generated I think I'll stick with my contention that Perl is COBOL for the 21st Century. In this respect perhaps perl 6 is going to be ADA, a wonderful language with lots of nice features that NOBODY USES. Perhaps abandon the backwards compatibility and design a new language with all of the features that modern languages should have. Surely that's less effort, and time better spent, that trying to maintain backwards compat. with perl 5. I mean, what can't you do with perl 5 now? Will perl 6 attract a single non perl user that perl 5 wouldn't have attracted? I'm sure perl 6 will be a great language, and a great monument to something, rather like
    "My name is Ozymandias, king of kings:
    Look on my works, ye Mighty, and despair!"
    Nothing beside remains. Round the decay
    Of that colossal wreck, boundless and bare
    The lone and level sands stretch far away.

    1. Re:Perl 5, the new COBOL, Perl 6, the new ADA by mlinksva · · Score: 2
      Sorry, Java will be the COBOL of the first half of this century. Ubiquitous in "business" applications, considered boring, retrograde, old hat, etc.

      You may be completely satisfied with Perl 5, though many others aren't. Perl 6 may keep some of them from migrating to Ruby or Python, as well as attracting new programmers. I did my first "web" programming in Perl (4 actually), though I'd never suggest Perl to a newbie now.

  49. Dying language...... by d2002xx · · Score: 0

    "new regex syntax" !!? So they want to use regex to attract more programmers?

    Would somebody tell me where I can find an application server written in perl? Or IDE? I'm wondering what's the perl good for? CGI!?? :)

    1. Re:Dying language...... by Anonymous Coward · · Score: 0
      Would somebody tell me where I can find an application server written in perl? Or IDE? I'm wondering what's the perl good for? CGI!?? :)

      application server: here and here

      IDE: here, here, here

      Oops, you really mean, written in Perl? Sorry, apparently all those tried, failed.

  50. To all the whiners by deblau · · Score: 2
    Don't complain. It's Larry's language. He can do whatever the hell he wants to do, and still call it perl. If he wants to add support for punching monkeys to it, it's still perl. If you don't like it, make up your own language. Same goes for Linus, if he wants to make the Linux kernel panic every time the clock rolls over to midnight for full BSOD-compatibility, that's his right.

    The reason that perl is successful is because it's useful. Only time will tell if people think perl6 is useful. If they do, they'll use it; if not, they'll stick to perl5.

    Ob regex troll: I think the new regex handling kicks major ass. The new regexes have been promoted to true first-class variables, cleaning up a lot of messy syntactical issues. In addition, everyone who says it's not backwards compatible, well you're right. That's because the current regex libraries SUCK in comparison to the features offered by perl6. That's right, they SUCK, and it would be impossible to be backwards compatible with all the new (useful) features that have been added. If you don't believe the new syntax useful, try backtracking a 100,000 character repetitive string only to discover that the 15th matched number is too large or too small. Now think <{ ... }>.

    --
    This post expresses my opinion, not that of my employer. And yes, IAAL.
  51. I agree with this post by FrostedChaos · · Score: 1

    I agree with this post!

    --
    "Any connection between your reality and mine is purely coincidental." -Slashdot
  52. Actually, I like it! by Paranoid · · Score: 2

    I've read every Apocalypse, Exegesis and, err, "Synopsis" (why the namechange?) so far. Almost everything I've read so far has seemed like a good idea. I've personally run into quite a few of the exact issues they're attempting to solve with these changes. Regexps are just as problematic as the rest of it, and I agree with the changes. And since they're ensuring reverse compatibility with every aspect (usually via a flag), even if I didn't like a particular aspect, I wouldn't have to use it.

    Frankly, I'm looking forward to it. Parrot is nice, and if it weren't for the memory management issues from string-scalar registers, I'd be seriously looking into implementing it in hardware, but its still not too impressive without the Perl6 parser. So I'm waiting patiently, but I feel it'll be well worth it.

    The changes may seem like a lot, but far more will actually be staying the same. Perl's already by far the easiest language for me to implement things in (and I've given basically everything a good try), and it seems as if this batch of changes will solve the few remaining rough areas. Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area. Still, it's kinda funny how many apparent perl-haters (old perl and new perl) there are, posting to a forum thats, err, written in Perl =)

    --
    Paranoid
    Bwaahahahahaa.
    1. Re:Actually, I like it! by Anonymous Coward · · Score: 0
      Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area.

      So apparently, you only know Perl, C, Pike and Basic?

    2. Re:Actually, I like it! by Paranoid · · Score: 2

      Not quite. =) I've used those mostly, simply because I've found myself the most comfortable in those for one reason or another. But I've dabbled in lisp (and scheme), python, haskell, smalltalk, ruby, php, pascal, a few assembly languages, and last but not least, befunge.

      --
      Paranoid
      Bwaahahahahaa.
  53. Re:Both Perl and PHP Suck by Anonymous Coward · · Score: 0

    Lisp hasn't enough portable GUI libraries???

    Lisp has: CLIM (great), Gtk (usual crap), CLUE/CLIO, Garnet (great), CLM (Motif...), CommonWindows, etc,etc,etc - in fact, lisp is a playground for new GUI technologies...

  54. Re:C++ should be the only programming language by Ignorant+Cocksucker · · Score: 0

    A disclaimer cannot change the law. Slashdot may like to think they are not responsible for their content, however a court of law might well disagree with them. They have removed stuff in the past (scientology stuff) and they will remove stuff in the future.

  55. Pascal rocks?? by Anonymous Coward · · Score: 0

    Wow... you totally blew your credibility with that one! ;D

  56. Re:Perl Sucks by fwr · · Score: 2

    Umm, TCL was not designed for GUI scripting. John Ousterhout desinged TCL in the spring of 1988 as a generic command language, to replace the command languages for various different tools used mainly for integrated circuit design. It had nothing to do with any sort of GUI whatsoever.

    Tk was spawned out of his frustration with Apple's HyperCard system and his belief that a "shared scripting language" could provide the glue to tie together components that a small group such as a university research team could build up over time. Plus, I personally suspect, his desire to reuse Tcl for more than its original design.

    Pick up "Tcl and the TK Toolkit" by John K. Ousterhout published by Addison-Wesley. The info above is gleaned from page xvii, the first page of the preface...

  57. Re:First Post for the AC's by Anonymous Coward · · Score: 0

    BTW you suck too

  58. Re:Both Perl and PHP Suck by Anonymous Coward · · Score: 0

    and what about ruby