Thursday, April 14, 2016

Musings on JavaScript

I'm sorting through code school videos in the Youtube repository, and others, looking for exemplary recordings.  Today, I'm combing through Douglas Crockford movies.

No, you won't find him in IMDB I don't think (OK, maybe), but he's a star nonetheless.  He invented JSON and JSLint after having an epiphany that JavaScript was really a lot like Scheme under the hood (plus Self, and HyperCard) -- no accident given the history -- and that realization made him really brilliant.

Zooming out, it's the Lessons he teaches we should take to heart:  it's not that what we have today is the way it is because it had to be this way, nor because this way is best.

In the case of JavaScript, the vision of the Web was taking off and Netscape wanted to launch LiveScript at a critical time, when we needed previews.  What would this Web come to be?  Big business was willing to gamble.  Little puppet shows, with some LiveScript pulling the strings, would say a lot about the potential future, and so it shipped, one might say as a part of a much-needed demo.

And that, my children, is what we're calling JavaScript today.  Or ES6 or whatever we're up to.

Crockford is returning to his roots in wanting to dive deep into recursion, with tail optimized calls.  "JS will finally be a real functional programming language", he exclaims.

So lets remember that Lesson:  it's not the best way, it's not the only way, it's just the way, whatever it is.

We're stuck along some axes more than others.

We might define the axes in a negative sense, as precisely those things which cannot happen, leaving what can, constrained, as the allowed space of what's next.  Do we know enough about the rules to preclude... [you name it]?

Let me digress to mention a movie again:  Ten Cloverfield Lane.  How would you ramp it up, given a budget, in the direction of more and more surreal?

In a way I found it compelling how deeply into surrealism our imagination could take us.  Yet my reaction was the same as hers:  "oh gimme a break".

Like, what "miracle" would say to you that "reality is broken"?  Something impossible that is, like the aliens landing.  The thing is:  might not aliens land?

You'd likely not be not surprised to find out many humans believe we've already been invaded, with much disagreement on who by or what the symptoms are.  Most mythologies don't cast the aliens as helping us hold it together, much as the good Angels used to do (the bad ones worked for some Lucy or someone).

Our language leaves that loophole open, for "space invaders" -- one might say.  We're at the twilight of the empirical in entertaining such beliefs, on the fence not so much with what's false as what it makes no sense to say.  What makes us think our language makes us capable of thinking "anything we like"?  I'd say more the opposite is the case.

OK, digression over, sorry.  JavaScript is where I'm focused.


1.  Because Portland has long had its Admirers of JavaScript (a meetup and listserv I've been a part of).  "I won't need loops anymore, because we'll have tail calls" (Crockford again).

2.  But more than that:  it's a hugely prevalent language that's worth learning from the ground up, perhaps using Crockford's minimalist approach, which allows him to call it "silly" (just a prototype after all) while staying fairly proud of his own use of it (as audited by JSLint).

No code school gets away without teaching JavaScript at some level, and in a hand-wavy way is worse.  I want to get it more thoroughly myself, for a host of reasons, such as looming "boot camps" for math teachers (I use quotes to suggest they're maybe really not as strenuous as the "boot camp" metaphor makes out).

The real question is whether to have it at all levels, client through server, from Angular to Node to MongoDB.

I lean towards wanting to tackle more than one language and SQL, HTML and CSS by themselves don't stand up as Turing Complete if ya know what I mean.

JavaScript and something else, maybe Clojure.

Maybe Java or Python or C# (as a trio?), with an emphasis on whichever one the mentor wants to pick.  We go with the strengths of the mentor, why not, without discouraging cross-training and branching out.

Do we work in .NET or not?  I don't see why not.  I'm not against using free teaser products that hint at more and even better for pay.  I understand money is a medium.  Open Source is often itself the teaser, meaning a company uses it to showcase what must be a vibrant culture, to hatch and sustain such a cool thing.  I'm neither cynical about nor disapproving of this practice, quite the contrary.

Code schools that start small may be tempted to stretch too thin and teach too many subjects, because the materials don't teach themselves and people need mentors, both synchronous and asynchronous (either the adjective and the adverb work here).

A code school without mentors is not so much an oxymoron as one with ghost mentors and/or unsung volunteers, which may be people willing to guinea pig themselves (like "Guinea Pig B", aka Bucky aka RBF).  That's pretty extreme though.  The word "school" has never been synonymous with "robot" and it's a stretch to make it mean that right now.

My theory is the geek etymology, with roots in the carnival business, show business more generally (even stage magic), comes with this idea of "rides" which are indeed "engines" that create experiences, such as roller coasters and Ferris wheels.

Lets remember these are real characteristics of the user experience in cyber-ville:  we do build little rides and theme parks for people (they're called web sites) that treat everyone the same way.  There's lots of automaticity involved, but nevertheless, every pinball game is different.

What I hadn't realized about JavaScript is its deep investment in IEEE 754 floating type as the only type, whereas Douglas is sensitive to the COBOL crowd's need for reliable monetary computations, and true Decimal computations.

We have the Decimal type in Python.  There's an advantage to having several Number types.

DEC64 sounds smart though.

He's entirely open to a next language, star Crockford is.  He's ready to create the space for us to try something new.

Why not something parallel to the Internet to fall back on, made of different parts?  I saw a talk on that topic as well, by someone else stellar.

Call it research.  Call it your company's Diversity policy, in action.  I'm not the one to boss you around, no worries.  I'm just celebrating our liberal openness to new languages and alternatives to what we tend to take for granted.

Having working languages already, dependable, responsible, is a gift as well.  In clinking my glass and toasting the future, I'm not thereby dissing the past, a misunderstanding that's easy to have, sometimes all too hard to let go of.

"We never change the minds... we just have to wait for them to die" (laughter, applause).  "Can we get rid of GOTO now?"  Hah hah.

He's really into lambdas, which is spelled 'function' in JavaScript.  You don't have to name it or remember it, just do it.

What does he think about Go I wonder, Crockford I mean?

That's something I could Google up no doubt, or even Bing.  Is Go not close to the metal enough to qualify as a systems language?

What I wonder, given such as ClojureScript and Brython (a topic in Cuba these days), is:  if JavaScript is to be seen as the Assembler of the Internet, should we maybe just use it like that, to implement mostly other languages?

Stay in Clojure or Python in the client, knowing you've got some V8 or whatever under the hood?

Is JavaScript more like our most refined grade of engine oil in Web 3.0?  Made of only the good parts I mean?