• Green vs. Brown Programming Languages
  • By Adam Gordon Bell
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: chzh9311
  • Proofread: Kimhooo, PingHGao, PassionPenguin, Chorer

“Green” and “brown” programming languages

data

Stack Overflow’s Developer Survey 1 is an important source of information on how developers are working. I recently analyzed the results of the 2020 survey to determine what languages we should add to the documentation of integrated distributions. I found some interesting conclusions about which programming languages people prefer that seem to be missing from many discussions of programming language preferences.

The results include a ranking of the most feared programming languages and the most popular. They come from the same question:

In what programming, scripting, and markup languages have you done most of your development work in the past year? Which language do you want to work in in the coming year? (Check both boxes on that line if you are already working in the language and wish to continue using it.)

A feared language is a language you mostly use this year but don’t want to use anymore, while a popular language is a language you mostly use and want to keep using. These results are interesting because they reflect the idea that developers who primarily use the language should not be influenced by the “I heard it was great” mentality — that is, people don’t give high marks to languages they don’t use just because they’re popular. The reverse is also true: the people who put languages on the fear list are also the people who use them. They fear the language not because they hear it’s complicated, but because they actually feel pain in using it.

TOP 15 most Feared Languages:

VBA, Objective-C, Perl, Assembly, C, PHP, Ruby, C++, Java, R, Haskell, Scala, HTML, Shell and SQL.

TOP 15 most popular languages:

Rust, TypeScript, Python, Kotlin, Go, Julia, Dart, C#, Swift, JavaScript, SQL, Shell, HTML, Scala and Haskell.

Can you spot a pattern in this list?

The code that was written before I got involved was the worst

The old code is the worst. If you were to find me a file from a codebase that’s been under development for more than three years, you’d find it hard to track down. Initially a straightforward file-fetching layer, the development process gradually added special cases, performance optimizations, and various branches controlled by setting options. Code in the real world needs to iterate based on market requirements, and as it does so, it becomes more complex and difficult to understand. The reason behind this phenomenon is simple. I first heard it from Joel Spolsky.

The reason developers think old code is a mess can be traced back to one of the most basic of programming laws: it’s harder to read code than to write it.

— Joel Spolsky, Things You Should Never Do, Part I

We could call it Joel’s law. A lot of things follow this premise. Why is it that most developers think the code they inherit is a mess and want to get rid of it and rewrite it? That’s because, cognitively speaking, writing a new program is much easier than reading a written code base, at least initially. Why do so many rewrite efforts fail? That’s because most of the statements that make your code look messy are actually crucial little improvements that add up over time. If you simplify the code without planning, you’ll end up back where you started.

Comic book by Scott Adams. ① The project I was working on had terrible code. I need to start all over again. ② Wouldn’t an engineer say, “That last guy did a great job. Let’s keep his job “? ③ I wish the idiot you hired to replace me would say so.

It’s easy to understand the code you’re writing. You are constantly implementing and improving the code. But it can be difficult to understand what code has been written just by reading it. If you look back at old code you’ve written and find it hard to understand, it’s probably because you’ve grown as a developer and can write it better. But it’s also possible that the code is inherently complex, and you blame the pain of understanding that complexity on the quality of the code itself. Could this be the cause of the PR backlog? PR checking is a read-only job, and if you don’t have a working model of the current code in mind, it’s hard to do it well.

That’s why you’re afraid of it

If a lot of real-world code can be wrongly messed up, can programming languages be wrongly messed up too? If you were writing new programs in Go and had to maintain a very complex 20-year-old C++ code base, would you rank the two languages fairly? I think this is what the questionnaire is actually assessing: the feared language is often used for existing brownfield projects 5, while the popular language is more often used for brand-new greenfield projects 6. Let’s verify this. 2

Measure the brown and green language

The TIOBE index claims to measure programming languages by “the number of skilled engineers, courses and jobs available worldwide.” The way they measure it may be problematic, but it’s accurate enough for our purposes. We used the TIOBE index from July 2016 (the earliest data available on the Wayback Machine) as a proxy for a programming language that already had a lot of code to maintain. If there is a big statistic for 2016, it is more likely that people are maintaining programs written in that language than assuming that the corresponding language is not popular in 2016.

Their top 20 programming languages for July 2016 are: Java, C, C++, Python, C#, PHP, JavaScript, VB.NET, Perl, Assembly, Ruby, Pascal, Swift, Objective-C, MATLAB, R, SQL, COBOL and Groovy. We can use this ranking as a list of more languages that are used for maintenance work. And they call these “brown languages.” Languages that didn’t make the top 20 in 2016 were used more for new projects. We call these languages “green languages”.

