[ruby-talk:03214] FYI: Interview with Larry Rosler (who helped standardize ANSI C) about Perl.

Hi,

This is another in a series of occasional items about what our Perl and
Python friends are up to, which may be of interest to other Ruby fans. (Know
thyself--then know thy competition. :-)

The article below is from http://www.perl.com the primary Perl website.

(Incidentally www.perl.com carries a weekly P5P Digest, which summarizes the
previous week's discussions of the Perl5 Porters--who are really the Perl5
Developers. Over an extended period of time, this digest provides a useful
and informative window on a wide range of Perl5 language feature
implementation issues (plus some complicating human factors issues), some of
which may have relevance for Ruby. It is also a sobering reminder of just
how complex the business of designing and implementing a growing programming
language is, and should give you a much greater appreciation for what Matz
has been accomplishing.)

Conrad

============================================

Interview with HP's Larry Rosler by Joe Johnston
June 6, 2000

Larry Rosler was both editor of the draft standard and chairman of the
Language Subcommittee for X3J11. He helped put 'ANSI' in front of C. He is
also just another Perl hacker. Larry recently took time out of his busy
schedule to share his thoughts on the value of standards, how Sun ought to
handle Java and optimizing Perl code.

What's your background? How did you get interested in computers?

LR: My formal education was in physics, and my primary research interest was
experimental nuclear physics. However, I soon discovered that I was more
interested in the equipment used to gather and analyze the data than in the
data themselves. The equipment was essentially digital computers, but there
were no degrees in computer science in those days.

In my first major job, with Bell Labs in New Jersey, I worked on a variety
of solid-state devices. I discovered that simulation could be more effective
than analysis of physical modules. When others began to use the programs I
wrote, I realized that my greatest professional satisfaction would be as a
software 'toolmaker'.

As a result, I switched to building tools such as graphical design
terminals, and then focused on computer languages and libraries.

I was taught by several "hardware" guys who got into programming somewhat
reluctantly. Do you feel that novice programmers lose an important
perspective without knowing what goes on under the hood?

LR: I taught the first course in C at Bell Labs, using a draft of K&R, which
helped vet the exercises. The students were "hardware" engineers who were
being induced to learn programming. They found C (which is 'portable
assembly language') much to their liking. Essentials such as pointers are
very clear if you have a machine model in mind.

Perl is at a higher level of abstraction, so the machine model isn't as
necessary *at first*. But when you get to complex data structures, which
require references, which are like pointers in C, a grounding in addressing
becomes useful.

In an ideal world, a student would first learn an abstract assembly language
such as MIX (See Knuth, Vol. 1), do some useful exercises, then take on a
higher-level language with the machine model in the back of the head.

When did you run into Perl? What did you think of the language the first
time you saw it?

LR: I am a relative latecomer to Perl. I was experimenting with CGI
programming using shell scripts (!) because they were better for rapid
prototyping than C, with which I was most expert. Soon I discovered that
Perl offered similar advantages as the shell, but was much more expressive
(particular in the manipulation of data structures) and much faster to
execute (because of execution after compilation, instead of interpretation).

Because of my extensive use of Unix commands such as 'sed', which made heavy
use of regular expressions, and because of my C experience, I was quite
comfortable with Perl syntax. The hardest adjustment was to learn to write
code with as few Perl operations as possible, because of the costs of
dispatching each instruction. The Benchmark module became the most important
tool I used to learn how to write efficient (and hence, sometimes elegant)
Perl.

Often Perl claims to be efficient in the scarce resource of the programmer's
time. It isn't often that people tune scripts for optimum performance. Are
there a few tips you can give to new Perl programmers on how squeak out a
little better runtime performance?

LR: 'Script' ne 'program' again. When dealing with upward-scalable data
sets, performance becomes important.

I proposed a tutorial to Perl Conference 4.0 this year on this subject, but
unfortunately it wasn't accepted.

0. Don't optimize prematurely!
1. Don't use an external command where Perl can do a task internally.
2. Refine the data structures and algorithms. References: The Practice of
Programming (Kernighan and Pike), Programming Pearls (Bentley), Algorithms
with Perl (Orwant et al).
3. After these are optimal, identify the remaining hot spots. (Judicious use
of the time() and times() functions, or the Benchmark module.)
4. Try to improve the hot spots by using perl functions such as map() and
grep() instead of explicit loops; making regexes more explicit to minimize
backtracking; caching intermediate results to avoid unnecessary
recalculation, ...
What's your favorite part of programming? Design or implementation (or
other)?

