Though binary code is conceptually simple, its use to perform computerized tasks introduces two drawbacks.
First, binary code is a relatively inefficient way to express information.
In computer applications, binary code is even more inefficient because computerized information is, by convention, typically expressed in multiples of 8 bits, e.g. 8-bit, 16-bit, 24-bit, etc.
A
computer program operating in binary code may therefore use a tremendous amount of storage space and processor cycles, particularly when
graphics are involved.
In addition, there are many other computer applications that are at least as intensive as
image processing.
Applications of such intensity tend to slow considerably as data is “bottlenecked” in the computer
system.
Still, while these numbers are impressive, computer systems are not sufficiently fast as to eliminate all bottlenecks, and in fact, as computers become faster with more available storage, new applications are developed to take
advantage of the improved technology so as to provide the need for even faster computers, even more storage space, etc.
A second drawback of using binary code to perform computerized tasks is that it is impractical to write a computer program in binary code, particularly with complex programs.
Beyond that point,
programming directly in binary code became too complex, and programs too difficult to correct, or debug.
Writing this same program in binary code not only would have required much more time and effort on the part of the
programmer, but the
programmer also would have had to know the
technical specifications of the computer processor.
Once again, however, the increasing complexity of computer programs exposed an underlying flaw of “C” as well as its predecessors.
In fact, writing such a program is similar to constructing a geometric proof, and like a proof, once a program such as C or FORTRAN exceeds a certain number of steps (somewhere between 25,000 and 100,000 lines of code), the program becomes too complex write effectively.
This often becomes problematical, however.
Recall that even with today's processors and storage devices, a computer's resources may still be strained by intensive applications.
With multiple
Java applications running simultaneously, each creating its own VM, system resources may be strained and slowdowns may result.
Thus, while the “guts” of each VM will of necessity be different across each platform, a user of a
Java VM was not intended to be able to recognize any difference, seeing the same functionality regardless of the host platform.
This, however, became problematical.
This diversity among
Java VMs tends to hinder the improvement of the Java VM and the
programming language because many such improvements are tied to the particular species of Java VM upon which the improvement was developed.
Many businesses may like the particular improvement, but dislike other aspects of the Java VM.
Exacerbating this problem is that the new improvement may be proprietary, thus eliminating the second option.