weinzierl

I just ran Andrej Karpathy's Tiny Stories model on a tiny ESP32. In principle we could probably have done this in the 80's and it would have been so amazing.

Works for whom? For the customer, "works" means the features work. Security is a vague, nebulous thought at the back of their minds.

The provider provides features. Lack of security has no impact on them, not in the short term and not in the long term. The short term we can't change easily, because people are people. The long term we could: regulation can turn negligent security into a lasting cost.

As much I'm against more regulation in general, I'm afraid as long as we don't do that, companies will always prioritize more features faster over security.

Thank you very much!

I'd be interested in the latest version of the dynaham.w program, if anyone has that.

noreply@[HN username]web.com

falls-dann-sonst

would be more correct, since "wenn" is temporal, like the English "when".

Many Germans often use these wrongly in everyday speech, but mathematicians like Friedrich L. Bauer probably wouldn't.

When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.

It's not that it can't be done.

It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.

We've git that under control with regulation and the help of organizations, some of which still exist today.

This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.

I, for my part, as much as I dig a little 70s and 80s retro stuff, would never ever want to go back.

But the work doesn't go away, it moves. Someone still has to judge the 100 results, pick one and integrate it with everything else. That part doesn't partition, and it's where Brooks put most of the schedule anyway: in the same chapter his rule of thumb gives a sixth to coding and half to testing.

For me it was a bit sad to see the mad and creative UX world of the homecomputer era being bulldozed over with the minimalist uniform results of the scientific usability research.

Little did I know that a mere quarter century later we are back were we once started and everyone as clueless as we were in the 90s goes overboard everywhere as if there was no tomorrow.

Yeah, and it sadly makes me miss the nicely ordered and easily usable world - I'm gettin' old I guess.

I worked with many clients that knew exactly what they wanted and (very importantly) could write it down in a way that they could validate. That is often not the perfect spec from an implementation point of view but by and large a solid aporoach.

Client wrote down what they wanted, programmers translated it to code, testers validated that against what clients had written down.

Now we have tickets, where BA's (but most of the time developers, really) write down the lore that is told in numerous meetings.

Tickets are supposed to be ephemeral but never really are, that's why we keep some of the lore in Wikis. Except Wikis are good for text, not so good for everything else, that's why the lore spreads to Figma, Excalidraw and Google Sheets (if you are lucky, xls documents on Sharepoint if you are not).

Now we start coding. Some of the lore get's solidified into code, which is good, some turns into tests which is good too, if you are lucky some turns into formal spec a tool can check.

But, there is always something left that gets spread evenly - more or less - across regular comment, doc comments, commit messages and various md files, most notoriously the README.md.

Which brings me to user documentation which again is often spread over the whole oeuvre of documents and systems we mentioned. Not to mention the confusion of most documentation about its intended target group. Is it user documentation for the enduser, really? Rarely!

Oh, and then the CHANGELOG that really wants to be release notes, but isn't, at least not entirely. Which is generated automatically, but isn't, at least not entirely.

Finally comes QA (but most of the time developers, really) but it doesn't have anything to validate against, so all they do is compare the faint memory of the lore they had heard in numerous meetings against what they have written down themselves in numerous places and are mostly content with the results most of the time.

Not only is this the only way to have a chance that they stay in sync with the code it also is the right way to make them easy for agents.

Y-statements are a nice way to practically do this.

Also: LEWG is the Library Evolution Working Group.

9 out of 22 countries voted "no", six would have been enough. These were Denmark, Finland, Iran, Italy, Japan, Luxembourg, Romania, Spain, and Sweden. In a addition and independently only 12 of the 20 participating members approved when 14 were needed.

The dispute is most likely because of a single feature called "contracts".

Very simplified these are conditions placed in a function's signature that are supposed to be checked at runtime.

The proposed implementation of this feature has been controversial from the start with prominent members of the community (Bjarne Stroustrup amongst them) expressing concerns.

I'd love to read that post!

I understand how to use Kani. I suppose Rust with Lean involves Aeneas, but this is over my head. I'd love someone to write this up, not only the mechanics but also exploring the current practical limits of it.

The complete omission of UB in the README could be one of two things. Either that the topic is not important or that it is considered a given and not worth mentioning.

Where does Goose sit when classified along these dimensions?

Sure, performance is right there on the packaging but no word about UB in the README. I read "Goose has syntax familiar to C and Rust" as DX in the same ballpark, but is it a performance first or safety first language.

If it is the former it occupies the same crowded niche as C++ and its many cousins and will have a hard time.

If it's the latter it will have much more room to prosper. We don't have enough languages in the niche that Rust and Ada fill right now.