jdp

I'm doing my small part by paying for websites that respect me in the way TFA describes. I have annual subscriptions to Defector, Brand New, and DIELINE, and I'll add more as other websites follow their lead. Maybe it'll become too much to manage one day, but it might be for other readers too, and then maybe that will pressure our card companies and banks to start providing some more useful consumer services. We need enough people to actually subscribe to these websites to make that future happen though.

The divergence between users and programmers became more pronounced over time. When command line interfaces were dominant they naturally made programmers out of users, even if they didn't realize it. CLIs made “using the computer” and “programming the computer” effectively the same activity in a lot of cases. A command someone entered to run a program was itself a program. Entering the previous command again and modifying it, for instance to pipe the output of the first program into another program, was also a program. Once the desired result was achieved, that final command could be saved and used again later. Or shared with someone to be used as-is, or to be tweaked a little bit for their own use case.

Each interaction with a CLI results in a valid program that can be saved, studied, shared, and remixed. That's a powerful model for the same reasons the spreadsheet model is powerful: it's immediate, not modal, and successful interactions can be saved as an artifact and resumed later. Can we do the same things for GUIs? What is the GUI equivalent of pressing the up arrow key in a shell, where I can recall my previous interaction with the system and then modify it? Can I generate artifacts as byproducts from my interactions with a GUI system that I can save for later and share with others?

Stamp collecting is a good outlet for research as leisure. If you're the type of person who falls into wiki holes and likes talking about what you learn with other people, it might be for you.

Many stamp collectors follow the research-as-leisure framework naturally as part of their hobby. The article outlines cultivating curiosity, developing questions, gathering evidence, developing answers, and building communities around that process, which is basically what collectors are doing when they're talking about stamps and other philatelic material. They're sharing discoveries they find interesting, often only after identifying the material, looking up its historical context, drawing parallels to current events, and then formulating some kind of answer or conclusion that makes it worthwhile to share what they've found.

I think the experts in a lot of hobbies engage in this sort of recreational research for the joy of it, but it's closer to the norm for casual collectors. There is a whole wide spectrum of collectors though, ranging from aesthetics-driven folks who spend more time on thematic album pages than on researching anything, over to experts in narrow areas like Transylvanian hotel stamps who publish whole books on about how they weren't valid for postal use but were used by hospitality workers nestled up in the Carpathians to get mail from guests back into the official mail stream because the state couldn't be bothered to service up there. If you get into it you'll find there are a lot of curious and motivated people in the middle who are happy to share what they've been reading about (or listening to, or watching) lately.

Nice work with the guide, the bevy of examples makes it easy to digest.

The colon being used in multiple contexts is tricky. As I was scanning the examples I found postfix `:` doing type conversion like in `(%)\. {%/Apple/}{`3:}` and then I was wondering what it does when it has nothing on its left-hand side, like in `[(+)|0 [:1"x]`. Then I noticed that the [ were unbalanced in the latter example, and eventually figured out that `[:` is its own operator separate from `:` and the middle `[` had nothing to do with function syntax.

I wouldn't consider the industry backing of Heroku and a collective 4,500+ GitHub stars between the tools particularly niche or obscure. Crank it up to ~20k stars if you want to count deploy tools that can use them, like Dokku or Flynn. Anyway, the other great thing about Procfile is that it's just a declarative format. Lots of tools can leverage them, and they are an important part of my and many others' workflows.

I also don't think the article is too keen on "standards", judging by it referring to make a "task launcher" and the suggested usage completely diverging from the expected behavior of the program.

The example isn't a makefile, it's a procfile.

ffmpeg can utilize streams, in both input and output. The trouble comes from different codecs and containers, especially on output. Some formats aren't append-only—the prime example being MP4 + h.264—and so ffmpeg needs to be able to write to a seekable output device, ruling out streaming output in those cases.