Reply to thread

Message: [QUOTE="Peter J. Holzer, post: 4872085"] [long fullquote deleted - please quote only the parts necessary for context] I don't think so. It doesn't meet your aesthetic criteria, but it is a powerful programming language which can be used to write everything from simple throwaway scripts to large, complex software systems, in a readable, testable, maintainable way. It is true that the syntax is rather complex - probably one of the most complex ones in popular programming languages. This is intentional: Firstly, because Larry tried to throw all the good bits from lots of programming languages in (when I first encountered Perl I called it "the PL/1 of nineties"), and partly because he modelled it after natural languages, so like natural languages it has a complex, irregular, context-sensitive syntax with lots of shortcuts. He probably went too far - Perl syntax could be cleaner and less visually cluttered without losing expressivity. Lisp is the opposite - it has an extremely minimalistic syntax, and for my taste it goes too far in the direction of simplicity and purity. A lisp program may be easy to read for a lisp compiler, but it isn't easy to read for me. I need more visual structure. Well, all of these are described in perldoc, so I don't understand why reading it didn't help. That doesn't necessarily make the language easier to learn or read. On the contrary, I think lisp offers too few visual clues - everything looks the same to me. (but then I've never used lisp in anger, so in part this is simply because I'm not used to it) While Carter's code wasn't specifically designed to be pathological it was pretty bad, too. But how would the same code look in well-written Lisp? (Ben already showed well-written Perl). Right. It doesn't do that but for a completely different reason: The sigil has (almost) nothing to do with the variable's data type. Instead it is an article, like in many European languages. English is a bad example, because it has only one definite article (the), so let's use Italian: il - singular male la - singular female i - plural male le - plural female Gender doesn't have any meaning in Perl, but we can distinguish between singular ($) and plural. And there are two types of plural - ordered (lists, arrays: @) and unordered (hashes: %). So $ denotes singular: $ x - one x $ a[2] - one element (with index 2) of the array a $ h{'k'} - one element (with key 'k') of the hash h @ denotes an ordered plural: @ a - the whole array a @ h{'a', 'c', 'b'} - the elements with keys 'a', 'c', 'b' of hash h, in that order. % denotes an unordered plural: % h - the whole hash h Note that I have used $ with a scalar variable, an array variable and a hash variable and I have used @ with both an array variable and a hash variable. So they clearly don't "indicate the type of the variable". I have written a space after the sigil to emphasize that it is a "word" in Perl's grammar and not a part of the variable name. Normally you omit the space. (Side note: Sigils are used differently in Perl6) Yes, but in a different way than you seem to think. Also, these three are rather fundamentally different (although awk and JavaScript seem to think that hashes and arrays are the same thing). Right. It doesn't do that. Should it? From a performance POV maybe - a 4byte int takes a lot less memory than a perl scalar value. But from a correctness POV using representative types doesn't buy you much - you may represent both the area of your living room and the milage of your car as a floating point number but that doesn't mean that the sum of both makes any sense. For that you need a much more strict type model. No, not really. At least not any more than it distinguishes between numbers and strings. And that distinction is relatively recent. Huh? Yes, it does. You can compile a string into code, but you'll have to do that explicitely. Of course you can look them up. All of them are documented and the Perl docs aren't that bad (although I agree that they could be better). You can't use google to search for them, but the same is true for any keyword or variable name which happens to be a common English word (although for opposite reasons). That's debatable. Perl is in the C tradition of returning an error value instead of throwing an exception, but that is only "silent" if the Programmer carelessly ignores the return value. "Universally accepted" is rather strong given that most shells, most templating languages and many scripting languages use a similar expansion mechanism. The expansion mechanism in Perl has a few shortcomings, but the fact that Perl has such a mechanism is a feature, not a bug. Apart from a few pathological examples like the one above, simply embedding variables or (very) simple expressions in a string is less cluttered and easier to read then constructing the string with concatenation operators or formatting functions. And Perl *does* have simple strings, you know. hp [/QUOTE]

Verification