Why languages exist at all
A computer’s processor understands only a small set of numeric instructions. Early programmers wrote those numbers directly, a style now called machine code. It was slow, error-prone work, and a program written for one machine usually could not run on another.
Nearly every programming language since then has been an attempt to close the gap between how people think about a problem and what the hardware needs to be told. Different groups felt that gap in different places: scientists wanted formulas, businesses wanted records, teachers wanted something students could learn in an afternoon. That is the main reason there is not one language but many.
Machine code and assembly
In the 1940s, the first electronic machines were often set up by wiring or by entering numeric codes. Once the idea of keeping instructions in memory took hold (the stored-program concept), programs became data that could be edited and copied. People soon began writing short symbolic names in place of numbers, such as a word for “add” instead of its numeric code. A helper program, an assembler, translated these names into machine code.
Assembly language was a real improvement, but it still mirrored one specific machine closely. Moving a program to different hardware meant rewriting it. Anyone who wanted to solve a physics problem still had to think like the processor.
The 1950s: languages for specific kinds of work
During the 1950s, several groups tried to let people write something closer to ordinary notation and have the computer do the translation. The idea that a program could be translated automatically was met with doubt by some programmers, who believed hand-tuned code would always be better. Over time, translators improved enough to change that view, a story told in part in the account of Grace Hopper and early work on compilers.
Three efforts from this period shaped much of what followed:
- FORTRAN aimed at scientific programming, letting engineers and researchers write mathematical formulas directly. It appeared in the late 1950s from an IBM team.
- COBOL aimed at business data processing, with English-like statements that managers and auditors might read. A committee effort began around 1959.
- Lisp came from artificial intelligence research and treated programs and data as lists that could be manipulated, which suited work on symbols and reasoning.
Each served a community with different priorities, and each is still discussed because those priorities have not disappeared.
The 1960s: sharing and teaching
As machines became more widely used, two new concerns appeared. One was making languages less tied to a single manufacturer. International committees worked on standardized languages, and the idea of a formally defined language syntax influenced many later designs.
The other concern was access. Time-sharing let many people use one large computer at once, and the BASIC language was created at Dartmouth in the 1960s so that students outside science and engineering could write programs. A language designed for beginners turned out to matter even more when small personal computers arrived in the 1970s.
Meanwhile, some researchers noticed that large programs were becoming hard to manage. Simulation work in Norway produced ideas about grouping data and behavior together, which became one root of object-oriented programming. Several other lines of research, including interactive graphics and the Smalltalk project in the 1970s, contributed to the same family of ideas.
The 1970s: structure and portability
Language designers in this decade worried about code that jumped around unpredictably and was hard to follow. Structured programming encouraged clear blocks, loops and procedures. Pascal, created partly as a teaching language, reflected this approach.
Around the same time, the C language was developed at Bell Labs and used to write the Unix operating system. Because most of the system was in a high-level language rather than assembly, it could be moved to new hardware with comparatively little rewriting. That showed a general point: a language can be a tool for making operating systems and other low-level software portable. The topic of systems programming has been closely tied to C ever since.
The 1980s and 1990s: reuse, scripting and the web
As programs grew, object-oriented languages gained popularity. C++ extended C with classes, and later languages such as Java made objects a default way to organize code. The promise was reuse and easier maintenance, though results depended heavily on how carefully a team designed its software.
At the same time, a different kind of language was growing. Scripting languages were meant for gluing existing tools together, processing text and automating chores. Shell scripts, Perl and later Python and PHP became everyday tools for system administrators and web developers. JavaScript arrived in the mid-1990s inside web browsers, bringing programming to pages that previously only displayed text and images.
Two other ideas became important in this era. The first is the difference between compilers and interpreters, that is, translating a program ahead of time versus running it step by step, and many languages blur the line. The second is the growing role of free software and open-source projects, which made new languages easier to try and share.
What each generation tried to make easier
It can help to see the pattern as a series of goals rather than a list of names:
| Period | Main goal |
|---|---|
| 1940s | Get any program running at all |
| 1950s | Write in formulas, records or symbols instead of numbers |
| 1960s | Let more people learn and share programs |
| 1970s | Make code clearer and software portable |
| 1980s-90s | Organize large programs and automate everyday tasks |
| 2000s onward | Fit new settings such as the web, mobile apps and data analysis |
This table is a simplification. Many ideas appeared earlier or later than a tidy decade suggests, and languages often borrowed from each other.
Why new languages keep appearing
Several reasons recur. Hardware changes, so a language designed for one kind of machine may fit poorly on another. New fields such as web publishing or data analysis bring new daily tasks. Programmers also find recurring mistakes in existing languages and design alternatives to prevent them. Finally, taste matters: some people prefer a minimal language and others prefer one with many built-in features.
Because old software keeps running, older languages rarely vanish. Large amounts of business code from past decades are still maintained, and decades-old scientific libraries are still used. The result is a layered landscape in which new and old approaches coexist.
Reading this history carefully
Popular accounts often credit one person or one language with a breakthrough. In practice, ideas were usually developed by several groups at once, and the credit is shared or debated. It is also easy to overrate what a language alone can do. The quality of a program depends at least as much on the people, the testing and the problem being solved as on the notation used to write it.