Programmers: you have to watch your weight, too
- Reference: 1756550468
- News link: https://www.theregister.co.uk/2025/08/30/programmers_watch_your_weight/
- Source link:
There are trends in software, and in software development, that everyone deplores… but for many people, it is terribly bad manners to point fingers at the projects doing it. We find it refreshing to encounter writers who are willing to poke their heads above the battlements and do just that. Here are some we noticed recently.
Ukrainian developer Kyrylo Silin asks a hard question: [1]Why do software developers love complexity? . He proceeds to call out some of the causes. Marketing trumps simplicity; programming is a creative act, and it's satisfying to craft complex solutions to problems. He notes the well-known issues of legacy systems, technical debt, team and collaboration dynamics, and the competitive pressure to innovate. He compares software to building the pyramids:
When you look at a Pyramid, only a moment later you notice your mouth is open wide in awe (close it now). Simplicity, on the other hand, doesn't hold any secrets inside. It's invisible until you realize it's genius.
Complexity shouts, "Look at me!", while simplicity whispers "Did you notice?".
One thing for sure, though, simplicity often wins in the long run. After the initial amazement is gone, it's the function that quietly does the job that most people need.
We thought it was interesting than he levels an accusatory finger at React in particular, rather than at other monster frameworks such as Node.js or Angular, or even Javascript as a whole. The link to [2]justfuckingusehtml.com gave us a grin, though.
First Grug teach code. Now Grug teach design.
One of our favorite calls for simplicity is Grug. Phrased in jokey caveman-style language, The Grug Brained Developer explains itself: A layman's guide to thinking like the self-aware smol brained. Even the URL is simple: [3]grugbrain.dev . Its source code is on [4]on Github under this eloquent license:
Grug 1-Clause License
do what want
That's it. As a result, others have adapted Grug, for instance [5]The Grug Brained Data Scientist and [6]Grug's Guide to Sound . It seems that the fake-primitive style is too much for some people; for instance, we found this [7]"English translation" .
Grug was written by Carson Gross of [8]Big Sky Software , who created intercooler.js and its successor HTMX . This vulture grug brain too smol to know which end pick these up. Him like [9]HTMX essay memes though.
[10]
Grug originally spoke up in 2022. A week ago, a new Grug appeared: [11]Grug.design . The website itself, though, is far from as simple as it could be, and looking at the source code, the phrase "Just fucking use HTML" did spring immediately to mind. We suspect this Grug is not the real Grug.
Back to 1980? No. Try 1974.
What Grug is trying to get at is, we feel, a more emphatic restatement of [12]Kernighan's Law :
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Brian Kernighan is the person who coined the name "UNIX" and invented the "Hello, world" programming language demonstration. We have expressed our admiration before, when he came out of retirement in 2022 to [13]add Unicode support to AWK . He stated his eponymous law in the 1974 book [14]The Elements of Programming Style [PDF]. If he has to make allowance for not being as clever as he thinks, the rest of us very definitely need to listen.
Small targets may be as valid as big ones
A 2016 article, originally titled "Xz format inadequate for long-term archiving" but now the more general " [15]Xz format inadequate for general use ", has recently resurfaced in several places, including [16]Hacker News .
It makes many specific cases against the code of the XZ compression tool that Linux uses in many places. If the world had paid more attention, then a great deal of inconvenience could have been averted. Last year, a [17]backdoor in xz caused issues in many distros , including a delay to the [18]Ubuntu 24.04 beta program and [19]wider concern in FOSS circles .
[20]
[21]
The criticisms in the article are detailed and mostly highly technical, but the points are more general. The author, Antonio Diaz Diaz, illustrates this with multiple quotes from [22]Professor Tony Hoare , an outstanding British computer science academic and the inventor of the Quicksort algorithm. In 1980, Hoare [23]won the Turing Award . His Turing Aware lecture is entitled The Emperor's Old Clothes. Diaz offers a very readable [24]plain text version , but Fermat's Library has an [25]annotated version that may be helpful. It's readable and funny, as is his earlier [26]Software Design: A Parable from 1975.
If you haven't got the time for The Emperor's Old Clothes right now, but want a taste, just read the quotations in the XZ paper.
Retro tech has lessons to teach
A few days ago, The Register asked [27]why we're falling back in love with retro tech . Well, one reason is that the older systems are simpler, and that makes them far easier to understand. We're nostalgic for 16-bit computers, or even eight-bit ones, because 32-bit ones quickly got too complicated to grok.
One could make a strong case that the last two really big advancements in software were Linux, which in 1991 freed Unix from the shackles of multiple proprietary implementations, and then in 1993, Windows NT, which removed most of the restrictions that crippled PC-compatible computers. Both were enabled by the advent of cheap, mass-market 32-bit x86 computers, mostly thanks to Intel's 80386SX chip in 1988.
[28]
Thirty-two-bit computers gave programmers a lot of room to experiment: the best part of four gigabytes of RAM. In 1999, the infant Register [29]reported on AMD's new 64-bit x86 architecture , and in 2001 that [30]it wouldn't ship until 2003 .
In other words, a decade after NT, the few remaining restrictions were lifted. Code could grow as big as developers wanted. Now, [31]we are drowning in it . For a third of a century, ever-growing computer capacity has meant [32]Worse is Better has held true. Nothing lasts forever, and things are changing. [33]Dennard scaling is running out . More cores don't make computers faster: [34]Amdahl's Law proved that in 1967. Adding more programmers to a project doesn't make writing software faster: Fred Brooks's [35]The Mythical Man-Month [PDF] spelled that out in 1975.
Our global society runs on consumption and waste, and that applies equally to software. That can't last forever, either. If Russia gets away with invading Ukraine, then the People's Republic of China could be emboldened to invade the Republic of China – or Taiwan as the rest of the world calls it, since only [36]12 countries recognize it as a state. That's a problem, since some [37]90 per cent of the most advanced chips are made there. (In case you doubt a Taiwanese source, [38]The Economist agrees .)
[39]
Meanwhile, climate change will really start to get serious soon. As [40]the latest research indicates , the Gulf Stream will probably stop in by 2035 to 2040:
our finding that deep convection in many models stops in the next decade or two, and that this is a tipping point which pushes the northern AMOC into a terminal decline from which it will take centuries to recover, if at all.
In case the paper is a little impenetrable, [41]the Guardian has an explainer .
High-tech chips and software will be the least of our worries, but we will have to deal with [42]artisanal software that can be maintained by hand. ®
Get our [43]Tech Resources
[1] https://kyrylo.org/software/2025/08/21/why-do-software-developers-love-complexity.html
[2] https://justfuckingusehtml.com/
[3] https://grugbrain.dev/
[4] https://github.com/bigskysoftware/grugbrain.dev
[5] https://simmering.dev/blog/data-grug/
[6] https://petrustheron.com/posts/2024-12-12-grug-guide-to-sound.html
[7] https://reidjs.github.io/grug-dev-translation/
[8] https://bigsky.software/
[9] https://htmx.org/essays/#memes
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aLMgEku3TLTJ2bCdtmEUkQAAAFA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[11] https://www.grug.design/know
[12] https://www.laws-of-software.com/laws/kernighan/
[13] https://www.theregister.com/2022/08/23/universal_unix_tool_awk_gets/
[14] https://docenti.ing.unipi.it/~a009435/issw/extra/kp_elems_of_pgmng_sty.pdf
[15] https://www.nongnu.org/lzip/xz_inadequate.html
[16] https://news.ycombinator.com/item?id=45022172
[17] https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
[18] https://www.theregister.com/2024/04/15/ubuntu_24_04_belated_beta/
[19] https://www.theregister.com/2024/04/16/xz_style_attacks_continue/
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLMgEku3TLTJ2bCdtmEUkQAAAFA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[21] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aLMgEku3TLTJ2bCdtmEUkQAAAFA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[22] https://www.cs.ox.ac.uk/people/tony.hoare/
[23] https://amturing.acm.org/award_winners/hoare_4622167.cfm
[24] https://www.nongnu.org/lzip/the_emperors_old_clothes.txt
[25] https://fermatslibrary.com/s/the-emperors-old-clothes
[26] https://people.dsv.su.se/~jpalme/s1/hoare.html
[27] https://www.theregister.com/2025/08/25/straight_outta_1996_why_were/
[28] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLMgEku3TLTJ2bCdtmEUkQAAAFA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[29] https://www.theregister.com/1999/12/15/amd_uses_nut_to_crack/
[30] https://www.theregister.com/2001/11/09/amd_delays_sledgehammer_to_q1/
[31] https://www.theregister.com/2024/02/12/drowning_in_code/
[32] https://www.dreamsongs.com/RiseOfWorseIsBetter.html
[33] https://www.theregister.com/2011/11/28/future_computing/
[34] https://en.wikipedia.org/wiki/Amdahl%27s_law
[35] https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf
[36] https://en.mofa.gov.tw/AlliesIndex.aspx?n=1294&sms=1007
[37] https://globaltaiwan.org/2025/03/taiwans-shortage-of-chipmakers-a-major-threat-to-the-industrys-long-term-growth/
[38] https://www.economist.com/special-report/2023/03/06/taiwans-dominance-of-the-chip-industry-makes-it-more-important
[39] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aLMgEku3TLTJ2bCdtmEUkQAAAFA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[40] https://iopscience.iop.org/article/10.1088/1748-9326/adfa3b
[41] https://www.theguardian.com/environment/2025/aug/28/collapse-critical-atlantic-current-amoc-no-longer-low-likelihood-study
[42] https://www.theregister.com/2024/09/18/the_future_of_software_part_2/
[43] https://whitepapers.theregister.com/
Re: Newer is not faster or simply slower
That is a very nice writeup.
It's interesting that the Lenovo chromebook seems to break away from the pack.
That's what you get for putting so much lipstick on a pig...
You can barely see the pig anymore...
All this shall pass
Quite difficult to make a brief comment on such a wide-ranging summary of IT history concluding in a reminder of our imminent demise, but just some random thoughts.
Firstly that code complexity is largely unrelated to the size of the memory available. I recall writing some extremely complex (and error-prone) overlay trees so that network management code (whose complexity was dictated by the full range of disparate communications devices and protocols supported by RSX-11) could be shoe-horned into the 8KB address window that was available to tasks that also mapped the kernel on the 16-bit system. It's also unrelated to the number of address bits - the VAX had a 32-bit address space but originally shipped with 1MB of memory. The VAX had variable-length instructions, multiple-operating mode and few alignment rules which meant you could get page faults fetching the instruction, fetching or storing operands (which might straddle pages) and - in the case where those operands were indirect addresses - in accessing the ultimate target: incredible complexity. But it was complexity in the system that removed complexity from the user who could simply write code without worrying about a list of arcane restrictions - and ensured every available byte of the limited and expensive memory was usable. The complexity arising from technical constraints can be dictated by economics as well as by architecture.
Sometimes we simply import complexity from our untidy existence. I was looking for some text-layout code and fell down the rabbit-hole of exploring the rendering of scripts in a wide range of languages: it's unbelievably messy and there's no practical way it can be made less complicated. It's also an area in which very few people are truly expert - so we have to accept not only the complexity but our inability to pass informed comment on it. Arguably, web browsers are so fiendishly big and complicated for the same fundamental reason - it's not just that they've taken on the burden of language-independence, but their pixel-perfect multimedia presentations are largely dictated by the way we humans can be persuaded to part with our money rather than by any technical necessity.
One of the odder consequences of the Open Source revolution is that we have access to more of the code we actually run than has been the case since IBM was obliged to start unbundling its software - but actually scrutinise less of it. Huge frameworks and libraries may be imported without our being aware of which parts are being used or even how they operate - or whether they are what they claim to be. We might be better off writing our own code for the small subset of functions we need, but we excuse ourselves the need to write, test and maintain that code on the basis that someone unknown claims to have tested their own contribution and might possibly maintain it at no cost to us. This seems to have happened almost overnight and without question and without the tools to even begin to manage the potentially catastrophic consequences.
Rather like the collapse of the Gulf Stream, we will claim it's simply inevitable and, by doing nothing, fulfill the prophecy.
Binary advice
Use more "ones", they weigh less than "zeroes" especially when printed.
Binary advice ... part 2
You are forgetting that the hole in the middle of the 'Zeroes' reduces the wind resistance, so they move faster !!!
P.S. I mean the '0' and not the slashed zero (Alt-216) Ø.
:)
Re: Binary advice ... part 2
in that case maybe we should just have 'O' and half 'O' i.e. 'u' without the tail
I know I am a dying breed
But I still code in C, and learned in the 70's in Brian's era. Good practices last a lifetime. Readable, clear, concise, well commented code.
Newer is not faster or simply slower
An overview of [1]input latency from 1977-2017 .
It is an interesting story of having smaller, faster and more capable/evolved computers over time while they are either slower from the user's perspective or not proportionally faster than the headroom provided by the technological evolution.
Talking about crud for software...
[1] https://danluu.com/input-lag/