[HN Gopher] Green vs. brown programming languages (2021)
___________________________________________________________________
Green vs. brown programming languages (2021)
Author : adamgordonbell
Score : 134 points
Date : 2023-08-05 12:26 UTC (10 hours ago)
(HTM) web link (earthly.dev)
(TXT) w3m dump (earthly.dev)
| Karellen wrote:
| > 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_defin...
| yawpitch wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| dkarl wrote:
| 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.
| valenterry wrote:
| Well, that's the thing. Scala is powerful and gives freedom,
| so it is really hit or miss.
|
| A good Scala codebase is a pleasure to work with and is sooo
| much better than the best Java codebase could possibly be.
| But a bad Scala codebase can be horrible and be confusing to
| a point where you'd wish that Scala wouldn't give this
| freedom to developers at all.
|
| Pick your poison I guess.
| herdcall wrote:
| 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.
| civilized wrote:
| > 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.
| schwartzworld wrote:
| 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.
| Shrezzing wrote:
| 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.
| fl0ki wrote:
| 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.
| kykeonaut wrote:
| Tangentially related, but it got me thinking. Does this mean that
| Copilot and friends are always writing old code?
| suby wrote:
| 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.
| nmz wrote:
| 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.
| pharmakom wrote:
| 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.
| adamgordonbell wrote:
| 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/
| jonstewart wrote:
| I agree that dev tooling improvement has been a huge theme of
| the past decade, but the premise that it's exclusive to new
| languages is flawed. I'm a a C++ developer and it has fantastic
| tooling these days: clang-format, the static analyzer, VSCode &
| VisualStudio, gdb & lldb, conan, godbolt, etc.
|
| Being stuck in an old legacy codebase may be hell, and may not
| be -- that seems independent of language, though. But writing
| C++ with new standards, libraries, and tools is a joy.
| the-smug-one wrote:
| I'm a C++ dev also, and I don't agree with you! I use clangd,
| gdb, dynamic analysis tools, no static analysis tools (other
| than compiler warnings). The help I've gotten from Rust
| analyzer compared to clangd is pretty large, imho. Rust
| restraining itself means that our tooling gets to be more
| free.
|
| Also, gdb is... Not that great. Yes, it definitely does debug
| my app and in that sense it is great. It is however pretty
| unstable and gets into weird state I cannot get out of,
| gdb/mi is a mess, and the text interface (TUI) is not
| performant enough. I'm still very happy that I have it, but
| when I look at RemedyBG I get jealous. I'd pay for an
| equivalent to RemedyBG on Linux, if it was FOSS.
| jll29 wrote:
| It is true that writing modern C++ is much more fun than
| writing old C++ in the old days. The code also _looks_ better
| than in the old days, too, but still far from pretty.
| gfody wrote:
| 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 wrote:
| 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".
| ozim wrote:
| I totally don't understand rant about integration with AD
| from C# standpoint. Seems like you meant .NET Framework.
|
| I also don't see how any other language would do any better
| in manipulating Active Directory settings.
|
| Same for ASP stuff, that is like a web framework - like for
| example Ruby on its own does not have anything to do with
| Rails as RoR is web framework for Ruby so, also really
| weird rant if we talk about language itself.
| fnord77 wrote:
| I thought this was going to be about the energy efficiency of
| programming languages
| fit2rule wrote:
| [dead]
| tialaramex wrote:
| 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.
| durumu wrote:
| I think a standard library is not negative, but rather acts as
| a multiplier for decisions. The C++ std::unordered_map
| designers made a _bad_ decision (requiring buckets to be
| iterable) and now, like you say, it 's hard to get people to
| use the superior absl::flat_hash_map. But if the standard
| library designers make a good decision -- for instance,
| Python's extremely well-designed dict that is fast, insertion-
| ordered, and forms the basis of nearly every object -- then
| everyone gets to reap the benefits without the cognitive
| overhead of figuring out what the best hash map is.
| pjmlp wrote:
| The beauty of a rich standard library is that it works
| everywhere there is a full implementation.
|
| I rather have a Goose than none at all, or a GoodGoose that
| only works when all the stars are aligned and I have made the
| right decision regarding what platforms to target.
| pclmulqdq wrote:
| 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.
| IshKebab wrote:
| 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 wrote:
| You're just stating the "obvious hypothesis" which the author
| is challenging, and showing evidence against.
| IshKebab wrote:
| He provided zero evidence against it.
|
| He showed that more loved languages are likely to be newer.
| That is consistent with them being loved more because they're
| more likely to be used on greenfield projects. But it's
| equally consistent with newer languages being _better
| languages_.
|
| I think it would be difficult to argue that newer languages
| are not usually better than old ones. They wouldn't be
| adopted if they weren't!
| strken wrote:
| Evidence for the existence of factor B doesn't disprove the
| existence of factor A.
| pjmlp wrote:
| 1 - Start Visual Studio, XCode, Clion, QtCreator,...
|
| 2 - File => New Project
|
| 3 - Build
| IshKebab wrote:
| Now add some third party dependencies. Have fun!
|
| vcpkg makes it tolerable, but it's very very recent.
| lesuorac wrote:
| 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.
| brabel wrote:
| 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).
| sigzero wrote:
| Dart is...popular?
| jakey_bakey wrote:
| Some people want their android and iOS and web apps to use
| the same code evade...
| lesuorac wrote:
| No the author didn't read the methodology of the Stack
| Overflow Survey nor did they notice they can get the
| historical CSV of the survey going back to 2011 [1] which
| literally tells the number of respondents per language (as-in
| how popular it is; no secondary population from TIBOE
| needed). Nor do they seem to understand (unlike you who does
| understand) that Loved and Dreaded have very specific
| meanings.
|
| They did shoddy work and I'm calling them out on it. They
| very easily could've tried to use the past (then) 9 years of
| data to show that as a language gets more popular it became
| less loved; but they didn't.
|
| The question of "If Java and Ruby appeared today, without
| piles of old rails apps and old enterprise Java applications
| to maintain, would they still be dreaded or would they be
| more likely to show up on the loved list?" is answered.
|
| It's a no. For 2020, Ruby was 4.5% and Java was 8.8% of
| developer's "Wanted" languages while Go (17.9%), Rust
| (14.6%), TypeScript (17.0%), Python (30.0% !!). Sure a lot of
| people would like Ruby and Java (there already are actually a
| lot of them) but when you're not at the top of the Wanted
| it's going to be very hard to get to the top of Loved.
|
| [1]: https://insights.stackoverflow.com/survey/
| ghayes wrote:
| I surmise that love or hate for a language is closely
| coupled with its stdlib. My favorite languages (Elixir,
| Rust) have some of the best standard libraries (and even,
| Go, for instance, includes JSON encoding and decoding in
| its own). This shields developers from code bases that need
| to constantly reinvent the wheel or pull in many
| dependencies for simple tasks. JavaScript is on the cusp
| here with a bad standard lib that has improved (in some
| ways) over the last 15 years.
| adamgordonbell wrote:
| > but when you're not at the top of the Wanted it's going
| to be very hard to get to the top of Loved.
|
| Loved is based on people who use it. Wanted based on
| wanting to use it. They are separate.
| troupe wrote:
| I think a further nuance (if I'm understanding the author) is
| that a language you are likely to use starting from scratch
| is going to be more loved. While there is plenty of shell
| code out there, it is more common to write a shell script
| from scratch than it is to start a java project from scratch.
| agnosticmantis wrote:
| > Python and Dart, for example, have been much more popular
| recently than in the past, so it's reasonable to assume that
| the percentage of newer code bases in those languages is
| higher than in, say, Java.
|
| And yet Python is the top fifth brown language? And also the
| top third loved language?
| pjmlp wrote:
| Python has been popular for 20 years, starting with Zope
| around 2000.
|
| In 2003, CERN was already doing trainings for Python in
| scientific computing, and Grid jobs automation (what predated
| the cloud), I was one of the engineers that took part of the
| 2nd Python training, and Grid Computing Summer School 2003.
|
| CERN build system for ATLAS/TDAQ used on those days, CMT, was
| written in Python.
| deepsun wrote:
| No, I've been programming for more than 20 years and Python
| was definitely not popular back then. I remember early
| Google even bragged that they'd rather hire a Python
| developer than Java/C++ one, because there were no python
| courses so the candidate learned it by their own.
| pjmlp wrote:
| Wrong developer circles, then. What can I say.
|
| https://en.wikipedia.org/wiki/Zope - 1999
|
| Dr Dobbs' Python Weekly URL, since 2000
|
| Dr. Dobb's Excellence in Programming Award in 1999
|
| "Guido van Rossum, creator of the Python programming
| language, and Donald Becker, chief investigator of the
| Beowulf Project, which achieved supercomputer performance
| using networks of inexpensive Linux-based PCs. "As
| creator of the Python programming language," Dr. Dobb's
| noted, "Guido van Rossum has given software developers a
| tool that addresses many of the shortcomings of more
| well-known and mainstream languages...Python makes it
| extremely easy to build complex data structures out of
| objects, lists, dictionaries, and the like. It is
| particularly useful for system administration, building
| GUIs, scripting, database programming, and rapid
| prototyping." Erickson detailed Donald Becker's
| contributions to the programming world by describing the
| problem Becker set out to solve: "One of the challenges
| in the realm of scientific computing is to efficiently
| and affordably handle large data sets," Erickson wrote.
| "To tackle the problem, Donald Becker and Thomas Sterling
| launched the Beowulf Project, a cluster computer
| consisting of high-performance PCs built from off-the-
| shelf components, connected via Ethernet, and running
| under Linux. Ultimately, the goal of the Beowulf approach
| was to achieve supercomputer (gigaflop) performance at PC
| prices."
|
| -- https://en.wikipedia.org/wiki/Dr._Dobb%27s_Excellence_
| in_Pro...
| robertlagrant wrote:
| If something didn't seem popular because you have to be
| in the right circles to realise it's popularity, then
| maybe it wasn't that popular.
| pjmlp wrote:
| Yeah, because Dr. Dobbs used to give excellent awards to
| obscure technologies.
| nerdchum wrote:
| Erlang not loved. Sad to see.
| rcme wrote:
| I don't think many new iOS apps are done in Objective-C.
| mxmlnkn wrote:
| Note that HTML, Shell, and SQL appear in both the most loved
| and most dreaded lists.
| raincole wrote:
| I'm really surprised that JavaScript is not one of the most
| dreaded.
| cjblomqvist wrote:
| The Gartner Hype Cycle is quite well known and exactly what's
| described here. See
| 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").
| semiquaver wrote:
| The inclusion of shell on the "loved" list for greenfield
| projects is enough to make me doubt the article's thesis.
| lincon127 wrote:
| 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.
| gonzo41 wrote:
| 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 wrote:
| 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.
| memefrog wrote:
| 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.
| brabel wrote:
| > 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.
| einpoklum wrote:
| > That's a pretty bold claim...
|
| I didn't think we could make bold claims on HN. _italic
| claims_ , tops :-(
| lelanthran wrote:
| > That's a pretty bold claim... even though I think it may
| look like this is the case, I very much doubt you would be
| found correct if a proper study was ever made to find out.
|
| I don't think it's _that_ bold.
|
| I have a related but slightly different take: more motivated
| and smarter developers are more inclined to use unusual or
| new tooling. As a result, the new tooling's userbase is
| almost entirely composed of people not minding the hard path,
| and steep learning curve.
|
| Even wrote a blog post about it (https://www.lelanthran.com -
| read the post about the average developer effect).
| einpoklum wrote:
| It's also been marred somewhat by the politics of StackExchange
| management vis-a-vis the community on their network in recent
| years.
| o1y32 wrote:
| 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 wrote:
| > 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+.
| ryzvonusef wrote:
| I like the Format of the developer survey though, and I wish HN
| had one of its own.
|
| @dang is this a possibility?
| jll29 wrote:
| 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.
| lamontcg wrote:
| > 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.
| dang wrote:
| Related:
|
| _Green vs. Brown Programming Languages_ -
| https://news.ycombinator.com/item?id=26902821 - April 2021 (486
| comments)
| smokel wrote:
| 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.
| pjmlp wrote:
| I guess I am mostly a brown language kind of guy.
| troupe wrote:
| 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.
| [deleted]
| Xorakios wrote:
| Surprised that COBOL isn't more discussed. Still the most
| important language in banking and insurance back end programming!
| Amorymeltzer wrote:
| 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.
| thswoer321 wrote:
| Green should also include Zig, Elixir, Gleam, Crystal, Hare,
| Odin, Clojure.
| msla wrote:
| > 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 wrote:
| > 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_ wrote:
| > [...] 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 :)
| msla wrote:
| Part of doing maintenance is being able to migrate to a
| better language, yes.
| uecker wrote:
| 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.
| hutzlibu wrote:
| "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_ wrote:
| Open source projects with a divine developer, no deadlines,
| and no business constraints.
|
| Example: TeX.
| xigoi wrote:
| Clearly having to compile a document three times to get
| correct output is not a bug, but a feature.
| KronisLV wrote:
| > 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.
| pron wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-05 23:00 UTC)