It's part dysfunction for sure, but it's mostly just reality being messy. Anyone who worked on a bigger engineering problem, solving real business problem, learns very quickly that reality is messy and doesn't conform to rules. And that's usually main challenge of building any project.
And it's problem specific to software engineering. Any engineering deals with it - when you manufacture physical things, for example, tolerances, safety factors, etc, are all tools to deal with reality being messy.
He’s one of the GOATs, but this article is written by someone who has no idea about software engineering and full of exaggerations as a result. For example:
> Many times there are certain chunks which will occur many times in the code of a program. Instead of taking the time to translate them all separately,
QEMU stores the chunks and their native translation, next time simply executing the native translation instead of doing translation a second time. Thus, Bellard invented the first processor emulator that could achieve near native performance in certain instances.
JIT is about as old as Fabrice, or even older depending on what you consider a modern JIT.
The actual innovation in QEMU was that the architecture-dependent part was much smaller than a full JIT compiler, because it used the C compiler to build small blocks and parsed ELF relocations to be able to move them into the translated code.
This technique has since been dropped by QEMU, but something similar is now used by the Python JIT. These days QEMU uses Tiny Code Generator, originally forked out of TCC though by now the source is probably unrecognizable except in the function names.
Moreover, Transmeta did this for their actual processor back in the day. Transmeta's version even did it in multipass, fusing more and more instructions as they appear more, getting faster as the system is used more, up to a certain point of course.
This doesn't make Fabrice a lesser man, but truth is truth.
Claims of ‘firsts’ undermine the authority of this document, though not the achievements of the subject.
For instance Marco Ternelli’s dynamic binary translator ZM/HT dates back to 1993, when it was published by Ergon Development. It translates Z80 to 68000 machine code on the fly and was a successful commercial product. I’d be interested to hear of earlier JIT binary to binary implementations, especially others which coped with self-modifying code, without which ZM/HT wouldn’t have been very useful.
Self-unpacking executables are at least a decade older, and Fabrice quite likely had Microsoft’s 1985 EXEPACK, written by Reuben Borman, on his computer when he came up with LZEXE. That was bundled with MASM and Microsoft C 3.0, their first in-house version. Both were preceded by Realia’s Spacemaker product, which Wikipedia says was written by Robert B. K. Dewar in 1982.
> Compatibility with the IBM/1400 Series has, of course, been a key factor in the success of the Series 200. The principal software components in Honeywell's "Liberator" approach are the Easytran translators, which convert Autocoder source programs written for the IBM machines into Easycoder source programs which can be assembled and run on Series 200/2000 systems, usually with little or no need for manual alterations. The Easytran routines have effectively overcome the minor differences between the instruction sets and assembly languages of the two systems in literally hundreds of installations.
I wouldn't hold my breath for it. It was suppose to be released in 2020. It's end of 2025 and current release date is 2027 (and who knows if it'll be pushed back again).
Oracle has been selling large enterprise contracts for many decades and those enterprises were looking to migrate off Oracle since then too (I've been working on a project like that almost 20 years ago, at my first real job).
1. About 25% of their service revenue is from charging commissions in app store and other 25% of the revenue is Google paying them for search default. Other services include things like insurance (applecare) That's not exactly same type services that most of the people would be thinking about.
2. A lot of their services have less criticality (and it's not a ding at them - it's often very explicit design choice).
3. App store having hiccups or iCloud backups being delayed it's not something that will usually gather enough attention of media.
You might be amazed to know how critical Services are to functioning Apple devices. While they mostly can run offline, there are dozens and dozens of services that Apple runs that modern ecosystems require (like certificate related stuff). Other oddball things related to iCloud, APNS and the private services like iCloud relay are all extremely critical to billions of devices. Thankfully the all mostly fail open (captive portal is particularly tricky). Not saying they are as critical or visible as, say, Google.com going down, but none the less would have a very very large and visible problem if they all did go down suddenly. Thankfully, due to Apple design philosophy, most are totally decentralized and teams are given almost complete autonomy on how services are ran, which makes them a huge confusing mess but also, kind of a feature as Apple generally expects them all to fail in odd ways and the software can generally handle it.
And it's problem specific to software engineering. Any engineering deals with it - when you manufacture physical things, for example, tolerances, safety factors, etc, are all tools to deal with reality being messy.
reply