This is in fact what happened with SpaceX. Musk had the vision to make first stage reusability a thing with the Falcon 9, and Gwynne Shotwell is the operational genius behind the juggernaut that it is today.
Hilarious quote from her Wikipedia page:
> Shotwell has received particular praise from NASA Administrator Bill Nelson for her "phenomenal" leadership of SpaceX as it developed the Falcon 9 into the "workhorse" of the space launch sector.[19] Nelson had reportedly been concerned in 2022, after Elon Musk purchased Twitter, that it would be a distraction at SpaceX, but became more comfortable after meetings with Shotwell left him feeling reassured that she was in charge of day-to-day operations.
The idea lingered for longer than that. China under Hu Jintao wasn’t exactly friendly to the west, but it was Xi who really set China on its present course to build a multi-polar world, make real noise about reunification with Taiwan, etc.
This new direction didn’t become clear to both sides of the aisle in the US until a year or two into Xi’s tenure. If someone else other than Xi had been chosen, we would likely have a very different China today.
For sure. I feel I need all of my experience to discern the difference between “slightly different, and should be combined” and “slightly different, and you’ll regret it if you combine them.”
One of my favorite things as a software engineer is when you see the third example of a thing, it shows you the problem from a different angle, and you can finally see the perfect abstraction that was hiding there the whole time.
I’m one of those that have thrown out Postel’s law entirely. Maybe the issue is that it never defines “strict”, “liberal”, and “accept”. But at least for public APIs, it never made sense to me.
If I accidentally accept bad input and later want to fix that, I could break long-time API users and cause a lot of human suffering. If my input parsing is too strict, someone who wants more liberal parsing will complain, and I can choose to add it before that interaction becomes load-bearing (or update my docs and convince them they are wrong).
The stark asymmetry says it all.
Of course, old clients that can’t be upgraded have veto power over any changes that could break them. But that’s just backwards compatibility, not Postel’s Law.
Source: I’m on a team that maintains a public API used by thousands of people for nearly 10 years. Small potatoes in internet land but big enough that if you cause your users pain, you feel it.
One example where I think the law does make sense is for website URL paths.
Over time the paths may change, and this can break existing links. IMO websites should continue to accept old paths and redirect to the new equivalents. Eventually the redirects can be removed when their usage drops low enough.
I probably use a different interpretation of Postel's law. I try not "break" for anything I might receive, where break means "crash, silently corrupt data, so on". But that just means that I return an error to the sender usually. Is this what Postel meant? I have no idea.
I don't think that interpretation makes that much sense. Isn't it a bit too... obvious that you shouldn't just crash and/or corrupt data on invalid input? If the law were essentially "Don't crash or corrupt data on invalid input", it would seem to me that an even better law would be: "Don't crash or corrupt data." Surely there aren't too many situations where we'd want to avoid crashing because of bad input, but we'd be totally fine crashing or corrupting data for some other (expected) reason.
So, I think not crashing because of invalid input is probably too obvious to be a "law" bearing someone's name. IMO, it must be asserting that we should try our best to do what the user/client means so that they aren't frustrated by having to be perfect.
I actually dont think it's that obvious at all (unless you are a senior engineer). It's like the classic joke:
A QA engineer walks into a bar and orders a beer.
She orders 2 beers.
She orders 0 beers.
She orders -1 beers.
She orders a lizard.
She orders a NULLPTR.
She tries to leave without paying.
Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is.
The bar explodes.
It's usually not obvious when starting to write an API just how malformed the data could be. It's kind of a subconscious bias to sort of assume that the input is going to be well-formed, or at least malformed in predictable ways.
I think the cure for this is another "law"/maxim: "Parse, don't validate." The first step in handling external input is try to squeeze it into as strict of a structure with as many invariants as possible, and failing to do so, return an error.
Yea, I interpret it as the same thing: On invalid input, don't crash or give the caller a root shell or whatever, but definitely don't swallow it silently. If the input is malformed, it should error and stop. NOT try to read the user's mind and conjure up some kind of "expected" output.
I've always liked Postel's law as a general philosophy toward life. But yeah, it's definitely become a little dated in the software world, if it was ever a good idea at all.
Vantage looks great! I’ll try it out this weekend.
To do the job that swarf does, I found that the bwrap sandbox I’d been using is the perfect place to mount a folder to catch markdown junk and keep it out of the project’s actual git repo. Works great.
He does go on to say “this is basically impossible if you want to live in society”, but yeah the order in which the information is communicated isn’t optimal for skimming.
Installed Carbonite on my parents’ computer something like 15 years ago, and it still works (every now and then my dad tells me he used it to recover from a bug or a mistake).
But I have no idea where the company currently sits on the spectrum from good actor to fully enshittified.
If you turn on Markdown formatting, shift+enter adds a new line, unless you’re in a multi-line code block started with three backticks, and then enter adds a new line and shift+enter sends the message.
I can see why someone thought this was a good idea, but it’s just not.
It’s kind of modal editing. Your 99% is enter to send because it’s a chat program. You’re sending mostly quick messages where adding a chorded input to send is just adding extra work to that mode.
When you enter a code block, that assumption changes. You are now in a “long text” mode where the assumptions are shifted where you are more likely want to insert a new line than to send the message.
I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context. Pressing tab in a table or spreadsheet will navigate cells instead of inserting a tab character. Pressing arrow keys may navigate cells instead of characters in the cell. Pressing enter will navigate to the cell below, not the first column of the next row. It’s optimized for its primary use case.
I think if the mode change was more explicit it’d maybe be a better experience. Right now it is largely guessing what behavior someone wants based off the context of their message but if that mismatches the users expectations it’s always going to feel clumsy. A toggle or indicator with a keyboard shortcut. Can stick the advanced options inside the settings somewhere if a power user wants to tinker.
> I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context.
I don't have a spreadsheet software nearby, but I remember the cell is highlighted different if you're in insert mode or navigation mode. Just like the status line in Vim let's you know which mode you're in.
Hilarious quote from her Wikipedia page:
> Shotwell has received particular praise from NASA Administrator Bill Nelson for her "phenomenal" leadership of SpaceX as it developed the Falcon 9 into the "workhorse" of the space launch sector.[19] Nelson had reportedly been concerned in 2022, after Elon Musk purchased Twitter, that it would be a distraction at SpaceX, but became more comfortable after meetings with Shotwell left him feeling reassured that she was in charge of day-to-day operations.
reply