Showing posts with label popularity of programming languages. Show all posts
Showing posts with label popularity of programming languages. Show all posts

Wednesday, January 12, 2022

Successful programming languages

The IT world has seen a number of programming languages. Some became popular and some did not.

With more than half a century of experience, we can see some patterns in languages that became popular. First, let's review some of the popular programming languages.

FORTRAN and COBOL were successful because they met a business need (or two, perhaps). The primary need was for a programming language that was easier to understand than assembly language. The secondary need was for a programming language that could be used across computers of different manufacturers, allowing companies to move programs from one vendor's hardware to another. Both FORTRAN and COBOL met those needs.

BASIC was modestly successful on minicomputers and wildly successful on personal computers. It was possible to run BASIC on the small PCs (sometimes with as little as 4K of memory!). It was easy to use, and amateur programmers could write and run programs relatively easily. It filled the technical space of timesharing on minicomputers, and the technical space of personal computers.

C became popular in the Unix world because it was included in Unix distributions. If you ran Unix, you most likely programmed in C. One could say that it was pushed upon the world by AT&T, the owners of Unix.

SQL became successful in the 1980s, just as databases became available and popular. Prior to databases, computer systems offered "file managers" and "file access libraries" which allowed basic operations on records but not tables. Each library had its own set of capabilities and its own API. SQL provided a common set of operations and a common API. If allowed businesses to move easily from one database to another,  guaranteed a core set of operations, and permitted a broad set of programmers to work on multiple systems.

C++ became popular because it solved a problem with C programs, namely the organization of large programs. C++ offered object-oriented concepts of classes, inheritance, encapsulation, and polymorphism, each of which helps organize code.

Visual Basic became popular because it provided an easy way to write programs for Windows. Microsoft's earlier Visual C++ required knowledge of the Windows API and lots of discipline. Visual Basic required neither, hiding the Windows API from the programmer and providing safety in the programming language.

Objective-C became popular because Apple used it for programming applications for Macintosh computers. (Later, when Apple switched to the Swift programming language, interest in Objective-C plummeted.)

Java became popular because it promised that people could write programs once and then run them anywhere. It did a good job of delivering on that promise, too.

C# is Microsoft's version of Java (its second version, after Visual J++) and is popular only in that Microsoft pushes it. If Microsoft were to disappear overnight, interest in C# would drop dramatically.

Swift is Apple's language for development of applications for the iPhone, iPad, and other Apple products. It is successful because Apple pushes it upon the world.

JavaScript became popular because it was ubiquitous. Much like BASIC on all PCs, JavaScript was in all browsers, and the combination of HTML, the DOM, and JavaScript allowed for web applications with powerful processing in the browser.

Python became popular because it was a better Perl. Python had a simpler syntax and also had object-oriented programming built in.

Notice that, with the exception of Rust replacing C or C++, these new languages become popular in new spaces. They don't replace an existing popular language. BASIC didn't replace COBOL or FORTRAN, it became popular in the new spaces of timesharing and personal computers. C# didn't replace Java; it joined Visual Basic in the Microsoft space and slowly gained in popularity as Microsoft supported it more than Visual Basic.

So we can see that there are a few reasons that languages become popular:

  • A vendor pushes it
  • It solves a commonly-recognized business problem
  • It fills a technical space

If we accept these as the reasons that languages become popular, we can make some predictions about new languages that become popular. We can say that, if a major vendor pushed a language for its projects (a vendor such as Amazon, for example) then that language would become popular.

Or, we could say that a new technical space would allow a new language to become popular.

Or, if there is a commonly recognized business problem with our current set of programming languages, a new language that solves that problem would become popular.

So what do we see?

If we accept that C and C++ have problems (memory management, buffer overflows) and we accept that those problems are commonly recognized, then we can see the replacement of C and C++ with a different language, one that addresses those problems. The prime contender for that is Rust. We may see a gradual shift from C and C++ programming to Rust, as more and more people develop confidence in Rust and develop a fear of memory management and buffer overrun issues.

