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

DesignerLanguageAge
John BackusFORTRAN30
Dennis RitchieC30
Bjarne StroustrupC++30
Yukihiro MatsumotoRuby30
John McCarthyLISP32
Brendan EichJavascript33
Larry WallPerl33
Guido van RossumPython34
James GoslingJava39
Anders HejlsbergC#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:

Other Articles in This Series

Sociology References

Other References

References Added Later

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

  • Comment on Organizational Culture (Part VI): Sociology

Replies are listed 'Best First'.
Re: Organizational Culture (Part VI): Sociology
by etj (Priest) on Jun 09, 2024 at 14:29 UTC
    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

    I'm entertained to note that Planck can be said to have made his breakthrough (black-body radiation) in 1894, age 36. But why let facts get in the way of a good story? ;-)
[reply]
Re: Organizational Culture (Part VI): Sociology
by bliako (Abbot) on Aug 17, 2021 at 11:43 UTC
[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Meditations