Slashdot Mirror
LWN Interviews Larry Wall
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.'"
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.
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.
Check out Althea for a stable IMAP email client for X. Now with SSL!
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.
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've finally had it: until slashdot gets article moderation, I am not coming back.
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.
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.
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....
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Segfault.org has the the answer.
--
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.
-Michael
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..
:) And 'use strict'.. The only time I'd advocate the lack of their usage is in single-use scripts.
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?
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
-Michael
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)
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 ?
[Pruneau
Question: What programming language will engineers use in 20 years?
Answer: I don't know, but they will call it Fortran.
"Rub her feet." -- L.L.
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.
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.
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.
------------
------------
Tonight on Fox: Deadliest Executions Part XVII