[sph]

First time I see his picture, and it’s a bit like someone’s revealed the identity of Satoshi Nakamoto when it’s clear they are going out of their way to protect their privacy and stay out of the limelight.

My impression is the guy had always better things to do than engage with the greater internet, like thinking real hard and solving difficult problems. Much respect to his work, but even more respect to his work ethic. When you have a strong vision, you need the ivory tower style of development rather than spending your days arguing and defending your choices with internet strangers.

[keyle]

No he never hid his identity, if you looked him up, you found his picture.

Satoshi shouldn't be compared, I don't hold bitcoins nor am I interested, but the name is a lore. It was stamped on the original document.

Fabrice Bellard is a real person shipping code; not an internet anonymous identity.

[coldtea]

Parent knows. He makes an analogy, not an absolute equivalence.

[f17428d27584]

Right, but the analogy is very clearly about someone trying to hide / protect their identity, which doesn’t apply in this case.

Perhaps it was trying to stretch it to “unknown figure”, saying this programmer is mysterious, even though it was not by choice but circumstance: fame has eluded him. (Not implying it’s desired).

But on that reading, I would still say the metaphor fails: it’s not effective at conveying this meaning and reads more like an unnecessary Satoshi name drop.

[sph]

> unnecessary Satoshi name drop

"Thou shalt not take the name of the Lord in vain". I apologise.

[bitwize]

As I say, Bellard is Mozart when most of us can't even hope to be Salieri.

[audunw]

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

https://www.unicorn-engine.org/docs/beyond_qemu.html

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.

[hnlmorg]

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.

[21asdffdsa12]

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.

[hnlmorg]

> But the code quality is speed

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.

XKCD parodies this problem with their pass the salt sketch: https://xkcd.com/974/

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.

[ryandrake]

This is one of the reasons I got away from writing commercial software and now only write code as a hobby.

To me, the code itself is the product. I want the code to look like a beautiful painting—the fact that it does something is secondary. I’ll sit there for hours working on things like const correctness, and making sure each class has the bare minimum amount of state/instance variables, making sure function arguments are named and ordered consistently, even though it has no effect on user-visible bugs or runtime performance. I’m the kind of person that paints the back of the cabinet. Even though no user will see it, I will know it is there.

Obviously this mentality is at odds with commercial software’s imperative to shit out barely working spaghetti code as fast and cheaply as possible, so I opted out.

[dkarl]

> 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.

You may have worked with people whose meaning of "code quality" encompassed things that you found inconsequential and a waste of effort. They may have even told you that if you didn't care about those things, then you didn't care about code quality. But that's not true. It only meant you disagreed with them about what code quality is and how to recognize it.

You draw a distinction between aspects of code that tend to lead to better outcomes and aspects of code that don't matter. You say you know what tech debt looks like. When you look at a codebase, you have opinions on where time should be spent to improve it. "Code quality" is shorthand for the heuristics underlying those opinions.

Instead of accepting that other, possibly dumber people get to define what code quality is, own your own definition of it and use it when you communicate with other people.

[brunooliv]

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.

[FpUser]

>"But the code quality is speed. And reach. You can not advance, unless you can read the code"

I am not sure about "proper" definition of spaghetti code but speaking of long functions: if it is straight code that reads like a book and has no common parts to refactor for further reuse it is actually way more understandable and debuggable then mess of 3 liners spread among 20 files and 10 microservices running under k8s.

>", you can understand the model, you can not scale beyond a certain point"

The needed scaling is being determined by business needs / projection. If you implement service for some SMB that deals with few partners and limited set of business entities in database and architecture of said service addressing Google style of scalability with corresponding overheads and costs you are definitely committing a crime in relation to your client.

>"Its a great interview topic to filter this kind of candidate out of companies." -

basically making sure that instead of pragmatic engineer who can deliver functional and serviceable product to client in reasonable time with reasonable costs you will have them pay for spaceship built by architecture astronauts

[overfeed]

> 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

Other people can do the important work of investing time to understand the model and simplify the code architecture, as proven many times over by actively maintained projects pioneered by Fabrice.

To kickstart a project, you have to show people that something they assumed impossible or hard to achieve is actually possible by dropping it in front of them.

> Its a great interview topic to filter this kind of candidate out of companies.

Fabrice Bellard ships. It makes sense to filter him out if you're a bank or an org with well-established products that prefers stability over velocity. If you're a start-up or have lots of greenfield projects requiring fast experimentation loops: you need folk who can ship quickly. Most organizations have a mix of projects and need a healthy mix of engineers, or ones who can flip modes relevant to the project.

[pjmlp]

Companies outside software as a product rarely care that much about what their physical goods are processed by IT, this is how you get outsourcing and offshoring of most of their computing needs, they won't care one second to filter such candidates.

[jongjong]

I agree with this for complex problems which cannot be vibe coded with AI. So definitely it's an essential skill for any human engineer.

[MomsAVoxell]

