34 ms·

Green vs. Brown Programming Languages

• agbell 6y ago
  Author here. I wanted to dig a little into data from the Stack Overflow survey on what made programming languages loved or hated and I think what I found is pretty interesting: it seems like people don't like the languages where they have to do maintenance work. Python and C# seems like outliers here though. People really love them.
  • offtop5 6y ago
    I like C# simply due to the tooling. I legit left a job since they made me use Eclipse with Java.
    • mariodiana 6y ago
      The more experience I gain as professional software developer, the more I begin to appreciate that what matters is the entire "ecosystem," rather than what language I'm programming in. What's the IDE like? How are dependencies managed? Is there a solid framework, as opposed to "move fast and break things" frameworks or "scores of amateurish third-party add-ons to choose from" to solve everyday problems? What's the programming community like? What kind of companies use these solutions, and what's the culture like there? Tools a big part of what we do. If I were a mechanic, I would rather work on Hondas with a good set of tools than I would Ferraris with tools bought at WalMart. Personally, I've done only a tiny amount of C# development. I'd have no problem going back to that.
    • xxs 6y ago
      >they made me use Eclipse with Java. I mean I do use them quite voluntarily. That's the thing that annoy(ed) so much.
      • offtop5 6y ago
        Doesn't Eclipse feel a bit dated to you ? Like they wrote the UI in 1999 and never updated it
        • xxs 6y ago
          > Doesn't Eclipse feel a bit dated to you ? I wonder what you'd say about the command line. The interface has not changed for like 40y+. I 1st started using eclipse in 2006 or so, while writing some plugins (post compilation byte code editing) in 2003-2004. The UI has been updated somewhat since, not drastically, though. I've got pretty decent understanding how it works internally and what functionality is available. Truth be told, updating the UI just to look modern might find some fans but to many it'd make it less usable for no good reason. For instance I don't want my hand drill to feature an OLED display, coupled with bluetooth just b/c it's cool and dandy.
    • maynman 6y ago
      If you're using Java, definitely give IntelliJ a try. I think it makes writing Java a pretty enjoyable experience.
      • offtop5 6y ago
        Agreed, I like IntelliJ. I said since I never know if a Java shop will make me use eclipse again, I tend to shy away from java. Of course I do have a price, if we're doing 200k up I'll put up with Eclipse
    • zwieback 6y ago
      Yeah, C# and Python are my two daily drivers. I think a good case can be made for C# due to excellent tooling and sitting in the sweet spot for statically typed languages: less enterprisey and more practical than Java and less painful than C++.
    • kaba0 6y ago
      I never understood why a company would enforce the use of a specific IDE. If they can’t set up .gitignore files and formatting properly, they should not be doing IT.
      • offtop5 6y ago
        To be fair eclipse and IntelliJ do different things to set up run configurations. Although I'll agree this is a very very bad sign, I left that job as soon as I could. I will say socially they did a lot of fun stuff, we had tons of parties and everything. Felt almost like a college campus, the actual work environment was horrible though.
      • mywittyname 6y ago
        Standardized IDEs are incredibly important for productivity in complex software projects. Large applications can get to the point where the build system and IDE kind of meld together, and custom IDE plugins are required to navigate or build the code base. I've worked at a place where developers didn't do any IDE configuration. The IDE (Visual Studio) was customized by another department then was pushed out to developer machines. This meant that developers could focus on building software and not messing around with configuration and plugins. It also ensured that everyone's code compiled the same, ensured library compatibility, etc. IDEs may not matter so much on small web apps, but one cannot extend that fact to all of software development.
        • kaba0 6y ago
          That’s a huge liability/red flag. Builds should be deterministic, and reproducible. An IDE should have no say in that, that’s what build tools are for. That’s just all around terrible. Also, a sane IDE should be able to make use of the config files of the build tool.
          • mywittyname 6y ago
            I mean, if you say so. Said project has been around for 25+ years, survived a dozen acquisitions, is actively developed by 1000s of developers all over the globe, and has revenues in the $100s of millions. So clearly they are doing something right. Personally, I loved never fucking around with IDEs.
    • o_nate 6y ago
      I agree. One reason I think people hate VBA so much is because the tooling is abysmal. If you've ever had to work with VBA code in the Excel code editor, you'll understand what I'm talking about. Ironically, both that and Visual Studio are made by the same company.
  • achtung82 6y ago
    Also with C# and .Net there has been a lot of changes since .Net Core released 2016. Doesn't change that there is a lot of older legacy code so im not entirely sure.
    • decafninja 6y ago
      I loved C# as a language. I'm not fond of most companies that use C# though.
      • mapmap 6y ago
        Could you elaborate on the second statement? Why is that?
        • decafninja 6y ago
          Most companies that use C# and .NET tend to be big old school enterprise orgs where tech is an unrespected cost center. Java is arguably used in many of the same companies, but also seems much widespread across a more diverse range of different types of companies.
  • xxs 6y ago
    One of the main issues with stackoverflow is (has been): very few seasoned developers ask questions and even they do, it'd be likely to be unanswered. That skews its user base very heavily towards the younger people.
    • calvinmorrison 6y ago
      Or different styles of learning! Some languages are really good in situ for debugging and solving problems, some are more opaque and require looking things up. Also 'brown' languages being older and more established, there are plenty of older engineers who RTFM first, look at man pages first, etc then ask questions.
  • mnd999 6y ago
    Seems there's a lot of hate for Scala and Haskell regardless of the project? What is it with functional?
    • notsureaboutpg 6y ago
      Scala and Haskell are also in the most loved languages, why do you think there's a lot of hate for them?
      • erik_seaberg 6y ago
        I think some people feel productive writing lots of code, while others feel productive learning ways to avoid writing lots of code.
    • shadowgovt 6y ago
      I've never seen someone succeed at giving an objective explanation. Anecdotally and subjectively, functional programming is a different type of thinking about a problem... Instead of breaking it down into stages, I'm almost breaking it down into a graph and figuring out how the nodes must connect. LISP is also like this. I wouldn't be surprised if cognitive modeling shows that graph-manipulation engages different chunks of one's brain than step-by-step procedural description, but I do not know.
    • microtherion 6y ago
      There might be a particularly strong Green/Brown delineation with those, with programmers loving to write code in them, but disliking to maintain other people's code.
  • jarpadat 6y ago
    It’s an interesting conjecture but I don’t think the data makes a compelling case. When you compare 2 points in time you have a lot of alternative hypotheses, like the 2016 languages just being historically unpopular for some reason. A better support is a cohort analysis where we see languages start green/liked and transition to brown/disliked over their lifecycle. The real difficulty though, is addressing the alternative hypothesis that language design improves over time. This is obviously the view of language designers or else they wouldn’t make languages. In that case, you would see the languages turn brown in your analysis, and even in more robust cohort analysis. But it would not be because of a honeymoon bias, it would be because you don’t want to use a horse-drawn carriage if you could use an automobile.
    • visarga 6y ago
      Different decades have different applications, hardware and trade-offs. So popular languages could be just overfit to the current epoch. It doesn't mean there is always progress, could be just change.
  • JoshTriplett 6y ago
    I've maintained large Python codebases, and I found it somewhat painful, especially when finding and fixing issues. I got tired of discovering issues at runtime that any compiled language would have found at compile time. I still enjoy Python, but I don't consider it an exception to any general principles here.
  • skrtskrt 6y ago
    About 4 years into my career I am really really reaching the end of my rope with Python. Type annotations have improved things a bit, but since it's not real, or enforced by anything, every library types things differently & often incorrectly, if at all, and the type annotation system itself still has massive limitations. That's not to mention the package management ecosystem. I'm getting into Go and Rust. Go is fine but it would be a million times better if it had proper enums & pattern matching for result & options types. Being able to define a class of errors as an enum in Rust makes handling them so easy. Rust is really cool, but I know I am barely scratching the surface with it and it would be hard to convince any of the Python shops I have worked in to go to Rust due to the learning curve. All the Python shops I have worked have eventually started to write some stuff in Go, except the one shop which is just data/PySpark stuff .
    • tcbasche 6y ago
      Putting aside the dreary package management situation with Python (although perhaps Poetry will scratch that itch?) codebases really only shine with comprehensive unit testing, linting, static analysis and a bit of discipline to stop it from degrading. Although perhaps that’s applicable to any large codebase.
      • skrtskrt 6y ago
        I agree. Poetry is good but not good enough to use at work yet. Also - not Poetry’s fault - many Python packages are miserable at listing and versioning their dependencies correctly. Re: everything else, you’re right but it gets really tiring writing tests that are handled by the type system in other languages. Go has this problem too to a certain degree since multiple error subtypes can’t be expressed as an enum. Just errors.Is and errors.As everywhere.
  • vaughandroid 6y ago
    Thank you for sharing. Intuitively I think your point makes a lot of sense. I don't think there's really enough data to really prove it, but I liked your approach. I do think there's other stuff going on as well though. For example, newer languages are often designed to address perceived problems with existing popular languages. I'm a long-time Kotlin and Java developer, and Kotlin feels a lot like Java 2.0 - it specifically addresses a number of pain points people were experiencing with Java. So of course I'd rather be working with Kotlin, and going back to Java can feel like a drag.
  • bob1029 6y ago
    As a C# zealot, I would have a hard time providing an unbiased take, but its probably the "whole picture" ideal that makes developers take to it so strongly. When working with C# (aka some specific flavor of .NET), you are embraced with the following: - Visual Studio, probably the best IDE ever created. - With .NET (Core 3.1~6), code that usually "just works" x-platform. - Mostly-workable application development ecosystem as of .NET 5. - Ecosystem of first-class CI/CD/Cloud/et. al. products & features. - World-class debugging experience, even across the network. - Stable versioning scheme with dependable LTS options. - Confidently run mission-critical loads on latest Windows Server platforms. - Very large library of high quality 3rd party dependencies (nugets). - Trivial to configure own nuget server for internal/private use. - Virtually everything you need is a first class dependency. - LINQ - Very good GC, especially when configured and used correctly. - Strongly-typed with very expressive language features as of C#8. - Fast compilation times, even on monster projects. - Principally maintained by largest software company on earth - Maintained by the open source community as well - Extreme performance (.NET Core optimizations, Kestrel, Disruptor, et. al.) - Extreme productivity (VS tooling, Self-Contained Deployments, Blazor, etc.)
