[HN Gopher] Wirth's Revenge
___________________________________________________________________
Wirth's Revenge
Author : signa11
Score : 175 points
Date : 2026-02-05 03:38 UTC (19 hours ago)
(HTM) web link (jmoiron.net)
(TXT) w3m dump (jmoiron.net)
| satvikpendem wrote:
| While the author says that much of it can be attributed to the
| layers of software in between to make it more accessible to
| people, in my experience most cases _are_ about people being lazy
| in their developing of applications.
|
| For example, there was a case of how Claude Code uses React to
| figure out what to render in the terminal and that in itself
| causes latency and its devs lament how they have "only" 16.7 ms
| to achieve 60 FPS. On a terminal. That can do way more than that
| since its inception. Primeagen shows an example [0] of how even
| the most terminal change filled applications run much faster such
| that there is no need to diff anything, just display the new
| change!
|
| [0] https://youtu.be/LvW1HTSLPEk
| elliotec wrote:
| Yeah, I think a lot of this can be attributed to institutional
| and infrastructural inertia, abstraction debt, second+-order
| ignorance, and narrowing of specialty. People now building
| these things are probably good enough at React etc. to do stuff
| that needs to be done with it almost anywhere, but their focus
| needs to be ML.
|
| The people that could make terminal stuff super fast at low
| level are retired on an island, dead, or don't have the other
| specialties required by companies like this, and users don't
| care as much about 16.7ms on a terminal when the thing is
| building their app 10x faster so the trade off is obvious.
| mountain_peak wrote:
| Interestingly (or possibly not), since my very first
| computers had ~4K of RAM, I became adept at optimizations of
| all kinds, which came in handy for my first job - coding 360
| mainframe assembly. There, we wouldn't be able to implement
| our changes if our terminal applications (accessing DB2/IMS)
| responded in anything greater than 1s. Then, the entire
| system was replaced with a cloud solution where ~30s of delay
| was acceptable.
|
| I think the Internet made 'waiting' for a response completely
| normalized for many applications. Before then, users flew
| through screens using muscle memory. Now, when I see how much
| mouse clicking goes on at service counters, I always think
| back to those ultra-fast response time standards. I still see
| a few AS/400 or mainframe terminal windows running 'in the
| wild' and wonder what new employees think about those
| systems.
| projektfu wrote:
| It's getting ridiculous. I know SPAs aren't to blame
| specifically, but it feels like whenever the 2003 page-
| based web interface is replaced with the modern SPA each
| action takes forever to load or process. Was just noticing
| this on FedEx's site today.
| Cthulhu_ wrote:
| It makes me wish more graphics programmers would jump over to
| application development - 16.7ms is a huge amount of time for
| them, and 60 frames per second is such a low target. 144 or
| bust.
| jacquesm wrote:
| And embedded too. But then again, they do what they do
| precisely because in that environment those skills are
| appreciated, and elsewhere they are not.
| moring wrote:
| I don't think graphics devs changing over would change much.
| They would probably not lament over 16ms, but they would
| quickly learn that performance does not matter much in
| application development, and start building their own
| abstraction layer cake.
|
| It's not even that performance is unimportant in absolute
| terms, but rather that the general state of software is so
| abysmal that performance is the least of your problems as a
| user, so you're not going to get excited over it.
| pjmlp wrote:
| No need for graphics programmers, anyone that is still around
| coding since the old days, does remember on how to make use
| of data structures, algorithms, and how to do much with
| little hardware resources.
|
| Maybe the RAM prices will help bringing those skills back.
| socalgal2 wrote:
| Those practices make things hard to modify and update. As
| one example, I use to use binary formats for game data. The
| data is loaded into memory and it's ready to use, at most a
| few offsets need to be changed to pointers, in place.
|
| Good: (*) no extra memory needed (*) can read directly from
| CD/DVD/HD to memory - not through buffered i/o (*) no
| parsing time
|
| Bad: (*) change or add a single field in to any part of the
| saved data and all previous files are now invalid.
|
| I'd solve this with a version number and basically print a
| message "old version in file, rebuild your data"
|
| Modern apps use JSON/Protobufs, etc. They are way slower to
| load, take way more memory as there are usually 2 versions
| of the data, the data in the file and the parsed data your
| app is actually using. They take time to parse.
|
| But, they continue to work even with changes and they can
| more trivially be used across languages and apps.
|
| That's just one example of 100s of others where the
| abstraction is slower and uses more memory but provides
| flexibility the old ones didn't.
| pjmlp wrote:
| No need for such extremes, it would already be enough to
| stop using Electron crap, or React on the terminal.
|
| Followed by actually reading a data structures and
| algorithms book.
|
| Finally, using compiled languages instead of interpreted
| ones.
|
| No need to count bytes to fit into 48 KB.
| socalgal2 wrote:
| I disagree. I use all of those because they let me get
| work done faster. I've shipped Electron apps to clients
| that are effectively just a wrapper around a command line
| app because (1) I knew the client would much prefer a GUI
| over a command line (2) I was on Mac and they were on
| Windows and I knew I could more trivially get a cross
| platform app (3) I could make the app look good more
| trivially with HTML/CSS than I could with native (4)
| Iteration time is instant (change something /refresh).
| The clients don't care. Interpreted languages are fine.
| pjmlp wrote:
| And that is how we get the mess we are in today.
| bccdee wrote:
| Exactly. It turns out there are strong business
| incentives that favour tall towers of abstractions. Then
| _everyone 's_ using Electron, so it doesn't really matter
| if it's slow. People just come to perceive computers as
| slow. I hate it.
| bluGill wrote:
| That wouldn't make any difference. Graphics programmers spend
| a lot of effort on performance because spending a lot of $$$$
| (time) can make an improvement that people care about. For
| most applications nobody cares enough about speed to pay the
| $$$ needed to make it fast.
|
| Many application programmers could make things faster - but
| their boss says good enough, ship it, move to a new feature
| that is worth far more to me.
| ferguess_k wrote:
| It's mostly on the business side. If business doesn't care
| then developers have no choice. Ofc the customers need to
| care too, looks like we don't care either...in general.
| GuB-42 wrote:
| One tradeoff is that one of the tradeoffs graphics
| programmers do is about security. They typically work with
| raw pointers, using custom memory allocation strategies,
| memory safety comes after performance. There is not much in
| terms of sandboxing, bounds checking, etc... these things are
| costly in terms of performance, so they don't do it if they
| don't have to.
|
| That's because performance is critical to games (where the
| graphics programmers usually are), and if the game crashes,
| no big deal as long as it doesn't happen so often as to
| seriously impact normal gameplay experience. Exploits are to
| be expected and sometimes kept deliberately if it leads to
| interesting gameplay, it is a staple of speedruns. Infinite
| money is fun in a game, but not in serious banking
| software...
|
| I am all for performance, and I think the current situation
| is a shame, but there are tradeoffs, we need people who care
| about both performance and security, maybe embedded software
| developers who work on critical systems, but expect a 10x
| increase in costs.
| tasty_freeze wrote:
| This sounds like how curses did things, a 1980 technology.
|
| On the other hand, if the guy in the video ran his app over a
| remote connection with limited bandwidth, diffing would
| probably perform better. I have a one Gbps google fiber
| connection to my job but at times my vpn bandwidth can choke
| down to a couple hundred kbps and sometimes worse.
| nickm12 wrote:
| I'm not sure what the high-level point of the article is, but I
| agree with the observation that we (programmers) should generally
| prefer using AI agents to write correct, efficient programs to do
| what we want, to have agents do that work.
|
| Not that everything we want an agent to do is easy to express as
| a program, but we do know what computers are classically good at.
| If you had to bet on a correct outcome, would you rather an AI
| model sort 5000 numbers "in its head" or write a program to do
| the sort and execute that program?
|
| I'd think this is obvious, but I see people professionally
| inserting AI models in very weird places these days, just to say
| they are a GenAI adopter.
| jokoon wrote:
| Hardware is cheaper than programmers
|
| Maybe one day that will change
| srean wrote:
| Thanks to AI driven scarcity of hardware it's already coming
| true.
| tgv wrote:
| Idk. What are these programmers doing afterwards? Build more
| shoddy code? Perhaps it's a better idea to focus on what's
| necessary and not run from feature to feature at top speed.
| This might require some rethinking in the finance department,
| though.
| pixl97 wrote:
| If writing thin code doesn't pay the bills then programmers
| will write thick code to eat tomorrow.
| xnorswap wrote:
| An interesting article and it was refreshing to read something
| that had absolutely no hallmarks of LLM retouching or writing.
|
| It contains a helpful insight that there are multiple modes in
| which to approach LLMs, and that helps explain the massive
| disparity of outcomes using them.
|
| Off topic: This article is dated "Feb 2nd" but the footer says
| "2025". I assume that's a legacy generated footer and it's meant
| to be 2026?
| cadamsdotcom wrote:
| The actual constraint is how long people are willing to wait for
| results.
|
| If the results are expected to be really good, people will wait a
| seriously long time.
|
| That's why engineers move on to the next feature as soon as the
| thing is working - people simply don't care if it could be
| faster, as long as it's not too slow.
|
| It doesn't matter what's technically possible- in fact, a
| computer that works too fast might be viewed as suspicious.
| Taking a while to give a result is a kind of proof of work.
| deepserket wrote:
| > It doesn't matter what's technically possible- in fact, a
| computer that works too fast might be viewed as suspicious.
| Taking a while to give a result is a kind of proof of work.
|
| In recent times I found myself falling for this preconception
| when a LLM starts to spit text just a couple of seconds after a
| complex request.
| pocksuppet wrote:
| https://thedailywtf.com/articles/The-Slow-Down-Loop
| topaz0 wrote:
| > people simply don't care
|
| I don't think that's right, even for laypeople. It's just that
| the pain of things that take 5 seconds when they could take 50
| ms is subtle and can be discounted or ignored until you are
| doing a hundred things in a row that take 5 seconds instead of
| 50 ms. And if you don't know that it should be doable in 50 ms
| then you don't necessarily know you should be complaining about
| that pain.
| wat10000 wrote:
| It's also that the people who pay the price for slowness
| aren't the people who can fix it. Optimizing a common
| function in popular code might collectively save centuries of
| time, but unless that converts to making more money for your
| employer, they probably don't want you to do it.
| https://www.folklore.org/Saving_Lives.html
| emsign wrote:
| LLMs are a very cool and powerful tool when you've learned how to
| use them effectively. But most people probably didn't and thus
| use them in a way that they produce unsatisfying results while
| maximizing resource and token use.
|
| The cause of that is the companies with the big models are
| actually in the token selling business, marketing their models as
| all around problem solvers and life improvers.
| dist-epoch wrote:
| Wirth was complaining about the bloated text editors of the time
| which used unfathomable amounts of memory - 4 MB.
|
| Today the same argument is rehashed - it's outrageous that VS
| Code uses 1 GB of RAM, when Sublime Text works perfectly in a
| tiny 128 MB.
|
| But notice that the tiny/optimized/good-behaviour of today, 128
| MB, is 30 times larger than the outrageous decadent amount from
| Wirth's time.
|
| If you told Wirth "hold my bear", my text-editor needs 128 MB he
| would just not comprehend such a concept, it would seem like you
| have no idea what numbers mean in programming.
|
| I can't wait for the day when programmers 20 years from now will
| talk about the amazingly optimized editors of today - VS Code,
| which lived in a tiny 1 GB of RAM.
| weinzierl wrote:
| This will probably not happen, because of physics.
|
| Both, compute and memory, are getting closer to fundamental
| physical limits and it is unlikely that the next 60 years will
| be in any way like last 60 years.
|
| While the argument for compute is relatively simple it is a bit
| harder to understand for memory. We are not near to any limit
| for the size of our memory but the limiting factor is how much
| storage we can bring how close to our computing units.
|
| Now, there is still way to make and low hanging fruit to pick
| but I think we will eventually see a renaissance of
| appreciation for effective programs in our lifetimes.
| zombot wrote:
| > I think we will eventually see a renaissance of
| appreciation for effective programs in our lifetimes.
|
| In theory, yes. But I bet that the forces of enshittification
| will be stronger. All software will be built to show ads, and
| since there is no limit to greed, the ad storage and
| surveillance requirements will expand to include every last
| byte of your appliance's storage and memory. Interaction
| speed will be barely enough to not impact ad watching
| performance too severely. Linux will not be an out, since the
| megacorps will buy legislation to require "approved" devices
| and OSs to interact with indispensable services.
| pjmlp wrote:
| Hence why I actually happy for the RAM prices getting back to
| how used to be, maybe new generations rediscover how to do much
| with little.
| pixl97 wrote:
| With all that said, applications back in the day being talked
| about were ridiculously easy to crash, and in the early MacOS
| and Win3.1 days, I mean the entire computer to the point of
| hitting the reset switch.
|
| This and a huge amount of size in applications is features and
| libraries that allow compatibility between all kinds of
| different formats. Being able to open and convert almost
| everything is a boon, while also being a security nightmare.
|
| Lastly I bet a lot of these applications could be way smaller
| if a lot of the UI prettiness was stripped from them.
| firmretention wrote:
| The Reiser footnote was on point. I couldn't resist clicking it
| to find out if it was the same Reiser I was thinking about.
| jongjong wrote:
| We haven't yet lost the war against complexity. We would know if
| we had, because all software would grind to a halt due to errors.
| We're getting close though; some aspects of software feels deeply
| dysfunctional; like 2FA and Captcha - They're perfect examples of
| trying to improve something (security) by adding complexity...
| And it fails spectacularly... It fails especially hard because
| those people who made the decision to force these additional
| hurdles on users are still convinced that they're useful because
| they have a severely distorted view of the average person's
| reality. Their trade-off analysis is completely out of whack.
|
| The root problem with 2FA is that the average computer is full of
| vulnerabilities and cannot be trusted 100% so you need a second
| device just in case the computer was hacked... But it's not
| particularly useful because if someone infected your computer
| with a virus, they can likely also infect your phone the next
| time you plug it in to your computer to charge it... It's not
| quite 2-factor... So much hassle for so little security
| benefit... Especially for the average person who is not a Fortune
| 500 CEO. Company CEOs have a severely distorted view about how
| often the average person is targeted by scammers and hackers.
| Last time someone tried to scam me was 10 years ago... The pain
| of having to pull up my phone every single day, multiple times
| per day to type in a code is NOT WORTH the tiny amount of
| security it adds in my case.
|
| The case of security is particularly pernicious because
| complexity has an adverse impact on security; so trying to
| improve security by adding yet more complexity is extremely
| unwise... Eventually the user loses access to the software
| altogether. E.g. they forgot their password because they were
| forced to use some weird characters as part of their password or
| they downloaded a fake password manager which turned out to be a
| virus, or they downloaded a legitimate password manager like
| Lastpass which was hacked because obviously, they'd be a popular
| target for hackers... Even if everything goes perfectly and the
| user is so deeply conditioned that they don't mind using a
| password manager... Their computer may crash one day and they may
| lose access to all their passwords... Or the company may require
| them to change their password after 6 month and the password
| manager misses the update and doesn't know the new password and
| the user isn't 'approved' to use the 'forgot my password'
| feature... Or the user forgets their password manager's master
| password and when they try to recover it via their email, they
| realize that the password for their email account is inside the
| password manager... It's INFURIATING!!!
|
| I could probably write the world's most annoying book just
| listing out all the cascading layers of issues that modern
| software suffers from. The chapter on security alone would be
| longer than the entire Lord of the Rings series... And the
| average reader would probably rather throw themselves into the
| fiery pits of Mordor than finish reading that chapter... Yet for
| some bizarre reason, they don't seem to mind EXPERIENCING these
| exact same cascading failures in their real day-to-day life.
| sevensor wrote:
| I know competent adults whose login flow for most websites is
| "forgot password." Might be better off writing your passwords
| on post it notes at that point.
| amatecha wrote:
| I've seen a few sites where the login flow is simply entering
| your email address and you get a time-limited login link sent
| to you. You never create any password at all. I was skeptical
| at first but I've found it seems to work pretty decently.
| Attrecomet wrote:
| This could not be a more picture perfect example of a
| Wirth-suboptimal engeneering decision as per the article if
| it were designed for that. The amount of slowdown to run to
| the emails, wait for reception, open, copy, paste instead
| of using the sensible flow of password manager integration
| is huge. But people will use wasteful processes if they
| just don't need to change them, so what are you gonna do?
| jongjong wrote:
| Whenever some website asks me to use specific weird
| characters in my password. I have to write it down on a post-
| it note and put it in the top drawer of my desk.
|
| The irony is that the websites which require such passwords
| are often low-importance.
| ontouchstart wrote:
| If you read that Wirth 1995 paper (A Plea for Lean Software)
| referenced by the OP, following paragraphs answered your
| question:
|
| " To some, complexity equals power
|
| A system's ease of use always should be a primary goal, but
| that ease should be based on an underlying concept that makes
| the use almost intuitive. Increasingly, people seem to
| misinterpret complexity as sophistication, which is baffling --
| the incomprehensible should cause suspicion rather than
| admiration.
|
| Possibly this trend results from a mistaken belief that using a
| somewhat mysterious device confers an aura of power on the
| user. (What it does confer is a feeling of helplessness, if not
| impotence.) Therefore, the lure of complexity as sale incentive
| is easily understood; complexity promotes customer dependence
| on the vendor."
|
| I am typing (no screenshots or copy and paste) this 30 year old
| wisdom in to reply here as an archived reminder for myself.
| gostsamo wrote:
| I suspect that the next generation of agenticly trained llm-s
| will have a mode where they first consider solving the problem by
| writing a program first before doing stuff by hand. At least, it
| would be interesting if in a few months the llm greets me with
| "Keep in mind that I run best on ubuntu with uv already
| installed!".
| casey2 wrote:
| It's inevitable even if it's unnecessary. Capitalism necessitates
| 6% growth year on year. Since IT services are the growth sector
| of course 25% of power will go to data centers in 2040
|
| The EU should do a radical social restructuring betting on no
| growth. Perhaps even banning all American tech. A modern
| Tokugawa.
| lateforwork wrote:
| Take a look at what was possible in the late 1980s with 8 MB of
| RAM: https://infinitemac.org/1989/NeXTStep%201.0
|
| You can run NeXTStep in your browser by clicking above link. A
| couple of weeks ago you could run Framemaker as well. I was blown
| away by what Framemaker of the late 1980s could do. Today's
| Microsoft Word can't hold a candle to Framemaker of the late
| 1980s!
|
| Edit: Here's how you start FrameMaker:
|
| In Finder go to NextDeveloper > Demos > FrameMaker.app
|
| Then open demo document and browse the pages of the demo
| document. Prepare to be blown away. You could do that in 1989
| with like 64 MB of RAM??
|
| In the last 37 years the industry has gone backwards. Microsoft
| Word has been stagnant due to no competition for the last few
| decades.
| lateforwork wrote:
| Here's a screenshot of FrameMaker I just took:
| https://imgur.com/a/CG8kZk8
|
| Look at the fancy page layout that was possible in the late
| 1980s. Can Word do this today?
| digitalPhonix wrote:
| I think Publisher would be the equivalent to FrameMaker from
| the Office suite. Publisher from Office ~2016 could
| definitely do that.
|
| Unfortunately I think Publisher has faired even worse than
| Word in terms of stagnation, and now looks to be
| discontinued?
| lateforwork wrote:
| Publisher is the equivalent of InDesign. It was meant for
| brochures and so on. If you want to write a long technical
| manual today most people use Word. In that respect we are
| using less powerful software today than our grandparents.
|
| Note: Adobe bought FrameMaker and continues to sell
| FrameMaker. But Word has captured the market not because of
| its technical merit but because of bundling.
| ferguess_k wrote:
| I have never written any technical manuals, but I'm
| surprised that Word is the choice of tool. How does one
| embed e.g. code easily in the document? I feel there must
| be a better way to do it, maybe some kind of markdown
| syntax? Latex?
| lateforwork wrote:
| > _How does one embed e.g. code easily in the document?_
|
| You don't. For APIs and such, documentation is published
| online, and you don't need Word for that. Word is used in
| some industries, where printed manual is needed.
| ferguess_k wrote:
| What about the printed manuals? I think they still have
| some of those not too long ago (e.g. Intel manuals). What
| was the tool chosen? Very curious to know.
|
| Or, maybe a legacy example -- how were the printed
| manuals of Microsoft C 6.0 written? That was in the early
| 90s I think.
| WillAdams wrote:
| Framemaker.
| ferguess_k wrote:
| Thanks, thought MSFT was using its own tools.
| WillAdams wrote:
| If you don't make it, you can't use it.
|
| Microsoft has never made a technical publishing package,
| so it has to be outsourced.
| ferguess_k wrote:
| Yeah I agreed. Kinda missed the old days with thick
| manuals. I bought one for gdb a couple of years ago and
| love it -- despite it is just the paper version of the
| online one.
| WillAdams wrote:
| Correct, it is going away as of October this year.
| WillAdams wrote:
| Yes, Word could do that, but it wouldn't be pleasant to set
| up or maintain or print (it would re-flow, badly every time
| one changes print drivers), moreover, there are only two
| states for long Word documents which include graphics in my
| experience: corrupt, and not-yet corrupt.
| socalgal2 wrote:
| now paste some Chinese and Thai in there and a few high-res
| jpegs
| kjellsbells wrote:
| I didn't have defending Word on my todo list today,... but
| Word would totally be the wrong tool for this,so it isnt fair
| to compare.
|
| The tragedy is that serious large document authoring systems
| died with the invention of hypertext and the CDROM. Instead
| of an elegant set of FrameMaker or Interleaf documents for
| print you got a cdrom with a private site. And then once the
| web took off, just a site. Something got lost in that
| transition beyond the pallet of manuals showing up on your
| loading dock when you bought a system.
|
| Sadly because Word won, technical authors still try to
| produce some content with it, but (not their fault) it's a
| horrible broken experience for both writer and reader. One
| example is the 3GPP specs that define how the mobile phone
| network works. Giant 200 page Word docs that take minutes to
| open and paginate.
| ferguess_k wrote:
| I think back then, due to the scarcity of RAM and HDD,
| developers, especially elite developers working for
| Apple/Microsoft/Borland/whatever really went for the last mile
| to squeeze as much performance as they could -- or, at least
| they spent way more time on this comparing to modern day
| developers -- even for the same applications (e.g. some native
| Windows programs on Win 2000 v.s. the re-written programs on
| Win 11).
|
| Nowadays businesses simply don't care. They already achieved
| the feudal-ish bastion they have dreamed about, and there is no
| "business value" to spend too much time on it, unless ofc if it
| is something performance related, like A.I. or Supercomputing.
|
| On the other hand, hardware today is 100X more complicated than
| the NeXTStep/Intel i486 days. Greybeards starting from the
| 70s/80s can gradually adapt to the complexity, while newcomers
| simply have to swim or die -- there is no "training" because
| any training on a toy computer or a toy OS is useless comparing
| to the massive architecture and complexity we face today.
|
| I don't know. I wish the evolution of hardware is slower, but
| it's going to get to the point anyway. I recently completed the
| MIT xv6 labs and thought I was good enough to hack the kernel a
| bit, so I took another Linux device driver class, and OMG the
| complexity is unfathomable -- even the Makefile and KBuild
| stuffs are way way beyond my understanding. But hey, if I
| started from Linux 0.95, or maybe even Linux 1.0, I'd have much
| elss trouble to drill into a subsystem, and gradually adapt.
| That's why I think I need to give myself a year or two of
| training to scroll back to maybe Linux 0.95, and focus on just
| a simpler device driver (e.g. keyboard), and read EVERY
| evolution. There is no other way for commoners like us.
| WillAdams wrote:
| There were also
|
| - TeXview.app which at least inspired the award-winning
| TeXshop.app
|
| - Altsys Virtuoso which became Macromedia Freehand (having been
| created as a successor to Freehand 3) --- these days one can
| use Cenon https://cenon.info/ (but it's nowhere near as
| nice/featureful)
|
| - WriteNow.app --- while this was also a Mac application, the
| NeXT implementation was my favourite --- WN was probably the
| last major commercial app written in Assembly (~100,000 lines)
|
| Still sad my NeXT Cube stopped booting up....
| projektfu wrote:
| Also Lotus Symphony
| senderista wrote:
| 64MB in 1989? That wasn't too shabby in 1999!
| lateforwork wrote:
| FrameMaker 1.0 for the NeXTcube required a minimum of 8 MB to
| 16 MB of RAM.
| canucker2016 wrote:
| A web search shows that FrameMaker 1.0 cost $2,500.
|
| wikipedia says that the Windows version, released in 1992,
| was priced at $500, which cannibalized sales on other
| platforms.
| drfuchs wrote:
| Well, ackchyually, the first releases of FrameMaker were
| created on Sun 3/50 workstations with 4MB of (unexpandable,
| soldered-in) RAM on a 16Mhz 68020. Most customers had the same
| model, and could work on modestly-sized documents with ease.
|
| But it's not a lot of space for documents of hundreds of pages,
| so typical customers who were using FrameMaker to write user
| manuals for their products had to use "book" files to tie
| together individually edited chapter files. Then, once in a
| while you'd have to push the "generate" button on the book to
| get all the page numbers consistent between chapters, all the
| cross-references updated, and generate the updated Table Of
| Contents, Index, etc. You're welcome.
|
| But there's a potential degenerate case where Chapter 1 might
| have a forward reference to Chapter 2 ("see page 209"), but due
| to some editing in Chapter 2, the referenced material now on
| page 210. Well, in some fonts, "209" is wider than "210" (since
| "1" can be skinny). So, during the Generate operation, the
| reference becomes "see page 210". But there's some tiny chance
| that this skinnier text changes the including paragraph to have
| one less line, so there's some tinier chance that Chapter 1
| takes one less page, so Chapter 2 starts one page earlier, and
| now the referenced material is back on page 209. So now we're
| in a loop.
|
| This was such an unlikely edge case that nobody else noticed
| that it even existed, much less that it was detected. I didn't
| bother with a fancy error message; it would just give a little
| one-word popup: "Degenerate". Years later, mild panic ensues
| when a customer calls in, irate that the software is calling
| _them_ a degenerate. (And it wasn 't even a real example, just
| some other bug that triggered it.)
| lateforwork wrote:
| You were on FrameMaker development team? That's so awesome!
| m463 wrote:
| That fat thing wouldn't fit on my 360k floppy!
| delichon wrote:
| > LLMs are still intensely computationally expensive. You can ask
| an AI what 2 * 3 is and for the low price of several seconds of
| waiting ... But the computer you have in front of you can perform
| this calculation a billion times per second.
|
| This is a flip side of the bitter lesson. If all attention goes
| into the AI algorithm, and none goes into the specific one in
| front of you, the efficiency is abysmal and Wirth gets his
| revenge. At any scale larger than epsilon, whenever possible LLMs
| are better leveraged to generate not the answer but the code to
| generate it. The bitter lesson remains valid, but at a layer of
| remove.
| 1970-01-01 wrote:
| He was wrong up until we found the end of Moore's law. Now that
| hardware cannot get exponentially faster, we are forced to
| finally write good code. The kind that isn't afraid to touch bare
| metal. We don't need another level of abstraction. Abstraction
| does not help anyone. I would love to point to some good examples
| but it's still too early for this to be seen globally. Your 1000
| container swarm for a calculator app is still state of the art
| infrastructure.
| whoisthemachine wrote:
| Lots of good thoughts in here.
|
| > You can ask an AI what 2 * 3 is and for the low price of
| several seconds of waiting, a few milliliters of water and enough
| power to watch 5% of a TikTok video on a television, it will tell
| you.
|
| This might be what many of the companies that host and sell time
| with an LLM _want_ you to do, however. Go ahead, drive that
| monster truck one mile to pickup fast food! The more that 's
| consumed, the more money that goes in the pockets of those
| companies....
|
| > The instincts are for people to get the AI to do work for them,
| not to learn from the AI how to do the work themselves.
|
| Improviny my own learning is one of the few things I find
| beneficial with LLMs!
| Lapsa wrote:
| "an interactive text editor could be designed with as little as
| 8,000 bytes of storage" - meanwhile Microsoft adds copilot
| integration to Notepad
| pixl97 wrote:
| I mean, it could be that small... but why isn't it?
|
| This isn't a different question from "Why is Microsoft office
| everywhere"
|
| And "Why are all the popular things gigantic".
|
| Features, not speed, are what gets people to adopt software in
| the vast majority of cases.
| stego-tech wrote:
| Just a genuinely excellent essay written to a broader technical
| audience than simply those software engineers who live in the
| guts of databases optimizing hyper-specific edge-cases (and no
| disrespect to you amazingly talented people, but _man_ your
| essays can be very chewy reads sometimes). I hope the OP's got
| some caching ready, because this is going to get _shared_.
| nemo1618 wrote:
| Just wait. In a few years we'll have computer-use agents that are
| good enough that people will stop making APIs. Why bother
| duplicating that effort, when people can just direct their agent
| to click around inside the app? Trillions of matmuls to
| accomplish the same result as one HTTP request.
| WillAdams wrote:
| Surprised no one has mentioned Oberon in this discussion:
|
| https://oberon.org/en
|
| Really wish that there were drivers available to make that run
| nicely/natively on a Raspberry Pi rather than in an emulator:
|
| http://pascal.hansotten.com/niklaus-wirth/project-oberon/obe...
| abeppu wrote:
| I would love to see an llm system oriented around trying to "jit"
| out fast/cheap combinations of tool invocations from calls. The
| case where heartbeat calls Opus, where the transformer model
| itself doesn't know the time but has access to some tools, should
| be solvable if Opus has said the equivalent of "it's still night,
| and to determine this I checked the time using the `date` utility
| to get the epoch time and if it had responded something greater
| than $X I would have said it's morning". I.e. the smart model can
| often tell a less capable framework how it can answer the same
| question cheaply in the future. But incentives aren't really
| aligned for that presently.
| vidarh wrote:
| Well, you can have the less capable system ask the more capable
| system to _give it a tool_ to solve the problems it doesn 't
| know how to solve, instead of solving it. If the problem really
| needs the more advanced system, that tool might call a model.
| abeppu wrote:
| Or tell you how to use the tools you already have, but sure
| whatever. The point is, "LLMs that actually do stuff" end up
| partly looking like expensive logic to decide what to do
| (like an interpreter) and actually doing it, in terms of some
| preexisting set of primitives. The expensive logic does get
| you a high degree of flexibility for less programming cost,
| but you pay a lot for interpretive overhead. I really do
| think something that looks like a tracing hit (and a standard
| set of tools or primitives) could find "straight line" paths
| a reasonable fraction of calls. But if the interpreter is a
| service that you pay for by the token, and which is already
| losing money, why should it be written to do so?
| vidarh wrote:
| > Or tell you how to use the tools you already have, but
| sure whatever.
|
| But that's missing the point of the writing tools example:
| The models can _unilaterally do this_ , and if prompted
| properly _they will do this today_. Writing an agent loop
| that will encourage the agent to build up it 's own library
| of tools and prefer that library first, using a small
| (possibly local) model to select, is literally no more than
| a couple of hundred lines of code.
|
| I wrote a toy coding agent a while back, and I started just
| with the ability for it to run shell commands. Every other
| tool the model wrote itself. At some point it even tried to
| restart itself to get access to the tool it had just
| written.
|
| The providers only control a miniscule proportion of
| tooling, and the models themselves are capable enough that
| they will never control most of the tooling.
|
| As a result, a lot of effort _is_ going into optimising
| this to reduce token use.
|
| But what we're seeing is that _the main driver_ for this is
| not to spend less, but to do more, because we get enough
| value out of these models that every cost saving measure
| makes it possible to at a minimum spend the same to do
| more, but often even to spend more.
|
| I'm doing projects now that would be financially unviable
| just 6 months ago.
| lo_zamoyski wrote:
| Wirth's complaint makes sense when the utility of software
| remains constant (or degraded) in relation to rising costs of
| providing that utility. But we must clarify what "cost" means
| here (and the relevant costs are all ultimately economic costs),
| because this can explain the contours of why software is written
| the way it is. We also should clarify "utility".
|
| Economically, something like memory is in the vicinity of 10
| orders of magnitude cheaper today relative to 1970 (a). Similar
| things can be said about processors. This means the incentive to
| invest costly engineering resources (b) into optimizing software
| is very low. In terms of energy, a CPU instruction is at least
| millions of times more energy efficient today (c). That's another
| big economic disincentive. Furthermore, time spent optimizing is
| time not spent doing product development (d). A slower product on
| the market can be better than late market entry.
|
| So we have production costs of hardware (a), production costs of
| software (as a function of time)(b), energy costs of hardware
| (c), energy cost of running software (c), and opportunity cost of
| late market entry (d). There's also the time cost of running
| software (e).
|
| (a) is cheaper;
|
| (b) depends on your measurement of utility;
|
| (c) is cheaper;
|
| (d) means unoptimized software tends to be cheaper;
|
| (e) depends on your measurement of utility;
|
| So (b) and (e) are where Wirthian arguments can focus.
|
| However, AI may yet play a major role in optimizing software.
| They are already being used in this space.[0]
|
| W.r.t. complexity, one consequence of abstraction is that it
| further decouples the cost of an operation from the difficulty of
| implementation. Of course, the two were never identical to begin
| with. It is easier to implement bubble sort than quick sort,
| easier still to come up with it when you have no knowledge of
| sorting algorithms. But greater abstraction is better at
| concealing computational complexity. The example involving ORMs
| is a good one. When you have to write SQL by hand, you have a
| clearer picture of the database operations that will be
| performed, because the correspondence between the operations and
| what the database is doing is tighter. ORMs, on the other hand,
| create an abstraction over SQL that is divorced from the
| database. Unless the ORM is written in some crafty way that can
| smartly optimize the generated SQL (and optimizers have their
| limitations), you can land yourself in exactly the situation the
| author describes.
|
| W.r.t. learning from LLMs, that is perhaps the better application
| in many cases, as a kind of sophisticated search engine. The
| trouble is that people treat LLMs as infallible oracles. Another
| issue is that people seem not to care about becoming better
| themselves. You see this with thought experiments where we posit
| some AI that can do all the thinking and working for us. Many if
| not most people react as if this makes human beings
| "obsolete"...which is such a patently absurd and frankly
| horrifying and obscene notion that it can only be an indictment
| of our consumerist culture. Obsolete with respect to _what_? A
| human life is not defined by economic utility. Human purpose is
| not instrumental. Even if an AI understood philosophy, science,
| etc., if _I_ don 't understand them, then _I don 't understand
| them_. I am no better for it when someone or some fictional AI
| does. I am made no wiser.
|
| [0] https://arxiv.org/abs/2503.15669
| miniBill wrote:
| Per Betteridge's: no
___________________________________________________________________
(page generated 2026-02-05 23:01 UTC)