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.
Great! So it's not just me! As I understand the paper, their main point seems to be that as you extrapolate out in time, you need to not just handle the physics of CO2 that is already in the atmosphere, but predict say how much populations will grow, as well as how much GDP will grow, and how CO2 emissions will be effected by that. So, say if there is an economic recession, then there will be less CO2 produced than if you predicted just say steady growth. This seems to be a case where I could see different assumptions (some reasonable) leading to different results--it's a far cry from say the breast cancer-vs skin-cancer mistake that he leads with
I think the point is that the actual emission are on the low side of the IPCC scenario bounds, and are tracking to exit completely the IPCC scenario bounds around 2021.
#!/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.
> 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'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
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.
I'm glad you pointed this out. That's way mal-informed for how you'd build that DOM in clojurescript. I mean, you _could_ do it that way, but there are libraries (like hiccup) that make it more natural.
Here's an example of a react component from the re-agent tutorial (http://reagent-project.github.io/), e.g., but you'd build straight html in the same-ish way using a library:
(defn simple-component []
[:div
[:p "I am a component!"]
[:p.someclass
"I have " [:strong "bold"]
[:span {:style {:color "red"}} " and red "] "text."]])
The point wasn't to show how to build HTML fragments, the point was to show javascript interop.
You could create a nice wrapper-library around anything in any-language, really, but that misses the entire point of that example: to show how interoperability is when you haven't wrapped a nice wrapper-library around everything.
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 was mentioned as a criterion. Actually, multiple:
- "Perfect IDE support" when described hinges on types
- "Static Optimizability" specifically mentions enjoying
type-driven AOT optimizations
- "Solving Real Problems" mentions types in the
"Refactoring is Painful", "'Non-trivial' abstractions",
and, briefly, in "Scala.js Solves Real Problems"
Furthermore, all of OpalRuby, Python, and CoffeeScript were explicitly dinged on their failures to have statically analyzed types.
But yeah, it does feel like he didn't give ClojureScript as much examination.
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.
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.
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...