Of the 22 languages that appear on the dreaded and popular lists, 63% are brown.

Brown language: The language more commonly used when maintaining existing software (i.e., brownfield projects).

Java, C, C++, C#, Python, PHP, JavaScript, Swift, Perl, Ruby, Assembly, R, Objective-C and SQL

Green language: the language more commonly used in new projects (i.e. greenfield projects).

Go, Rust, TypeScript, Kotlin, Julia, Dart, Scala and Haskell

TIOBE and Stack Overflow disagree on what a programming language is. To solve this problem, we need to standardize by removing HTML/CSS, Shell scripts, and VBA from both lists. 3

Languages removed: TIOBE and Stack Overflow disagree on these languages.

VBA, Shell, HTML/CSS

This simple green/brown one-size-fits-all approach loses a lot of detail — I expect to write more greenfield projects in Swift than IN Objective-C, for example — but it does seem to reflect the information we need effectively. There are more brown languages on the list than green, which is not surprising given that programming languages change relatively little from year to year.

Now we can answer the question: Do people really love and fear the programming language itself as much as they say they do, or are they just afraid of years and years of code? Or to put it another way: If Java and Ruby came out today and there weren’t so many old-framework apps and old enterprise-class Java applications to maintain, would they still look awful? Or are they more likely to appear on popular lists?

The dreaded brown programming language

Language to fear: 83% brown.

The most feared languages are almost always brown. Of all the languages we counted, 68 percent were brown, whereas in the dreaded language it reached 83 percent, which was higher than the random allocation.

Popular green programming language

Popular programming languages: 54% green.

Of the most popular languages, 54 percent are green. Only 36% of the languages we count are green, and every green programming language has a place in the popular list.

Another flaw of human nature is that everyone wants to build something and nobody wants to maintain it.

– Kurt Vonnegut

This may not be enough to explain the fear of having to maintain projects in this language, but it does seem to be a motivating factor. Many of people’s favorite programming languages are too young or short-lived to have as many bloated projects to maintain.

In other words, Rust, Kotlin, and other green programming languages may still be in their honeymoon phase. The favorability of working with these languages probably has a lot to do with not having to maintain a 20-year-old code base, as certain languages have to.

To overcome prejudice

Some new or previously unpopular languages may be better than older or more mainstream ones, but our judgments seem to be swayed by bias. In effect, developers put a halo on new or previously unused languages, treating them as angels, and put a corner on long-established languages, treating them as demons. I think it’s because no one wants to defend anyone else’s job. Moreover, as Joel’s Law describes, it’s hard to read actual code. Building new things is fun, and emerging languages are more often used for that kind of fun work.

Programming language wind review lifecycle

I started digging into this data to publish a ranking of programming language usage and popularity among developers. I was going to use these conclusions as a guide to add examples to our documentation and build samples. Somewhere along the way, however, I had a few thoughts about the programming language lifecycle: popular programming languages are used all the time, which leads to code maintenance, which leads to people hating the language, which leads to people looking for newer projects and trying newer languages. Popular frameworks probably fit into this lifecycle as well.

Programming language wind review lifecycle

I don’t have the numbers for this chart, but I do remember that Ruby was the most popular language in 2007, and Ruby is much better than it used to be, even now that it has more competitors. Now, however, it has become disliked. One of the differences seems to me to be that now people have 14 years of applications to maintain. This makes Ruby a lot less fun than it was when it was all new projects. So beware Rust, Kotlin, Julia, and Go: you will eventually take off the halo you put on them. 4

  1. Graphic and raw results for 2020.

  2. I came up with this standard first. I’m not looking for data to back up my argument.

    I did consider using birth dates to distinguish between green and brown languages, but some languages have been around for a while and have only recently come into use.

    TIOBE measures this way, and their historical data is paid for, so I used the Wayback Machine.

  3. TIOBE does not measure HTML/CSS because it believes that these languages are not fully developed and therefore not programming languages. As far as I know, Shell scripts are categorized separately by TIOBE, and VBA is not on the list of languages they measure at all.

  4. Not all brown languages are feared, however: Python, C#, Swift, JavaScript and SQL are still popular, and if anyone can explain why, I’d love to hear it. Also, Scala and Haskell, two of my favorites, are the only green languages on the dreaded list. Is it just noise or is there something else going on?

  5. Brownfield projects are projects that need to be developed based on existing software systems. This means that new software systems developed must consider compatibility with existing software. (Source: Brownfield (Software Development) – Wikipedia)

  6. Greenfield projects are projects that are not tied down by previous work. In software engineering, it can be developing a system for a completely new environment without having to worry about compatibility with other systems. (Source: Greenfield Project – Wikipedia)

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.