LR: Happy users.

I understand you were the Chairman of the ANSI C committee. How did that
come about?

LR: Not the chairman -- that was primarily an administrative function, and
what I did was more technical. I was the chairman of one of the three major
subcommittees (language; the others were library and environment), and --
most important -- I was the editor of the Draft Standard. The hand that
holds the pen controls the direction of the work and the results. :-)

This all happened because at Bell Labs I was one of the managers of the
effort to turn C from a research vehicle to a commercially useful language,
which began with internal standardization. Because of the demands of some
major users, such as the US Government, commercialization required the
development of a formal standard. My colleague Dennis Ritchie (who created
C) didn't want to participate personally, but he was always active behind
the scenes in reviewing and improving my efforts. He was quite satisfied
with the final results.

A few years later, now working at Hewlett-Packard, I found myself in the
same position regarding C++. I persuaded Bjarne Stroustrup, the creator of
C++, to support standardization, as a prerequisite for successful
commercialization. He agreed, and took a very active role.

There's certainly no ANSI Perl. Does Perl need the same kind of official
standardization that C got?

LR: I believe that it does, in order to increase its acceptability. Many
organizations either cannot or will not endorse the use of unstandardized
languages in their business-critical activities.

The current situation with Perl is better than it was with the other two
languages I mentioned. Perl has one official open source for its
implementation, whereas the others had multiple proprietary implementations,
leading to different semantics for many language features. But this single
'official' Perl semantics has never been adequately characterized
independent of the implementation, so is subject to arbitrary change.

Building on quicksand is acceptable for 'scripts' of limited longevity and
applicability. It is not acceptable for 'programs' of significant commercial
value. I think the lack of a firm, stable, well-defined foundation is the
major inhibitor for the continuing commercial evolution of Perl. Of the
major contributors to Perl, Ilya Zakharevitch is most outspoken in his view
that Perl is not (yet?) a 'programming' language!

Many of the people who contribute their efforts to the Perl community are
interested in adding features, perhaps to overflowing. More people should
devote their attention to firming up the semantics and making sure that the
implementation conforms to those semantics, rather than the other way
around.

Your point is well taken about focusing future Perl development on producing
consistent semantics. I'm a bit surprised that you see this as a barrier to
greater Perl acceptance. Some might suggest the interpretive nature of the
language is a greater barrier ("Why can't I get a hello.pl.exe?").
Or point to Perl's endearingly unique syntax.
Or to Perl's charmingly permissive OO implementation.
Are there particular areas of Perl's semantics in which the inconsistencies
are glaring?

LR: I am less concerned about individual programmers' decisions for their
own projects and more concerned about major corporations or government
agencies that reject Perl because of lack of formal support and lack of
standardization.

An example of excellent work that is long overdue is Ilya Zakharevich's
document 'perlnumber', new in Perl 5.6.0, which specifies for the first time
the semantics of Perl's string-to-number conversions.

I'm curious how one would standardize Perl when the language changes so
quickly and committees move so slowly. Consider than three years ago, Perl
was not threaded. Now, threads are standard, but their interface may change
in the near future. Mr. Zakharevich continues to pull new regex constructs
from head of Zeus. Even more striking, Perl supports unicode. Is there some
way to stage the standardization so that it isn't painfully out-of-date?
Would standardization necessarily slow down perl development?

LR: Sometimes standardization speeds up development, by forcing evaluation
and convergence on a specified way of doing things. Sometimes features are
characterized and implemented during standardization (wide-character types
for C, for example; the Standard Template Library and many other features
for C++).

One way to view it is re Samuel Johnson's famous mot: "When a man knows he
is to be hanged in a fortnight, it concentrates his mind wonderfully."

Are you following the debate amongst programmers who favor Sun lessening
their control over Java (especially after Sun withdrew it from the
independent standardization process)? Do you feel Java might benefit from a
more open/chaotic development model (ala Perl), should it follow the C path
of getting independent standardization or is Sun doing the best thing for
the language by keeping it "in-house"?

