Apple

I have to echo previous posters' opinions that hiding the details from scripters does them a disservice

Every computer language hides details from programmers/scripters/users, that's kind of why we have languages. The higher level language the more is hidden.

There are benefits and costs associated with any language design choice made and while we may quibble about the relative value of one decision over another, on the whole I have a lot of faith in choices made by the Apple engineers.

especially when the hiding of details breaks down when presented with the simplest of compound expressions. The recent discussion of implied 'get' events is a prime example.

Easy there. These are calls to properties of objects in applications, these may be simple expressions, but not the simplest. Plus, there is no breakdown here. Nearly everyone who asked seemed to be wondering why it behaved that way, I don't think anyone was facing an insurmountable roadbloack or any breakdown of any kind.

These things are much easier to discuss without undo exaggeration.

Here's another bit of AppleScript deception that bit me recently.

There is no deception here. There is a design choice that benefited many users.

AppleScript 2.0 has eliminated the disparate string data types (string, Unicode text, international text, etc.) and gone to Unicode-only strings. Bravo! To provide some level of backward compatibility, all of the legacy string data types are viewed as synonymous. In other words, on AppleScript 2.0:

set theString to "string"

set theClass to (class of theString) --> 'text'

set theResult to (theClass is string) --> 'true'

However, this aliasing behavior is not extended to list-containment evaluation:

That's not deception, your expectations were not realistic. The class text and the class string evaluate as equal, but the class string is not in the list {text}.

In my code that needs to run on both AppleScript 2.0 and AppleScript 1.9.x, I had to track down all of my string parameter validations and add 'text' to the list of valid data types:

Without simple-case type aliasing, I never would have expected the list-containment case to work. With this aliasing, it took me a bit longer to track down the source of the problems.