edits:

- b&w basemap
- additive RGBA composite rendering
- each line has low opacity (<10%)
- hue scaled to some interesting value, like heading equal interval

*glow map magic*

How I write fast web pages for displaying data:

morganherlocker.com/post/Fast-da...

Initial download sizes:

foxnews (21.62 MB)
wapo: (10.96 MB)
reuters: (9.28 MB)
nytimes (9.16 MB)
apnews (6.81 MB)
usatoday (336 KB)

This is a fair comparison to raise, but Java '96 had unforced errors IMHO:

1. insanely long start time
2. requires non-default OS dlls - if packaged together, exe's would have been huge (latest java download is 40MB compressed - maybe it was smaller back then?)
3. legendarily shitty installer

Silly example, but:

What if instead of sending a `meme.gif` (20KB) or a URL to a gif (1KB) to be viewed in a browser (300MB),

...we sent a `meme.gif.exe` to be viewed in a self-contained standalone viewer (20KB gif + 80KB exe).

The standalone executable GUI/graphics program I'm working on currently weighs 289KiB, with minimal effort to optimize it so far. I love the shareability of web apps (just copy+paste a URL), but maybe there's a tipping point favoring the shareability of tiny exe's at some point on the size spectrum.

"Program Files (x86)" vs "Program Files" has major report_final_final2.xlsx energy.

This is my read as well. The core principle is to avoid marks that don't convey intentional information, because they are distracting or actively misleading. Go wild with ink that does convey information. The last chapter even praises *maximizing* ink w/ high data density displays.

I'm in the process of setting up a cross-platform cmake setup for a project, and getting Windows working is... interesting. Even the projects trying to be "unix-y" like Cygwin are still heavily GUI driven and full of jank. I guess most devs just accept Visual Studio and heavy GUIs as a necessity?

It is 100% worth making this cultural shift, but its not a technical problem that gets solved with WASM. If every web dev started writing pages with C++/emscripten tomorrow, we'd be flooded in 300MB Qt pages before long.

I'm bearish on WASM as a widespread browser runtime because I have heard so many complaints about 5MB JS payloads over the years, where the proposed alternative is a 2GB python stack or something equally bloated. Without cultural shift to data-oriented code, I only see WASM slowing down the web.

elevation data map of Alaska/Canada/PNW

I am releasing globe.c, a simple tool I wrote in C99 for parsing/manipulating the NOAA GLOBE global 1km resolution elevation dataset. Here is a brief writeup on the CLI, along with a demo site for the project.

morganherlocker.com/post/globe.c/
morganherlocker.github.io/globe.c/

I started using Obsidian a few weeks ago for research notes and semi-structured issue tracking. It's so good that I nearly stopped using it out of fear of vendor lock-in, but I found that the storage format is really simple (just .md files). I'm using syncthing to have it work on multiple machines.

this proto generates 584 lines of C++, links to 173k lines of dependencies, and generates a 21Kb object file:

syntax = "proto3";
message LonLat {
float lon = 1;
float lat = 2;
}

It works best to define a *single* protocol that is shared across many orgs (OSS), and even then, pretty bloated without opting into light runtime mode. When it's used for everything as a sort of shared type system, the compile times & quantity of code produced is bonkers, even used sparingly.

protobuf is surprisingly awful for it's intended use case (gluing a big monorepo together).

Sliced optimal transport cartogram of some POI in the Foursquare data drop.

I was expecting to find a C or C++ kernel in all of these, but they stick close to the UI runtime, which makes sense. I also imagine the possibility of segfaulting your pancreas' control system is not appealing. This joins "spacecraft control runtime" for safety-critical JS app hall of fame.

Language breakdown of the 3 largest open source artificial pancreas loop systems in order of release:

1. JavaScript (OpenAPS / oref0 alg)
2. Kotlin (AndroidAPS, derived from oref0)
3. Swift (LoopKit)

LLM assists are metered over a net connection or use a fast local GPU pegged at 99%, and the memories of trying to type through input lag on an under-equipped MS Vista machine come flooding back. Like VS, time is spent debugging what a tool wrote instead of what *you* wrote. Complexity is fostered.

I dropped it for a few reasons: It was a hog taking precious GBs of RAM, tools often failed in cryptic ways, I felt disconnected from the build system and configs of my projects. It was essentially a black box and took debug time away from learning to build smaller, more efficient systems.

My 1st IDE was Visual Studio '10. It had incredible productivity tools that imho are unmatched to this day. Intellisense, a visual ORM, property editing to rival a modern game engine. It felt like magic, but it also held me back from understanding what I was making. I see parallels in today's LLMs.

What does 500M u32 pieces of information get you at hires, in a geo context? (ie: longitude, latitude, altitude, velocity, population, temperature, admin, etc.)

- lon, lat for 250M things (density viz ~free on GPU)
- 1 column for 166M
- 3 columns for 100M
- 98 columns for 5M
- 498 columns for 1M

Can you really expect a 10,000x performance delta? As an example, you can allocate a typedarray of 500M elements in around 100ms in the browser. An equivalent object will fail at this size and will start to see slowdowns in allocation and gc around 50k elements. That's a 10,000x budget delta.

Conditional optimization (adding an 'if' around expensive work) is an intuitive way to snag a 10-90% gain for many problems. What this misses is that each one adds a branch in the state machine (bugs) and obscures the 10,000x gains that are usually waiting to be had from reworking allocations.

"you should be made constantly aware of the full horror of what you are doing. [...] do always, then inhibit or ignore." (Carmack)

I went all in on this for the last year and it really changed the way I think about many problems, from data analysis to writing web pages.

bluesky feels uncannily similar to twitter in 2010. it's encouraging to see that the clock can be turned back on something big w/ good execution + serendipity.