LWN: Comments on "Distribution quote of the week"

Distribution quote of the week

Wol — Wed, 07 Jul 2021 18:19:07 +0000

> But what if you take the techniques you learned from programming with 640k of RAM, and apply that to programs which are not constrained by RAM?

Then your program becomes much more efficient. And it's not just RAM that is constrained. To quote the Pick FAQ, "SQL optimises the easy task of finding data in memory. Pick optimises the far more difficult task of getting it into memory". Okay, SSD's have now negated that to some extent, but Relational is wasteful of space.

Then, if your program is wasteful of instruction code, you're going to start crashing into cache lines and page faults and L1/L2/L3 memory limits.

And as I mentioned earlier, it wasn't 640KB, for me it was 256KB - shared with twenty other users of the same computer!

And then, what happens if - and it does happen today, still - you get asked to program something that crashes into hardware limits. In my early programming days I regularly ran into jobs that took a LONG time to run. Too long ...

And haven't the kernel developers just recently learnt that caching the disk ACTIVELY HARMS the not uncommon case of copying files? They didn't care about wasting "spare" ram, and it's come back and bit them in the bum ...

Cheers,
Wol

Distribution quote of the week

excors — Wed, 07 Jul 2021 14:49:28 +0000

> Nevermind limited RAM usage; we've forgotten way more than that. There's this talk[1] which discusses how the things we had in the late 60's and early 70's have just been…forgotten these days. In 1968 or so, there was handwriting recognition.

I guess that's referring to the RAND Tablet. Apparently [1] the tablet cost $18K to build (in 1964 prices; equivalent to about $150K today), plus you needed exclusive use [2] of an IBM System/360 Model 40 (which cost another $18K/month to rent; it had up to 256KB RAM and could do 32-bit additions at ~0.13MHz).

It recognised uppercase letters and numbers, and some special symbols and the 'erase' gesture. It was purely an input device, not a touchscreen, so you had to look at a separate monitor to see what you were drawing. According to [3], after a half-hour training session the average recognition rate was around 90%.

From [1]:

> The device did not catch on commercially, perhaps because of inertia in user habits and familiarity with a keyboard; perhaps, as is true for many R&D successes, the world was not ready for this very different way of communicating with a computer; or perhaps commercial interests did not perceive applications that would require and exploit the tablet capabilities.

but to me it sounds more like perhaps the world was not ready to spend the equivalent of several people's annual wages on an input device that had fairly high error rates and, even if it worked perfectly, was much slower than a keyboard for writing large amounts of text, and worse than a mouse for selecting things on the screen. Those compromises only became worthwhile much later when they let us sacrifice the bulky keyboard+mouse and make computers small enough to fit in your pocket. (The System/360 Model 40 weighed literally a tonne.)

Palm's Graffiti input system was on the Pilot 1000 in 1996, which had similar RAM to the System 40 (128KB) though a lot more compute power (with a 16MHz 32-bit CPU), and cost $300. Graffiti required users to write in a weird single-stroke-per-letter alphabet, presumably to increase speed and accuracy. A study [4] says experienced users still had a 9% error rate compared to 2% with the virtual keyboard, though they could write slightly faster with Graffiti (21 words per minute) than the virtual keyboard (18 wpm). That study also measured pen and paper with normal printed letters, getting about 27 wpm.

A study on modern smartphone users [5] reports an average speed of 36.2 wpm with an error rate of 2.3%, using virtual keyboards with autocorrect and word prediction. That's decent accuracy, and much faster than any handwriting-based system. And in cases where you really do need to recognise handwriting (e.g. the postal service automatically routing mail), the modern compute-intensive deep learning algorithms push the accuracy to >99.8% with diverse untrained handwriting [6], which is totally infeasible with the old pattern recognition algorithms.

So I'm not sure it's fair to say the 60s research has been forgotten as an indictment of the modern world. It was an interesting proof of concept but it seems it wasn't a good fit for the hardware of the time, and by the time the hardware had caught up, there were much more sophisticated solutions that gave better results. The early research was largely forgotten because it had been superseded by later research and was no longer relevant.

[1] https://www.rand.org/content/dam/rand/pubs/corporate_pubs... (page 98)
[2] https://www.rand.org/content/dam/rand/pubs/research_memor...
[3] https://www.rand.org/content/dam/rand/pubs/research_memor...
[4] https://journals.sagepub.com/doi/abs/10.1177/154193120204...
[5] https://userinterfaces.aalto.fi/typing37k/resources/Mobil...
[6] https://en.wikipedia.org/wiki/MNIST_database

Distribution quote of the week

mathstuf — Wed, 07 Jul 2021 12:13:54 +0000

