Re: Of skunks and their works [was: Re: Library Use Statement Question]
Re: Of skunks and their works [was: Re: Library Use Statement Question]
- Subject: Re: Of skunks and their works [was: Re: Library Use Statement Question]
- From: has <email@hidden>
- Date: Tue, 24 May 2016 18:49:45 +0100
Deivy Petrescu wrote:
>> [3] Personally I'd love to have a few free months to get back onto
my skunkworks project to create a Logo/AppleScript hybrid that attempts
to nail these problems.
>
> About [3], if I am not busy, count my in as a guinea pig.
Appreciate the gesture, but honestly don't hold your breath because it
won't be released any time soon.
You're more than welcome to play about with kiwi if you want
(http://www.mantasystems.co.uk/docs.html), and don't mind spelunking
incomplete documentation and shortage of examples. Kiwi touches on some
of the EUP ideas I want to explore in entoli, but kiwi's very much a
special-purpose language (for Adobe Illustrator templating) aimed at a
single niche market (packaging artwork producers) whereas entoli is
intended to be a general-purpose scripting and automation language
anyone can use. e.g. General ideas like "code is data", powerful
coercions, all behavior is supplied as plugins, and "variables and
nominative types totally confuse users so let's get rid of those" are
very similar to where I'm going in entoli. (OTOH, domain-specific stuff
like kiwi's tag values and lazily evaluated semi-declarative "rules" are
not: like AS and Logo, entoli uses traditional imperative execution of
sequential command instructions, though with much more powerful
parameter handling, and getting/setting stored values uses entoli's
standard command syntax, not specialized tag values.)
As to entoli itself, I've gotten as far as nailing down the syntax
(standard grammar and punctuation rules) and getting its parser working,
including and extensible whitespace-independent lexing and tokenization
with the ability to define custom operators because no language ever
gets popular without recognizing established human mini-languages for
arithmetic and algebra (although as a practical matter I've yet to
figure exactly how to prevent custom operator definitions degenerating
into terminology conflict hell as AS dictionaries do). It also has an
"interpreter" which is just a super-basic AST walker, slow to run but
dead simple to develop and maintain (and not a performance killer as
long as user code can be selectively compiled too). And it's all
implemented in Swift, which means it should be super-trendy and
attractive amongst computer geeks as well as end users – and since you
need those geeks to build the libraries and tools that actually make a
language useful to everyone, it's every bit as important to win them
over too (and even more difficult as, unlike end users, they're already
spoiled rotten for geekbait languages).
Which brings us to where the whole project's wedged. As in kiwi, I want
all primitive handler calls to convert their parameter and return values
between native and Swift datatypes *completely automatically*, thus
eliminating the need for great swathes of mindless boilerplate code of
the sort you find in [e.g.] Python's C modules and which makes them
horrid for anyone to write. Alas, Swift's generics are a brain-damaged
PITA that have made me waste far more time fighting with that stupid
language than actually getting my own one done. [2] I already manually
prototyped a handful of math handlers and corresponding infix operator
syntax in order to test the interpreter out, but implementing an entire
standard library of functionality this way would take many months of
mindless make-work, which is something I won't tolerate, never mind
expect anyone else to. And what's the point of going to all the work of
establishing a language that's [hopefully!] friendly and easy to use but
unsustainably expensive to grow and maintain? (One need only look at
AppleScript to see how well that strategy works for achieving mass
popular success.)
So you can write and execute lovely looking entoli code like this:
Pen down, forward 5cm, turn right 90°.
Input {prompt: "Enter a distance", type: length (10mm thru 100mm)};
forward.
Pen up. Output "Job well done, lad!"
but sadly running this code won't yet do a damned thing because entoli
doesn't even have a standard library of general-purpose handlers yet,
never mind libraries for specific tasks like graphics and IO. And being
a "stealth Lisp", where absolutely EVERYTHING is a plugin (even flow
control and coercion), no libraries means the language can't do ANYTHING
yet. So the whole project's blocked until I can figure out how to
seamlessly bridge between the native entoli language and its underlying
Swift implementation without the Swift compiler instantly crashing or
otherwise refusing point-blank to do all the mindless repetitive
make-work so that us humans NEVER have to write that crap ourselves. [3]
And this is even before I start thinking about entoli-to-Swift code
converter; because why bother trying to build a "fast
performance-optimized interpreter", which is insanely complex and still
comparatively slow, when you can just use cross-compile some or all of a
user's scripts straight to fast machine code using the existing Swift
compiler to do all the heavy lifting totally for free? Not to mention
auto-generated user documentation, modern UI/UX standards such as live
interactive auto-suggest, auto-correct, and auto-complete, and upcoming
capabilities like voice-based interaction. But such capabilities will
only be possible if ALL of the work of translating data and behaviors
between entoli and Swift is already 100% automated, and thus 100%
automatically analyzable and transformable too. So while the temptation
is always to "kludge things manually for now and redo it properly after
it's released and successful", actually 99% of the language's starting
and future value hinges on cracking this one particular problem right at
the start, so that all the other stuff falls naturally into place from
there. [4]
/braindump
Ah, the joys of modern computing; not so very different from the Good
Old Days when "computer" meant a human person sat at a desk with a slide
rule and ledger, doing all the flipping work herself. Wonderful thing,
automation (as we here all know:); pity the Real Programmers all suck at
it so. :p
has
[1] This is not to say Python libraries are inherently wonderful: Python
code is no more automatically self-documenting than AS code is and,
having already designed one self-documenting language
(http://www.mantasystems.co.uk/documentation/rule-descriptions/index.html)
with another in the works, I can say that any language that doesn't
support user documentation as a *first-class* feature has no business
calling itself "user-friendly", or even "developer-friendly" for that
matter.
[2] Same reason SwiftAE (https://bitbucket.org/hhas/swiftae) has been
dead in the water since last summer: I got it 90% implemented and
working great, but got completely stuck on the final task: determining
how to unpack an Apple event's return value automatically according to
the type of variable to which the user assigns the command's result. (It
works fine for atomic types like Integers and Strings, but as soon as
Swift's effing Array/Dictionary/Set generics come into play I might as
well smack my head at a granite wall, because Swift's much-vaunted type
system is truly dumber than rocks: it may like to think it's elegant and
powerful as Haskell, but frankly it's not even competent and capable as
C++, i.e. not much. Hey, guess why I like Lisp-y systems and loathe
Algol/C-descended ones so much now…)
[3] Eh, but at least I can laugh when new Swift converts wax lyrically
about how Swift has enabled them to slash their code base sizes in
half(!), when Alan Kay has been saying for several decades now that we
need to cut them by *several magnitudes* (100-1000 times smaller!) in
order to keep building increasingly powerful and sophisticated systems
without killing both them and ourselves with fatally exploding
complexity and cost.
[4] KIP: "Knowledge Itself is Power". And where better to find knowledge
that can be put to all kinds of use than in the machine-readable data of
a Lisp-like system, where even the language's own code is its own data too?
_______________________________________________
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