There’s something in bemoaning the loss of a poetic register in written language, but that’s a different and much less significant change.

For Rust, this is not accurate (though I don't know for the other languages). The type system instead simply enforces that pointers are non-null, and no checks are necessary. Such a check appears if the programmer opts in to the nullable pointer type.

The comparison between pointers and integers is not a sensible one, since it's easy to stay in the world of non-null pointers once you start there. There's no equivalent ergonomics for the type of non-zero integers, since you have to forbid many operations that can produce 0 even on non-0 inputs (or onerously check that they never yield 0 at runtime).

>The same can be done for division (and remainder / modulo). In my own programming language, this is what I do: you can not have a division by zero at runtime, because the compiler does not allow it... In my experience, integer division by a variable is not all that common in reality

That's another option, but I hardly find it a real solution, since it involves the programmer inserting a lot of boilerplate to handle a case that might actually never come up in most code, and where a panic would often be totally fine.

Coming back to the actual article, this is where an effect system would be quite useful: programmers who actually want to have their code be panic-free, and who therefore want or need to insert these checks, can mark their code as lacking the panic effect. But I think it's fine for division to be exposed as a panicking operation by default, since it's expected and not so annoying to use.

I'd be interested if this weren't true, since the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0.

It doesn't look like Zig does either of these.

[0]: https://ziglang.org/documentation/master/#Division-by-Zero

It’s also tacit, but I assume it helps them to interface with a Dutch company. Did they get any financial incentive for it?

It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power.

Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive throughout the program. That’s a significant difference from how C’s unsafety works.

Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.

If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.

If your Outlook server disables IMAP & POP3, then the ActiveSync protocol is AFAIK the only way to get in-app emails on your phone. Admins do this so that they can forcibly wipe the device if they "need" to.

0: https://learn.microsoft.com/en-us/exchange/clients/exchange-...

That's not the point. Businesses are obviously happy to raise prices under the confusion of other changes, but I find it very hard to believe "accounting fees" are a plausible way to do so. People know that the register machine can do the calculations easily - it already does so. And there is a good reason for businesses not to introduce such fees, because they are directly visible to the consumer who is going to complain and shop elsewhere.

The UPS example is apples to oranges. Tariffs are poorly understood, and consumers rarely shop around for shipping - they tend to take the service given by the merchant. The agency people will show on 2 random cents on every shop is way higher.

>It's not super relevant to the discussion of whether rounding can/will be gamed.

It's very relevant. How are consumers going to react to a price like $1.03? Especially since that's almost certainly something that would previously have been priced at $1.

Where’s the law preventing someone from doing this right now? I don’t think this cynicism is justified.

Similarly, if places are willing to price stuff at $1.03 for the few extra cents they’ll collect some of the time, then they can just raise prices on 99c items right now to $1 to collect the extra cent, which they don’t do because such prices have a psychological effect on the consumer that outweighs the small gain.

That seems like a very strong claim against the paper’s results. What makes you think that the study participants located the cube with reasoning, rather than unthinking sense?

I think we can be too quick to write things off as somehow coming from conscious thought when they bypass that part of our minds entirely. I don’t form sentences with a rational use of grammar. I don’t determine how heavy something is by reasoning about its weight before I pick it up. There is something much more interesting happening cognitively in these cases that we shouldn’t dismiss.

Is the fact that the name originates from a bell, and that the official name for the tower is different, interesting? Maybe. Is it worth “correcting”? No, for the same reason it’s not worth policing people’s use of “Google” to mean “Alphabet”.

I think that’s what is being insinuated.

Why do you think this is a strong enough reason to allow a dangerous product that used to kill people onto the market? This anecdote isn't a strong empirical justification for the safety of raw milk, just like saying that you often don't crash your car isn't a good argument for the unnecessity of seatbelts. Food poisoning incidents are not that common, even in unsanitary conditions - pasteurisation is about making it so that kids don't get unlucky.

Unless I’m wrong, this is mainly an API for trying to get an LLM to generate a Z3 program which “logically” represents a real query, including known facts, inference rules, and goals. The “oversight” this introduces is in the ability to literally read the logical statement being evaluated to an answer, and running the solver to see if it holds or not.

The natural source of doubt is: who’s going to read a bunch of SMT rules manually and be able to accurately double-check them against real-world understanding? Who double checks the constants? What stops the LLM from accidentally (or deliberately, for achieving the goal) adding facts or rules that are unsound (both logically and from a real-world perspective)?

The paper reports a *51%* false positive rate on a logic benchmark! That’s shockingly high, and suggests the LLM is either bad at logical models or keeps creating unsoundnesses. Sadly, the evaluation is a bit thin on the ground about how this stacks up, and what causes it to fall short.

But your avoidance of vertical splits likely comes for the same reasons I have a rotated screen - shrinking the vertical space in a buffer by any amount on a horizontal display quickly hits some kind of ergonomic limit where you just can’t see enough of the file at a time. I find that not only splits, but also console output, search results , etc. take up too much vertical space.

Is this your own experience? I’ve personally rarely suffered for horizontal space, but very often for a bit more vertical space, especially with web-browsing now being so vertically cluttered.

I think many workflows are top-to-bottom in a way that benefits from more vertical space to keep it all in view - though development is probably exceptionally well-suited. My current setup (cribbed from an ex-colleague) is two vertical screens side-by-side, and I miss it whenever I’m working with a horizontal display.