ivanbakel

In some discussion about Arabic rendering on another website[0], it was pointed out that the Basmala is its own codepoint in part because it is (or was?) a legal requirement on Pakistani documents and comes from an Urdu character-set. It's possible that, as a character effectively originating from and used by Urdu speakers, Apple defaults it to Nastaliq regardless of your font settings.

0: https://lobste.rs/s/7s4sjp/u_fdfd_arabic_ligature_bismillah_...

Is this a knowing joke? Switzerland's largest (very much in both senses) coin is 5Fr, around 6 USD. Not a token amount by any means, though it wouldn't even cover most public transport journeys in cities.

Natural selection can only work at the granularity of whole organisms, since they're the things that compete and reproduce. There is no finer pressure on specific concepts like efficiency, except that they may help the organism survive - but whatever solution works for the whole organism, works.

The GP is talking about DMT, not the mushroom mentioned in the article.

What they call a "trigger" is apparently a theorem proved by some more powerful system. (Or just assumed as an axiom. That's cheating, and it will come back to bite you.)

A trigger in SMT lingo is nothing of the sort. It’s simply an instruction to the solver about which instantiations of a universal quantifier should be considered, with the aim of getting a proof without too many specious steps.

The statement with the trigger on it is typically an assumption from e.g. a function specification. At some point the statement with the trigger may itself become a proof obligation elsewhere in the program, but that’s something that can be handled with SMT.

This is a point I was also wondering the whole time. The vulgarisation of literature happened all over Europe at varifying times and in different stages. We don’t see these as changes in the language itself, but instead the authors daring to write the way they actually always spoke.

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

Some programming languages (Kotlin, Swift, Rust, Typescript...) already do something similar for possible null pointer access: they require that you add a check "if s == null" before the access.

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.

Could you clarify what's going on in the Zig docs[0], then? My reading of them is that Zig definitely allows you to try to divide by 0 in a way the compiler doesn't catch, and this results in a panic at runtime.

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

Providing a device doesn't require picking a standard issue model of phone. IT departments often support an employee's choice of phone (or at least, choice of manufacturer) provided it's compatible with management software.

Interesting that they settled on a standard model at all. The announcement implies that the university is responsible for phone maintenance and repair, which makes sense as a motivation, but is not something I would expect in itself from a cost/expertise standpoint. I would be curious to know if a Fairphone makes servicing cheap enough to warrant doing it in-house for an IT department.

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 not "Safe Rust" which is competing with C it is "Rust".

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.

There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."

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.

No, Exchange ActiveSync (as the other commenter correctly identified it) really allows an admin to wipe your device - ostensibly of mail, but often of all other data as well.[0]

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-...

What I'm most curious about, and what the docs are light on detail about: does this mean Thunderbird complies with remote deletion requests (which IIRC, the Exchange protocol suppports)? I have the impression that Microsoft makes this a requirement for Exchange implementations, which is why third-party devices and apps like Apple's Mail cooperate with those requests.

You don't think businesses take advantage of situations for more profit?

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 stores from imposing an accounting fee for multi-item purchases, conveniently totaling a few cents?

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.

I mean, feeling sand compress in subtle ways and being able to map that mentally to an object that might be hidden in the sand seems like literally touch plus normal world modelling / reasoning

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.

Probably because it’s unclear what this pedantry about synecdoche contributes to the discussion. Many people (including journalists at the state broadcaster) happily refer to the whole tower as Big Ben, so that is functionally one of its names.

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”.

Is there any reason you can't spoof literally all of that?

I think that’s what is being insinuated.

I've been drinking raw milk probably since I was 3 year old, like most kids in my relatively underdeveloped country before I moved to the US.

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.

The repo is sparse on the details unless you go digging, which perhaps makes sense if this is just meant as the artifact for the mentioned paper.

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.

It is likely too late for many existing contracts with packages built-in, which probably also overlap with the longest-working (and thus most expensive) engineers.

Isn't the consensus from climate scientists that emission reductions are totally necessary, and there is no solution which is solely based on capture of greenhouse gases or cooling technologies? Even if reducing emissions is not enough, I thought it was clear that it needs to be done - and the economic impact is a necessary evil, since in reality we are just seeing the reversal of economic benefits obtained at the cost of planetary temperatures.

I don’t exclusively use vertical splits - often I opt for a four-corner split if I need more than 2 panes at a time.

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.

I think most people lack horizontal space more than vertical.

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.

Given this is an article about Taiwan, surely the more logical conclusion is that “Chinese” refers to the PRC? Otherwise, as you say, it makes little sense. The rest of the comment is still low quality.

This alternative interpretation doesn’t seem to have much basis either, since the author is apparently native Taiwanese, but perhaps the GP is accusing her of PRC loyalties?

How true is this really?

I’d be interested to see a more thorough analysis, but there is a simple way to gauge this - rip out all the parts of the compiler where aliasing information is propagated to LLVM, and see what happens to performance.

I found a claim that noalias contributes about 5% performance improvement in terms of runtimes[0], though the data is obviously very old.

https://github.com/rust-lang/rust/issues/54878#issuecomment-...

This looks to have been a conflation by the GP between the volume of the unit sphere itself and its ratio to the volume of its bounding cube (which is not the unit cube.) The volume of the sphere does top out at an unintuitive dimension, but indeed the ratio of the two is always decreasing - and intuitively, each additional dimension just adds more space between the corners of the cube and the face of the sphere.

As it is, Go is massively successful and most active Go programmers don’t mind the error handling situation. The complaints are mostly from folks who didn’t choose it themselves or don’t even actually use it.

This is a case of massive selection bias. How do you know that Go’s error problem isn’t so great that it drives away all of these programmers? It certainly made me not ever want to reach for Go again after using it for one project.

I doubt that would fix the issue. The real cause is that programmers mostly deal in fixed-size integers, and that’s how they think of integer values, since those are the concepts their languages provide. If you’re going to write a JSON library for your favourite programming language, you’re going to reach for whatever ints are the default, regardless of what the specs or type hints suggest.

Haskell’s Aeson library is one of the few exceptions I’ve seen, since it only parses numbers to ‘Scientific’s (essentially a kind of bigint for rationals.) This makes the API very safe, but also incredibly annoying to use if you want to just munge some integers, since you’re forced to handle the error case of the unbounded values not fitting in your fixed-size integer values.

Most programmers likely simply either don’t consider that case, or don’t want to have to deal with it, so bad JSON libraries are the default.