phleet

10,000s of tons of CO2/year: how much we can remove from the air in 2023

1,000,000,000s of tons of CO2/year: how much we need to remove by 2050

We need to double our capacity every 21 months for the next 27 years

Hi! Author here. Agree it could be more discoverable. The feed is here: https://jamie-wong.com/atom.xml

I worked at Khan Academy for two internships and then just under 2 years fulltime, and don't know anyone that has anything less than positive to say about Kamens (nobody called him Ben because there were no less than 5 Bens at Khan Academy when I left).

One of his most memorable habits to me was coming into a meeting room where his words obviously had a lot of sway, then sitting on the ground when we were short on chairs.

He was an inspiration to many, first as an engineer, and later as a manager, and I'm excited to see what he takes on next.

(Author here) I cheated: to prevent that steady state (since it's ugly), I have 3 dye injectors strategically placed, causing certain areas to get redder, greener, and bluer over time.

Without that, yes, it turns into a muddy grey.

Author here -- I also just published a new post on ray marching, which you might find interesting if you find this post interesting: http://jamie-wong.com/2016/07/15/ray-marching-signed-distanc...

My luck on HN has been not so great. All in all, I think my posts have reached the front page ~5 times, only 1 of which I submitted. But oh well! Glad they get there somehow and people like them!

Webpack's algorithm for doing this is not black magic -- it has to consciously consider the same tradeoffs as were involved in this post. How many chunks should you have?

Haha, sorry, that was me. I was eating my words, because it looks like there is support!

The experiments described in this post were conducted early this year, and it looks like those developments are fairly new?

I just discovered this too: https://github.com/GoogleChrome/http2push-gae

Is this new-ish capability documented somewhere?

We're playing around with inline-styling our components, but pushing the inline-styles into CSS injected into `<style>` tags in the head. It's experimental at the moment, but it's being sent into production shortly: https://github.com/Khan/aphrodite

This is a hard generalization to make, but it's certainly true in the worst network condition case. Even if your client-side rendering happens instantaneously and your JS is (magically) 1kB, it's still 2 round trips before you can render anything instead of 1 (well, 4 instead of 3 for TCP connect, SSL handshake, HTML response). On poor mobile connections, a roundtrip will be 500ms+, so if you can render in less time than that on the server, it'll feel faster.

I've been looking for something like this forever! I loved AutoIt v3 on Windows, and osascript always felt super crippled in comparison (as well as impossible to look up documentation for). I've long since forgotten what I wanted to use this for, but I'll be sure to remember this for later!

It's a lot harder to reason about memory constraints on recursive programs.

The clearness and correctness of the code often ignores the possibility for stack overflow. Most naive implementations of DFS will hit the stack limit given trees that are all one long path from a single root to a single leaf.

Thank you for posting this!

We've done similar performance analysis at Khan Academy by using the navigation timing API and throwing the data into graphite. The most interesting part of this post for me is seeing that the numbers (server side times, median client times) are roughly the same as ours (http://i.imgur.com/wKglMTc.png)

One thing that I see in both GitHub's data and our data is this daily-periodic increase in both server and client times. Is that just load? We had theories that the clientside spikes may be caused by users in less CDN covered areas, or an increase in mobile usage, but were never fully satisfied by those explanations.

They don't inherently have to be sampled.

Just like you can define the perimeter of a circle given constants (x_0, y_0, r):

(x-x_0)^2 + (y-y_0)^2 = r^2

you can define the perimeter a metaball on a list of (x_i, y_i, r_i) as described in the post.

Beautiful page!

One small nit: when loading up the page on a mac, I see OS X window chrome around the examples, but Windows style C:\ file paths

The link to "Assembly" in the page footer is broken.

Can someone explain to me the migration path towards ES6 and syntax like this? This isn't syntactically valid ES5, so is there a reasonable path to making the browsers run ES6 directly?

If I just include it in a <script> tag directly, it'll throw syntax errors in any non-es6 compliant browser. So I'd have the transpile, and send down the es5 version of the code.

But if I'm transpiling, what's the point? I still have a build step, so why use ES6 over another compile-to-js language? The eventual promise, that years and years and years from now, all the non-es6 compliant browser will be dead, so I can send down the es6 code directly?

The difference here is that in Python vs C, you almost _never_ actually need to know what's going on under the hood[1]. Whereas in every framework I've _ever_ used, I eventually need to dig into the guts of them because of some leaky abstraction. For instance, automatic data bindings are great until you want to do animation[2].

I do agree that LOC for a _non trivial_ application is a reasonable measure, though I disagree that Angular:Backbone is Python:C.

[1]: Serious performance optimization is the exception here, but in building CRUD apps, this honestly did come up infrequently, and usually the right thing to do was to improve algorithmic complexity or fix slow DB queries, not fix python constructs that were unexpectedly slow.

[2]: I haven't spent much time with Angular specifically, but definitely remember this being difficult in other automatically bound frameworks, like Meteor in its initial release.

It's definitely totally fine to build these things for fun, but with a landing page like this, it seems like the author built it for some purpose beyond that, otherwise I don't see the point in presenting it in this form.

If the author wanted to learn _and_ get publicity, a blog post or at least including a "why" section that says "just for fun" on the landing page would seem suitable to me.

There probably is some interesting motivation for doing this, it's just not clear what it is.

Promises aren't just about keeping things flat.

The biggest value to me is being able to avoid the passing around of callbacks and them relying on varying conventions (some async are function(args, ..., callback(err, data)), some are function(args, ..., callback(data), errback(err)), some are function({success: callback, error: errback})).

Promises solve this problem by not passing around callbacks _at all_. Instead you return the promise and let the consumer attach the callback itself. And once we have promises widely available and part of the standard library, the calling conventions will be standardized too.

EDIT: I agree that as it stands, the lack of standardization of promises (jQuery's are mutable, for instance) is a pain, and that documentation could certainly be better.

I take a bit of offense of not being referred to as the "actual" Jamie Wong. More important in the context of the startup world, more prolific sure, but this seems needlessly dismissive.

Sweet - always good to see people using my stuff in the wild :)

If you're interested in reading the data with KCacheGrind, you can do that using pyprof2calltree: https://github.com/pwaller/pyprof2calltree

The result ends up looking like this: https://f.cloud.github.com/assets/150329/1570121/5713f02c-50...

I agree that this usage isn't really in line with how it's used in mathematical proofs. Do you have a better concise suggestion I can keep in mind for next time?

Done.

Agreed. I suppose the more important test for library code is "googleability" rather than "greppability".

I've done a bunch of work with statically typed languages and am not about to argue that dynamic languages can be as easily navigated or statically analyzed by IDEs as statically typed ones can.

That said, dynamic languages still have a great deal of value, and a significant portion of the programming population uses them, so I still think it's worthwhile to set down some useful rules of thumb.

Agreed. I do comment on dynamic invocation being more problematic when I say "As a broad generalization, I would say dynamic declaration is occasionally worth the tradeoff, but dynamic invocation is almost never worthwhile.", but it perhaps should've been a larger part of the thesis.

Your example of adding a comment mentioning the methods called in there would indeed pass the Grep Test, and is a reasonable compromise when there is a real call for dynamic declaration.

I think there are definite ways of adding metaprogramming functionality without breaking this test. For instance, in the first JavaScript counterexample, if the iteration was over [{attr: "position", fn: "getPosition"}, {attr: "direction", fn: "getDirection"}] instead, the Grep Test passes, and you get much of the same benefits, with a very minor duplication that I'd argue is worth the cost.

I have no problem with autoloading classes (though I suppose me including "modules" in the list might've implied that). If a class is autoloaded, I can still find its declaration and implementation using grep.

As for "Not grepping the right file", I meant it should be findable in a project-wide grep, not in the file I assume it to be in.

functions passed as arguments are fine, because something needs to be passing them. While the function invocation site itself is dynamic, the source of the call isn't.

Basically the important aspect is that even if you have higher order functions, the things passing the functions to these higher order functions will still be greppable.