Good language UX != rocket science [was: Re: Handlers in a variable]
Good language UX != rocket science [was: Re: Handlers in a variable]
- Subject: Good language UX != rocket science [was: Re: Handlers in a variable]
- From: has <email@hidden>
- Date: Mon, 25 Jan 2016 19:55:24 +0000
|
On 23/01/2016 06:00, Phil Stokes wrote:
Dunno who told you incremental
parsing is "A.I.",
Direct quote from Chris Page. See the thread
“Grammar Police in OS X 10.11”.
Looks like Chris was talking about error report generation there,
not incremental parsing. Although even good error reporting isn't
AI; mostly just understanding what sort of errors users typically
make and why, and providing better feedback when they do. e.g.
Here's a blog post from the Elm folks discussing what they're doing:
http://elm-lang.org/blog/compilers-as-assistants
For something like an unterminated `"`, it'd probably be enough just
to color the code so it's obvious to the user which sections the
compiler currently _thinks_ are text literals, then leave the user
to work back from the end to determine at precisely which `"` it all
started to go wrong.
A slightly smarter compiler might use a simple heuristic to make an
educated guess at that point for itself (just compare word and
punctuation frequencies inside and outside of quoted sections: if a
section contains a lot of AS-defined words and punctuation it's
probably code, and vice-versa). Or a smarter code editor, backed by
an incremental parser that builds and dynamically updates an
abstract/concrete syntax tree in the background, will be able to
detect if a `"` is only temporarily missing because you're still
typing/editing a particular line, so it isn't constantly recoloring
*everything* after your cursor as you type, but instead waits till
you're done before reminding you of any unbalanced punctuation that
you still need to insert. And that's before you even get to the
genuinely fancy stuff like trying to inference the origin and
reasons for _why_ an error occurred and explaining it to users in
plain human language. Lots of ways to improve UI/UX for _all_ users,
and decades of published research to plunder for concepts and
techniques. <http://lambda-the-ultimate.org/> is always a good
place to start digging.
Smarter error reporting is something I've already done a little bit
of work on for kiwi <http://www.mantasystems.co.uk/docs.html>,
which, being semi-declarative and lazily-evaluated, can see errors
reported at very different locations and at much later times than
the point at which the duff data was originally provided. And no
doubt end-user-friendly error reporting is something I'll explore
further if/when I get back to working on language #3. For example,
one of the goals is to allow running scripts to pause-edit-resume on
errors, so that users to tweak the code and/or data then continue
running from where it left off. Far from a new idea, of course (e.g.
some of the Lisps can handle errors and resume without ever
unwinding the call stack, while Smalltalk machines are famous for
live editing of running code), but one that mainstream scripting
languages have completely failed to make their own. And with
traditionally staid 'compiled languages' starting to catch up in
other respects, e.g. see Swift's editor and playground (REPL)
support, it's past time that scripting languages were finding fresh
ways to differentiate themselves.
That all said, the best single solution is to design your language
in ways that minimize the likelihood of such errors arising in the
first place. Many a syntactic and semantic error could be avoided
entirely were languages not so insanely syntactically and
semantically complicated, inconsistent, and brittle in the first
place. (e.g. Recall Apple's recent `goto` security bug for laughs:
<http://www.dwheeler.com/essays/apple-goto-fail.html>.)
HTH
has
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden