Slashdot Mirror
Perl And Standards: Larry Rosler Interview
Kaufmann writes: "In this interview with Joe Johnston (on O'Reilly's Perl.com), Larry Rosler (of HP, one of the people who helped put the 'ANSI' in 'ANSI C') shares his thoughts and advice on the value of standards, optimising Perl code, how Sun should handle Java, and programming in general. Will we ever see a Perl Language Subcommittee too?"
The OO paradigm promised to save the world of software engineering from bugs, complexity, and maintenance difficulties, but if the last 5 or 6 years are to be considered as indicators for future performance, it's not worth the hype.
Think of it in terms of economics. People will write the most complex and featureful software they can that stays within the level of buggyness they can tolerate. Therefore, buggyness will tend to stay constant.
Software is just as buggy now as it was 5 or 6 years ago, but is far more complex. I have personal experience with what can be done with OO to facilitate large complex systems which would be unthinkable without it.
Therefore, people have taken advantage of the ability of OO to manage complexity and pushed the envelope with it. I don't consider this a bad thing.
In addition, while I know Perl well and like it a lot, I would not dare use it for a large complex project.
pornking
We had an intro to perl as part of the "programming environments" course last year at my university. The reference book was O'Reillys Perl intro book. That's were I first played around with it (I had vaguely heard about it already).
It was great, tough a little superficial, but I now have about 5 other perl books on my bookshelf, so there you go.
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
.....you may just get it.
According to this a group of hardy hackers are hard at work on a complete, from scratch, re-implementation of perl in C++. This reimplementation is supposed to be completely compatible with perl5. How can you guarantee compatibility without a specification? My guess is, in the same way that perl5 broke some obscure perl4 scripts, perl6 will break perl5 scripts - but without a spec, it's impossible to tell which of those breakages are bugs and which are features!
I'm really not sure I understand what point you are trying to make here. If it is "no one thing will cure all our problems" I agree 100%, would anyone really believe that anyway? But what does that have to do with OO? I never believed that OO would solve everything, but it DOES solve a lot of problems, such as maintainability & rapid analysis/development.
You also seem to imply that OO somehow stops us using standards - this is plainly silly. I would have to say that OO, with it's concepts of interfaces, inheritance and modularity does more to encourage standards than any other paradigm (except maybe formal programming - Z, B and their kin).
The fact is that applications these days do MORE. And they have been developed more QUICKLY. And, in my personal experience of large-scale financial systems, they are more reliable and cost FAR less in terms of time & manpower to maintain. This has been brought about by lots of things, standards is one, OO is another. It's not an either-or situation...we can have the best of all worlds!
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
This is incorrect. As reported on use Perl :-) you can use standard perl 5.6.0 if ActivePerl is unavailable for your platform. I guess that means that if you use Linux for x86, you need to use ActivePerl; but who is gonna know if you don't, and just use perl 5.6.0? They are the same thing.
Personally, I don't buy the point about a standardized language being more accepted. The C and C++ standardization committees both probably started during the crest of their languages popularity. (Since C++'s prototypes got back ported to the C standard, you can tell they new they had to keep up with this competitor. And by the time C++ was standardized, all the hype had moved to Java.)
The point I agree with more, is that so much of what the language does is undocumented or ambiguously documented, you really have no way to ensure that your program will work in any future version of perl. (and can only guess if it works in past versions by testing.)
When a report of a change of behavior between the current version of perl and a previous version comes to the perl5porters, pretty much the first step (although the step can be implied at times.) is to decide on an adhoc basis the definition of the language. Sometimes they can use historical precedent to prove one implementation over another. Sometimes they use vague philisophical notions of what the "perlish" way to do it would be. Sometimes the arguments seem to consist of people quoting contradictory entries from lwall-quotes file.
Of course, standardation is antithetical to the current perl development model. Its enshrined in their "Rule Number One", and "Rule Number Two". (#1 is "Larry is alway right". #2 is "Larry is right even when he changes his mind" or "Don't try to use Rule Number One against Larry".)
His answer was, "sometimes when you are a missionary, you have to go out to the heathens"
The best way to study the way perl executes a script is to build a special "-DDEBUGGING" version of perl and run short test program with the "-D14" switch.
It would seem to me that comparing the two is stupid in and of itself. They were made for different purposes.
A bar bet? Feed me details - this is one of my current favorite constructs, and if beer and gambling was involved, so much the better.
This is the voice of World Control. I bring you Peace.
Well, I'm glad the interview was thought provoking, even if people don't agree with Larry.
He seems like a smart cookie with Perl's best interests at heart.
Hey, they have standards committees for a reason, I guess.
I have to think P5P will not like this thread of conversation. :-)
This is a completely stupid overgeneralization. VB is great at rapid prototyping of visual apps, and Perl sucks big at it.
Case and point no one cares about perl. Just look how many people have posted to this article. 'whew' I can relax, I think I might still have a job after the year is over. Or if VP++ takes of and I lose my job to someone who can read an O'Reilly book is
True, we are all gonna die...
"It takes many nails to build a crib, but one screw to fill it."
Yes, we definately need to start teaching Perl in CS classes. Specially as a example of scalable, self documenting language.
Perl is sys admins tool and that's where it should stay.
True, we are all gonna die...
"It takes many nails to build a crib, but one screw to fill it."
Right here.
It really is a nice construct though. I am a big fan of anonymous functions. For instance you need to emit errors from a module that will be used various places for various things. Have a package variable with an error sub, by default "croak" but overrideable. That is fine for development and interactive scripts. Now if someone wants to use that in a cron, they can replace your croaks with a routine to page someone before dying...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
LR: Why not? Perl is superior to Visual Basic in every way imaginable.
Maybe a push from Microsoft will help overcome the barrier of acceptability that I focused on above.
ActiveState's support of Perl has been increasingly bothering me other the last 12 months... am I just being paranoid?
ActiveState's work in bringing Perl to Win32, and supporting OLE effectively, has been a very important piece of work (and done very well to). But having achieved that, they now seem to moving towards the embrace, extend, extinguish paradigm that some might have noticed from a certain other company.
For instance:
- Packages are distributed in PPM format, which as far as I can see are quite separated from the CPAN model which has been so effective for the Perl community
- The Perl Power Contest (sponsored by ActiveState) requires the use of ActivePerl, rather than encouraging generic Perl solutions
- With Gurusamy Sarathy (of ActiveState) looking after the Perl 5.6 release (and doing a great job, I might add), the 'official' binaries for both Win32 and Linux are now ActivePerl packages
- They are partnering with M$oft in many projects. This just makes me uneasy, given M$'s history.
I don't mean to put down the many good things ActiveState has done... But I do feel that the Perl community should be a little cautious about being pulled along by them. Other than the flexibility and power of the language, the things I most like about Perl are:- Scripts I write will run on almost any platform I come across, as long as I avoid direct system calls and avoid assumptions about file system structure
- I know that if a problem has been tackled in Perl, it's solution will be available on CPAN. And furthermore, I know that I can use the CPAN module to install it with just one command.
It seems to me that it would be all too easy to lose these benefits if the MS/ActiveState version of Perl forks much more from 'normal' Perl, and if ActiveState develops its own community around PPM rather than using CPAN.I thought this rather strange to be honest.
Is there really any need now to concentrate on optimising each instruction? As somebody who learnt to program using 68k, i remember doing this well, reducing mulu #40,d0 to a number of shifts and adds. ( moveq #0,d0 is quicker than clr.l d0 etc etc )
Times have moved on however, and that "count-the-raster-lines" performance is something thats just not required nowadays, at least not in the programming domain we are talking about.
That kind of "instruction optimisation" is really the last resort, after the much more important algorithm optimisation, which generally tends to produce far greater benefit.
Even if you hand code your bubble sort in the best assembler ever, its still not going to be quicker for large datasets than a moderately badly written quicksort.
Having never had to use an object in a program ever, I wonder if Mr. Rosler unnecessarily limits himself. Although relatively new to the concept, and long time assembler / C programmer, I am beginning to see that the OO approach has many benefits, not least ease of reuse.
I agree that for pure speed, OO can lack somewhat, as the cost of object instantiation / method execution is not immediately apparent, and for that reason you can write code that works much more slowly than you think it might, but its a balance.
Funny enough, there was a big debate over a year ago on whether you should use $|++ rather than $| = 1. Turns out that most people agreed you shouldn't. It's probably on deja.com somewhere, but I'm too tired to look for it.
Don't use one hammer but educate yourself to be able to use the appropriate tools for the job at hand.
I agree entirely. Each language and, indeed, programming methodology, was created with a particular problem space in mind. Using each for what it does best is not a bad idea. I've programmed in BASIC (remember when it was an acronym, and needed to be capitalized?), assembler, C, Java, and a host of smaller, niche languages. Each did its job well enough.
In my previous post, I wasn't saying that I've never used OO. I was simply saying that I never encountered the problem space for which OO is the most correct solution. I'd begun to doubt the existence of that problem space, and this interview helped me to realize that I wasn't the only one. I'd thought I wasn't seeing this huge elephant that the rest of the world sees standing right in front of me. But, apparently, either I'm not the only blind one, or the elephant isn't as large as it's been made out to be.
-Joe
I agree that the languages may have been standardized at their peak of popularity (popularity being media coverage, general press, and book publication), but I don't think they had as wide of use until after standardization. Larry is right in that most Banks, Corporations, and Governement Agencies are bound by their bylaws and operating codes to not use a "flash in the pan" system. How the heck do you think that Fortran and Cobol and even PL1 and Ada have survived for so long? Sure, it has something to do with keeping up legacy systems, but it also has to do with the fact that there was no standardized language to turn to when those systems were still young and could be more easily replaced.
While standardization may violate Perl Rules One and Two, it would be better for the language in the long run, especially in terms of documenting just how the thing works.
Microsoft Fried Chicken... it ain't chicken anymore
I could see if there was GPerl, and SunPerl and IBMPerl, and HPPerl.. but there really is only one person so isn't that the standard?
Hmm.. oh well. If it makes people stop using system calls in perl scrips I'll be happy.. I especially like the 'script' ne 'program' part. Jon++
And why the hell are the first 5-10 posts always flamebait/trolls/offtopic?
nerdfarm.org
Dacels Jewelers can't be trusted.
Rosler is not an object oriented trailblazer, nor is he out to prevent good innovation. Instead, he supports good languages that help do useful things.
I've worked on massive multi-platform efforts at Oracle, and have to say that C is a great language for this. It is extremely compatible across platforms.
Perl, although supporting some object behaviour, is capable of anything Rosler has needed from it. He (and many others) don't need heirarchy to write a simple web app, nor to format / translate data.
Already, Perl has helped solve many simple development issues where I have worked. Although there is a cutting edge of enhanced Perl, the current 5.xxx library is quite mature. For tasks that don't require threading etc... simply use the tried and true Perl.
just my 5x10^10 rubles
COME ON PEOPLE WE NEED TO KEEP THINKING JOB SECURITY!!!
I also think it's funny that Visual Perl is coming out... Who wants to bet it will be called VP++ because of all the M$^%t add ons, doesn't anyone remember what happened with VJ++? Jscript was the only microsoft clone of a language that actually provides cool functionality.
True, we are all gonna die...
"It takes many nails to build a crib, but one screw to fill it."
Perhaps it is the ultimate fate of perl to encompass all standards, making it the single most standard development language! ;)
Geeky modern art T-shirts
is the best thing that could happen to Microsoft. With Win32-API and Win32-GUI both working nicely the OS is much more accessible and programmable. When Microsoft starts shipping Perl as a part of their standard distribution Perl will hit desktops worldwide and its usage will probably increase by an order of magnitude, Win-Win. (Dave Grove may have a heart attack though, Hi Dave! :-))
Just another perl hacker in Bangkok
Many organizations either cannot or will not endorse the use of unstandardized languages in their business-critical activities.
Some need an ISO or ANSI seal of approval on their tools. This is probably mostly CYA but that's life.
Just another perl hacker in Bangkok
I'm reminded of a quote I found when I started fencing:
Your education as a programmer is always incomplete, that's part of the fun :-)
An excellent article by a man who obviously calls 'em as he sees 'em. The OO paradigm promised to save the world of software engineering from bugs, complexity, and maintenance difficulties, but if the last 5 or 6 years are to be considered as indicators for future performance, it's not worth the hype. Although Perl is often accused of having a "bolted-on" OO interface, the base language is stable, supported, and widely used. Standards will only help to push its acceptance with the suits.
:) In my experience, Perl does just that.
/dev/null and let the language holy wars begin!
Personally, I'd prefer to rely upon a language that delivers on the promise of "write once, run anywhere"
Flames to
It is called Larry Wall.
Yeah, that was a very interesting remark. I'm an old C programmer also and can see where he's coming from. When you're coding right in C the useful part of object orientation shows up anyway. Its just the deep structure showing up. :-)
Perl makes it very easy to pop something into a module if you want to without enforcing structure like a prothesis, like you're an old man using a walker or something.
Just another perl hacker in Bangkok
Getting offtopic, I would like to congratulate BSDi on their plans to bring Java 2 to FreeBSD. After a year of pestering Sun about this, and a few months of bothering IBM, FreeBSD will finally get the Java support it deserves. After the BSDi purchase of Walnut Creek, I often said that perhaps BSDi would put more "corporate" pressure on Sun to release JDK1.2 for FreeBSD, but this is a most unlooked-for and welcome development.
(Now if only they would lower the BSDCon prices... )
And re: "Perl Language Subcommittee" -- I thought that Larry, Randall, and Tom were the committee. ;-)
---------///----------
--
I like to watch.
Yeah, that's real elitest of you. Just forget about the benefits of good OO design, and label the people that didn't as brainwashed.
You'll make all sorts of 0x7a69 friends doing that, eh?
I think it would be useful to standardize at least a subset of Perl. The syntax is a non-issue, I think; after all, Perl does have a parser. For the semantics, most of it boils down to numbers and strings (and POSIX). Regular expressions are a mess. Maybe pragmas, too.
I think we should keep in mind this part of the Perl FAQ.
... or was it "patent the business plan/idea"?
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Ilya was extremely talented person, yet the arrogant and mean SOB. It's to bad he left PERL. It's great he left PERL Whatever ... I'm using Perl a lot, yet its kitchen-sink like syntax constanly annoys me. What Perl needs at this point is stabilization and consolidation. But the fact is that Perl is here to stay, exactly because it is PRACTICAL, and has reached a critical mass in many respects.
I find that the "if all you have is a hammer, every problem looks like a nail" effect is particularly rampant in Java... everything looks like an object, even things that could be better expressed as something other than an object.
There's a good thread on this topic over a PerlMonks. Just do a search on "Visual Perl and ActiveState". Its not very long, but interesting to see what the day-to-day users have to say about this.
Jason
The ANSI Perl standard recognizes that "there's more than 1 way to do it." Specifically, the standard outlines 123 ways to do it -- see appendix c. Additional methods are "implementation defined."
--Shoeboy
(former microserf)
Wow. You know, in all the software I've written, I've never thought at that low a level. Maybe I should?
I use Macs for work, Linux for education, and Windows for cardplaying.
Good move too, IMO. Anything proprietory will be in the plug-in, ActiveState will own it and why bother to open source the code? They might open the API so people can add cool stuff but plug-ins to Visual Studio are so abundant (30 or so things in there I have no idea what they do) its evident that rocket science it ain't and I'm not sure why you'd bother. :-)) :-)). Stuff like that.
Documentation will be better and newless cluebies won't be posting I clicked on my program but the box closed so fast I donno what happen please help me type questions. Perl doesn't have a GUI, this will do it.
I want a menu item to search for modules and there could be an Active Update, heheheehe check ActiveState for new versions of any modules every time I boot up.
Biggest impact may be a large upsurge in background programs on Win32 doing housekeeping, updating personal news pages, instant flame response forms if someone happens to mention Python on slashdot
Just another perl hacker in Bangkok
Written any assembler?
I've regressed to my childhood and tend to look at $_ as the accumulator and hashes as infinite named registers.
Course when you do what Larry is talking about it starts to look like line noise but runs like a champ.
Just another perl hacker in Bangkok
embrace, extend, extinguish How?
Perl ain't Kerberos. (how many of you heard of Kerberos before that blew up, raise hands). And micro~1 isn't doing the work. AS is. That's just enough of a difference to make a difference.
For Microsoft to screw around in the (AS) core distro they actually need a reason (any reason, some kind of rationale) to 'extend' and I don't really see one. They want a paperclip? use Win32::API; Something else? XS and make a dll. The Extend may, in fact, go in the other direction, hacking the OS to accomodate Perl and minimizing the differences. We know have a fork(). Alarm, anyone?
Anybody with a solid idea of how to embrace, extend, extinguish please bring it out. I haven't heard much but flaming vapor.
Just another perl hacker in Bangkok
Things were were always better in the old days, weren't they?
What you have is a gut feeling that things used to be better because you only remember the good stuff. You remember how great Wing Commander was while forgetting that it took you 3 hours to figure out the config.sys and autoexec.bat for the boot disk.
Now, the specific time frame being discussed is 5-6 years. Would you rather use Windows 95? As for unix, would you rather use SunOS? I remember some epic battles with xf86config under Linux. Was Netscape 1.1 really less buggy than Netscape 4.7?
pornking
The point is, you realize how bad your code really is ;) Hopefully, it will make you a better programmer, even if you very rarely use assembly.
Oh yeah, and the line noise code, well let's just say it can win you prizes (see: Obfuscated Perl Contest, and the IOCCC). Not that I'm encouraging this or anything.
Jeff
internet business paradigm: ship the business plan!
Jason
His parting message.
Sad. But he and Tom C had one too many flamewars and he has left.
Incidentally Perl has a standard. It is the documentation. The cause of said flamewars is that Tom considers the documentation a standard and Ilya constantly wanted to play around with new features, add new constructs, etc.
Cheers,
Ben
PS Trivia. If $a is an anonymous subroutine then $a->(@args) calls the subroutine with those arguments. This is very useful because $handler{$foo}->($bar) is far cleaner and more understandable than &{$handler{$foo}}($bar). OTOH I am amused that such a nice feature got included in Perl on a bar bet...
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Agreed, if you've never worked with assembly before, your education as a programmer is incomplete.
;)
Of course, if you're going to be doing it for a living you'd better make sure your company has a good vision plan. You're going to be needing a new pair of glasses every couple of weeks