At the beginning of the electronic computing era in the 1950s, computers were mutually incompatible both in terms of hardware and software. It was impossible to use peripherals (e.g. punched card or tape readers, printers, etc.) for some computer with another one as there was no common interface. The same was mostly true for software. Programs created for one computer often could not run on another because programming languages (or rather assemblers or microcode) were unique to each computer (although first versions of Fortran, Cobol and Algol were introduced at the end of 1950s). So when a customer bought a new computer, new peripherals also had to be purchased and software completely (or at least partially) reprogrammed. This changed in 1964 when IBM introduced System/360, a scalable computing system with mutually compatible peripherals, common programming language(s) and operating system. It was even possible to emulate IBM older models (e.g. 1401) on System/360. After that, some other computer manufacturers started to produce computers compatible with IBM systems.

I can understand that at the beginning, there was a lack of standards, and each manufacturer tried to lock its customers in and avoid switching to competitor's products. However, I do not understand why computers produced by manufacturers were incompatible with each other, and software had to be rewritten after an upgrade. In IBM, there were even two rival teams of engineers, placed in different factories. The first team produced smaller computers such as 600 and 1400 series and second one mainframe computers (series 700 and later 7000). Each product line had its operating system, programming language and peripheries as these teams did not collaborate.

So, why did it take so long (until mid of the 1960s) to introduce common standards even within one company? Was it more about technical reasons or business ones (e.g. development of System/360 cost IBM about 30 billion of today US dollars)?

Note: Information about IBM is based on the book "IBM: The Rise and Fall and Reinvention of Global Icon" by James W. Cortada.

  • 2
    $\begingroup$ I guess you don't have long experience in upgrading your operating system and having to replace software (Win 3.1 - Win NT - Win 10 arc for example). Or the whole transitioning of the Mac platform from 68000 to Intel. Backwards compatibility is not always a good thing. $\endgroup$ – Jon Custer Apr 17 '20 at 17:44
  • $\begingroup$ @JonCuster: I worked with all Windows systems you mentioned and you are right that it is difficult to run some old programs on new versions, however, there are compatibility regimes, emulators etc. Moreover, when I write a code on one computer I can run it on another one, I can use same printer on computers produced by different manufacturers etc. And this was not case in 1950's. $\endgroup$ – Martin Vesely Apr 17 '20 at 21:56
  • 3
    $\begingroup$ Why is from 1950 to 1964 "so long"? It was an age of generating ideas and trial and error for a new type of technology, when people did not really know what they were doing, and even less so what would work best. It made little sense to lock in early, and then drag it along like an albatross. It took from 1868 to 1888 to start standardizing typewriters, far simpler devices, so the real question is why did it not take longer (my guess is that cold war and Moon race sped up the process). $\endgroup$ – Conifold Apr 18 '20 at 1:29
  • 2
    $\begingroup$ You're being a little too harsh. Fortran was pretty widely available by the early 1960's, as were 026 keypunches using standardized bcd coding. No problem running the same 026-punched Fortran program on pretty much any machine with a Fortran II compiler. My personal experience in 1967, with a part-time programming job at NYU: Tuck Howe brought his Music4BF program, running on a 7094 at Princeton, to NYU, where I got it running on our 360/30. And then we brought it down the street to the Courant Institute, where we got it running on their CDC-6600. No more porting problem than I'd expect today. $\endgroup$ – John Forkosh Apr 18 '20 at 12:48
  • 1
    $\begingroup$ Why does car manufactorers not use interchangeable parts? $\endgroup$ – Thorbjørn Ravn Andersen Jun 15 '20 at 10:59

