Archive
Computers installed in the UK during the 1960s
The first commercially produced digital computer, the UNIVAC I, became available in 1951, and by 1961 the exponential annual growth in the number of computers installed was well underway (it may have been earlier, but earlier data is sparse).
For the UK, detailed annual installation data is listed in the paper: The Spread of Computer Usage in the UK, 1954-1970 by P. Stoneman (his PhD thesis: “Technological Diffusion and the Computer Revolution: The UK experience” is not available online {I have the book of the thesis}; perhaps someone from Cambridge could scan a copy of the thesis). The data comes from the trade periodical “Computer Survey”, and Stoneman extrapolated back from when it started in 1961. The plot below shows the number of computers installed in the UK in a given year, and the number still installed in subsequent years (colored line for each year), along with two fitted regression lines (both exponential; code+data):
Between 1958 and 1970 (end of the data) the annual growth rate of new computers was 34%. After the first year, installations decline at a rate of around 16% per year (presumably replaced by a more powerful system).
Which industries installed these computers? The plot below shows the annual spend (adjusted for inflation til 2026) on new computer systems by 26 UK industry classifications, the grey line is an exponential fit to the total, showing a 53% annual growth rate (code+data):
The mapping from colored line to industry is via the numbers/colors in the legend at the bottom of the plot, and the table below:
Number Industry description
1 Aircraft Manufacturers and Guided Weapons
2 Armed Services
3 Atomic Energy
4 Chemicals, Rubber, Glass, Plastics, Paints, Cosmetics
5 Computer Manufacturers and Service Bureaux
6 Electrical Engineering
7 Ferrous and Non-Ferrous Metals, Mining and Quarrying
8 Financial: Banks, Building Societies etc.
9 Food, Drink and Tobacco Manufacturers
10 Retail, Wholesale, Mail Order, Merchants
11 General and Constructional Engineering
12 Government Departments
13 Government and Other Research Establishments
14 Insurance and Assurance
15 Local Government
16 Motor
17 Oil
18 Public Bodies (mainly Post Office)
19 Public Utilities (Coal, Electricity, Gas, Water)
20 Transport
21 Universities and Other Educational Establishments
22 Textiles, Clothing, Furniture and Toys
23 Publishing, Printing, Paper, Book clubs
24 Sports, Leisure, TV, Films, Hotels
25 Miscellaneous
26 Unknown |
The higher spending industries tended to be those with lower Numbers, while the lower spending industries are at the higher Numbers. The total spend on new computers grew at 53% per year.
How much computer power did the £27.8 billion (in 2026 money) spent in 1970 buy?
In the 1960s most computers were used by businesses for regularly (i.e., weekly, monthly, quarterly) performing simple calculations on large quantities of information, and then printing the results. The printed outputs were items such as employee payslips, gas/electric/water bills, and invoices between companies.
The scientific/engineering uses of computers attracted most of the coverage in the popular press (after a few iterations, weekly/monthly payroll becomes deadly dull), and bought the larger machines, but businesses had a lot more money and an immediate need.
The British Commercial Computer Digest (published annually between 1959 and 1970, and also based on “Computer Survey” magazine data) lists computer installations by purchaser and computer installed, along with tables of computer performance, monthly lease prices and selling prices. The following data was obtained from the 10th edition, published in 1969.
The plot below shows the number of organizations having a given number of computers installed, along with a fitted power law whose exponent is -2.8 (code+data):
The table below shows the six computer models, out of 48, that represented 60% of all computers installed. The monthly rentals are an estimated average, and inflation adjusted 2026 pounds sterling. Possible memory capacities varied between 4k to 64k (yes, thousands of bytes). Readers will be familiar with the IBM 360, the ICL 1900 series was the UK’s home-grown response (via Canada):
Computer Installed Percent Monthly rental
IBM 360/30 305 17 £42k
ICL 1901 253 14 £21k
IBM 360/20 147 8 £17k
ICL 1902 138 8 £37k
IBM 360/40 127 7 £84k
ICL 1903 101 6 £45k |
The compute capacity of UK computers installed in 1969 might be less than one 2026 smartphone. However, the computer printer capacity (in bills/payroll slips/invoices/etc) might be about the same as it is today, down from a peak in the late 1990s, when the major push to electronic billing started.
2026 in the programming language standards’ world
This week I was on a virtual meeting of IST/5, the BSI committee responsible for programming language standards in the UK. It’s been three years since I last reported on the programming language standards’ world, what has been going on?
tl;dr: Business as usual, with a handful of active committees.
I have been meeting secretary for the last few years, and sometimes struggle to write something in the minutes, other than: “The document was noted”, or “No action”. IST/5 is a management committee whose job is to check that the various programming language panels/committees (who do the technical work) follow the procedures. When experienced people are chairing the technical work, procedures are followed, and IST/5 get to tick a box.
The latest revision of C was intended to be published in 2023, hence the commonly used name C23, but slipped to 2024, and there are people who refer to it as C24. The plan is for the next revision to be published in 2028. Over the last few years there has been a significant increase in proposals for new languages features. C has started to follow in the footsteps of C++ (the committee is currently an order of magnitude smaller), attracting bored consultants looking for a creative outlet.
The ISO C++ committee acquired a new chief sheep herder, who has been restructuring the organization of the committee, which had outgrown its previous way of working.
The C++26 document is out for balloting by SC22‘s 28 P-member countries. It’s possible that this vote will fail (people in various National bodies are canvassing for No votes). The sticking point is contracts, which was removed from the C++20 draft to enable it to progress, and did not make it into C++23. Stroustrup, voted against the proposal, and has said (53 minute mark) “…it’s claimed to be a minimal viable product. It’s not minimal, it’s not viable.” The ballot closes on 27 September.
BSI is active on the climate bandwagon, and is constantly reminding its committees about the London Declaration (net-zero, etc). What can a programming language standards’ committee do to reduce emissions and cut electricity use? There have been various studies comparing the electricity consumed by different language constructs. I have not written about them on this blog because they were either poorly run, or the results were essentially noise. Interpreted languages obviously consume more electricity than compiled languages. However, none of the three languages within SC22 that are commonly interpreted (WG8 BASIC, WG16 ISLISP, and WG17 Prolog) are actively being worked on.
Programming language standards were among the first to support the non-8-bit character sets (SC2 Coded Character Sets). Andrew West was an active member of SC2 and attended IST/5 meetings to report what was going on. Andrew died towards the end of last year, and has an obituary in The Guardian.
At the start of the year BSI moved to new headquarters in Covent Garden, about 100 yards up the road from the Royal Opera House/Royal Ballet. A rather different ambience than an office block above Gunnersbury underground station (which is being converted to flats). This week’s IST/5 meeting was intended to be hybrid, to have a chance to meet new faces (and check out the plush new offices). However, BSI’s net-zero rules restrict us to online only; no BSI tea and biscuits for us 🙁 I walked past the building one evening a few weeks ago, and pressed by nose against the door, but could not see any BSI signage through the tinted glass.
UK based readers can apply to join a panel. Existing panel members are emailed the CV of applicants, and asked if “… applicant’s knowledge would be beneficial to the work programme and panel…”. Anybody can join the US Standards body, INCITS, by paying an annual fee for membership of a language committee ($1,530/$2,703).
INCITS recently introduced a new rule which prevents its members being a member of any corresponding National committee: “However, Individuals who are participating as members of other National Bodies (NBs) for an International Technical Committee (TC) or Subcommittee (SC) are not permitted to participate in INCITS IOEs responsible for the same international standards activities. This is to ensure the confidentiality of the USNB discussions and positions and to avoid conflict of interests.”
Flagging poor algorithm choice: LLMs next role
Current use of LLMs in software engineering has focused on using them as proficient coding assistants or having them write programs from specifications.
Algorithm selection is an important issue that has yet to attract much attention within the software engineering LLM ecosystem. While much of a program’s functionality is mundane, and the accuracy/performance of the algorithm chosen is not critical, there is always some functionality where algorithm choice can have a big impact on accuracy/performance.
Existing code repositories provide the training data for both the mundane and the critical functionality.
In the same way that LLMs generate code that contains mistakes, LLMs can use an inappropriate/suboptimal algorithm, i.e., the algorithm does not do what is required, or does it inaccurately/slowly.
The flip side of generating code containing mistakes, is that LLMs can flag mistakes in existing code. A large number of serious coding issues are now being found by LLMs. I suspect that some of these were being flagged by traditional static analysis tools, along with a huge number of non-serious issues. However, LLMs appear to do a better job of separating out the really important issues from the run-of-the-mill.
The ability to find coding mistakes is not surprising. LLMs are creatures of their training data, and there are lots of examples of coding mistakes, along with discussions in fault reports, online posts, and the large number of developer interactions that the major vendors now have.
Fixing coding mistakes in existing code will soon be an infrequent activity. Fixing poor choice of algorithms is the next step up the value chain.
Despite its importance, algorithm selection is something of a niche topic (yes, there are lots of books discussing the mathematics behind algorithms and their implementation), with the common default of using what everybody else uses (which is often a good strategy). There is also the issue that choice of algorithm can be context dependent. For instance, a simple algorithm with quadratic runtime performance may be selected because the number of items processed is expected to be low. As program usage grows this initial assumption may evolve to a high number of items being processed, with quadratic performance becoming a bottleneck. I am not aware of a large source of examples of poor/good algorithm selection.
One domain where algorithm choice can have a huge impact is the numerical solution of the equations used in scientific and engineering applications. How good are LLMs at flagging the use of suboptimal/inappropriate algorithms in this domain?
Pre-LLM, figuring out which algorithm a function implemented, if any, was a very hard problem. The numbers tool was written to pattern match any real literals appearing in the source against a database of known formula and associated constants. The assumption being that any matching formula was the one implemented by the function containing the literals. Maintaining the numbers/formula database was a huge task, and the project died, apart from as a tool to flag possibly inaccurate literal use.
Based on a small sample (some ChatGPT responses), LLMs appear to do a good job of matching a cluster of floating literals to the corresponding formula (in all the cases I tried, they searched the web). All the scientific source I have is readily available on the web, apart from the Climategate code, which only contains simple data analysis and plotting code.
Recent papers appear to still be using the solution via a prompt approach (e.g., The orbit has an eccentricity of 0.6, and at a specific moment, the mean anomaly is 0.6 radians… find the eccentric anomaly in radians), code generation via a specification, or investigating low level improvements to existing code (e.g., detecting instabilities and stabilizing numerical expressions).
Recent Comments