If you ever tried Office 97 on a PC of 10+ years later, it's amazing how fast and lightweight it was. Instant startup, super snappy. And those apps were not lacking in features. 95% of what you need out of a desktop word processor was in Word 97.
How did we get back to this though? We have gigabytes/sec with NVMe and stupid fast CPU's with at least 4 cores in even low end models. Yet a text editor takes so long to load we need to load it up on boot... Such a frustrating field to work in.
Not that I'm that nostalgic for the old days, we would have been doing the exact same thing if we were able to get away with it. But performance restrictions meant you had no choice but to care. Modern tech has "freed" us from that concern.
About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much). An operating system had to manage with 8,000 bytes, and a compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary, were it not for a thousand times faster hardware, modern software would be utterly unusable.
https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR...
That said, as someone fairly young, I still don't think that makes it wrong or something only an old man would think. Software seems to perform exactly as well as it needs to and no more, which is why hardware advances don't make our computers run software much faster.
If software was simpler, we could afford to offer some formal guarantees of correctness. Model check protocols, verify pre and post conditions à la Dafny, etc.
There's too much change for the sake of change.
+1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally.
The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's almost no other option but to introduce change for the sake of change.
At a general level, I believe there are other options - changes/features need to meet some level of usage or it is scrapped out of recognition that supporting all these features make bugs more likely, performance likely to degrade, increase difficulty of adding features, make the product more difficult to use, etc.
+1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally.
The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's often almost no other option but to introduce change for the sake of change.
He said it's often just some new marketing exec wants to put something on their resume, and they have certain metrics that they target that don't necessarily align with long term profits of the company.
I'm sure software has a similar problem.
The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today.
I'm not talking about "write in assembly, duh" I'm talking about just doing things intelligently instead of naively. The developers I support often simply are not thinking about the problem they're solving and they solve the problem in the simplest way (for them) and not the simplest way for a computer.
Software is an inefficiency amplifier, because the number of developers for a piece of code is much smaller than the number of computers that run that code; how much coal has been burned solely because of shitty implementations? I'd wager that the answer is "a LOT!"
Even if you don't care about coal usage, think about how much happier your users would be if your application was suddenly 5x faster than it was previously? now think of how many customers want their software to be slow (outside of TheDailyWTF): zero.
languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. JS and Electron are great for developers, and horrible for users because of that amplification I described above.
I am dead tired of seeing hustle culture overtake everything in this field, and important things, to me, like quality and performance and support all fall straight down the toilet simply because executives want to release features faster.
things like copilot could help with this, i hope. presumably copilot will help introduce better code into applications than a daydreaming developer would, though the existence of vibe coding sort of nulls that out probably.
one thing that AI will do quite soon is increase the amount of software that exists quite dramatically. and I am kinda concerned about the possibility that it's all going to suck horribly.
Both are written/designed by people who care a lot about application performance and developer experience.
Copilot is trained on Github (and probably other Git forges w/o permission, because OpenAI and Microsoft are run by greedy sociopaths.)
I'd wager that the majority of fleshed out repositories on these sites contain projects written at the "too-high level" you describe. This certainly seems to be true based on how these models perform ("good" results for web development and scripting, awful results for C/++/Rust/assembly...) - so I wouldn't get your hopes up, unfortunately.
Low level programming means actual -thinking- about the system, resources, and language decisions etc
Even humans struggle with it, Its much easier to build a website than say a compiler, for anyone, humans and llm's included
My personal benchmark for these models is writing a simple socket BPF in a Rust program. Even the latest and greatest hosted frontier models (with web search and reasoning enabled!) can only ape the structure. The substance is inevitably wanting, with invalid BPF instructions and hallucinated/missing imports.
It works great for me, but it is necessarily an aid learning tool more than a full on replacement, someone's still gotta do the thinking part, even if the llm's can cosplay -reasoning- now
Waiting is ok when it comes to sending batches of data to be transformed or rendered or processed or whatever. I’m talking about synchronous stuff; when I push a key on my keyboard the computer should be done with what I told it to do before I finish pushing the button all the way down. Anything less is me waiting on the computer and that slows the user down.
Businesses should be foaming at the mouth about performance; every second spent by a user waiting on a computer to do work locally, multiplied by the number of users who wait, multiplied by the number of times this happens per day, multiplied by the number of work days in a year… it’s not a small amount of money lost. Every more efficient piece of code means lighter devices are needed by users. Lambda is billed by CPU and RAM usage, and inefficient code there directly translates into higher bills. But everyone still writes code which stores a Boolean value as a 32-bit integer, and where all numbers are always 8-bytes wide.
What. The. Fuck.
People already go on smoke breaks and long lunches and come in late and leave early; do we want them waiting on their computers all of the time, too? Apparently so, because I’ve never once heard anyone complain to a vendor that their software is so slow that it’s costing money, but almost all of those vendor products are that slow.
I’m old enough that I’m almost completely sick of the industry I once loved.
Software developers used to be people who really wanted to write software, and wanted to write it well. Now, it’s just a stepping stone on the way to a few VP positions at a dozen failed startups and thousands of needlessly optimistic posts on LinkedIn. There’s almost no craft here anymore. Businessmen have taken everything good about this career and flushed it down the toilet and turned teams into very unhappy machines. And if you don’t pretend you’re happy, you’re “not a good fit” anymore and you’re fired. All because you want to do your job well and it’s been made too difficult to reliably do anything well.
Why? A good portion of programs are still single-threaded, and often that's the correct choice. Even in games a single-threaded main thread or logic thread may be the only choice. Where multi-threading makes sense it should be employed, but it's difficult to do well.
Otherwise, it's up to the OS to balance threads appropriately. All major OSes do this well today.
One can write software that uses the CPU cache in non-dumb ways no matter how many threads your program has. You can craft your structs so that they take less space in RAM, meaning you can fit more in cache at once. You can have structs of arrays instead of arrays of structs if that helps your application. Few people think of things like this today, they just go for the most naive implementation possible so that the branch predictor can’t work well and everything needs to be fetched from RAM every time instead of building things so that the branch predictor and the cache are helping you instead of impeding you. People just do the bare minimum so that the PM says the card is complete and they never think of it again. It’s depressing.
The tools to write fast software are at our fingertips, already installed on our computers. And I have had zero success in getting people to believe that they should develop with performance in mind.
Nowadays you just "scale horizontally" by the magic of whatever orchestration platform you happen to use, which is the modern approach of throwing hardware at the problem in the vertical scaling days.
Even operating systems don't get direct access to the hardware these days. Instead a bunch of SoC middlemen handle everything however they like.
If you do the things which make your code friendly to the CPU cache and the branch predictor, when it comes time for your code to run on the CPU, it will run faster than it would if you did not do those things.
Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer.
Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.
Let’s normalize speed over time like we do dollars, so we are talking about the same thing.
Given the enormous multiplier in CPU and storage hardware speeds and parallelism today vs. say 1995, any “slow” application then should be indistinguishable from instant today.
“Slow” in the 90’s vs. “Slow” in 2025 are essentially different words. Given unclarified co-use pushes several orders magnitude of either speed or inefficiency difference under the rug.
RAM parallel bandwidth, increased caching levels and size, and better caching rules, instruction re-ordering, predictive branching, register optimization, vector instructions, ... there have been many advances in single thread execution since the 90's. Beyond any clock speed advances.
Source: https://arstechnica.com/gadgets/2020/11/a-history-of-intel-v...
(I'm sure someone could dig up more recent graphs, but you get the idea).
In order to get more performance, your app needs to use multithreading.
The promise of computing is that what was slow in the 1960s and 1970s would be instant in 1990. And those things were instant, but those things aren’t what people did with computers anymore.
New software that did more than before, but less efficiently, came around, so everything felt the same. Developers didn’t have to focus on performance so much, so they didn’t.
Developers are lazy sacks who are held skyward because of hardware designers alone. And software developers are just getting heavier and heavier all the time, but the hardware people can’t hold them forever.
This cannot continue forever. Run software from the 1990s or 2000s on modern hardware. It is unbelievably fast.
Maybe it was slow in the 1990s, sure. I ask why we can’t (or won’t) write software that performs like that today.
The compiler for Turbo Pascal could compile something like a million lines per second in 1990. We have regressed to waiting for 60+ minute C++ compile times today, on even moderate project sizes.
Debugging in visual studio used to be instant when you did things like Step Over. You could hold the Function key down and just eyeball your watch variables to see what was going on. The UI would update at 60FPS the entire time. Now if I hold down that key, the UI freezes and when I let go of the key it takes time to catch up. Useless. All so Microsoft could write the front end in dotnet. Ruin a product so it is easier to write… absolute nonsense decision.
All software is like that today. It’s all slow because developers are lazy sacks who will only do the minimum necessary so they can proceed to the next thing. I am ashamed of my industry because of things like this.
As a programmer who studied computer and electrical engineering in university, never before have I been so offended by something I one hundred percent agree with
The cynical spin I would put on this idea is that software performs as poorly as it can get away with. MSFT is feeling the need/pressure to have Office load faster, and they will try to get away with preloading it.
Otherwise, there is a strong pull towards bloat that different people will try to take credit for as features even if the cumulative experience of all these "features" is actually a worse user-experience.
we now DO have civil engineering but that is it
Not Java, but an IDE in 4K: https://en.wikipedia.org/wiki/BASIC_Programming
Having used it quite extensively (Well, five solid days over two weeks, which is about 1000x longer than most people gargling on the internet), it's surprisingly capable.
Imagine if someone with the same talent and motivation was working on today's hardware.
<aside> Someone on Atari Age wrote a LISP for the same machine.
Indeed. I am sure many of us here are burnt out on bloat. I am also sure many of us want to move to smaller stuff but cant simply because of industry momentum. BUT that doesn't mean the dream is dead, only that we must work towards those goals on our own time. I found Plan 9 and haven't looked back. I can rebuild the entire OS in seconds on a fast machine. Even my little Celeron J1900 can rebuild the OS for several supported architectures in minutes. I can share a USB device seamlessly across my network, PXE booted from a single disk without installing anything. Cat(1) is just 36 lines of C.
There's still hope. Just ignore the industry hype noise and put in the effort ourselves.
I'm looking forward to when app developers ship you an entire computer in the mail to run their text editor.
Yet for the user it is bad -- bloated, slow, feels non-native, has specific bugs which are hard to address for the devs, etc.
I don't see any light for the desktop UI development unless there is some lightweight universal rendering engine. Tauri with WebView is somewhat promising, but it has problems on Linux and it is hard to target older systems.
As for your second point: [1]
Correct me if I'm wrong, but isn't it around 800 lines[1]?
1. https://github.com/coreutils/coreutils/blob/master/src/cat.c
The problem isn't "engineering" the problem is the culture of product management. (Note: NOT product managers per se).
I ask this basic question, how many Directors, VP's or CPO's do you know who got their job based on "cutting out unused features"? If you can find one, it will end up being the exception that proves the rule. The culture of "add", "new" and "shiny" doesn't reward keeping things lean and effective. T
In the tangible world we look to accountants for this sort of thing (because they tend to have costs). Think cheap Costco hotdogs and free cookies at Double Tree. No one in product, dev and accounting is going to sit down and try to justify loosing some code, features and maybe a few customers to make it faster when you can just "engineer" you way out of it and not have to sell less is more.
Google goes a step further and kills entire apps
https://www.slashgear.com/1513242/ford-gets-rid-of-self-park...
Performance just isn’t on that list, and it’s often more and harder work than a given new feature took to create. Office users are getting what Microsoft is designed to deliver.
Yes! This is what all my projects are geared towards restoring. The big one is not quite ready to announce yet, but I am very proud of it, and extremely excited to release it, to solve exactly that: it makes engineering fun again!
But adding yet another gateway to ChatGPT’s API…that’s a $15/mo/user add-on right there, and not just a monkey, but one of the slower intern monkeys, could write the code for such an incredibly innovative and, there’s no other word for it, powerful new feature that everyone should be thrilled to pay for at a 200-300% (or more!) markup. So guess who gets that VP of New Bullshit Development position, and guess what kind of choices get reinforced?
(EDIT: grammar)
Absolutely this. I think this is evidence that points to modern civilization starting to collapse. When we can engineer correctly, we're fucked.
Have a large ZIP file. Preferably like a few gigs and lots of (small) files.
Try to open it with the built-in Windows 11 tooling from Microsoft. It's going to be super slow to even show anything never mind unpack it.
Now install say 7-zip and do the exact same thing(s) and it's going to be instant opening and unpacking it takes a much much smaller amount of time (only limited by disk speed).
Turns out optimizations / not doing stupid things is still a thing even with all this raw power we now have.
Why the hell are all my desktop apps written in JS now?!
Have you seen the state of pretty much every non-js UX framework?
That's why.
JS/css/html won the UX domain in a way that no other language comes close to. If you look at the most recent most modern UX frameworks, they are often just half implemented poor mimics of the js/css/html stack with approximately 0 devs writing new 3rd party extensions.
Intellij uses swing, SWING, as it's UX. A framework written in the 90s filled with warts. Yet, it's still a better experience than the more recent JavaFX experience. Swing simply has more support.
The bigger issue isn't the tech, it's the ecosystem. While you might like swing, you simply are never going to find the swing version of Material UI or D3.js. That's more the problem that you'll run into.
For some of our apps because we need charting, we are using GraalJS just to run the JS charting library to export to an image that we ultimately put on some of our downloadable reports. It's a huge pain but really the only way to do that.
I remember a time when having your application look "out of place" was undesired, and the ultimate goal was to be "as native as possible". If you are running a website selling something, I agree that you want a brand-identity and a unique look. But productive software shouldn't require users to adapt to new UX paradigms (guessing whether the cancel button comes on the left or on the right, dealing with slightly do different input method and entry shortcuts…).
Anyhow, I think things could be worse, since, as you say, we can embed a webview into any JavaFX/Qt/… app and get the best of both worlds.
Besides, the only thing that matters is getting tickets "done" before the arbitrary sprint deadline in 2 weeks, so best not to spend any extra time cleaning up or optimizing the first thing that works. You can't think about performance until the sprint dedicated to performance.
By piling up nonzero-cost abstractions left and right.
And getting out of the trap is hard too, because no single abstraction is to blame - you can't just hit things with your profiler and find the hot spot. It's all of them. So now you either live with it or rewrite an entire stack of abstractions.
While true LLMs fall flat on their face when fed massive codebases, the fact of the matter is that I don't need a 200k LOC program to accomplish a single task that an LLM can do in 2k LOC.
To give an example, we have proprietary piece of software that is used to make (physical) product test systems using flow charts and menus. It's expansive and complex. But we don't need it when we can just spend 30 minutes prompting your way to working test code and it produces way faster and more robust systems.
Maybe the devs of that software package cannot dump that whole codebase into an LLM and work on it. But they are completely missing the forest for the trees.
The Plan
In the beginning, there was a plan, And then came the assumptions, And the assumptions were without form, And the plan without substance,
And the darkness was upon the face of the workers, And they spoke among themselves saying, "It is a crock of shit and it stinks."
And the workers went unto their Supervisors and said, "It is a pile of dung, and we cannot live with the smell."
And the Supervisors went unto their Managers saying, "It is a container of excrement, and it is very strong, Such that none may abide by it."
And the Managers went unto their Directors saying, "It is a vessel of fertilizer, and none may abide by its strength."
And the Directors spoke among themselves saying to one another, "It contains that which aids plants growth, and it is very strong."
And the Directors went to the Vice Presidents saying unto them, "It promotes growth, and it is very powerful."
And the Vice Presidents went to the President, saying unto him, "This new plan will actively promote the growth and vigor Of the company With very powerful effects."
And the President looked upon the Plan And saw that it was good, And the Plan became Policy.
And this, my friend, is how shit happens.
from anonymous email
We'd sometimes go to the library to write something up in MS Word. We always liked this because it would be a good 5-10 mins to boot up some kind of basic Unix menu. You'd then select windows 3.1 and wait another 10-15 minutes for that to load. Then you could fire up word and wait another 5 minutes. Then you could do 5 minutes work before the class was over!
Another example: it takes ~2 seconds to run git on my work machine
(Measure-Command { git status | Out-Null }).TotalSeconds
Probably because windows needs to make a connection for every file somewhere else first and wait for the reply, before granting you the advanced software as a service feature called text editing.
It definitely feels like this at times and I fear there is too much truth in my statement.
But it is not just windows only. My old chromebook took seconds to open a folder in the file browser (even if it was already open). But a "ls" on the terminal was instant for any folder. So getting the information was not the problem. But from there to displaying it in a GUI, there seems to be myriads of important (tracking?) layers involved.
It’s not rocket science to eke out oodles of performance out of a potato if you don’t care about correctness or memory safety.
Word 97 will only delight you if you use it on an airgapped computer, as a glorified typewriter, never open anyone else’s documents with it, and are diligent about manually saving the doc to multiple places for when it inevitably self-corrupts.
But at that point, why not be like GRRM and write on a DOS word processor? Those were historically a lot more reliable than these second-generation GUI apps.
My intellij license just expired so today I'm back using Sublime Text, and honestly it's a breath of fresh air / relief - and it's not even the fastest editor, iirc it uses Python under the hood. I've installed Zed but getting plugins and keyboard shortcuts all lined up is always challenging. That one took ~2-3 seconds to cold start.
This is even more sad with Apple. My M1 Mac felt incredibly snappy with Big Sur, but is getting ever so slightly slower with each update. My iPhone SE2 is a complete disaster.
It's amazingly fast, though it's missing some features and will be really expensive when it leaves beta.
Thank you for posting this, and if you have any other speedy apps you'd recommend I'd welcome suggestions. Mine top suggestions are Speedcrunch [0] (calculator app) and Everything [1] file search combined with Listary [2]
[0] https://github.com/ruphy/speedcrunch
[1] https://www.voidtools.com/
(For reference, I've tried Total Commander, DOpus, Files, Explorer XP, XY Explorer, Explorer ++, FreeCommander, Double Commander, Q-Dir)
I learned about File Pilot (whose author posts here: https://x.com/vkrajacic) from Casey Muratori (https://x.com/cmuratori) who pushed it a bunch because he loves fast things.
Mostly users interact with the explorer in this scenario to open/save a file in ‘BrowserOS’
It's a little unclear what you mean exactly. Do you want the browsing experience changed for the system's file open/save dialogs? i.e. a third-party file explorer opens instead with all of it's features.
It seems fascinating how much more efficient Windows apps were back in the nineties, capable do to almost everything the same today apps do in a similar manner on orders of magnitude less powerful hardware, often performing even faster.
The last time I expressed this, probably also here, somebody suggested the performance drop is the cost of modern security - vulnerability mitigations, cryptography etc.
I also wonder if it's just harder to continually monitor performance in a way that alerts a team early enough to deal with regressions?
That said, security _can_ impact performance! I work on Stripe frontend surfaces, and one performance bottleneck we have comes from needing to use iframes to sandbox and isolate code for security. Having to load code in iframes adds an additional network load before we can get to page render.
Over time decisions are made independently by devs/teams which cause the code bases to get out of alignment with a performant design. This is exacerbated by the growth pressure. It's then really hard for someone to come in and optimize top to bottom because there is everything from a bug to a design problem. Remediation has significant overhead, so only things around the edges are touched.
Fast forward a couple of years and you have a code base that devs struggle to evolve and add features to as well as keep performant. The causes are many and we come to the same one whether we complain about performance or maintainability. You probably don't feel this way, but Stripe and other premier engineering companies are way ahead of others in terms of their practices when you compare with the average situation developers are facing.
Independent mobile development is often where I see most attention to performance these days. The situation for these devs is a little bit closer to what existed in the nineties. They have a bigger span of control and performance is something they feel directly so are incentivized to ensure it's great.
I remember everyone complaining about how bloated they were at the time. Pretty sure someone in 2055 is going to run today's Office on 2055 computers and marvel at how streamlined it is.
You can run Office 97 now and it'll start fast because disk i/o and cpus are so much faster now. Otoh Excel 97 has a maximum of 256 columns and 64k rows. You might want to try Excel 2007 for 16k columns and 1M rows, and/or Excel 2016 for 64-bit memory.
You could build fast software today by simply adopting a reference platform, say. A 10 year old 4core system. then measuring performance there. If it lags then do whatever work needs to be done to speed it up.
Personally I think we should all adopt the raspberry pi zero as a reference platform.
Edit: * office 2000 was fast too with 32 megs of ram. Seriously what have we done?
I rebooted a lot though (mostly used Linux by then), so maybe it was just fighting with itself when I immediately fired up office after boot.
https://copy.sh/v86/?profile=windows95
Once it boots, run povray, then click run.
It took over 2 minutes to render biscuit.pov, though it did manage to use SSE!
We used to wait two hours for a mandelbrot to display on a Commodore 64, and were delighted when it did.
Ironically, it was specifically the longer feedback cycle of long builds and scheduled releases that seems to specifically have given us better software?
Similar to the slow-opening glove box in a car, many humans perceive slow computers & software as a signifiers of importance/luxury/prestige. At least at first. By the time they are familiar with the slow software, and impatient to just get their work done - too late, SnailSoft already has their money.
The majority of the app is written in C++. Python is used for plugins.
I still love IntelliJ, its a great product. But it is slow, bloats the computer, needs constant updating. But at least its incredibly powerful as a tradeoff to the bloat.
The Office debate is slightly different. It is slow, bloats the computer, needs constant updating. But unlike IntelliJ i dont feel that there is any advantage to all that added weight. We are using a word processor. We type words onto a blank screen. Why is Word and Outlook the most common applications to crash my computer that has an M1 Max Chip with 48Gb of Memory? I can literally run and build AI models on my computer with no problem but you boot up Microsoft Word to type words onto a blank page and you have a 33% chance of crashing the computer.
Google Sheets and Docs are actually better tools in my opinion for most people. 99% or more of the features you need are available in the google equivalents. These products are fast and run in a browser! The UI is actually VASTLY superior to Microsoft's ribbon. I still can't find stuff that I need on a routine basis and have to google it. I don't have this problem when using Google's office equivalents.
My prediction is that we are about to enter a great winter of poor performance across the industry as AI slop is put in to production en mass. Along with bugginess that we have not seen since the early dotcom days.
I have a small utility app that I sell and make great pains to keep it small and resource light. I really appreciate when other devs do the same.
https://www.vintagecomputing.com/index.php/archives/1063
Their service used vector art to render interactive pages like that over <= 2400 baud modems. Other than it being proprietary and stuff, I'm guessing the web would be a much cooler place if HTML hadn't eaten their lunch. SVG is a decent consolation prize, I guess.
It's not merged yet but I've written an Elixir library that writes graphics files in Prodigy's graphics format, NAPLPS. I'm using it to get current weather and creating weather maps that are displayed in Prodigy. https://github.com/rrcook/naplps_writer
You can run Prodigy in DOSBox and get screenshots.
Opening a spreadsheet, even if you don't want to print it, will hang for 30 seconds doing nothing, because LibreOffice will load the printer settings for the document, which means asking the printer, which if the printer is network-based and turned off, means a 30 second wait for a timeout.
Reported in 2011, still not fixed: https://bugs.documentfoundation.org/show_bug.cgi?id=42673
"Print to PDF -> print the PDF" is much more reliable.
sigh
Perhaps spurred by this comment, there was new discussion in the report and it turned out Microsoft has fixed the issue in Windows 11: https://bugs.documentfoundation.org/show_bug.cgi?id=42673#c8...
Quote:
"I was one of the many who reported this problem in one from or another. The problem is Windows-specific. I have found out that the problem actually comes from the Windows print system. There is no way to check that a printer is actually active or working or even present without incurring a long time-out in case the printer is not present or powered. Trying to check the defualt printer will incur the same time-out.
Calc apparently wants to check the printer to know how to construct its layout, and has to wait for the time-out to continue.
Some of the comments that claim that Calc hangs and never returns have probably not waited long enough for the timeout.
On my new Windows 11 computer, this printer system behavior has been changed and I no longer experience a delay while opening Calc."
If you've ever given answers to that in another comments on HN or elsewhere, feel free to link.
Plenty of graduates simply got into to it to make money, and have no real deep interest. Some of them love the theory but hate the practice. And some of them are good at both of course.
By contrast, self taught people tend to have personal interest going for them. But I've also worked with self taught people who had no real understanding (despite their interest), and who were satisfied if something just worked. Even if they are motivated to know more, they are often lacking in deeper theoretical computer science (this is a gap I've had to gradually fill in myself).
Anyway, the determining factor is rarely exactly how they acquired their skills, it's the approach they take to the subject and personal motivation and curiosity.
There are many college educated software developers who have that sort of drive (or passion, if you will) and there are just as many who don't, it's not something college can teach you, and the same is true for self-taught developers.
At the end of the day "self-taught" is also a spectrum that ranges from people who created their first "hello world" React app 2 months ago to people who have been involved in systems programming since they were 10 years old, and have a wealth of knowledge in multiple related fields like web development, systems administration, and networking. That's why I think it's silly to generalize like that.
Software development is extremely broad so depending on the discipline self-taught developers might not be missing anything essential, or they might have to learn algorithms, discrete mathematics, linear algebra, or calculus on their own. I learned all of that in college but I'd probably have to learn most of it again if I really needed it.
Guess it makes sense; I'm self taught myself, but thought academically taught developers should have a leg up in theory and mathematics, at the same time though, at one point I considered further formal education for myself (in at least paid courses and such), I realized that I don't think there's much I can't teach myself with the resources available (which includes high quality university lectures which are available for free).
Thanks for your perspective.
I have a Master's in Economics. After 3 years of economics, I started a Master's program in maths (back then the Master's degree was the standard thing you achieved after 4.5–5 years of studying in my country, there was basically nothing in-between high school and that). 9 years later I got a PhD in mathematical analysis (so not really close to CS). But I've been programming as a hobby since late 80s (Commodore 64 Basic, Logo, then QBasic, of course quite a bit of Turbo Pascal, and a tiny bit of C, too). I also read a bit (but not very much) about things like algos, data structures etc. Of course, a strong background in analysis gives one a pretty solid grasp of things like O(n) vs O(n log n) vs O(n^2) vs O(2^n). 9 years ago I started programming as a side job, and 2 years later I quit the uni.
I lack a lot of foundations – I know very little about networks, for example. But even in our small team of 5, I don't /need/ to know that much – if I have a problem, I can ask a teammate next desk (who actually studied CS).
Of course, _nemo iudex in causa sua_, but I think doing some stuff on the C64 and then Turbo Pascal gave me pretty solid feeling for what is going on under the hood. (I believe it's very probable that coding in BASIC on an 8-bit computer was objectively "closer to the bare metal" than contemporary C with all the compiler optimizations.) I would probably be able to implement the (in)famous linked list with eyes closed, and avoiding N+1 database queries is a natural thing for me to do (having grown up with a 1 MHz processor I tend to be more frugal with cycles than my younger friends). Recently I was tasked with rewriting a part of our system to optimize it to consume less memory (which is not necessarily an obvious thing in Node.js).
Another teammate (call them A) who joined us maybe 2 years ago is a civil engineer who decided to switch careers. They are mainly self-taught (well, with a bit of older-brother-taught), but they are a very intelligent person with a lot of curiosity and willingness to learn. I used to work with someone else (call them B) who had formal CS education (and wasn't even fresh out of a university, it was their second programming job, I think), but lacked general life experience (they were 5-10 years younger than A), curiosity and deep understanding, and I preferred to work with A than with B hands down. For example, B was perfectly willing to accept rules of thumb as a universal truths "because I was told it was good practice", without even trying to understand why, while A liked to know _why_ it was a good practice.
So – as you yourself noticed – how you acquire knowledge is not _that_ important. IMHO the most important advantage of having a formal CS education is that your knowledge is more likely (but not guaranteed!) to be much more comprehensive. That advantage can be offset by curiosity, willing to learn, some healthy skepticism and age. And yes, I think that young age – as in, lack of general life experience – can be a disadvantage. B was willing to accept even stupid tasks at face value and just code his way through them (and then tear the code apart because it had some fundamental design problem). A, as a more mature person, instinctively (or maybe even consciously) saw when a task did not fit the business needs and sometimes was able to find another solution which was for example simpler/easier to code and at the same time satisfied the actual needs of the customer better.
My personal anecdotes, which are music centric but all apply to my software career:
1. I've studied music my whole life, and baked into music is the idea of continual practice & improvement. Because of this experiential input, I believe that I can always improve at things if I actively put a bit of energy into it and show up. I believe it because I've put in so many hours to it and have seen the results. This is deeply ingrained.
2. When I picked up bass in high school, I spent the first year learning tabs in my bedroom. It was ok, but my ability accelerated when I started a band with my friends and had to keep up. I really think the people you surround yourself with can: push you more, teach you things you didn't know, and make the process way more of a fun hang than doing it by yourself.
3. Another outcome from music education was learning that I really love how mastery feels. There's a lot of positive feeling from achieving and growing. As a result, I try to seek it out in other places as well. I imagine sports/etc are the same?
"Programming" consists of an insanely large number of isolated communities. Assuming the respective person is capable, I would assume that he simply comes from a very different "programming culture".
I actually observe a very related phenomenon for myself: the more I learn about some very complicated programming topics, the more "alien" I actually (start to) become to the programming topics that I have to do at work.
That said, I have also worked with brilliant people who had no formal education in the subject whatsoever, they just really, really liked it.
I’m biased towards ops because that’s what I do and like, but at least in that field, the single biggest green flag I’ve found is whether or not someone has a homelab. People can cry all they want about “penalizing people for having hobbies outside of their job,” but it’s pretty obvious that if you spend more time doing something – even moreso if you enjoy it – you will learn it at a much faster rate than someone who only does it during business hours.
I am an old-school developer with a computer engineering degree but many of the old famous devs were self taught. Yes, if you learn how to code through online courses you will miss some important fundamentals but those are possible to learn later and I know several people who have.
We have excellent metrics between PMM and AWS Perf. Insights / Enhanced Monitoring. I assure you, on-disk temp tables were to blame. To your point, though, MySQL 5.7 does have a sub-optimal implementation in that it kicks a lot of queries out to disk from memory because of the existence of a TEXT column, which internally treated as a BLOB. Schema design is also partially to blame, since most of the tables were unnecessarily denormalized, and TEXT was often used where VARCHAR would have been more appropriate, but still.
Trust me so much, some of the stuff I learned there was actively harmful. Half of subjects were random fillers, and so on.
I envy Americans so much with that, their CS education seems to be top notch.
...and by then, the requests for performance are somewhere between onerous and ridiculous.
I'm as wary of premature optimization as anyone, but I also have a healthy fear of future-proofed sluggishness.
"It's written in Python and not e.g. in Rust" is simply not relevant in that context.
(For that matter, when uv is asked to pre-compile, while it does some intelligent setup for multiprocessing, it still ultimately invokes the same bytecode compiler - which is part of the Python implementation itself, written in C unless you're using an alternative implementation like PyPy.)
Of course, not always the case. C++ is a good counter example with a massive range of performance "orientedness". On the other hand, I suspect there are few Rust / Zig or C programmers that don't care about performance.
On the flip side, I've seen quite a few C developers using their own hand-rolled linked lists where vector-like storage would be more appropriate, without giving it a second thought. Implementing good hash tables from scratch turns out not to be very much fun, either. I'm sure there are off the shelf solutions for that sort of thing, but `#include` and static compilation in C don't exactly encourage module reuse the same way that modern languages with package managers do (even considering all the unique issues with Python package management). For better or worse.
(For what it's worth, I worked in J2ME for phones in the North American market in the mid 00s, if you remember what those were like.)
Well first off, pip itself does defer quite a few imports - just not in a way that really matters. Notably, if you use the `--python` flag, the initial run will only import some of the modules before it manages to hand off to the subprocess (which has to import those modules again). But that new pip process will end up importing a bunch more eventually anyway.
The thing is that this isn't just about where you put `import` statements (at the top, following style guidelines, vs. in a function to defer them and take full advantage of `sys.modules` caching). The real problem is with library dependencies, and their architecture.
If I use a library that provides the `foo` top-level package, and `import foo.bar.baz.quux`, at a minimum Python will need to load the `foo`, `foo.bar`, `foo.bar.baz` and `foo.bar.baz.quux` modules (generally, from the library's `foo/__init__.py`, foo/bar/__init__.py`, `foo/bar/baz/__init__.py` and `foo/bar/baz/quux.py` respectively). But some libraries offer tons of parallel, stand-alone functionality, such that that's the end of it; others are interconnected, such that those modules will have a bunch of their own top-level `import`s, etc. There are even cases where library authors preemptively import unnecessary things in their `__init__.py` files just to simplify the import statements for the client code. That also happens for backward compatibility reasons (if a library reorganizes some functionality from `foo` into `foo.bar`, then `foo/__init__.py` might have `from . import bar` to avoid breaking existing code that does `import foo`... and then over time `bar` might grow a lot bigger).
For pip, rich (https://pypi.org/project/rich/) is a major culprit, from what I've seen. Pip uses little of its functionality (AFAIK, just for coloured text and progress bars) and it tends to import quite a bit preemptively (such as an emoji database). It's very much not designed with modularity or import speed in mind. (It also uses the really old-fashioned system of ad-hoc testing by putting some demo code in each module behind an `if __name__ == '__main__':` block - code that is only ever used if you do `python -m rich.whatever.submodule` from the command line, but has to be processed by everyone).
And yes, these things are slow even with Python's system for precompiling and caching bytecode. It's uniformly slow, without an obvious bottleneck - the problem is the amount of code, not (as far as I can tell) any specific thing in that code.
Edit: It still might be a bad idea to waste the IO if you do not have to but the latency of a temporary table is usually RAM latency, not disk latency even for temporary tables on disk.
If you’re curious, the EBS disks Aurora uses for temporary storage, when faced with a QD of approximately 240, can manage approximately 5000 IOPS. This was an r6i.32xlarge.
My hypothesis is currently that the massive context switching the CPU had to do to handle the interrupts slowed down its acceptance of new connections / processing other queries enough such that everything piled up. I’ve no idea what kind of core pinning / isolation AWS does under the hood, but CPU utilization from disk I/O alone, according to Enhanced Monitoring, was about 20%.
Have you tried launching a local app by typing in the start menu on a default win11 install with limited / slow internet access? Good times. How about doing some operation (say delete an e-mail) in one window of "new" outlook and having the others refresh?
I have never understood how some otherwise reasonable people are able to consider this absolute shitshow of a work environment good enough.
They refused to store files in directories and use good file names (although they were limited to 8.3), so they just scrolled through all their files until they found the right one. But they could open them so fast they didn't care.
In windows you had to use the mouse, click three times, wait for the document to load and render....it was instant under DOS character mode.
Reveal Codes was an order of magnitude more useful than whatever crap MS continues to pass off as formatting notation to this day 20+ years later, and that's before we even get into Word being over-helpful and getting ahead of you by doing things with autoformat you never wanted to have happen.
Yes, I know WordPerfect is still around, but fat chance being able to conveniently use it anymore.
CUA ~= "standard menus + keyboard shortcuts for dos and windows": https://en.wikipedia.org/wiki/IBM_Common_User_Access
I was hoping to figure out what led to design incompetence so spectacular that people would still be discussing it after 17 years.
I think there’s a clue in the abstract: The author claims they made 25,000 mock UI screenshots, but doesn’t mention user studies or even internally prototyping some of the concepts to see how they feel.
When the accursed ribbon came along, "discoverability" went out the window. Functions were grouped according to some strange MS logic I could never understand, and it takes me twice as long to format a page as it used to. Now, I basically just use Word for text entry, and if I want an elegant format, I use a graphic design app like Illustrator.
Judging from what I've read online, you may be the only person who actually likes the ribbon.
Also traditional menus had some traditional standards. Once you learned what was under "File" or "View" or "Insert" or "Format" it was often pretty similar across applications.
There is no faster discoverability than O(log(N)) search using the letters of the name as a lookup.
The biggest failure of modern operating systems is failing to standardize this innate reality.
Windows,Linux,etc should have 1. keyboard button to jump to search box 2. type 1-2 letters and hit enter. Operating systems and applications should all have this kind of interface.
The most ironic apps have a ribbon named something like "Edit" but then the most used "edit" command lives in an unrelated ribbon.
It wouldn’t be so bad if keyboard navigation was as good as with the classic menus, but having to press the Alt key separately, and general increased latency, kills it.
I think rosy recollection is tainting your memory here. How often docs would get corrupted due to those aforementioned memory safety issues, even if that Win95/98 box was never connected to the internet.
Of course it’s gonna be super snappy. It was designed to run on any Doom-compatible hardware. Which includes some toasters now.
Edit: it’s also worth noting that 1997 was right around the time where Moore’s law succumbed to the laws of physics for improving single-core CPU performance via clock speed alone.
And funny thing, barely uses any memory! Makes todays apps look like monsters. Even my music player uses 5x more memory while paused, then freaking Excel with multiple pages open.
`Omnibook300Intro-5091-6270-6pages-May93.pdf` https://www.hpmuseum.net/exhibit.php?hwdoc=123 sez:
> Built-in ROM applications don't use up disk space
- Microsoft Windows
- Microsoft Word for Windows
- Microsoft Excel
- Appointment Book
- Phone Book
- HP Calculator
- Microsoft File Manager
- LapLink Remote Access™
You are wildly off base. The algorithms aren't difficult or special. They were written by people reading text books for the most part.
They are able to sit on an on old algorithm for decades because the DMCA made interoperability and selling cheaper tools like that basically illegal.
Because of the DMCA, the work that was done to make IBM PC clones would have been close enough to illegal to kill all the businesses that tried it. They still tried with the liberal IP laws at the time.