Green vs. brown programming languages (2021)
earthly.dev
earthly.dev
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.
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).
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.
Loved is based on people who use it. Wanted based on wanting to use it. They are separate.
And yet Python is the top fifth brown language? And also the top third loved language?
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.
https://en.wikipedia.org/wiki/Zope - 1999
Dr Dobbs' Python Weekly URL, since 2000
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."
-- https://en.wikipedia.org/wiki/Dr._Dobb%27s_Excellence_in_Pro...
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+.
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).
I didn't think we could make bold claims on HN. italic claims, tops :-(
@dang is this a possibility?
Summary: new languages for complex reasons, have better tooling and that does matter.
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 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.
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 feel for you it’s more like one package.
I don’t write you off one way or the other.
My main point is that writing off C# as really bad language based on your arguments is at lest uncharitable.
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.
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.
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.
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.
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.
The list is actually a stack rank, so the middle overlaps. But I missed that.
Consider those 5 ( Haskell, Scala, HTML, Shell, and SQL ) the murky middle, perhaps?
I should have done top 8 of something back when I wrote this.
I think the point still holds though. Obviously PL improvements happen, and tooling improvements happen as well.
But also people hate old code bases.
Tangentially, thanks for the podcast; really great work.
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.
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.
Pick your poison I guess.
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.
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").
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.
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.
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.
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.
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.
> 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.
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."
After reading the article, I had the same conclusion
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 :)
That would imply that open source (hobby) projects with no deadlines and no buisness constraints are bugfree?
Example: TeX.
Or in other words: The notion that all C software is buggy and crashes all the time simply does not match my own experience.
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.
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.
[0] https://www.tiobe.com/tiobe-index/programminglanguages_defin...
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.
Also c'mon man, some of these arguments are just made in bad faith and you know it.
Other "green" languages: Austral, Val, Jakt, V, Nim.
But I don't think that the amount of legacy code influences that much the love or hate for a language.
Green vs. Brown Programming Languages - https://news.ycombinator.com/item?id=26902821 - April 2021 (486 comments)
I don't consider all opinions to be equal in this.
Clearly intrinsic quality is a factor, and likelihood of being a greenfield project is a factor too.
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).
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.
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!
2 - File => New Project
3 - Build
vcpkg makes it tolerable, but it's very very recent.
- Instal as dev package and use pkg-config
- Use NuGET, vcpkg or conan
- Download a binary build, add location to include and lib search paths.
Hardly any herculean effort.
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.