“You can read the code”

.. 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 ..

[gpderetta]

great coders ship.

[nixon_why69]

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.

[hnlmorg]

You’re ostensibly arguing the same thing I am though. Focusing on building the thing rather than designing the code to look pretty.

[nixon_why69]

I haven't read the codebases in question but people were talking about spaghetti code, which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively.

I guess I'm saying there are code quality concerns which do affect velocity/maintainability and then there are superficial and stylistic issues. The former aren't just about some kind of beauty standard, they're part of executing.

[bitwize]

It's not about "looking pretty". Beautiful code is easy to read, comprehend, and change; it's not simply nice formatting.

[lproven]

I don't think "ostensibly" means what you think it means.

But I can't guess what you meant.

[TremendousJudge]

>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.

I have tried to do this for POCs (just hacking everything together), and I always get stuck very quickly. Then until I figure out some sort of architecture for what I'm supposed to be doing I can't proceed. It's like, once I have the first step (of several) of the a POC working, I literally cannot think of how to implement the second one until the first one is somewhat well organized

[psychoslave]

> 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.

[bitwize]

If your code is a low-stakes one-and-done and it works in the end, messy code is forgivable. Undertale looks like Yandere Simulator inside; nobody cares.

But if your code is something that needs to be maintained over time and/or has constraints in terms of security, availability, etc., like virtually all code is, then yes: clearer, better factored, more readable code is a big part of the product because it's a massive favor both to yourself and your successors when changes have to be made and results in quicker changes, lowered costs for changes, and higher quality on metrics like security. Even if I'm writing a game—I'm auDHD, so if the initial code is garbage (and I've written a lot of garbage code) I'd be loath to touch it later. Better factored code is easier for me to revisit and improve upon with time. So I make it a point to continuously improve how I structure code from the jump to stave off it turning into an unpleasant quagmire later. This is especially important when you consider that oftentimes in business, the first draft that could possibly work goes right into production. Rewrite? What do you mean, rewrite?

Fabrice is still fucking brill though. He'll slap something together that's a holy shit idea as easily as I take a dump.

[xyzzy123]

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?

[coldtea]

>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...

[sph]

> 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.

[yaantc]

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.

[sph]

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.

https://en.wikipedia.org/wiki/Radar_chart

[lambdaone]

Carmack and Bellard are both wizards, and trying to rank them is a fool's errand. Let's appreciate them both!

[sp0rk]

> 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.

This seems like a strangely harsh response considering the person you're responding to is just restating the assertion that Carmack made in his tweet.

[anthk]

Carmack it's a better engineer, but Bellard it's a better thinker and innovator. To each its own.

[groceries8192]

> The code isn’t beautiful and elegant

Beauty is in the eye of the beholder. What you find beautiful, I would find grotesque, and vice versa. What you think of as well-organized, I think of as spaghetti.

I think it's great that we can have such a diversity of viewpoints on beauty, but I wouldn't advise making universal proclamations on beauty standards.

[vkazanov]

True. Carmack was polishing idtech for a decade, and his work is always pleasant to tinker with.

Now, what is outstanding in Fabrice's work is that his curiousity projects often end up being breakthroughs.

I mean, i have like hundreds of these. Can emacs do that? I make a compiler to do that? How fast can i make this bytrcode to run?

And it is cute at best.

[SwellJoe]

"It’s not beautiful but that’s OK."

Really? I find his code elegant and concise.

[moralestapia]

Oof, HN says the darndest things.

OTOH it's fun to see people comparing programmers (better/worse) as if that actually mattered.

As the internet says, post physique bro.

[pwdisswordfishq]

Obsessed with poop?

[gaigalas]

Honestly, two mythologized figures (Carmack and Bellard).

They're good (like, quite good), but as soon as their names come up people start talking about some weird expectation of what they are supposed to think rather than the actual things they did.

Somehow, that mythologizing diminishes their accomplishments.

[noisy_boy]

Telling stories, looking for gods that don't have our limitations and telling stories about those gods is pretty much in our nature irrespective of the era.

[gaigalas]

There's no such thing as "human nature", that's just a way to justify something that can't be easily explained.

I have nothing against it. The fact that I explained a mechanism (mythologizing diminishes one's real work) offends people who like to do it, but that's outside of my control. It's not meant to offend or deny their right to do it. It is just what it is and I'm naming it. I understand it's uncomfortable, and pulling the "everyone does it" card makes things easier.

I love mythology by the way, stories, etc. Fascinating stuff.

[noisy_boy]

I don't even know what are you arguing against.

> I love mythology by the way, stories, etc. Fascinating stuff.

Most people do. Given that it is quite prevalent across cultures and given that we are a product of our genetics and upbringing, one might even say, in our nature.

[gaigalas]

I think it's the wrong lens for observing this conversation. You're looking for something that I might be attacking. I'm not doing what you think I am, that's why you can't pinpoint it.

It's a simple observation: mythologizing might diminish one's work.

Even if we assume there's some "human nature", that claim stands unchallenged.

"But you can't fight this thing that all humans do" is your line, and it was never my point to fight it. I want to explain what it does, not change it (which is outside of my control).

[wang_li]

I am of an age with Carmack and wanted to be a game developer when i was young. I very much elevated him very high. In terms of computer graphics he is very informed and talented. But I have watched him do interviews that largely focused on other areas and I find him to be pretty average or even below average. His thoughts on BJJ and AI are quite immature and don't express any special insight.

[caspper69]

There’s a reason people say don’t meet your heroes.

No matter how elevated they are in your mind, they’re still just people. One pants leg at a time and all.

[noufalibrahim]

Not exactly my idea. However, it's pleasant to see two people I admire so much having respect for each other.

[MomsAVoxell]

Oh, this is human nature and you will find it impossible to avoid this framing of cult figures, because they are indeed cult figures - albeit positively perceived ones, since they appear to not just be doing it for themselves, but altruistically every wonder they produce is for their users - and thus their works have effectively and productively impacted the lives of millions of other people, at economies of scale most of us here on HN aspire to.

And it is that aspiration you’re degrading with the rush to de-mythologize, as if it weren’t inevitable, under the crushing rush of time, that we in the hacker world had heroes.

[gaigalas]

Humanity has some 300.000 years of existing, and we can only trace back the prevalence of cult figures a few thousand years back.

For all we know, it could be a temporary fluke and we'll snap back to something else. We could be beings with no default to snap back to, ever changing, destined to dissolve the prevalence of cult figures into something else in the following eras.

In a few thousand years we could totally see this practice as some distant-past thing like making clay pots or carrying Roman dodecahedrons.

The new cultural trend could become jumping off cliffs, and someone would be arguing that it's inevitable human nature.

By the way, no rush to de-mythologize. I'm not fighting any dragon here, you do you.

[MomsAVoxell]

> a few thousand years back

I beg to differ, but okay. I don’t disagree to your allusions that there is a banality to mob idolatry, but that’s a discussion for other forums, ironically.

[gaigalas]

Idolatry is not the same as mythologizing. And I never said there is a banality to it, just that there could be. We don't have enough to know.

[MomsAVoxell]

In any case, you do seem to have overlooked that there are successful mythologies in the contemporary era - that indeed Fabrice and co., are worth understanding better not just for the nature of their work, but also the means by which their reputation preceded them - and lets not forget that the markets in which they operate are worth multi-millions of dollars worth of economy and they are clearly successful at scale.

[nixon_why69]

We only have writing and, consequently, people who's names we know a few thousand years back.

A cult figure before writing would have more limited reach, and be forgotten because their name wasn't written down. But they'd still have been a cult figure.

[zerohp]

The Buddha lived before writing in India. We have plenty of other stories that were passed by oral tradition before they were written down.

[gaigalas]

The oral tradition you're probably trying to refer to is the Rigveda, which is amazing. It's like a human recorder that kept a series of vocalizations intact for thousands of years through chanting, with error correction mechanisms and all sorts of tricks to reduce drift over time.

That's our oldest attested oral tradition, 2000 years or so. Stretching to a maximum of 6000 years if we're generous.

Buddhism is like, a thousand years after that.

It's all still super young though. Like I said, humanity has 300.000 years.

Earliest petroglyphs from 50.000 years ago corroborate my point of view: they depict animals, and migrations and shit. Nothing that can attest some kind of cult towards individuals, no heroes, no holy images.

So, yeah, talking about the Buddha "seems like old stuff", but it really isn't in the timescales that matter for estabilishing what "human nature" is, we've been human way before all that jazz appeared.

[gaigalas]

It's an interesting hypothesis we can never prove. We don't even know how old names are.

[jongjong]

Yeah. They've had their time.

[Zardoz84]

Sad that him can't show the same respect for "Burguer" Rebecca Ann Heineman.

[Quarrel]

err?

afaik Bellard never had any beef with Burger Becky. Both are legendary programmers, but somewhat different eras.

I have no idea what you're suggesting.

[TheAmazingRace]

I think he was referring to Carmack's note on Burger Becky when she passed away.

[Quarrel]

Ah, thanks, yeah, I just looked it up.

I had no idea.

[shevy-java]

I imagined him with wild, long hair; possibly tattoos, huge and heavy set. The picture destroyed my imagination - and now I want my imagination back. :(

[throwaway2037]

In my personal experience, uber French nerds don't really fit the Simpsons "Comic Book Guy" appearance stereotype. Anyone else reading this, feel free to disagree.

[speedgoose]

Yes, it’s difficult to practice climbing if you are obese.

[taway20260616]

If you want your "imagination" back, go back to watching Netflix and Hollywood cliches.

[sph]

Except the ‘huge and heavy set’, you’re thinking of tokyospliff here.

[huhtenberg]

Or some version of RMS :)