• protomyth 6y ago
  This looks more like a cool vs uncool list. SQL and HTML are "Dreaded"? Frankly, anyone who has the actual opportunity to program in Assembly should thank their lucky stars.
  • jrsj 6y ago
    SQL and HTML are on both lists. Presumably because they can be great or terrible depending on the quality of the existing code you’re dealing with
    • agbell 6y ago
      Also they can only dread what they use. The question SO uses specifically asks only about things that you use extensively. That is what makes this interesting to me. It isn't people dreading APL because it looks funny, its people dreading something are using it day to day.
    • schwartzworld 6y ago
      Html has a lot of flaws, but it's easy to learn, so it totally tracks to me that it could be in both categories. I wouldn't want to write a sizeable app in vanilla html, but I can't think of a simpler way to create cross-platform UIs
  • xxs 6y ago
    I'd consider Assembly a lot better language than SQL. You can't get proper testing framework what makes SQL hard - hundreds of lines queries with unknown amounts of joins/unions and not-well-defined relations. It's not that's inherently dreaded, it just leans itself to a hard to follow one.
    • shadowgovt 6y ago
      I've wondered sometimes if it's possible to quantify what I hate about hacking SQL so much, but it's hard. The language lacks something that I've taken to fuzzily call "localized mutation..." When I have to change someone's existing SQL, it usually involves jumping around in the text buffer a lot (i.e. wrapping an existing statement in parens to use it as a clause in a bigger statement, or having to split a clause that is now complicated enough into a separate WITH clause... These operations involve mutating text that can be dozens of lines separated, and all those mutations need to be coordinated. It feels like a harder language to refactor than most I use.
• ChrisMarshallNY 6y ago
  I think it's a pretty valid hypothesis. Like so many "research" projects, there's a lot of "baggage" that comes with data. For example, I was reading that a study found that people who take Melatonin do better, when infected with COVID. Then, it was pointed out that this may well be because they tend to get better sleep than people that don't. The "better sleep" may have more to do with the fact that these people take getting sleep more seriously (the Melatonin is an indicator, as opposed to an actual variable). But "brown" languages are here to stay. One of my first projects (in the late 1980s), was a 1970s-era FORTRAN 4 codebase of over 100KLoC, without a single comment (in those days, disk space and memory was so expensive, that we used short variable names, and no comments). These days, I am usually the poor schlub that has to go back to my codebase, so I've learned to be pretty heavy-duty in documenting my code. I eat my own dog food. This article is a few years old, but I think is highly relevant (and a bit meta): https://veekaybee.github.io/2019/05/10/java8/ https://veekaybee.github.io/2019/05/10/java8/
• rowanseymour 6y ago
  I think green/brown also applies for projects I've written myself (in my case older stuff tends to be Java or even PHP, newer stuff Python, Go). I've become a better programmer and when I have to touch code that I wrote a decade ago.. I sometimes cringe. That said I still think Go is objectively better than Java!
  • frob 6y ago
    I share the following rule with younger developers and try to hold myself to it as well: If you look back at code you wrote 12 months ago and don't think, "Ewww, what was I thinking here and why did I write it this way?", then you're not growing as an engineer. For very beginners, I change that to 4-6 months depending on how fast they're picking it up.
