Comments URL: https://news.ycombinator.com/item?id=45953139

Points: 5

# Comments: 1

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...

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.

Private Eye definitely did a lot of work, but they were not the only ones, and multiple freelancers and journalists worked on it "in the shadows" for years.

The Post Office tactics of calling editors to make threats and play down the stories were also quite influential.

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.

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.

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.

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.

Reality on the ground is that there were governmental subsidies to implement them, so everyone got them.

How much they actually help vs create problems is still an open research problem

Without any idea of the market demand. At the current cost of developing new Platforms (a few billions), you could understand being risk adverse. Low sales would have killed the whole companies.

Starlink has been their solution to that but it is still an open question how well that makes money and for how long...

And we have not really seen a space market exploding behind it.

Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc.

But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest.

Sadly i do not have solutions rn but if people have ideas please come offer them.