Saturday, August 24, 2013

Amerish English

DSCN3881

JavaScript is the local puppet master, 
in communication with 
a netherworld of cloud based Servers.

HTTP and JSON 
keep the AJAX alive 
as Clients push their shopping carts
or whatever.

Old myths lay just beneath the surface. 

The dragon, atop a treasure trove:
our Python coiled among memory stones, 
latter day oracles,
each full of juicy secrets, 
some authentication required.

I was arguing with Steve and Patrick at Mulligan's the other day, that HTML is in the province of the English teacher, grammar teacher, elementary school language skills teacher.  It's not "computer science" or a "computer language", it's more punctuation, like semi-colons 'n $%&, plus with some auxiliary grammar, the XML concepts (or, as I explained to Uncle Bill SGML concepts, from Boeing).

Patrick shot back that software gets between conventional writing skills and all this machine-oriented stuff, so mastery of HTML is not a prerequisite for mastery of English, that boundary still stands.  My thoughts went back to Gene Fowler's thesis, that Amerish (as distinct from English) did include XML grammars (one could say) much as the Roman language included outlines, argument templates, formats.  A meta-grammar if you will (this was Steve's point).

Assuming Gene has a genuine leading here, lets explore moving move of this HTML stuff into both literature and theater.  For one, you have the Document Object Model (the DOM), which you may think of as an XML outline and a puppet, a segmented floppy thing controlled by strings (or controller).  JavaScript makes the DOM "laugh and play".  You write scripts for JavaScript or you could say JavaScript is but scripts, much as English contains (is, gives form to) what we might call "scenarios" (an overlapping feature with Synergetics, another language, that has those too).

You don't want your JavaScript-controlled client-facing environment to get bogged down or bottle necked owing to not enough attention from the server.  A poorly designed web framework makes the browser wait for updates that could just as well be handled within the browser by JavaScript.  The server gets bombarded by minutiae that could have been handled locally, and so service for everyone bogs down.  "One server per many clients" is the expected geometry here, and the devil is in the details of how that's managed.

If there's no zip code but one is required, or if the puzzle question is not solved (correctly or incorrectly), then lets not go running off to the server half-cocked.  Have all your papers in order before reaching the server's desk, don't be fumbling through your bottomless purse for that elusive passport.  Servers need to move quickly, not sit there grinding away pointing out exceptions, empty blanks, missing data.  The client side should have handled that stuff.  First get the blanks filled, then send only completed forms to the server for transaction processing.

Think of court life in the age of monarchs and needing the King's clock cycles to settle some dispute or obtain permission to build some facility (approval, denial... whatever).  You queue for the King for days and days, bribing the right officials, and some wrong ones, and when you finally do meet the King you realize vital facts are missing from your story, facts that could have been discovered and provided in the time intervening, if only there had been the proper form (template), a list of minutiae that might arise.  If you're thinking lawyers and JavaScript have something in common, as to their role in workflow governance, you may have something there.

Python is happy to delegate that which can be or has been covered.  Widget tool kits and web browsers were and are doing fine without having their guts be in Python.  Google App Engine got outfitted from the inside (I used it for an I Ching application), and novel ways of configuring the back end (e.g. Heroku) kept adding to Python's power on the server side.  As a mediator between SQL engines and HTML, Python was an early "P language" as in the classic "LAMP stack" (Linux, Apache, MySQL, a P-language: PHP, Python or Perl).  So letting JavaScript manage the DOM has always seemed quite natural.  Talk to JavaScript with JSON and everything's smooth.

This was a literature class, not a computer science class.  The "tabla rasa" or "blank canvas" of our day is the web page.  That's where most writing now appears, even when published in hard copy on demand.  Gene had a point about the final repository being more XML-like at the roots, not necessarily applied "later".  The structure and logic of the document requires the DOM to express and define itself.  To argue these are the skills of human language writers, not just machines, is not the huge uphill battle it once was.  "Amerish" (a-MER-ish) is taking shape.

Postscript:  Adobe's PDF format or Portable Document Format is another DOM with its own controller language.  Although servers may create PDFs on the fly and serve them to browsers, PDF has not taken off as an alternative to HTML + CSS + JavaScript.  They each fill their own niche.  PDF remains under-appreciated for its ability to contain embedded media such as videos, as well as internal hyperlinks.

Thinking about Objects