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.

It's not ideal, but governments already use MS products on a large scale. Quite some are cloud-based these days. And they are an established corpo that is doing well financially compared to pure model operator that might be broken up the day after tomorrow for spare parts by their investors and creditors, which put the confidentiality of the conversation logs into jeopardy.

[delayed]

GraalVM for example places heavy restrictions on reflection usage. It also performs aggressive tree-shaking to include only those classes and methods that are actually going to be executed. Corresponding measures are required for several common libraries to be compatible with GraalVM.

Hotspot's AOT is promising and doesn't have those pitfalls, but has not yet been delivered.

It requires heavy trade-offs.

As I have already written above, one will reliably make errors with memory unsafe features even if one is careful. Therefore, it's not the same thing.

People using a tool in the wrong way is not necessarily an argument against the tool though. There's always the potential for misuse. (Of course, this misuse should be sharply distinguished from the errors caused by my memory-unsafe features since those will reliably cause errors even if programmers are careful)

This is about an issue in the type checker, which would lead to unsoundness also in a C++ program. And also in Rust most causes of runtime failures are actually things that happen in `unsafe` blocks.

That's not how "unsafe" works at all. If "unsafe" is so commonplace in a code base that your statement becomes relevant then the project is badly run, and memory safety is just another problem among many others. Similar to accepting code with empty or nonsensical `catch` blocks.

Of course people will still program for the foreseeable future. But it is still a legit question how long it will be before people come to accept a vibe coded program and are ready to deal with its flaws (of course with more vibe coding) compared to hiring a consultancy.

I'm not talking about mission critical software, but bespoke business applications that are produced by software engineering sweatshops and where the actual users are inured to incomplete features with sharp edges, arcane bugs, and incomprehensibly long intervals between bug report and fix.

Even in mission critical software we will likely see a lot of LLM tool usage. Even if the copyright plug is pulled and all vibecoded applications are regarded as copyright violations, its uses to analyze existing code and give advice will remain. In this world, writing applications entirely by hand will become an artisanal discipline.

It is well known that proof assistants can be wrong. Fortunately, the theories underlying formal methods are usually simple enough that it is feasible to write verifiers for these proofs.

That's the same kind of issue like a bug in a C++ compiler.

That's not the issue though.

That's the thing; neurons in ANNs are really just processing the inputs they receive from other neurons. But natural neurons are not necessarily restricted to that.

Intelligence services are very likely far ahead and for obvious reasons the public is not privy to it.

I gave up before I read "Minesweeper" for the first time.