22 ms·

Green vs. brown programming languages (2021)

158 points by adamgordonbell 3y ago

Amorymeltzer 3y ago
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.
msla 3y ago
> 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."
- zikohh 3y ago
  > 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
- tetromino_ 3y ago
  > [...] 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 :)
  - hutzlibu 3y ago
    "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?
    - tetromino_ 3y ago
      Open source projects with a divine developer, no deadlines, and no business constraints. Example: TeX.
      - xigoi 3y ago
        Clearly having to compile a document three times to get correct output is not a bug, but a feature.
  - msla 3y ago
    Part of doing maintenance is being able to migrate to a better language, yes.
  - uecker 3y ago
    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.
- KronisLV 3y ago
  > 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.
kykeonaut 3y ago
Tangentially related, but it got me thinking. Does this mean that Copilot and friends are always writing old code?
- suby 3y ago
  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.
adamgordonbell 3y ago
Here is a follow up I wrote to this: Summary: new languages for complex reasons, have better tooling and that does matter. https://earthly.dev/blog/programming-language-improvements/ https://earthly.dev/blog/programming-language-improvements/
- gfody 3y ago
  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.
  - devjab 3y ago
    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”.
fit2rule 3y ago
[dead]
lesuorac 3y ago
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.
- nerdchum 3y ago
  Erlang not loved. Sad to see.
- brabel 3y ago
  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).
memefrog 3y ago
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.
- o1y32 3y ago
  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.
  - lesuorac 3y ago
    > 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+.
- brabel 3y ago
  > 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.
smokel 3y ago
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.
deleted 3y ago
[deleted]
yawpitch 3y ago
> 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.
- adamgordonbell 3y ago
  Author here. This is an error in original article. 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.
  - yawpitch 3y ago
    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.
    - adamgordonbell 3y ago
      Thanks for listening!
- dkarl 3y ago
  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.
schwartzworld 3y ago
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.
IshKebab 3y ago
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.
- brabel 3y ago
  You're just stating the "obvious hypothesis" which the author is challenging, and showing evidence against.
  - strken 3y ago
    Evidence for the existence of factor B doesn't disprove the existence of factor A.
    - brabel 3y ago
      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).
      - IshKebab 3y ago
        > 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.
gonzo41 3y ago
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.
- orthoxerox 3y ago
  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.
thswoer321 3y ago
Green should also include Zig, Elixir, Gleam, Crystal, Hare, Odin, Clojure.
herdcall 3y ago
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.
tialaramex 3y ago
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.
- pclmulqdq 3y ago
  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.
troupe 3y ago
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.
pharmakom 3y ago
any stats on most loved programming languages by people who know many programming languages? I don't consider all opinions to be equal in this.
semiquaver 3y ago
The inclusion of shell on the “loved” list for greenfield projects is enough to make me doubt the article’s thesis.
nmz 3y ago
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.
lincon127 3y ago
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.
Shrezzing 3y ago
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.
cjblomqvist 3y ago
The Gartner Hype Cycle is quite well known and exactly what's described here. See https://en.m.wikipedia.org/wiki/Gartner_hype_cycle https://en.m.wikipedia.org/wiki/Gartner_hype_cycle 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").
pjmlp 3y ago
I guess I am mostly a brown language kind of guy.
fl0ki 3y ago
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.
fnord77 3y ago
I thought this was going to be about the energy efficiency of programming languages
lamontcg 3y ago
> 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.
- deleted 3y ago
  [deleted]
dang 3y ago
Related: Green vs. Brown Programming Languages - https://news.ycombinator.com/item?id=26902821 https://news.ycombinator.com/item?id=26902821 - April 2021 (486 comments)
Xorakios 3y ago
Surprised that COBOL isn't more discussed. Still the most important language in banking and insurance back end programming!
jll29 3y ago
Other "brown" languages: COBOL and FORTRAN. 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.
Karellen 3y ago
> 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. [0] https://www.tiobe.com/tiobe-index/programminglanguages_definition/ https://www.tiobe.com/tiobe-index/programminglanguages_defin...
civilized 3y ago
> 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.
pron 3y ago
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.

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.

