Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) Newsgroups: comp.unix.shell Subject: Re: ap Message-ID: <1991Jun5.051104.7601@jpl-devvax.jpl.nasa.gov> Date: 5 Jun 91 05:11:04 GMT References: <16852@helios.TAMU.EDU> Reply-To: lwall@netlabs.com (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 167 In article <16852@helios.TAMU.EDU> byron@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@netlabs.com : -- : Byron Rakitzis : byron@archone.tamu.edu