Would this logically extend to also include C-reliant languages like Python and Ruby (the latter being mostly a grammar underpinned by C) as technical debt also?
Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code.
A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.
Most Python libraries that relies on C are numerical stuff.
From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library.
On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.
All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs.
There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.
Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem.
My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.
Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.
Disclosure: Didn’t read. But I did always get heckled at gatherings for inverting my controls, and then forgetting to switch them back. I think it came from whatever console you started with first (Sega Saturn), if you played early PC joystick games (Tie Fighter!), and Goldeneye’s Solitare configuration, which allowed deadly accuracy without needing to invoke the crosshairs.
This is specifically mentioned in the article as the common reason given, but that it is wrong. People think this is why, but then they study them and it’s an innate difference.
It's not as simple as whatever this article says. I can play inverted and regulary and have played games throughout my life in both ways. So it's not simply an "innate" difference.
It's preference, and people can easily learn the difference if they played for 10 mins. It's easy to get used to.
This is probably the right answer. Similar to "dont fight the police on the street, fight them in court". Can even quiet-quit during the project if you need to.. software can take an awfully long time to build..
Also, track your time during the work. And keep all correspondance. Paper trail, paper trail, paper trail.
Yes, very clever. Have them deliver the diploma while you deliver the software... ever...so...slowly... and then, charge for consulting fees to make it work after you graduate!!!!
I imagine Finland's would be similarly branded a disaster if the present-day internet/social media megaphones had existed..
History books on 1945 aggressive monetary policy change: "The public didn't like it"
History books on 2025 aggressive monetary policy change: "The public went frigging bananas, doxxed their leaders, coordinated widespread disobediance on the scale of GME, etc"
(Granted I live in the US, and that's putting it mildly how the US would react)
I think you are 100% spot-on. Good enough has always been fine for the vast majority of people and the vast majority of use-cases.
Couple this with decreasing costs of storage (and ideally compute), and it doesn't matter if the data model is garbage, people can still get something workable that's better than the awful Excel files they curate now. It will still make errors, but eventually fewer than their spreadsheets.
There is no "good enough" for data modeling. There is correct, and there is "this works, but it has latent bugs that will eventually surface." You either have referential integrity, or you don't.
In college, in a music class (History of Jazz maybe?), I had to miss an exam, and the professor assigned me an essay to make up for it: Life and impact of Django Reinhardt, minimum of 10 pages (back in the "12 point font, Times New Roman" days).
This was in the early '00s, and hand-over-heart, there was less than 10 pages _on the internet_ about Reinhardt. The collegiate library was not much more help.
