di4na

I would not call it harm. The use of uring in higher level languages is definitely prone to errors, bugs and security problems

Depends who you talk to.

You are getting this wrong.

Basically the framework, like the Shield before, is the Commission trying to show "look, we fixed it".

Sadly, for the previous two times, the ECJ pointed out after the fact that no framework can fix the lack of data privacy law in the US, and that as such, the Shield, just like its predecessor, was not allowing what it claimed to do.

The Framework has not been tested in the ECJ so far, but the US has not significantly altered its laws so...

Why would you owe them something if you already provided the code and docs?

Can I recommend looking at what people studying Experts at work and how they manage to do better than they "should" be able to have found? There are tons of domains looking at this empirically :)

There is work in progress in the high-level inquiry that should manage to produce most of it. Besides that, you can try to check the appeals court reports, which are not too bad.

It happens to be even worse.

Because we have no way to detect all the cases.

A lot of the cases were handled in the "Post Office courts" (I don't remember the correct name, not a British), and there are more or less no records of them. So you need to ask people affected to come up and find ways to validate them, then create a case for quashing it. It is a total FUBAR mess.

Note that there are already some of this stuff in the compiler for AOT. Using these new specs for AOT optimisations is going to be a far taller problem than catching some of the errors

Yes and that is what these analyzers do.

The problem is that your space grow really fast and that your compilers are really not built to extract that information in a few ms.

Even less to regenerate only part of it based on partial input. Even less when the input may not be correct syntax.

Also that linkage being kept is exactly what this post talk about. How to keep it intact through the different steps and transformations in your pipeline in a way adapted to the kind of queries you are going to need is... Actually hard and dependent on the query.

Which means that adding new features to your IDE would regularly need (and actually does need) a new way to store and query that data.

But yes. Reusing part of the rust compiler (or replacing some of them) in rust-analyzer is already something that happens and that maintainers work on.

It is just not that easy. But yes, C# and Roslyn in general was built with that in mind. Typescript too.

If you are interested in writing down more of what problems you have with scripting languages, feel free to shout me an email. Should be in profile.

I have been slowly working on a model of what problems i see in this domain and my own ideas to "fix" (or more like try to) them. So would love to see other perspectives.

yes but it is portable. On the lisps machine, you could not port to a different type of machine by another producer in general, even less across version. The Linux ABI is stable.

One thing i think forgotten here, which actually is in the Worse is Better talk. But people tend to miss it.

These ST and Lisps systems failed at another aspect. Reuse. The biggest change of the past 2 decades in software engineering compared to previous generations is the amount of reuse. It is tremendous.

It is hard to talk of cause and effects here, but mostly this is due to the Internet. At this point, the vast majority of code running on any proprietary system is... Open source infrastructural packages.

This condition a lot of the current ecosystem. You can only reuse code on systems in which said code runs well. As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable".

Yes i know. It is far from magically portable, but it is far more than full machine living image SmallTalk or Lisp like.

As such, these "living code" are fundamentally evolutionary deadend. They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism.

On top of this, a lot of the elements to make this kind of machine works does necessitate deep in depth expertise. As the piece shows, the Newton is a pale copy of the goal because they did not have that knowledge in house nor the time (or money) to create it.

Same thing all over the stack. A good efficient logger need deep expertise. Same for a good localization library. Same for a good set of graphic servers. Same for audio servers. Same for a http parser or a network library. A good regexp engine is knowledge knows by less than 10 people in the world probably.

Once you realise that, you realise that at scale reuse is the only realistic way forward for software so ubiquitous as it is today. And that is how we got the current FOSS ecosystem, not because the code is better but because it would need too many licences to be manageable without breaking the bank in numbers of lawyers.

Same thing for the Worse is Better. It works because it provides extension points and can adapt. Something the Lisp and SmallTalk machines fundamentally failed to provide. And that is something Richard Gabriel focuses on far more than the whole New Jersey schtick in his talk.

Google has longer tenure.

The thing you seem to miss are the other common denominator.

Huge amount of money and unreasonably far into the future expectations of returns.

Means there is no short to medium term pressure to optimise for efficiency or returns, which means one of the fundamental element of good engineering environment is missing.

These companies build in a vacuum of limitations in term of cost and a vacuum in term of goals.