ap

[Larry Wall]

In article <16852 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
: After compiling perl on my system and being nauseated by the syntax of
: the language, I've decided to try to come up with my own alternative.
: I'm going to call it ap, or anti-perl.

You're certainly welcome to try.  But if you come up with a beautiful
syntax, you'll be solving a different problem than the one perl solves.

Perl is certainly ugly--I've never claimed otherwise.  But the ugliness
is there for A Reason.  Several reasons, in fact:

	1) Perl is a systematization of a chaotic culture.
	2) Perl should do what you expect, for most "you".
	3) Perl should evolve without obsoleting old scripts.

1) Perl is a systematization of a chaotic culture.

If you think of Unix culture as a kind of language, it's an exceedingly
undisciplined language.  New words are added helter skelter.  Dialects
diverge faster than they can be standardized.  There are several
alternate forms of syntax (shells), most of which are based on the
ever-confusing multiple-substitution-pass paradigm (shades of transformational
grammar, ugh).

If you try to analyze Perl as a classical computer language, you'll find
that it's more cumbersome than you're used to.  If you think of Perl as
a systematization of Unix culture, however, it's quite small and coherent.
Huge languages like English and Unix are obviously good for something,
but Perl is an experiment in moderation, to see if a medium-sized language
can get some of the benefits of a huge language without all of the
annoyances.  The question is whether the expressive power increases
faster than the ease of use and learning decreases.  Obviously this
is a matter of taste and prior experience.

I'm not a computer scientist, though I have some training in the field.
I have more training in linguistics.  I'm also more of a synthesist than
an analyst.  Some of my opinions are naturally repugnant to the analytical 
mindset--I don't mind a little redundancy if it increases effective
communication.  If you want to be able to factor out every little
bit of redundancy from your programming, pick a language with abstract
types and multiple inheritance like C++.  But expect that you'll have to
know the semantics of 57 abstract types to figure out what that "+" means...

2) Perl should do what you expect, for most "you".

If you're going to design a language to fill the (huge) niche between
C, sed, awk and the shells, you'd better make it easy for programmers
in those languages to migrate to your language.

People often suggest new features for Perl.  (If you're gonna be a language
designer, you'd better get used to that idea.)  Believe it or not, I don't
add most of the features people suggest.  However, when someone says, "It
didn't do what I expected," my ears perk up.

3) Perl should evolve without obsoleting old scripts.

All those weird characters like $ and @ and & are also there for a reason.
They let me put variable identifiers into their own namespaces, so that
new "reserved words" can be added to the language without blowing up your old
scripts.  (For a simply typed language like Perl, they also enhance
readability--you can see the type of something just by looking at it.
There's also the cultural thing about variable interpolation in shells.)

I was never so gratified as when someone hauled out some old Perl version 1
scripts and they ran without a hitch.

: Right now I'm thinking that ap will be a super-awk that is less
: confusing for a C programmer to learn. I'm not sure if I want the
: implicit looping over stdin (though that's kind of nice) and I
: definitely don't want the
: 
: 	pattern { action }
: 
: syntax that awk has.

I'd certainly agree that awk's syntax is too distant from C for comfort (to C
programmers, anyway).  Perl's syntax from the expression level on down is
basically ripped right out of C.  Higher level constructs are also quite
similar, modulo some changes to make loop control more readable.  There
are a few additional control contructs that help you write more readable
programs, but aren't by any means required.  You can program Perl like a
C programmer, and nobody is going to get very mad at you (unless they have
to read your code, of course... :-).

:  It will have an integer and a string datatype, and
: you should be able to build arrays out of those objects (associative
: arrays too). Functions would be a nice thing to have, but it must
: always be easy to toss off a quick one-line ap script, i.e., in the
: most trivial case I would like something like
: 
: 	ypcat hosts | ap 'print $1'
: 
: or something similar to work just right. I hate having to place braces
: around that simple statement as one has to do in awk.

I agree with the sentiment, but you have to be very, very careful in
picking your defaults.  In language design you can't have your cake and
eat it too.  Every time you choose some way to default something, you
force every other construct to indicate in some way or other that it is
not using that default.  For instance, awk boxed itself into a design
corner by using newline to terminate commands and the null string to
indicate string concatenation.  Likewise by not having any way to refer
to an open file symbolically.  Not to mention the implicit looping and
pattern/action construct.

I suggest very strongly that you start out designing your language with few
implicit semantics.  You can then always add a switch to assume some implicit
semantics.  Going the other direction is much harder.

: Most importantly, ap will be driven by an easy-to-understand grammar
: with C-like syntax.

You just contradicted yourself there...  :-)

Ease of learning is one thing to design for in a language, but it's only one.
Furthermore, you're not designing for ease of learning except for one specific
set of people.

: There may be 2 or 3 ways to perform a particular task, but there will not
: be 10,000 as there are in perl.

I think you may be exagerating slightly.  Perl isn't that good yet.

: The main deficiency of awk that I see is its inability to interface
: well with Unix. Up until recently, awk did not even have ARGC and ARGV,
: not to mention things like file redirection. This is where perl has
: taken a step in the "right" direction. Of course, it could be argued,
: why put symlink(2) into ap when you have ln(1)? Well, this is why perl
: was written:  Unix today just cannot provide any performance with shell
: scripts; for better or for worse this has to be coded into the command
: interpreter.

That's only one reason Perl was written.  As I mentioned earlier, many
of the design decisions in Perl were for the benefit of (potential)
readability.  But Perl also lets you optimize for conciseness, or
writability, or performance (as you mentioned), or portability, or
similarity to any of several languages you may be familiar with.  To
gain all these, I consciously traded away a little learnability (at
least in terms of being intimately familiar with all parts of the language).
The hope has been, and I think it was justified, that people would pick
up Perl like they pick up English--enough to get by.

Ask yourself if you really have a clear idea of what you want in your language,
and secondly, if you do, whether you really want enough out of your language.

But good luck, and all that.  If you're right and I'm wrong, I'm just glad
I had a 5 year headstart...  :-)

: Ideas are welcome. I really want to write this thing; perl is a
: disgrace to the Unix community.

No, Unix is a disgrace to the Unix community.  Perl merely inherits some
of that ungracefulness.

When you get down to it, Swiss army knives are ugly too.  But everything
is there for a reason.

Love,
Larry Wall
lwall at netlabs.com




: --
: Byron Rakitzis
: byron at archone.tamu.edu