LR: My prejudice should be clear from what I have already written. AT&T
handed control over C and C++ to ANSI/ISO technical committees, while
keeping an active leadership role to ensure that the goals of the
originators of the languages were met. Sun should do the same.

On the other hand, Microsoft's desire to 'embrace and extend' Java should be
doomed by standardization, just as they failed to subvert the target
independence of C and C++.

My understanding is that Microsoft is 'embracing' ActiveState's Perl. They
will be shipping Perl with their "Services for UNIX 2.0". Do you see any
chance for Perl to compete on a Windows Platform as a replacement for Visual
Basic? In particular, as application "glue"?

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.

Back to Java for a moment. Because they are both "web technologies", Perl
and Java are often seen as competitors. There have been attempts, like Larry
Wall's JPL, to provide better integration between these two beasties. What
sort of utility do you see in such a marriage?

LR: Hard for me to say. Java forces OO programming from the beginning, and I
have never needed to write an object in any program. This may be for me a
conceptual hurdle that I cannot (and need not) overcome.

C++ provides sweetened C syntax and semantics (particularly toward bits and
bytes), and OO if you want it. This can all be done with the efficiency of
C.

Perl provides higher-level syntax and semantics (particularly toward
strings), and OO if you want it. I know how to write efficient Perl when I
have to.

Java, in my opinion, fills a much-needed gap between those two approaches.
:-)

Speaking of competitors, Python is making a big splash this year. Although
it seems to satisfy many of the same itches Perl does, its proponents point
to its cleaner syntax and more tradition OO implementation as making it a
"better Perl". What are your thoughts on Python?

LR: Whatever improvements Python may offer are not sufficient to give it a
critical mass of programmers and programming support relative to Perl. There
is an order-of-magnitude difference in this metric (programmers, modules,
books, ...), and I don't think significant inroads are being made. And, as I
said, to me OO is a big yawner.

What five people would you like to see learn Perl?

LR: Hah! People are now trying to convince me to move on to Python. :-)

Have you had the chance to read Mr. Conway's _Object Oriented Perl_? I found
I learned more about general Perl from it than OO techniques (which by no
means is to say book is inadequate in the latter department).

LR: Yes, I have gotten to about the middle of it. It is a fine book. But it
still didn't convince me about the necessity of objects. All I see is the
performance-damaging complexity of the interfaces.

How much longer do you see the "Internet Goldrush" continuing?

LR: Judging by the recent performance of the NASDAQ, it may be over already.

You presented a paper at TPC on efficient sorting with Uri Guttman, a fellow
Boston Perl Monger. How did you two meet?

LR: We met in comp.lang.perl.misc in March 1998 (soon after I began to post
questions to the newsgroup). Uri educated me on 'hash slices', which he
eventually turned into a tutorial. That July, I spotted his and his wife's
names in the credits at the end of a movie, which exposed a common interest
(in Jews and Buddhism, to be specific :-). We met for the first time at TPC2
in San Jose that August.

The paper on sorting was developed entirely by email. The next time we met
in person was (with Damian Conway and respective wives) at TPC3 in Monterey.
We will probably meet again there at TPC4 this summer.

Do you have any tips for new programmers dealing with management?

LR: Agree with your management on useful metrics for progress and
completion. Never report that your code is 90% complete, 90 days from
completion, because that tends to be a steady-state description.

Never estimate more than about half your time actually working on the
project, because other things will always happen.

Has this rapid web development trampled on software quality control
irreparably?

LR: Not only the web -- Micro$..t. Imagine the world tolerating an
environment with the dismal quality of Windows? At least nothing that a
browser can glean from the Web is likely to produce the Blue Screen of
Death!

Since you've in the business for a respectable number of years, what are
your five biggest pet peeves about programming?

LR: That's a toughie. How about four, in no particular order:

Extracting from the potential user a complete and useful specification of a
problem.
Coping with buggy or inadequately documented tools.
Keeping things functioning as operating environments evolve. (No one wants
anything to change except the things that that person wants changed. :-)
Evaporating expectations of quality.
(1980's paradigm: If it's worth implementing once, it's worth implementing
twice.
1990's paradigm: Ship the prototype!
2000's paradigm: Ship the idea!)

Thank you and take care.

LR: See you at TPC.