|[7 earlier articles]|
|Re: A Plain English Compiler email@example.com (2006-02-19)|
|Re: A Plain English Compiler firstname.lastname@example.org (Aaron Gray) (2006-02-19)|
|Re: A Plain English Compiler email@example.com (Keith Thompson) (2006-02-19)|
|A Plain English Compiler firstname.lastname@example.org (DEÁK JAHN, Gábor) (2006-02-19)|
|Re: A Plain English Compiler email@example.com (toby) (2006-02-20)|
|Re: A Plain English Compiler firstname.lastname@example.org (2006-02-20)|
|Re: A Plain English Compiler email@example.com (Scott Wyatt) (2006-02-24)|
|Re: A Plain English Compiler firstname.lastname@example.org (Gene Wirchenko) (2006-03-12)|
|From:||Scott Wyatt <email@example.com>|
|Date:||24 Feb 2006 18:00:30 -0500|
|Posted-Date:||24 Feb 2006 18:00:29 EST|
Languages like AppleScript / Xtalk (sp?) found in Runtime Revolution,
SuperCard (HyperCard), and throughout the Mac world are a complete pain
when you try to figure out what some routines will do.
The problem with "English" is meaning. The "Definitive Guide to
AppleScript" begins with a discussion of just how confusing English can
be as a programming language.
Sure, I want an "easy to read" programming language, but that doesn't
mean it should be like English. English is often mangled -- I admit as a
college English teacher.
A computer language should never be ambiguous. English thrives on its
ambiguity. Sorry, but programming needs rules and limits.
[My understanding was that the hope for Cobol was not that it would be
any easier to write than other languages, but that it would be easier
for non-experts to read. One can debate how well they met that
Return to the
Search the comp.compilers archives again.