An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning: another instance of the fact that the future lies with the youth.

-- Planck's Principle

A person who has not made his great contribution to science before the age of thirty will never do so

-- Albert Einstein

Remembering some of my physicist friends lightheartedly complaining about being over the hill at their thirtieth birthday party, I was intrigued to see if programming language designers were similarly youthful.

Some Successful Programming Language Designers

Designer	Language	Age
John Backus	FORTRAN	30
Dennis Ritchie	C	30
Bjarne Stroustrup	C++	30
Yukihiro Matsumoto	Ruby	30
John McCarthy	LISP	32
Brendan Eich	Javascript	33
Larry Wall	Perl	33
Guido van Rossum	Python	34
James Gosling	Java	39
Anders Hejlsberg	C#	39

As you can see, many successful programming languages were designed by men in their thirties. Perhaps programming language designers tend to be older than physicists because designing a new programming language requires more wisdom, experience and social networking skills, rather than a blinding flash of inspiration (combined with exceptional calculation faculties) often associated with physics breakthroughs.

Curiously, these successful programming language designers seemed to have precious little experience in actual programming language design! They just boldly created a language to meet what they perceived as an unmet need in their workplace -- typically without asking permission to do so.

I had this idea that given how much time we had available for Amoeba, I could actually build a whole new language, design and implement it from scratch, and then use it to implement our suite of tools and still be ahead of the game compared to a situation where we would have just clunked on writing the things we wanted to write in C

-- Guido van Rossum

Larry similarly invented Perl as a way to make report processing easier at work and to more efficiently solve Unix problems that were being inefficiently solved in a motley mix of C, sed, awk and shell ... while Ritchie invented the C programming language to implement the Unix operating system after Bell Labs withdrew from the ill-fated Multics project. Later, one of Ritchie's workmates, Bjarne Stroustrup, added ideas from Simula to C, creating C++ as a language to make writing his simulations more enjoyable than C while running faster than Simula.

Perhaps this lone hacker language designer trend was simply a natural reaction to the vacuum created by the failure of design by committee experienced by Algol-68, PL/I and Ada.

This paper (based on a keynote address presented at the SIGACT/SIGPLAN Symposium on Principles of Programming Languages, Boston, October 1-3, 1973) presents the view that a programming language is a tool which should assist the programmer in the most difficult aspects of his art, namely program design, documentation, and debugging. It discusses the objective criteria for evaluating a language design, and illustrates them by application to language features of both high level languages and machine code programming.

-- Hints on programming language design by Sir Charles Antony Richard Hoare (1973)

Though Hoare's classic paper makes interesting reading, it's hopelessly outdated, sorely in need of a modern equivalent. I couldn't find one though (citations welcome), the nearest I could find being the Socio-PLT works of Leo Meyerovich (see Sociology References below).

Programming Language Sociology and Evolution

Another reason for the unpleasantly large size of modern language is the need for stability. I wrote C++ code 20 years ago that still runs today and I'm confident that it will still compile and run 20 years from now. People who build large infrastructure projects need such stability. However, to remain modern and to meet new challenges, a language must grow (either in language features or in foundation libraries), but if you remove anything, you break code. Thus, languages that are built with serious concern for their users (such as C++ and C) tend to accrete features over the decades, tend to become bloated. The alternative is beautiful languages for which you have to rewrite your code every five years.

-- Bjarne Stroustrup

Stroustrup hits the nail on the head: if you have serious concern for your users, as both Perl and C++ do, you must not break backwards compatibility.

Related is Simon Peyton Jones’s unofficial motto for Haskell "avoid success at all costs" because becoming too successful harms the ability to modify Haskell ... an evolutionary dead end. I might add that Haskell seems to have been successful in its mission to avoid success. :)

It seems to me that Perl and Raku have (finally, much too late) got it right: Perl does not break backwards compatibility (out of serious concern for its users), while Raku is free to innovate and improve without the shackles of backwards compatibility ... though as it becomes more widely adopted it will presumably need to pay more attention to backwards compatibility.

Update: The Why Perl Didn't Win essay argues (convincingly IMHO) that to remain popular over time, a programming language must be compelling for new projects ... while further noting this is not solely a technical concern; it's a concern of the language community and ecosystem.

Improving Programming Language Adoption

Social factors seem to have a far greater impact on language adoption than technical features.

From Sociology we can learn of many ideas that might be tried to improve language adoption:

