- There are a lot of "probably"s in the article. I was also suspicious that the author didn't say they did any pre measurement runs of the code to ensure that it was warmed up first. Nor did they e.g. use V8 arguments with Node (like --trace-opt) to check what was actually happening.
- They seem to be working on it, but so far it's only available in preview builds? https://zed.dev/docs/dev-containers
- Shout out to Vivaldi, which renders RSS feeds with a nice default "card per post" style. Not to mention that it also has a feed reader built in as well.
- I've been down this rabbit hole too. I quite enjoyed Kenton's two episodes on SE Daily:
https://softwareengineeringdaily.com/2017/12/18/protocol-buf...
https://softwareengineeringdaily.com/2018/02/06/serverless-a...
- To me it sounds like one way to do this would be to have LLMs write Cucumber test cases. Those are high level, natural language tests which could be run in a browser.
- This is interesting, and I think worth trying. However,
Do not fool yourself. This is not "truly" "understanding" your "users". This is a model which may be very useful, but should not be mistaken for your users themselves.The process is iterative: Vibe code users <--> Vibe code software Step by step, you get closer to truly understanding your usersNothing beats feedback from humans, and there's no way around the painstaking effort of customer development to understand how to satisfy their needs using software.
- "Our users are morons who can barely read, let alone read a manual", meet "our users can definitely figure out how to use our app without a manual".
- That reminds me of BEM, where slow= is like the "element" within a parent "block".
- That is neat trick, and interesting to know that's how ssh git@github.com works, but that does not feel practical for a real usecase. Aside from relying on a scrape of the Github users API (there's no "look up user by pubkey" API), what if I wasn't expecting to automatically log in with Github?
- > estimates only an 80/20 chance of finding a suitable provider
I must be terribly fussy but this genuinely tripped me up while reading. What does this phrasing even mean? Is it an 80% chance of success? This seems like someone has heard the phrase "80/20 rule" and applied it somewhere it makes no sense.
- I have gotten code reviews from OoenAI's Codex integration that do point out meaningful issues, including across files and using significant context from the rest of the app.
Sometimes they are things I already know but was choosing to ignore for whatever reason. Sometimes it's like "I can see why you think this would be an issue, but actually it's not". But sometimes it's correct and I fix the issue.
I just looked through a couple of PRs to find a concrete example. I found a PR review comment from Codex pointing out a genuine big where I was not handling a particular code path. I happened to know that no production data would trigger that code path as we had migrated away from it. It acted as a prompt to remove some dead code.
- > "proves"
I like using the word "demonstrates" in almost every case where people currently use the word "proves".
A test is a demonstration of the code working in a specific case. It is a piece of evidence, but not a general proof.
And these kinds of narrow ad-hoc proofs are fine! Usually adequate.
To rephrase the title of TFA, we must deliver code that is demonstrated to work.
- I instinctually agree with nkrisc, but this is an interesting line of thought.
What's an example of something that nobody should be allowed to do e.g. on a laptop? If I buy a system with OS stuff set up from the get-go. What abilities do you withdraw from the user?
- If anyone is looking for a clean JS charting framework, I highly recommend Observable Plot.
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
- This looks great! I am diving right into the yak of producing a HTML version of this.
- Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine.
---
Short Passages (132)
[Context, or pre-links]
The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131).
[Problem statement]
Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves.
[Pattern contents here]
[Pattern summary]
Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall.
[Elaboration, or post-links]
Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)
- This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc.
In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway").
This is because you can't just take a pattern on its own; it forms part of a larger whole.
Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them.
This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day.
One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh.
*EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.
- Microsoft's cloud design patterns are quite well-written IMO, if you're into that kind of thing
https://learn.microsoft.com/en-us/azure/architecture/pattern...
- I think the government making stuff up is worth considering, but isn't it a kind of different threat model?
The hypothetical government isn't going to make stuff up about me, some nobody, on a flight to the US to be a tourist or something. They statistically don't care about me. However, the US morality police might decide to statistically care about everyone who watches porn.
But if I'm a somebody, say a former or potential whistleblower, or a local politician, etc. then a government might have a specific motive to do me dirty and not care about being honest.
I guess there's a wide and blurry line between being a "nobody" the government has no motivation to lie about and being a "somebody" that deserves special malicious treatment.
- The author says "skill issue" isn't a defence for Rust, but also says
"C/C++ (Experienced Developer)
Resource management is internalized. It's like driving a manual transmission - you don't consciously think about shifting gears, you just do it."
How is this not saying that C/C++ require highly skilled developers? Why is there not an equivalent "Rust (Experienced Developer)" section for those who internalise the borrow checker model and can use their freed-up cognitive powers for the same things the experienced C/C++ developer can? This is a double standard.
And like wow, CloudFlare had one outage where they messed up config file parsing. Good thing nobody coding in C++ ever shipped a bug that caused an outage!
I actually think I agree with a lot of the substantive criticisms this article makes of Rust, but man, it is so overstated and melodramatic.
- If they saved money, as they said it did, then... yes?
- I think there's a serious related issue which is that icon packs (font awesome, feather, material icons, whatever you prefer) encourage you to just pick the "closest" icon for a given menu item, rather than an icon that is actually what you want.
At work we do sometimes design custom icons for specific things, but that's very rare and relatively costly. Most developers on our team don't have that capability, and we are left trawling through Google's admittedly-large icon library to find something that seems plausible.
- For those interested, here's a take from Bryan after that incident https://bcantrill.dtrace.org/2013/11/30/the-power-of-a-prono...
- I think more people should read Naur's "programming as theory building".
A comment is an attempt to more fully document the theory the programmer has. Not all theory can be expressed in code. Both code and comment are lossy artefacts that are "projections" of the theory into text.
LLMs currently, I believe, cannot have a theory of the program. But they can definitely perform a useful simulacrum of such. I have not yet seen an LLM generated comment that is truly valuable. Of course, lots of human generated comments are not valuable either. But the ceiling for human comments is much, much higher.
- It's part of the web platform: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Half my team switched to JJ this year, and I do find stacking PRs to be much more pleasant now. We had previously tried out Graphite but it didn't really stick.
I wrote up a little way to use JJ's revsets to make it easy to push an entire stack of branches in one command:
https://crabmusket.net/2025/jj-bough-a-useful-alias-for-stac...
- Electricity isn't a tool, it's nature. An unenclosed electrical plug which you had to be really careful when handling would be a bad tool, yes.
A tool is something designed by humans. We don't get to design electricity, but we do get to design the systems we put in place around it.
Gravity isn't a tool, but stairs are, and there are good and bad stairs.
- Oh, silly me. It's the episode called "principle stacks", which I didn't notice skimming through the feed, nor did Google find it.
Why privilege that side of the equation over "we as workers"? Being a customer isn't all there is to life. I happen to spend quite a bit more time working than shopping.