But John Carmack is in my mind a better software engineer. He writes elegant code that can be used and maintained for a long time. At least from Quake 2ish, but you can see signs of solid code architecture already in Doom.
Doom code will live almost as-is forever. The code Fabrice wrote for ffmpeg has been entirely replaced
Mozart doesn’t feel right. The code isn’t beautiful and elegant. It’s not built to last (at least for ffmpeg) or be some kind of masterpiece. He writes code to get a job done or tickle some intellectual curiosity. It’s not beautiful but that’s OK.
I think Unicorn illustrates one of the issues with his style. It wouldn’t have needed to exist of the QEMU code was architected into neat components. But then writing spaghetti code that gets the job done is why he’s so fast and effective. It’s a trade off
I think there’s actually a sharp contrast with John Carmack here. Fabrice might be smarter and faster but Carmack is perhaps a better software engineer. You can really see the development of his style from Doom and Quake source code, where Quake 3 source is like a beautiful gem of a code base.
I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer. In fact I’ve seen developers fall into the trap of mistaking their code as the product and thus spend so much time beautifying it that that fail to ever release anything.
Then you have the other end of the spectrum where people are too focused on hacking stuff together that the end result is unmaintainable.
The reality is there needs to be a bit of both to be a good developer.
For example, if you’re building a proof of concept (POC), then it’s more important to prove the idea than it is to define the architecture. And the reason for that is because you don’t always understand how the final product (whether it’s commercial software or a FOSS library) is best architected until you’ve gone through a few drafts of the idea. So spaghetti code isn’t necessarily a bad thing.
But then when you know your idea works and you need to flesh it out into something more durable, you start to refactor the spaghetti into something more maintainable.
Fabrice mainly releases POCs while Carmack mainly releases finished products. So it’s unsurprising you’ll see a difference in the style of architecting in their code.
I used to be someone who focused on beautiful code for my POCs too. And used to fail to release any personal projects. Then one day I learned to embrace the chaos of POCs and realised that you can getting something built and tarting it up afterwards was better than failing to build anything at all.
But the code quality is speed. And reach. You can not advance, unless you can read the code, you can understand the model, you can not scale beyond a certain point. The beauty of the architecture is the ability to build a spaceship compared to a train of kerosene tankers. Physically similar, but in capability radical different.
I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation. This is literally the difference between rocket-science and exploding failed projects. Everyone can pile up explosives, not everyone can go to space today.
Its a great interview topic to filter this kind of candidate out of companies.
No it’s not. Code quality is just code quality. It's a subjective measure. eg how do you define one thing is of greater "quality" than another? Is it CPU ops? Memory footprint? Code readability? And how do you measure readability? By who? What I find readable someone else might not, and visa versa.
If you’re making choices to improve development throughput then that’s fine. But so often I see developers architecting code for what they mistakenly think will improve their throughput but ultimately they spend longer on writing those abstractions than any time they have saved when using them.
Sometimes this comes down to developer vanity, sometimes it comes down to poor alignment of goals and/or communication between the product teams and development teams. And sometimes it’s just because solving problems is fun so naturally we’ll look for problems to solve. But whatever the reasons, I’ve personally seen this happen (as well as being a victim of it myself) enough times to know it is an underestimated problem.
> I find this very scary. Somebody unable to perceive capabilities and tech-debt. If you can not perceive that- you should not be let near executive decisions or code-base evaluation.
This is a rather insulting assumption. I've been a tech lead for around 2 decades now and have worked on plenty of brownfield projects in that time. I know what tech debt looks like.
The problem with "tech debt" is it can mean anything from "this is ugly code that takes 5 minutes longer to read but it works well" to "this in a insecure/unstable pile of horse manure and customers will start to notice".
The latter is where time should be spent. The former is a vanity project that doesn't bring the business any value.
That's not to say that developers shouldn't ever spend time on the former examples of tech debt, just that it's of a lower priority than getting the project working.
Thanks for saying this! I completely agree with everything you said!
There’s far, far too many people who confuse code quality for speed of development and start treating code quality as the product for customer base in the hundreds and active customers in the dozens and for most features to be basically unused.
The reality is that tech debt as a concept these days is hardly real: to be in debt means previous decisions or a previous implementation makes current work extremely hard or impossible, but, the truth is that the human factors such as knowing what to build, team collaboration and even speaking to customers matter far more and can get you “in debt” so so much faster than code alone. At least in your typical SaaS company.
If you ship code in a way that you let tech debt pile up to the point that customers notice it, you have an organisational problem, not code issues per se.
The fact that a lot of people don’t get this is really baffling to me.
.. is very, very important in the context of milliseconds, hours, days, weeks, months and years. And decades.
Today, you might say that John/Fabrice’ code is readable/unreadable, but will that also be true in 5 years time, in a different cultural/technological era?
Obviously yes in the case of these individuals - because the ecosystem their products have created is self-sustaining at a mass (consumer/social) level.
I’ve built software which has shipped and effected the lives of millions, too. Many of us have.
But I have not built a massive ecosystem by working on the right software which was adopted by millions of developers who read my code, was inspired by it, and used it for something in their own products - thus creating sub-ecosystems upon sub-ecosystems, a big sprawling tree of economy which spreads out into the mass of humanity who use technology.
In this story we have two cases of individuals who have accomplished an extraordinary reach of software, in their own uniquely flavored ways - and this demonstrates that there are no absolute requirements to strip personality from the code - as long as its damn good code in the first place.
>filter candidates out of companies
It’s a great way to decide not to work at a company which managers do not understand the importance of architecture at various scales, milliseconds, seconds, hours, days, weeks ..
It's the opposite, better-factored code makes me, a mediocre developer, capable of making progress instead of hitting a complexity wall.
It's separate from striving for "beautiful" code, beauty within well-factored boundaries yields dimishing returns compared to just having the boundaries.
> I think developers sometimes get too obsessed with code quality thinking that smarter code makes them a better developer.
Not much about "smartness", but code can by far outlast many "product" sold on top of it, so it can make sense to polish them more than the ready to throw gift paper.
People will certainly buy nice gift paper wrapping cheap crap music toy of the day. But they will also value differently access to a beautiful handcrafted musical instrument. On the other hands, people who don’t even play any music won’t be able to assess any musical appliance.
I wonder if what you're noticing in Fabrice's code is a lack of _abstraction_ beyond whats obviously needed to get the job done. It's not spaghetti IMHO, I think its what code looks like when you're smart enough to just hold most of the problem in your head. I am speculating a bit here, because I am not that smart.
If I had to describe it in aesthetic terms I would maybe say brutalism?
>Mozart doesn’t feel right. The code isn’t beautiful and elegant. It’s not built to last (at least for ffmpeg) or be some kind of masterpiece.
Pedantic much? It's not about him writing elegant code like someone would write elegant music. It's a comparison about the skill level achieved, Mozart-level vs Salieri-level (and in the sense of their Amadeus movie rivalry, not real world).
His code tackles very complex subjects, succesfully, with huge technical skill, and has been reliable and relied upon by millions...
> I think there’s actually a sharp contrast with John Carmack here. Fabrice might be smarter and faster but Carmack is perhaps a better software engineer.
There’s few things I find more pathetic than trying really hard to show who’s best and ranking things that have no business being ranked.
You will find humans are n-dimensional and elude these simplistic categories.
Yes, ranking requires reducing to a single dimension where all interesting things are multi-dimensions. This is a lossy process, which often tells more about the one(s) doing the ranking than what's ranked.
I was thinking of sport players that have their stats laid out as a radar chart. One might be average on defense, but a world class striker. Is he better than a world class defender but average striker? And even that is a convenient and lossy approximation.
You don’t know there’s still millions of lines of code being written for environments with no OS or much more limited OS than what’s on modern desktops/laptops/servers?
It’s not the only time the CCP has reported an unbelievably low number of casualties in a large catastrophe. Seems like the number of dead is always around 6-7 (sorry) no matter how big the incident is. Like the flooding of that tunnel a few years ago where the authorities tried to hide how many flowers were put up by the tunnel
Yes, but at a significantly higher level of magnitude. Their official count is 122,398; the US reported 1,238,123. Both are undercounts, but China's is probably much more of an undercount.
I’m not sure what your point is. I could certainly not, and I could certainly not write a breakthrough paper in mathematics even with the most advanced AI. I wouldn’t even know what to ask of it.
Perhaps I could set up an elaborate master agent to consider all possible new problems in mathematics and ask sub agents to work on the most promising ones. But then I could probably also program a self driving car system which could win an F1 race as well.
Well yeah of course, using APIs io_uring and grand central dispatch is basically the whole point of all this async stuff in a systems programming language. It’s absurd it hasn’t been mentioned more here.
OS Threads are for compute parallelism, async with stackless coroutines (ideally) or green threads is for IO parallelism. It’s pretty straight forward.
And IMO, Zig has show how to do async IO right (the foundational stuff. Other languages could add better syntax for ergonomics.
It's not the whole point, there's lots of other (albeit smaller) gains to be had once you have a strong async apparatus.
The core of your async implementation doesn't have to care about I/O - as long as it has a way to block/schedule fibers, it's easy to implement io_uring/IOCP based I/O on top of that - it's a matter of sticking a single IO poll in your main loop, and when you get a result, schedule the fiber that's waiting for it.
Another thing you get almost for free is an accurate Sleep(0.3) - your Sleep pushes the current fiber in a global vector with the time to be resumed, and you loop over that vector in your main loop.
We're writing a game engine so WaitForNextFrame() is another useful one - the implementation is literally pushing the current fiber to a vector and resuming it the next tick.
The C compiler was a prime example of an application where the LLM can self-evaluate/optimise, with one of the best set of tests could imagine. Yet the end result was a mess.
I have experienced areas where high productivity can be had without much loss in quality. So I can believe it. But it really depends on what you’re doing and I firmly believe many companies will run out of easy stuff that we can blaze through with AI fairly quickly. At least that’s where we seem to be heading
I don’t see why you would look at nuclear at all on a 100 year horizon. At that timescales you gotta look at the fundamentals:
1. We’ve got a free fusion reactor in the sky and collecting and storing that energy is fundamentally cheap. Especially in a long term perspective when the materials needed to store the energy will be mostly recycled and practically free.
2. We’ve got a free fission reactor under our feet. Drilling deep enough expensive now but there’s no reason it needs to be. Se Quaise for progress in that area.
3. In a 50 year timeframe we don’t have any spare capacity to add more global warming from the thermal forcing of thermal power plants. Yeah you heard me right, thermal power plants contribute directly to global warming, and the effect is surprisingly significant. The good news is the effect disappears rapidly when you shut them down, unlike greenhouse gases. And we should certainly never shut down any nuclear power plants until we’ve eliminated greenhouse gas emissions. But at the same time, while we have an insane amount of greenhouse gases lingering in the atmosphere we can’t afford adding global warming from thousands of new nuclear reactors… like some nuclear proponents would have us do.
A 100 years from now, if we’ve brought greenhouse gases down again, that’s when we can start considering adding significantly more nuclear power. Though I doubt there will be any interest. Makes sense for space travel though.
I’m pro nuclear despite all that. But more from an R&D perspective.
1 - fusion reactor in the sky is not that easy to capture 24/7 due to nights/winter. BESS can partially alleviate the problem, not solve it.
2 - geothermal has an inconvenient property to lower output over time.
3 - nuclear requires far less grid investments, far less mining/materials
4 - If we are serious about nuclear we should investigate up to smallest detail how hitachi deployed first ABWR for such a short time/low cost and do that in series, en masse. I can bet in 20y Germany will still have far worse emissions than France
I missed this, the point was more long term view. If you want a robust power network that doesn't kill the planet you really need to consider a timescale where climate changes effects are observable I'd argue that is a 100 years. We are debately between 100-200 years into the industrial revolution and climate changes worse impacts at still 20-50 years off (Not a lot of time to reinvent the economy just to be clear). But in that conception of time 100 year time frame seems very reasonable.
If you just look 10 years ahead you'd probably conclude solar, wind and maybe hydro is enough because short term thinking will always undersell the climate risk in my opinion. My justification for this thought is look at climate deniers arguments its always about magnitude and speed now because its the last effective argument.
Nuclear cost recovery and profit function for proven GEN4 is also on the 20-30 year timescale (depending on how much cost overruns they've faced it could be 50 years for bad cases) not the 5-10 year timescale. Making them unattractive financially speaking. Despite the fact that after that time which most US reactors are they are extremely profitable for the operator because the fuel -> power out is incrediblely in their favor. Ultimately, it takes longer term risk evaluation to show their benefits but they are undeniable and will be involved in solving the climate crisis.
The new response works for me, because in my mind I’ve always defined “woke mind virus” as a a mental virus which causes people to become absolutely pathologically obsessed with fighting an imaginary enemy they call “wokeness”. It’s the only definition which makes sense. “Woke” itself was never that viral.
People obsessed with fighting whatever they perceive as "woke" which remains ill-defined on purpose so they never have to actually formulate a rational take down beyond their emotional response
I find the talk around Donut so weird. At CES we were told they had nothing because they hadn’t shared third party test. They then shared third party tests remarkably fast. From the dating of VTT reports it’s clear they shared it as soon as VTT finalised their reports. Now they have nothing because they haven’t released enough tests fast enough?
It’s clear they have something very interesting.
We’re mainly missing low temp and energy density test. If they have something real, obviously they’re saving density for last (near the time real customers get their hand on the bike), since it will give them huge amount of attention. Can’t fault them for milking what they’ve got (if they got it) for all the marketing hype it’s worth.
We’re also missing cycle life test but the claims can’t really be fully tested in a reasonable time. So even if their tests show projections that indicate high cycle life, people will doubt it, or shift the focus to ageing effects. So personally I don’t care much, we just have to see how it works out in real life.
The lawsuit incidentally reveal their connection to partners which does reveal that there’s something real there. Another criticism was that the couldn’t have developed all the tech from scratch themselves in such a short time, and now it’s clear they didn’t, they’re using tech licensed by other companies with real competence in the field.
If it’s as good as they say with zero caveats and can be manufactured at scale is another matter
I think by this point they demonstrated basically all the characteristics of their battery well enough, except for the density, but then that was a pretty damn important and big claim. I'm not sure they can afford to delay that much longer. Or the actual shipment of products.
They didn't share third party tests. They shared tests done by a party they contracted, and whose test reports don't back up the claims to the extent that they claimed.
Do they have something interesting? Maybe! But it could also be yet another Theranos. Extraordinary claims require extraordinary evidence, and they haven't exactly been forthcoming with it.
Fabrice is more clever and faster, I guess.
But John Carmack is in my mind a better software engineer. He writes elegant code that can be used and maintained for a long time. At least from Quake 2ish, but you can see signs of solid code architecture already in Doom.
Doom code will live almost as-is forever. The code Fabrice wrote for ffmpeg has been entirely replaced
reply