People no longer talk about "the camera," by which I mean the family camera.
Despite what "the" literally means, it's not so much that American middle-class families1 in the 1990s usually had only one camera. it's more like there was a designated family camera. There were cheaper (and hopefully sturdier) cameras aimed at kids and in many homes there's probably some disposable cameras kicking around.
Even though I am going so far as to write about it, I have only vague memories of the first camera. I think it was a Canon. Now I'd probably consider it an entirely ordinary, albeit well-constructed, point and shoot, but at the time it had a sense of weight--and not just because my weaker arms would have struggled a bit to hold it steady2. I did not really understand photography, although I was aware of film, having had a very cheap camera with a translucent outer shell I thought was cool.
I have a better memory of our family's first digital camera, which was a Sony. While not rivaling what a good photographer could do with any film camera or digital SLR, in daylight it took pictures that could be developed into 3x5 prints fairly comparable quality to the film camera it replaced. It was very limited, of course. My dad worked in IT and was (and is) a geek, so I think he was slightly ahead of the adoption curve. He probably paid a little more and accepted a bit lower quality than other people might have. (Although he did do photography as a hobby and has a detail-oriented, do it right mindset, and a lot of people don't care that much about photo quality, so perhaps he didn't actually accept lower quality than the average person.)
I don't know that we ever had a family camera after that, not quite in the same way. The three of us children grew up, and so did digital point-and-shoots. I had one (a Canon) and a few years later, so did my sister. My brother, perhaps because he was more into music and so money and gifts were directed that way, did not. My dad got a dSLR and then eventually I did as well. I had a camera phone late in high school but the quality was mediocre.
My brother and sister-in-law bought a dSLR a few years ago but they don't really use it to my knowledge. So they technically own a family camera but not one meriting the "family camera" title, either. I'm not sure any other young families I know have single designated cameras, either.
I have pretty complicated about smartphones in general, particularly how they enable us to be always on social media, but in terms of how the fast majority of people use their smartphone's cameras, they're a clear positive. Being able to capture memories, snippets of information, a picture of that funny sign you saw, or a weird bug is just so useful and enriching for most people.
I still miss the ceremony around the family camera, though. Families often had what was sort of a "camera of record" whose pictures would not only be developed, but likely kept in albums (or at least a box) everyone knew the whereabouts of. There's an extent this record was staged, people carefully corralled before the button was pressed. And of course there's a lot of staging in what pictures you decide to showcase or keep at all.
And of course, one good, if slightly wasteful, thing about film is that it almost always would be developed into at least one print. It's great we don't waste paper and ink on mistakes or on the five or six attempts at getting the shot we really want, but too many pictures today live wholly digital lives.
Given how long cameras had been around by this time period, my sense is this spanned much of the middle class and working class families and was not just an upper-middle-class luxury. (Of course some people simply aren't that interested in taking pictures, but I'm making a point about class here.) I would like to look more into this but I'm probably exceeding the amount of time that makes sense for this post.↩
my niece and nephew are fascinated by my dSLR, which led to one case where my three-year-old niece, against my better judgement, carried the camera without me holding at all, almost staggering with it in her small hands.↩
two lesbian diplomats have to decide between prioritizing their burgeoning romance or their commitment to nuclear disarmament just after the dawn of the gay rights movement. (R; 1:49)
Bill Laimbeer's Combat Basketball. I don't even know who Bill Laimbeer is (although he is well known enough to be a recent answer on ESPN Jeopardy!), but it is a great title.
Recently a project to create a new Pascal compiler flitted across my radar. Since it's vibecoded, I'm not going to say much about it. Instead I want to talk about my dreams. I'm trying to keep these semirealistic in terms of things that are definitely achievable.
The biggest one is documentation. There aren't great resources for getting up to speed on Pascal if you're doing so post-2000. The reference documentation is fine, but it either needs more examples or we need a community site like Clojure and some other languages have that adds community-created examples. The reference documentation's examples also can be hard to find.
I also think the documentation could benefit from being clearer about what is actually the "blessed" approach
It would also be great to have better error messages, ala Rust. That's a huge project for any compiler, especially if you're adding it to a pretty old codebase. I'm not going to pop in a year from now and be disappointed it didn't happen.
Free Pascal supports many SIMD instruction set extensions, but the latest is apparently AVX2, which came out in 2013. It's not clear how much autovectorization it does, and I have a sneaking suspicion there might be other gaps even if you're willing to manually adapt code to SIMD. So more of that would be great to see. That's definitely a lower priority, though.
I'm of two minds of eliminating many of the older targets and compatibility features like the vibecoded project I alluded to above does. Clearing that cruft could potentially allow the project to move faster. And while the vulnerability-finding capabilities of AI are often exaggerated, that old code is probably are more of a liability than it might have been two or three years ago. On the other hand, it's great having at least some tools that have a foot in the present and in the past. It's great to have some way to cross-compile for old platforms on a new machine. I'm inclined to perhaps drop features that don't work or can't be tested realistically but keep what can be. There might also be some extremely granular compatibility flags that aren't useful by themselves that it might make sense to remove.1
Another way to look at it is that I think the only things I would trade the DOS compilation features for personally are security and better error messages. (I guess technically I see documentation as also more important than the DOS port, but I don't think the DOS port is really an obstacle.)
Perhaps it's because I am old enough to have seen so many valuable things frittered away. Sometimes it's because the new owner thought they could strip it for parts or wanted to bleed it dry, but other times because they thought. Free Pascal's stability is one of its strengths, and even if none of what I wished for here comes true, I hope I will still be able to use it for much the same programs I have so far long into the future.
like perhaps we don't need the ability to switch between Amiga/MorphOS calling conventions. I'm being serious by the way.I don't know whether that's a necessity to have a useful Amiga/MorphOS compiler or if hobbyist use today just uses one specific calling convention.↩
Come and See is a really unique and haunting Soviet anti-war movie. There's a contention that movies cannot be truly anti-war because cinema, even if it avoids glamorizing war, nonetheless turns it into a spectacle. I don't think this film settles that debate, but to me it suggests that an anti-war movie can't be straightforwardly cinematic. A lot of media criticizing war is satirical. Come and See is perhaps satirical in parts but it is not predominantly a satire. What it is is surreal and unflinching and willing to show the undignified parts.
Nordic chips are so efficient, you don't need batteries anymore . One of my favorite posts I wrote on Cohost involves some back-of-the-envelope math to determine whether you could power. This video is much further, and involves powering a chip based on tiny photodiodes. Perhaps it will be the thing that motivates me to get back into electronics like I've been meaning to do.
Why Are Movies about Research So Addictive?. I've been mesmerized by movies like Spotlight and All The Presidents' Men, and Patrick H Willems and team do a great job breaking down what makes them compelling. Better yet, there are plenty of recommendations of movies to check out.
Two things you can't see any more, unfortunately, but may be of interest if you're looking for artists to put on your radar1:
A Broad Sweep of Sky at the Madison Museum of Art is a thoughtfully presented collection of Regionalist pieces. I think it does a good job about acknowledging the limits of the movement—most notably its whiteness. It also features artifacts from the progressive movement, which as a Wisconsin leftist, I always like to see.
Radiant Vision. You've definitely seen Keith Haring's dancing, dynamic figures, often embracing or hugging or holding up a heart.
admittedly a funny thing to say about exhibitions that include Grant Wood and Keith Haring.↩
one thing I've been thinking about in conjunction with AI—when i feel disheartened lately, i start to feel like everything is in conjunction with AI1—is how efficiency is a terrible sole metric. it's probably as bad as money, which is a famously bad thing to optimize for2.
now, i love it when things go faster, at least when they're boring or an obstacle to something more important. while there are merits to slowing stuff down, at least some of the time, i'm not going to talk about those. instead, i'm mostly going to talk about the disadvantages besides that, ones that may exist even if you want stuff to go faster.
caveat two is that i also love energy efficiency. it's exempt from the things i'm talking about here. (i'm going to get to the reason why i think that' so in a bit.)
so what's so bad about efficiency? to me, it's that it has become the thing to improve. i feel like if something makes some process faster, i'm immediately on the back foot. if there's an argument about efficiency, the people with the most efficient solution have a gun and your arguments based on accessibility or environmental sustainability or even customer happiness feel like knives.3
to bring it back to ai, in a workplace setting, i feel like admitting that ai makes a task more efficient is equivalent to conceding it should be done for that task.
we see this in other ways. of course, they're going to make you wait for customer service representatives to be available because having enough capacity to minimize waits is inefficient. of course, amazon is going to cut breaks down to the fucking bone because taking marginally longer breaks is inefficient. of course they're going to make doctor's appointments shorter and shorter because that's more efficient.
shitty customer service phone trees are yet another example of this, but instead of saving time by making support questions be answered more efficiently, they're saving time by reducing the number of questions that make it through the gauntlet. it's efficient for their bottom line. in theory they save time when you do make it to a living person because the information is gathered already. who knows if that actually pans out.
you might have noticed i set some parameters. this is related to why i think energy efficiency tends to be great—it's often engineering, all about the consideration of tradeoffs. it's not perfect, but it works pretty well, and i feel like many of the examples of energy efficiency upgrades being bad are rumored or speculative or fictional 4. like there are CFLs and LEDs that can't dim or have unpleasant color temperatures but i feel like it was only a brief time that these were the only CFLs you could get. and when LEDs, which are even more efficient, came out in lightbulb sizes 5 you could always fall back on CFLs if you couldn't find one in the ideal configuration.
okay, i have one example. i have encountered automatic faucets that don't stay on long enough. i'm not sure whether these are actually due to people overfocusing on saving water or if it's just due to people not doing a good job of setting them up right. a much bigger problem with automatic fixtures in bathrooms is them not activating reliably.
it feels a bit lazy to say this, but part of the answer is just balance. feel free to delete form fields that you don't need the information for. that saves employees time and the time of your customers/patrons/clients. but don't try to pair that with some sort of manic countdown that stipulates how long employees can take on the form.
the other lazy-but-true answer is to end capitalism. optimizing for money and economic growth is no way for a society to live.
i feel like i may have lifted this phrase from somewhere, although i think it was talking about COVID, not AI.↩
even many capitalists will acknowledge that optimizing for just money is no way for a natural person to live, even if they think legal persons should live that way. the extent to which making everything subservient to capital forces people to optimize for money is seemingly lost on them.↩
in the best case we want to be in a collaborative setting and you're not trying to win. sometimes workplaces are like that, but not always.↩
e.g., I watched a King of the Hill episode a few months ago about low flow toilets that were so bad they resulted in more water used. Maybe there were some genuinely bad low flow toilets around the time this episode was produced, but i think when i've encountered toilets that don't use enough water to properly flush, they're broken. during the episode we learn the committee responsible for resource-related rules (or ordinances? unclear) is corrupt and only recommending low-flow toilets because a member sells all of the ones available in town, so i could see the argument that this episode was more about corruption than low-flow toilets.↩
i think this was mostly a light spectrum thing, not the size itself being a problem to manufacture. and checking wikipedia, i seem to be correct.↩
I accidentally published a post, The Washington Editorial Board's Mask Slipped. Well, I think it was accidentally. It was basically a complete post, just a short one. However, since it didn't have a date, it ended up way in the back of the posts.
I didn't want to date it now because it it isn't really new, so I dated it close to when I (accidentally?) published it. But I did want to say something in case people who missed it want to read it now.
To be clear, this isn't one of those thoroughly rotten takes that makes me think less of the writer, like the stuff Sam Altman says approximately once every six news cycles, or Thomas H. Ptacek's weirdly hostile post about his friends who don't like LLMs.
That being said...I have a lot of doubts.
Part of my reason for skepticism is that AI is relentlessly pitched as a way to go faster. Formal verification, for all its benefits, generally makes you go slower. Kleppman's logic seems to be that Speed(Formal verification + LLMs) >= Speed(regular coding). I'm not sure that's true, but even if it is, I'm not sure companies will want to give up much of the (perceived) speed benefit, even if they're still somewhat faster on net.
The other thing is that formal verification seems like the kind of thing that would take a long time to pay off, and, with the exception of people planning multi-year data center construction projects, AI has not been a situation where people are exercising patience.
I also strongly suspect AI is appealing because it allows for spending less on employees. Having them learn formal verification would make them cost more, both initially as your current developers have to take time to learn it, and over time as your less-senior developers have a longer learning curve.
Now, these observations are for the industry as a whole, given that Kleppman was saying it would go "mainstream." But perhaps LLMs will still make them mainstream among more quality-conscious developers, the sort of people who test pretty aggressively but haven't added formal verification yet. As critical as I was of the start, maybe someone like Thomas Ptacek would do it at a place like Fastly. Ptacek seems like a genuinely capable guy, hostility in that area aside. That's more likely to me, and I would be genuinely interested in seeing their results, even if what I really want is for developers to demand more and higher ethical standards for what they produce and the tools they use.
Beyond industry and societal issues, the more technical reason I'm skeptical is that AI coding assistants sometimes will just delete stuff leading to errors rather than meaningfully fix them. It seems like an AI might just loosen specifications, add exceptions, or even delete them. Perhaps it's clear enough when they do that for it not to be a problem or there are other features of formal verification that make that harder. However, given the average developer doesn't have much experience, I'm not very confident they will build that experience. And even if they catch the assistant cheating, they might not know enough to prod it in the right direction or fix it themselves.
If I'd have to guess, Martin Kleppman has a lot more familiarity with formal verification than I do, so perhaps he's thought of this issue. Of course, a PhD doesn't prevent you from talking out of your ass. (For some people, it merely enables them to do it with greater authority in front of larger audiences.) Still, my money's on Kleppman knowing more than I do.
The other technical reason is that there's not as much formal verification code to learn from, and I don't think formal verification is quite similar enough to other languages.
Interestingly, formal verification has been seeing more attention on Google. It does get less than other testing methodologies. Looking at the data behind GitHub's "innovation graph" shows that some of the most common theorem provers and formal verification languages are varying and seem to have peaked as a group in 2023, although 2025 is incomplete and if scaled up (doubled because we have just the first half of the year), it would be in the ballpark of 2023. This depicts the number of people who've pushed code in that language. (GitHub chose the...interesting...name "pushers" as shorthand.)
language
'20H1
'20H2
'21H1
'21H2
'22H1
'22H2
'23H1
'23H2
'24H1
'24H2
'25H1
Agda
244
429
259
271
306
283
982
1011
274
267
347
Alloy
156
287
1013
1015
318
259
311
Coq
5387
4315
3060
2671
3220
1805
1782
1736
2038
2566
2294
Frege
115
Idris
104
405
103
212
104
110
790
720
118
109
Lean
112
232
254
391
348
464
475
821
1141
1636
2219
TLA
390
394
430
464
483
612
697
1234
916
715
933
Total Result
6237
5890
4106
4009
4617
3561
5739
6537
4687
5561
6213
The total row probably counts people twice.
Of course, the prediction is that formal verification will go mainstream, not that it already has. So the fact it there isn't clear growth is mostly absence of evidence, especially since the first half of 2025 was pretty strong and the Google Trends data suggest that either it got started very early following the first releases of GitHub copilot or there's some other trend increasing people's interest.
I'd love to be wrong about Kleppman's prediction. Formal verification has always seemed like an underutilized tool and one I've been meaning to learn some day myself. And of course, as a software user I'd love if software were more correct and reliable. The best case is that formal verification ends up being less scary once they've seen LLMs produce it, developers actually learn what it is about, and software gets genuinely better. The worst case is probably that developer unfamiliarity prevents the vast majority of verification from actually verifying much of anything, and it becomes a reflexive defense against critics, a rhetorical counter-move for when people bring up hallucinations.
Since I made this table aggregated by year already, here it is
It's been a while since the prior (and inaugural) media of interest post, so here's another!
MythBusters. I recently discovered that MythBusters has posted full-length episodes on YouTube. I enjoyed it growing up, and it holds up, although it definitely is a product of its time (mostly in harmless ways). It is a bit inconvenient to find the full-length episodes because it seems like they've taken a lot of them down.1 It's probably less informative, strictly speaking, than the average documentary, but it is a lot of fun. I think the spirit of thinking through problems and figuring out how to test them safely really shines through. It honestly has some parallels to software and data analysis projects I've worked on2, which I think is less to do with software development specifically and more to do with the overall structure of problem solving.
Queens at Heart UCLA made this documentary about transfeminine people (not using that term) back in the 1960s. Most of the people profiled seem like they'd use the term "trans women" today. I would love if someone caught up with any one who's still surviving.
Doppelganger by Naomi Klein is a fascinating book that I am on the verge of finishing. It manages to be both a great analysis of our current era and the initial stages of the pandemic. Its discussion of antisemitism is also very relevant now with both the rising tide of actual antisemitism and disingenuous use to deflect criticism of Israel. There's the occasional thing that perhaps is irrelevant or didn't quite hold up, but that's the risk about writing about very recent events, IMO.
I would be remiss if I didn't mention Grant Imahara, who died in 2020, and was a cast member of MythBusters, or Miss Major, who wasn't featured in any of these media but did survive that era of Queens at Heart and died recently. We're poorer without them.
I don't know if the idea is to have a rotation or they're uploading higher-definition versions or if there's some internal push and pull about how much to make available for free versus how much to withhold for a streaming service.↩
E.g., for some data projects, I've done a "scale model" before pulling down huge amounts of data.↩
thank you jesus christ in advance of giving me the power to do this. I hate this game on a fundamental level, I think it is evil, and it is through your power that I will complete this game that will make me a true nintendo fan to have added to my game co…
hey friends, gonna start this one off with a request: i’m currently without stable housing and without employment, and i’m in extremely dire financial straits. as of this writing my account is overdrafted and i have very limited options for fixing that. i…