The articles theory that old code is what determines if a language is loved / dreaded is really severely flawed. 5 of the most loved languages are ancient (Python, JS, Sql, Shell, HTML) and also all have reputations of having hacked (i.e. poor maintability) together code.
Additional the top loved programming languages are beyond 10 years old which means there's going to be plenty of 3yr old codebases for people to be programming in. So quite trivially it's not that the languages are too new to have old crusty codebase ...
> The TOP 15 Loved Programming Languages
> Rust, TypeScript, Python, Kotlin, Go, Julia, Dart, C#, Swift, JavaScript, SQL, Shell, HTML, Scala, and Haskell.
Rust is 2015 (8 years), TS is 2012 (10 years), Python is 1991 (32 years), Kotlin is 2011 (12 years), Go is 2009 (13 years), Julia is 2012 (11 years), Dart is 2011 (11 years), C# is 2000 (23 years ago), Swift is 2014 (9 years ago), JS is 1995 (27 years), SQL is 1970?? (50 years), HTML is 1993 (30 years), Scala is 2004 (19 years), and Haskell is 1990 (33 years).
---
ObjC and or Swift really should be in the Green languages column as well; what's he going to do new projects on iOS using? I think also many people would keep Java / C#|C++ in the Green column as well. SQL also would be in the green column. Moving 3 languages from Brown to Green really skews the later pie charts.
You're missing the important point that in OP's hypothesis, it doesn't matter how old the language is, but how long it's been popular.
Python and Dart, for example, have been much more popular recently than in the past, so it's reasonable to assume that the percentage of newer code bases in those languages is higher than in, say, Java. Python may have been popular already 10 years ago, but it feels like back then it was mostly used for small websites and scripting, things you don't normally need to maintain for a long time.
> So quite trivially it's not that the languages are too new to have old crusty codebase ...
Considering the year a language was created is missing the point the author tried to make, unfortunately, so I would say your argument is based on a flawed premise (trivially shown by reading the article and understanding it).
I think JS is the only language that goes against this, but that's quite easy to explain: it's a language used mostly for web development, where it's practically, your only choice (notice that "loved" actually means having intent to continue using it in the future).
No the author didn't read the methodology of the Stack Overflow Survey nor did they notice they can get the historical CSV of the survey going back to 2011 [1] which literally tells the number of respondents per language (as-in how popular it is; no secondary population from TIBOE needed). Nor do they seem to understand (unlike you who does understand) that Loved and Dreaded have very specific meanings.
They did shoddy work and I'm calling them out on it. They very easily could've tried to use the past (then) 9 years of data to show that as a language gets more popular it became less loved; but they didn't.
The question of "If Java and Ruby appeared today, without piles of old rails apps and old enterprise Java applications to maintain, would they still be dreaded or would they be more likely to show up on the loved list?" is answered.
It's a no. For 2020, Ruby was 4.5% and Java was 8.8% of developer's "Wanted" languages while Go (17.9%), Rust (14.6%), TypeScript (17.0%), Python (30.0% !!). Sure a lot of people would like Ruby and Java (there already are actually a lot of them) but when you're not at the top of the Wanted it's going to be very hard to get to the top of Loved.
I surmise that love or hate for a language is closely coupled with its stdlib. My favorite languages (Elixir, Rust) have some of the best standard libraries (and even, Go, for instance, includes JSON encoding and decoding in its own). This shields developers from code bases that need to constantly reinvent the wheel or pull in many dependencies for simple tasks. JavaScript is on the cusp here with a bad standard lib that has improved (in some ways) over the last 15 years.
I think a further nuance (if I'm understanding the author) is that a language you are likely to use starting from scratch is going to be more loved. While there is plenty of shell code out there, it is more common to write a shell script from scratch than it is to start a java project from scratch.
Python has been popular for 20 years, starting with Zope around 2000.
In 2003, CERN was already doing trainings for Python in scientific computing, and Grid jobs automation (what predated the cloud), I was one of the engineers that took part of the 2nd Python training, and Grid Computing Summer School 2003.
CERN build system for ATLAS/TDAQ used on those days, CMT, was written in Python.
No, I've been programming for more than 20 years and Python was definitely not popular back then. I remember early Google even bragged that they'd rather hire a Python developer than Java/C++ one, because there were no python courses so the candidate learned it by their own.
Dr. Dobb's Excellence in Programming Award in 1999
"Guido van Rossum, creator of the Python programming language, and Donald Becker, chief investigator of the Beowulf Project, which achieved supercomputer performance using networks of inexpensive Linux-based PCs. "As creator of the Python programming language," Dr. Dobb's noted, "Guido van Rossum has given software developers a tool that addresses many of the shortcomings of more well-known and mainstream languages...Python makes it extremely easy to build complex data structures out of objects, lists, dictionaries, and the like. It is particularly useful for system administration, building GUIs, scripting, database programming, and rapid prototyping." Erickson detailed Donald Becker's contributions to the programming world by describing the problem Becker set out to solve: "One of the challenges in the realm of scientific computing is to efficiently and affordably handle large data sets," Erickson wrote. "To tackle the problem, Donald Becker and Thomas Sterling launched the Beowulf Project, a cluster computer consisting of high-performance PCs built from off-the-shelf components, connected via Ethernet, and running under Linux. Ultimately, the goal of the Beowulf approach was to achieve supercomputer (gigaflop) performance at PC prices."
> Python and Dart, for example, have been much more popular recently than in the past, so it's reasonable to assume that the percentage of newer code bases in those languages is higher than in, say, Java.
And yet Python is the top fifth brown language? And also the top third loved language?
Yes. Have a look at the StackOverflow tag, Flutter hashtag on X, GitHub projects, the Youtube Flutter Channel (which has a lot of videos, with a lot of views)... it's evidently used by a lot of people, but beware it's almost all due to Flutter.
I saw Ruby and SQL in the brown box, Js in the green box and stopped reading. Just last week I was getting annoyed with js bundlers trying to get a js library to work on the browser while fighting all the mess. Still feels like a big pile of duct taped components. Not the experience I have with Perl, a "brown" language.
The 'Stack Overflow Developer Survey' is simply not a reliable source of information on what languages are popular and unpopular. Most programmers don't use Stack Overflow to the extent that they'd fill in a programming language survey. The sort of people that actively engage with internet programming forums are also the sort of people that actively engage with new programming languages.
Well said. Where I work, the only people who talk about languages and compare languages are the people who are language nerds, who know many languages and are learning/discovering new languages. Most people just chug along with whatever their job requires and provides -- the default IDEs and other tools with default settings. They may not even know the latest syntaxes/features in the language they use every day.
> They may not even know the latest syntaxes/features in the language they use every day.
Always annoying when you get an interview question of the different between an Interface and Abstract Class from somebody looking for a Java 7 answer ...
> Most people just chug along with whatever their job requires and provides -- the default IDEs and other tools with default settings.
Well, nothing wrong with doing a good job with the tools you have but if you don't ever evaluate new tools ever then you're almost certainly going to be doing things less efficient than you otherwise could.
I'm not able to find the article but IRC it's a Joel Spokeys article on every project has 3 innovation tokens and I think sometimes that should be a goal of no more but also sometimes no less. His idea was it being a maximum amount of new risk you take on; but sometimes I think it should also be considered a goal. If you're familiar with MySQL it takes 0 tokens to use but if you decide to use (new to you) Postres then it costs a token. Sure if the whole project is a short time frame it probably makes sense to only loop in 1 new technology but if its a multi-year project I think it's worth it to burn a week evaluating 3 new things on the off-chance one of them saves a week+.
> The sort of people that actively engage with internet programming forums are also the sort of people that actively engage with new programming languages.
That's a pretty bold claim... even though I think it may look like this is the case, I very much doubt you would be found correct if a proper study was ever made to find out.
> That's a pretty bold claim... even though I think it may look like this is the case, I very much doubt you would be found correct if a proper study was ever made to find out.
I don't think it's that bold.
I have a related but slightly different take: more motivated and smarter developers are more inclined to use unusual or new tooling. As a result, the new tooling's userbase is almost entirely composed of people not minding the hard path, and steep learning curve.
Even wrote a blog post about it (https://www.lelanthran.com - read the post about the average developer effect).
This makes more sense. I dread the 20yr old codebase at work but I still love C#. If not for the amazing tooling there’s no way this codebase could’ve survived this long.
I’ve worked with C# for 15ish years and it’s easily the language I hate working with the most. I understand the love it gets, I really do, but as soon as you step out of its basics and need to do something extra it becomes such a shit show of wasted hours. I still have nightmares from the 1-2 version where you basically had to build your own ASP to do anything reasonably with it, but those days have been gone for at least a decade and it’s not fair to compare with that. Even after 4.5 hit, however, you’d have to extend things to make them work the way you want, and as soon as you did that, some of the magic sometimes break.
I did some extensive AD work with it back before Runbooks and Powershell became the obvious way to do that, and while it was easy to do simple things, setting up something to admin a bunch of school devices meant rewriting a lot of the basic library because Microsoft only ever include the minimum. Which is where things got odd, because you’d expect something like filtering to work the same regardless of which AD attribute you were filtering, right? Well yeah, that’s not how the extra extended attributes work. Maybe Microsoft of the day never imagined you’d need more than the standard extended attributes, but there was just no foundation to get anything of the official AD packages to work with them back then.
In more modern days things are basically the same. We currently have an API that uses OData, and since that’s mainly a Microsoft thing on the server side as most other people went with GraphQL or are still doing special Rest endpoints, we like it on the client side. The server side has been an actual shot show though. Because despite the EntityFramework and OData libraries both being official Microsoft libraries (they even worked together better than they do now at one point) they just won’t play nice. In OData you have a “patch” functionality which basically lets you update changes in objects without doing anything yourself but since the EF and OData model builders don’t work the same way, not even for the exact same annotations, well, it doesn’t work until you rewrite half of it. And the “fun” doesn’t stop there because while .Net has UUIDv4 GUIDs they aren’t actually following the specification for UUIDv4, meaning that any GUID you generate won’t pass any non-Microsoft checks. And to make things even better, if you ever need to extend objects in your JSON in a way that improves on the OData efficiency then they will no longer be forwarded as camelCase JSON but instead as PascalCase for a reason we still have been able to figure out despite working with actual Microsoft developers on the issue…
Like I said. C# is really great for things that GPT can basically generate for you, but I’ve probably wasted at least a year of my life trying to figure out why some part of it wasn’t working the way it was supposed to in some obscure edge case. I’ve worked with a lot of languages and C# is the only one that has this “feature”.
I totally don’t understand rant about integration with AD from C# standpoint. Seems like you meant .NET Framework.
I also don’t see how any other language would do any better in manipulating Active Directory settings.
Same for ASP stuff, that is like a web framework - like for example Ruby on its own does not have anything to do with Rails as RoR is web framework for Ruby so, also really weird rant if we talk about language itself.
> I totally don’t understand rant about integration with AD from C# standpoint. Seems like you meant .NET Framework.
The C# libraries for AD integration weren't very extensive back in the day, but where the "magic" broke was when you extended the extra properties on your AD objects and then none of the AD library functions worked. This despite the fact that AD has extension attributes where it worked, it was only if you extended it.
> I also don’t see how any other language would do any better in manipulating Active Directory settings.
Back then I think it's probably debatable, and you could be right. I can't say because I'm not sure how PowerShell was back then, but I believe it wasn't as included in .NET back then, so maybe. Today I think C# is terrible for AD work. You're going to want all your AD automation and API's to be handled through orchestrated runbooks, and they only support PowerShell and Python. This is sort of by design by Microsoft though so I don't really fault them for not having good C# tooling available for AD anymore.
> Same for ASP stuff, that is like a web framework - like for example Ruby on its own does not have anything to do with Rails as RoR is web framework for Ruby so, also really weird rant if we talk about language itself.
I guess that is a fair point, but throughout my decades in the industry I've never seen anyone use C# for anything without it's frameworks. So while it's true that our problems are mainly with two frameworks, it's not like we would have ever chosen to work with C# if we didn't need it's OData framework.
I think you may be missing the point I'm trying to make though. It's not that C# is terrible, as such. While I certainly think it is a horrible language to work with, I think this because a lot of the "automation magic" the different frameworks do for you break down once you stop doing basic CRUD functionality with them. As long as things work as intended, however, it's a very likeable language and the reason I hate working with it is simply that it wastes too much of my time when it stops working. You're certainly free to write me off as you like, because you're right, all my criticism here is with the frameworks. I think the only thing I really dislike about the language itself is how "var" became the standard way to define things instead of giving them types.
I agree that dev tooling improvement has been a huge theme of the past decade, but the premise that it’s exclusive to new languages is flawed. I’m a a C++ developer and it has fantastic tooling these days: clang-format, the static analyzer, VSCode & VisualStudio, gdb & lldb, conan, godbolt, etc.
Being stuck in an old legacy codebase may be hell, and may not be — that seems independent of language, though. But writing C++ with new standards, libraries, and tools is a joy.
I'm a C++ dev also, and I don't agree with you! I use clangd, gdb, dynamic analysis tools, no static analysis tools (other than compiler warnings). The help I've gotten from Rust analyzer compared to clangd is pretty large, imho. Rust restraining itself means that our tooling gets to be more free.
Also, gdb is... Not that great. Yes, it definitely does debug my app and in that sense it is great. It is however pretty unstable and gets into weird state I cannot get out of, gdb/mi is a mess, and the text interface (TUI) is not performant enough. I'm still very happy that I have it, but when I look at RemedyBG I get jealous. I'd pay for an equivalent to RemedyBG on Linux, if it was FOSS.
It is true that writing modern C++ is much more fun than writing old C++ in the old days. The code also _looks_ better than in the old days, too, but still far from pretty.
> Let’s call this Joel’s Law. A lot of things follow from this premise. Why do most developers think the code they inherited is a mess and want to throw it out and start again? It’s because writing something new is cognitively less demanding than the hard work of understanding an existing codebase, at least initially. Why are many rewrites doomed to fail? Because much of what makes the code seem messy are vital little improvements that accreted over time. Without some plan for simplifying them, you will end up back where you started.
This is a somewhat flawed argument.
The old code probably is very bad and brittle and difficult to use and really does need a rewrite in order to grow. It was probably never designed for all the requirements it has accreted and the patches that were done were likely done with expediency and minimal-change in mind and are now hopelessly entangled.
It is also true that the person doing the rewrite _often_ doesn't have any appreciation for the complexity of the old code and the rewrite attempts to just simplify the problem while throwing out all kinds of requirements that it turns out were there for a reason.
However, it is also possible to do the actually hard work of understanding an old codebase that you didn't write and refactoring it into a better shape, while maintaining all the requirements and producing something that is more maintainable and extensible.
When can we put the "don't rewrite old code" myth to rest? People cite Joel's essay in many situations where it can be reasonably believed to be applicable, but they also cite to people who are in a much better position to determine whether it is applicable.
I've had to inherit a couple of troubled Go codebases with a lot of bugs, to the point of near-constant outages and functional incorrectness problems attributable to many different causes all throughout the codebase.
One of them was amateur work with zero tests or docs, but it was only about 10k lines of well-delineated components I could understand and rewrite one by one. The end result was effectively a total rewrite, but as Joel suggested, I always had a shippable version at any given moment.
One project was "professional" work with tons of structure and tests, but it was 70k lines for what should have been at most 15k. Worse, it wasn't delineated at all in practice; every component depended on everything else in fine detail. Even the many "interfaces" that were defined were always circumvented by various means anyway, including in tons of copy-paste unit tests that barely caught any bugs but took hours to update when trying to fix the bugs they didn't catch. This was a total writeoff and replacing it with 15k lines took less time than fixing some individual bugs in the original code.
It wasn't "Real-world code evolves to fits its niche, and as it does so, it becomes more complex and harder to understand". Sometimes people do write code more complicated and fragile than it needs to be, and often the people that do that also fail to refactor it later. The more stakes they've loaded onto their rickety mess, the harder it is to justify the risk of maintaining it, even if the steady state is abysmal.
Despite both being Go -- a language praised for its maintainability -- one of them is the kind of project that can be evolved in-place, and the other can barely even be bandaided much less meaningfully evolved. I think everyone who's maintained enough projects has seen a mix of both. People parroting that you should never rewrite either haven't worked on the second kind of project, or are just assuming that it will always be someone else's job to work on that kind of project. Either way I'm not especially persuaded.
This article was nearly 1000 words in before it defined green/brown, which seems important when you're co-opting common use phrase like green/brown. I'd wager 90% of people would open it expecting a discussion of how energy efficient two given languages were, rather than how old they are.
> The TOP 15 Dreaded Programming Languages [list that includes] Haskell, Scala, HTML, Shell, and SQL.
Okay.
> The TOP 15 Loved Programming Languages [list that also contains] Haskell, Scala, HTML, Shell, and SQL.
Hmm.
> There is a pattern in this list. Can you see what it is?
Yes… but, with all due respect to Adam, when the Venn diagram of both of those lists share 1/3rd of the languages, I really don’t think the pattern actually there is the one he expects us to see. What I see is really unreliable data.
Especially given that more than half of the overlap are DSLs rather than GPLs.
Eliminating the overlapping 5 does help your point, though I have a feeling Rust will be amongst the most dreaded once Rust is as old as VBA, Objective-C, or whatever “assembly” is… I don’t think it’s old code bases so much as it’s old languages that have accumulated a lot of cruft… the new hotness doesn’t (yet) have the cruft, but because human beings seem to inevitably want to force feature drift, it’ll inevitably gain cruft as it ages and tries to keep market share.
Tangentially, thanks for the podcast; really great work.
When I read it, I thought the overlap was the pattern, and based on my experience with Scala, I thought it supported his point well. I would dread inheriting a Scala codebase, but if I were writing a new codebase in scratch, by myself, in a vacuum, I would love to do it in Scala.
I'm not sure how Scala ended up in the green category, though. 2011-2015 I saw lots of brand-new Scala codebases. Not many since then.
Well, that's the thing. Scala is powerful and gives freedom, so it is really hit or miss.
A good Scala codebase is a pleasure to work with and is sooo much better than the best Java codebase could possibly be. But a bad Scala codebase can be horrible and be confusing to a point where you'd wish that Scala wouldn't give this freedom to developers at all.
I can't speak for all the others, but JavaScript is basically a different language than it was pre-2016. I am very good at reading modern JavaScript, but give me some 10 year old code and it's like Ye Olde English.
It's a fair and interesting read, acknowledging its own short-comings but still worthwhile. Swift is probably the biggest "mistake?"
At any rate, I think it really just boils down to their first header:
>Code Written Before I Joined Is the Worst
That's obviously impacted by what people are using and what's popular (thus the written piece) but at the end of the day that's what it really comes to.
Oh dear. This refers to both the Gartner hype cycle _and_ the TIOBE index. Still, the premise is interesting.
However, I doubt that languages have the largest effect on maintainability. It is more likely a bad team setting, tight deadlines, lack of funding, odd customer requirements, and dozens of other factors that turn a codebase into a terrible mess.
I've seen this pattern a lot in IT (in particular here on HN) - "discovering" new patterns/models (main case being Lean Development). Many times people even write about how they've found that their pattern/model can be generalized into other fields. Funny thing is that management and MBA people are often quite despised here. I think it might be because how new the industry is (and how fast it's grown - majority of software devs have not a lot of experience compared to most other industries)
But hey, even this phenomena isn't new (aka I'm just guilty of it myself). See "New Wine in Old Bottles").
Most developers prefer to spend their time writing code instead of reading code. To make long running projects that people enjoy working on, we need to make it easier to add and modify functionality while minimizing how much you have to understand about the entire system.
> It’s easy to understand code as you are writing it. You are executing it and refining it as you go. But it’s hard to understand code just by reading it after the fact.
After it's written, you can execute it and refine your mental model of it as you go, and you're relieved of the burden of having to write the code. So in theory it could be easier. The problem is programmers have an unreasonable expectation that they should be able to understand legacy code just by reading it. When it should be treated as a science project to understand a mysterious ancient artifact. Don't just stare at it and chin-scratch, probe it actively.
Oh, and the stuff they didn't document? They didn't understand it at the time, either.
An expansive Standard Library has a cost, which will be paid by your users (programmers, maybe their end users) in several ways. I see a Package Repository as almost always strictly better than such a Standard Library.
1. Unlike a Package Repository, there is only one Standard Library. Got a Goose in your stdlib? That's the Goose. Even when this Goose is completely wrong for the application, you will need to work very hard to get people to use their GoodGoose instead because Goose came with the standard library. It's not stupid, it's advanced. See C++ std::unordered_map and std::list which are - respectively - the unordered map or list you probably should not be using, but hey, they're in the standard library.
2. Unlike a Package Repository the Standard Library must chase HEAD. New shiny feature in your language is awesome for almost everybody but it makes the Goose tricky so that's going to take a bunch of work? Sorry you must fix the Goose before you can ship the shiny feature, because it's in the Standard Library. This is maybe OK if many people need a Goose, you had to fix it anyway, but in our expansive library maybe most people only need Bird, or at most Duck, and use of Goose is actually uncommon. Too bad, Goose blocks the whole feature.
3. Compatibility. Of course the other option is to remove Goose from your standard library. Merely marking it "deprecated" is different. That's maybe useful for teaching but most of the considerations still apply even though you now don't recommend using it - but in Python and I believe even in Java, gradually, they remove things from the standard library (Python calls these "Dead batteries" in reference to the "Batteries included" policy). Code which worked five, ten, fifteen years ago won't work with the latest stdlib. If you decide to pay this price it's paid by your whole language. If some third party package didn't support the new language version, it's on the community to decide whether to write a compatibility package or if that's too hard/ not worth it. But for the stdlib you own the problem.
I think a standard library is not negative, but rather acts as a multiplier for decisions. The C++ std::unordered_map designers made a bad decision (requiring buckets to be iterable) and now, like you say, it's hard to get people to use the superior absl::flat_hash_map. But if the standard library designers make a good decision -- for instance, Python's extremely well-designed dict that is fast, insertion-ordered, and forms the basis of nearly every object -- then everyone gets to reap the benefits without the cognitive overhead of figuring out what the best hash map is.
Python's current dict is reasonable by Python's standards (it's slow but not ludicrously slow, it's big but not ludicrously big and insertion ordering, though non-free, is not a great extravagance and is convenient for newbie programmers) but it wasn't so very long ago that their dict was bigger, slower and didn't preserve order. Even early Python 3's dict was like that.
There's a benefit for vocabulary types, which Python's dict clearly is. I think you could make the argument for C++ std::unordered_map if it wasn't awful and I would make that argument for std::vector even though it's not the best possible design it's fine and it's vocabulary.
And don't get me wrong, the opposite is a problem too. Python's dict isn't from their standard library it's a core language feature. Python doesn't formally have a freestanding mode so that doesn't make much a huge difference but e.g. the syntax for dict is not something a third party library could do. C++ here chooses to go out of its way not to put important stuff in the core language, so e.g. the built-in array type in C++ is garbage, it's the array from C. You can have a vaguely reasonable array type, std::array but it's from their stdlib and so can't change language syntax. Likewise tuples, the C++ rather unconvincing attempt at sum types (std::variant) and so on.
The result is that C++ falls into the Turing Tarpit where everything is possible but nothing interesting is easy, which is maybe one harder way to play Advent of Code without needing an esolang that's designed to be awful but doesn't make a lot of sense for engineering. It's too late for WG21, but don't do this at home.
The beauty of a rich standard library is that it works everywhere there is a full implementation.
I rather have a Goose than none at all, or a GoodGoose that only works when all the stars are aligned and I have made the right decision regarding what platforms to target.
Package managers have their own versions of these problems, and I would suggest that there is a balance here, but it weighs more in favor of standard libraries than you think.
Here are the package manager problems:
1. Discoverability. Need an unordered map? We've got 20 of them, all made for slightly different use cases. No, their APIs are not cross-compatible. Also, only one of them has documentation and it's only in English/Chinese.
2. Lagging HEAD. Want to develop with the most recent version of the language? Too bad, package Foo was written for Python 2 and is now broken. The maintainer of foo may get around to updating it if you pay him.
3. Compatibility. The standard library runs everywhere. Package Foo only runs on M1 Macs, and has subtle bugs on x86 machines.
4. Supply chain hell. Chances are one of your packages or one of their packages is maintained by one guy. If a core function like left_pad is slow, you're shipping inefficient code. If one of those packages decides that you need to evangelize about how Putin is bad, guess what's showing up in your logs? If one of them gets compromised, you're on the hook for the damage. This practically means a lot of audits or a lot of sleepless nights.
I skimmed, it seems to be marketing for confusing terminology
> Brown Language: A language that you are more likely to use in existing software maintenance. These projects are often called brown-field projects.
> Green Language: A language that you are more likely to use in a new green-field project.
My first thought of a "green" language was one that was the most energy efficient. They can have the "brown" language terminology but not green.
Its also strange to use a color label for something that can be thought of in temperature, their "green" is just about the hot new language, which all of the brown languages were at one time.
> There is a pattern in this list [of green and brown, or most loved and most dreaded, respectively, programming languages]. Can you see what it is?
HTML, which isn't even a programming language, is in both of them.
Just make sure your data is clean.
Also:
> Old code is the worst. Find me a file in a codebase that has been under active development for more than three years, and it will be hard to follow.
Not if the developers have basic good practices and understand how to maintain a codebase, which presupposes that they were ever allowed to do maintenance.
This is fundamentally a "manager" article, in that it summarizes a technical concept such that it seems the underlying issue is nontechnical, and it gives managers an excuse to dismiss the technical concerns programmers might have about "technical debt" or "picking the wrong language for the job" with something you can use as a handwave dismissal: "Oh, programmers always grumble about old code. It's harder to read than write, so they dislike our POS system written in pre-RAII C++ with fragile templates."
> Not if the developers have basic good practices and understand how to maintain a codebase, which presupposes that they were ever allowed to do maintenance.
I've definitely seen good intentions and supposedly good practices lead to codebases that are hard to maintain. Heck, I've contributed to the problem myself occasionally - and probably everyone has, as that maintenance experience doesn't come out of thin air.
When you look at what the turnover might be at an average org versus how long a system might be used for, it's almost guaranteed that you'll have quite a few cooks in the kitchen, with different opinions in addition to the always changing business requirements and how those might translate to a technical solution.
That said, many of the older languages are actually quite valuable for new codebases as well, because most of the problems that you'll run into have already been solved and the frameworks and libraries are both mature and have proven that they'll most likely be around for the foreseeable future.
> [...] if the developers have basic good practices and understand how to maintain a codebase, which presupposes that they were ever allowed to do maintenance [...]
In that parallel universe, they wouldn't need modern programming languages, since that universe's divine developers working unhampered by deadlines and business constraints would surely be able to write bug-free code in Fortran and C :)
I think C is a perfectly fine language for modern projects and one can write good software with it. In fact, most software I use on daily basis is written C and extremely reliable: Linux, git, xcfe, terminals, vim, etc. The software I use which is written in C++ or Python have far more issues (e.g. libreoffice or inkscape crash regularily). Python backtraces I see quite often.
Or in other words: The notion that all C software is buggy and crashes all the time simply does not match my own experience.
> This is fundamentally a "manager" article, in that it summarizes a technical concept such that it seems the underlying issue is nontechnical, and it gives managers an excuse to dismiss the technical concerns programmers might have about "technical debt" or "picking the wrong language for the job" with something you can use as a handwave dismissal
After reading the article, I had the same conclusion
> TIOBE and StackOverflow have different ideas of what a programming language is.
To be fair, the StackOverflow survey used explicitly concerns "programming, scripting, and markup languages", whereas TIOBE specifically refers only to "programming languages", and they explain how they define programming languages.[0]
Also, I suspect that if StackOverflow were to separate out programming, scripting and markup languages, HTML would be placed into the "markup language" category rather than the "programming language" category. Mostly due to its lack of Turing-completeness, which is one of the TIOBE criteria.
Not necessarily. There's going to be new code in the data. There's also a form of reinforcement learning or sort of natural selection taking place where the code selected by the user can be used to train the system and favored for showing in future suggestions.
So Rusts future is to be hated. That'll be fun to watch.
I think a missing bit critique is that a lot of the 'hated' langs are ones that started out forging a very opinionated style of doing things. Think java and classes for OOP.
I can easily imagine that. Let's say Rust 2028 finally comes up with a solution to the incompatible async and error reporting crates. There's finally one blessed way to do async and one blessed type everyone uses for E in Result. Except your codebase was started in 2020 and uses Tokio and snafu, and both are so baked-in that replacing them is too much effort.
I think it's much simpler than all this: we prefer newer languages (or most newer anything really) because we haven't seen the warts yet or we just want change. Like they say: familiarity breeds contempt.
The only one from the list you gave that doesn't make sense to me is Shell, but it's also one of the lower ranked ones. The rest could make sense since they're all likely voted on with new frameworks in mind, which means new code bases. Also, since most of those appear in the most hated as well, it shows that there's a distinct factor between those that love these languages, and those that don't. The distinguishing factor is likely the framework they're on.
Also c'mon man, some of these arguments are just made in bad faith and you know it.
I would put Python in the green camp. While it's very established, I don't think most Python code is in large codebases that are maintained for very long.
This kind of ignores the fact that there are real differences between languages. Anyone who has programmed in a few languages knows that. For instance, consider the pain of setting up projects in Python or C++ to that of Go or Rust.
Clearly intrinsic quality is a factor, and likelihood of being a greenfield project is a factor too.
He showed that more loved languages are likely to be newer. That is consistent with them being loved more because they're more likely to be used on greenfield projects. But it's equally consistent with newer languages being better languages.
I think it would be difficult to argue that newer languages are not usually better than old ones. They wouldn't be adopted if they weren't!
While that's true, you would need to show evidence that factor A is more important than B in order to show that A is not a deciding factor.
Factor B being "the loved languages are better languages"... I would say there's ample evidence that better languages are far from being more popular, and hence loved... Lisp is probably the poster child of _better languages_ according to many people, including me, but there are many others: Smalltalk, OCaml, Haskell, Erlang. Not to mention that showing conclusively that a language is "better" than another is incredibly hard, probably impossible as it just depends on too many factors, many of which are subjective. So your factor B is basically unmeasurable, which makes factor A a much more useful metric (easy to measure and arguably reliable until shown otherwise).
> Lisp is probably the poster child of _better languages_ according to many people, including me, but there are many others: Smalltalk, OCaml, Haskell, Erlang.
I think you just have an unpopular view of "better".
Lisp is weird to read and write. OCaml is ok but its infrastructure is arguably worse than Python's. I've been forced to use it recently and Opam is the most annoying tool I've used for quite a while.
Haskell is simply too difficult for most people. I think it's pretty clear that algebraic effects are going to be much better than monads where you absolutely need purity, and I think most people don't care about purity most of the time.
I have never used Smalltalk.
Anyway, his "evidence" is equally consistent with A and B so it doesn't really show anything.
> Not to mention that showing conclusively that a language is "better" than another is incredibly hard, probably impossible as it just depends on too many factors, many of which are subjective.
Of course. But that obviously doesn't mean that all languages are equally good.
Yeah well it's a massive faff even when it goes perfectly, which it very often doesn't.
For example just this week I was building a project that uses pkg-config to find GMP. I use RHEL 8. It has GMP but guess what? It doesn't install a pkg-config file.
Compare that to `cargo add foo` or `flutter add foo` or `npm install --save foo`.
Feel free to pretend it's fine. The rest of the world is going to move on to more pleasant languages.
Additional the top loved programming languages are beyond 10 years old which means there's going to be plenty of 3yr old codebases for people to be programming in. So quite trivially it's not that the languages are too new to have old crusty codebase ...
> The TOP 15 Loved Programming Languages > Rust, TypeScript, Python, Kotlin, Go, Julia, Dart, C#, Swift, JavaScript, SQL, Shell, HTML, Scala, and Haskell.
Rust is 2015 (8 years), TS is 2012 (10 years), Python is 1991 (32 years), Kotlin is 2011 (12 years), Go is 2009 (13 years), Julia is 2012 (11 years), Dart is 2011 (11 years), C# is 2000 (23 years ago), Swift is 2014 (9 years ago), JS is 1995 (27 years), SQL is 1970?? (50 years), HTML is 1993 (30 years), Scala is 2004 (19 years), and Haskell is 1990 (33 years).
---
ObjC and or Swift really should be in the Green languages column as well; what's he going to do new projects on iOS using? I think also many people would keep Java / C#|C++ in the Green column as well. SQL also would be in the green column. Moving 3 languages from Brown to Green really skews the later pie charts.