Why Do Programming Languages Rise and Fall? Part 2

Why Do Programming Languages Rise and Fall? Part 2

The first article in this two-part series looked at programming languages with long tenures. In this section we’ll examine a few cases of languages that didn’t fare so well—despite high hopes for them.
False Starts

Some languages make a big splash but fail to really catch on. The most salient example is Pascal. It was invented in 1970 by the distinguished computer scientist Niklaus Wirth to solve the problem of spaghetti code.

Wirth and other researchers of the time, such as the brilliant, outspoken, and somewhat feared Edsger W. Dijkstra, decided that the way to make programs less buggy and more maintainable was «structured programming.» Just as parents and neighborhoods, by providing structure for children, help them grow (sometimes) into responsible adults, a language that enforces good programming habits is supposed to create responsible programmers.

This was actually a good idea, and an early demonstration of the concept of design patterns. The term was an architectural concept, invented by Christopher Alexander for his 1977 book A Pattern Language: Towns, Buildings, Construction. The term entered programming in the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by a quartet of computer science experts known best as the Gang of Four.

In practice, patterns start out as good programming practices that programmers are supposed to be (but find difficulty) following. The patterns are then incorporated into libraries, which make them easier to use. Finally, they are integrated into the syntax of programming languages, so that programmers can use a convenient construct such as forall without having to think about it on an abstract level.

Pascal became the darling of the computer science researchers and was supposed to show everybody how to program properly. It was widely taught in computer science courses (as Java is today), which should have clinched its dominance. So why didn’t it last?

It seems that even the redoubtable Wirth did not go far enough in standardizing good programming practices, and was not aware which way the winds of programming were blowing. Pascal was not object-oriented, a concept already making headway. Object Pascal was introduced in the mid-1980s, but it came too late.

Developer James Vasile ascribes Pascal’s problem to its design as a teaching language. It lacked a portable compiler and features needed for production use, such as a variable-length string type. Several such lapses were aired in a paper cited by computer science researcher Greg Wilson in his review of this article: «Why Pascal Is Not My Favorite Language» by Brian Kernighan, one of the central creators of Unix and C.

Another interesting language that made a false start was Objective-C, invented shortly after C++. The reason Objective-C, a syntax-heavy language weighed down by introspection features and an inscrutable memory management system, captures our attention is that Steve Jobs chose it for a new system he developed after leaving Apple, the NeXT computer. That was in the 1980s, before it was clear which object-oriented version of the C language would win out.

And when Jobs was brought back to Apple in 1997 to turn it into the behemoth it is today, Jobs called for applications to be coded in Objective-C even though he should have known better by then. When the iPhone opened its fabled «app store» to eager developers, they all had to learn Objective-C. The language is regaining its much-deserved obscurity now that Apple uses Swift for mobile devices.

(Google went through a similar evolution for its mobile devices, starting by promoting Java because it was so widespread, and then switching to the previously obscure Kotlin language.)

Two other languages were favored by large organizations that tried to impose them on developers. The first was PL-1, which was promoted in the 1960s by IBM, the company for whom the term «large organization» hardly conveys more than a hint of its monolithic importance. PL-1 became the Edsel of programming languages.

The other was Ada, developed in the 1970s by the U.S. Department of Defense and required for innumerable defense contracts. The DoD guessed right when it sponsored the internet, but it tumbled into a pit with Ada. Vasile points out that Ada also required an expensive proprietary compiler.

Now for a claim many will find controversial—notably, supporters of the Ruby language. This language hasn’t gone the way of Pascal or Perl, but it has fallen far from its heights in the mid-2000 decade when Ruby on Rails came out. At that time, Ruby looked like Perl’s successor, and certainly eclipsed Python.

Some people say that Ruby was not promoted as well as Perl or Python because its inventor was Japanese, standing outside North American circles. But Rails was a tremendous promotion. My opinion is that Rails turned out to be less valuable than it originally seemed. And when the excitement over Rails waned, Ruby had less to offer than Python.

Rails was the first framework for template-based development of server-side programs that support dynamic web pages. It provided a basic design that a programmer could fill in very quickly. But it also set in stone the assumptions of its designer, David Heinemeier Hansson. If you want a web page that behaves just like DHH’s web page, Rails is fantastic. Its utility decreases geometrically with your distance from the DHH paradigm.

On the other hand, the early success of Rails spurred developers who favored other languages to develop similar frameworks; soon every modern programming language you could think of had a framework for server-side web applications. The most popular (although I can’t find hard and fast statistics) seems now to be the JavaScript framework, Node.js, which reduces development friction by letting programmers use the same language for the client and server sides of an application. In addition, some observers find Node.to be superior to Rails in performance and some other characteristics.

Rails is still widely used, but the momentum it achieved in the early years has slowed. Along the way, Ruby itself lost its sheen. Both still have respectable followings, but not like they were a couple decades ago.

Before Ruby came Tcl (pronounced «tickle»), which briefly threatened to replace Perl as the language for quick-and-dirty scripting. Eventually people found that its design held it back from handling complex programming needs, and now it is barely remembered even by former users.

What It Takes to Win

The (somewhat subjective and highly opinionated) history I’ve aired in this series shows that it’s extremely hard to predict what language will win the hearts and minds of programmers over time.

In the case of Java, support from a major firm in those years, Sun Microsystems, was crucial to its spread. But efforts by IBM, Microsoft, Apple, and even the mighty Department of Defense to promote their favorite languages had little impact.

Nor does development by leading researchers lead to popularity. We saw this in the case of Pascal, and similar circumstances exist for other research-driven languages such as ML and Haskell. By contrast, JavaScript, PHP, and Python were relatively rough-hewn efforts that adequately served their initial needs and had space to evolve, becoming more robust.

Some languages never gain wide followings, but strongly influence other, more popular languages. This was the theme of my recent article, «Functional Languages and the Future of Programming.»

Haskell development team leader Simon Peyton Jones says, «The success of a language, measured in terms of adoption, is very weakly connected to its technical merits: clean design, formal specification, or even programmer productivity. Non-techincal or socio-economic-techincal issues dominate.»

Essentially, I think, language developers are brilliant people who, if educated in the design and construction of many different programming languages, can create a thing of mathematical rigor. Whether it’s aesthetically pleasing and meets the needs of real-word applications are more nuanced questions that perhaps will be answered only over time. So the creation of new programming languages will never end—unless we stop programming altogether and let AI do all our computing, but that would mean relinquishing human agency over the future of humanity in ways that most of us would resist.

Author

  • Andrew Oram

    Andy is a writer and editor in the computer field. His editorial projects at O'Reilly Media ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. Andy also writes often on health IT, on policy issues related to the Internet, and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM (Brussels), DebConf, and LibrePlanet. Andy participates in the Association for Computing Machinery's policy organization, USTPC.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *