Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog Topics
 
 Archive
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

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.

Reader Comments: (RSS Feed)
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.
Or E-Mail Uli privately.

 
Created: 2005-09-28 @726 Last change: 2024-04-19 @228 | Home | Admin | Edit
© Copyright 2003-2024 by M. Uli Kusterer, all rights reserved.