There is a heap of answers to this question, and they cover a wide range of aspects of the early computer industry. As has been pointed out, the very first machines were hand built lab experiments. It was not at all obvious how to build a digital computer that would work. Remember Babbage's Analytical Engine had foundered on the challenge of actually building it. Go back to the 1940s and 50s. Not merely no integrated circuits (invented 1959), but no transistors (invented 1948). Until the widespread inclusion of microcode ( invented 1951), instruction sets were intimately tied to the physical architecture. So a different architecture meant a different instruction set. Incidentally, a hard wired architecture will out perform a microcode implementation of same, but at an enormous cost in flexibility. And we all know that every design is perfect when first implemented, right? Why would IBM have entirely separate architectures in their product line-up? Part of it was market control - the incompatibilities meant customers were locked in. There was more competition in the midrange (a market pioneered by DEC), but they didn't want high paying mainframe customers jumping down to midrange where profits were lower. They have finished up at the other extreme now, iSeries, pSeries and zSeries all use Power architecture chips (but still have incompatible instructions and OS's). RISC architecture promised massive performance/efficiency gains (which is why Sun, Motorola and IBM all jumped in that direction), but seemed to fall by the wayside, until the rise of mobile devices in the last 10 years (most of which use ARM, a RISC architecture). That begot the SBCs such as Raspberry Pi, as well, IoT is another growth area. It's sometimes hard for people who grew up with the Wintel stack to see this, but it's by no means the only solution, and it's dominance owes more to history, market power and market forces than technical merit.

  • $\begingroup$ A slight correction on your history: RISC didn't "fall by the wayside", it won. x86 chips have been internally RISC for over two decades, using a translation layer to support the traditional instruction set. $\endgroup$ – Mark Feb 26 at 4:32
  • $\begingroup$ I remember hearing that at the time, but I am going to disagree with you. A microengine (possibly running nanocode) running microcode to implement a CISC instruction set is about as far from RISC as you can get. Intel don't expose the RISC layer. So IMHO, marketing it is, RISC it is not. $\endgroup$ – mikb Feb 26 at 13:32

First machines were one-off affairs, custom built (often for a very narrow purpose). There just weren't enough of those around to make standarization of anything surrounding them worthwhile. Thomas Watson (IBM president at the time) accurately estimated a demand of half a dozen computers worldwide in that timeframe.

Remember the idea behind the Multics proyect (GE -- AT&T -- others) was to build a machine to essentially serve all computing needs of a larger area. Not "a machine in each home", an access point. Here in Chile by the early '80s even banks didn't have their own computers, they rented computer time from companies that specialized in doing the processing for a lot of even large clients.

Later on, each company built their own machines, and had their own standards (i.e., IBM machines worked --mostly-- with IBM peripherals), some copycats came up (e.g. Amdahl had a very successful IBM-compatible line of mainframes), Digital specialized on minicomputers -- small machines for e.g. a department, later workstations --powerful machines for personal use with graphics screens-- became common. All very much incompatible, software-wise (porting a program to the brand-own Unix dialect was real fun) and absolutely hardware-wise. For example, IBM has EBCDIC as character set standard (up to this day, I'm told), they used to use a weird coaxial cable with two central conductors to connect assorted equipment. But even so, often the new model was very much incompatible with the last one. War stories of machines running an emulator of an earlier one, on which to run an emulator for an even older one, on which to run some legacy software abound.

Today's much simpler world, in which "everything is a PC" is a rather recent phenomenon (since around the time Apple migrated to intel), largeish "servers" now also are PC-type hardware, not SPARC or Alpha or some other architecture. Earlier phenomenon was the mistaken idea that "everything's a VAX" in the Unix world.

  • 2
    $\begingroup$ These days the Watson quote about only marked for a few computers is often ridiculed. If the price had stayed the same, I think it would still be true. $\endgroup$ – Thorbjørn Ravn Andersen Jun 15 '20 at 11:01

This changed in 1964 when IBM introduced System/360, a scalable computing system.

It's obvious now that we have scalable computing systems that we can have scalable computing systems. Before then, it wasn't.

There were in my opinion two insights that made this possible:

  1. Firstly, the separation of architecture from implementation: that the machine as seen by the programmer, and the machine as seen by the hardware designers, were different things.

  2. Secondly, that the cost of upgrading of a computer system was heavily skewed towards the cost of rewriting working programs.

Prior to that, there was more of a design culture oriented to the immediate goals for the machine being designed. Don't forget, also, the division into "scientific" and "business" computers, optimizing for different targets. Scientific computers had fixed word lengths and fast floating point and relatively poor I/O; business computers tended to decimal-string arithmetic with extensive I/O capability.

To build a family of computers requires some careful design to ensure that architectural features don't add undue cost to the low end (alternatively stated, that you're willing to accept the extra cost at the low end for the sake of the family), and consideration for the low end doesn't badly constrain performance at the high end. For that, the state of the art needs to have matured a little from the very early days.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.