cobbal

This is the only one that has bitten me personally, but I probably only noticed it because it was working and then taken away. I just assume there are more instances where something was never implemented in the first place for a political reason.

Edit: I also remember hearing that for a long time an ffi was forbidden because someone could use it to call proprietary software. Don't have a source on that one though.

Specific example: for a while, color emoji worked on macOS emacs perfectly. Then it was decided that since linux couldn't support it, it needed to be disabled on macOS, or else people might want to use a non-free system. It was removed for many years.

http://xahlee.info/emacs/misc/emacs_macos_emoji.html

I read this entire post before realizing you weren't referring to `cc`, the C compiler. It actually kinda works with this interpretation, particularly the "if you know this language" part.

Celery is just a "natural" source of nitrates/nitrates. This makes it legal somehow to lie and claim "no added nitrates" on the label.

Probably possible. But if I see something that is AI, I won't bother to engage with it. I'm happier to engage with a human-written piece of bad writing, because it's a meeting of two human minds. There's some innate value to that. Me trying to understand an AI's mind? Not a worthwhile endeavor.

It gets more complicated by the fact that many people don't mark what's AI and what's not, and harder to be certain every day. Many people putting out the slop will have different priorities, and don't care if they're wasting my time.

Meandering back to your point, I would be happy to look at AI-co-created art as long as I knew in advance that it significantly expressed the mind of the human who created it.

Since I can't get people to mark what is AI, I've instead considered signing off all my writing with:

(The above was written by a human without assistance from AI)

Nice. Looks like I was looking at an old version of the file. https://github.com/python/cpython/commit/09ba98436444d2a4e11...

UUIDv4 may or may not use a cryptographically secure random number generator. Python's UUID library, for example, falls back to the insecure 'random' module. Given a handful of outputs, it's possible to predict future ones.

Fortunately they have a solution for trusting untrusted clients already! They just need to run an anti-cheat for their anti-cheat.

Why would you hand out data that gets tunneled back in?

There are lots of use cases for this exact pattern. An acceleration structure to speed up searching complex geometry. The internal state of a streaming parser. A lazy cache of an expensive property that has a convenient accessor. An unsafe pointer that the struct provides consistent, threadsafe access patterns for. I've used this pattern for all these things, and there are many more uses for encapsulation. It's not just an OO concern.

It uses cryptography (a little-known and mostly-useless offshoot of Crypto)

swift has this as well

    { foo($0, bar) }

"The first time a user logs in using Microsoft or Azure account credentials"

Maybe it's related to using the online account for local logins

If we're fixing the language, may as well fix the real problem and not artificially limit stack space.

Clearly we just need to invent a "-2" AI

If anyone like me was wondering how accuracy of a continuous measurement can be a percentage, apparently they're just multiplying correlation by 100.

> Correlation coefficient estimates and their 95% confidence intervals were also expressed in percentages for clarity and readability.

Microsoft has a habit of naming similar (or not) things the same as each other. VS and VS Code; Powershell and Windows Powershell; Copilot and Github Copilot; Azure, Azure DevOps, and probably other Azure things.

I'm not sure what internal incentives in the company lead to such terrible naming practices.

Only if the church-turing-carmack thesis holds, which I personally doubt

"Safe" is unfortunately overloaded here. I wasn't trying to say anything about memory safety. `leak` and `forget` may be memory-safe, but they can only be implemented with `unsafe` code to circumvent the liveness/"relevant" guarantees of the type system.

While this is not the direction the standard library took, I think it would be possible to write an alternative stdlib that doesn't choose to allow leaks.

My original statement was probably too strong though. Leak-free code might be possible with rust-the-language, but is probably not possible with rust-the-ecosystem without significant development.

(Not a regular rust developer, so take this with a large grain of salt)

Rust can absolutely prevent memory leaks. It depends on how much unsafe rust code you use. Many rust developers find the convenience outweighs the risk of leaks, and take the tradeoff offered by the `Rc` type.

Don't they have this? I hit the "don't recommend this channel" button and never see them again

The point is not that all NP hard problems make bad cryptosystems, but rather the NP-hardness guarantee fails to translate into a useful guarantee for a cryptosystem.

It's about the proof, not the computation.

Running `make' works in tramp, so it can do some form of execution

Not just that, but +20/-282 is the up/down split

Personally I like to differentiate subclassing from conforming to an interface. Both are subtyping, but interfaces are much cleaner.

Gold is sold by weight, so those extra neutrons are pure profit.

I really hate to be defending cryptocurrency, but doesn't this same argument apply to banks? They don't produce anything either, they just shift made up numbers around.

It's a decent, if uncommon, unit for human reactions. The difference between 0 and 1 seconds is a noticeably long time to wait for something, but the difference between n and n+1 milliseconds is too fine to be useful.

Another complicating factor that many less-tech-literate don't have a good internal model for is window focus. I've seen several people try and single-click on a not focused web button, only for nothing to happen. When they click again, the button is activated. They then learn to always double click that button.

Having a mental model of "this button needs to be double clicked" gets them the result they want, even if that's not a very accurate reflection of the computer.

PSA: If you configure your default search engine to be "https:/ /www.google.com/search?udm=14&q=" (space added to disable link detection) you can get rid of the AI.

It also turns off some nice things like the calculator, but the absence of AI garbage is worth it

One of the best things about proof assistants is that they're not convinced by how "obvious" you think something is. It's much harder for a human to resist proof by social forces such as intimidation, confidence, and "it's well known".