🚀 go-pugleaf

From: jtv2j (John Viega)
To: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Relative Speed of Perl vs. Tcl vs. C
Date: Sun, 11 Feb 96 19:07:36 EST

Tom Christiansen writes:
 | In comp.lang.perl.misc, rust@Virginia.EDU writes:
 | :I fell in love with Perl a couple of years ago, until I learned
 | :Python, which can do everything Perl can, and has the advantage of
 | :being readable.  
 | 
 | So many false assumptions in such short text.

I think it's all a matter of perspective.  I could say the same thing
about your post, of course, but I won't.  Such vague pot-shots might
help sway people toward your view without considering the arguments
for and against, but, having read the full text of your reply, I don't
believe I've made too many assumptions, never mind any out-and-out
false ones.  The issues at hand are much more a matter of opinion
than of facts that can be proven false.

 | 
 | First of all, any language can do anything any other language can do --
 | it's just a ``simple matter of programming''.  Some things are better
Granted.

 | supported in the language or libraries than others, but the determined
 | programmer can bend any language to his will.  That being said, Perl's
 | string-processing facilities make Python's seem like mere ed-compatible
 | patterns.  [Examples available upon request.]  Sure, you could eventually
 | write the same in any language, but it would take so much more work that
 | it would seldom be worth it.
Like I said, I've used both languages extensively. Perl's string
processing facilities are more concise than Python's.  However, I
know a lot of people, myself included, who feel that Perl's
conciseness in this area is a drawback.  Sure, it might be 3 to 5
lines of python code, but the operations are a lot clearer.  Besides,
if I want to do string processing, I'm probably going to go use Icon,
anyway... Perl isn't everyone's favorite choice for string handling.

 | 
 | Second of all, the legibility thing is a red herring.  If I showed someone
 | the obfuscated C programming contest entries -- or even some freshman
 | college students muddled attempts at C programs -- they would likely decry
 | C as inherently illegible.  That's silly.  A bad programmer (or a sneaky
 | one) can always write programs that are hard to read, and a good
 | programmer can always write ones easy to read.  The implementation
 | language here is largely irrelevant.  If you don't write perlstyle(1)
 | compliant Perl code, it's not the language's fault that you have bad
 | taste.

I agree with you on most of this, but not quite all of it.  I think it
is unfortunate that people believe that legibility should not be an
issue in language design.  Like you say, most languages enable someone
who is set on writing a legible program to do so. While most languages
don't have much to say on style, they certainly could support legible
style, instead of merely enabling it.  Some languages make it a lot
easier than others.  Having non-obvious operators such as many of
Perl's, and having type qualifiers are variable prefixes make for less
legible programs in _some people's minds_.  Legibility is highly
subjective without a doubt, but a lot of people seem to agree that
Python is inherently more readable than Perl.  If 10 rewrote all of
the examples from Programming Perl in Python, I'll bet most people who
don't know either language, and a large number of the people who know
Perl and not Python would be able to understand the Python version
much easier, because the structure of the language forces at least a
small amount of structure, and directly supports a lot more.


 | 
 | As for whether a language should be understandable to programmers not 
 | even passingly conversant in that language, that's a theoretical matter
 | upon which the jury is yet to return.  I tend to prefer to see professional
 | tools tailored for professional use. 
I tend to prefer to see professional tools that enables professional
use., with which a novice can instantly be productive.  I believe there is no
excuse for any programming system to do any less, especially if it
wants a user base.

 |  It's easy to make a system that  
 | people with no training to use -- but very hard to make it so that experts
 | also feel comfortable with.  

I think the user interface / usability engineering community would
strongly disagree with you.  Making easy-to-use interfaces isn't easy.
Take doors, for example.  We've been building them for how long?  And
yet, how often do you push on a door that was meant to be pulled?
The user interface community has good guidelines to give as to how to
make a system easier to use for both novices and experts, at the same
time, even.  I'd strongly recommend the following books:

Jakob Nielson's "Usability Engineering"
Don Norman's  "The Design of Everyday Things"

 | Remember: user-friendly is a politically 
 | correct term for user-obsequious, or sometimes even expert-hostile.
In fact, the user interface / usability community berate the term
"user-friendly" quite harshly.

 | If you're merely going to claim that Python or Java are more readable due
 | to weak string-handling, I don't see that as particularly advantageous.

I don't claim Java is even more readable ;-)

Cheers,

John

------------------------------------------------------------------------------|
|John Viega        	              "Non-structurally equivolent types in C |
|rust@virginia.edu                     are polymorphic vis-a-vis their common |
|http://www.cs.virginia.edu/~jtv2j/    entity, the core dump."                |
|University of Virginia                                  --George Williams    |
-------------------------------------------------------------------------------