15 Most Recent [RSS]
More...
|
The English-Likeness Monster ... or is it?
John Gruber of Daring Fireball fame just wrote a piece on The Suckage that is AppleScript's attempt at being like English. Now judging from the headline, John seems to basically be of the opinion that English-like-languages per se are bad, instead of placing more emphasis on the fact that AppleScript is simply a complex object-oriented and strongly typed language that some nit decided shouldn't expose much of that to its user.
An even bigger flaw of AppleScript is one that would get any interaction designer ("GUI designer") slapped on their hands: It breaks the metaphor. In this case, the metaphor is the English language. Yet, AppleScript lets you write un-grammatical sentences like set window 7 of application "Safari"'s value to display dialog "Hello", which sounds more like a short attention-- oh. a butterfly...
In my defense, a lot of the Cocoa community probably know one of the major advantages of english-like languages: Named and labeled parameters. Yes, you don't need to be very english-like for that to work, but it's one of the first steps in that direction. Cocoa still sucks a little in this regard, because the order of parameters is important. But with arbitrarily-ordered and optional labeled parameters, it lightens the burden on the programmer's memory.
The labels on the parameters alone are expressive enough to let the compiler know what parameter you're talking about. And for most users it's easier to remember that e.g. a system calls a window frame and that that's the label for the parameter that specified the window than it is to remember that a particular function takes the window as the third parameter.
However, English-like syntax has disadvantages, too. Most of them can be overcome. E.g. verbosity can easily be worked around by giving the programmers a syntax-completing editor (like in Terminal, where you can type the start of a filename, hit tab, and Terminal.app will complete it for you). The longer words are easier to tell apart (mv and mu, vs. move and mutate, or whatever that command would do...), and easier to remember.
One that is less easy to overcome is the disadvantage it has over clearer and less ambiguous languages (like mathematic notation). English is one of the more ambiguous languages, and you can't have ambiguity in programming languages. Still, in my opinion modern programming languages aren't yet taking advantage of English-like-ness as much as they could or should.
Aaron Ballman writes: I firmly believe that there are three types of languages in the world.
Perl, a write-only language. You can write a script, and while you're doing so, it makes a ton of sense. But two weeks later, you won't have a clue how it works because you can't read any of the code.
AppleScript, a read-only language. Given a script, it's really easy to understand what it's supposed to do. However, being told to write one from scratch is almost impossible because you never really know what's going to work.
Most other languages are read/write languages. You have an equal chance of reading someone else's code as you do writing your own code. |
| |