Nevermind limited RAM usage; we've forgotten way more than that. There's this talk[1] which discusses how the things we had in the late 60's and early 70's have just been…forgotten these days. In 1968 or so, there was handwriting recognition. Sure, probably only for the Latin alphabet and tuned for the developer's style, but recognition none the less. It also had gesture and object recognition (e.g., scribbling out a line to mean deletion or recognizing a box as such and making it such instead of only hand-drawn). All of that without fancy ML techniques or massive GPU training runs. And they were responsive too.

[1]https://vimeo.com/71278954 Bret Victor's "The Future of Programming"

Distribution quote of the week

immibis — Wed, 07 Jul 2021 10:30:11 +0000

Indeed, people want to edit 100MB bitmap files today, and that's simply impractical with 640k of RAM.

But what if you take the techniques you learned from programming with 640k of RAM, and apply that to programs which are not constrained by RAM?

Distribution quote of the week

Wol — Sat, 03 Jul 2021 19:19:49 +0000

If your mini has virtual memory backed by 256KB of real ram, then you're free to use what you need but you'll still get crucified by everyone else if you're wasteful.

But it's more the disciplined mindset that's useful.

Cheers,
Wol

Distribution quote of the week

Wol — Sat, 03 Jul 2021 19:16:01 +0000

No. Your lighter machine part comes with all the scurf attached such that you can't remove it. The amount of crud and cruft modern programs carry that comes along as part of the toolkit is amazing. Your typical embedded engineer could probably write the program using our modern toolkits, then reduce its size 10- or even 100-fold by aggressive stripping of unused code. Your normal programmer probably wouldn't even know where to start doing that ...

Cheers,
Wol

Distribution quote of the week

ghane — Sat, 03 Jul 2021 14:27:29 +0000

True, but *he* pays the price of the one-time hardware and software stack, and I (and millions more) have lower resource requirements, with cheaper hardware.

It is like you buying an expensive CNC machine; each part that I buy is cheaper and lighter.

--
Sanjeev

Distribution quote of the week

gerdesj — Sat, 03 Jul 2021 00:34:31 +0000

"We have much better tools now than 30 years ago, though."

Your better tools seem to need an insane amount of resources to do things. In Civ Eng terms, I'll need a bucket the size of Mars to move a few tonnes of conc from A to B.

Distribution quote of the week

rodgerd — Thu, 01 Jul 2021 22:23:53 +0000

It's a great foundation, but it can also lead to focusing on the machine's needs over the user's - which was very understandable when we had 48k of memory, not so much now.

Distribution quote of the week

excors — Thu, 01 Jul 2021 17:25:25 +0000

> That's an interesting quote because it describes how programming looked like 30+ years ago. All programming. It used to be *normal*. I still kinda remember these times, though I was only doing toy programs then. And I still try not to forget the lessons I learned then and not be spoiled by GBs of RAM etc.

We have much better tools now than 30 years ago, though. You can do embedded development on modern microcontrollers with 10 or 100 times less RAM than FreeDOS's 640KB requirement, using languages and libraries that are type-safe and mostly memory-safe, with RAII and nice generic collection types and iterators and no ugly C preprocessor macros, and you can write efficient platform abstraction layers so the code is portable to different devices and can be unit tested and fuzzed and profiled, and so on. You still have to be constantly thinking about memory usage and code size etc, and have to be very careful about which features and libraries you use, but once you understand it the modern tools let you write better-quality code and more sophisticated programs with less wasted effort.

I agree that it's both fun and educational to try writing code under those challenging constraints, where you need a deep understanding of the hardware limitations and precisely what your code is doing, but I don't think writing C programs for DOS is the best way to approach it for most people. It's more productive and more fun if you try to apply more state-of-the-art development practices. And using DOS is a needlessly artificial constraint, whereas there's plenty of real products being designed today where the hardware constraints are necessary (e.g. to minimise power consumption) but you have total freedom over the software, so you can either get a career building those products or be a hobbyist who hacks those products to run your own code, and rather than be stuck in the past you can try to advance the state of the art in that field.

Distribution quote of the week

Wol — Thu, 01 Jul 2021 15:39:46 +0000

And if it wasn't a PC, but a multi-user system (like most systems back then, like the system I learnt on), if you were profligate with resources you upset everybody else in the office because THEIR stuff started running slow.

Cheers,
Wol

Distribution quote of the week

jezuch — Thu, 01 Jul 2021 15:25:09 +0000

That's an interesting quote because it describes how programming looked like 30+ years ago. All programming. It used to be *normal*. I still kinda remember these times, though I was only doing toy programs then. And I still try not to forget the lessons I learned then and not be spoiled by GBs of RAM etc.