• shadowgovt 6y ago
  This is an interesting approach to take on analyzing the topic. One confounding factor I can imagine is how many languages are created in response to lessons learned maintaining legacy code with other languages. We can see examples of design decisions explicitly made to address common and challenging patterns in other languages (Rust's static memory rules as a response to the unchecked non-garbage-collected memory patterns of languages like C++, for example). This suggests a follow-up question: is it possible to see a pattern of languages ranking as beloved for longer and longer times depending on their newness? Sort of a "reverse half-life?" If, as an industry, we're getting better at developing languages, we might expect them to stay more well-loved for longer than the languages preceding them.
• d_silin 6y ago
  Python seems like a notable exception - despite being of comparable age as Java, it is still mostly a loved language.
  • realityIsntHere 6y ago
    Anyone who loves Python doesn't program python Professionally. It becomes a brown language, and as complexity increases you run into issues with dynamic typing. I don't recommend for loops.
  • Jtsummers 6y ago
    Python 1.0 was directed more towards a programming literacy idea. Python 2.0 from ~2000 was largely directed at web applications and text processing (a la Perl). Python 3 (and later versions of Python 2) has been more directed (in the past decade) towards number crunching (numpy) and data analysis and machine learning. It would be interesting to see a breakdown of perspectives on the language based on the applications it's been used for. Would web app maintainers still feel the love if they're maintaining something originating circa 2005, versus a data analysis app that was started in 2015.
    • citrin_ru 6y ago
      I see nothing in Python 3 itself directed towards number crunching. Its integer performance actually worse than for Python 2 (because integers in 3 are big integers). nympy can be considered a DSL based on Python and it was used with Python 2 too.
      • deleted 6y ago
        [deleted]
      • Jtsummers 6y ago
        I don't understand the point of your comment. I called out numpy for number crunching explicitly along with later versions of Python 2. I didn't say Python was good for number crunching, but that it's being used for number crunching and listed the library that has largely driven that trend (by making the language effective at number crunching).
• kardianos 6y ago
  HTML is in both dreaded and loved list. It isn't even a programming language. I think you've missed the boat slightly. I maintained a VB6 application. I disliked doing that not because it was old, but because the code base was created into many projects, some I had no source for. Independent of that I wouldn't choose VB6 for a new project because it lacked stack traces and wasn't cross platform. Java: I don't care to program in it because the IDEs are so heavy and I don't like how the ecosystem has grown up. Go: I don't like it because it is "new" (over 10 years old), I like it because it has reflection and stack traces, it is easy to write in a lighter environment, it is cross platform, it is typed, and it prefers explicit usually. I have a large application written largely in Go. But I don't think about writing in Go. I think about the domain; Go is almost incidental. Yes, many immature developers hate old code. I don't hate C++ directly, but if you've ever had to work with a C++ code base with 3 types of strings then you may dislike working with C++ ecosystem you've ran into. People don't dread assembly because it is "old". People dread it because you can blow your foot of without realizing it, but it is still necessary today. Specifics matter. "Old" doesn't cause it to be "bad". Foot guns and and lack of easily reproducible environments (I'm looking at you R) are "bad".
  • vips7L 6y ago
    > Java: I don't care to program in it because the IDEs are so heavy Just use VSCode, or Sublime, or neovim. They all work fine.
    • atraac 6y ago
      IMO not using IntelliJ with Java is like shooting yourself in the foot and crutching for the rest of your life just to show people how tough you are.
  • disgruntledphd2 6y ago
    > Foot guns and and lack of easily reproducible environments I kinda agree with the reproducibility concerns around R, but you can use conda or MRAN if you really need that. The massive benefit of your concern is that if you install the latest version of R, then you'll get an entire compatible ecosystem of packages, which I really, really appreciate and the lack of which drives me mad in Python.
• okareaman 6y ago
  I think this theory is not accurate and not useful due to Simpson's Paradox, which I learned about recently in this great post by vladoh in regards to Tesla crash reports. https://news.ycombinator.com/item?id=26855608 https://news.ycombinator.com/item?id=26855608 I have an alternate theory. Junior developers prefer languages they learned to program in or closest to it, while senior developers like languages that make is easiest to express a problem solution and this consideration includes the library ecosystem. I'd like to see this article again rewritten in terms of developer experience.
• TheFlyingFish 6y ago
  I'm particularly interested in why several languages show up on both lists, namely SQL, Scala, Haskell, Shell, and HTML if you count it. One possible explanation (that supports the author's main thesis) would be that three out of five of these are unlikely to be the main language for a project, but rather a supporting language. In other words, SQL and shell are just as likely to show up in a green-field project as in a brown-field project, because we still use SQL to communicate with database same as 20 years ago, and we still use shell scripts to tie it all together. No idea how one would test this hypothesis, however. And I still don't have an explanation for why Scala and Haskell are both loved and hated.
  • MattGaiser 6y ago
    For Scala and Haskell, it could just be pragmatic developers vs purist developers (to grossly generalize). There are people out there who want the absolute best language for a project, even if they don't already know it. Then there are those who would be annoyed at having to learn a new language and all its quirks to do something that Java could have done, even if it cost more in servers or requires more lines of code.
    • karmakaze 6y ago
      Rarest of all seems to be those trying to get a good compromise: F# or OCaml.
  • dcolkitt 6y ago
    Scala and Haskell are both "astronaut" languages. They really encourage highly complex abstractions. They're potentially very powerful, but it's easy to get lost in the clouds. Some people love it, because it potentially gives you an enormous amount of leverage to solve difficult problems with careful but short solutions. I forget where I heard this joke, but you give a Java programmer some specs and he'll spend 4 hours writing code, whereas the Haskell programmer will spend 3 hours and 55 minutes meditating, then write a 10 line solution. The counterpoint is all that abstraction is often just needless busy work, that more often serves to feed the programmer's ego rather than accomplish real work. It's also not pleasant trying to figure out compiler errors that you need a PhD in abstract algebraic topology to understand.
