Perl And Standards: Larry Rosler Interview 74
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?"
Re:Perl Standards (Score:5)
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.
Re:The push from Microsoft (Score:1)
It was great, tough a little superficial, but I now have about 5 other perl books on my bookshelf, so there you go.
Be careful what you wish for... (Score:1)
Why Perl would benefit from a standard (Score:5)
Re:Perl Standards (Score:1)
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!
Re:ActiveState--good for Perl... or not? (Score:2)
This is incorrect. As reported on use Perl [perl.org] :-) 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.
Re:Isn't perl already standardized? (Score:1)
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".)
Re:ActiveState--good for Perl... or not? (Score:1)
His answer was, "sometimes when you are a missionary, you have to go out to the heathens"
Best way to study perl opcodes (Score:1)
Should you eve compare the two? (Score:1)
Re:Sadly Ilya has retired (Score:1)
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.
Garsh, I'm on slashdot! (Score:2)
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. :-)
Perl & VB (Score:5)
This is a completely stupid overgeneralization. VB is great at rapid prototyping of visual apps, and Perl sucks big at it.
Does anyone care about Perl? (Score:1)
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...
Re:The push from Microsoft (Score:1)
Perl is sys admins tool and that's where it should stay.
Re:This guy is so prejudice! (Score:1)
True, we are all gonna die...
Re:Garsh, I'm on slashdot! (Score:2)
All the details I have... (Score:2)
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
ActiveState--good for Perl... or not? (Score:3)
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 [yapc.org] (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.Re:my favorite quote: (Score:1)
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.
Re:Why Perl would benefit from a standard (Score:2)
Volunteers?
Re:No need to standardize (Score:1)
Re:Why Perl would benefit from a standard (Score:1)
Re:Perl Standards (Score:2)
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
Re:Isn't perl already standardized? (Score:1)
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.
Re:Perl & VB (Score:1)
Re:No need to standardize (Score:1)
Re:Perl & VB (Score:1)
This simply depends on how you define superiority. Perl is nice for some jobs, VB for some others.
Though I have to admit that I cannot imagine any job I would prefer VB to perl.
For GUI prototyping with perl I would give a shot with Glade [pn.org] - last time I checked it was far from perfect but it's developing pretty fast.
_________________________
Re:Why Perl would benefit from a standard (Score:2)
Well, it seems like your group would be best placed to provide material and consultation for this standard's work.
You have developed some kind of syntax diagrams or parsing tables or something for your work, haven't you?
When you say you are concerned with breaking Perl 5 code, does that include modules interfaced with XS? If not, I'm very concerned that there will be a danger of fracturing the Perl community, with people dependent on Modules that only work with Perl 5 and those who move to Perl 6.
-Jordan Henderson
Isn't perl already standardized? (Score:3)
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 [nerdfarm.org]
Larry Rosler understands niche languages - kudos! (Score:2)
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
No need to standardize (Score:4)
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...
Re:No need to standardize (Score:1)
brutal news [brutal.com] = bad news from around the network
Re:Perl standards (Score:2)
The push from Microsoft (Score:4)
No, its just standard? (Score:1)
Some need an ISO or ANSI seal of approval on their tools. This is probably mostly CYA but that's life.
Re:No need to standardize (Score:3)
I wonder if this just entails the things that facilitate using the IDE (e.g. syntax highlighting, debugging, etc.), or proprietary code modules ala MFC (Microsoft Fried Chicken?). I further wonder if the guts of this big Visual Studio plug-in will themselves be open-source, or will they be grabbed by Microsoft. The arrangement is not terrifically clear if you just read the press release.
Does anybody know the end game here?
-L
Re:Op Codes! Hell Yeah! (Score:1)
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 :-)
Perl Standards (Score:4)
Personally, I'd prefer to rely upon a language that delivers on the promise of "write once, run anywhere"
Flames to
There is a perl standard (Score:4)
It is called Larry Wall.
Objects (Score:1)
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.
Re:Perl Standards (Score:2)
Re:Perl Standards (Score:1)
Sun and Java standardization (Score:2)
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. ;-)
---------///----------
Re:This guy is so prejudice! (Score:1)
You'll make all sorts of 0x7a69 friends doing that, eh?
Standardize a Perl subset (Score:1)
Remember the FAQ (Score:1)
Re:to add another one... (Score:1)
Re:Sadly Ilya has retired (Score:1)
Java Hammer (Score:1)
Re:Perl & VB (Score:2)
In fact, I can design a UI and do my prototyping using Perl, but because the GUI is managed by Glade as XML files, I can then move over to C, C++, ADA or guile fairly easily. I still have to re-write my code, but all the UI gunk is language independant. This means that you can hire UI people who don't even know the language you are writing your core system in!
The next tool that we need is a program that makes tying your UI to your back-end through CORBA simple. It will have to be as simple to use as glade (perhaps even a glade plugin). Then we can have applications where the two are developed in different languages and stay that way....
More on this at Perlmonks. (Score:1)
Re:Perl Standards (Score:1)
Add me to the old fart list. I have come to the conclusion that OO is a religion. Either you have faith or you don't, but you can't prove to someone that s/he should believe.
There are a lot of rational arguments for OO, including reduced life-cycle costs, reduced cost of enhancement and extension, improved modularization and thereby lower integration cost. Unfortunately, I have never--despite a lot of looking--found any quantitative data to justify OO. Instead I have seen projects that take longer to generate slower, bigger code than analagous projects using a structured design and development approach. I haven't seen a payoff in life-cycle costs either.
C++ is just hard compared to C. Java allows me to be pretty productive, particularly for UIs. In both cases it seems to be the language, not the methodology.
Put me down for Fortran, C, Java, Perl, JavaScript, and HTML. Skip the C++ and Ada, hold the OO Perl.
Re:Isn't perl already standardized? (Score:1)
Or look at it this way, according to an old copy of "Design and Evolution of C++", Borland was the largest producers of C++ compilers, and they had shipped 500,000 units by October 1991. And that would be just the year after the C standard was ratified.
For C++ and Java though, you may be right. I just through that in to imply a trend. In actuality, I don't think Java is taking away projects from C++. Each one is suited for jobs the other is not. (At hte most, Java is being used for jobs that would have, but shouldn't have, been written in C++).
Also, I find your mention of Ada as a "legacy language" interesting, since it is a fairly recent language. Not at all in the category of Fortran or Cobol.I think that Ada is something that has its place, mostly for someone wanting an excplicitly standardized language. (A company can't call itself Ada until it passes the conformance tests.)
Re:No need to standardize (Score:3)
evaporating standards (Score:5)
Jason
The inevitable result of perl standardization... (Score:4)
--Shoeboy
(former microserf)
my favorite quote: (Score:1)
Wow. You know, in all the software I've written, I've never thought at that low a level. Maybe I should?
Re:No need to standardize (Score:1)
:)
micro~1 is paying for it (Score:2)
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
Op Codes! (Score:1)
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.
Re:ActiveState--good for Perl... or not? (Score:3)
Personally, I don't lose too much sleep over ActiveState. The Perl community has always been very vocal and pro-Unix. If ActiveState wants to provide and support Perl binaries, more power to them. Though they employ several Perl developers, if they were to fork, they wouldn't be able to maintain the huge beast without the support of the community, and p5p would happily leave them behind.
Microsoft is interested in Perl for several reasons:
- VB sucks, and they know it. It may be easy to write code, but serious programmers don't like it. (Microsoft, which employs a surprisingly large number of programmers, is acutely aware of this.) Microsoft wants to position Perl as a supplement for VB. They could integrate it with IE if/when Mozilla does the same. They won't do this until they need to, because VB is a great way of getting people to create web sites that only work with IE, but they don't want to be caught off-guard when people start scripting sites in Perl and thus requiring Mozilla.
- There are a large number of COTS and free software CGI scripts written in Perl. Many IIS sites would benefit from them. (They already do, but more Win32:: modules wouldn't hurt.)
- Microsoft always wants more people coding in a language that works on their OSs. Not having Perl on Win32 would really hurt them for this reason.
If Microsoft ever really wanted to EEE Perl, they wouldn't be subtle about it. They could easily buy ActiveState. But it really isn't worth it to them: Perl has a strong community organized around a single open source interpreter, and very few people are writing cross-platform applications with a scripting language. (They were afraid of Java not only for this reason, but also because it was tied to Sun.) Perl isn't a threat to Microsoft.Re:The push from Microsoft (Score:1)
yes..but imagine the PR when some luser writes a virus in perl to attack win32, beacuse you know Open Source is inherently insecure(*snicker*) Maybe then the linux users would have a worry (<ducks>)
*Not a Sermon, Just a Thought
*/
Re:Perl Standards (Score:1)
Unfortunately, you prove my point here. There is no "silver bullet" which will solve all of the problems and challenges of software engineering. The idea that sold people on OO was one of re-use and less complexity. The lesson that the industry should learn from this experience is that a paradig-shift is no substitute for engineering standards and quality-control. What good is a feature if it fails 1 time out of four?
OOP, componenent architectures, and open source are snakeoil solutions to a problem that begs for standardization and structure. They have their uses but not one of the group can be called the messiah of computer science. Standards are good.
Beware software "artists"! The honeymoon is almost over for us...
I think you're too paranoid (Score:1)
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.
Re:Why Perl would benefit from a standard (Score:2)
When I was a youngun... (Score:4)
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?
Re:No need to standardize (Score:2)
There is nothing easier than writing perl code that only YOU can understand. Even if it is perfectly documented.
Re:Perl Standards (Score:4)
Exactly, you just found another guy who missed the boat. This guy is smart enough to not completely dismiss python and java as useless but from the interview it is quite clear that you won't find him programming in either language (to put it mildly).
For me OO is also something of the past. But at least I'm not stuck in the procedural/machine oriented paradigm of thirty years ago (when OO was the hot new thing). Personally, I find modern ideas such as aspect oriented programming, subject oriented programming or even intentional programming much more interesting.
Perl is interesting in that sense because it is probably flexible enough to extend it to support either of those. On the other hand its syntax will probably always be a major obstacle for any serious adoption. Also performance is an issue (more than in Java) if you start doing serious development.
Java at the moment is a much more mature language, perhaps due to the rigorous control of SUN over it. However, I think institutions like ISO mover too slow to keep up with the rapid developments. A standardized version of Java of three years ago would be close to useless to me. I suspect the same goes for perl. Like it or not, SUNs control of the Java language has prevented fragmentation and effectively caused it to be an industry standard with support for a large number of platforms.
Finally a wise quote:
"When you have a hammer, every problem seems a nail"
I think this applies equally to either perl, vb, c(++), java, fill in you're favorite language. When developing device drivers stay away from visual basic. When developing e-commerce websites: don't bother using c. Also beware that languages and their accompanying libraries are under development. Two years ago Java was not good to do anything, now it is rapidly becoming the language of choice for number of domains (most notably web development).
Don't use one hammer but educate yourself to be able to use the appropriate tools for the job at hand.
Re:Op Codes! Hell Yeah! (Score:2)
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
to add another one... (Score:1)
Jason
Sadly Ilya has retired (Score:2)
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...
Re:Perl Standards (Score:1)
Reading that interview's brief discussion of object-oriented programming made me feel really good. I thought I was completely missing the boat on that stuff. I mean, I can see how it makes for esthetically pleasing designs on some level, but try as I might, I couldn't find a reason to stop doing things the way I always have. Maybe I still am missing the boat on OO, but at least I'm in good company. =)
-Joe
Re:Op Codes! Hell Yeah! (Score:1)
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