Whenever I tell people that I'm working on a brand new development platform called ioL, the first question I often hear is 'why?', 'what's wrong with the way things are now?', or even 'why would you want to re-invent the wheel?' In recent years, computers have gone from being niche novelties to mainstream devices that everyone keeps in their pockets. The industry seems to be going from strength to strength. So here's a post about negatives. I'm going to spend the next several paragraphs complaining about the state of computing today, and discussing where I believe the room for improvement lies. You've been warned.
There's no longevity in code
Consider the direction operating systems have been headed lately, and the way in which software distribution has become increasingly centralised. Now ask yourself: where is the fun in writing an app (or getting into programming for the first time), when you can't easily share your work with your friends without first publishing it in a tightly-regulated app store? Where is the incentive to create a masterpiece, when the life-span of a typical app is limited to the current OS version that it supports? Large software corporations can afford to continue updating applications so that they continue to work on new system releases. The works of independent developers are simply forgotten. The art of coding has become devalued as expendable in the eyes of the software industry to the point that it is now typically outsourced.You might ask why anyone would be interested in running old applications. How do traditional media formats compare? Would movies such as Star Wars have become enduring classics if they had required regular revisions to keep them watchable? Perhaps that was a bad example. What about Citizen Kane? Books, movies, songs, even radio plays endure and become classics because they are permanent works. Interactive works (no less culturally significant) don't endure, because they are typically not built on firm foundations. Although writers of software engineering textbooks invariably advise against tightly coupling your code modules to dependencies that change outside your control, this is often the only way to do things on modern operating systems.
There are some exceptions: interactive works that have endured. The first ever website, created in 1991, is still online, and still functions perfectly in a modern web browser (even if it does look a little dated). Websites endure because they are not coupled to a particular web browser implementation. Instead, a web server outputs the page in an intermediary language (HTML) consisting of text-based content punctuated by formatting instructions. A web browser doesn't need to interface directly with a web site's implementation. It only needs to interpret the HTML code well enough to produce a good-enough result. The use of an intermediary layer of interpretation has worked wonders in the database world too. Rather than attempting to mesh with the gears of a database system directly, today's business information systems send their queries in Structured Query Language (SQL), to be interpreted by the database system. This kind of approach has to be the way forward.
There's no variety either
Today's modern operating systems typically lock you into writing your app in a particular programming language. If you're writing for Android it's Java. If you're writing for iOS it's Objective C. The locked-down nature of these systems is understandable. They are feature-rich systems and it would seem that an app needs to be tightly coupled to the host system's programming interface in order to integrate well.Early operating systems were far more rudimentary. A program's user interface was a bunch of green fixed-width characters on a dark-grey phosphorescent screen. As the program produced new output, old output would scroll off the top of the screen. User interaction was done by waiting for the user to type a string of characters and press the enter key. The user experience wasn't much, but the upshot was simplicity. The elegant nature of a simple computing model led to programs that were robust and easy to test. The only standard facility a programming language had to provide was the ability to 'print' a string of characters to an output stream (the terminal screen) and read characters from an input stream (the user's keyboard). There was a plethora of competing programming languages to choose from, representing different coding paradigms suitable for different kinds of applications, and different coders' preferences. The coder's choice of language rarely mattered to the end user. Innovation in programming languages was a happening thing. The locked-down nature of modern operating systems has put a freeze on that kind of innovation.
Today's operating systems still support the so-called standard-input and standard-output streams, though their use has remained relegated to providing the old style of input and output via a rudimentary terminal window. All programming languages continue support standard input and output, even though the terminal output is now often hidden from view. There is still a variety of programming languages to choose from (for those who are happy to write text-based programs that run in a terminal window), and novices are often taught to write text-based terminal programs first, because the standard input/output paradigm remains an easy model to grasp. Of course they are then discouraged by the fact that their programs don't look anything like 'real' graphical apps.
It's not all about fun or games
The writing of robust computer software free of interoperability issues remains one of the great unsolved problems of software engineering. Even today, multi-million-dollar software engineering projects go massively over time or over budget because of unforeseen regression faults in the software, promoted by tightly-coupled dependencies in the host system. It can often become cheaper to retire systems rather than maintain them (even before they are complete), because the relationships between different code modules and dependencies simply become too complicated to work out.Programming education is more accessible than ever before, but perceived barriers to entry imposed by system vendors drive enthusiastic novices away. Modern operating systems are increasingly geared for users to consume rather than produce. Tightly-coupled dependencies imposed by system vendors discourage the development of new programming languages (is object-oriented programming as far as we go?), and the inherent lack of a firm foundation on which to create an enduring work, can destroy a programmer's motivation to build a quality product.
Some of the problems I have touched on may seem daunting. You might even argue that many of them are necessary side-effects of the direction computing has taken. However, the success of the decoupled nature of the web has demonstrated that such problems are certainly solvable.
