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

 


Forgot your password?
Close
typodupeerror
×
Perl Programming IT Technology

State of the Onion 11 278

Posted by Zonk from the my-personal-favorite-is-french-onion-soup dept.
chromatic writes "Larry Wall's State of the Onion 11 address is now online. Every year, he describes the state of Perl and its community through metaphor and analogy. This year, Larry explored the history of scripting languages, from their dimly-lit beginnings to their glorious future. Along the way, he also describes several of the design principles invoked in the design of Perl 6. 'When I was a RSTS programmer on a PDP-11, I certainly treated BASIC as a scripting language, at least in terms of rapid prototyping and process control. I'm sure it warped my brain forever. Perl's statement modifiers are straight out of BASIC/PLUS. It even had some cute sigils on the ends of its variables to distinguish string and integer from floating point. But you could do extreme programming. In fact, I had a college buddy I did pair programming with. We took a compiler writing class together and studied all that fancy stuff from the dragon book.'"
This discussion has been archived. No new comments can be posted.

State of the Onion 11 More

State of the Onion 11

Comments Filter:

  • scripting (Score:5, Insightful)

    by Lord Ender ( 156273 ) on Friday December 07, 2007 @12:15PM (#21613333) Homepage
    I really wish the term "scripting language" would die. Can't we just call them "very high level" languages, instead? Isn't that sufficient to distinguish the Perls, Pythons, and Rubys of the world from the "high level" languages like C and C++? It is perfectly possible to compile Python programs, for example, to a pyc binary. They aren't any more "scripts" than a.out. The difference between "very high" and "high," to me, is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense.

    • I don't think Perl or Python are scripting languages. I think sh-script is a scripting language.

      I don't like to think about AppleScript.

      -:sigma.SB

    • Re:scripting (Score:5, Insightful)

      by Ed Avis ( 5917 ) <ed@membled.com> on Friday December 07, 2007 @12:22PM (#21613455) Homepage
      Python, Perl, Lua etc. are very high level languages, at least from a slightly old-fashioned perspective that regards assembler as the baseline and something like C or Pascal as high level. But there are other very high level languages which are not scripting languages, for example Haskell, Erlang, Prolog, C++ with insane template nonsense, even SQL and XSLT. So the term scripting language is still useful I think. The definition is a bit fuzzy, which is what Larry points out in his talk.

      • Re: (Score:2)

        by Intron ( 870560 )
        C only has the data types supported by the hardware, so it is not a high-level language. A high level language is one which provides an abstract view of the machine.

        • C only has the data types supported by the hardware, so it is not a high-level language.

          Uh, no. C has guaranteed data types that must be present in every implementation, such as 32 bit integers (not native to 8 bit processors) and floating point (not native to many processors). It is true that C has flexible data types that can be optimized for particular hardware.

        • Re: (Score:2)

          by Ed Avis ( 5917 )
          C provides an abstract view of the machine in that you don't have to care about how many registers the processor has; you can just declare as many variables as you want and they will be allocated to registers automatically when needed for computation. It provides abstract data structures (structs) where you don't have to care about the memory layout. I agree that ML could be considered more abstract than C, and assembler less abstract; I don't think that 'provides an abstract view of the machine' is a goo

          • Re: (Score:2)

            by Intron ( 870560 )
            A data structure is not a data type. Carry bits have been around for a while, too.

            When you compile C the assembly code looks like the C code. You can do it yourself at least as well as gcc, usually better. Subroutine calls and stack frames follow standard, simple rules and leave a lot of room for optimization. Structs and unions are just a list of offsets and bookkeeping. There's basically nothing in the compiled code that you don't write in the C source code or include in a very straightforward way fr

            • Re: (Score:3, Insightful)

              by Chandon Seldon ( 43083 )

              Hand compiling is only moderately more complicated for Perl than it is for C. Just as the C function turns into a specific pattern in assembler, the various things that Perl provides can be turned into assembler patterns too. The stuff that Perl does for memory management implicitly is only moderately more complex than the stack manipulation that C does implicitly for lexical variables. Even the two data structures that Perl provides - vectors and hashes - are just very simple data structures that would alw

        • Re: (Score:2)

          by SL Baur ( 19540 )

          C only has the data types supported by the hardware, so it is not a high-level language.
          That's not the distinguishing feature of a "high-level language". A high level language is one which often requires translation of the source into hidden subroutine calls to implement some of the features (and I'm not referring to simple stuff like double word arithmetic).

          C is not a high-level language because it is sugar-coated assembly.

          • That's how you would define high level language if you were trying to exclude C, and even then it's arguable - malloc is part of the C language for example. Sure, you'll argue that it's a function call - part of the standard library not the language - but that's really just a question of syntactic sugar - C-like language where malloc was a keyword with special syntax wouldn't be any higher level than C.

      • My point is that whether a virtual machine, bytecode interpreter, or traditional compiler are used, you are still going from human-readable-language to machine code. The path you take to get there is inconsequential compared to what really matters: the language itself.

      • Re: (Score:3, Interesting)

        by anomalous cohort ( 704239 )

        To me, the term scripting has nothing to do with the level of abstraction. Rather, it is more about whether or not the source is directly interpreted or compiled into an intermediate form. Having said that, I must admit that it would be awfully silly to create a low level language that is interpreted.

        From most of the languages that he lists, it looks to me that what he is really talking about are Dynamic Scripting Languages. Scripting languages that are also dynamic provide a lot of flexibility and can

        • Re: (Score:3, Informative)

          by Ed Avis ( 5917 )

          I must admit that it would be awfully silly to create a low level language that is interpreted.
          Not at all. Open Firmware [wikipedia.org] (used in the OLPC among other devices) is built around a Forth interpreter which can be used to write device drivers and hardware initialization code. Pascal was originally implemented as a p-code interpreter. And so on.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      Agreed. I code almost exclusively in Python at work (I say "almost", because I dabble in bash), and I'm so damn glad I don't have to deal with memory allocation nonsense like in C and C++. Even Java gets on my nerves with its static typing.

      Languages like Python make it easier to design and implement algorithms without having to worry about other concerns.

      • High level != "automated memory management" (Score:5, Informative)

        by Anonymous Brave Guy ( 457657 ) on Friday December 07, 2007 @01:10PM (#21614145)

        Can we please stop bashing C++ memory management? I write C++ for a living, yet very rarely use what the critics typically call "manual memory management". Either it's really not that hard to do things in better ways, or I guess I must be a superhuman programmer, because according to all the checking software, I haven't introduced a memory leak since... no, actually, I've never introduced one in as long as I've worked here. If you want to talk about the advantages of garbage collection, knock yourselves out, but please stop treating C++ and C as if they're the same in terms of memory management. They are different worlds.

        In any case, garbage collection is far from the biggest benefit of using a scripting language (or whatever we want to call them) over something lower level. As others are pointing out, the more important properties exhibited by most of the modern scripting languages that make them "high level" include first class data structures, first class functions, and dynamic typing.

        • Re: (Score:3, Informative)

          by Anonymous Brave Guy ( 457657 )

          Before anyone else points it out, I realised that my final sentence in the parent post reads as though I think dynamic typing is necessary for a high-level language. I don't think this is so in general, but in the context of scripting languages, I think it's one of the key features that lets you write higher level code more easily. In a statically typed language, some sort of type inference serves a similar role, keeping the code generic and cutting out unnecessary boilerplate code.

        • Re:High level != "automated memory management" (Score:5, Insightful)

          by smittyoneeach ( 243267 ) * on Friday December 07, 2007 @01:22PM (#21614337) Homepage Journal

          Can we please stop bashing C++ memory management?
          No.
          If we don't insist on treating the tools themselves as the end product, then how will we perpetuate mis-information, and sell "new" products, which are, dared we look at them objectively, just re-shufflings of what has come before?

    • Re: (Score:2)

      by LWATCDR ( 28044 )
      "Is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense."
      I guess you haven't used STL.
      I have not used Perl for a while but when I did I would have called it a scripting language. It just didn't lend it's self to large programs. Python looks like it is better for large tasks but I haven't had time to get into it.
      Perl and PHP are what I consider the crescent wrenches of programing.
      Not the best tool but just too u

      • Is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense.

        I guess you haven't used STL.

        Assuming you're referring to the container classes in the C++ standard library, those are nothing close to having first class data structures and good language support for them. You can't write literals using them, for a start. Even what they do do is clumsier than in languages with built-in support, e.g., Perl's neat sort keys %hash, Python's yield facility and for loop, Haskell's pattern matching for list processing, and many similar ideas in these and many other languages.

    • Re: (Score:2)

      by interiot ( 50685 )
      Even compiled python retains the ability to eval(), no? Granted, even C can do this at times (C-Interp, XCoral), and in my mind at least, eval() isn't at the core of what defines "scripting languages" (as you mentioned, garbage collection (making memory management go away) and robust introspection (making serialization and debug-dumping brain-dead easy) are the defining features for me).
    • And, where would you classify graphical programing languages, like Labview?

    • Re: (Score:2)

      by rbanffy ( 584143 )
      I think "scripting language" refers to the idea that what you write in the program happens in that order. Another idea is that you can write the program with a text editor and run the text file directly from your shell without further steps.

      That's not like C or Java, when what happens when the program runs is what is inside the main function (or static method). And that happens only after you turned your text file into something else.

      I think we may be creating a category where there is none or, better, we a

      • Re: (Score:2)

        by bahwi ( 43111 )
        I think Interpreted language is what it is now. In Perl/PHP etc... you can define functions/methods before or after you call them, as the entire file is parsed into bytecode typically, then interpreted. The steps are all automatic from the compiler/interpreted(perl or php from the command line). Python can save as bytecode to speed it up even further, although it is a one-time speed up typically.

        Most IDEs let you compile and run at least basic C/C++ code from the IDE, without any additional steps. :D You ca

    • It is perfectly possible to compile Python programs, for example, to a pyc binary. They aren't any more "scripts" than a.out.

      Pedantic mode ON
      A .pyc is python source code compiled to bytecode. That bytecode is then interpreted by the Python virtual machine which executes appropriate machine code, sort of like the Java VM (though I don't think the Python VM does JIT compilation to machine code).
      This is different from a.out (or the more modern alternative, ELF), which contains real machine code, which is execu

      • You think that's pedantic? Your "real machine code" isn't. It's a set of CISC code that is interpreted to RISC. Only the RISC runs on the Si itself. The so-called binary does not.

        I win the pedantry wars and my point stands :-)

    • Re: (Score:3, Insightful)

      by Yvanhoe ( 564877 )
      Perls, Pythons, and Rubys are interpreted languages as opposed to compiled languages. A .pyc is not an executable file.
      Every people use the term differently. Here is mine : I am doing a script when I give directives to launch programs or functions written in another language. When the CPU spends 90% of its time outside my program, I consider that this is a script.
      Python's philosophy is that it is a scripting language in the sense that if you spend more than 10% of your CPU time interpreting some python
    • "Can't we just call them "very high level" languages, instead?"

      No.
    • The difference between high and very high has always meant about one or two bowlpacks difference to me...

    • Re: (Score:2)

      by drew ( 2081 )
      I don't know about python specifically, but in my experience "compiling" most interpreted languages only means that you are embedding the a copy of the interpreter and the source code (or the parse tree) of your program together into an executable format. It doesn't give you any benefit over interpreting the raw script other than that you don't have to have the standalone interpreter installed on the target machine. (and if the "compiler" generated the parse tree for you then you save a minor hit on parsi

  • Perl 6: The Language of the Future (... Forever) (Score:5, Funny)

    by joe_n_bloe ( 244407 ) on Friday December 07, 2007 @12:19PM (#21613409) Homepage
    Every year Larry talks about what interesting things have been going on with Perl 6. These interesting things never include "release."
    • Every year Larry talks about what interesting things have been going on with Perl 6.

      And this year he barely even did that!

    • Fine by me (Score:4, Insightful)

      by winkydink ( 650484 ) * <sv.dude@gmail.com> on Friday December 07, 2007 @12:26PM (#21613513) Homepage Journal
      Perl 5.8 does everything I need it to. There are other languages I use when Perl doesn't do what I need it to. I don't need one language for all of my needs.

      I view Perl 6 as an continued employment mechanism for those who write books about Perl and teach Perl to others.

      • Re: (Score:2, Insightful)

        by TheLink ( 130905 )
        There's one big limitation I find with Perl 5.8. It's slow. Don't get me wrong it's fast enough in many cases.

        BUT if it was 20-30 times faster people would be able to use it for a lot more stuff where they'd otherwise have to resort to stuff that involves a lot more work :).

        Parrot hasn't been very impressive, and ponie is dead anyway.

        Yeah I know python is a bit faster and cleaner but so far it doesn't seem like a huge improvement.

        I've looked at Lisp and I've come to the conclusion that:

        Lisp is powerful for

        • Re: (Score:3, Interesting)

          by bzipitidoo ( 647217 )

          I'm not a Perl wizard, but I have used it. I find a lot more limitations than just slowness.

          Calling on external C functions from Perl is a pain. You can't ignore all those C functions, there's way too many useful ones out there. There's UNIX system calls, XWindows and higher level GUI libraries, socket and networking stuff, file manipulation, and everything in libc. Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Then you're stuck trying to figure out Frozen Bubble f

      • perl 5.8 does everything I need it to. There are other languages I use when Perl doesn't do what I need it to.

        perl 5.10 is about to be released, and it has a number of significant improvements over perl 5.8. Off the top of my head: it has a real "switch" statement included (as originally designed for perl 6), it has recursive regular expressions that can be used to do Text::Balanced sorts of things (if for some reason that now-standard module doesn't do it for you), and a number of new modules have been

    • and every year the design for Perl 6 becomes more and more contorted and ultra-complicated, basically taking every cool feature Larry sees in other languages and mashing them together into an incoherent Mulligan stew. If Perl is like "whale guts everywhere" then Perl 6 is like taking a whole Oceanarium of sea creatures and dropping them through the dual rotors of a crane copter 10,000 feet over Manhattan.

      • Re: (Score:2)

        by krog ( 25663 )
        Thankfully, Perl 6 follows the same principle as previous Perls: you don't need to know the whole language to use it -- kinda like spoken language. There's more than one way to do it, and those who can't hang with this design goal have plenty of pattern-rigid, syntax-poor dynamic languages to choose from (Python, Ruby, Esperanto...).

        • Re:Perl 6: The Language of the Future (... Forever (Score:4, Interesting)

          by timster ( 32400 ) on Friday December 07, 2007 @12:47PM (#21613817)
          That sounds great, until you're trying to work with someone else's Perl code and it turns out that they have a special fondness for those Perl features which were inspired by awk. A language with a clean design means that you can collaborate with others.

          • Re: (Score:2, Insightful)

            by krog ( 25663 )
            Or, conversely, you could blame yourself for not knowing the language you're trying to work on, rather than blaming your colleague for knowing it.

            I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.

            • Re: (Score:2, Insightful)

              by timster ( 32400 )
              You said that it's OK for Perl to have an excessive number of features, because you don't have to know them. I'm pointing out that the truth is that you do have to know the whole language to use it. So no, I don't have to "blame myself for not knowing the language", I blame the language for being poorly designed.

              • Re: (Score:2)

                by krog ( 25663 )
                You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language. This is to be expected. However, if you are in your boxer shorts and you just want to pump out a short file-diddling script before bedtime, no one is going to tell you that it can't look like C.

                Perl will let you approach a problem however you want. Imperative, functional, OO programming all works out of the box; constraint, logic, aspect programming are possible. This liberates many programm

                • Re: (Score:2)

                  by timster ( 32400 )
                  You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language.

                  No! You need to know the whole of the language to work with three other people, each of whom knows a different part of the language.

                • Re: (Score:2)

                  by Otter ( 3800 )
                  This is to be expected.

                  And his point is that that's why hideous syntax and features are a problem even if you choose not to use them.

            • Re: (Score:2)

              by Coryoth ( 254751 )

              I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.

              I think which side of the enforcement continuum looks appealing is generally a function of the sort of project you're working on. The more programmers who all have to cooperate and work with each others code, and the greater the importance of long term maintenance, the more appealing strict enforcement becomes. Conversely, the more important rapid expression and development of ideas is, the more appealing lack of enforcement and flexibility in how you express things becomes.

              So yes, if you have a big projec

          • Re: (Score:2)

            by ajs318 ( 655362 )
            But you could say the same about almost any language, unless it's either based on a "bondage-and-discipline" paradigm, forcing you to do things One True Way; or hopelessly crippled in terms of things you can actually do with it. Or both. (*cough* Modula-2 *cough*)

            Some use screws, some use nails; some use nuts and bolts, some use tapped holes. Some use gaffer tape. Perl doesn't mind which you use. The OP's complaint sounds like someone who has inherited a second-hand tool box and found no number 2 pos

          • Re: (Score:2)

            by doom ( 14564 )

            timster wrote:

            That sounds great, until you're trying to work with someone else's Perl code and it turns out that they have a special fondness for those Perl features which were inspired by awk. A language with a clean design means that you can collaborate with others.

            Which explains why Lisp is the leading programming used throughout the industry.

            The trouble with the line you're taking is that you run into problems with "the waterbed theory of complexity": If you simplify the language, the libraries g

          • ... in it's own foul way. But I know what you are saying. MY analogy would be to say that the whole world speaks one language, and if an English-speaker has trouble understanding Chinese, well, then, you just haven't read that part of the manual.

            Personally, I take care to write my Perl in grunts and whistles, which are fairly universally understood. Except in those equivalent places where "nodding your head" means "no" and "extending your middle finger" means "hi there!"

        • Re:Perl 6: The Language of the Future (... Forever (Score:5, Funny)

          by nuzak ( 959558 ) on Friday December 07, 2007 @02:01PM (#21614873) Journal
          > Thankfully, Perl 6 follows the same principle as previous Perls

          Except for actually existing.
      • Sounds like a good episode of 'Does it shred?'

      • Re: (Score:3, Funny)

        by sootman ( 158191 )
        Congratulations on the best mental image, evar. And yeah, it's taking a while: here he is talking about Perl 6 over five years ago. [slashdot.org] (Home of the famous "big knob" quote.)

        I wonder how this guy turned out: "Given this approach to learning Perl (just for a general working knowledge, maybe light usage,) is it really worth spending a lot of my time learning Perl now, or should I wait for the big Perl6 revision?" :-)

    • Yup... and he doesn't apologize for it (Score:5, Interesting)

      by krog ( 25663 ) on Friday December 07, 2007 @12:31PM (#21613575) Homepage
      The Perl 6 community is more focused on getting it right than getting it into the marketplace ASAP. While this is frustrating for many -- it seems like every other day, there's a Perl 6 feature I want to use in my Perl 5 program -- it has contributed positively to the development of Perl 5 and Perl 6 alike. Perl 6 is painstakingly designed and planned as truly a next-generation dynamic language, and as features are completed, they often spill down into Perl 5. (See the perldelta [cpan.org] for v5.10, out very soon, for some good examples.)

      Unless someone is willing to finance full-time development on Perl 6, this is the best we get. I think it's pretty good.

  • In other news... (Score:4, Funny)

    by nycguy ( 892403 ) on Friday December 07, 2007 @12:32PM (#21613603)
    Duke Nukem Forever team announces that they are reimplementing everything in Perl 6.

    • Re: (Score:2, Funny)

      by Ignominious ( 816315 )
      FTA:

      "Then there's Duke Nukem Forever, a nice clean design. It has some issues, but in the long run Duke Nukem Forever might actually turn out to be a decent platform for running Perl 6 on. Pugs already has part of a backend for Duke Nukem Forever, though sadly that has suffered some bitrot in the last year. I think when the new Duke Nukem Forever engines come out we'll probably see renewed interest in a Duke Nukem Forever backend."

  • Thanks, and see ya! (Score:2, Insightful)

    by stuntpope ( 19736 )
    Thank you, Mr. Wall, for providing a language that caught my interest and led me into a profitable career.

    However, I moved on several years ago. One of those Python guys inspired negatively by Perl. Much of what keeps me away from Ruby, in fact, is the Perl resemblance. I still have a legacy Perl application to maintain, but I don't do any new Perl work.

    I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a

    • Re:Thanks, and see ya! (Score:5, Insightful)

      by kisrael ( 134664 ) on Friday December 07, 2007 @01:18PM (#21614273) Homepage

      I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

      I guess I really don't get the purpose of the essay.
      I think the purpose of the essay might be to be a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

      It was also (IMO) a damn fine read, with lots of intriguing rhetorical flourishes (I also learned a little C. [...] That's because a little C is all there is) and thought-provoking concepts, like how most human languages can express anything, but they differ in what you MUST express.

      I think most people have a rough idea where Perl is now (present, though likely slipping as a % of interesting code being written) and where it's going (a guess about how the new perl 6 would be received when it finally shows up)

      As to TMTOWTDI, I've concluded TOABWTDI (There's Often A Better Way To Do It).
      Better than Perl, or in general?
      If the latter, well sure... there will almost be another way that is better in some subset of the parameters you could use to measure "Betterness". One tradeoff you always have to make is how much time and conceptual effort do you put into optimizing that...

      • Re: (Score:2)

        by doom ( 14564 )

        I think most people have a rough idea where Perl is now (present, though likely slipping as a % of interesting code being written) and where it's going

        It's not entirely clear what you're getting at here, but this brings up a bit of a peeve with me: we all know that lanugage snobs dislike perl -- why they appear to dislike it more than the far-worse PHP is hard to discern, but clearly they do -- but you shouldn't jump from that to the conclusion that use of perl is dwindling. For example, if you look a

        • Re: (Score:2)

          by kisrael ( 134664 )
          Well, don't get me wrong: I love Perl and it remains my "goto" language... everything on my own tends to be Perl CGI (and, oy, flatfiles...) but professionally I do Java, lately with a big hunk of "Wicket". (And I worry that my years of exposure to Perl CGI, and the strong mapping with CGI and Hashmaps in the normal HTTP cycle has made me have a hard time getting used to stuff like Wicket that abstracts that away)

          My guesstimation that Perl is dwindling was based on A. fewer headhunters who were appearing to

          • Re: (Score:2)

            by doom ( 14564 )

            I started playing w/ PHP before it was ready for primetime, apparently, and while Perl has a lot of quirks, but unlike PHP there are relatively few things that stand out as being that way because it was easier for the implementor of the language to do it that way...

            You mean, except for the complete absence of any namespaces in PHP?

            PHP's technical advantages, as I understand it, are (1) a smaller memory footprint; and (2) ISP's seem to feel it's easier for them to support.

            I can see how those would be

            • Re: (Score:2)

              by kisrael ( 134664 )
              From a programmer's point of view, PHP's advantages seem to be (1) that whole code-embedded-in-HTML thing, ala JSP or ASP (I feel I get about the same benefit through use of Perl's quoting operator) and (2) pretty much every damn library seems to be baked into the typical PHP install, as opposed to requiring trips through CPAN, and then some challenges installing locally, if you don't have admin privileges on the machine you're renting webspace off of.

              When I was playing with PHP in 2002, then, the DISadvan

        • the provocative larry wall (Score:3, Interesting)

          by doom ( 14564 )

          we all know that language snobs dislike perl -- why they appear to dislike it more than the far-worse PHP is hard to discern, but clearly they do

          Actually, it occurs to me that I probably do know why perl provokes such rabid responses, I think it's because of "The State of the Onion" talks.

          "Larry has turned what was a gentleman's war into guerrilla tactics. He consistently and cleverly (I never said he wasn't brilliant) slanders other languages and language communities, and encourages

    • Re: (Score:2, Offtopic)

      by Tomy ( 34647 )
      Though Ruby may have borrow some syntax features from Perl, most of the Ruby community stay away from them. I don't think you'll find much Ruby code out there that in any way resembles Perl. Like you, I'm negatively-inspired by Perl, after working for a company that had huge amounts of Perl code as a large portion of their infrastructure.

      Code should be pleasing to read, since we spend so much of our lives at this activity. I think Python and Ruby do well in this goal, though the double underscores like "__i

    • Re: (Score:2)

      by Fweeky ( 41046 )

      Much of what keeps me away from Ruby, in fact, is the Perl resemblance.

      foo =~ /bar/ and $1 etc are probably the most used Perlish feature in Ruby. While I've never been a fan of Perl, I do appreciate the odd little shortcut like this. Where it's not suitable, there's always md = /bar/.match(foo), md[1], or indeed Regexp.new("bar").

      Sigils like @ and $ have only a passing resemblence to Perl; they define scope, and can often be considered a warning sign ($foo -- zomg you're using a global you idiot! @foo -- hey, maybe you'd be better off using the accessor methods?), but the

  • BASIC/PLUS (Score:3, Funny)

    by Sloppy ( 14984 ) on Friday December 07, 2007 @12:43PM (#21613745) Homepage Journal

    Oh wow, BASIC/PLUS on a PDP-11 running RSTS. That's how I started too. And yet, I became a Python guy. ;-)

    • Re: (Score:2)

      by markana ( 152984 )
      Yeah, that particular machine was an 11/45 running RSTS/E. That was a sweet machine and O/S learning programming and systems fundamentals. Oh, it had FORTRAN, COBOL, and assembly too, for the masochistic Comp Sci students.

      The real reason they didn't put Unix on it was because that machine was the *only* minicomputer on campus, and ran the school database (written by Larry) and cafeteria card readers. It was locked in to running those critical functions, and V7 Unix certainly wasn't going to run on the oc

    • Re:BASIC/PLUS (Score:4, Funny)

      by Suzuran ( 163234 ) on Friday December 07, 2007 @12:58PM (#21613987)
      My high school had a calculator policy of "You may bring any calculator you like to calculator-allowed tests."
      So one day I decided that my calculator was GLAXIA, my PDP-11/44 which ran RSTS/E (V8 or V7, I forget which...)
      I packed the whole thing on a cart; the system (Two BA11s), RA81 disk, and LA-120 teletype, and wheeled it into the classroom.
      The teacher asked me what it was - "It's my calculator." The look on his face was priceless.
      It was loud as hell, but the teacher allowed me to complete the test with it. I forget what I scored.
      Thereafter the calculator policy was changed to read
      "You may bring any calculator you like to calculator-allowed tests, provided it does not dim the lights when powered on."

      Old hardware rocks!

    • Re: (Score:2)

      by rbanffy ( 584143 )
      A lot of people started with BASIC: that was just about the only choice for 8-bit computers with no real mass storage back in the 70s and early 80s. No way I could conjure the money for a real CP/M computer.

      And the IBM-PC was, already, the same sorry inelegant mess it is today, so I won't get started. And it was very expensive too.

      I learned to program in a Texas calculator and my first computer was an Apple II+ (after a Sinclair ZX-81 clone that was not a real computer) and, or course, I learned BASIC with
  • I remember how Fry's discounted the dang thing to 14.98. The Fools.

  • wanna be annoyed? try this (Score:2, Informative)

    by wardk ( 3037 )
    attend a local Perl user group meeting seeking basic knowledge like maybe a few tips about hashes and namespaces

    your question may be answered if you are willing to sit through 3 hours of the alpha geeks sparring over who understands Damian Conways latest obsfucation most, hopefully with many examples of their own variations to programs that have no real use. meetup at break with someone who didn't participate in that discussion and note they don't know what the hell they are there for either

    besides, anyone

    • Re: (Score:2)

      by doom ( 14564 )

      This doesn't sound anything like the San Francisco Perl Mongers group I hang around with... neither does it sound much like the gang at perlmonks.org.

      Sorry if you were traumatized by Tom Christensen, but maybe you need to grow some skin, you know?

  • Maybe I just don't get it, but I really don't see how "pair programming" -- at least as it was explained to us in the CS classes I took -- could possibly be efficient. Two programmers sharing one computer?

    I'm not the world's most l33t programmer (far from it), but I did win a local programming contest a few years back -- due in large part, I think, to the fact that the other teams had to share a terminal, whereas I was working by myself. Anecdotal, I know -- but it gives me definite doubts about the wisd
    • While pair programming may not win any contests for LOC/hr efficiency, that is not the only measure of such. For some projects, for some people, pair programming provides efficiency gains in bug creation/resolution, on-spec performance, and reduction of dead-end programming. YMMV.

    • Re:Pair programming? (Score:4, Informative)

      by sohp ( 22984 ) <.moc.oi. .ta. .notwens.> on Friday December 07, 2007 @03:05PM (#21615821) Homepage
      Pair programming isn't 2 people both trying to use the computer at the same time. Pair programming is 1 person working on writing the code and doing the keyboard tasks while the other person looks on and thinks about what's happening within the context of whatever functionality is currently being added to the code. They talk to each other, help each other notice stupid 1-off errors and typos, and bounce ideas off each other. Every so often, whenever one of them is tired of typing, or the one not typing has an idea that can be more easily expressed by typing out the code rather than talking about it, they switch.

      Maybe one of them is a whiz the language and tools, and but is a bit fuzzy on the domain, and the other one is new to the language, but is a domain expert. At first the whiz does most of the keyboard work and the domain expert handles the meta stuff, but gradually they learn from each other and switching off helps them both progress. The domain expert might come to a point where he is trying to explain something complex, so decides to ask for the keyboard and type in some code that does it. It might not be syntactically correct or use the language structure in the best way, but the whiz, looking on, can help clean it up once the ideas are down.

      But really, you can't fully appreciate it until you try it with someone with experience in pair programming.
  • The summaries ended in 2006...
    http://dev.perl.org/perl6/list-summaries/ [perl.org]

    Does that mean the future is over?

  • Worst presentation in a while. (Score:4, Insightful)

    by harrkev ( 623093 ) <kevin.harrelson@ ... om minus painter> on Friday December 07, 2007 @01:58PM (#21614813) Homepage
    Is it just me, or is this his worst presentation in a while? I think that I missed last year's, but I remember thinking that a couple of his presentations were quite original. There is the one where he based his entire presentation on an optical-illusion picture (three years ago, as I recall), and one where his presentation was based on the default Red Had screensaver collection (two years ago, if I am not mistaken). I had always thought that listening to him present one of these would be kind of like geek-stand-up-comedy. This one was downright plain by comparison.

    • Re: (Score:2)

      by doom ( 14564 )

      Is it just me, or is this his worst presentation in a while?

      Yes, it's just you. Last year's collection of family pictures was way too fluffy, essentially a punt. This year's, by comparison, is an interesting overview of some technical issues, with a few interesting little quips tossed in. It's not as brilliant as his "postmodern computer language" talk, for example, but it's nothing to complain about.

      I think the real trouble with these talks is that Larry Wall doesn't really have an overview of the

  • Put up or shut up, please (Score:3, Insightful)

    by coryking ( 104614 ) * on Friday December 07, 2007 @03:17PM (#21615985) Homepage Journal
    I'm disappointed with the state of perl. I used to be a huge perl nut and have a major project that is all mod_perl. But I'm growing increasingly fustrated by the lack of modern programming tools, especially compared to other modern languages. Even PHP has a better choice of editors. Heck, I can write syntax colored, intellesense'd python in Visual Studio!

    Perl6 is a text book example of why rewrites are bad. While these people are busy writing the Programming Language to End All Programming Languages, .NET has stolen the market for the very thing these people where trying to make. Pugs, or parrot or whatever, sounds a heck of a lot like .NET/Mono. By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono. At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

    So please, put up or shut up.

    See also: Netscape.
  • Perl 6 has been in development now for some 6 years or so, before I even learnt perl. Since then I have come to love Perl's text handling features, hate Perl's bastard syntax for anonymous hashes and array references and the fact that really simple stuff, like automatic de-referencing of references is STILL not in there, or that array walkers or other features that have been in PHP for years now, are still not there. I hardly ever use Perl now. When I need to shell script, I use Bash (because it works in al

Slashdot Top Deals

BLISS is ignorance.

Close