Big is the new big

For PCs, big is the new big. It wasn't always this way.

When the PC revolution started, small was big. The advantage of PCs was smallness, in size, in cost, and in effort. PCs were small enough to fit on a desktop, cheap enough to be purchased as "word processors" (to avoid the data processing bureaucracy), and easy enough that one person could operate them.

The programmers of the PC revolution took pride in the smallness of hardware and of programming languages. BASIC, the original language of the PC revolution, could fit on a computer with 8K of RAM. (That's 8192 bytes.) Other programming languages were also small. Even the names emphasized smallness: Tiny-C, Tiny-Pascal.

We rebels of IT considered "big" an aspect of mainframe systems, and associated "big" with slow, lumbering processes that hindered productivity. The Agile movement was defined as the opposite of "BDUF" (Big Design Up Front). Big was what we did not want our systems to be.

Yet something has changed. We no longer want to be small. Now, we want to be big.

Notice the (now decade-old) desire for "big data". That was a full embrace of bigness. There was also "big analytics" which analyzes large datasets.

Other things have become big. Databases have become big. Spreadsheets have become big. Word processors have become big. Our PCs are not stand-alone systems, but nodes in a larger system and reliant on that system for authentication, updates, and basic processing.

Programming languages have become big, with C++, Java, Python, C#, and Visual Basic in the top slots of the Tiobe index for October 2020. The top position is held by C. While some consider C a small programming language, I have my doubts. C uses a small set of keywords, but has a large standard library. It may not be large, but it isn't small.

We have lost our desire for small systems. Our smart phones are physically small, yet their operating systems are complex and app development is for professionals. Even small hardware systems such as the Raspberry Pi run a full Linux distro, which requires a fair amount of administration.

The only small systems are the Arduino and similar systems, which run a slim monitor operating system and are designed for hardware control, not general-purpose computing.

Perhaps we were deluding ourselves. Perhaps we wanted large systems all along. We craved the power of fast processors, ample memory, and disk space that was not limiting -- that much is certain. Perhaps the cost of faster processors, more memory, large disk space, and interconnected systems is bigness. Perhaps it is not possible (or not cost-effective) to operate small systems loosely coupled.

Perhaps.

But perhaps the desire for small, simple systems remains, and perhaps, one day, it will resurface.