medstrom

Appreciated this storytelling, it exposes some real procedural knowledge about using the Internet Archive.

The prompt is the code :) The code is like a compiled binary. How long until we put the prompts in `src/` and the code in `bin/`, I wonder...

Consider your biases about the word "hobby". It's easy to average way more than 40 hours per week on a hobby, and to spend those hours with as much deadly seriousness as the hours at work. Especially if you don't work full-time or don't work at all.

But you can be a software dev even if you do not work in software dev. Plenty of those individuals in open source, for example.

I, too, appreciate the clarification in the term "write-only code".

Still, isn't the forecast for one hour from now more useful than literally now? You can see that through the window (and feel it on your face by opening the window).

I don't see that TFA claimed any cost savings. That is not the reason people go for e-paper.

TIL a built-in

   (zone &optional PGM)

   Inferred type: (function (&optional t) t)

   Zone out, completely.

That's not so dissimilar to my experience in 2025 with whatever USB drives I can scrounge up around the house!

The issue isn't really Android, it's the touchscreen and the way the UX is a regression from many analog single-purpose devices.

If you gonna have a single-purpose device - make it analog (or close to analog)!

Don't give it a perceptible boot-time and all the other flaws that come with general-purpose computing. Don't make the user have to "wake up the device", let alone have to visually confirm that it is woken-up, before they can switch to the next song.

I loved the buttons on the Galaxy Spica https://www.gsmarena.com/samsung_i5700_galaxy_spica-pictures...

Now that I think about it, going no-buttons might have been a driver towards larger screens. Having at least a few buttons seemed to make it much less necessary.

There is plenty more for a cardiologist to do even if they solve the most pressing current problems. Hard to run out of puzzles in biology.

High LDL is correlated with the development of heart disease, but it does not cause heart disease.

You realize this sentence is an oxymoron?

Unless you meant to say "it does not cause the development of heart disease". I agree correlation is not causation.

tell the AI to write in the style of a HN commenter, or whatever.

This might turn out to be one of those tricks like Ctrl+C Ctrl+V that surprisingly few people discover.

...ChatGPT? Such an odd take, to point at weather being variable.

This is a coastal city at a fairly run-of-the-mill latitude, people build functional bike networks in much worse.

A discussion is held between people who don't (initially) believe each other. Nothing odd about it.

Not clear in your example if you have a to-dont list, or just decide "don't" in the moment.

You mean... an aha list?

There are tan-thru clothes, if you want to be serious about it.

The 2 y/o example isn't very good, I can only imagine that they'd perceive last year as pretty recent, compared to how I perceive last year.

Damn, the 80s felt that recent?

Self-updating too!

Plus, in my experience when I make a separate user manual... a lot fewer people read it.

If it seems odd, maybe it's not what they're doing.

Also thinking about this. Requirements I've identified -- and this is why people give up and just run Emacs on Android:

1. Able to natively edit and view same file type on both devices, be it .md or .org or whatever you choose (there are more apps supporting .md, if you can stomach that)

2. Links must work on both devices! That alone means it's not trivial, even if you have a lightbulb moment and use .md files for access to more apps, together with one of Emacs' filetype-independent links like Hyperbole or Denote, because no .md app will support those links. Conversely in .org, not all apps even support Org-ID links... especially not making it easy to insert such a link.

3. App must have satisfactory editing facilities. I know at least one app that doesn't even let you indent/dedent list bullets...

4. If you use TODO tasks, the app needs to make it convenient to see them at a glance across all files. Many Org apps fail here and either basically assume you have like one "todo.org" file and need no hand-holding, or even if they list all TODOs, there's no way to sort or filter, or it only lets you see them but not toggle them to DONE!

5. If you use a wiki-style workflow such as org-roam, so that you have far too many small files to keep track of, the app needs to make it easy to browse. Many apps fail here, just showing you a file list on the assumption that you even know what your files are named or what's in them. Count your blessings if there's at least a good search facility.

6. Instant & reliable sync. Logseq Sync is too buggy (at least it was in 2023). Things like Syncthing just aren't good enough if you don't also host a server that is always on. If sync conflicts are frequent, I'll be so wary of editing that I stop altogether.

Big difference in portability between a foldable keyboard and a full laptop.

IIRC, putting pipe operator `|>` at end of line prevents the expression from terminating early. Otherwise the newline would terminate it.

That's almost concerning. I wonder if it'd be realistic to

1. put up a whiteboard somewhere

2. observe with some regularity what your routines are right now (non-judgmentally)

3. write them down (descriptively, not prescriptively)

4. update over time

Then you'd get the chance to notice your routines changing.

There's kinda not much to it. It's just that you have:

1. a full-fledged programming language

2. no namespacing (nothing is private)

3. no modern GUI concepts to take into account (no CSS `flex-direction`...)

4. no edit-compile-run cycle

5. people have written extensions for many decades

6. people always write extensions with the possibility in mind that their extensions may be extended

Then you can probably see how it works, with just your imagination!

Of course there's a number of epiphanies that may be needed... Like how the principle "compose many small Unix programs with text as the universal interface" is just like "compose many functions with return values as the universal interface", or that it isn't an editor and more like a terminal (with integrated tmux-like functionality) that you decided to turn into an editor, or that an editor waiting for text entry is just stuck in a `while`-loop of reading the next input character, what even is a shell, what even is a computer, etc etc.

Reminds me of "default to null":

The mental motion of “I didn’t really parse that paragraph, but sure, whatever, I’ll take the author’s word for it” is, in my introspective experience, absolutely identical to “I didn’t really parse that paragraph because it was bot-generated and didn’t make any sense so I couldn’t possibly have parsed it”, except that in the first case, I assume that the error lies with me rather than the text. This is not a safe assumption in a post-GPT2 world. Instead of “default to humility” (assume that when you don’t understand a passage, the passage is true and you’re just missing something) the ideal mental action in a world full of bots is “default to null” (if you don’t understand a passage, assume you’re in the same epistemic state as if you’d never read it at all.)

https://www.greaterwrong.com/posts/4AHXDwcGab5PhKhHT/humans-...