Slashdot Mirror


Apocalypse 2

Larry Wall has written the second article in his "Apocalypse" series about Perl6. If you missed the first article, you might want to read that one first, or see the previous discussion.

52 of 94 comments (clear)

  1. Re:Programs written in Unicode? by megas · · Score: 2

    This is already a valid perl 5.6 program.

    Check 'Programming Perl' 3rd Edition, Chapter 15, where a japanese character is used as a variable (you have to 'use utf8;' though.

  2. Re: hypens by freeBill · · Score: 2

    For the definitive answer on hyphens, see Elements of Style by Strunk and White.

    Hint: They only connect words that are all connected by other hyphens. The main thing is to avoid the problem which occurred when the Chattanooga News merged with the Chattanooga Free Press to become the hyphenated Chattanooga News-Free Press.

    --
    Eternal vigilance only works if you look in every direction.
  3. Re:SImple Question by Jonathan · · Score: 2

    No, Kierkegaard was far too interested in philosophy to worry about ports of yet-to-exist scripting languages to yet to exist hardware. In fact, I don't think he owned any sort of PDA or even knew how to program.

  4. Re:The Perl6 answer could be ... Ruby by Ed+Avis · · Score: 2

    I wouldn't want to use any language that has 'begin' and 'end' instead of { and }. Yuck.

    --
    -- Ed Avis ed@membled.com
  5. Re:Killing sh-ness by elmegil · · Score: 2

    I had pretty much the same reaction. Except not only is $foo\Q[bar] UGLY, it's bloody confusing looking. I've always tried to distance myself from the argument about how much of perl looks like line noise (regexp's anyone?), but this is definitely a step in the WRONG direction for clarity and lack of line noise, despite the apparent planned elimination of $", $[, and their ilk.

    --
    7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
  6. Re:The problem with open source^H^H^H evolving by elmegil · · Score: 2

    I believe apocalypse 1 addressed the point that simple scripts written in perl 5 will be clearly distinguished from perl 6 and treated as perl 5 appropriately. Which means chances are good you'll still be able to use your old coding style just fine. It's unclear as yet how this will handle the elmination/deprecation of things like $", but Larry's done a good job so far of maintaining appropriate backward compatability, so I have no reason to doubt him going forward.

    --
    7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
  7. Is it just me, or... by Teferi · · Score: 2

    ...does the language proposed in this and the previous Apocalypse resemble Ruby very, very strongly?
    Panobjectification with common accessor methods, cleaning up a lot of the syntactit warts, new class syntax...
    I like it, personally. Ruby is a pretty neat language. And I have no complaints about Perl evolving towards being like it...

    --
    -- Veni, vidi, dormivi
  8. Re:Programs written in Unicode? by Chris+Pimlott · · Score: 2

    There is an article by Bjarne Stroustrup about the future of C++ where he goes overboard on this idea.

    I do hope you realize...

    B Stroustrup: Generalizing Overloading for C++2000. Overload, Issue 25. April 1, 1998

    (If that isn't enough, there's another similar soundingarticle from 92:
    B. Stavtrup: Overloading of C++ Whitespace. Journal of Object-Oriented Programming. April 1, 1992.)

  9. Re:*more* contexts? Is Perl's use of context good? by Chris+Pimlott · · Score: 2

    What about the difference in comparing scalars as strings ($a eq 'ham') or numbers ($a == 10)? You could argue numeric context already exists in Perl. This just defines it in a more rigorous way.

  10. Re:better off understanding ancient Mandarin by Nightpaw · · Score: 2

    My guess in the distant future our descendants will see Perl as this cryptic cult of demon worshipers or something.

    Umm, hello; isn't that how most people think of Perl hackers already?

  11. Re:Gee... I guess Perl was too Unambigious by powerlord · · Score: 2

    So then the syntax construction is not identical between refering to the variable within quotes or without quotes. Gee... that makes sense.

    While I don't expect the syntax to be identical I would expect it to be rather similar.

    --
    This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
  12. Re:Gee... I guess Perl was too Unambigious by powerlord · · Score: 2

    I thought they were talking about multi-level abstractions (for instance the case of an array of a hash of a hash), and not just 'simple' indexing.

    In that case I'm not talking about simple indexing and $foo[$bar] but perhaps something like ${${$foo[$bar]}{$foo2}}{$bar2}
    While I'm sure there are probably better ways to write this, and while I wouldn't dream of putting a construct like this into quotes (for lots of reasons). I'm not quite sure I like the idea of the braces disapearing for 'clarity' sake. But then I would be fine with a mandatory "No variables in quotes" so I won't claim consistancy.
    :)

    --
    This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
  13. Re:better off understanding ancient Mandarin by MadAhab · · Score: 2
    In a weird way, it's syntactic promiscuity (it's all good, baby) does resemble learning ancient Mandarin. Chinese is an ideographic writing system that doesn't care how you pronounce it, as long as you agree that character A means Alpha. Even if you speak Cantonese, you have a reasonable chance of understanding ancient Mandarin as well as a modern Taiwanese. In the same manner, I've seen Perl code where I'm not sure what their original coding language is, but thanks to Perl, it's reasonably easy to understand someone whose internal coding language is completely different from mine.

    Perl. Can't live with it, can't live without it.

    All I know is, doing decent OO and well modularized code is hateful in Perl. I pray this will be better in Perl 6. Right now, I use plenty of server side java for web stuff, even though CPAN kicks ass over any services you'll find built into Java and I'd rather cast my lot with Larry than with Scott any day. If Perl were a bit straightforward for compartmentalizing large projects, and if mod_perl made any damn sense, I'd use it, because in my experience, mod_perl is much faster than Java, PHP, ASP, more open, better integrated with OS level functions (try setting permissions on files from Java), etc, etc, etc.

    I love it, even though I hate it and it enables the ugliest code in history. I still prefer it to Python's shaven tonsure and vow of celibacy. Perl is the whore of Babylon and you love her.

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

    --
    Expanding a vast wasteland since 1996.
  14. Re:The problem with open source^H^H^H evolving by Abigail · · Score: 2
    No, you read it wrong. By default, variables in Perl remain untyped. Typing becomes an *option*. Just like it can be done in perl5 already, actually.

    -- Abigail

  15. Re:Gee... I guess Perl was too Unambigious by Abigail · · Score: 2
    So then the syntax construction is not identical between refering to the variable within quotes or without quotes. Gee... that makes sense.

    Considering that outside of quotes a variable name followed by left bracket, something else, and a right bracket and it *not* meaning indexing is a syntax error, your wish for the syntax constructs to be the same inside and outside quotes is utterly meaningless.

    If you do want to do indexing, then the constructs inside and outside of quotes *are* the same.

    -- Abigail

  16. Re:word counts of "syntax" vs. "sematics" by Abigail · · Score: 2
    he word "syntax" occurs 33 times, while "semantics" occurs 4 times

    So what? It's only the second article in what is going to be a long list of articles. The focus of this article lied more with syntax than with semantics. The article also counted more occurances of the letters `e' and `t' than of `f' and `z'. Now what does that mean?

    -- Abigail

  17. Re:The Perl6 answer could be ... Ruby by krmt · · Score: 2

    Ruby looks really cool to me too. I've just downloaded it and installed it, and I'm planning to write a few test scripts in it. Since our server doesn't have a heavy load, I'd rather have our CGI's readable, and Ruby seems to be a good way to do it. I just need the time to go through the tutorial...

    "I may not have morals, but I have standards."

    --

    "I may not have morals, but I have standards."

  18. Re:THANK YOU RUBY ADVOCATES! by krmt · · Score: 2

    Hehe, I actually just sat down with Ruby and wrote a basic Hello World program with a class. I'm very impressed! The whole messaging idea (smalltalk, right?) is very very cool. I'm going to keep playing with it this weekend (or right now!!!! Hahahah!!!!) What kind of libraries does Ruby still need? It'd be nice to have it as feature complete as perl. I really like perl as a utility, and it's a fun language to hack, but I'm pretty impressed with Ruby as is.

    "I may not have morals, but I have standards."

    --

    "I may not have morals, but I have standards."

  19. Re:My God... by donglekey · · Score: 2

    Nice troll, comparing perl to BASIC and then calling Java a toy language. You obviously don't know fucking shit and haven't taken the time to learn very many languages very deep. Pretty lame. What is the problem that Lisp and Perl are both aproaching?

  20. Re:Programs written in Unicode? by baxissimo · · Score: 2
    There's also the last line of the article to tip you off: Because this project relies of the ability to fool the brain into accepting a projected image as 3D and because we don't take delivery of the 3D projection device until next spring, this project is usually referred to as "Project April Fool."

    That's funny as hell though. I'd never seen that before.

  21. Re:Best thing to ever happen to the Python communi by baxissimo · · Score: 2
    Yeh, you could write a "sonnet" in Perl, but the problem is there are no such agreed upon "elegant" forms. You might argue that "use strict" imposes such a form, but I don't think that goes far enough. It's still pretty much the same old Perl and you still have 20 different ways to do anything. Even if these restricted sonnet-like forms exist in Perl, is there documentation for that? I can get books on sonnets, can I get books on this hypothetical restricted Perl that I'm free to write in? I doubt it. Sure I could create that if I wanted to, and if it's good, with effort and marketing my Perl sonnet form might actually gain widespread acceptance. BUT I JUST WANT TO GET WORK DONE! I'm interested in the job I'm trying to do, not in designing and marketing my own language. I have better things to do with my time (like posting to ./ :-> )

    I very much respect Larry Wall and love reading all the stuff he's written about Perl and languages, and how Perl can be this organic evolving thing. It's all very satisfying from a philosophical point of view, but at the end of the day I don't want to have to spend my time trying to figure out which of 20 ways is correct or if in fact they are all equivalent.

    Here's another thought. I'll admit that I'm the type of guy who likes to know all the possiblilites and design choices before I do just about anything. That's often not such a good thing, but that's the way I am. So really using Perl takes me a long time because I feel compelled to find out what those 20 different ways are and try to pick the optimum. I'll grant that maybe not everyone is like that. For the guy who is happy just to get something up and working, maybe Perl makes things easier because he's more likely to stumble upon at least one of the 20 ways to do it sooner. So that guy doesn't need to learn the all the ways it can be done, and maybe he gets work done faster (I doubt it though because the volume of documentation he has to wade through will be larger in proportion to the number of ways to do things).

    So good for that guy who (maybe) codes faster using Perl. Unfortunately we don't just work with our own code. The minute you start reading other people's code this TMTOWTDI philosophy bites you -- you suddenly have to be able to recognize and understand ALL the ways to do it if you're going to be grabbing code from people who might be using any of these methods. And this sounds like it's going to get even worse in Perl 6 with plug in syntax modules.

    Being able to do things your way and create your own style and form in a programming language is great if you work alone, but most of us don't, and can't predict ahead of time exactly where the code we end up having to work with will come from.

    This natural language analogy that Larry always preaches is nice, but I think the purposes of natural language and code have some very important differences. We aren't born speaking any particular natural language, but we HAVE to learn to speak what those around us speak at an early age, well before we are able to make any sort of judgement about the quality of the language we are learning. Heck, if I had been able to wait and make an informed decision, I might have chosen to learn French instead of English. But once you've learned one language, unless you change your geograpic location there's little incentive to learn another (before you flame -- je parle un peu de francais, soshite nihongo mo nakanaka tokui desu.) Learning a human language is a necessity and something you do at an early age without really thinking about it.

    But computer languages just aren't like that. They are tools for making the computer do stuff and for sharing with others to show them how to make the computer do stuff. Computer languages are designed. Human languages are not. The prime example of an attempt at designing a better human language (esperanto) was pretty much a failure. In contrast most computer languages were heavily designed. C, C++, Java very popular and successful languages, and they were all designed.

    I'm definitely rambling now. But my point is that this "let the language evolve" and "let people use it the way they want" and "let people develop their own communities and dialects" philosophy -- this idea of making a computer language with the same properties as a human language -- is not helping make programming easier or make programmers more productive. The head can hold a tremendous amount of ad hoc syntax and grammar, we all know a ton of little bits of trivia about what is correct and what isn't in our native tongue. But most of us who do actually know a second or third human language are keenly aware that our grasp of the subtleties is not as great with those languages we didn't grow up with. Well learning a computer language is ALWAYS going to be like learning a second language (until people start playing Perl tapes to their babies, and Barnie starts singing Perl songs). So why try to mimic the flexible, ad hoc, crazy syntax of a human language when designing a language that is a tool for people to use? Make it simple and easy to remember! Make it so that you can learn it in a weekend. Make it so the person with two days experience in the language can read a program written by someone fluent in it. Human languages are all much more complex than that, but our programming languages have no reason to be.

  22. Re:The problem with open source languages... by Alomex · · Score: 2
    Is it better to have to somtimes think a bit to 'work around' flaws in the languge, or to change the languge, which makes everyone have to 'think a bit' to do anything?!?

    If you consider that early in the lifetime of a language the majority of programmers have yet to learn it then it is well worth the extra moment of thought from those who pioneered programming in it.

    Naturally this is somewhat subjective and it depends on the bug. I'd say "strict" in Perl is well worth the learning effort, considering how many bugs are obviated by it.

  23. Re:My God... by vsync64 · · Score: 2
    In my opinion, Perl is good for, well, Practical Extraction and Reporting. :) I've always called it "BASIC with regexps", simply because it is most reminiscent of good old BASIC in its incoherency. (Please note that incoherency is not necessarily a bad thing; for focused tasks it's probably better that each feature have a syntax uniquely tailored to it, but the problem occurs when you try to make the language do everything under the sun and then some.) Of course, it was possible to write a working syntax highlighter for BASIC :)

    Right now I'm addicted to Common Lisp, and one amusing thing I've picked up is that Perl is approaching Common Lisp in functionality. As an example, a few of my favorite things are closures and CLOS, and Perl has closures now. Perl's OO system (please note that I'm not an expert, and I've only used it in passing) isn't as powerful as CLOS (is anything?), but it's certainly free of the constraints of toy systems like Java.

    So Perl and Lisp are approaching the same problem from completely opposite directions. Perl has syntactic sugar splattered everywhere, while Lisp basically has (one (type (of syntax))). This is a good thing, because you can have the same power available to you, no matter what your preferences on syntax and platform organization are. I prefer Lisp, but whatever lets you Get Stuff Done...

    --

    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  24. The problem with open source languages... by electricmonk · · Score: 2
    ...is that trying to learn them is a moving target. I know that C++ and C don't change that often, even though there are open source compilers for them like GCC. It just bugs the hell out of me when languages keep changing like this. Anyway, I'm probably showing my ignorance by now, so I'm going to hit that little "Submit" button...

    --
    Friends don't let friends use multiple inheritance.
    1. Re:The problem with open source languages... by ichimunki · · Score: 2

      On one hand, I agree with you. On the other I'd say, tough. Yes, it would be nice if good languages were somewhat static, especially with regards to major syntax points. I must say I'm disturbed by what appears to be a future shift to Perl 6 calling object methods by using $foo.bar rather than $foo->bar(). But then, the new syntax is simpler to look at and will make it easier to distinguish from anonymous list indices as in $foo->[$bar]. Seems to me this is similar to the shift from using $Foo'bar to $Foo::Bar for explicitly naming variables within namespaces. The reason C doesn't change much is simple: it's extremely low-level. There just isn't much to change until the nature of computers themselves changes.

      --
      I do not have a signature
    2. Re:The problem with open source languages... by The_Runcible · · Score: 2

      I understand your frustration with having to relearn the syntax, but I believe that if the best thing to do is to byte the bullet as early as possible and fix the flaws.

      Well, that's if you want to call this early. There are many prgramers who have picked up perl through web application programing etc. When they dive into their next project which happens to be in perl6, with diferent sintax in some cases, they will run into problems when editing and understanding the code.

      Is it better to have to somtimes think a bit to 'work around' flaws in the languge, or to change the languge, which makes everyone have to 'think a bit' to do anything?!?

      --

      I am not a spork.
    3. Re:The problem with open source languages... by frantzdb · · Score: 3
      Yes and no... I think it's being made quite clear that Perl 6 will be different from previous versions. not just another round of improvmens. I don't think it's a moving target but rather Perl 6 will be a new target distinct from classic Perl.

      --Ben

    4. Re:The problem with open source languages... by Alomex · · Score: 3
      The problem with open source languages...is that trying to learn them is a moving target.

      I say that, to the contrary, the biggest problem with almost all languages, open source or not,is that they froze to early. Take any language (Java, C, C++, Perl, Python), and you can quickly name some real flaws that the designers readily admit to, but have left alone for "consistency" purposes.

      I understand your frustration with having to relearn the syntax, but I believe that if the best thing to do is to byte the bullet as early as possible and fix the flaws.

  25. Re:My God... by Bingo+Foo · · Score: 2
    If people want a python like language they would just sue python.

    Good point. If Larry would round up a few lawyers, he could probably convince a jury that Python is a rip off of his ideas, and then put them out of business. Then, since it's all open source anyway, he could implement Python within Perl. You're really on to something there.

    Bingo Foo

    ---

    --
    taken! (by Davidleeroth) Thanks Bingo Foo!
  26. Re:Programs written in Unicode? by Bingo+Foo · · Score: 2
    There is an article by Bjarne Stroustrup about the future of C++ where he goes overboard on this idea.

    It goes like this: He wants to overload whitespace, but recognizes that sometimes you want implicit whitespace overloading, such as ab==a*b. So, he proposes limiting all variables to one character. This is possible with unicode, he argues.

    The article reads more like science fiction by the time you get to the end. 3-d editors, overloading whitespace along all three spatial axes, etc.

    The guy is either a comic genius or completely off his rocker.

    Bingo Foo

    ---

    --
    taken! (by Davidleeroth) Thanks Bingo Foo!
  27. LaVey is dead by Water+Paradox · · Score: 2
    Jesus is alive. Big difference.





    'Pursue the Good long enough, and the Bad makes you yawn.' This is not a Christian belief, because it excludes the leap of faith Kierkegaard mentioned. The leap of faith means that we believe no matter how much we pursue the Good, we'll never get there. Our minds are finite, and Good is infinite.

    Faith, repentance, baptism, and the gift of the Holy Spirit. Anything else is not Christian.

    Applauding capitalism is like applauding a pig for finding a truffle. Pigs find truffles by nature. Applauding a pig for speaking proper English, now that would be something worth applauding.

    Close-minded Christians are no different than close-minded anything else. The difference is that Christianity provides a reliable tool to overcome close-mindedness. Surely you are not calling Jesus close-minded? He is our example, not our failing, mortal, neighbors, toward whom we are to express love.

    LaVey came and went. Houdini has more credibility than him; at least he was honest about his escapism.

    --
    information is immaterial
  28. Aw yer just a grump by Water+Paradox · · Score: 2

    Python enthusiasts drive me away, for some reason. Perl enthusiasts invite. That's why I choose Perl. I don't give a damn bout your pseudo complex namespaces being preempted. Perl is fun.

    --
    information is immaterial
  29. Re:Read some LaVey, man. by smittyoneeach · · Score: 2
    Christian.

    Intelligent.

    Open minded.

    Sorry, I just can't make the connection. If you truely were so open-minded and intelligent, you wouldn't be a christian.

    I am those three, and Open Eyed, as well.

    Pursue the Good long enough, and the Bad makes you yawn. Let us applaud LaVey's capitalism; he made a living out of packaging 'evil'. To what real end? Did it amount to much when he met the author of Reality, an operating system that still hasn't crashed?

    But you are spot-on when you allude to close-minded Christians. Alas, there is no escaping humanity in this life... :-|

    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  30. When Perl moves at the speed of Java by Bonker · · Score: 2

    Please, Larry, just don't make us set up virtual machines and class paths to make use of all the new OO junk that is creeping into Perl.

    --
    The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
  31. Not a chance. by Flying+Headless+Goku · · Score: 2

    Ruby lacks some key features. One example is inline data (multiline strings).

    Ruby's string handling is inferior to Perl's in other ways, too. It's a nice language in many ways, but it's not really a replacement for Perl.
    --

    --
    1. Re:Not a chance. by Waffle+Iron · · Score: 3
      Ruby lacks some key features. One example is inline data (multiline strings). Ruby's string handling is inferior to Perl's in other ways, too. It's a nice language in many ways, but it's not really a replacement for Perl.

      Try this:

      a = <<EOT
      hello
      there
      EOT

      b = "
      hi
      again"

      c = %q(one (more)
      time)

      puts a, b, c

      Result:

      hello
      there

      hi
      again
      one (more)
      time

      I agree strings need some work - especially polynomial performance with repeat appends. However, there are at least three ways to do multiline strings.

  32. Re:Programs written in Unicode? by MouseR · · Score: 3

    my $¾ = 0.75;

    Just think of the time and space we'll be saving by using Han characters!

    Karma karma karma karma karmeleon: it comes and goes, it comes and goes.

  33. Killing sh-ness by Luke · · Score: 3

    These first two had some resemblance to sh syntax for dis-ambiguating variable names:

    "${foo[bar]}"
    "${foo}[bar]"

    This is horrid!!!!

    "$foo\Q[bar]"

    So much for Perl being like a bit of sh, awk and C!

  34. Re:Gee... I guess Perl was too Unambigious by Luke · · Score: 3

    I thought the same thing at first, but then realized it's only in " " strings.

  35. Re:reasons to use python instead of perl by elmegil · · Score: 3
    As opposed to all the atheist and other assorted wackos out there? I left the church over significant issues a long time ago, but that doesn't mean that no one from the church can do good. Larry's doing some very good.

    As for reading what you wrote, sorry, but I can still read every perl script I ever wrote. If you can't, you're doing it wrong.

    --
    7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
  36. Perl 6 is to Perl as C++ is to C by churchr · · Score: 3

    Perl 6 is to Perl as C++ is to C.

    I bet Perl 6 is going to take a _loong_ time to catch on, if at all. Larry's taking one of the most complicated language syntaxes / semantics ever devised and piling on even _more_.

    my int $pi is constant = 3.14;

    my str $goodness!

  37. Gee... I guess Perl was too Unambigious by powerlord · · Score: 3

    Weird brackets

    Use of brackets to disambiguate

    "${foo[bar]}"

    from

    "${foo}[bar]"

    will no longer be supported. Instead, the expression parser will always grab as much as it can, and you can make it quit at a particular point by interpolating a null string, specified by \Q:

    "$foo\Q[bar]"



    Okay, I'll admit it, I write Perl code.
    I like writing perl code.
    Why are they taking away something that let things be unambiguous and adding this? How can you provide nested unambiguous clues useing a two chatacter, non bracket combination? ::sigh::

    Maybe its time to go learn Python. I can get used to white space indentation. This? I'm not sure.

    --
    This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
  38. Re:*more* contexts? Is Perl's use of context good? by Abigail · · Score: 3
    However, it seems that Perl 6 will extend the concept of "context" still further!

    No, it doesn't. It just makes it easier to query what the context is. But in perl5 you can make objects that behave differently in different context, including numeric context, boolean context, string context, iteration and the five types of dereferencing. Consult the 'overload' manual page.

    -- Abigail

  39. Re:Best thing to ever happen to the Python communi by baxissimo · · Score: 3
    I'll second that. I'd consider myself something of a Perl devotee. Though I'm primarily a C++ coder, there are some times a scripting language is the right way to go. In the past I've always used Perl for those things, but just now reading that Apocalypse2 thing gave me pause. I devoured the camel book. Enjoyed every wacky and twisted page. But there comes a point when you just want to get some programming done without having to consult a reference chart for every other line of code.

    Perl's (and Larry's) "There's more than one way to do it" philosophy is fascinating as programming language theory, but when it comes to really designing something remember this: It's actually easier to write a sonnet than to write free verse. This may seem counterintuitive at first -- there are more rules to constrain you when you write a sonnet. It must be harder to do! But wait, if you're going to design something GOOD it's got to have to have some kind of consistent form and organization in the end anyway. If you write free verse you will have to craft that all yourself, choosing from an infinite possibility of ways to organize words. But if you write a sonnet, that's all taken care of: you just concentrate on the CONTENT, on what you want to say.

    Larry might argue here that that's all well and good, but people still write plenty of free verse -- its probably more common today than ever, in fact. That may be true, but there's also probably more BAD free verse poetry today than ever as well. And brining this back to code, presumably we're actually talking about getting work done here, not expressing one's deepest feelings or inner angst with subtlety and tenderness. A good poem should be read a dozen times at least, and you'll get something more out of it on each read. A good program should only need to be read once. Subtlety that requires a dozen reads to notice is not a virtue! Going into an unfamiliar program knowing the form and syntax ahead of time just makes it that much easier to decipher.

    So good luck to all you Perl poets out there. I wish you luck. But as for me, I think I'm going to check out Python over the summer. It looks like a language that won't force me to keep on thinking about low level design and syntactical form, but instead free me to think about CONTENT.

    I also hear it's a pretty good scripting language for 3D apps (e.g. Alice3D and Disney's recent big switch to it.)

  40. Re:My God... by vsync64 · · Score: 3
    Get an identity pal, you've never written a single line of code in Lisp and you know it.

    No?

    --

    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  41. Re:Larry Wall ownz j00! by dnh · · Score: 3

    I too am a christian, your comment brought up many things that have been bothering me lately. I suppose the worst side of anything will be the most publicized, but its disturbing that recently the 'bible belt' had gotten so much attention, and is almost synonymous with christianity. As a christian i believe that these people stand against almost everything christianity is about. They spread hatred, fear and force their beliefs upon others, all three of which are said to be wrong in the new testament. Just as bad is that they put more value into the laws which they have imposed than the laws of God. They somehow mistake victorian morallity with christian morality. In doing this they become hypocrites, on the same level as the pharisees, the antagonists of the new testamate.

    All I ask is that people understand that this small group does not represent all christians, most of us are intellegent, open minded people who do not agree with the views of the 'bible belt'.

  42. *more* contexts? Is Perl's use of context good? by Paul+Crowley · · Score: 4
    I love Perl in lots of ways, it really is the language that rolls its sleeves up and gets the job done, but the first thing I'd take out if I had a free hand is the entire distinction between scalar and array contexts. As Perl is moving closer to a pure OO way of thinking, it becomes more attractive to make the distinction explicit, by using different names for "foo in scalar context" and "foo in array context".

    However, it seems that Perl 6 will extend the concept of "context" still further!

    Proposal 1 is ``that a hash in scalar context evaluate to the number of keys in the hash.'' (You can find that out now, but only by using the keys() function in scalar context.) Proposal 1 is okay by me if we change ``scalar context'' to ``numeric context'', since in scalar context a hash will produce a reference to the hash, which just happens to numify to the number of entries.

    So now you can get the wrong thing by expecting a number but accidentally creating a scalar rather than numeric context! You've got to have a new operator, presumably numeric(), to sit next to scalar()!

    Will there be a context for every type, built-in and dynmically created, in Perl? Or will the contexts remain a weird wart on the type system?

    I don't know what the right solution is, since Perl 6 would barely be Perl at all without the contexts, but moving away from contexts at least would be good.

    I could be wrong here. I'm writing this mainly because for the most part I love Perl, and I'd be interested in being persuaded that context is a good thing and worht the potential for confusion, that it's better to have a distinction between

    my $line = <FILE>;
    my @wholething = <FILE>;

    than having

    my $line = FILE.line();
    my @wholething = FILE.lines();

    I think I'm intellectually inclined to feel that Python does most things the right way, but somehow I still find myself reaching for Perl when I need to get the job done...
    --
  43. Programs written in Unicode? by Jeffrey+Baker · · Score: 4
    Larry says that the programs can be written in Unicode. Wow. If I am reading that properly, then this would be a valid Perl 6 program:

    my $¾ = 0.75;

  44. better off understanding ancient Mandarin by selectspec · · Score: 4
    Look I love Perl, but everytime I focus on the semmantics of the language, I find myslef utterly confused. Mainly, because I am lazy, but also, because I like an artificial world were there is only one way to do something (like C or Java). With perl, there are an infinite number of ways to do the same thing, and they all look syntacticly different. Understanding perl is like pooring over ancient manuscripts in different languages. My guess in the distant future our descendants will see Perl as this cryptic cult of demon worshipers or something. Some archeologist will spend his whole life trying to unearth the complexities, only to one day to yell out, "My God! Its so simple!"

    Perl. Can't live with it, Can't live without it.

    --

    Someone you trust is one of us.

  45. My request for Perl6 by lupetto · · Score: 5

    Here is my one and only request for perl6:

    When running the 'Configure' script, make the questions a little more difficult. This will effectively weed out serious sysadmins and programmers from the newbies.

    The perl6 configure script should keep track of the answers to their questions, and grade them on how many questions they've got correct.

    Don't know which version of malloc to use??
    Do you want to use vfork()? You sure?
    NO PERL6 FOR YOU!!

    Come on people, if you don't even know the size of the byte boundy on a double, how are you supposed to understand something like:

    if ( /DECLSPEC.*\s\**([^\s\(]+)\(/ ) {

    Post the users name and email address on a public web site and let others view it. Email the results to their family, friends, and employers! Have a special list for those who ctrl-c before it's finished, call it the "chicken" list.

  46. Larry Wall ownz j00! by vsync64 · · Score: 5
    I have to chuckle a little bit at the title of this series, and the fact that Larry Wall actually knows what the word "apocalypse" is. I'm not a big fan of Perl, myself, but I have to say that Larry Wall is one of the most interesting and insightful people to show up in the arena for some time.

    As a Christian, I have to say it's nice that people like Larry are out there to show we're not all stupid bumbling loonies (it's just Sturgeon's Law cropping up again, you know). If you've read any of his writings, especially his "State of the Onion" addresses, you'll see that he manages to present his thoughts and beliefs in a humorous and intelligent way.

    Secondly, I really like the way he manages to make analogies between things. The first year he used sounds, the second year he used pictures, and the third year he used smells. And somehow he ends up with a grand scheme that addresses theology, science, computers, and, of course, Perl.

    I think this is great, not just because the subject matter is interesting, but because to be any good at programming, you have to be able to map between different systems. The good ones don't seem to be as focused on depth (although they certainly can be; no one can argue that Knuth isn't good, and he's way hardcore) but on breadth of experience. The more different systems you experience, the more you can abstract the particular thing you have to be working on and actually transcend the implementation language and platform. (Or at least that's what I tell myself, being permanently scatterbrained and distractable :)

    Anyway, I don't know how to keep this from sounding hopelessly fanboyish, but ummm Larry Wall is cool and learning new stuff is cool, and I recommend that everybody go read his stuff and then go play with something you've never tried before. Exploration is the One True Way to have fun with computers again.

    --

    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  47. The Perl6 answer could be ... Ruby by Waffle+Iron · · Score: 5
    Perl has been my favorite language for some time now, even with all its warts. I've been keeping tabs on Perl6 stuff and thinking about how Perl could be improved. I finally surfed over to the Ruby site to check it out, since I heard that it was an attempt at a "better" Perl.

    After playing with it for a while, I think it could be my new favorite language. My Ruby programs usually come out even more concise than Perl, but just as clean looking as Python.

    Ruby needs more library support and some optimization work (I usually get about 4X slower than Perl), but I think that is an extremely promising contender in this space.