HelloNurse

"Just don't do that" is the correct approach to errors, even when they are easy to overlook and the programming language provides many opportunities for mistakes.

For example, you seem to underestimate how wrong placing negative values in a signed char is: ordinary character encodings do not use negative codes, so either those negative values are not characters and they have no business being treated as such, or something strange and experimental is going on.

Some of the examples are somewhat formally true in theory and bullshit in practice; some are quite hallucinatory.

  - Creating a potentially troublesome misaligned int pointer is a precisely localized and completely explicit user mistake, not something that just happens because it's C.
  - Passing signed char to character classification functions that expect an unsigned char (disguised as an int) is a very specific dumb user error. The C standard could specify that all negative inputs, including EOF and invalid signed char values, are classified as not belonging to the character class, but I doubt the current undefined behaviour in isxdigit() etc. implementations ever went beyond accepting invalid inputs.
  - Casting floating point values to integer values in general requires taking care of whether the FP values are small enough to be represented and what to do with NaN and Inf values: not the language's responsibility. C offers a toolbox of tests, not ready-made application specific error handling.
  - Expecting C to handle "address zero" in physical memory in ways that conflict with NULL in source code denotes a complete lack of understanding of what a program is. Where stuff in an executable is loaded in memory, in the rare cases when it matters, can surely be affected with platform specific extensions, possibly at the level of linker commands with nothing appearing in the C source code.

The final value of a is that if you write this you are fired. It's worse than a racist joke.

It is worth noting that some rather "enlightened" type system features are common in other imperative languages, not particularly novel ides in Zig.

For example Swift enums, while in some ways clunky, can do a decent job both as newtypes and as sum types (unlike Java enums, which are a fixed collection of instances of the same class).

Normalizing repeating groups doesn't offer significant savings when they are completely populated (e.g. each entity has the full 12 monthly values per year), but other types of normalization do. For example dependent data are actually redundant.

Formally, it doesn't appear to be so (tests can be added to each early return); in practice, encouraging the reorganization of messy early returns would be zero cost developer reeducation.

Or a small step that enables actually problematic real compliance, combined with a bad precedent: a "secure" way to populate that birth date field is a plausible future drive-by contribution.

Why didn't systemd reject these changes? Was there an internal debate that the article doesn't cover, or is it the arbitrary decision of other "volunteers"?

So it depends. Float parsing performance is only a problem if you parse many floats, and lazy access might reduce work significantly (or add overhead: it depends).

As an example of the likely future of science in the USA, read about Trofim Lysenko.

What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.

This is naive pathfinding that adopts the shortcut of perfect information. Good looking pathfinding simulates realistic terrain ignorance (no "psychic powers"), but it is likely to be expensive enough to require other compromises (e.g. updating paths less often).

Serious loss of life is a plausible LLM outcome, particularly for Microsoft who does both operating systems (incidents can be much worse than the Crowdstrike bricking) and chatbot assistants that can offer lethal advice. Catastrophic property damage is hopefully more likely.

Neither deadlines nor cheap work for hire help any sort of review process, while an hobby project is normally done by someone who cares.

> "everything is moving very fast"

Then slow down.

With this objective lack or control, sooner or later your LLM experiments in production will drive into a wall instead of hitting a little pothole like this diagram.

Powerful, "capable" plugins are obvious; NSA cannot stop people from writing them, and they have little reason to restrict their use.

