chowells

Are you aware of HTML 5? Fun fact about it: there's zero leniency in it. Instead, it specifies a precise semantics (in terms of parse tree) for every byte sequence. Your parser either produces correct output or is wrong. This is the logical end point of being lenient in what you accept - eventually you just standardize everything so there is no room for an implementation to differ on.

The only difference between that and not being lenient in the first place is a whole lot more complex logic in the specification.

The linear algebra argument for almost any three colors only works if you can have negative intensities. I don't know how to do that with stimulation of photoreceptors, so I don't think that applies here.

No mention that both sets of primaries come from the biology of the average human eye, and other animals might be better served by other colors? Ok, yeah, that's not really relevant to the point the article was actually getting to, but I think it's important to remember. There's nothing magical about those colors. They effectively stimulate color receptors in our eyes such that our brains interpret the input in ways that can be combined to cover a pretty large gamut of the full range our eyes can perceive.

But as for what the article actually does focus on, I absolutely agree. You can create some really striking art by restricting your gamut to the range you can cover with a particular set of pigments.

When the marketing tells us it's like talking to a PhD in the relevant field on any topic, it's worth pointing out that's only true if the PhD in question has recently suffered severe head trauma.

The issue is that people in general are very easy to fool into believing something harmful is helping them. If it was actually useful, it's not an issue. But just because someone believes it's useful doesn't mean it actually is.

Dijkstra's algorithm is completely trivial. It's a greedy algorithm; there's nothing more complex involved than repeating the same simple step over and over. You pick a starting node then repeatedly add the lowest-cost edge to a node you haven't already reached. It's harder to explain what a "node" and "edge" are than to explain how Dijkstra's algorithm works.

Many textbooks make it sound harder than that because they want to examine complex data structures that make various parts of that as fast as possible. But the complexity is the implementation of the data structures, not Dijkstra's algorithm.

By "centralized" I mean a single file that contains all transitive dependency version information and nothing else. This is very different than having to recursively examine tiny portions of your dependencies' package specs recursively to find all transitive dependencies.

The difference is that the data is centralized with a single source of truth, and you have tools for working with it automatically. It doesn't mean lockfiles are cheap to update, but it does mean it's a much more streamlined process when it's time.

Once again... The instruments reported the hull was no longer safe for use before the start of the last dive. That was well before the implosion. You keep ignoring this part to focus on how there was no engineering that would suggest that those instruments would actually give early warning. I'm halfway there with you. It is actually a surprise that they reported it was unsafe before the dive. But they did, and that makes the subsequent human failures even more egregious.

I think you missed the thrust of OP. The submersible had instruments in it to report on the hull condition. They all were reporting it had previously experienced severe strain before the last dive, and they were designed as tripwires. If they tripped, the hull should have been considered unsafe and not used again. They were ignored.

It is a shock that they actually worked and reported the hull was unsafe before it failed. Given everything else, it's not a surprise in the slightest that they were ignored.

They took VC funding. That requires them to attempt to grow to the size of Facebook or Amazon, or implode. Merely being profitable forever is not an acceptable outcome.

On multiple occasions, I've wanted a standard format that allows large multi-line text blocks to be unquoted. JSON, JSON5, and TOML don't do that. You know what does? YAML and XML. I'm not really a fan of either of them, but where's the better option that still gives me large unquoted text blocks?

You're like 50% of the way there...

> According to Anthropic’s commercial terms of service, customers are barred from using the service to “build a competing product or service, including to train competing AI models”

That's... quite a license term. I'm a big fan of tools that come with no restrictions on their use in their licenses. I think I'll stick with them.

Chatbots are on a different list than the rest of those. Animals aren't human companionship, but they're still physical beings with physical needs that interact with you on their own schedule for their own reasons.

My cat will harass me if I'm on my computer after midnight. It's time to put the technology away and lie down where she can keep an eye on me. She's quite clear on this point. This is an entire category of interaction not available to chatbots. There is a difference in level of reality.

And when lacking human companionship, grounding to reality is really important. You've got to get out of your head sometimes.

I don't think it's true that Rust is safer, using the terminology from the article. Both languages prevent you from doing things that will result in safety violations unless you start mucking with unsafe internals.

Rust absolutely does make it easier to write high-performance threaded code correctly, though. If your system depends on high amounts of concurrent mutation, Rust definitely makes it easier to write correct code.

On the other hand, a system like STM in Haskell can make it easier to write complex concurrency logic correctly in Haskell than Rust, but it can have very bad performance overhead and needs to be treated with extreme suspicion in performance-sensitive code. It's a huge win for simple expression of complex concurrency, but you have to pay for it somewhere. It can be used in ways where that overhead is acceptable, but you absolutely need to be suspicious in a way that's never a concern in Rust.

You mean like the program in the article where code that never dereferences a non-pointer causes the runtime to dereference a non-pointer? That seems like evidence to me.

