45 karma · joined July 8, 2025
early on when I was doing iOS development I learned that "m34" was the magic trick to make flipping a view around have a nice perspective effect, and I didn't know what "m34" actually meant but I definitely knew what the effect of the line of code that mutated it was...
Googling on it now seems like a common experience for early iOS developers :)
https://stackoverflow.com/questions/14261180/need-better-and...
https://stackoverflow.com/questions/3881446/meaning-of-m34-o...
> but there is no invitation to guess, and no one pretends you don’t need the manual
which is basically what you're saying too? the problem with voice UIs and some LLM tools is that it's unclear which options and tools exist and there's no documentation of it.
for example I say: "play comically long album title by artist on Spotify", it thinks about that for five seconds, does the bing noise, then says "playing comically long album title [special remastered edition] by artist on Spotify", and then a few seconds later starts playing the album, and if you don't wait through that whole thing it will just decide that actually you didn't want to hear the album
I don't own a car but rent them occasionally on vacation in every one I've rented that I can remember since they started having the big touch screens that connect with your phone, the voice button on the steering wheel would just launch Siri (on CarPlay), which seems optimal—just have the phone software deal with it because the car companies are bad at software.
It seems to work fine for changing music when there's no passenger to do that, subject to only the usual limitations with Siri sucking—but I don't expect a car company to do better, and honestly the worst case I've can remember with music is that played the title track of an album rather than the album, which is admittedly ambiguous. Now I just say explicitly "play the album 'foo' by 'bar' on Spotify" and it works. It's definitely a lot safer than fumbling around with the touchscreen (and Spotify's CarPlay app is very limited for browsing anyways, for safety I assume but then my partner can't browse music either, which would be fine) or trying to juggle CDs back in the day.
looking at zod (assuming https://zod.dev) it is a parsing library by that definition — which isn't, like, an official definition or anything, one person on the internet came up with it, but I think it is good at getting the principle across
under these definitions a "parser" takes some input and returns either some valid output (generally a more specific type, like String -> URL) or an error, whereas a "validator" just takes that input and returns a boolean or throws an error or whatever makes sense in the language.
eta: probably part of the distinction here is that since zod is a JS library the actual implementation can be a "validator" and then the original parsed JSON input can just be returned with a different type. "parse don't validate" is (IMO) more popular in languages like Rust where you would already need to parse the JSON to a language-native structure from the original bytes, or to some "JSON" type like https://docs.rs/serde_json/latest/serde_json/enum.Value.html that are generally awkward for application code (nudging you onto the happy parsing path).
idk if your partner is jealous of you using one of the top five social networking apps in the world that seems a little weird and maybe your relationship is not very healthy? it's instagram, not tinder or okcupid...
Now, there is a serde_protobuf (I haven't used it) that I assume allows you to enforce nullability constraints but one of the article's points is that you can use the generated code directly and:
> No manual validation. No JSON parsing. No risk of type errors.
But this is not true—nullability errors are type errors. Manual validation is still required (except you should parse, not validate) to make sure that all of the fields your app expects are there in the response. And "manual" validation (again, parse don't validate) is not necessary with any good JSON parsing library, the library handles it.
this seems like a problem only if you use JSON.parse or json.loads etc. and then just cross your fingers and hope that the types are correct, basically doing the silent equivalent of casting an "any" type to some structure that you assume is correct, rather than strictly parsing (parse, don't validate) into a typed structure before handing that off to other code.
At a population level maybe... but if you (and your family/friends if you want to consider that too) already don't smoke, there is not much to do? I don't have to work hard to avoid smoking because I am not interested in doing it to begin with, and it is not like cigarettes jump out of bushes and ambush you.
Helicopter crashes aren't common, but traffic violence is mostly treated as normal in the US, and deaths are often brushed off as an unavoidable "accident" with little or no punishment for the perpetrator, or serious consideration of systematically redesigning streets or vehicles to make these deaths less likely. This is something that I cannot "simply" avoid like smoking is.
https://floridaphoenix.com/2024/05/15/desantis-signs-bill-er...
In this case it seems obvious that it needs some kind of vesting terms to prevent people from taking the bonus and then just taking another offer anyways.
IDK! I don't think Vibe Coding, with the definition that I understand, is a good idea.
But the term comes from here: https://x.com/karpathy/status/1886192184808149383
And the key parts are:
> "forget that the code even exists"
> "I don't read the diffs anymore"
I myself am unclear on what the "vibes" that one is giving into actually are. But terms should have meanings and my understanding from reading the original tweet is that "Vibe Coding" means something distinct from "coding using some AI to help".
Maybe this is pedantic, but I thought that the core point of "Vibe Coding" is that you do not look at the code. You "give in to the 'vibes'".
I don't know how to translate it into a physical hardware product exactly, but I think it would be manufacturing it without looking at it, plugging it in for your use-case and seeing if it works, then going back to the model, saying it didn't work, rinse, repeat.