Windows 1.0 and the Applications of Tomorrow (2005)

Having gone through a few cycles in language changes, I look forward to the day C is drinking its retirement tea together with PL/I, and the industry finally understood the path taken by the Algol/Mesa/Cedar languages for memory safe systems programming.

It might take a few generations, but it will happen.

The same way it did to many of my fellow developers that saw C and Pascal dialects as high level bloat.

I just recently debated a colleague on the merits of AltJS languages. He's of the opinion that Javascript is all we need and is happy to be a "Javascript assembly programmer" for the foreseeable (and perhaps unforeseeable) future.

There is a significant difference between the asm/C jump and the C/managed jump though- even though early C compilers had a performance penalty, the C language semantics are very amenable to optimization and the cases where you could do better in asm are pretty rare.

Your typical dynamically typed, garbage collected scripting language, on the other hand, is not very nice to optimize. It may be "good enough," but there's plenty of good reasons people still start new projects in C++, and there's a reason for the recent resurgence of more static languages like Go, Julia, Swift, Rust, etc.

I've been writing apps for computers since 1978, and I'm seriously horrified by bloat. It appears to be an unstoppable force, however, so these days I'm mostly interested in ways to harness bloat. I believe this is also a principle activity of my peers.

I'm not. I don't miss the days of manually copying data from the floppy drive buffer into the screen device, or word processors writing out bitmaps to print heads.

Some people see bloat. I see not having to care if a file-like object is coming from my hard drive, a URL retrieved via HTTP, a network filesystem, or an in-process fake file generator because they all look exactly the same to the apps I'm writing.

Abstraction is inherently expensive. If you want to support printer A and printer B, the common driver interface has to support the union of both their featuresets. A's driver will be bigger than it has to be because it has to handle stub calls for B's functions. Know what? Having lived the alternative, I have zero desire to ever go back.

Back in the day, I spent weeks writing a basic DOS-based windowing framework for one of my applications. Today, an equivalent (well, vastly more powerful) framework comes out of the box with 3 clicks of the "create a new app" wizard on just about every platform out there.

I also spent weeks, if not months, fine-tuning my apps so that they would run at a sensible speed on the hardware we had, would fit into the 500K or so of RAM that was available, and would pretty much never crash as issuing a patch involved me manually copying hundreds of floppy disks and posting them to clients.

Modern hardware/OSs/languages may be far less efficient in their use of CPU/memory etc, but they allow me to be far more efficient in the use of my time to deliver actual functionality to users.

It probably helped that I played RTS and FPS for years, lol.

http://en.m.wikipedia.org/wiki/File:Bundesarchiv_B_145_Bild-... shows a desk that is way larger than the typical desk one had at home, with its separate tray for the keyboard.

Even if you had such a desk, that tray doesn't have room for a mouse.

Edit: also, mice were terribly unresponsive. You had to move the mouse for decimeters to get from one edge of the screen to the other, even if that screen had only 640 pixels.

Desks weren't necessarily small, but the amount of paper, paper handling and organizing equipment on the typical office desk was unbelievable to the modern office worker.

http://www.devoncornwallexecutive.co.uk/wp-content/uploads/2...

http://www.bbc.co.uk/northyorkshire/content/images/2008/06/2...

http://www.sundaynightimprov.com/files/images/Tom2.preview.i...

Actually, if you want to see a modern version of this, the Japanese have kept the paper office alive and well.

http://www.accountant-tokyo.com/wp-content/uploads/2014/04/J...

Can't remember exactly what it was, but this was Ireland in mid 1980s and the hardware was already pretty creaky so some low end model from the 1970s. Print jobs were formatted by placing a loop of punched paper tape on two sprocket wheels before sending the job request to the mainframe, and offline storage was to giant vertically-mounted spinning tapes. Our department's prize possession was a 286 with a 10mb hard disk, which was what I learned DOS on. I got told off for installing Desqview without permission XD

Having recently switched to Linux, I've been astonished that some X applications seem to require the use of a mouse, and that many graphical environments don't have default keyboard shortcuts assigned to certain tasks. At least it's much easier to create and redefine shortcuts, and you can always open a terminal and type in the full commands as needed.

This is one of the things that's very annoying about applications that hide the menubar or lack a menubar entirely. Cycling through menubar options with a keyboard is far, far more efficient than attempting to use a keyboard with many of the poorly-thought-out experimental UIs that seem to be increasingly prevalent.