msla 3y ago

> 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."

zikohh 3y ago
> 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
tetromino_ 3y ago
> [...] 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 :)
- hutzlibu 3y ago
  "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?
  - tetromino_ 3y ago
    Open source projects with a divine developer, no deadlines, and no business constraints. Example: TeX.
    - xigoi 3y ago
      Clearly having to compile a document three times to get correct output is not a bug, but a feature.
- msla 3y ago
  Part of doing maintenance is being able to migrate to a better language, yes.
- uecker 3y ago
  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.
KronisLV 3y ago
> 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.

kykeonaut 3y ago

Tangentially related, but it got me thinking. Does this mean that Copilot and friends are always writing old code?

suby 3y ago
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.

adamgordonbell 3y ago

Here is a follow up I wrote to this: Summary: new languages for complex reasons, have better tooling and that does matter. https://earthly.dev/blog/programming-language-improvements/ https://earthly.dev/blog/programming-language-improvements/

gfody 3y ago
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.
- devjab 3y ago
  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”.

fit2rule 3y ago

[dead]

lesuorac 3y ago

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.

nerdchum 3y ago
Erlang not loved. Sad to see.
brabel 3y ago
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).

memefrog 3y ago

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.

o1y32 3y ago
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.
- lesuorac 3y ago
  > 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+.
brabel 3y ago
> 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.

smokel 3y ago

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.

deleted 3y ago

[deleted]

yawpitch 3y ago

> 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.

adamgordonbell 3y ago
Author here. This is an error in original article. 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.
- yawpitch 3y ago
  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.
  - adamgordonbell 3y ago
    Thanks for listening!
dkarl 3y ago
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.

schwartzworld 3y ago

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.

IshKebab 3y ago

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.

brabel 3y ago
You're just stating the "obvious hypothesis" which the author is challenging, and showing evidence against.
- strken 3y ago
  Evidence for the existence of factor B doesn't disprove the existence of factor A.
  - brabel 3y ago
    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).
    - IshKebab 3y ago
      > 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.

gonzo41 3y ago

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.

orthoxerox 3y ago
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.

thswoer321 3y ago

Green should also include Zig, Elixir, Gleam, Crystal, Hare, Odin, Clojure.

herdcall 3y ago

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.

tialaramex 3y ago

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.

pclmulqdq 3y ago
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.

troupe 3y ago

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.

pharmakom 3y ago

any stats on most loved programming languages by people who know many programming languages? I don't consider all opinions to be equal in this.

semiquaver 3y ago

The inclusion of shell on the “loved” list for greenfield projects is enough to make me doubt the article’s thesis.

nmz 3y ago

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.

lincon127 3y ago

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.

Shrezzing 3y ago

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.

cjblomqvist 3y ago

The Gartner Hype Cycle is quite well known and exactly what's described here. See https://en.m.wikipedia.org/wiki/Gartner_hype_cycle https://en.m.wikipedia.org/wiki/Gartner_hype_cycle 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").

pjmlp 3y ago

I guess I am mostly a brown language kind of guy.

fl0ki 3y ago

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.

fnord77 3y ago

I thought this was going to be about the energy efficiency of programming languages

lamontcg 3y ago

> 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.

deleted 3y ago
[deleted]

dang 3y ago

Related: Green vs. Brown Programming Languages - https://news.ycombinator.com/item?id=26902821 https://news.ycombinator.com/item?id=26902821 - April 2021 (486 comments)

Xorakios 3y ago

Surprised that COBOL isn't more discussed. Still the most important language in banking and insurance back end programming!

jll29 3y ago

Other "brown" languages: COBOL and FORTRAN. 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.

Karellen 3y ago

> 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. [0] https://www.tiobe.com/tiobe-index/programminglanguages_definition/ https://www.tiobe.com/tiobe-index/programminglanguages_defin...

civilized 3y ago

> 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.

pron 3y ago

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.