Why would you ask one of these tools why they did something? There's no capacity for metacognition there. All they'll do is roleplay how human might answer that question. They'll never give you any feedback with predictive power.

Eh, that's an easy typo to make on a phone when you're used to autocorrect getting things right. Sometimes you miss when it doesn't.

That's not the incoherent part of GP, which is the part where they somehow seem to believe women are favored (?!) by current power structures and that favor will increase as those structures turn towards might-makes-right policies.

Addition vs multiplication is a bad and useless thing to talk about. It's a waste of time. It's much more useful to talk about what number you get at the end. You might get that number from adding once, or twice, or even more times, but that final number is the actual thing you need to understand and "addition vs multiplication" just gives absolutely no information or insights whatsoever.

They're just different names for different things. Not caring that they're different things makes communication difficult. Why do that to people you intend to communicate with?

The difference is quite useful and informative. In fact, most places don't seem to state it strongly enough: Concurrency is a programming model. Parallelism is an execution model.

Concurrency is writing code with the appearance of multiple linear threads that can be interleaved. Notably, it's about writing code. Any concurrent system could be written as a state machine tracking everything at once. But that's really hard, so we define models that allow single-purpose chunks of linear code to interleave and then allow the language, libraries, and operating system to handle the details. Yes, even the operating system. How do you think multitasking worked before multi-core CPUs? The kernel had a fancy state machine tracking execution of multiple threads that were allowed to interleave. (It still does, really. Adding multiple cores only made it more complicated.)

Parallelism is running code on multiple execution units. That is execution. It doesn't matter how it was written; it matters how it executes. If what you're doing can make use of multiple execution units, it can be parallel.

Code can be concurrent without being parallel (see async/await in javascript). Code can be parallel without being concurrent (see data-parallel array programming). Code can be both, and often is intended to be. That's because they're describing entirely different things. There's no rule stating code must be one or the other.

Why did you call this innocent person a "perp"? Is it because of your pro-police political beliefs?

That whole argument assumes that you as a consumer can always find a product with exactly the features you want. Because that's a laughable fiction, there need to be laws with teeth to punish bad behaviors that nearly every product would indulge in otherwise. That means things like requiring sites to get permission to track, and punishing those that track users without permission. It's a good policy in theory, but it needs to be paired with good enforcement, and that's where things are currently lacking.

Actually, I think what you really need is "i++ != end". The whole point was inequalities don't work how you want when end is INT_MAX. You want to just terminate after the loop body where i was equal to end. Except now I'm not sure if that evades the UB of a signed int exceeding INT_MAX. I don't know C well enough to know if the UB is in performing the increment or reading the value afterwards.

Edit: Just checked in with a C expert. The UB is in the increment operation, so that's not correct after all. You really do just need to separate out the update from the test entirely.

I did consider that, but I wrote "in general" for a reason. It works very specifically in the case of "add one" or "subtract one", but it doesn't work with anything more complicated, like chasing pointers or adding/subtracting more than one at a time.

You could write functions to do the update and return the old value so you could use them in the same way, but I don't like this either. This is mostly because it orders the termination check and the update logic the wrong way around. If there's IO involved in checking for the next thing, for example, side effects of that unnecessary operation might interfere with other code.

You could resolve that by moving the termination check into the update logic as well, but now you're seriously complecting what should be independent operations. I don't think the tradeoff is there versus just using a break. But mostly, this is a self-inflicted problem in C's language constructs and idioms. I just don't have this problem in many other languages, because they provide end-inclusive looping constructs.

Yeah, it's a hard case in general. But C's idioms really don't encourage you to think about it. You really need to default to a loop structure that checks the termination condition after the loop body but before the increment operation for inclusive end coordinates.

It's easy to think that's what do/while is for, but it turns out to be really hard to do the increment operation after the conditional, in general. What you really want is a loop structure with the conditional in the middle, and the only general purpose tool you get for that is a break. C (or any language with similar syntax) really doesn't have an idiom for doing this correctly.

That's a really funny example, given how many bugs have been found in C programs because idiomatic loops are wrong in the edge cases.

How do you idiomatically write a loop to iterate over signed ints from i to j (inclusive) in increasing order, given i <= j?

What does that loop do when j is INT_MAX?

Because it shows a lack of respect for and understanding of the work graphic artists actually do. Now if that's your brand, great. You are communicating it effectively. If it's not your brand, it's probably worth considering the subtext in your presentation.

In ruby, "frozen" is a property of some values that makes them immutable. I mean, other than the part where you can mutably unfreeze objects of many classes. (At least you can't unfreeze strings.) This change makes string values that come from literals initially frozen. It has nothing to do with variable bindings.

I, uh... What? Did you mean to respond to some other post there?

I can't see how anything you said is a response to anything I said. My statement was very simple: if two models predict the same result, you can use either of them. As far as we have worked out so far, continuous and discrete spacetime give the same results for every experiment we can run. If you have an experiment where they don't, physicists would really love to see it.