• kstenerud 6y ago
  A big problem and reason why "brown" languages come to be dreaded is because very few software houses take code UX seriously. I've worked on codebases built with UX in mind and codebases without, and it's a world of difference. Code with UX has descriptive names, functions whose names intuitively describe what they do, using parameters that can't be accidentally misused. APIs are clearly delineated, domain edges clearly defined. Reading such code feels almost like reading a high level recipe, with the nitty gritty details available on demand using CMD-click. Weird edge case code is documented with a block comment explaining why it was done in this unexpected way. Nesting is minimal. Aptly named temp variables that only exist to aid readability are common. And the irony of it all is that by eschewing code UX, you're mortgaging your future: making it progressively harder to maintain your codebase, and harder to bring new people up to speed. Changes take longer, and testing is more difficult as fewer and fewer people understand what it's doing.
  • MattGaiser 6y ago
    Tenure in this field is short enough that most devs are renters, not owners, so the mortgage isn't your problem. I suspect that drives a lot of the problems.
    • kstenerud 6y ago
      Technically true, but quality control must be part of the leadership and culture if it is to mean anything. People come and go, but culture endures.
      • MattGaiser 6y ago
        Can culture survive everyone being replaced?
    • skrtskrt 6y ago
      Everywhere I have worked has about the same average engineer tenure (between 1.5-2 years), but had massive differences in code quality. Also, super-long-tenured engineers can be detrimental. There can be a tendency to not document anything when you can always just ask one of the oracles of knowledge that originally built it. The wrong type of super-long-tenured engineer is just going to be defensive and full of excuses about why something was built one way, even when the pain of using what they built is dragging down the whole organization. They will push back on anything new and choose to add incremental blobs of crap code to their existing pile of crap instead of breaking things down and using their learnings to help design the new system
• Rooster61 6y ago
  It hurts seeing Ruby listed as a dreaded language. I think what is actually dreaded is Rails, and the terrible, awful, no-good things PM's forced it to do in the 2010's. I'm a Python developer now, but I still miss the ease of writing code in Ruby. I find it a cushy, intuitive activity, and I wish it was used for something other than hulking, poorly scaled/planned out web apps of yesterdecade.
  • wsc981 6y ago
    It's funny how quickly opinions seem to change. When I first visited HN (~2010) it seemed Ruby and Rails was all the hype; doing Ruby/Rails stuff seemed to be the hip and cool thing to do. Perhaps Heroku was also introduced around this time? Nowadays it seems Rails is mostly forgotten and Ruby, well ... Python seemed to have dethroned Ruby as Python seems to be used for similar purposes. I tried to get into Rails in the past, but it didn't quite click with me. Perhaps in part because I don't do web dev by trade. In general I just don't enjoy web dev. Ruby as a language, I did enjoy and I used it in combination with Calabash for iOS tests. But I believe most of my team members didn't get the same kind of enjoyment out of Ruby as I did, much preferring much to work with statically typed languages, as such most didn't get involved in writing UI tests too much and just focused solely on the mobile app work. I also used Ruby as a replacement for some shell scripts, when a shell script would be too complicated and problematic to write. Just last year (after a few borked initial attempts) I really got into Lua [0] and I have to say, I enjoy it even more than I did Ruby in the past and also most statically typed languages that I've worked with (C#, Swift, Objective-C, ...). Lua (with LÖVE [1]) is awesome to me. Lua seems to be a very neat small little language that is build on just a few very simple concepts, which makes it pretty easy to wrap your head around it. With Ruby there would be quite a bit of magic (complicated internals) happening, which I don't see in Lua. Some people mentioned Lua might be hard to use in big projects, but I believe it should be manageable and I hope to write a pretty big game using Lua and LÖVE in the future. --- [0]: http://www.lua.org http://www.lua.org [1]: https://love2d.org https://love2d.org
    • sanderjd 6y ago
      Rails is still the elephant in any web application room. But it isn't hype-y, it's just the mature option for its use case.
• roland35 6y ago
  I am a Python (green) programmer who joined a team using Java (Brown), but I have found that working with Java has overall been a great experience. Most of that may be because of Intellij, but I find the verbosity helps prevent future bugs and helps more strickly define interfaces.
  • rowanseymour 6y ago
    I imagine a lot of Python programmers find themselves using strongly typed language, and love that a whole class of bugs has just disappeared.
    • pydry 6y ago
      I went in the opposite direction coz 40% more code to maintain didn't seem like a worthwhile price to pay to catch some pretty shallow bugs. Especially since more code correlates pretty strongly with more bugs.
      • kaba0 6y ago
        How is it 40% more code??
      • roland35 6y ago
        Java is certainly more verbose, but I feel that nothing is free and being more concise comes with some costs. For some applications the trade off is certainly worth it! I use python and Django for personal projects to move quickly. But if I need to build something that will be rock solid I need to move more slowly and carefully, and Java works well for that.
        • dunefox 6y ago
          > But if I need to build something that will be rock solid I need to move more slowly and carefully, and Java works well for that. Rock solid with features like null references, AbstractFactoryFactories, extremely over-engineered class and inheritance architectures, object fetishism, etc. I know what you mean, but Java and rock solid are not something I would mention together.
• ncmncm 6y ago
  "There are only two kinds of languages: the ones people complain about, and the ones nobody uses." ― Bjarne Stroustrup
  • majjgepolja 6y ago
    "This is blatantly false" -- Dude looking for COBOL developers
• aequitas 6y 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 starting from scratch, 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 also resonates a lot with Chesterton's fence[0]. Often the current solution to a problem might seem unnecessary or complicating. But the complexity lies in the problem itself. Only if you truly understand the problem you can say if the current solution is too complex itself. [0] https://en.wiktionary.org/wiki/Chesterton%27s_fence https://en.wiktionary.org/wiki/Chesterton%27s_fence
  • skrtskrt 6y ago
    This is true, but bad codebases are inherently hard and dangerous to change. That's one of the properties of them being bad.
    • aequitas 6y ago
      That's why creating a new codebase is not the solution per se. Understanding the old codebase and putting its behaviour under test should be the first step. Only then you can start working on a new codebase, compare its behaviour to the old one and call it an improvement (if you manage to not mess it up as well, which is sadly often the case). Of course this can (and should often) be done is stages and not as a whole.
      • skrtskrt 6y ago
        Agreed, whether you rewrite or change in-place you're not going to be confident in the outcome unless you have tons of end to end tests first. Then you need to find and skip/ignore the tests that don't actually test end-to-end behavior or business logic, just some implementation detail along the way. Only then will you be free to do what is probably the first step if you have a crappy codebase: start establishing domain boundaries and interfaces and splitting things across those lines.
