HelloNurse

Meaningless toy examples have the problem that they can appear to make sense, planting the seeds of terrible ideas.

If in a course example Dog extends Animal, it can be an arbitrary demonstration of language mechanisms (with an uncontroversial is-a relationship) but even in that case it is implicitly suggested that it is a good or "normal" design, implying an alarmingly complex program that has good reasons to deal with those two types.

Such a program is usually not described for brevity, giving the false impression that it exists: if the problem were analyzed with any diligence, usually Dog would appear a completely pointless complication.

> This one also depends on political stability.

Canada is going to be seen as similar to USA, but open to immigrants and not fascist. Will it develop enough opportunities?

Delusional rockstar engineers might really have this kind of opinion of their LLMs and their colleagues.

With less sarcasm, how bad is Microsoft as a workplace? The source of this kind of naively arrogant proclamation can be anything from a single rotten apple, to a critical mass of unchecked idiots in the same business unit, to normal for the company culture, to a top-down mandate.

The important metric is how many tests need to be written to trust those lines of code (in one month, and more ludicrously by one engineer).

Maybe the plan is not testing because they think that Rust is "safe" and automatic translation is smarter than a typical Microsoft employee.

And hardware raytracing is on the same trajectory as hardware rasterization: devs finding ways to repurpose it, leading to pressure for more general APIs, which enable further repurposing, until hardware raytracing evolves into a flexible hardware accelerated facility for indexing, reordering, etc.

It is unreasonable to expect to run the same graphics code on desktop GPUs and mobile ones: mobile applications have to render something less expensive that doesn't exceed the limited capabilities of a low-power device with slow memory.

The different, separate engine variants for mobile and desktop users, on the other hand, can be based on the same graphics API; they'll just use different features from it in addition to having different algorithms and architecture.

You don't need a "proper" random selection: if your points are sorted deterministically and not too adversarially, any reasonably unbiased selection (e.g. every Nth point) is pseudorandom.

Why do you think the mentioned "color-centric" image processing operations deserve a specialized file format, rather than building and using a transient index in memory when it is useful? Do you have some special use case in mind?

Any interactive application, for instance, can be expected to render the image to the screen (repeatedly); any GPU use for texture mapping needs pixels sorted by location, regardless of whether pixel values are palette indices or explicit colours; many image processing tasks, like segmentation and drawing, need efficient access to pixels at arbitrary locations or near already processed locations.

Weapons and violence in Jane Austen's novels include characters hunting with shotguns and (remotely implied) armed Navy ships.

Nothing comparable to treating a mobile suit like an extension of the body, or killing people, or both at the same time (e.g. the "duel" between Char Aznable and Kycilia Zabi).

Aren't the notes adjacent enough on consecutive lines?

  2.0 note Cmaj7 ch=1 
  2.0 note D ch=1 
  2.0 note C dur=0.15 ch=2
  2.1 note C ch=2
  2.1 note Cmaj ch=1

The best place for such a cache is a GPU texture, and in a shader that does simple texture mapping instead of rasterizing shapes it would cost more memory reads in exchange for less calculations.

> seems fairly clearly to be talking about icons of known sizes, in which case that advantage disappears.

That's the point: obliviousness to different concerns and their importance.

Among mature people, the main reason to use SVG is scaling vector graphics (in different contexts, including resolution-elastic final rendering, automatically exporting bitmap images from easy to maintain vector sources, altering the images programmatically like in many icon collections); worrying about file sizes and rendering speed is a luxury for situations that allow switching to bitmap images without serious cost or friction.

We are talking about an application file format, so "type errors" are about who's right: the application (even better, multiple equally right implementation of a specification) or random hackers altering the file in incorrect ways.

Loose type checks, e.g. NOT NULL columns of "usually" text, are loose only compared to typical SQL table definitions; compared to the leap forward of using abstract tables and changing them with abstract SQL instead of using text or byte buffers and making arbitrary changes, enforcing data types on columns would be only a marginal improvement.

For many web services it would be more often 200 KB of schema (many possible request and responses, some of them complex) tacked onto a less than 1 KB message (brief requests and acknowledgements without significant data inside).

The blog seems to contain other similar misunderstandings: for example the parallel article against using SVG images doesn't consider scaling the images freely a benefit of vector formats.

Also architecturally suitable for the common case of collecting heterogeneous files in existing and new formats into a single file, as opposed to designing a database schema or a complex container structure from scratch.

Any multi-file archive format would do, but ZIP is very portable and random access.

> I think most languages that are batteries-included enough to included a regex engine should have a a full-fledged PEG parsing engines

Then there would be more PEG horror stories. In addition, string and indices in regex processing are universal, while a parser is necessarily more framework-like, far more complex and doomed to be mismatched for many applications.

Guess what, doing a relatively complex but standard task (filtering and aggregating example penguins) with a specialized and ossified library (Pandas) is better than doing it "bare.handed" with basic lists and dicts.

More terse, more efficient, less error prone, hopefully more numerically accurate, as if Python had an ecosystem of well designed libraries on par with R.

AES and RSA had enough public scrutiny to make backdooring backdoors imprudent.

The standardization of an obviously weaker option than more established ones is difficult to explain with security reasons, so the default assumption should be that there are insecurity reasons.

If there is a risk of a 10+ million dollar issue there is also some manager whose job is to overreact when they hear the announcement that someone wants to eliminate thing X, because they know that thing X is a useful part of the systems they are responsible for.

In a reasonable organization only very minor systems can be undocumented enough to fall through the cracks.

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts.

Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve, etc.

If you follow the prescribed procedure and involve all required management, it stops being a beginner's mistake; and given reasonable rollback provisions it stops being a mistake at all because if nobody knows what the thing is it cannot be very important, and a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed.

It makes enough sense for someone to implement it (sans hackers in hoodies and stage lights: text or voice chat is dramatic enough).

Perl was immensely popular, but it isn't necessarily enough to qualify for the personal "bubble" of languages one learns. It was a good choice of proven, general purpose interpreted scripting language for you in a time when Perl competed with AWK and shell scripts, but in the 1990s I used mainly C and C++ before adopting Java quite early and almost exclusively; when I later decided to learn some proven, general purpose interpreted scripting language Python was my obvious choice: more advanced than Perl 5 and more popular than Ruby.

Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.

For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.

For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.

The "coding error" is a somewhat deliberate choice to fail eagerly that is usually safe but doesn't align with the need to do something (propagation of the configuration file) without failing.

I'm sure that there are misapplied guidelines to do that instead of being nice to incoming bot management configuration files, and someone might have been scolded (or worse) for proposing or attempting to handle them more safely.

It can be really bad, especially if the enemy deliberately attacks when you really need your site and/or makes you look evil.

More generally XML is so thoroughly out of fashion that it is perceived as driving resume-driven architecture backwards in time, into an unfamiliar "dark age" of deliberate engineering decisions.

Wrong question, an unreadable "proof" goes nowhere and comes from nowhere.

The painfully staggering density of undefined concepts, novel jargon and informal language in the paper obscures the difference between old ideas, possibly valid new ideas, and worthless AI slop and insanity.

Not if you spend that energy, or more, to cool the device hundreds of degrees below room temperature using liquid helium.