I think what NSA is likely to keep confidential are in-house plugins that are so specialized and/or underengineered that their publication would give away confidential information: stolen and illegitimate secrets (e.g. cryptographic private keys from a game console SDK), or exploits that they intend to deny knowledge of and continue milking, or general strategies and methods (e.g. a tool to "customize" UEFI images, with the implication that they have means to install them on a victim's computer).

Generally, the nth roots of 1 form a cyclic group (with complex multiplication, i.e. rotation by multiples of 2pi/n).

One of the roots is 1, choosing either adjacent one as a privileged group generator means choosing whether to draw the same complex plane clockwise or counterclockwise.

A worrying choice of words.

"Losing sleep" implies an actual problem, which in turn implies that the mentioned mitigations and similar ones have not been applied (at least not properly) for dire reasons that are likely to be a more important problem than bad QoS.

"Infrastructure" implies an expectation that you deploy something external to the troubled application: there is a defective, presumably simplistic application architecture, and fixing it is not an option. This puts you in an awkward position: someone else is incompetent or unreasonable, but the responsibility for keeping their dumpster fire running falls on you.

Yes, but it is a meaningless syntax sampler.

Good examples should be complete music pieces and they should be commented: where is important information? How are the numbers computed? How are commands organized? What is the practical workflow for making changes?

  >  ÆTHRA is output-oriented: you write a script → run it → get a WAV file.

You are competing with traditional noninteractive usage of CSound. What do you think you can do better than CSound? More generally, what are the peculiar and valuable ÆTHRA features that you want to develop well?

The current language is relatively verbose and readable (more suitable for live coding than for a "music compiler"), but somewhat simplistic and ad hoc on the notation side (e.g. no separate tracks, parts etc.) and not very general on the sound synthesis and processing side (e.g. fixed waveforms and keywords for effects).

Indeed. If a test runner embedding the Godot engine is now feasible on paper a proof of concept implementation seems deserved: if there are fatal bugs or limitations they will be eventually corrected (sooner if properly discovered, reported and discussed), and if there are none the new technology is "battle-tested" enough.

Taking feature lists and plans at face value is offensively shallow; the typical Rust fan arrogance pattern can be an explanation (if the Rust rewrite is "better", it doesn't have to be compatible with the rest of the world who uses the actual C SQLite).

These would be differences between two different monitors sharing the same panel. But if one is Nano IPS Black and one isn't, they don't have the same panel.

Progress would be a respectful experiment to hack an implementation of vector indexing, or some other actually useful feature, into the actual SQLite, preferably as an extension.

That would be a valid experiment and, if it goes well, a contribution, while hoping that someone bases anything important on Turso looks like grabbing captive users.

If you think this discussion is antagonistic, you should see how antagonistic "entrepreneurs" and VCs become when they are in charge of open source projects. Risk aversion is good.

In this case, the familiar "rewrite it in Rust" MO has a special angle: the Turso feature list is such a terrifying collection of high-risk, low-performance, inferior, unlikely to be compatible, unproven and unnecessary departures from SQLite that a malicious embrace-and-extend business plan is a reasonable theory and reckless naivety is the best possible case.

Not only any computer of last resort would have software installed in advance and easily prepared redundant archives to install it again, but "pip install" is perfectly fine for other use cases: testing Reticulum, regularly updating everyday computers, improvised installations on someone else's computer, etc.

"Lastly, if you're set on 6K, there's also the Asus ProArt PA32QCV to consider. I haven't tested it yet, but it's $600 cheaper than LG's model, despite using the same 6K panel. [...] The biggest difference is the lack of Nano IPS Black"

How can it be the same panel if it differs in such a fundamental aspect?

It might make sense to reduce curve size adaptively. Suppose the first control point of each candidate curve is randomly distributed anywhere in the image (weighted by error at each pixel might be more efficient than a uniform distribution), the other three control points are randomly distributed according to a Gaussian distribution with variance σ and average the previous control point, and the actual curve is clipped against the image rectangle. Then after N consecutive candidate curves are rejected we could reduce σ in order to try smaller curves.

The problem is that treating the incorrect simplification as good can be very tempting for teachers.

For example, in an introductory physics course teaching Newtonian dynamics without the brutal complications of special relativity and general relativity is fine because it doesn't take much to explain that it is an approximation and it is good enough for "everyday" situations. Students are aware that a better model is available: worst case, they try to get away with not using it.

On the other hand in an introductory programming course teaching that if you have Animals in the program the dog instances "should" belong to a Dog subtype is logically consistent and elegant; the only opposing force is the abstract and uncool engineering principle of keeping software simple, and many teachers are dogmatic and enthusiastic.

Typically, what's nicer is the absence of other features that interfere with the important ones.

For example, Prolog isn't a general purpose functional or imperative language: you can assert, retract and query facts in the automatically managed database, risking only incorrect formulas, inefficiencies and non-monotonicity accidents, but not express functions, types, loops, etc. which could have far more general bugs.