Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: "John C. Welch" <email@hidden>
- Date: Fri, 06 May 2005 19:00:15 -0500
On 5/6/05 17:50, "has" <email@hidden> wrote:
> 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.
Has, this will take, literally YEARS. What do the people who need to do work
NOW do? Nothing until the new language is usable? Keep working and hope
Apple doesn't make the MS VB to VB.Net mistake?
Ask the VB people about how happy they are about now.
>> 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.
And what do applescripters do in the meantime. Taking an external language
and making it take AppleScript's place will not, sorry to say, take either
little effort or time. Two years at a minimum, and that's with massive new
hiring and the entire team doing NOTHING ELSE, and that's just the language.
Not the IDE.
>
>
>> 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.
So don't use it for those tasks.
>
> 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.
Um...that's documentation not the language. AppleScript's documentation has
always sucked.
>
> 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).
And now we have Unix, which is not only more complex and cryptic than DOS,
but contains 1 and 2 letter commands that are hell on the dyslexic.
And all options were never always available on the screen, sorry to say.
Again, what do you do while this magical new language is being developed?
Use AppleScript? Hell no, it's dead. That's a waste of time. Do nothing? Not
an option, you have work to do. Learn a new language? If you do, why bother
with AppleScripts replacement, since you'll have a couple years to rewrite
everything in the new language, and since that will be working, why change
again for the sake of change.
>
>
>> 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.
I've been there, done that. Did Fortune 500 database-telephony applications
In a 100% visual language, did them in text languages too.
NOTHING is self documenting. It NEVER is, because part of documenting is the
REASON for using a particular construct. There's not a language alive that
will contain WHY I used a particular method for a particular solution. It
will contain the how and the what, but the why, that still has to be done
the hard way. If there is a *truly* self documenting language, the CDs are
under the keystone of the Fountain Of Youth, just east of El Dorado.
>
>
>> 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.
To whom? It would cost Apple a ton for a couple years, and customers even
more. Nothing's free.
>
>
>> 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.
And what do you do during that multi-year period. Hell it took years to get
the engineering time to get masked text in Display Dialog, and that's not
even made it to Studio. Where is this room with infinite free labor that
will do all the work to take <language> and integrate it into the OS,
document it, create the tools and test the whole thing in "no time at all"?
It's not that simple.
In your eyes. I'm evidently more realistic in what I want from the language.
--
"Tracers work both ways."
US Army Ordnance.
_______________________________________________
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