On Wed, 25 May 2011 08:01:38 +1000, Chris Angelico wrote: > On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain <da...@druid.net> > wrote:
>> When I first looked at Perl it looked like line noise. When I first >> looked at Python it looked like pseudo-code. > > When I first looked at assembly language it looked like random junk left > behind in memory. When I first looked at COBOL it looked like ... COBOL. > Doesn't make either of them better or worse. Er, yes it does. Writing code is primarily for *human readers*. Once you've compiled the code once, the computer never need look at it again, but human being come back to read it over and over again, to learn from it, or for maintenance. We rightfully value our own time and convenience as more valuable than that of the computer's, which is why we use programming languages at all, instead of having custom-made hardware built for every task we want the computer to do: "I have to rename a file before August 2015, but the rename itself needs to be done in under a picosecond. Know any bespoke chip manufacturers who do small runs?" From that perspective, COBOL is an improvement on assembly, which is why there are probably still more COBOL programmers around than people who work exclusively on assembly. Sometimes we compromise, or even subvert, that trade-off: for speed critical code where we do care more about the computer's time than our own, or for esoteric languages designed to be as hard to read as possible. My personal favourites, Oook and Whitespace. But generally, people spend more time reading code than writing it, therefore we should weigh "ease of reading" higher than "ease of writing". (My guess is, the weights should be about 5:1.) > Pseudo-code is not a viable language for a computer to parse, Only because "pseudo-code" implies that the code is ambiguous or otherwise cannot be parsed. If it could be, it wouldn't be *pseudo*, it would be real code (possibly for some compiler that hasn't been written yet). > but it's a > good language for scribbling down comments in. That doesn't necessarily > mean that a programming language that's "closer to" pseudo-code is good. That depends on the nature of pseudo-code. "Pseudo-assembly" has all the disadvantages of assembly with none of the advantages, i.e. it doesn't actually work. So in that sense, pseudo-code is not necessarily a good thing nor a bad thing. But in general conversation, pseudo-code is usually implied to mean that the language is as close to human language as you can make it, while still be parsable by a compiler. > And verbosity doesn't necessarily equate to quality; for instance, when > I'm working in both Python and PHP, I find it FAR tidier to use Python's > {1:2,3:4] notation than PHP's array(1=>2,3=>4) - but on the flip side, I > would prefer to have program structure defined by keywords like "if" and > "while" than obscure random line noise. (Fortunately, most sane > languages do indeed use keywords there.) True. That's one of the limitations of the xtalk family of languages derived from Apple's (defunct) Hypertalk: it's awfully verbose, which is good for newbies but not quite so good for experts. -- Steven -- http://mail.python.org/mailman/listinfo/python-list