Yeah, it’s pretty frustrating that software has seemingly gotten as wasteful as it has. I think this is a consequence of the power of abstraction – we’re building on the shoulders of giants on the shoulders of giants. That silky smooth text editor on a 286 was essentially 100% bespoke, with every line of code contributing. Now our text editors are built with GUI toolkits and powerful, yet general purpose edit controls…so we drag in all sorts of stuff that we don’t need. This is the sacrifice we make at the altar of code reuse.
Whether or not this is a good thing is up for debate. But I think it’s unavoidable with the particular combination of software demand, economies of scale in hardware, and labor pool that we have in this world we’re stuck with.
It sounds like the challenge going forward is collapsing these towers of dependencies. Like the Zen of Python says:
Flat is better than nested.
Flat is better than nested.
There are different scales of tradeoff in code reuse, though. Very often, using some third-party library takes more effort than implementing the facilities you were going to use with builtin facilities (particularly if you’re working in a language with a feature-rich standard library, like python) – and this problem gets worse the more bloated the library is. We buy into some framework because of flashy features we will never use, then waste a lot of time learning the framework’s special ways of doing things, and in the end the code we wrote is unportable and the sunk cost fallacy keeps us from doing the sensible thing & throwing it out.
The most irritating thing, for me, is that good-enough performance isn’t very hard for most common tasks & doesn’t require any special knowledge. If you write something in python and you do it in the most straightforward way possible, with no particular emphasis on optimization, it’s still going to be hard to make it too slow (the example in the post about a python command line script running for 1.5 seconds is sort of absurd, unless it’s doing a bunch of complex math without the help of numpy). Even so, basically everything we use – including most common open source applications – are substantially slower than the minimum acceptable performance, for no clear & defensible reason.
You can make a milky-smooth text editor in about three lines of python – Tk ships with a fast & powerful text widget that does about 90% of what you want from a rich text editor. In other words, it’s literally easier to make it fast than to make it slow, so long as you are willing to avoid being sucked into dumping cycles into unnecessary facilities.
Bouncing off of your statement about text editors, I suggest you check out Kakoune, it’s a modal code editor that packs a punch.
Thanks, I actually gave it a try recently. I’m a recent convert from emacs to sublime and miss the ability to use my editor over an ssh session. I like everything about kakoune but the modal editing is a tough change for me. If kakoune was made as a modern emacs rather than vim it would have been an instant win for me!