stijlist

> I believe that the strong producers and leaders in the software industry feel the same. The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I suspect 40% or less of them might benefit from pair programming

I don't buy this - weren't Jeff Dean and Sanjay Ghemawat notorious for pairing frequently?

It wasn't mentioned as a criterion, and OpalRuby, Python variants, and Coffeescript all got significant discussion in the article. The ClojureScript omission on all the axes other than "superficial similarity to JavaScript" is still pretty glaring.

It's a little strange that ClojureScript is omitted from the sections where it compares favorably to Scala.js, e.g.:

> If you look at other compile-to-JS languages like:

> - Google Web Toolkit which lets you compile Java to Javascript, > - The Opal Ruby Compiler for Ruby > - Brython, PyJS, Skulpt, Transcrypt or RapydScript for Python > - Various flavors of C#-to-Javascript (Salterelle, Bridge.Net, JSIL) > - Or Haskell-to-Javascript compilers (Haste, Faye) > You'll notice one thing in common: none of them have a standard way of writing code that runs on both their "original" runtime (JVM, MRI, CPython, CLI, ...) and on Javascript. And the reason why is straightforward: none of them are compatible enough, complete enough to really let you write "full" Java/Ruby/Python/C#/etc..

ClojureScript is mentioned in the article, but only for this specious comparison:

> Clunky Interop > Many other languages are not as fortunate. For example, here's how you create an element in ClojureScript, compared with Javascript

(let [paragraph (.createElement js/document "p")] (set! (. paragraph -innerHTML) "<b>Bold!</b>"))

var paragraph = document.createElement("p") paragraph.innerHTML = "<strong>It works!</strong>"

> Now, the conversion between these two snippets is mechanical, so it's not something you need a PhD to perform. Nevertheless, it is clear that using Javascript APIs in ClojureScript, while looking like ClojureScript, looks almost nothing like the Javascript it represents.

> This mapping is something that everyone who wishes to learn Clojurescript will have to internalize.

This seems misinformed at best - both Clojure and ClojureScript have interop as a first-class concern, and interop forms are exactly the same between them.

I appreciate the work that Li's done, but I'm disappointed by what seems like a rather disingenuous omission of the only other language which fulfills Li's criteria.

Interop, IDE support (IntelliJ), parent language compatibility, static optimization (judging by the payload size numbers, ClojureScript utilizes dead-code elimination more effectively than Scala.js), performance (ClojureScript immutable vectors are faster to build than JavaScript arrays, far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has been - since 2011) a compile-to-JavaScript language that is in the same league as Scala.js, and arguably eclipses it on many dimensions.

A language-agnostic comparison can't reasonably leave out ClojureScript.

More specifically, there is already a package manager and ecosystem that can install all of an OS, and you don't have to fuss with installing anything on your own. This package manager and ecosystem could subsume the problem of language-specific package managers entirely.

RC's motto is "Never graduate!"

curious. I thought "the grid" was about using a constraint solver + A/B testing to optimize websites for arbitrary metrics - pageviews or sales or whatever. the "AI" marketing makes some sense in that context, at least.

I'd be really curious to read more about how the Github team's intuition around polyglot programming and "Right Tool for the Job" rhetoric changed over time. I feel like I read a blog post about this one or two years ago but I can't remember which team member wrote it :)