samus

What happened with the CPython JIT is not a sign of ossification. The failure to produce a proper PEP that answers all questions and concerns shows that the experiment should not have been merged in `main` in the first place.

It's just a Lisp dialect at the end of the day and not much more complicated to learn than Javascript. The only unusual aspect is its prevalent use of dynamic scoping, although nowadays lexical scoping is also available and encouraged AFAIK.

It's not red tape, it's about making sure that the effort actually delivers what it promises and can continue to so in the future. From the state of the draft PEP it seems it doesn't and it won't ever. The SC merely put the nail into the coffin.

It looks like it very much should never have happened like this. The actually hard and awkward questions have not been asked beforehand, and the SC doesn't like their hands being forced, and rightly so.

Getting a JIT right is hard work because time spent by the JIT is time not spent doing actual work, and finding the correct tradeoffs is very much an empirical problem.

Mature projects simply don't like large unexpected code drops if it is not made clear beforehand what the blast radius is and how it is going to be maintained. On top of that it seems that the performance gains weren't as expected and require further invasive changes.

Implementation effort has never been what has held these efforts back. LLM helps with squirting out code, but the hard tasks are benchmarking, profiling, community engagement, knowledge management, and dealing with the hard questions such as whether the change is actually worth the additional complexity.

These concerns won't go away even if we give up on human developers being able to grok the code and instead completely relying on LLMs for coding.

Just tally up how long it takes to shop, cook at home, and clean up, and multiply it with the rate at $dayjob. I am pretty sure for most people on Hacker News the figure will be significantly higher than at a restaurant, and we would have to adopt a similar working style to bring the cost down, like buying and preparing in bulk, focusing on a few dishes, cooking for multiple people at once, etc.

I am not exactly a fan of this kind of comparison unless one can actually freely allocate one's time, but it is illustrative.

Depends on your definition of overpaying. Governments are generally not the best at keeping costs down, for various reasons. To a certain degree it's simply organizational inefficiency.

The difficulty of implementing a replacement for MS Office was never the implementation effort. There are problems where LLMs can help, but the remaining crucial roadblocks are of organizational and political nature.

> Further, America has definitely been pumping money into Microsoft, for instance with hefty defense and public administration contracts. It is incredibly naive to believe that the US allowed the Microsoft monopoly to corner the office market without the opportunity of establishing a digital hegemony being a significant factor.

That's not a subsidy. That's a customer paying for a product. Apart from that, the USA has Anti-Trust laws, and Microsoft has been at the receiving end of these in the past.

The issue with building alternatives is always that it is quite easy to get something that can do 90% or more of the work, but the remainder takes a lot more time to pull off.

Implementation was never the bottleneck. The hard part is about usability engineering, which requires feedback cycles with actual users to have good results. That's a hard, time-consuming process; merely dogfooding the product won't work.

Governments are free to pay consultants to fix it. It's Open Source after all.

In the best case that's a one-time cost though.

Expect problems as soon as the people who made and maintain them are gone.

I get where these places are coming from - it is really easy to get started implementing these workflows in Excel and just grow it from there. But they are really fragile and hard to audit - who knows whether they work correctly even now! And it's highly likely that only very few people actually understand how they work and how to maintain and extend them. Great for job security, but there is going to be a lot of problems when the people who know them are not available anymore. Better to transition the embedded knowledge to something more maintainable as long as it's still possible.