Enterprise Software and Cross-Platform Pain

By the late 1980s, the computer industry looked nothing like the mainframe world of a decade earlier. Personal computers sat on desks. Servers hummed in back rooms. Networks connected branch offices. And businesses wanted software that did things people had never asked computers to do before: track every customer, manage every shipment, balance every account, in real time, in every store in every country.

This is the era of enterprise software, and it changed what programmers needed from a language.

What "enterprise" really means

When we say enterprise software, we are not just talking about "software for a big company." We are talking about programs that have these uncomfortable properties:

• They live for decades, often outlasting the people who wrote them.
• They are huge — millions of lines, hundreds of programmers.
• They run on a zoo of different machines: Windows PCs, Sun workstations, IBM mainframes, Mac desktops, eventually phones.
• They must be reliable: a crash in a banking system is not just annoying, it costs money or breaks the law.
• They must be secure: they hold data that other people would love to steal.

If you write a payroll system in one language for one kind of computer, you might have to rewrite it for every other kind of computer the company uses. For a big enterprise, that meant maintaining several near-identical codebases. Imagine fixing the same bug in five places, in five slightly different programming languages.

C++ — almost the answer

In the early 1980s, Bjarne Stroustrup at Bell Labs created C++, which added classes and objects to the wildly popular C language. C++ was a huge step forward:

• It was fast (it compiled directly to machine code).
• It had classes, inheritance, and (eventually) templates.
• It worked on every platform that C worked on, which was everywhere.

For a while in the late 80s and early 90s, C++ looked like the future of all serious software. But it had two problems that grew sharper as enterprise programs grew larger.

Problem 1: portability was a fantasy

In theory, you could compile the same C++ source code for Windows, Mac, and Unix. In practice, every platform had different libraries, different conventions, different sizes for built-in types, different ways of opening windows, reading files, drawing pixels, talking to the network. A serious C++ program for Windows shared maybe 60% of its code with the Mac version. The other 40% was platform-specific.

Every platform required a separate build, separate testing, separate release. For a global company shipping to 20 platforms, this was ruinously expensive.

Problem 2: manual memory management

In C++, the programmer was personally responsible for every byte of memory: asking the operating system for it with new, giving it back with delete, never forgetting, never giving it back twice, never using it after returning it. Forgetting to free memory caused memory leaks (the program slowly bloats until it crashes). Returning memory twice or using it after freeing it caused undefined behavior (the program might crash, or do something worse, like silently corrupt customer data).

In a small program, a careful programmer can manage this. In a five-million-line enterprise program written by a hundred people over ten years, a single forgotten delete could ruin everyone's week.

QuestionSelect one

Why was cross-platform portability such a big deal for enterprise software in the 1990s?

Because computers were getting more expensive

Because big organizations ran many different kinds of machines and could not afford to maintain a separate program for each one

Because users wanted programs to look identical everywhere

Because the internet did not yet exist

The internet enters the picture

There was one more force at work. By the mid 1990s, the World Wide Web was exploding. Suddenly there was a brand-new kind of program: a small piece of code that could be downloaded from a server and run inside a web browser, on any user's machine, anywhere in the world. Nobody knew in advance what kind of computer the user had.

For this dream to work, you needed a language that could:

• be downloaded over a slow connection (so: compact);
• run safely on a stranger's machine (so: sandboxed, can't trash the hard drive);
• look and behave identically on every platform (so: truly portable — not portable-in-theory like C++).

C++ was simply the wrong tool. It compiled to machine code that was specific to one CPU. You could not just download a C++ binary onto "whatever the user has." Something else was needed.

A perfect storm

So by the early 1990s, the world had:

• An industry desperate for a way to write portable enterprise software without rewriting it for every platform.
• A new web that needed safe, downloadable, portable programs.
• A generation of programmers who had been taught OOP at university and wanted to use it in industry.
• A research community that had been refining OOP for thirty years.

The conditions were set for a new language. The catch is that this language was not actually invented to solve any of these problems. It was invented to control smart toasters and TV remotes. That's the next page.

QuestionSelect one

Which of these was a real limitation of C++ for very large enterprise systems?

C++ could not represent integers larger than 100

C++ did not support inheritance

C++ required the programmer to manually allocate and free memory, which became error-prone at large scale

C++ could not compile on Unix systems

QuestionSelect one

Why was the web browser an awkward place to run C++ programs?

Browsers could not display text

C++ compiled to a CPU-specific binary, but a browser could be running on any CPU on any operating system

C++ did not support graphics

Browsers did not support classes