Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: has <email@hidden>
- Date: Fri, 6 May 2005 23:50:07 +0100
John C. Welch wrote:
> >> The idea that you can create a language that will perfectly satisfy both
> >> programmers and non-programmers is a chimera.
> >
> > Umm, this was exactly my point.
>
>I haven't seen anything that's better enough than applescript at the task of
>the end user language.
There's no shortage of good ideas and interesting implementations out there. What's really need is for a company like Apple to take the best of these, package them in its own inimitable way, and really commercialise and popularise the heck out of it.
>Pretty much anything with dot notation is right out.
So why did you bring it up?
>There's no need to create AppleScript Basic and AppleScript Pro.
So why suggest it? My suggestion is to take an existing OSS language, give it a little spit and polish where needed (e.g. IDE support) and provide a modicum of promotion; that'd take care of the pro/semi-pro market - something that OSS already caters for very well - with very little effort. It'd also free Apple to focus language development exclusively on the end-user sector - something OSS tends to be very poor at - by creating an innovative next-generation programming environment.
>End user languages will never be good as general programming languages, and the reverse is true.
False dichotomy. End-user languages may be either general-purpose or specialised; this is not what differentiates them from conventional languages. What makes them special is _how users interact_ with them. AppleScript, for example, is a general-purpose language in its design; it's just not very good/convenient for a lot of tasks due to its weak library support.
AppleScript also leaves a lot to be desired as an end-user language: unusual syntax aside, it's a completely conventional, traditional language; little different to something like JavaScript under the surface. And, like other traditional languages, it lacks the levels of transparency and constraint that end-users need to work effectively. Even humble ZX81 BASIC is a better end-user language than AppleScript in this respect: all legal language keywords are displayed prominently on the keyboard and the machine permits users to input these keywords and nothing else. Whereas AppleScript just throws the user a blank text window and leaves them to guess what to type in... then figure out what they did wrong when the compiler 'arbitrarily' rejects it later on.
DOS had the exact same problem, and Apple solved it by creating Mac OS: users no longer had to memorise cryptic commands because all available operations were always visible on screen, and they no longer had to worry about choosing the wrong one because the system only allows them to select from those operations that actually make sense for a given situation. Apple is in a good position to repeat this exercise with programming languages, not least as they've already done some exploration in previous projects such as Hypercard and Cocoa (no relation to OS X's Cocoa API).
> AppleScript does
>a better job of serving two masters than anything I've seen outside of 100%
>GUI drag and drop flowchart tools, such as Prograph or Edify, and having
>built systems in Edify at least, even full-on GUI tools aren't as easy as
>they initially look.
I dislike the symbolic visual languages for the same reason I dislike symbolic textual ones: human-readable text is self-documenting [to a degree anyway] whereas symbolic languages completely depend on prior knowledge to read. (OT: if you're a Prograph fan, you might be interested in Andescotia's Marten language [OS 10.3+] which looks very similiar.) For an AppleScript successor, a visual editor where textual identifiers, literals, flow structures, etc. are represented as drag-n-drop boxes (c.f. Alice) would be my preference.
>Is it so broken that it
>needs to be chucked and replaced with <product> that doesn't exist and is
>based on requirements that will never be consistent enough to allow it to be
>developed in the next decade? Hell no.
No, it should be replaced because Apple could (and should!:) do so much better. Even buying in an existing system like Boxer - which essentially takes Hypercard's drag-n-droppable objects concept and extends it to the language flow control and structures level as well - and repackaging it as their own would provide a significant step forward at very little cost.
>But if you hate it that much, why use it at all?
I don't hate AppleScript. I understand the language better than just about anyone else here. I've experienced it both as a classic end-user and as a moderately competent coder familiar with a number of other languages. I know where it works. I know where it fails. I understand why folk use it. I understand why others can't stand it. It contains some good ideas, some bad ideas, and some bad execution of good ideas.
My desire is to see those good ideas taken and recast in a form that does them true justice, along with lots of other good ideas taken from other sources, because no matter how much its internal guts could be improved I don't see any practical way to significantly improve its crude, inflexible and unreliable user interaction model except to rip it away and start altogether; and if you're going to redo that you might as well do the rest as well.
AppleScript talks the talk but ultimately fails to walk the walk; I want something that does both. It's not an unreasonable request, and it's certainly not an unrealistic one. :)
Regards,
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden