In 1969 we had Lisp, and the PDP-10. Interactive computing was very doable even then. I'm sure Stallman would have love for ITS on the 10 to have remained the default.
That's the value add. Any dipshit can be trained in the Windows server stack, so you can staff your back office with dipshits. For a while in the early 2000s—before the cloud era—Windows was routinely found to have a lower TCO than Linux as a server OS for precisely this reason. More actual deployments too, especially in corporate intranets.
"Guys, guys, guys, listen, listen, listen. So I'm in this computer, right? So I'm lookin' around, lookin' around, throwing commands at it, I don't know where it is or what it does or anything..."
I think it's from hackers, Joey the youngest hacker found the bad guys computers, not sure if it's an accurate quote since it's been years since I saw it.
I... downloaded a 4-bit quantized GGUF of the model, used llama.cpp to run it, and pointed OpenCode at that. My machine is an 8-core Gen1 Ryzen 7, 32 GiB of DDR4, (I think) 4 GiB of VRAM on the graphics.
Science fiction authors have had to grapple with the fact that it's nearly impossible to build a robot out of metal, plastic, or composite material that has the physical performance characteristics (strength, durability) of a human body and weighs just as much. You can build a strong robot but it'll be heavy. The better SF authors, if they've need of robots of mere human weight, will make them comically fragile.
The same is even more true of our intelligence. We're building computers with the size and power consumption characteristics of entire cities to do things that may almost, but not quite, match what our brains do with a kilogram and a half of mass and about 20 watts at the top end of power consumption.
The only way we are ever going to match that with technology is to run AI workloads on human brain tissue, which Rick-and-Morty level horror is being actively worked on as I understand it. The original concept for The Matrix wherein the machines used humans to run compute workloads on their brains actually kind of makes sense.
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.
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.
Have you ever done research mathematics? To me, the only difference between code and math is that the code can do things, make stuff happens in the world; outside of that, mathematics has a lot more opportunities to be beautiful (not to say that there isn't beautiful code, but the beauty is not central in the way it often is in mathematics).
Yeah, a lot of businesses definitely do push things too far the other way and advocate releasing _anything_ regardless of how well it works.
I'm strongly against the "move fast and break things" mentality. But there is a happy middle ground between architecting works of art, and shipping urinals with faulty plumbing.
Although in this case it's more like using the paint in the tin to paint the tin itself. It's useless and completely missing the point of why the paint exists in the first place.
You do you, I'm sorry if I come across rude and stupid, but I am both things. But "code is the product" is what IMO caused the downfall of this entire profession. No wonder everyone is trying to get rid of us. I wouldn't want a plumber that's obsessed with the tubes itself and not whether my house has working plumbing in a reasonable time frame and within budget.
Despite the gallons of ink spilled on the subject I have not worked at a single place in my 30-year career where developers sat around perfecting masterpieces.
I have worked at a never-ending list of places where people shipped the first thing that worked, built spaghetti around it, something else got built on top, and the original thing is now critical infrastructure that takes 10x longer to fix bugs or add needed features to than it would have if we’d taken 1.5x longer to ship it in the first place. I have worked at a never-ending list of places where developers beg for time to be set aside to deal with the worst parts that sap their time, energy, or will to continue working at the job. I have worked at a never-ending list of places that eventually sets aside a few days to tackle these tasks, when the engineers estimate two or three weeks. I have worked at a never-ending list of places that then uses the failure of these momentary diversions as evidence that their engineers don’t know what they’re talking about and should shut up and ship more features.
I sure wish I knew what masterpiece factories you must have spent your career working at.
I feel like the navel-gazing-ivory-tower programmer is almost a straw man used by commenters and bloggers to make themselves sound pragmatic. Summoned only be be torn down. Never to be found on an existing software team.
I have come across the architecture astronaut before. But I feel like they’re the result of the culture of the ecosystem the language. The Java and C# programmers whose language requires you to juggle weak types with visibility keywords and null ability. They can be forgiven for not being able to implement a priority queue without a committee and a class hierarchy deeper than the Mariana Trench.
But the perfectionist that never ships anything useful and only ever tweaks interfaces and types? Never met one.
Most people are just trying to balance progress with practical concerns.
That maybe true, but the reason we are having this conversation was because people made those kind of comments. Which lead me to defend Bellard’s POCs.
I’ve been in this profession for two decades as well. As both things.
My take on this is that we need both, because the market is cyclical. It’s just that it’s hard to perceive any of those cycles if you (a) live them (b) are not experienced enough to introspect.
I absolutely would love an obsessed plumber (and got one!) when it comes to deciding that we’re going to do PTFE tubing in our new house. An obsessed electrician in charge to overinvest into our grid, rather than a 3-month timeframe executive. Otherwise our critical infrastructure gets myopically degraded.
I also want the “working within timeframe” outcome.
And we, as an industry, swing wildly in both direction. The Cambrian explosion of shareware was the the former. We course-corrected into cathedrals of good software (I still love Windows 2000’s stability, the pinnacle of NT line), followed by the “reasonable timeframe” 4GB Electron apps, etc.
It will swing. Every complex system from logistic equation upwards will oscillate .
> 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.
I don't think you're being very charitable in your reading of my comments. For example:
> 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.
Who's these "people" you're referring to? This is an imaginary conversation you've added.
What I actually said was that there's a balance between design and output.
I did generalize that often product people will push too far towards output and often developers will push too far between design, but like all generalizations, I know there are exceptions (eg me).
But the crux of my point is that there are tradeoffs between the two, and thus times when it makes more sense to lean towards output and times when it makes more sense to focus on design.
What you've replied with isn't even remotely the same sentiment as the comment I made.
> 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.
No. Code quality is just a subjective term that means nothing in reality because everyone will have different goals in mind when they think about the purpose of the code.
So the underlying heuristics require far insight into project goals, deadlines, and resources than just "code quality".
> Instead of accepting that other, possibly dumber people get to define what code quality is,
The original reason I replied (albeit I did digress quite a bit) was to demonstrate that you cannot extrapolate how smart or dumb an engineer is from their "code quality" alone. So please refrain from calling people dumb in your rebuttals.
> own your own definition of it and use it when you communicate with other people.
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.
Im talking about the speed of mental model building, understanding concepts, relations and organizational concepts.
Good codebases sort of read themselves. You can guess where things are, how they are sorted and how they work, by understanding and relying on the authors ideas.
“Good” code makes trade offs. While readability is an important constraint, it’s far from being the only constraint. And there are plenty of occasions where objectively better code is subjectively harder to read because other constraints trump human parserability, such as using CPU-friendly memory layouts, SIMD-instructions in tight mathematical loops, and so on and so forth.
Not to mention that readability is entirely dependent on the readers familiarity with particular coding styles. Eg someone unfamiliar with SQL would find ORMs easier to read, whereas I find SQL easier than ORMs. Same is true for any other paradigm, eg for functional vs imperative.
And this is why I hate when people generalise about human readability being the definition of “good code”. For one thing, there will never be a consensus on what is more readable. And external constraints might require subjectively less readable code.
> 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.
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.
.. 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 ..
>"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
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 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.
The comments about Ballard's code is very subjective. But if we take their comments at face value:
> which would not be well-factored and would impede someone less talented from comprehending it or being able to change it effectively.
Except the community did comprehend it and changed it effectively. Ballard hasn't maintained ffmpeg nor qemu for 20+ years.
> 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.
Which is why I'm saying we're basically arguing the same things. For a POC you get more velocity when focusing on proving that idea. I'm not saying zero effort should be spent on architecting the code. Just that you don't always know how best to organize it until you've had several revisions so developers shouldn't get too caught up trying to intellectualize the best internal layout. That can grow once the problem is better understood.
And I made this point because I felt the comparisons of one engineers POC to another engineers commercial release was unfair. They're completely different ends of the factory.
>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
> 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.
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.
It was always like that before about 10 years ago. You're getting your feet wet in programming, learning about free alternatives, and you learn that all the world's legendary hackers become proficient in one of either vi (vim) or Emacs. So you dig in and you find that, as your awareness of programming languages grows, Emacs is a "good-enough" solution for working in nearly all of them. (Vim is too, but maybe a bit less so in 1995 when I was starting out.) And if you want to program effectively cross-language, there's nothing you can do but lock the fuck in and learn your editor's idiosyncrasies, shortcuts, and programming/customization features.
These days we're all spoiled by Visual Studio Code, Zed, even things like Geany and Notepad++. So it makes less sense for neophytes to start with something as ancient and idiosyncratic as Emacs, and Emacs does not enjoy nearly the prominence or mindshare it had decades ago. (Though I understand its absolute user base has grown.)
I used vim for about 15 years and emacs for the last 6 or 7 and never has it been easier to emacs. For years it was searching Google, blog posts and manuals for "how do I do X in emacs?" and now it's trivial to ask AI. I always have a Copilot session open in my emacs config so it can tell me how my emacs does something and can update my config for me.
It affects everybody. I've heard of people arrested in rather more oppressive regimes expecting to be Miranda'd because it's what they know from American cop shows and they thought it was broadly applicable everywhere.
reply