The Least Liked Programming Languages

StackOverflow’s 2020 developer survey included a table showing the  “most loved, dreaded, and wanted languages.” Loved and wanted languages are, well, sort of boring. The programming languages we dread are a lot more interesting. As Tolstoy said, “All happy families are alike; each unhappy family is unhappy in its own way.”

So what are these unhappy, unloved languages, and why do programmers dread using them? Given the chance it’s, well, hard to resist jumping in with some theories, and perhaps even saying something impolitic.  Or defending some languages that are disliked for the wrong reasons.

More precisely, StackOverflow tabulated the “% of developers who are developing with the language or technology but have not expressed interest in continuing to do so.” That doesn’t sound quite as dire as “dreaded”; “not expressing an interest in working with a language again” is a rather vague indication of dread. There are lots of things I’ve done that I’d rather not do again, including writing troff macros that spawned shell scripts. But we won’t worry about that, will we?

The list of least liked languages is similar to the lists of the most widely used languages, as indicated by Redmonk, Tiobe and, for that matter, searches on O’Reilly Learning. That’s no surprise; Bjarne Stroustrup said that “there are only two kinds of languages: the ones people complain about and the ones nobody uses.” And that makes a lot of sense, at least in relation to this survey. If you’ve got millions of users, it’s not hard to get a lot of people to dislike you. So seeing perennials like C alongside relative newcomers like Java on the list of disliked languages isn’t surprising.

Kevlin Henney and I thought that the list of least liked languages also reflected the opinions of programmers who were working on large and legacy projects, as opposed to short programs. Dislike of a language may be “guilt by association”: dislike of a large, antiquated codebase with minimal documentation, and an architectural style in which every bug fixed breaks something else. Therefore, it’s not surprising to see languages that used to be widely used but have fallen from popularity on the list. And it’s also easy to fall in love with a quirky language that was perfect for one project, but that you’ll never see again.  (In my case, that’s Icon. Try it; you might like it. It’s not on anyone’s list.)

What’s most surprising is when a language is out of place: when it’s significantly more or less disliked than you expect. That’s what I’d like to think about. So, having disposed of the preliminaries, here are a few observations:

• Java: Java has been the language people love to hate since its birth. I was at the USENIX session in which James Gosling first spoke about Java (way before 1.0), and people left the room talking about how horrible Java was–none of whom had actually used the language because it hadn’t been released yet. Java comes in to this survey at a mild #9. Given Java’s reputation, that 9 should have hearts all over it.
  
  If there’s one language on this list that’s associated with gigantic projects, it’s Java.  And there are a lot of things to dislike about it—though a lot of them have to do with bad habits that grew up around Java, rather than the language itself. If you find yourself abusing design patterns, step back and look at what you’re doing; making everything into a design pattern is a sign that you didn’t understand what patterns are really for. (If you need a refresher, go to Head First Design Patterns or the classic Gang of Four book.) If you start writing a FactoryFactoryFactory, stop and take a nice long walk. If you’re writing a ClassWithAReallyLongNameBecauseThatsHowWeDoIt, you don’t need to. Java doesn’t make you do that.  Descriptive names are good; ridiculously long names (along with ridiculously deep package hierarchies) are not. I’ve always tried to put one coherent thought on each line of code. You can’t do that when the names are half a line long. But that’s not Java’s fault, it’s an odd cultural quirk of Java programmers.
  
  Java is verbose, but that’s not necessarily a problem. As someone who is not a Java fan told me once, all those declarations at the start of a class are actually documentation, and that documentation is particularly important on big projects. Once you know what the data structures are, you can make a pretty good guess what the class does. I’ve found Java easier to read and understand than most other languages, in part because it’s so explicit—and most good programmers realize that they spend more time reading others’ code than writing their own.

• Ruby: I was very surprised to see Ruby as the #7 on the list. Ruby more disliked than Java?  What’s going on? I’ve had some fun programming in Ruby; it is, for the most part, a “do what I meant, not what I said” language, and 15 years ago, that promise made lots of programmers fall in love.
  
  But if we think about Ruby in the context of large systems, it makes sense. It’s not hard to write code that is ambiguous, at least to the casual observer. It’s very easy to run afoul of a function or method that has been “monkeypatched” to have some non-standard behavior, and those modifications are rarely documented. Metaprogramming has been used brilliantly in frameworks like Rails, but I’ve always been bothered by the “And now the magic happens” aspect of many Ruby libraries. These aren’t features that are conducive to large projects.
  
  Many years ago, I heard someone at a Ruby or Rails conference say “There aren’t any large projects; everything in Ruby takes 90% fewer lines of code.” I’ve always thought LOC was a foolish metric. And even if you believe that Ruby takes 90% fewer lines of code (I don’t), 10% of a big number is still a big number, particularly if it’s your responsibility to digest that code, including things happening behind your back.  Ruby is a lot of fun, and I still use it for quick scripts (though I’ve largely switched to Python for those), but is it the language to choose for a big project? That might have me running in fear.

