stijlist

The text says one thing, but the graph they display to support their argument does not say what I thought it said.

The purple line is supposed to be our "real" emissions, and the impression you get from the image and text is that our real emissions are much lower than the projected emissions.

But if you actually look at the values of the purple line vs the other lines now, in 2020/2021, the values are almost exactly the same.

I don't understand how to reconcile that with the text.

https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q...

This shell script:

#!/bin/sh while true; do $EDITOR $NOTESDIR"$(ls -t $NOTESDIR | selecta --scrolloff --passthrough)" done

It replicates the core interaction model of Notational Velocity: type to fuzzy-filter the list of notes (sorted by MRU) by filename, enter to edit the notes, and quit the editor to end up back in the list of notes.

I forked selecta to add those flags - --passthrough means that the text typed in to filter is emitted on stdout if it doesn't match anything. This way you create a note if it doesn't exist.

https://github.com/stijlist/bin/blob/master/nv

> 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.

That's one of the ideas behind transducers:

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

And they work! It's not stream fusion, but the composed functions being applied to whatever container or stream of values are applied per-value, so (map (comp xf1 xf2)) applied to [1 2 3] applies (xf2 (xf1 1)), (xf2 (xf1 2)), and so on, with similar allocation savings to stream fusion.

There's this great series by mbrubeck which sounds like it might be right up your alley: https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.h...

RC's motto is "Never graduate!"

https://github.com/atomicobject/heatshrink, by @silentbicycle, sounds like it might be up your alley.

I wrote about this here: http://somethingdoneright.net/2015/07/30/when-object-orienta...

Comments welcome.

Attempting to get a job at 1 of the Google/Apple/Facebook/Amazon/Microsoft quintet of big companies that pay well, though, is quite doable, in spite of the noisiness of the process. mxcl got a job at Apple (working on Swift's package manager, no less[0]) a short while later.

[0]: https://github.com/apple/swift-package-manager/graphs/contri...

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 :)

If you'd like to see an attempt at the best of both worlds (Smalltalk and Lisp), check out Robert Krahn's work on Cloxp: https://www.youtube.com/watch?v=qQvvgzvPgQI

If it's helpful, the original implementation of Arc was actually quite similar to this - a bunch of macros that compiled down to MzScheme (which eventually became PLT scheme, which eventually became Racket!).

Short answer: yes, jump right in!

Check out David's other blog posts, ClojureScript synonyms[1], and http://clojurescriptmadeeasy.com.

http://himera.herokuapp.com/synonym.html