• brundolf 6y ago
  I think there's a lot of truth to this, but I'm going to make an additional suggestion that I'll readily admit is biased by my own feelings: I think Go is in a honeymoon phase and people will hate it in 10 years; I think Rust will continue to be liked even when it's a legacy language (perhaps no language can continue being loved once it becomes "brown", but I think Rust will be a lot less dreaded than others). Go, like Ruby (mentioned at the end of the article), is optimized for building. You can do things quickly and easily with minimal ceremony. Some people love that. But that's exactly the trait that's starting to weigh on Ruby, and it's exactly the trait that has put PHP and Perl in the "dread" category over time (remember when people were in love with those?). Rust on the other hand is optimized for maintaining (it's right there in the name: software should be allowed to become old and "collect rust"). Rust APIs are very hard to misuse, everything is constrained and specified very explicitly. Documentation and testing live inline with your code. You know exactly what a piece of code can and can't do - you even know whether it's allowed to mutate an object you're passing it. And of course certain mistakes are impossible to make at all without (again, explicitly) dipping into unsafe { }. This kind of forethought is what makes a language that survives the honeymoon phase.
  • foolfoolz 6y ago
    this sounds entirely like personal preference based on the projects you’ve worked with. all languages are capable of producing maintainable software. it’s much more about the authors skill than the language itself. yes statically typed languages scale better, but ide support on dynamic languages is still good. i don’t buy the “rust solves all problems” idea. that is the hype curve
    • tpm 6y ago
      For projects with a large number of contributors and long development time there will inevitably be some less maintainable code and that is where the quality of the language itself will become important. No language solves all problems obviously, but clearly some are better than others in nthat regard. I have no experience in Rust but many years with Perl and Java (and others). Perl in the hands of a small, very experienced team had the highest productivity and quality I have seen - but I would not want use Perl in a project with higher developer churn and lots of inexperienced coders.
• kaladin_1 6y ago
  Seems this "It’s because writing something new is cognitively less demanding than starting from scratch" could do with some editing. Doesn't new and scratch mean the same thing in this context? "The reason that [ developers ] think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it." Joel I couldn't agree less with this. Currently working on a large codebase built on top of Apache ofbiz with Java. At intervals every dev involved in this project reminds our boss he shouldn't be using this codebase. Of course, events always remind us we are wrong because many features that would've taken months of dev time and work are already implemented and taken advantage of. Anyway, takeaway, remind yourself - yeah - that reading code is hard!
  • agbell 6y ago
    Good catch. I have fixed it. It's because writing something new is cognitively less demanding than the hard work of understanding an existing codebase, at least initially.
  • kaba0 6y ago
    There are so utterly terrible codebases, on which we should pull the plug. But my experience is that even not-that-bad code bases will be seen as bad by new developers, solely because of their complexity (mostly inherent in this case). The thing is, programs grow continuously and they will pick up on complexity, and most software out there is simply beyond human understanding with every intricacy of it. And developer egos routinely say that the code is bad, instead of saying that they don’t understand the context of this and that decision.
• jen20 6y ago
  This quote from the article is interesting: > 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. It might be true of enterprise [1] software, but is not generally the case. The question is whether code quality is valued in a given environment. If it's not, it doesn't matter what language is used, a mess will be created. Despite words to the contrary from most enterprise software shops, code quality is usually not valued at all - if it were the patterns which prevail would... not. By contrast, at random just now, I chose a popular device (Intel E1000 NICs), and looked at one of the files from the FreeBSD driver code for it [2]. This code written in C was added in 2008. The code is not "hard to follow" despite not being an expert on FreeBSD drivers, it has not atrophied or suffered from rot, while remaining under active development for at least 13 years. I didn't track the history beyond the addition of that file, so it's likely the code is actually older. I could have performed this experiment on any project that values quality: Illumos, the Linux Kernel, LLVM, the Go standard library, and I'd wager the results would be similar more often than not. [1]: "Enterprise" software is the (pejorative) term I tend to use to mean over engineered software with liberal use of frameworks and ORMs, generally at least 4-5 layers of mapping code adding no value, and an "architecture committee" - even if that committee consists of a single individual who also writes all the code for the project... [2]: https://github.com/freebsd/freebsd-src/blob/main/sys/dev/e1000/if_em.c https://github.com/freebsd/freebsd-src/blob/main/sys/dev/e10...
• fny 6y ago
  If you look into prior years, you'll notice that many of these brown languages were once green. When Rails boomed, Ruby shot up in popularity, when Node came to the fire, so did JavaScript. Same with Scala (which happens to be on both lists.) Python has had a revival because of all the ML and data science. TypeScript is hot. Julia and Motion are new. Dart got a bump from Flutter. Rust is also hot. Go is probably the exception here, but mark my words many of these green names will also brown in time as developers become bored and ShinyLang, and it's IOTWebAIMobile Framework takes off.
• ceronman 6y ago
  One trend that I notice is that most new languages focus their design on writability over readability. And by writability I mean prioritizing features that allow you to express more, while typing less code. These languages are specially prone to become "brown languages". One classic example is Perl. One of the killer aspects of Perl is that it allowed you to write in just one line or two what in other languages would take dozens of lines and boiler plate. Writing Perl is actually really nice. You could go from idea to working code extremely fast. And that's why Perl became super popular two decades ago. However, maintaining a 100K LoC Perl website written by a lot of different people over 20 years, it's definitely not a nice experience. I know this is going to upset a lot of people, but another extreme example is Lisp. I think I've never seen any language as expressive as Lisp. Once you grasp it, writing Lisp is really really nice. However, reading a complex Lisp program using a ton of macros and a lot of higher order functions could be really hard. In my experience some of the hardest code to read that I have ever encountered has been written in Lisp. And if reading is hard, I don't even want to talk about debugging. But okay, Lisp never really became super popular, so let's ignore it for now. One more modern example: Kotlin. Kotlin's main improvements over Java are mostly on writability. Semantically, these languages are very similar. That's kind of intentional, as one of the goals of Kotlin is maintaining a very good interoperability with Java. However, Kotlin is nicer to write than Java. Java is verbose, Kotlin is succinct. Kotlin adds a lot of syntax and features to make you write the same things that you would express in Java but in a much shorter way. Writing Kotlin is so much nicer than writing Java, I'm sure of that. I recently started working on a large Kotlin code base, and I can say that reading Kotlin is harder than reading Java. It turns out that verbosity is not a problem when actually reading code. And having few ways of expressing things actually makes code easier to read. Languages with a lot of features and different ways of doing things are easily abused. You can still write readable code in them, but it requires a lot more discipline. It's so tempting to use that obscure language feature to make your code so succinct! Python is a language that always put emphasis on readability. The developers of the language are famous for rejecting a lot of ideas to be added to the language. Even though Python is almost as old as Perl, so far, it has escaped from becoming a brown language and it's still loved. Who knows if it will remain like that. Another language that seems very serious about this is Go. I know that there are a lot of Go haters here on HN, but you have to admit that Go designers put more emphasis on readability than writability. I predict that Go will escape from becoming a brown language.
• naushniki 6y ago
  Another article where SQL and HTML are listed as programming languages, great.