• R: R weighs in at #10 on the “dreaded list.” I think that’s because of a misperception. R both is, and is not, a general-purpose programming language. Several statisticians have told me “You programmers don’t get it. R is a statistics workbench, not a programming language. It’s not a weird version of Python.” I’ve played around with R any number of times, but I finally “got it” (well, at least partly) when I read through the R tutorial in Vince Buffalo’s Bioinformatics Data Skills. Loops and if statements are relegated to a couple of pages at the end of the tutorial, not one of the first concepts you learn. Why? Because if you’re using R correctly, you don’t need them. It’s designed so you don’t have to use them.  If you come from a more traditional language, you may find yourself fighting against the language, not working with it. There are better approaches to conditional logic and iteration.
  
  It also helps to use the best tools and libraries available: RStudio is a really nice integrated development environment for R, and the Tidyverse is a great set of libraries for working with data. Ironically, that may even be part of the problem: with excellent graphics libraries and web frameworks, R suddenly looks a lot less like a specialized statistics workbench, and more like a general-purpose workhorse.
  
  Lots of programmers seem to be taking another look at R–perhaps to analyze COVID data?  R jumped from #20 on the Tiobe index to #8 in the July, 2020 report. That’s a huge change. Whatever the reason, R will be a much more pleasant environment if you work with it, rather than against it. It is very opinionated–and the opinions are of a statistician, rather than a programmer.

• Python: Python is #23 on the list—extraordinarily low for a language that’s so widely used. Python is easy to like; I could love Python just for getting rid of curly braces. But aside from that, what’s to love? I’ve always said “don’t choose the language, choose the libraries,” and Python has great libraries, particularly for numerical work. Pandas, Numpy, Scipy, and scikit-learn are good reasons to love Python, all by themselves. Features like list comprehensions eliminate a lot of the bookkeeping associated with traditional control structures. Python is as good for tasks that are quick and dirty as it is for bigger projects. If I want to do something with a spreadsheet, I almost always hack at it with Python. (Me? Pivot tables?) And tools like Jupyter make it easy to record your experimentation while you’re in the process.
  
  On the “big project” end of the scale, Python is easy to read: no eyeburn from nested curly braces or parens, and fewer levels of nesting thanks to comprehensions, maps, and other features.  It has reasonable (though admittedly quirky) object-oriented features. I’ve gone back to some of my older loopy scripts, and frequently been able to write them without loops at all. If you want to put one coherent thought on a line, that’s the best of all possible worlds.
  
  An important slogan from “The Zen of Python” is “Explicit is better than implicit”; you’re very rarely left guessing about what someone else meant, or trying to decipher some unexpected bit of magic that “happened.” Python wins the award for the most popular language to inspire minimal dislike. It’s got a balanced set of features that make it ideal for small projects, and good for large ones.

• JavaScript: And what shall we say about JavaScript, sixteenth on the list? I’ve got nothing. It’s a language that grew in a random and disordered way, and that programmers eventually learned could be powerful and productive, largely due to Doug Crockford’s classic JavaScript: The Good Parts. A language that’s as widely used as JavaScript, and that’s only 16th on the list of most dreaded languages, is certainly doing something right.  But I don’t have to like it.
  
  There’s lots more that could be said.  There’s no surprise that VBA is #1 disliked language.  I’ll admit to complete ignorance on Objective C (#2), which I’ve never had any reason to play with. Although I’m a Perl-hater from way back, I’m surprised that Perl is so widely disliked (#3), but some wounds never heal. It will be interesting to see what happens after Perl 7 has been out for a few years. Assembly (#4) is an acquired taste (and isn’t a single language).  If you don’t learn to love it, you pretty much have to hate it. And if you don’t love it, you really shouldn’t be using it. You can almost always avoid assembly, but when you need to work directly with the hardware, there’s no alternative.  C and C++ (#5 and #8, respectively) give you a lot of rope to hang yourself, but get you as close enough to the hardware for almost any project, without the pain of assembly.  Are they fading into the past, or will they be with us forever?  My guess is the latter; there are too many projects that demand C’s performance and ubiquity. It’s the foundation for just about everything important in modern computing.

Speculating about languages and why they’re liked or disliked is fun.  It may or may not be useful.  Take it for what it’s worth.

from Radar https://ift.tt/2ChEZOB