• Identify opinion leaders. Apparently, this approach proved effective in promoting safe sex to fight HIV/AIDS in the 1980s. Given how heavily Google invested in C++, Java and Python I was surprised by the growth of Golang, perhaps this can be partly explained by Rob Pike being an effective opinion leader at Google. Similarly, now that Guido moved from Google to Microsoft, will we see an increase in Python adoption at Microsoft and a decrease at Google?
• Observability. This worked well to increase Coverity static code analysis adoption simply by running the customer's code base through Coverity and having it find hundreds of long-standing bugs the customer was not previously aware of.
• Data mining and AI analysis (e.g. of github repos, SO, social media). Looking for niches to fill, for example.
• More important than language features are the libraries and community supporting various domains - this explains why BioPerl is so popular and why Python is so popular in the AI/Machine Learning domain (see BioPerl/PDL and Data Science References for more detail on this topic).
• See the Sociology References and this response below for other ideas that might be tried to improve Programming Language Adoption.

Other Articles in This Series

• Organizational Culture (Part I): Introduction
• Organizational Culture (Part II): Meta Process
• Organizational Culture (Part III): Spaceflight and Aviation
• Organizational Culture (Part IV): Perl Culture
• Organizational Culture (Part V): Behavior
• Organizational Culture (Part VII): Science

Sociology References

• Leo Meyerovich home page
• Empirical Analysis of Programming Language Adoption by Leo Meyerovich (pdf)
• Adoption-Oriented Language Design (pdf)
• Social Theories for Programming Language Adoption by Leo Meyerovich (Google tech talk 2012, 57 mins)
• The Sociology of Programming Languages Leo Meyerovich (Strange Loop Conference, 2014, 42 mins)

• Diffusion of innovations (wikipedia)
• Diffusion (business) (wikipedia)
• Bass diffusion model (wikipedia)
• Early adopter (wikipedia)
• Opinion leadership (wikipedia)
• Technology adoption life cycle (wikipedia)

• Online community (wikipedia)
• Community of interest (wikipedia)
• Hacker culture (wikipedia)
• Sociology of scientific knowledge (wikipedia)
• Social learning theory (wikipedia)
• Computational social science (wikipedia)

• Second-system effect (wikipedia)
• Worse is better (wikipedia)
• Minimum viable product (wikipedia)
• Plan to Throw One Away (famous quote from Fred Brooks)

Other References

• Timeline of programming languages (wikipedia)
• Niklaus Wirth (wikipedia)
• Turbo Pascal (wikipedia) - C# architect Anders Hejlsberg was only 19 years old when he first started writing compilers at Technical University of Denmark (inspired by Niklaus Wirth's Tiny Pascal and culminating in Borland's Turbo Pascal in 1983)

• Backward compatibility (wikipedia)
• Forward compatibility (wikipedia)
• Bug compatibility (wikipedia)
• Deprecation (wikipedia)
• Legacy mode (wikipedia)

• The Development of the C language by Dennis M Ritchie
• The Evolution of the Unix Time-sharing System by Dennis M Ritchie

• Re^6: Improving p5p: Perl is going to stay Perl (Backwards Compatibility) - Sad public animosity between Bjarne Stroustrup and Ken Thompson
• Re: Organizational Culture (Part II): Meta Process (Perl Timeline) - merlyn promoted Perl in its early years by answering usenet requests for Unix shell/sed/awk code with snippets of Perl code

References Added Later

• Re: Honest question about Perl, Python and Ruby (Comparing Programming Languages References)

• Perl holds its own against Python Ruby et al - by Gavin (2008) - Perl was one ahead of Python in the TIOBE index back then (No. 6 vs No. 7)
• Re^2: Perl holds its own against Python Ruby et al - by me (2008) - some non-technical reasons for Python's rise in the TIOBE index
• Re^3: Editing node titles w.r.t. Perl 6 - by Bod (2024) - What would need to happen for PerlMonks to grow in activity? What would have to happen to get Perl to become a more universally used language?

• Re^9: Automatic downvote by afoken (2023) - discussion around an interesting quote from Douglas Adams in The Salmon of Doubt (anything invented after you're thirty-five is against the natural order of things)

• New built-in perl5.38 try/catch syntax by me (2023) - learning from the smartmatch/Switch debacle, P5P improved the way they introduced experimental new features into the Perl core

Updated: corrections to history of B and C programming languages by Ritchie and Thompson. Expanded Other References section.