• sanderjd 6y ago
  Ok but it isn't true that there are no brown languages that are loved. So the interesting exercise is to try to figure out which green languages will remain loved after they turn brown! Obviously this is hard to guess at. My guesses from the green list: I think Kotlin and TypeScript will remain loved; they solve a real pain point in a simple and well curated way. I think Scala will be dreaded (actually I would already put Scala in the brown category). I think Haskell will remain both loved and dreaded; I think it's a bit different than the rest, because I don't think people mostly dread it because of maintaining old systems, I think whether or not it clicks is just very personal (I'm personally in the "dread" camp on it, though I appreciate many of its ideas). I don't have enough experience with Dart or Julia to make a guess. The most interesting questions are Go and Rust. My intuition is that I think Go will be like Ruby: quite nice to start with, but increasingly unwieldy as projects get bigger and bigger. I do find it pleasant to hack on small Go files, but would dread joining a project with millions of lines of code. Rust could be dreaded as the C++ of the future, known for big unwieldy difficult to maintain codebases. Or it could be loved as the much better C++ of the future, known for making big unwieldy difficult to maintain codebases more tenable and enjoyable to work with. I'm not sure!
  • H1Supreme 6y ago
    > increasingly unwieldy as projects get bigger and bigger. This applies to any project in any language. How would it be worse in Go versus Kotlin or Typescript?
    • The_rationalist 6y ago
      There are many features in such languages that allow to reduce cognitive overhead, such as null safety.
    • sanderjd 6y ago
      Yep, as the other commenter said, languages scale differently because of the entire suite of different and interacting features. I know it's cliche to say, but I still believe it's true, that Go suffers from lacking generics, particularly as a project grows. I see big projects with lots of `interface{}` usage to work around this, and at that point the type system is essentially equivalent to Python's, which in my view is harder to maintain at scale. This seems a lot more common in big Go projects than use of Object in big Java projects, for instance, and I think it's a smell. I also think nil-based error handling is harder to maintain than languages with no nulls, or strongly discouraged nulls (but most languages have this problem). I don't have a good sense for how well the concurrency functionality in Go scales, but I get the sense that it's pretty good, and superior to most other languages, including the other ones in this thread.
• beders 6y ago
  Just to keep in mind: StackOverflow deliberately removed Clojure from their surveys. People who embrace it are loving it to bits. Also Haskell and Clojure are not even in the Top 50 programming languages according to TIOBE. "Languages not in the top 20 in 2016 are more likely to be used in new projects. " Based on what statistic? This is a wishful thinking article with very little basis in reality.
  • bccdee 6y ago
    Yeah this article is kind of a mess. It wants to have a data-driven perspective, but what the data shows is "people tend to like newer languages more." Now, this could be because there are fewer legacy projects in newer languages. Or it could be because newer languages learned lessons from older languages. Python is still considered "well-loved" despite being pretty old, while its contemporaries C++ and Java are fairly disliked — this is (probably) because Python actually innovated over those other languages in a lot of ways. And languages which learned from Python (JS, TS, Julia, Dart) are all well-loved, with the possible exception of Ruby, which famously differs from Python with its TMTOWTDI philosophy. I'm not necessarily saying that there is obviously a forward march of programming language progress, but it's worth noting that the data the author's looking at can just as easily acommodate that thesis too.
  • Scarbutt 6y ago
    Clojure is statistically insignificant, that is why it was removed, what's the point of saying "Clojure is the most loved language" when only two out two voted for that.
  • oblio 6y ago
    > StackOverflow deliberately removed Clojure from their surveys How? When? Why?
• jillesvangurp 6y ago
  I half agree. There is the notion that I actively don't like most of what is on the brown list. And I'm old enough to remember most of those things being new and have used a few of them. Also, I've done maintenance on a lot of code over the years (and still do). Including my own code. If you work products rather than projects and stick around long enough, this happens. Some stuff I've written in one language, I eventually rewrote in a different language. E.g. a lot of my early Kotlin code replaced Java code I wrote before. Kotlin made doing that particularly easy. These days, I rarely deal with Java code bases as I default to Kotlin for the last three years. I've also done Ruby, Php and declined to ever touch VBA with a ten foot stick even when it was brand new. Just no. Php I never really liked but I appreciate what it does. Ruby was kind of alright but a bit limited for the things I do with it. I've deleted quite bit of it over the years. Some of it written by me. There's a pattern that the author overlooks: the green languages address issues with the brown languages. E.g. Rust provides meaningful memory safety and other zero cost abstractions relative to C++. That's why a lot Github projects exist that essentially are about building better versions of classic unix tools in Rust. Also see the discussions about allowing Rust in the Linux kernel. Kotlin was an obvious attempt to improve on both Java and Scala. Scala purists may disagree with that of course. The key issues there were lack of expressiveness in Java and the relative verbosity of that language. The issue in Scala that Kotlin tries to address is the complexity of that language. Jetbrains actually considered using Scala as an alternative to Java and in the end decided to create Kotlin instead. With Ruby, people loved meta programming but the lack of typing made it less suitable for larger code bases. I've seen enough messy code bases to agree with that. There are several languages that you could name that ended up with a lot of former ruby-ists that basically feature powerful type systems, similar levels of expressiveness, etc. So there's a progression of languages and programmers. Of course you use a green field language for a greenfield project. Why wouldn't you? Brown field projects are more common in this industry and rewriting them tends to be costly. So, that tends to not be a thing. Particularly successful things last a long time.
• mattnewton 6y ago
  Isn’t it also true that newer languages might have learned from what made older languages hated? Isn’t a massive confound the possibility that language design as a field is meaningful and people are actually improving languages still? I know the article mentions this, almost in passing, but it seems hard for me still to separate the size of the bias towards greenfield and against older languages and I don’t feel they adequately addressed it. The fact that python is definitely a “brownfield” language for me but still one I reach for and cherish as well designed seems to suggest that language design matters more to me.
• fnord77 6y ago
  from the title and the URL, I thought this was going to be which languages are the most and least energy efficient.
• leafario2 6y ago
  Rust is already brown. I love it.
• 0wis 6y ago
  I may have missed a line in the original text, but I don’t find what are the 5 loved brown languages. I feel they may be the most interesting to learn, having passed the test of time and still being loved.
  • sanderjd 6y ago
    If you cross reference the two lists, it is: Python, C#, Swift, JavaScript, and SQL.
• sz4kerto 6y ago
  This is interesting to watch when it comes to Java/Kotlin. Everyone (including me) thought that Kotlin is a 'better Java'. Time has passed and I am more and more convinced that the evolution of Java is just great. It's slow, but when something gets part of the language then it is almost always good (I'm talking about the post-JDK8 era). So I think eventually Java will remain dominant over Kotlin.
  • tonyedgecombe 6y ago
    It feels a bit like TypeScript to me, a bandaid over a wound. In time the wound heals and you don't need the bandaid anymore.
