Despite the formal equivalence of all computers, some may be better-suited to a given task than others. Similarly, most computer languages are designed to facilitate certain operations and not others: numerical computation, or text manipulation, or I/O. More broadly, a computer language typically embodies a particular programming paradigm. More than just a collection of features, a paradigm is a way of thinking about problems and their solutions, and an approach to using computers to implement those solutions. Three important paradigms are described below.
In this kind of work, algorithms are permanent and data is transient. Each algorithm represents a large investment in scientific and programming effort. The algorithm is kept on, or near, the computer. Users bring their problem to the computer, run the algorithm, and then leave with their results.
Programming languages that are primarily designed to express algorithms are called procedural languages. They include FORTRAN, Algol, C and Pascal.
In business applications, data is permanent and algorithms are transient. A firm's data, coded and recorded on a computer system, represents an enormous investment. This collection of data is called a database, and is carefully tended and protected. Small algorithms, called transactions, come to the database, execute, and leave. For example, each time you take money out of an ATM, a transaction operates on a database to debit your bank balance.
Conceptually, a database and its transactions are simpler than the mathematics that underlie much algorithmic programming. However, database programming involves complex and subtle issues, and is often more difficult than algorithmic programming. Programming languages that are designed to manage databases are called database systems. On PC's, the most widely used database system is DBase. On Unix systems, many people use Sybase.
Many different user interfaces have been tried. One of the most successful is the graphical user interface (GUI). This is the kind of interface provided by the Macintosh, Motif, Tk, and Microsoft Windows. It includes a mouse and a graphical display, with windows, menus, dialog boxes, scroll bars and so on.
You can move a window on the screen, just as you can move a piece of paper on your desk. Clicking in a button on the screen makes something happen, just like pushing a button in an elevator. Things on the screen only move if you move them, just like things in the real world.
Most users consider GUIs to be simple and natural. They're half right. A GUI is natural, in that it embodies properties of the real world. However, those properties are not particularly simple. The reason that people find GUIs easy to use is that the human brain has evolved to function in the real world. By mimicking the real world in certain ways, a GUI can leverage the power of the human perceptual system, thus making the functionality of the application easily accessible to the user.
Strictly speaking, a GUI is an algorithm. It accepts input and generates output. However, the input comes from a human, and is therefore very complex. The user could click and then type, or type and then move the mouse, or open one window and then close another, or insert a disk, etc., etc. A GUI must behave correctly and consistently no matter what the variety and sequence of user inputs. A single algorithm to do this would be very complex.
Alternately, a GUI can be viewed as a database. The database contains all the information about the things on the screen: positions and contents of windows, fill patterns and colors, cursor shape, etc. Each user action invokes a transaction that alters some of the data. The problem here is that the data in a GUI is ill-suited to a database system. There isn't very much of it, but what there is tends to be varied and complex. Database systems are better at handling large, homogeneous datasets, such as the names and social security numbers of all US citizens.
OOPS are well-suited to programming GUIs. Typically, each element of a GUI is represented by one object. The object determines both the state and the behavior of the corresponding element. For example, an object representing a window would have data for its position, size and title. If the user closes the window, the OOPS sends a message to the window object telling it to close itself. The window then executes an algorithm that erases its image from the screen.
In principle, the same thing can be done in a procedural language. However, for technical reasons, it is more difficult, and it very often corrupts the original design of the program, leading to unmanageable complexity.
Unfortunately, C is a procedural language and C++ is an OOPS. There are profound differences between these two paradigms, and trying to include both in a single language leads to many difficulties.
Technically, object libraries are quite feasible, and the advantages of extensibility can be significant. However, the real challenge to making code reusable is not technical. Rather, it is identifying functionality that other people both understand and want.
People who use procedural languages have been writing and using subroutine libraries for decades. These libraries are most successful when they perform simple, clearly defined functions, such as extracting square roots or computing trigonometric functions.
An object library can provide complex functions more easily than a subroutine library can. However, unless those functions are clearly defined, well understood and generally useful, the library is unlikely to be widely used.