Why not use AI to speed up the Python runtime?
V8 showed what focused engineering can do for JavaScript, and Astral showed how much room there is to improve Python tooling. The same tricks may not apply directly, but AI could definitely accelerate the work.
Volcanic winters are far more frequent than catastrophic asteroid blasts. Disregarding a volcanic winter possibility and its impact is like disregarding the possibility of a pandemic.
True. But if you're working in public policy in a vaguely-democratic country, and trying to get anything useful done - then the public feels vastly more familiar with "giant asteroid wiped out the dinosaurs" than with volcanic winters. So, just like "Zombie Apocalypse (wink)" disaster prep - you go with a "close enough" scenario which lets you achieve some actual preparation.
On ash and slag heaps that are incredibly toxic to their surroundings. Current research suggests that living in the vicinity of such a heap has an immense effect on cancer rates.
Nice! Now moving from Windows to Linux is the "easy", visible part. Replacing US cloud + US AI dependence end to end is much harder, and that’s the real deal today.
I think you're right. Even though France might not have done much yet, it's a sign many people will read about and maybe think Linux is a good alternative. That's a win in my book.
AI and cloud are another thing altogether. Mistral is alright, open-source AI models are alright, but overall I think they can't compete yet. And I don't think there are fully capable cloud alternatives to AWS, Azure and Google Cloud yet. EU pushing Nextcloud-based alternatives really doesn't fuel confidence honestly. I mean Nextcloud is fine, but that's not the big alternative push we need here.
Really though, how many companies actually need Azure, AWS? In my experience in SME's there is _so_ much overcomplication, over-provisioning and overspending going on because there has been a default assumption that US cloud==lower risk.
Governments properly mandating that data be held in the EU, or even in orgs with proper EU entities and checks and balances against US interference in time of conflict would change the game. This is what the EU should be working on... a data residency regime that allows us to use AWS but creates a firewall that allows us to take operational control of the servers if the US continues on it's current path.
Wouldn't that imply that design is solved (at least regarding visual elements discussed here)? Then why not move onto other things? Why self-sabotage their success?
A lot of bad, unwanted features get written purely because "developers need something to do" and the same thing happens on the design side. I spent over a decade as a developer at various companies fighting bored designers who just had to redesign the look and feel of the app over and over because the current one was "stale" and "lacked pizzazz and pop!" But, then we devs would do the same thing to the feature list, refactoring and reimplementing and adding features for the sake of writing software, so... I was a hypocrite to complain.
Use them for what they are (hints, documentation). Use it for gradual typing when implementation makes it hard to understand return or parameters types. But don't enforce it across your code base, use another language or another mindset instead.
Those kind of tools should have the same name as the command they replace, I don’t want to change my workflow with this or that. I think a simple wrapper over cd with fzf is good enough and much simpler. Claude can probably write it in a few minutes.
Of course you can alias, but I was not very clear indeed. My point is that these tools ship multiple commands (z, zi, etc. autojump does too). I treat core shell commands as interfaces: keep the name, swap the implementation. If there's just one command, you can of course alias it (but why should I do this final step); if there are many, it turns into clutter. These tools should enhance existing commands instead of reinventing them: the goal is the same result, just faster and better. The philosophy is non-intrusive augmentation, like bash_completion or fzf.
Further improve XDM, XPath; achieve v3.1 compliance.
Add remaining v3.0 features to the XSLT engine.
NB. We're picking the low-hanging fruit first. So major, fundamental features of the languages are being implemented to begin with. The fine detail will be added later.
Although the eventual desire is to implement all of XSLT v3.0 functionality, some more advanced features will be implemented sooner rather than later.
reply