Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Perl Programming

LWN Interviews Larry Wall 47

dlc writes: "Linux Weekly News interviews Larry Wall. 'Until now, the process of the design of Perl has been evolutionary. It's been done by prototype and modification over time. I talked about becoming stupid, but I've always been stupid. Fortunately I've been just smart enough to realize that I'm stupid.'"
This discussion has been archived. No new comments can be posted.

LWN Interviews Larry Wall

Comments Filter:
  • I buy the first readers arguments. After all, a company is less likely to have a "god" (read ADD megalomaniac with bad breath and small penis) directing the project.

    I tried hard as hell to contribute to perl. Because I didn't know how to package up some modules, I was ignored, so I did it, and was then scoffed at because I did it "wrong" (despite the fact it worked for me ...). So I refused to place them on CPAN (and we're not talking shit here - it was 2 months worth of work porting python C modules to perl).

    The real problem with Perl is

    (a) Tom Christainsan - he still doesn't see the need for threads - we were trying to get this years ago

    (b) their hatred of java - I tried to get them to do a java implementation of perl (and offered to help naturally), which would then have run on all JVMs etc, allowed applets to be developed in perl etc. They *hated* the thought of this. They tried to do project like Penguin (signed perl as an alternative to java's superior security model), and Ned Flanders javaperl thing (came with the O'reilly books - I got a free copy from them for some code of mine in the book) - this was *STUPID* - it embedded perl in java - who wants to do that? People want it the other way around - to embed java in perl - imagine if we could use the Swing libraries from perl? (bye bye perl/tk)

    (c) Their refusal to change perl bytecodes to the JVM - they could do this without breaking any code. I started on it but was out of my depth. Again, their hatred of java blew this.

    (d) The *STUPID* decision to put the 'eval' keyword in the language (and Larry is a language designed, huh?) This is fine when we're talking about a 50k lisp system, but a 1 meg perl language? - you don't include 'eval' in something that size. This is the sole reason we have no perl compiler - because the compiler is built into the interpreter - they are the same thing (and don't mail me about 'B' - I assure you I've been there and done that).

    (e)
    Their "there's more than one way to do it" motto. This is the most stupid programmers motto ever.
    So you use different idioms to me - great. Ever heard of patterns larry? (not as if I live by patterns like some people, but idioms are undoubtedly useful). Do things the same way in languages!

    (f) Their other motto that you only have to know 20% of the language to use it. This makes it a throwaay write once language, since the 20% of perl you know, is unlikely to be the same 20% the next huy knows, etc. etc.

    ...

    (z) Chip went off to write a second generation perl. What was he going to write it in? C++.
    !!!!!!

    Why the hell would a C++ implementation of Perl improve it? Now a java one would, since we'd have a perl that ran (and more importantly, LINKED AGAINST) JVM bytecodes.

    Spastics, the lot of them. And Larry (or Ned Flanders, or whatever) is NOT funny. Nor linguistic (I did language science at univercity, so don't try to tell me about that shit)

    They are doomed to fail.
  • Nice to see a link that talks about Ruby on Slashdot, hasn't got much press in America, but a lot outside of it. Check it out in any case, it's got this 4 year perl veteran swearing he will never write perl code again. Very smooth OO, very clean syntax. Like, perl, but more professional, and like python but less anal. From a perl perspective, it's got all the great quick hack features, but a lot less clumsy to make the transition to a huge hack. And a lot easier to maintain due to a consistent style and readibility. Default local scope helps too. If your ever bored, checkout the link on Ruby compared to some other popular languages on http://www.ruby-lang.org/en/compar.html Not saying it's the end all be all, but it's a great thing to try. The Pickaxe book is recommended as a lot of the better documentation isn't in English yet. -- idling in #ruby on EFnet.
  • Well, how fast is C evolving? Not at all since the ANSI specification superseded K&R as far as I can tell. So the answer is yes, but that doesn't mean that the language will lose any popularity.

    What about C99?

    (although the differences between C89 (aka K&R2) and C99 is miniscule compared to say, Perl 4 vs. Perl 5.)
    ---

  • I just wish Larry had made things backwards compatible with past perls. I support a perl/web based product that had major problems going from perl 5.005... to 5.6 on both Linux AND NT. Cookies were handled so differently that it just ceased to work. And no documentation about the change.

    Don't get me wrong, I think Perl is pretty damn slick in the world of programming languages and I truly hope that Perl 6 is the last version so that we can have a standard.
  • how can you think of something finished when everything else is evolving ?

    Yes, but we're talking about a programing language here. I can see the reasons why something like Mozilla or GNOME or mutt might grow and change over time. However, with a programing language, we're talking about the foundation that everything else is built on. If you're changing the foundation every 2 months, you're going to have a hard time keeping everything above it in one piece.

    Now admittedly, this is partially negated by the Perl5->Perl6 autotranslation mentioned in the article and it's also partially negated by the issue of minor tweaks to the language that don't affect existing programs (in both instances, my analogy to a building's foundation fails). But in general, stability is a good thing. Each new tweak has a potential to break older stuff -- this is bad enough in the realm of system libraries; throwing the entire programing language into the mix is enough to give anyone who's studied software engineering nightmares.

    Hell, even Debian appreciates the importance of stable software. As I understand the process, they perform a version freeze at some point and, rather than upgrading when bugs/security holes come out, instead backport the patch to work with the stable version.

  • Perhaps the most important of all programming-related question, and certainly a must-have in any IT interview worth its salt: what music do you listen to while you code?

    np. autechre "amber"
  • I think this is one of the most sensible things I ever read: I mean, a computer program is build with the intention to solve a problem, right? If that problem is solved, why should people keep wasting their time twitching things ad nauseam?

    Of course people would continue to develop on top of Perl, but Perl 6.0 would be the point of reference, the minimum to which any other implementation would have to stick to be able to call itself Perl at all.
  • I had the same skepticism myself when I started looking at the language a few months ago.. but after seeing the RAA (ruby application archive, CPAN equivalent) grow significantly in the last few months, it stands a good chance.

    To give you an idea, the RAA has had 6 updates/additions to it in the last 16 hours.

    RAA still needs some severe reorganization, as talked about before on the ruby-talk mailing list.

    As testament to the current truth to what you said, my current project at work (>3500 lines of perl.. a complete mess) is written in Perl due to the modules support.

    Now if only Ruby's RDBC can get more database support to match up with Perl's DBI, i'll be happy as a pig.

  • C has evolved since the ANSI specification of 1989; a new ISO standard, ISO/IEC9899:1999 [www.iso.ch], was ratified in December 1999. However, it will probably take some time before all major compilers support the new standard.

    A list of changes and some drafts of the standard are available online [onetelnet.ch]. Please note that these might differ from the final version.

  • by scrytch ( 9198 ) <chuck@myrealbox.com> on Tuesday January 23, 2001 @06:50AM (#488758)
    Unfortunately Linux is emerging onto the platform scene when there is already a significant surplus of better-supported options. NT, Solaris, AIX, etc ...

    Do I really need to continue this argument? Python cracked Perl's armor just fine, and it appears Ruby has already overtaken Python in its country of origin. People still write scripts in shell and tcl too.
    --
  • I thought he looked more like Gallagher, but I guess he's the perfect mix of Gallagher and Flanders.
  • I think regular expressions go back just a little bit further than Perl...

    I took the comment to mean that they borrow Perl's version of regular expressions. As someone who played with grep and sed before getting into perl, while the regular expression theory was already around and in practice, perl managed to engineer it into something a little nicer.

    On a related note, Philip Hazel's written the PCRE library, which stands for Perl-Compatible Regular Expressions. I know tin and Xnews both use it. So there are people out there borrowing from directly Larry Wall's ideas and using them outside of Perl.

  • "Both are free script language which more or less share the same goal: be a more readable Perl."

    I can't speak for Ruby since I know little about it but the name, but I'd hardly call Python "a more readable Perl."

    Perl is a language that was meant at the beginning to do jobs that were just out of reach of the sed, awk and shell--which is why Perl tends to resemble sed, awk and shell to a fair extent.

    Python was meant to be a very clean, orderly language, which is why it has such features as using indentation for statement grouping, and can have something like "foo foo) and (x bar)". Readablity seems to be Python's reason for being.

    I won't claim that either language is better than the other, but they strike me as thoroughly different in culture, lineage, and goals.
  • This poses an interesting question. Once the language can do everything in a sense that it was meant to do (everything but operating systems, pretty much) do you discontinue development? Or do you still tweak it for as much speed as possible? What happens if the enviroment of computers changes enough that perl is just not apt to handling it in its latest version?

    I think the idea of the final version number asymptotically approaching 2PI is actually a pretty good model. This is especially true given the probability of immediate subroutines (a sort of metacompiler feature like in FORTH). The modules may keep growing, and what is considered the Perl 'package' may grow to include them (and they become like libc and libm where they're not part of the compiler, but the implementation is considered incomplete without them in most instances), but the core is quite likely to change less and less.

  • I couldn't disagree more. The fact that you bought the software perpetuates exactly why proprietary code companies don't have to be responsive. They already made their money. Chances are, if there are bugs or holes in the code, it is already being worked on, or has been deemed to not need to be redesigned. Also, the phrase
    "...and just because the developers thinks it's fun."
    is completely unfounded, and based solely on your opinion besides. OSS projects tend to be more responsive, because there is a specific person you may contact with a problem, and are probably very interested (for reasons other than money) in working with you to fix it. Note the term working with you. I've never heard of MS inviting people to help fix bugs.
  • By the way, the moderators are really awake this morning : 33 posts only in that story, 26 moderated down : is /. suffering from a over-crowd of mods ?

    Its not a moderation problem, Its all the ACs that post garbage. The signal/noise ratio on Slashdot lately has gotten ridiculous. I browse at +1 to avoid most of the crap, but it still irks me to see the list of stories and see something like (14 of 76 comments)

    One idea I have to reduce the amount of crap is disallow the use of AC for the first several hours a story is posted, that way you lose a lot of the "First Post" and other flamage that usually happens within hours of a story being posted. At one point, a story (I believe it was the latest GNOME posting) had only 3 of 39 posts that were rated 1 or higher. A vast number of garbage posts and trolls happen within 2-3 hours of a story posting.

    siri

  • You know, I think that if I were picking somebody to be in charge of the world -- or even this little country I live int -- it would be Larry Wall.

    He's happy, and not driven by worldly ambition, and his ethos of trying to contribute to the world is both admirable and real-seeming. He also seems remarkably non-dogmatic.

    I suppose these people don't seek to be in charge, though. They just lead where they want to go and hope other people follow....

    --
  • How do you define a finished programming language?

    Segfault.org has the the answer [segfault.org].

    --

  • OK,OK Guys, you are right, but, as usual, it depends of the point of view.

    From the language designer perspective, TeX did not change (and Knuth Rules, of course : one of my favorite dream is to buy his "Art..." books and have enough time to study them properly, and toroughly).

    ...But from the user perspective, who really used naked TeX, without LaTeX or anything helping ? Better admit that you use vi to directly write postscript files to you favorite printer.

    That's what I meant about evolving : once the niche your software is filling (the user needs)grows, disappear or mutate, you will have to change it.

    TeX is extremely good at laying out 2-D pages, but what will it do if 3-D representation begins to be commonplace : someone will have to extract the ideas in it (hopefully the code) and adapt it to the new reality.
  • I disagree with the "doomed" part. It may not take off as much as perl, but it is really a beautiful, elegant language. I think LW criticized awk for being elegant, but awk was limited in what it could do. Ruby seems to be both elegant and very complete, at all the same things that perl is good at.

    I personally have used perl extensively, for larger and larger personal and work-related tools. Unfortunately, ALL of my large projects in perl have become so UGLY that I don't even want to maintain them, and I'm always milliseconds away from reimplementing them in java or even C++.

    My point: Don't underestimate the lure of language simplicity, synactic sugar, and features that promote correctness. I think Visual Basic took off because of its simplicity, and I use java (over C++) because of language simplicity and correctness.

    BTW, as for libraries. True, there are many perl libs, but they don't necessarily play-nice and plug together well. A language that has trivial-to-use OO features should promote reuse, meaning less people reinvent libraries.

  • From the language designer perspective, TeX did not change
    And Perl doesn't have to change; packages can and should evolve, but the language core doesn't have to.
    who really used naked TeX, without LaTeX or anything helping?
    I did it when there was no LaTeX in sight, and I still fairly regularly do it for various reasons. It's not very hard, believe me. Just read the TeXbook.
  • Yes, the perl -d to start the debugger is REALLY NICE as it means that everywhere I can run a Perl script, I can also debug it..
    I hope that all the other scripts languages will duplicate this feature..

    For the begin/end instead of { }, I don't like it either because it is unecessary typing which does little to improve readibiliy IMHO.
    But I don't agree with your critics: first dump vi use vim instead, then if emacs (or vim) doesn't treat the same way {} and begin/end, this is a "misfeature" of the editor, it is not a fault of the language..

    About your critics about the speed: frankly interpreted languages (all of them) are not used for their speed..

    About the syntax, I do think that using a SmallTalk-inspired syntax is a really bad idea..
    IMHO SmallTalk difficult to read syntax is the reason why the language is not more widespread..

    But it is definitely nicer than Perl's syntax which I dislike utterly.

    I do prefer its string syntax "xxxx #{var_name} xxxxx" than Pythons (not readable) and Perls (too easy to make an error which is ignored unless you use -w).

    As for $xxx as an easy way to find variable xxx, don't forget that you can also use ${xxx} (I do it inside strings) so just searching for $xxx is not good enough.
    I prefer Ruby sparse use of @ and $, it is less verbose than Python (self. everywhere) and more readable than the cluttered Perl $%@ usage..

    Could you explain more precisely the Pythons problems: poor use of anonymous functions, couldn't find a way to functionalize 'use strict' ?

    I'm not that impressed with Perl's CPAN, maybe I'm too difficult..

    I am currently trying to decide if I go with Python (good integration with the rest) or if I choose Ruby: it has definitely some very good points, because I can't stand Perl anymore..

  • I haven't used it yet (except to download and type out the quick examples). Things I've noticed that I'm not crazy about:

    I haven't found a decent debugging mode for it yet. It mimics perl in many ways, but -d isn't the same.

    They use "begin / end" instead of the uniform {}. This pisses me off because of lack of emacs / vi matching.

    Numbers are all objects, which hints at slower performance. In fact, performance is said to be above that of python, but one can deduce it as being slower than perl.

    It is said to have a much more convinient C / C++ API, but that additionally suggests that it'll have additional layers of abstraction, meaning slower interface code (pure speculation). I have the same issue with the Perl6 direction.

    It's supports multi-threading even if the OS doesn't, which obviously requires interpreter threads. Depending on how they do this, it could be a negative. (additional checks per ruby-op)

    It uses mark-and-sweep memory, which is great for memory leaks, but my initial impression is that it'll be slower than reference counting (since I believe it requires wasteful periodic passes through memory.. Probably through one of it's interpreter threads).

    Being a perl advocate, I have no room to speak on this, but some of the syntax seems odd - making use of punctuation marks, etc.

    It's heavily OOP, and that isn't always the best solution to problems. Granted, it's useful for things like x.length, but sometimes you want to just length( @{ $some_gloal_name } ) to get the job done. I'll have delve deeper to see how well they copied the TMTOWTDI philosophy.

    They made a nice attempt to duplicate perl's interpolating strings through the use of "xxxx #{var_name} xxxxx", which I definately like better than python's c-like method: "xxxxx %s xxxxx" % var_name. Since if I wanted the latter I could just use prints. Still, I can see the extra characters geting annoying. (though there might be a compiler speed-up, since fewer variations need be accounted for).

    One of my favorite features of perl is it's code's searchability.. Want to find a function, search on "sub xxxx". Want to find a variable: "$xxx". (Though mangled perl variables can be a pain-sometimes). If nothing else, it's a key for emacs to color on (which remarkably aids reading code). C, Java, Python, and now ruby give this up. (Note: ruby does use $ and @, but only for globals / member-vars, which only has minimal usage. Local's are prefix-less).

    I'm definately going to try it out. I dabbled with Python for a while, but couldn't find a compelling reason to move over (poor use of anonymous functions, couldn't find a way to functionalize 'use strict', etc ). I'm expecting a similar final result with ruby, but you never know.

    Lastly, I don't believe it's as tried and true as Perl. Ignoring for a moment it's small but growing size 3rd party support compared to CPAN, it was a devil for us to convince our bosses to continue doing web development purely in Perl (as opposed to the more popular but less coder friendly servlets). A good manager would most likely not entrust their clientelle to such a bleeding edge technology. Perl's been on most every platform that I've ever heard of (still waiting for palm). It is the epitomy of robustness as far as I'm concerned. The only times I've ever core'd had to do with c-libraries (which you can _always_ avoid; even if it means resorting to IPC). I'd trust perl-code to c-code any day (assuming you had actual developers on the job). Still ruby's defintaely got future potential.. The trick is how do they differentiate themselves today so that they can grow into tomorrow. They're not defining their own niche, they're piggy-backing existing ones.

    What they could do to really bolster acceptance is provide porting scripts fom raw perl. They seem to mimic enough of the rough syntax (like reg-ex, qq(..), etc), so it's bound to be possible. Due to the divergent memory archetectures, it's doubtful that XS code could be ported though. Perhaps if anybody ever used swig, otoh. :)

    I saw a lot in Ruby that I heard Larry refer to in Perl6. Namely: OOing the data-types, providing a clean C-interface, consoldating datatypes, etc. So I think it's fair game to steal back from. At least Larry recognizes it; obviously stating his bias. I get the feeling that his cozy job is dependant on the longevity of Perl. If a branch like Ruby could steal the show (considering it is the closest I've ever seen to perl), Larry might be in for some stiff competition.

    -Michael

    Note: I welcome corrections.. I'm still learning Ruby / Python. Just don't mess with my Perl. ;)
  • But I don't agree with your critics: first dump vi use vim instead, then if emacs (or vim) doesn't treat the same way {} and begin/end, this is a "misfeature" of the editor, it is not a fault of the language..

    I used vile for the longest time, but I've become spoiled with emacs. There is literally only one thing I miss from viXX, and that is the "." repetition feature. Anyway, the issue with "begin/end" is that rubdy DOESN"T maintain consistent use of "begin".. Things either fit on a line, or continue (with an optional "then") until the "end" directive.. It seems that the only time you see the word "begin" is in a try-block. AS the try block.. It boggles my mind why they didn't stick with the traditional keyword "try". I'm sure you could write parsers the color and match properly for begin/end, but it's definately more complicated to achieve.

    About your critics about the speed: frankly interpreted languages (all of them) are not used for their speed..

    Not so. Perl can be significantly faster than servlets in a CGI / mod_perl environment. Every ounce of speed is essential in that realm.. It's simply a matter of not wanting to give up extremely rapid development time (and freedom from worries of core dumps or memory leaks)

    Ideally the language of choice is highly convinient AND fast.. Perl has a really optimized and speedy engine underneath.. And through proper use of profiling, you can tune your app to be nearly as fast as C. Granted you can do this with Ruby/Python as well, but I think it's easier to do with perl without resorting to C-code.

    Perls (too easy to make an error which is ignored unless you use -w).

    But you _do_ use "-w" don't you? :) And 'use strict'.. The only time I'd advocate the lack of their usage is in single-use scripts.

    As for $xxx as an easy way to find variable xxx, don't forget that you can also use ${xxx} (I do it inside strings) so just searching for $xxx is not good enough.
    I prefer Ruby sparse use of @ and $, it is less verbose than Python (self. everywhere) and more readable than the cluttered Perl $%@ usage..


    Yes, it's definately not fool-proof. But of all the languages I've had to "find stuff in", perl's historically been the easiest. It's another reason I like emacs.. The default operation is case insensative search-as-you-type operation. But don't let me get into a viewer war.. I use both vi and emacs interchangably.

    I agree that to the casual user, there's less line noise with Python or ruby's flat-variable names. But I'm still partial towards the shell/perl method of variable names. I definately like the method variables over $self->{..} or self.xxx. Maybe it's not too late to make suggestions to the Perl RFC process.. Allow over-riding method variables as 'my' would over-ride 'our'.

    Could you explain more precisely the Pythons problems: poor use of anonymous functions, couldn't find a way to functionalize 'use strict' ?

    Well, anonymous functions in python are more like 'lambda', which are single line functions, not fully supported functions. In Tk design, it's often nice to write really complex anonymous call-back functions in the middle of the function call.. To my knowledge you can't do that in Python, since you can only have a single non-complex statement in a lambda function. It seems that you have greater freedom with ruby at least.. Though the { |var,list| statements } takes some getting use to.

    I haven't completely delved into either Ruby or Python, but I can't find a way in either to require pre-declarations of variables (as perl uses 'use vars qw( $x $y )' or 'our ($x,$y);' or 'my ( $x, $y );' or 'use fields qw( x y);' I've found that invaluable to avoid situations such as $filename, $file_name, $fileName. Now coding standards help greatly in such situations, but what about $login or $login_name? Having a single place to declare all these names helps to visually catch such errors. Granted "-w" should alleviate most of the activity. Ruby won't let you use unassigned variables as far as I understand (which takes care of much of the -w functionality)

    I'm not that impressed with Perl's CPAN, maybe I'm too difficult..

    I can't imagine what you do that hasn't allowed CPAN to help you. I have over 50 modules that I use regularly from CPAN.. DBI alone is monumental. Ruby seems to have copied many of them. Hell, if you've ever performed a "use XXX", you're using a module that at one point in time or another needed to be downloaded from CPAN.. As they developed greater fan-fair, they were incorportated into the standard distribution. I have a top-level book-mark to CPAN since I visit it almost weekly. But that's just me.

    I don't have anything against Ruby.. Every language I've ever used has something that pisses me off; Perl definately being among them. If you're just looking for something to do personal work with, then Ruby should suite you fine (my guess is that it'll be more fun than Python). But if you're looking to do serious work outside of Japan, you're going to have some time before you'll have much support if you leave the mainstream C / C++ / Java / Perl.

    -Michael

  • Someone remind me to use the damned preview button. Spoiled by the geeklogs that force me to.
  • A lot could still be added to Perl. I remember Larry (or someone else from the core Perl dev group) saying that many people now want Perl to be more of an "orthogonal" language -- one that is built around a central idea, like functions in SML, or objects in Smalltalk, or lists in LISP -- whereas Perl was designed as the diagonal language, that integrates features of many languages can be bent to any of the paradigms out there (even if it's not best at it).

    I like this "diagonality" and I see this as the direction Perl should go. There's still quite a few programming language paradigms that haven't been "integrated" into Perl.
  • Once the language can do everything in a sense that it was meant to do (everything but operating systems, pretty much) do you discontinue development?

    Well, how fast is C evolving? Not at all since the ANSI specification superseded K&R as far as I can tell. So the answer is yes, but that doesn't mean that the language will lose any popularity.

    Other languages, such as SQL, evolve very slowly, some languages such as Pascal find niches, and some, such as Java have yet to be tested by time. Others, such as COBOL and FORTRAN have relatively little new development done, but a great deal of existing code that is maintained.

    I'd say that Perl falls somewhere in between all of these :0)

  • Care to be a little more specific? OSS projects tend to be *more* responsive, rather than less, afaict, since you have pretty direct access to the developers. Of course, it has to be a *good* idea. If it's not a dramatic one, then the project leader may not be willing to spend time working on it. This doesn't mean they won't include it if you send them a patch, just that they have other priorities.
  • Hey, I can do magic with Perl but I would like to see a stable and uniform threads support in the
    langage. It doen't neet to be native threads, just
    standard.

  • C is evolving (at least up until 1996)... it's C++. You might reject the comparison but you see C with objects, with generics, with exceptions, etc.

    I'm guessing in Perl's evolution it has seen similar core additions at one point in time (I don't know since I just started using Perl in the last year).

    But your original premise is very true. The languages stabilize... or more likely the people in charge of driving the standard simply lose interest and devote efforts to something else (at this point in time higher level languages are the thing).

    Brian Macy
  • I think OSS projects are *differently* responsive, not more or less.

    Closed source things, if you're paying for them, and if they're not in some kind of monopoly position, really *have* to be responsive if they want to keep selling the product. (And it isn't necessarily the case that you don't have access to the developers of course.)

    Open source projects which you're not paying for don't *have* to be responsive in this way and often are not, but they are usually responsive in a different way: if you decide you want some feature, and implement it in a competent way, then it's often likely to make it into the sources. You are dependent on the fractiousness of the people who are running the project of course, and some OSS people are pretty fractious, but this often works out OK.

    A third category, often ignored, is OSS projects which you *are* paying for -- for instance buying support for some OSS system. For these things you should get very good responsiveness, especially as you can audit the changes.

  • That Zope [zope.org] includes Perl scripting, Perl will gain more popularity with application developers. I for one could not do without Zope and it essentially was the key factor in my descision to use Python as my main language. I was pondering Java and Perl, too, but Zope convinced me that Python was truly a superior language.

    Of course, perhaps the next version of Perl will include the ease-of-use and clean-factor of Python. Perhaps the next version of Perl will allow ultra-fast development time and allow programmers to do what they enjoy most: look after their polo ponies, and not have to spend weeks developing applications that would take 3 days in Python and Zope.

    I certainly hope that they fix the lexical scope problem in Perl and also make it less obfusticated in the next release. I have had dealings with legacy Perl code and it wasn't a pleasant experience. Luckily a lot of the system in question has been rewritten in Python and Zope and only some esoteric Perl code remains. (Well, actually, the size of the system in question runs into hundreds of thousands of lines of code, there is a lot of Perl code left in it, but it seems to work fine, and I don't have time to go through it:-).
  • It's dead ! Nobody use it anymore, the only hardware able to run it rusts in some remote museum.

    I have to admit that the sheer concept of finished software is alien to me : how can you think of something finished when everything else is evolving ? I'm pretty sure that even the so-called "livings fossils" have maybe barely evolved, but have evolved a bit nonetheless.

    But maybe that was some of the famous LW second-order jokes ;-)

    By the way, the moderators are really awake this morning : 33 posts only in that story, 26 moderated down : is /. suffering from a over-crowd of mods ?

  • Yeah, what's up with that? I counted 5 in one answer at one point!
  • This reminds me of an old engineering joke going around when Fortran 90 was new. Maybe it's not that funny. So sue me.

    Question: What programming language will engineers use in 20 years?

    Answer: I don't know, but they will call it Fortran.

  • You tweak all you like, but if its only tweaking there's no need for a new major number, so no Perl7, only Perl6.147.3
  • Unfortunately Linux is emerging onto the platform scene when there is already a significant surplus of better-supported options. NT, Solaris, AIX, etc ...

    Your analogy is flawed - linux was and is fundamentally different than NT and Solaris - in that it is both free and open source.

    Ruby, Perl and Python are all free and open, which levels the playing field considerably. Added to which, languages are not OSs - library support is extremely important.

  • by Ars-Fartsica ( 166957 ) on Tuesday January 23, 2001 @06:02AM (#488786)
    Unfortunately Ruby is emerging onto the development scene when there is already a significant surplus of better-supported options. Perl, Python, Java, etc. all have more mindshare and support, regardless of Ruby's supposed superiority at the language level.

    Added to which, don't discount the value of libraries. One of the biggest draws of perl is CPAN - you can literally find a module to do nearly anything you want. I don't see Ruby bridging this important gap anytime soon.

  • Both are free script language which more or less share the same goal: be a more readable Perl.

    I would say from my short knowledge of both that Python is a bit more verbose and readable but that Ruby is more object-oriented and powerfull.

    Python has more users (less than Perl of course) but in Japan Ruby has more users than Python..

    I "fear" that we may end-up with the same situation as functionnal languages: having lots of differents languages which compete in the same workspace.
    Well not quite similar, because I suspect that there is quite a big number of script written whereas functionnal languages seems to be doomed to stay quite confidential..

    PS: for those who like Perl, yes you can write readable Perl but this is not really in the spirit "There is more than one way to do it" of the language.
    And each time I had to maintain a Perl script written by someone else it had been a major pain..

  • Umm, perl doesn't handle cookies. Your scripts, written in perl do. Whatever problems you may have with your cookies, chances are very good it's because you didn't write the code correctly in the first place.
    --
  • Please allow for the fact that the interviewer probably speaks English much better than you speak Japanese. :-)
  • A discussion of languages on slashdot inevitably devolves into matters of preference and the recognition that different languages are different tools for different jobs.

    Nevertheless, it seems Ruby has not recieved as much press as it should. I have yet to hear one bad thing about Ruby itself (ignoring observations about the relative size of its support base relative to Perl and Python, which may simply be the result of Ruby's age). This is more than I can say about Python or Perl.

    I have been using Perl extensively until this point, but Ruby sounds very appealing. Is there anyone who has tried Ruby and not been impressed enough to switch? Why?

  • how can you think of something finished when everything else is evolving?

    There seems to be a lot of talk about open source and evolution. Don Knuth [stanford.edu] has written bug-free public domain software that is actively used for circa 20 years and is not evolving.

    Knuth writes: [stanford.edu]

    I still take full responsibility for the master sources of TeX, METAFONT, and Computer Modern. Therefore I periodically take a few days off from my current projects and look at all of the accumulated bug reports. This happened most recently in 1992, 1993, 1995, and 1998; following this pattern, I intend to check on purported bugs again in the years 2002, 2007, 2013, 2020, etc. The intervals between such maintenance periods are increasing, because the systems have been converging to an error-free state. The latest and best TeX is currently version 3.14159 (and plain.tex is version 3.1415926); METAFONT is currently version 2.7182 (and plain.mf is version 2.71). All these systems are Y2K-compliant. My last will and testament for TeX and METAFONT is that their version numbers ultimately become $\pi$ and $e$, respectively. At that point they will be completely error-free by definition.
  • There is one piece of code that accomplishes a _specific task(s)_ faster than all other implementations.
  • This bit from Larry's interview stuck out to me.

    CL: Now, since Perl 6 is going to be developed under more organized way, do you expect it to live longer? (Of course, I don't mean Perl 5 is dead, though.)
    LW: One of the proposals, one of the RFCs was that Perl 6 should be the last version of Perl. The idea is that if we make Perl 6 sufficiently flexible, then there's no need for Perl 7, because you can always bend the full language into whatever you want it to be.

    This poses an interesting question. Once the language can do everything in a sense that it was meant to do (everything but operating systems, pretty much) do you discontinue development? Or do you still tweak it for as much speed as possible? What happens if the enviroment of computers changes enough that perl is just not apt to handling it in its latest version?

    Flamewars aside, I don't think that perl development will stop. If Larry Wall stops developing it, then the rest of the perl development group will jump on.

    I know I'm going to get modded down for this, but I'd like to hear some other's opinions.
    ------------
  • Yeah, what was up with that? A few questions into the interview I couldn't stand reading it anymore. Whoever wrote this article made himself and Wall look like morons. I mean, aside from the excessive smileys, there were spelling errors and a slew of sentences that just made no grammatical sense. Does that website even have an editor?
  • if you count languages that are maybe not Perl directly, but have taken parts of Perl... You know, they've borrowed regular expressions or other parts of Perl.

    I think regular expressions go back just a little bit further than Perl...

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...