weinzierl

Wait for the timing of the next release. It will be a Christmas present.

That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.

This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.

He is probably not alone, so this "curse" is has never restricted to Lisp completely. There always have been some wood and metal workers besides the many LEGO engineers.

Many from my generation, who grew up during an era of information scarcity, have huge stashes of hoarded data. But what can we do with it? There is no way to legally share it, so we take it with us in our graves.

EDIT: Many good comments, but they all suffer from one blind spot, so I answer here instead of individually.

A lot of content is only legal because it is on YouTube (or any other platform that has deals with the content industry). Sure, we can share illegally in a way that is obscure enough that no one gets sued. But what help is that, eventually it will get either popular and sued out of existence or forgotten and fade.

Then there is old content that is not legally shareable at all, like old game ROMs. Plenty of millennial stuff there but the Gen-X world is already half forgotten.

Cooyright is just too long and too unreliable. What we need at least is exemptions from Copyright for archivists, otherwise a lot of stuff will simply be lost in the coming decades.

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.

What I wish existed is smarter handling of megamorphic call sites. In practice most dyn sites only ever see a handful of concrete types, so tracking which types actually get coerced to dyn Trait in reachable code could prune a lot of the vtable fan-out. Probably not easy, but does not have to be perfect. It's also OK to acknowledge that this sometimes fails and handle that gracefully in visuslization.

And a view that overlays coverage data, so you can see which paths are actually exercised. Could be especially useful with panics, so you can see which panic paths tests actually hit.

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.