One technical space that could provide an opportunity for a new programming language is the Internet of Things (IoT). Appliances and devices must communicate with each other and with servers. I suspect that the IoT space is in need more of protocols than of programming languages, but perhaps there is room for a programming language that works with new protocols to establish trusted connections and, more importantly, trusted updates.

A third area is a teaching language. BASIC was designed, initially, for people not familiar with programming. Pascal was designed to teach structured programming. Do we have a language designed to teach object-oriented programming? To teach functional programming? Do we even have a language to teach basic programming? BASIC and Pascal have long been discarded by the community, and introductory courses now often use Java, JavaScript, or Python which are all rather complex languages. A new, simple language could gain popularity.

As we develop new devices for virtual reality, augmented reality, and other aides, we may need new programming languages.

Those are the areas that I think will see new programming languages.

Friday, August 27, 2021

Replacing a language

Do programming languages ever get replaced? Languages are introduced, and some rise and fall in popularity (and some rise after a fall), but very few ever disappear completely.

There are some languages that have disappeared. Two are FLOW-MATIC and NELIAC, languages from the 1950s.

Some languages have fallen to very low levels of usage. These include BASIC, PL/I, PL/M, and DIBOL.

Some languages never die (or at least haven't died yet). The go-to examples are COBOL and FORTRAN. Organizations continue to use them. Fortran is used for some parts of the R implementation, so anyone using R is in a sense using Fortran. We can include SQL in this list of "immortal" programming languages.

Some languages are replaced with new versions: C# version 6 replaced a very similar C# version 5, for example. VB.NET replaced VB6. And while there are a few people who use the old Visual Basic 6, they are a very small number.

The replacement of a language isn't so much about the language as it is about popularity. Several groups measure the popularity of languages: Tiobe, Stack Overflow, the Popularity of Programming Languages (PYPL)... They all rank the languages and show pretty tables and charts.

The mechanics of popularity is such that the "winners" (the most popular languages) are shown, and the "losers" (the less popular languages) are omitted from the table, or shown in a small note at the bottom. (Not unlike the social scene in US high schools.)

If we use this method, then any language that enters the "top 10" or "top 40" (or "top whatever") chart is popular, and any language that is not in the list is not popular. A language that never enters the "top" list is never really replaced, because it never "made it".

A language that does enter the "top" list and then falls out of it has been replaced. That language may still be used, perhaps by thousands, yet it is now considered a "loser".

For this method (referring to the Tiobe index), languages that have been replaced include: Objective-C, COBOL, Prolog, and Ada. They were popular, once. But now they are not as popular as other languages. (I can almost hear the languages protesting a la Norma Desmond: "We are big! It's the programs that got small!")

Sometimes we can state that one specific language replaced another. VB.NET replace VB6, because Microsoft engineered and advertised VB.NET to replace VB6. The same holds for Apple and Swift replacing Objective-C. But can we identify a specific language that replaced COBOL? Or a single language that replaced FORTRAN? Did C++ replace C? Is Rust replacing C++?

We can certainly say that, for a specific project, a new language replaces an older one. Perhaps we can say the same for an organization, if they embark on a project to re-write their code in a new language. I'm not sure that we can make the assertion for the entire IT industry. IT is too large, with too many companies and too many individuals, to verify such a claim in absolute terms. All we can rely on is popularity.

But popularity is not the measure of a language. It doesn't measure the language's capabilities, or its reliability, or its ability to run on multiple platforms.

We don't care about popularity for the technical aspects of the language. We care about the popularity of a language for us, for ourselves.

Product managers care about the popularity of a language because of staffing. A popular language will have lots of people who know it, and therefore the manage will have a (relatively) easy time of finding candidates to hire. An obscure language will have few candidates, and they may demand a higher wage.

Individuals care about the popularity of a language because it means that there will be lots of companies hiring for that skill. Few companies will hire for an obscure programming language.

This essay has meandered from replacing a language to popularity of languages to the concerns of hiring managers and candidates. That's probably not a coincidence. Economic activity drives a lot of behavior; I see no reason that programming should be exempt. When thinking about a programming language, think about the economics, because that will contribute a lot to the language's life.

Tuesday, November 17, 2020

The joy of a small programming language

I recently had the pleasure of reading the reference manual for Dibol (a programming language from the 1970s). And reading the manual was a pleasure. What made it so was the brevity and directness of the manual, the simplicity of the concepts, and the feeling of confidence in my ability to start programming it the language.

Dibol is a language from the minicomputer era, a short period of computing that occurred prior to the PC revolution. Made by DEC, it was an alternative for COBOL that ran on small systems and operated on simple files. It's syntax was influenced by COBOL, but much simpler.

The entire reference manual ran about 30 pages.

Dibol, I think, would have fit well in the Unix environment. Unix systems tended to use text files with flexible formats and varying line lengths, and Dibol was built for text files with fixed-length formats, so the match is not perfect. But Dibol is a language that follows the Unix philosophy: a simple tool to perform a simple task.

I could see it as a companion to AWK, a small language which handles text files and variable-length lines.

Dibol didn't "make it" as a programming language. It lives today, in the form of "Synergy/DE" which is a large superset of the original Dibol. So large, in fact, that it perhaps no longer follows the Unix idea of a simple tool. (I suspect the reference manual is longer than 30 pages.) But Dibol and its successors DBL and Synergy/DE have no significant presence in the popularity lists from Tiobe or PYPL or RedMonk.

We have no small languages today -- at least no small languages that enjoy any amount of popularity. AWK may be the most famous of the small languages, and even it is in the lower ranks on popularity lists. The popular languages are big (C++, Java, Python, C#, R, Visual Basic...).

We should be careful with the popularity indices. The methods used by them may skew the results. Tiobe and PYPL count queries about the languages -- people asking questions. I think we can safely assume that people will ask more questions about large languages than small languages, so complex languages have an advantage in the popularity metrics.

RedMonk also looks at Github and the code posted there. It's not clear if RedMonk is counting number of projects, number of files, or lines of code. (A complex language would probably have more lines of code.) But Dibol and other small languages do not show in RedMonk's list.

So we can conclude that there is no significant use of small programming languages. As a programming language, you're either big or you're unknown.

Which, I think, is a shame. The big language are hard to learn and easy to create large, complicated systems. Small languages have the advantage of doing one job and doing it well. We as an industry may be missing out on a lot.

It also means that large programming languages are the "go to" solution for programmers; that programmers prefer large languages. There is some sense in this. A large programming language (C#, Java, take your pick) can handle just about any task. Therefore, a programmer who knows a large programming language is capable (in one sense) of handling any task. Large programming languages give the programmer flexibility, and more opportunity. (I say "in one sense" because knowledge of a programming language is, while necessary, not sufficient for the design of large or specialized applications. System architecture, user requirements, performance analysis, and deployment practices are also required.)

The consistent use of large programming languages means that our solutions will tend to be large. I know of no small Java applications, no small C++ applications, and no small C# applications. There may be small utility programs written in large languages, but I suspect that those utility programs grow over time and become large utility programs.

Large code bases require more effort to maintain than small code bases, so our bias towards large programming languages is, in the long run, costing our customers time and money.

Of course, the alternative (lots of small programs written in small programming languages) can have the problem of multiple languages and not enough people to maintain them. A shop with hundreds of programs written in a dozen or so different programming languages also faces maintenance efforts. Should every programmer in the shop know every programming language used in that shop? That also requires time and effort.

So what should a programmer do? Learn one large language? Learn lots of small languages?

My recommendation is to learn multiple languages, some large and some small. For large languages, pick two of the popular languages C, C++, C#, Java, JavaScript, and Python. Also learn some small languages such as Awk, Lua, and bash.

But don't spend time on Dibol.

Wednesday, February 28, 2018

Backwards compatibility but not for Python

Programming languages change over time. (So do the natural, human-spoken languages. But let's stick to the programming languages.)

Most languages are designed and changes are carefully constructed to avoid breaking older programs. This is a tradition from the earliest days of programming. New versions of FORTRAN and COBOL were introduced with new features, yet the newer compilers accepted the older programs. (Probably because the customers of the expensive computers would be very mad to learn that an "upgrade" had broken their existing programs.)

Since then, almost every language has followed this tradition. BASIC, Pascal, dBase (and Clipper and XBase), Java, Perl, ... they all strove for (and still strive for) backwards compatibility.

The record is not perfect. A few exceptions do come to mind:
  • In the 1990s, multiple releases of Visual Basic broke compatibility with older versions as Microsoft decided to improve the syntax.
  • Early versions of Perl changed syntax. Those changes were Larry Wall deciding on improvements to the syntax.
  • The C language changed syntax for the addition-assignment and related operators (from =+ to +=) which resolved an ambiguity in the syntax.
  • C++ broke compatibility with a scoping change in "for" statements. That was its only such change, to my knowledge.
These exceptions are few. The vast history of programming languages shows compatibility from old to new versions.

But there is one language that is an exception.

That language is Python.

Python has seen a number of changes over time. I should say "Pythons", as there are two paths for Python development: Python 2 and Python 3. Each path has multiple versions (Python 2.4, 2.5, 2.6, and Python 3.4, 3.5, 3.6, etc.).

The Python 3 path was started as the "next generation" of Python interpreters, and it was started with the explicit statement that it would not be compatible with the Python 2 path.

Not only are the two paths different (and incompatible), versions within each path (or at least the Python 3 path) are sometimes incompatible. That is, some things in Python 3.6 are different in Python 3.7.

I should point out that the changes between versions (Python 3.6 and 3.7, or even Python 2 and 3) are small. Most of the language remains the same across versions. If you know Python 2, you will find Python 3 familiar. (The familiarity may cause frustration as you stumble across one of the compatibility-breaking changes, though.)

Should we care? What does it mean for Python? What does it mean for programming in general?

One could argue that changes to a programming language are necessary. The underlying technology changes, and programming languages must "keep up". Thus, changes will happen, either in many small changes or one big change. The latter often is a shift away from one programming language to another. (One could cite the transition from FORTRAN to BASIC as computing changed from batch to interactive, for example.)

But that argument doesn't hold up against other evidence. COBOL, for example, has been popular for transaction processing and remains so. C and C++ have been popular for operating systems, device drivers, and other low-level applications, and remain so. Their backwards-compatible growth has not appreciably diminished their roles in development.

Other languages have gained popularity and remain popular too. Java and C# have strong followings. They, too, have not been hurt by backwards-compatibility.

Python is an opportunity to observe the behavior of the market. We have been working on the assumption that backwards-compatibility is desired by the user base. This assumption may be a false one, and the Python approach may be a good start to observe the true desires of the market. If successful (and Python is successful, so far) then we may see other languages adopt the "break a few things" philosophy for changes.

Of course, there may be some demand for languages that keep compatibility across versions. It may be a subset of the market, something that isn't visible with only one language breaking compatibility, but only visible when more languages change their approach. If that is the case, we may see some languages advertising their backwards-compatibility as a feature.

Who knows? It may be that the market demand for backwards-compatibility may come from Python users. As Python gains popularity (and it is gaining popularity), more and more individuals and organizations build Python projects, they may find Python's approach unappealing.

Let's see what happens!

Monday, April 20, 2015

How long do programming languages stay popular?

Programming languages come and go. Some are more popular than others. Some are popular longer than others.

So just how long do programming languages stay popular?

I mean this in a very specific sense, one that is different from the general popularity of programming languages. The folks at www.tiobe.com have studied popularity in great detail, but they are considering all uses of programming languages.

There are many languages. Some, like COBOL and Fortran have been with us for ages. One can argue that their popularity has extended from the 1950s to today, or over sixty years. But much of the demand for those languages is existing systems. Very few people today (I believe) start new endeavors with COBOL.

If we look at the languages used for start-ups and new projects, we see a pattern for the popularity of languages. That pattern is:

1950s: IBM System/360 Assembly
1960s: IBM System/360 Assembly, COBOL, Fortran
1970s: COBOL, Fortran, RPG
1980s: PC Assembly, BASIC, C
1990s: C++, Visual Basic, Java, Perl
2000s: Java, C#
2010s: Python, Ruby, JavaScript

This list is not comprehensive. I have kept the list small, to focus on the big languages. There were lots of other languages (Dibol, Focal, PL/I, Ada, Awk, Forth, etc) that were used for projects, but they were never mainstream. Apologies if I have omitted your favorite language.

Looking at my selected "winners" of languages, we see a pattern: Languages are popular (for new projects) for a period of perhaps ten to fifteen years. Early languages such as IBM System/360 Assembler and COBOL have longer lives.

BASIC is an interesting case. It had popularity in the 1980s and then a second life as Visual Basic in the 1990s. Its first incarnation was as a general-purpose language for programming the original microcomputers (Apple II, Commodore PET and C-64, Radio Shack TRS-80, etc.). Its second life was as a general-purpose language for Windows.

All of these languages had a heyday of a little more than a decade. COBOL and Fortran fell to BASIC. BASIC mutated into Visual Basic and eventually fell to Java and C#. Perl emerged, had success, and has been replaced by Python.

Which leads us to an interesting point. We're now at Java's twentieth anniversary, and C#'s fifteenth. According to my theory, these languages should be on the wane -- for new projects. Certainly there are lots of existing Java systems and lots of existing C# applications. But what languages are people using for new systems?

Informal conversations with fellow developers indicates that new projects are using neither Java nor C#. Instead, new projects (or start-up companies) are using Python, Ruby, and JavaScript.

It may be, in the near future, that we will see conversion projects from Java and C# to newer languages.

Thursday, February 26, 2015

The names of programming languages

A recent project involved a new programming language (a variant of the classic Dartmouth BASIC) and therefore saw the need for a name for the new language. Of course, a new name should be different from existing names, so I researched the names of programming languages.

My first observation was that we, as an industry, have created a lot of programming languages! I usually think of the set of languages as BASIC, FORTRAN, COBOL, Pascal, C, C++, Java, C#, Perl, Python, and Ruby -- the languages that I use currently or have used in the past. If I think about it, I add some other common languages: RPG, Eiffel, F#, Modula, Prolog, LISP, Forth, AWK, ML, Haskell, and Erlang. (These a programming languages that I have either read about or discussed with fellow programmers.)

As I surveyed existing programming languages, I found many more languages. I found extinct languages, and extant languages. And I noticed various things about their names.

Programming languages, except for a few early languages, have names that are easily pronounceable. Aside from the early "A-0" and "B-0", most languages have recognizable names. We switched quickly from designations of letters and numbers to names like FORTRAN and COBOL.

I also noticed that some names last longer than others. Not just the languages, but the names. The best example may be "BASIC". Created in the 1960s, the BASIC language has undergone a number of changes (some of them radical) and has had a number of implementations. Yet despite its changes, the name has remained. The name has been extended with letters ("CBASIC", "ZBASIC", "GW-BASIC"), numbers ("BASIC-80", "BASIC09"), symbols ("BASIC++"), prefix words ("Visual Basic", "True Basic", "Power Basic"), and sometimes suffixes ("BASIC-PLUS"). Each of these names was used for a variant of the original BASIC language, with separate enhancements.

Other long-lasting names include "LISP", "FORTRAN", and "COBOL".

Long-lasting names tend to have two syllables. Longer names do not stay around. The early languages "BACAIC", "COLINGO", "DYNAMO", "FLOW-MATIC", "FORTRANSIT", "JOVIAL", "MATH-MATIC", "MILITRAN", "NELIAC", and "UNICODE" (yes it was a programming language, different from today's character set) are no longer with us.

Short names of single letters have little popularity. Aside from C (the one exception), other languages (B, D, J) see limited acceptance. The up-and-coming R language for numeric analysis (derived from S, another single-letter language) may have limited acceptance, based on the name. It may be better to change the name to "R-squared" with the designation "R2".

Our current set of popular languages have two-syllable names: "VB" (pronounced "vee bee"), "C#" ("see' sharp"), Java, Python, and Ruby. Even the database language SQL is pronounced "see' kwell" to give it two syllables. Popular languages with only one syllable are Perl (which seems to be on the decline) C, and Swift.

PHP and C++ have three names with syllables. Objective-C clocks in with a possibly unwieldy four syllables; perhaps this was an incentive for Apple to change to Swift.

I expect our two-syllable names to stay with us. The languages may change, as they have changed in the past.

As for my new programming language, the one that was derived from BASIC? I picked a new name, not a variant of BASIC. As someone has already snagged the name "ACIDIC", I chose the synonym alkaline, but changed it to a two-syllable form: Alkyl.

Thursday, March 6, 2014

I thought I knew which languages were popular

An item on Hacker News lead me to a blog post by the folks at Codacy. The topic was "code reviews" and they specifically talked about coding style. The people at Codacy were kind enough to provide links to style guidelines for several languages.

I expected the usual suspects: C, C++, Java, C# and perhaps a few others.

Here's the list they presented:

  • Ruby
  • Javascript
  • Python
  • PHP

My list was based on the "business biggies", the languages that are typically used by large businesses to "get the job done". Codacy is in business too, so they are marketing their product to people who can benefit from their offerings. In other words, this is not an open-source, give-it-away-free situation.

Yet they list languages which are not on my "usual suspects" list. All of their languages are not on my list. And none of my languages are on their list. The two lists are mutually exclusive.

The languages that they do list, I must admit, are popular and mature. Individuals and companies use them to "get the job done". Codacy thinks that they can operate their business by focussing on these languages. (Perhaps they have plans to expand to other languages. But even starting with this subset tells us something about their thought process.)

I'm revising my ideas on the languages that businesses use. I'm keeping the existing entries and adding Codacy's. In the future, I will consider more than just C, C++, Java, and C#.

Sunday, January 26, 2014

Where has all the COBOL gone?

COBOL.

The language of the ancients. The workhorse of accounting systems. The technology that runs business. The most popular programming language in the 1960s (and possibly 1970s and 1980s, depending on how one measures popularity).

Where has it gone? More specifically, where have the systems written in COBOL gone?

Demand for COBOL programmers has been declining. Not just this year, but over the better part of the past ten years -- and possibly longer than that. Consider the statistics reported by the site indeed.com:



COBOL Job Trends graph


COBOL Job Trends
Cobol jobs



This link renders an image created in real-time, so your view may differ from mine. But my view shows a steady decrease in the requests for COBOL programmers, from 2006 to 2014.

COBOL was the language used for business systems. It powered accounting systems, payroll systems, invoicing systems, inventory, and reporting for businesses ranging from insurance to telephone to banking to manufacturing. Those businesses are still here (although perhaps spread around the world) and I expect that those accounting systems, payroll systems, and invoicing systems are still with us. (At least, I still get paychecks and bills still arrive.)

I have two theories about this decline:

1) The demand for COBOL remains steady in absolute terms; it is declining as a percentage of the overall technology market.

2) The demand for COBOL is truly declining; the use of COBOL is declining.

With the first theory, systems written in COBOL remain in use. They are maintained as usual, and the demand for COBOL programmers remains steady. The decline of COBOL is a decline in market share, as other languages grow. Certainly the use of C++, C#, and Java have increased over the past decades. One can clearly see the market for Visual Basic in the 1990s. These other languages expand the "pie" and COBOL is growing at a rate less than the market growth.

The second theory is, I believe, the correct one: The demand for COBOL is declining. This can be caused by only one thing: a reduction in the number of COBOL systems.

Systems written in COBOL need a certain amount of maintenance. This maintenance is caused by forces exterior to the system owners: changes in market, changes in technology, and changes in legislation. Thus with a decline of COBOL demand, I can reasonably conclude that there is a decline in the number of COBOL-based systems.

But the functions performed by those old COBOL systems remain. We're still getting bills, in case you hadn't noticed. The bills may be electronic notifications and not paper invoices, but some system is generating them.

Given that the functions are being performed, there must be a system to perform them. (I highly doubt that companies have abandoned computers in favor of people.) Those systems are written in something other than COBOL. The question then becomes... which language?

A better question may be: is there a single language for the business community? Have companies gravitated to a new leader in technology? Or is the business community becoming fragmented?

I've seen nothing of a "new business standard", so I assume that the business community is splitting. The new languages for business are probably C# and Java. Small portions of the business world may be using other languages such as C, Objective-C, JavaScript and node.js, Python, or even F# or Haskell.

Getting back to COBOL. If I'm right about these new languages, then we may have seen "peak COBOL", with the glory of COBOL behind it. That gives us in the industry an opportunity.

The IT age is more than half a century old. We've seen technologies come and go. Not just hardware, but also software. The rise and decline of the big languages (COBOL, BASIC, Visual Basic) may tell us about the rise and decline of other popular technologies, some which are still in the "rise" phase (perhaps tablets).

Perhaps COBOL can still teach us a thing or two.

Thursday, December 5, 2013

The future popularity of languages

The popularity of a programming language matters. Popular languages are, well, popular -- they are used by a large number of people. That large user base implies a large set of available programmers who can be hired (important if you are running a project), a large set of supporting documents and web sites (important for managers and hobbyists), and significant sales for tools and training (important if you sell tools and training).

But there are two senses of popular. One sense is the "lots of people like it now" sense; the other is "lots of people will like it in the future" sense. This distinction was apparent at the beginning of my career, when PCs were new and the major programming languages of COBOL and FORTRAN were not the BASIC and Pascal and C of the PC revolution.

COBOL and FORTRAN were the heavyweights, the languages used by serious people in the business of serious programming. BASIC and Pascal and C (at least on PCs) were the languages of hobbyists and dreamers, "toy" languages on "toy" computers. Yet it was C that gave us C++ and eventually Java and C#, the heavyweight languages of today.

The measurements of language popularity blur these two groups of practitioners and dreamers. The practitioners use the tools for established systems and existing enterprises: in the 1970s and 1980s they used COBOL and today they use C++, C#, and Java. The dreamers of the 1970s used BASIC, C, Forth, and Pascal; today they use... well, what do they use?

The Programming Language Popularity web site contains a number of measures. I think that the most "dreamish" of these is the Github statistics. Github is the site for open source projects of all sizes, from enterprise level down to individual enthusiast. It seems a better measure than the "Craigslist" search (which would be weighted towards corporate projects) or the "Google" search (which would include tutorials and examples but perhaps little in the way of dreams).

The top languages in the "Github" list are:

  • Objective C
  • JavaScript
  • Ruby
  • Java
  • Python
  • PHP

A little later down the list (but still in the top twenty) are: Scala, Haskell, Clojure, Lua, and Erlang.

I think that the "Github" list is a good forward indicator for language popularity. I believe that some of these languages will be the future mainstream development languages.

Which ones exactly, I'm not sure.

Java is already a mainstream language; this index indicates a continued interest. I suspect JavaScript will have a bright future quite soon, with Microsoft supporting it for app development. Apple iOS uses Objective-C, so that one is also fairly obvious.

Languages rise and fall in popularity. Project managers would do well to track the up-and-coming languages. Software tends to live for a long time; if you want to stay with mainstream programming languages, you must move with the mainstream. Looking ahead may help with that effort.

Sunday, October 20, 2013

Java and Perl are not dead yet

Are Java and Perl dead?

The past few weeks have seen members of the Java community claim that Java is not dead. They have also seen members of the Perl community claim that Perl is not dead.

Many developers may want Perl to die (or Java to die, or COBOL to die) but when members of the community claim "X is not dead" then we should review the health of X.

The industry has seen many languages come and go. Of all the languages that we have seen since the beginning of the computer age, most are dead. Don't take my word; consider the languages documented by Jean Sammet in the late 1960s. They include: A-2, A-3, ADAM, AED, AIMACO, Algol, ALTRAN, AMBIT, AMTRAN, APL, and APT (and that is just the entries under 'A'). Of these, the only language that can be said to be alive today is Algol -- and even that is pushing the definition of 'alive'.

Languages die. But not all -- popular languages live on. Long-lasting languages include COBOL, Fortran, C, C++, and Perl. One could add Java and C# to that list, depending on one's definition of "long-lasting". (I think that there is no debate about their popularity.)

Back to Java and Perl.

I think that Java and Perl are very much alive, in that many projects use them. They are also alive in that new versions are built and released by the maintainers. Perl is an open source language, supported by its community. Java is supported by Oracle.

But Java and Perl are, perhaps, not as popular as they used to be. When introduced, Java was a shiny new thing compared to the existing C++ champion. Perl's introduction was quieter and it developed a following slowly. But slow or fast, they were considered the best in programming: Java for object-oriented programming and Perl for scripting.

Today, Java and Perl have competition. Java has C#, a comparable language for object-oriented programming. It also has the JVM languages Scala and Lua (and others) that have taken the "shiny new thing" title away from Java. Perl has competition from Python and Ruby, two other capable scripting languages.

Java and Perl are no longer the clear leaders. They are no longer the "obvious best" languages for development. When starting a new project, people often pick one of the competition. I think that it is this loss of "obvious best" position that is causing the angst in their respective development communities.

Now, Java and Perl are still capable programming languages. I wouldn't abandon them. For projects that use them today, I would continue to use them.

For new projects... I would consider my options.

Monday, May 20, 2013

Where do COBOL programmers come from?

In the late Twentieth Century, COBOL was the standard language for business applications. There were a few other contenders (IBM's RPG, assembly language, and DEC's DIBOL) but COBOL was the undisputed king of the business world. If you were running a business, you used COBOL.

If you worked in the data processing shop of a business, you knew COBOL and programmed with it.

If you were in school, you had a pretty good chance of being taught COBOL. Not everywhere, and not during the entire second half of the century. I attended an engineering school; we learned FORTRAN, Pascal, and assembly language. (We also used the packages SPSS and CSMP.)

Schools have, for the most part, stopped teaching COBOL. A few do, but most moved on to C++, or Java, or C#. A number are now teaching Python.

Business have lots of COBOL code. Lots and lots of it. And they have no reason to convert that code to C++, or Java, or C#, or the "flavor of the month" in programming languages. Business code is often complex and working business code is precious. One modifies the code only when necessary, and one converts a system to a new language only at the utmost need.

But that code, while precious, does have to be maintained. Businesses change and those changes require fixes and enhancements to the code.

Those changes and enhancements are made by COBOL programmers.

Of which very few are being minted these days. Or for the past two decades.

Which means that COBOL programmers are, as a resource, dwindling.

Now, I recognize that the production of COBOL programmers has not ceased. There are three sources that I can name with little thought.

First are the schools (real-life and on-line) that offer courses in COBOL. Several colleges still teach it, and several on-line colleges offer it.

Second is offshore programming companies. Talent is available through outsourcing.

Third is existing programmers who learn COBOL. A programmer who knows Visual Basic and C++, for example, may choose to learn COBOL (perhaps through an on-line college).

Yet I believe that, in any given year, the number of new COBOL programmers is less than the number of retiring COBOL programmers. Which means that the talent pool is now at risk, and therefore business applications may be at risk.

For many years businesses relied on the ubiquitous nature of COBOL to build their systems. I'm sure that the managers considered COBOL to be a "safe" language: stable and reliable for many years. And to be fair, it was. COBOL has been a useful language for almost half a century, a record that only FORTRAN can challenge.

The dominance of COBOL drove a demand for COBOL programmers, which in turn drove a demand for COBOL training. Now, competing languages are pulling talent out of the "COBOL pool", starving the training. Can businesses be far behind?


If you are running a business, and you rely on COBOL, you may want to think about the future of your programming talent.

* * * * *

Such an effect is not limited to COBOL. It can happen to any popular language. Consider Visual Basic,  a dominant language in Windows shops in the 1990s. It has fallen out of favor, replaced by C#. Or consider C++, which like COBOL has a large base of installed (and working) code. It, too, is falling out of favor, albeit much more slowly than Visual Basic or COBOL.