• dcolkitt 6y ago
  Eyeballing which languages are outliers, it seems that python, Swift and C# really stand out as good languages. Though I wonder if it’s that more a function of their codebases being more beige than brown. Python tends to be used more for small, informal, non-critical cases like data science pipelines. It’s less common in the sprawling, mature, long-lived software that wakes you up in the middle of the night. Swift only came out in 2014. So even though it’s widely used, it’s had much less time for code rot on the existing projects. Going the other way, Haskell and Scala stand out as exceptionally bad. I’m pretty sure that the dread truly does come from the inherent complexity of those languages rather than their use cases. However they’re also widely loved. So those language design choices are more polarizing than they are reviled.
• jbunc 6y ago
  Amusing that Scala and Haskell are on both the loved and hated lists. Python and Javascript running counter to the author's premiss is not that odd to me. Both of these language do a good job of adapting to new approaches and technology. I am not a fan of untyped Python and Javascript, but Python with type linting and Typescript are great. Maintaining code without these features is a pain, while the newer code in the same project with these features is more interesting.
• aeturnum 6y ago
  > [from Dilbert] Will there ever be an engineer who says "that last guy did a great job. Let's keep all of it"? I don't know about other people here, but this is almost always how I feel? I almost always feel like the previous team made choices that were sensible given the facts at the time. Most changes I want to make come from the changes in our product since that chunk of code was written. Of course I have my own methodological practices and sometimes I will re-write some particularly ugly copy & paste job the way I want "as a treat," but mostly if something works it works and you move on. The best code is the code that already exists and works.
  • mywittyname 6y ago
    It sounds like you have empathy. A lot of people look at issues with a code base and just assume the problem is due to stupidity. Rather than coming from the angle of, "this person was probably as capable as I am, why did they make this decision?"
    • disgruntledphd2 6y ago
      Yeah, the trouble is that it's easy to update a method to account for a bug, but the cumulative effect of those changes tends to make a codebase more difficult to reason about for new starters. In general, being able to take a few steps back and look at the whole system is often rewarding, but it's super difficult. Actually, people who come to a project later can often be great for this, as they can see the project as it is now, rather than as it evolved. Unfortunately, we tend to be quite bad at letting people take the time to build said mental model. Also, most people hate reading code (or at least they don't take the time to do so). Personally, I really like reading code, and I find legacy projects much easier to work on than many of my colleagues.
• EMM_386 6y ago
  I'm seeing this a lot with SQL it seems. ANSI SQL has been a thing since 1986, and SQL itself having been invented in the 1970s. With the boom of JavaScript on the client, various forms of NoSQL came into existence. Recently, the HN frontpage has open source SQL management studios, Sqlite articles, and Node frameworks for directly executing SQL in JS. It almost seems as if the greater development community is catching up to why these things have been done this way for a long time. People seem to be getting really interested in SQL, maybe because they are at a point in their careers where they are being exposed to it more and the benefits relational models can offer. I'm not debating the benefits of one over the other, just that as trends go, SQL seems to be cool again.
• ajarmst 6y ago
  I'm much more fascinated by the languages that made both lists. Any language (Haskell and Scala as well as---inexplicably---HTML, SQL and Shell programming) that makes both a 'most dreaded' and 'most loved' is probably interesting enough to investigate) p.s. I must confess some disappointment at no Lisps on either initial list, especially on a Y Combinator site, but I think Haskell has usurped the "Language beloved by people who make it very clear they think they're better than you" throne. I blame Norvig's defection to Python. pps: Shell? HTML? SQL? Really? Also: VBA is still a thing? Ewwww.
• tompazourek 6y ago
  Strange to see R as dreaded... It's not a tool for everything, but for the right niche (data analysis), it seems like a very sensible choice. Could it be that it's something that non-programmers are forced to use if they want to do some advanced stuff? And that these non-programmers dread programming in R not because of the language, but because it's programming. If not, then what is so dreadful about R?
  • fwip 6y ago
    R is mostly just a different paradigm than most programmers are used to. A surprising number of them are scared off by R's 1-based indexing by default, or the slightly-unfamiliar syntax. It's designed for REPL usage foremost, and with vectors / dataframes as the normal unit of operation. There's also a whole bunch of built-in functions with unfamiliar names and options, and R libraries tend to be similarly opaque to the user with a programming (non-stats) background. For an R-like written for programmers, see Julia.
    • disgruntledphd2 6y ago
      > For an R-like written for programmers, see Julia. Yeah, if you look at the people behind dataframes.jl, it's a lot of people who were involved in R in the earlier days. And there is no better environment for solving a data analysis problem than R. Python can work better for some DS use-cases (sklearn is ace), and it's definitely better for glue but if you need to understand what the hell is going on for a product/service/whatever, R is definitely the right choice.
  • dunefox 6y ago
    "Sensible choice due to the ecosystem and tools" and "loving the language for its features" are two very different things.
• meetups323 6y ago
  The author seems to completely ignore the possibility that language designers get better at designing languages over time, and people simply prefer to develop new projects in well-designed over poorly designed languages. This to me seems to be the null-hypothesis, and I see no evidence on the page that use in "greenfield projects" vs "brownfield projects" provides any more indication than a simple underlying "well designed" vs "poorly designed" metric. For instance: why do people dislike Objective-C but like Swift? Could it be simply that Swift was expressly designed to ease pain points of Objective-C? Or is it, as this author claims, that Objective-C is in more legacy projects and if Swift were to have been invented first then replaced with Objective-C, people would suddenly love Objective-C and hate Swift? Same reasoning holds for C/Rust, VBA/Python&TS, Assembly/LiterallyAnythingElse [1], Java/C# [2], and R/Julia. [1] I imagine if this author were to have been around to write this in 1980, they'd make a claim something like "People say the enjoy C projects more then Assembly ones, but in this essay I describe how this is actually just because Assembly is more likely to be used in existing codebases, and if Assembly had come around after C people would certainly prefer Assembly and detest C" [2] Note C# is incredibly enterprise/legacy, yet well-designed. This supports the null hypothesis perhaps the most.
  • Zarel 6y ago
    Yeah, this seems like one of those "correlation is not causation" situations. If you noticed that languages many people loved were correlated to languages that were used for new projects, it seems crazy to eliminate "loved language causes people choose it for new projects" in favor of "people choose it for new projects causes loved language".
    • mavelikara 6y ago
      The article makes the observation that "loved languages don't have legacy codebases". Also, using Ruby as an example, it postulates that "once a language has enough legacy codebases, it stops being a loved language".
      • meetups323 6y ago
• stephc_int13 6y ago
  I've used mostly C and orthodox C++ for more than twenty years and I am only starting to consider alternatives. Zig and Jai are looking very nice, in my opinion. I am pretty sure that Rust will follow a route similar to C++, too complex and too many young coders trying to embrace it without enough experience.
• chasedehan 6y ago
  Love how Haskell makes it into both loved and dreaded languages.
• luord 6y ago
  This presents a strong case, IMO. And taking in account that studies have been made suggesting that language choice has little to no correlation with number of bugs[1], it would make sense that recency bias plays a part in, well, preference in technologies. I'm interested in the outliers though: Both the ones among the loved brownfield languages, and the ones present in both loved and dreaded lists. I feel like programming language designers, people in charge of choosing the stack for new projects, and people considering renovating legacy codebases can learn a lot about what to do and what not to do from those. [1]: Though that one ended up in a flame-war, like discussion on programming languages tend to do. Apparently not even academia is safe.
• psfried 6y ago
  Another possible explaination is simply that people have gotten better at designing programming languages. Or that newer languages are better adapted to solving the problems we now want to solve. Which really shouldn't be too hard to swallow.
• hardwaregeek 6y ago
  Maybe we need more innovation in reading code. Language servers and autoformatters already are doing a lot. Visualizers could make it way easier too. There's a general issue though that we haven't figured out the silver bullet for abstraction. Traits/typeclasses are convenient but they're inherently global. Interfaces are similarly global and are quite annoying when you have to take in two objects of the same type. Omitting traits and using something like modules can work but you lose quality of life stuff like easy printing (quick, how do you say something is printable in OCaml?). I'm not familiar with Erlang/Elixir but I suppose message passing could be an option, although I'm not sure how it'd work for memory intensive situations. You could go the PL nihilism route and be against abstraction as a whole, but I don't think that's a valid answer. Abstraction is necessary for code to function at scale.
• alexshendi 6y ago
  Two words are enough: Rampant Neophilia.
• Lammy 6y ago
  > "It’s harder to read code than to write it". Let’s call this Joel’s Law. People have said "Spolsky's Law" for a long time about several different aphorisms, but when I hear it I assume people usually mean this one: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
• leshawelch 6y ago
  Somehow Haskell ended up on _both_ the top 15 Loved and Dreaded lists...
• 8note 6y ago
  What I really enjoy about typescript is that the things I do frequently in java code require like a tenth of the effort to make. Wrapping data into structure objects is pleasent in typescript, so I do it more. Same with handling missing entries. I don't need to wrap each indirection in yet another if statement to check for null; in typescript I can do the whole check at once and worry about what to do if I cant find the data using ?? When I'm working on the java code now, I'm mostly saying "this would be so much simpler to do in typescript"
• jokethrowaway 6y ago
  That's definitely a good explanation for language sentiment over a high number of developers. I don't think these results or this article has much use in any language discussion, simply because I wouldn't trust the majority of developers to recommend a language. I'd rather read why I should avoid Ruby on Rails magic from an expert.
• g42gregory 6y ago
  I am very surprised that Python was not a "green" language. Why would you not use Python for various new Deep Learning projects? What would you use instead, then? I am questioning the author's Python assessment. Also, I do not program in Java, but I think many new corporate large-scale projects are done in Java these days (and in C#, if you are a Microsoft shop). Many new high-performance projects (Deep Learning infrastructure) are done in C/C++ for the reason of needing to manage memory directly. No new projects in JavaScript? What would you program the (new) browser scripts in, then? I am not sure what the brown-field languages are, really. COBOL is the one, for sure. I think rating languages is a highly-perilous task and the author did not disappoint.
  • dunefox 6y ago
    > What would you use instead, then? Julia, for example.
• tomc1985 6y ago
  Ruby is a top dreaded language?!?! People suck :(
• chrisbrandow 6y ago
  I’m not sure how you’d distinguish the conclusions drawn from this paper from the hypothesis that the newer languages implement newer concepts in a more useful/ergonomic fashion.
• mastazi 6y ago
  Well following along the lines of the article, congrats to Python, Javascript and Swift for making it to the list of top loved languages despite being "brown" languages.
• ankurdhama 6y ago
  The reason for reading code is hard as compared to writing code is that while writing code you already know "what" and you are figuring out "how" whereas while reading code you need to figure out both what and how at the same time.
• bitwize 6y ago
  Stroustrup basically wrote this entire essay in a single sentence: "There are only two kinds of languages: the ones people complain about, and the ones nobody uses."
• BiteCode_dev 6y ago
  Interestingly, the author classifies python as a brown language, yet it's on the top 15 of most loved programming languages. Now, maybe it's because for a lot of people, it's a green language since it only became that popular in the last 10 years despite being an old one (1991). But for me it's definitely a brown language, as I've been using it since 2.4 (we are at 3.9). And I must say, reading a decade old Python code bases, even with the 2=>3 transition in the middle, is still very easy. I went back to a project I wrote 10 years ago (first commit 2011), and the code is clear. I can make changes to it with no problem at all. And it's not even a small project, it's a streaming website that still serves half a million users a day using an old Django. Today I'm working for a client on a FastApi project. It uses all the current modern Python gimmicks, async, typing and f-string and so on. I could get into the code base in less than a day, and make my first commit. I know Python has the reputation to not scale, not be good for big projects or big teams, but It's certainly not have been my experience. The upcoming Python 3.10 has been controversial because it introduce some weird choices for pattern matching. But it's the tree hiding the forest: - it's a sign the language is still actively evolving and will not become obsolete. Legacy design decision will always make adding new features an exercise in compromises. - 3.10 also have been focusing on not-s-sexy but oh-so-important things like improving the error messages (I'm actually very excited about this, I've followed it and it's very well done) So I'm pretty confident it's going to stay a brown, but nice language to work with. Not that's it perfect, the more I use other languages, the more I can see the limits of Python. But I expect it to still be a solid choice for new projects for a long time.
• Normille 6y ago
  >I've wondered sometimes if it's possible to quantify what I hate about hacking SQL so much, but it's hard. For me, any time I have to write any SQL statements it's the totally and utterly unhelpful error messages: >ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your DB server version for the right syntax to use near <insert really long SQL query> ...which, as far as I can see, haven't changed an iota in their total and utter vagueness since I first wrote an SQL query about 20 odd years ago.
• akagusu 6y ago
  I am probably wrong but I think all this conversation are heavily biased because: 1) it's mostly US centric 2) it's mostly Silicon Valley centric Surveys say nothing because they are heavily biased, Google Trends too. While we are discussing Rust vs Go, Python vs Ruby or whatever language is brought on the table, companies around the world are making millions with PHP and many other languages considered legacy. At the end of day, we don't realize that the language and other tools we select to do our jobs are influenced not by how useful they are to solve our problems but how much they increase our chances to get a new job. We disguise our choices as technical choices but they are not, they are, indeed, just our preferences biased towards our necessity to find better jobs.