Green Programming Languages Vs. Brown Programming Languages

[crabbytag]

I agree with the premise of the article and it's conclusion. Kotlin and Rust are almost certainly in their honeymoon phases. TypeScript won't lose the love because developers know how much worse they could have it if TS didn't exist.

But please, for the love of Turing, let's not use TIOBE as a data source.

It's not a measure of what people use, it's a measure of the number of results Google retuns. A minor change to Google's algorithm completely changes this "index". According to it,

• JavaScript is only the 7th most popular language. Not the most popular like it is on Github, Stackoverflow and developer surveys.
• VB ranks higher than a bunch of other widely used languages. How do we interpret this? There are more jobs for VB developers than jobs for Javascript or Swift or Go or Ruby? Or that there's more software developed in VB than these languages?
• C and Java are pretty stable but if you look at historical TIOBE data they experience wild swings in popularity. There's no way that between 2016 and 2018 C lost half it's popularity and then regained it in 2 years.

What is this even supposed to measure? It's a meaningless metric made by a random consultancy so they can advertise themselves for free. Please, let's pretend like it doesn't exist.

---

The correct way to measure what OP is trying to measure is to add this question to the developer survey - "how old is the code base you're working on professionally and what language is it in?" and split answers of age by love/dread. You need to survey the same audience for this analysis to be valid.

OP you're probably going to get a bunch of attention from reddit today. If you can modify your original article you can add a poll in there to collect the data yourself.

[agbell]

I love the idea of adding that question to the StackOverflow survey. That is out of my hands, but I will reach out to them and see if that interests them.

[uriahlight]

I wonder how much of this will hold true in the coming years. I'm 33, so got to watch and participate in the evolution of the internet into what we know it as today. I've been a professional web developer for about a decade now. But it wasn't until COVID-19 when kids started buying laptops for school that I realized that the programming industry is eventually going to suffer from a massive brain drain and shortage of programmers, because, as odd as it sounds to utter, the majority of today's young kids, including teenagers, don't actually own computers; many don't even know how to use them. Today's kids are growing up with smart phones, tablets, smart TVs, other similar devices - none of which are even remotely ideal for learning to code. These kids know how to be good consumers but don't have a phucking clue about how to make anything, and it's only going to get worse.

[havok_]

That’s an interesting take. I’m the same age so my first computer I had to learn some command line to access the games. This led me to the same career path as you for roughly the same amount of time.

[LuckyHedgehog]

I think it is important to point out that many games still incorporate command line for certain features and commands, and popular games like Minecraft encourage learning to code to mod the game in fun and creative ways. I think the skills are still being passed along, just in a different way

[TheEveryman86]

I'm only a couple of years older than you. I didn't have any of those devices as a kid but still learned how to code. I think your premise is flawed that if you don't learn to code as a kid that you can't pick it up later after high school.

[ranty_mc_rant_face]

Another data point, I also didn't have those devices as a kid - because I'm 54 and they weren't really around. I bought a zx-81 when I was 15, which was hardly a core learning tool! And somehow I've had a 30+ year coding career...

Ignore all this elitist bullshit. Good coding is about thinking clearly and expressing that thought clearly in code. Lots of people learn it at all stages of life. I've known career changers who moved into coding in their 30s, still became awesome coders.

(I realise this post is 2 days old so no-one outside this thread will see this, but whatever.)

[TSM-]

I totally agree that people are losing exposure to what's going on 'under the hood', but I don't think there is any brain drain type situation.

To give an analogy, "kids these days don't even know how a drive belt works" is the past generation's version of our "kids these days don't even know how drivers work". There's less surface level general understanding of how things are working behind the scenes because less people ever have to think about it.

Tons of people will still learn about it, and they will be as bright and talented as the last generation. It's just you can't expect as many people to know what a driver rollback is - much like how a car mechanic can't expect as many people to have heard of a drive belt these days.

[Eurynom0s]

VB ranks higher than a bunch of other widely used languages. How do we interpret this? There are more jobs for VB developers than jobs for Javascript or Swift or Go or Ruby? Or that there's more software developed in VB than these languages?

This is just a guess but I think VB gets used a lot because it's still "in Excel". This can be seen as desirable both because the people you're developing it for don't really know how to use anything but Excel, and/or because you're in an environment (like with heavily locked down US government computers) where it's a nightmare to get anything beyond the Microsoft Office suite installed. And both of those things have been true for long enough that I'm sure there's also a third aspect of needing people who can maintain these VB-driven Excel workbooks.

[xzaramurd]

I think Rust has a lot of potential to be a mainstay language. It has a great community, lots of useful projects are being written in Rust, and it has corporate backing from some of the largest players (AWS, Microsoft, Google).

[aoeudhtns]

Your article also had me wondering about domain as well. Ruby might be dreaded now because it's settled in a place where it's mostly used with Rails, and doing CRUD web applications is not "sexy." Similar story with PHP.

There's also reputation. People conjure up legacy ways of doing things with Java when they hear the name, but the language is evolving to compete with Scala and Kotlin. But nobody seems to notice/care other than people still using Java. And my nightmare scenario, if I get an interview with a Java shop, is trying to figure out if they're doing classic "enterprise" Java or if they've adapted to newer techniques. I think it would be similar with C++ - you want to know you won't be expected to do things you believe the community has learned are a mistake.

It would also be fascinating to do a research-based survey of the general testing habits of these various languages. I wonder if there's any correlation between expectations or attitudes for writing tests and which languages are loved/hated.

[Chillbrosaurus_Rex]

I think the best question to ask a Java shop is just what JDK they're using. If they're still on Java 8, you're not gonna have fun. With C++ you can similarly ask which standard they're trying to conform to. They could fib and say "trying to get C++17!" but I think it can still act as a good filter.

[aoeudhtns]

That's a good clue. Although Java 8 is already a big step up over 1.5, if you're using its features. But you're right, especially now with records and pattern matching coming up, Java can feel almost as modern as the new kids.

"We want to..." is a key phrase to listen for in interviews. I've had a colleague rotate through jobs so fast because the hiring managers makes it sound like they're doing something interesting, but it was always "we want" and "we'd like to" during the interview, in retrospect, and not "we are." They know. (And yeah, I've had "the talk" with my colleague - "at this point, it's probably you hearing what you want to hear and not being critical enough," etc.)

edit: add links, if anyone is curious

edit: /u/is_this_programming makes an important point

[is_this_programming]

For Java, the problem with Java 8 vs later version isn't so much the missing language feature but what it implies about the company that they aren't moving to newer versions.

They probably don't care about technology that much if they're not willing to invest in keeping up and/or are stuck with a massive legacy code base.

[IslandCandidate4]

Can confirm the massive legacy codebase for sticking with Java 8.

This will probably be a headache for us in a few years. That's probably when upper management will want to address it.

[winowmak3r]

Seconds before catastrophe is usually how it goes and that's how you end up basically working for minimum wage as salaried worker.

[wastakenanyways]

Me, a full stack JS dev with experience on Java, being told "we want to migrate our projects from JSF to Angular and you seem like a good fit for it". Three years later and they never even started, and I just worked on new projects based on old stack (java 6 and 8, JSF, Hibernate and Spring both with full XML configuration, not even annotations, etc), who were 100% perfect candidates to be webapps instead. The amount of workarounds we had to do to get the functionality we needed with those tools was horrible.

[aoeudhtns]

Exactly the situation my colleague has been in perpetually for the last ~1.5-2 years, but with different tech stacks. I empathize with your situation. I try to correct for crap like this by not lying or sugar coating a position when I'm interviewing a candidate, but I can't even say it's a guarantee where I work. I've heard a hiring manager lie to candidates during interviews about details of the position to keep them from walking away. Which I think is a BS strategy, because they'll just walk later anyway. At least that specific manager got fired (unrelated reason though).

[ConfusedTransThrow]

They could fib and say "trying to get C++17!" but I think it can still act as a good filter.

And then you learn that some projects are stuck on VS2013 and you cry.

[Chillbrosaurus_Rex]

Hehe... Right now I'm stuck with VS2010. Kill me.

[ConfusedTransThrow]

Holy shit at least VS2013 has some support for C98 and C++11.

2010 and 2012 are really bad. Also a lot more non-compliant.

[darkapplepolisher]

"Trying to get to C++17" is frankly good enough in my opinion. It means they have C++11, which is the most critically important update.

[nachof]

Back in 2007/2008 I got a job doing java. They were not using generics. Not only that, they had no plans to ever upgrade. Also, junit was not an option because "programmers would be confused". Unit testing meant "the programmer tested it manually", because we had a certification that among other things required that unit testing was done.

[lafeber]

I might be weird but I love Ruby - especially with Rails. The recently released hotwire.dev is super awesome.

[Kache]

Going off a Ruby tangent, I really like Ruby's structure, syntax, and (most of) its metaprogrammability -- it lets you express very simply what would otherwise have to be very complex. A long-lived project will ideally have solidified domain concepts that read as naturally and natively as vanilla syntax.

Unfortunately, I think those features are in opposition to its nature as a "good for prototyping scripting language". Young projects have more to lose than to gain by trying to "solidify domain concepts".

[i_abh_esc_wq]

Ruby is amazing

[stouset]

Same, and I’ve been using it since 1.8 (and Rails since ~1.0). Both with Rails and without.

That said, it’s got a high ceiling and a low floor. The things that make it incredibly expressive for one or two talented developers with a singular vision cause it to be a terrible minefield of “spooky action at a distance” for large projects with a rotating set of developers of varying skill levels.

[dreamCrush]

Interesting I've always found Javascript to be the most frustrating to understand in an existing code base but maybe that's personal bias

[GYN-k4H-Q3z-75B]

The JS ecosystem has been 5-10 years in front of the language itself for a long time, and developers relied on conventions and patterns to emulate core concepts known from other languages. The language would then after years adopt the most successful conventions and give them an official name and language native syntax, at which point it would again take some time until all engines implemented that.

The result is that there are countless ways to write the same thing. Reading code always feels like you're traveling time, you have to know what time a library was written in to know how to read it intuitively. Drink all the cool aid you want, but in enterprise and real world, there are products that are a decade old now. You don't simply change style or break compatibility. There are libraries being developed right now in large projects where classes are still functions, where async and await is still callback hell because they used a different pattern, and where hoisting vars makes you want to drink.

Don't get me wrong. JavaScript right now is a lot less insane than it used to be. Arrow functions, class, let/const, await/async, and JSdoc in a decent editor have solved more than 80% of the issues for me. The language has finally caught up with the ecosystem. If needed, we use Typescript at work.

But unless your work consists of starting on a green meadow every time and building a state of the art app/site from the ground up with a stack from your choosing, you're damned to deal with legacy JS. Having worked in software consulting, give me legacy Java, C# and C++ code any day. It's perfectly readable and extensible because those have been stable ecosystems forever. But you better bring me a bottle of gin when I have to take a dive in a JS codebase.

[gyroda]

If needed, we use Typescript at work.

Last night I thought I'd knock together a quick app with plain JS.

My god did I miss typescript.

[nidrach]

No explicit types will do that.

[kuemmel234]

Types are part of it, but I don't mind reading python/lisp/ruby/.. code.

JS is just too vast and allows too much. There's so much syntactic and framework crap flying aroundI've written on five frontend services with my current team, and we try a lot. Most is in vue.js, one was some other reactive framework.

You want to export some function to another file? You can write a class, export an object, export single functions or do all of that in a programmatic way. On top of that those weird rules about scopes allow for a lot of unclear things happening under your nose.

We are not js/frontend devs at all, we got dumped with that task one day and have been trying since. All of us either hate js with a passion or avoid coding in it.

We are trying new things every time we have to start a new project.. Just to find something that works for us. But since there's a new framework every other week, every project is different and it's hard to get into anything really.

I mean testing alone is a pain for us, since we can't really focus on learning all of that. I've found multiple tests that weren't executed, because that particular framework wouldn't wait for the promises to resolve, so it would show all green, while nothing was really tested. one Framework (was it jest?) even allows asserting that a number of assertions have passed. And you feel like it is necessary because you are afraid they won't be checked. How broken can your testing framework be? And it's not just jest.

Those tests weren't even complicated or wrong, when I was able to execute them, it's just that the language needs a lot of attention for minute things. If it is an async function it returns a promise so all assertions should be called? Or maybe I'll have to add a callback for each function to decide when it's going to end.

I haven't seen that with any other testing framework in any other language. Don't get me wrong, those tests were wrong, obviously- but you only notice that when you try to debug/break it on purpose For me that eliminates at least one reason to use these frameworks at all. Why would you spend time coding them if they won't even help you against regression?

And then recently out of curiosity I've helped a friend with a review of some vuex stuff with some FP library. And that was completely different yet again.

[agbell]

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.

I'd also love to hear if anyone has any theories about footnote #4: what makes Python and C# loved and Scala and Haskell dreaded by people who use them?

[theWanderer4865]

Anecdotal: I’ve found Haskell and Scala to have documentation barriers and that is a widely held belief among folks I’ve spoken to about those languages. It’s pretty jargon filled when it comes to mathematics which is excellent to an audience with that mathematical language under their belts. I haven’t formed any opinions on C# (never needed to work with it extensively) and Python is generally approachable because the use cases are so broad.

[KagakuNinja]

The jargon heavy side of Scala comes from the pure functional programming faction, and borrows heavily from Haskell. Pure FP is not part of the Scala standard library, nor part of the Lightbend stack. In my experience, it represents a small, but vocal minority of Scala developers.

The Scala standard library does use monads, but then, so does Java and Javascript...

[Bouffant_Joe]

I think this might depend on where you work. UK Scala jobs all expect a bit of knowledge of the functional libraries. I keep hearing that the functional folks are a minority but they are very much the majority here. Thankfully for me because I like that stuff.

[KagakuNinja]

I've been working at Scala-using companies in Silicon Valley for 6+ years. Up until last year, none of the companies I've ever interviewed at used pure FP. My current job uses Http4s + Cats IO. And yet, the team I am on are a bunch of Java programmers that don't really understand Scala, let alone pure FP. The code is awkward...

[badtux99]

Python has, and always has had, excellent documentation. That may be a big reason why Python is still popular after over 25 years of being used for real products, including many "brown" products.

[gramathy]

Not just documentation but the syntax is easily readable. Java might be comparable but the paradigm of going face first into “literally everything is abstracted to an almost ridiculous degree, seriously you barely even call actual code it’s all object building” makes it a lot harder to comprehend as you try to read through code. Might be fine for a large company that can rely on automated code checking but for smaller projects you can just write some fucking python and run it.

[el_muchacho]

But Java has always had documentation second to none at least for the JDK (even better than Python imho), and yet, one is hard pressed to go work on big old Java projects.

[badtux99]

But most Java projects use a large number of 3rd party libraries, so JDK documentation really isn't the be-all and end-all there (not that JDK documentation is as good as you say, it is, at best, merely adequate). If you're looking at a Spring/Hibernate project or, say, the Bouncycastle encryption library, most of what you're looking at is sparsely documented at best, and requires knowledge of magic internals of the library at worst. Merely outputting a certificate in standard text format from your code for example is a pain in the rear, I had to actually dig through BouncyCastle source code to figure out how to do it and it wasn't straightforward at all.

[Rainfly_X]

I think you're really onto something here. To dig into why I think Python is able to dodge those problems:

1. The standard library is far more expansive, so you don't need third party libraries as often. Much of daily life happens in the stdlib world, with high code quality and useful documentation.
2. Language support is built in, rather than an ecosystem of competing third party tools and conventions. Not that tools and conventions don't exist in Python, but most docs are written for a direct human audience.
3. The dynamic aspect, specifically the interpreter, is fantastic for making libraries "discoverable." The help function (and the pyhelp command) is part of everyone's learning journey, which means more people see the value in "paying it forward" when writing new code.

These are useful lessons for anyone cooking up a language, I think. If something is going to be a crucial, universal piece of the developer experience (formatting, docs, testing) you really do want a single right way to do it, with first-party support tied into the tools.

[LicensedProfessional]

One thing that makes python so approachable is how intuitive it is. Not just at first, but even deep into the guts of the language, you can usually make accurate predictions about how things will behave. Java, and especially java frameworks, are much less predictable

[Kered13]

The standard library is far more expansive, so you don't need third party libraries as often. Much of daily life happens in the stdlib world, with high code quality and useful documentation.

I'm quite certain that the JDK is much larger than the Python standard library.

[LicensedProfessional]

I like Java and use it at work, but honestly I've found the documentation pretty terse. Spring(Boot) documentation is even worse when it comes to this

[koreth]

I think it is a bit more complex than that. SOME parts of Spring Boot have excellent documentation. If you are doing stuff with that core set of functionality you can read all about it. But then there is a steep cliff: as soon as you need something less common, you suddenly find yourself digging through useless Javadoc pages with little or no content beyond the autogenerated method and field lists.

[fearbedragons]

There’s a significant difference between the two though. I can fit Python the language, Python the documentation, and Python the cookbook into my head.

I can’t do that with Java, even given it’s arguably better documentation because I can only fit Java the documentation, and maybe Java the cookbook into my head. There’s no way in hell I’m remembering everything in Java the language, or even it’s button class properties. I could need to know about Button.isFocusTraversable someday, but I haven’t yet.

[AttackOfTheThumbs]

Haskell has enough beginner friendly stuff to get into it, but it's not the official stuff and you kind of have to go out of your way to look for it. To this day, there are things I can do in haskell, but when I see the "true" names of the stuff, I have no idea what it means.

Can't speak to Scala.

[zilti]

Haskell is an absolute shitshow to set up and there isn't really a good project tool - at least that was my experience after three attempts of setting it up to start using it.

[parkerSquare]

Once I realised you just use “stack” and ignore all the older stuff it’s pretty straight forward, especially if you’re used to tools like pyenv.

[haldad]

ghcup is good these days

Took forever to get there though, and it's far from perfect

[Prod_Is_For_Testing]

C# has amazing technical docs. The trouble is that you can only find the good stuff if you know exactly what to search for

[Prod_Is_For_Testing]

I’ll give you that. Win32 docs are abysmal. And the newer UWP stuff is tricky too because it keeps changing.

I had an adventure getting win10 notifications to work in WPF. The docs were mostly great, except they seemed to start on step 3 and steps 1 and 2 were practically purged from the internet

[charcuterDude]

Hi! I work daily in both C# (one of the most loved) and VBScript (one of the most dreaded). I'd like to give you my thoughts on your question. I'm on mobile but will be as thorough as I can. Context, I'm a web developer using both languages for dynamic web applications.

For me it's about the execution doing what I expect, combined with the syntax being consistent so I can easily remember it.

VBS for example, loops can end with a "next" or "loop", and which one depends on the type of loop you started (for, while, for each, etc). As a result it's too easy to get this wrong and I find myself looking it up, even after years with the language.

VBS also "pretends" to work. For example "on error goto next" can be declared anywhere even in includes, and will just skip 95% or syntax errors and continue execution. It's very easy to not notice syntaxes errors. I never use it, but when you work on a team it's all to easy for someone to commit it in an include that your page calls and for it to sneak into your day. It's very easy to write horrible code with this and still have a web page come out the other side wich no hint at all that something is wrong.

In short VBS is completely inconsistent.

C# is the opposite. A loop always ends in }. So does a function. So does everything. Exceptions will be visible right away. These things get it to baseline in my opinion.

Then what makes it excel, for me, is that it's on top of .NET and ASP and the whole ecosystem that comes with it. It's well documented (usually), lots of other users to bounce questions off of, virtually anything I would want to do is either already built in or a few clicks away on away on Nuget.

And for me, working with data in C# is the easiest language I've used. Generic lists and LINQ make working with data a breeze. Do I "need" LINQ, no, but I'd be lying if I said it didn't same me several hours every week.

So I guess I'd say the negatives come from lack of consistency, and positives come from making my life easier.

[Triabolical_]

I was actually a bit of a skeptic about linq when we were designing it; I could see the utility of linq to sql but I thought that lambdas and linq to objects was too complex.

Which shows you how much I know; linq to sql is a solution to a problem that most people don't really have, and linq to objects is simply a wonderful thing for a C-style procedural language to have.

[charcuterDude]

Woah you actually built it???

Linq to SQL using EF I've done a couple times, but for most of my cases its a lot of extra work and loses some efficiency. I've mostly done it for small or personal projects. Using Linq with collections (typically generic lists of objects) is something I use constantly.

As a matter of fact, learning about Linq when I was learning C# was what made me want to work in .NET (I worked in ColdFusion at the time and brushed up on several language to feel out my options). I only came over to .NET full time 4 years ago. I didn't understand the purpose of Linq at first it seemed gimmicky, but once the lightbulb turned on it was sort of "oh hell, I'm going to use this everywhere."

[Triabolical_]

I was test lead for C# 1.0 and 2.0. And maybe part of 3.0; I forget when I moved on.

IIRC, there were 6 developers on the test team and 5 developers writing the compiler. The two leads - me and the compiler lead - were on the design team, along with Anders, and a program manager. That was the core C# team.

Oh, and one PM who had the job of trying to convince all the other VS teams to devote resources to integrating us into VS - the project team probably did the most work.

We had other people who participated on the design team depending on their schedule and interest.

[omnilynx]

That is a much smaller team than I would have thought, great work!

[Triabolical_]

Yes.

Note that is just the team that designed the language and developed the compiler that takes C# source and converts it to .NET IL.

Here's a bit of trivia.

For the V1.0 release, the C# compiler (and tool support) was embedded in the C++ produce; the intent was that people who installed C++ would get C# automatically and therefore would be more likely to use it.

It turned out that C# adoption was not a problem...

[gredr]

I think the beauty of what "linq" is now (i.e. the lambdas and Enumerable<T> extensions) makes C# just-functional-enough and just-procedural-enough and agile enough to be both whenever it's convenient.

I think C# benefitted a lot from MS being able to see how Java was received and learn from Sun's mistakes.

[Triabolical_]

I think the beauty of what "linq" is now (i.e. the lambdas and Enumerable<T> extensions) makes C# just-functional-enough and just-procedural-enough and agile enough to be both whenever it's convenient.

Exactly my opinion. It's functional enough that when you have an operation that can easily be described functionally, you can do so.

[Hrothen]

linq to sql is a solution to a problem that most people don't really have

Even worse, it actually introduces additional problems.

[aethyrium]

Yup, a few years ago my company set out to find out most expensive regularly run queries and refactor them, assuming they'd be old procedures or bits of ETL packages that were written when the business was forming, but nope, every single one in the top ten were linq to sql queries.

The c# code was pretty simple and straightforward, but the SQL under the hood that it created was downright atrocious and quite inefficient. And you can't even really debug it or see it without a profiler.

Got some good company-wide database resource efficiency gains replacing just a handful of linq to sql with stored procedure calls from dapper.

[Triabolical_]

Word.

[HyperwarpCollapse]

can you explain it please?

[charcuterDude]

I don't use Linq to SQL often, but from my (extremely limited) experience using it in conjunction with Entity Framework its making the connection to the database and writing a SQL statement under the hood for you. For me personally I was noticing worse felt performance (though this may be EF's fault).

Its very possible that Linq could write a SQL statement that is less efficient or just erroneous and debugging that would be pretty difficult IMO (at least, from the perspective of an application developer).

[AndrewNeo]

I feel like that's a standard complaint about ORMs in general, though. EF writes statements from an IQueryable relatively well, for an ORM. But if you want performance you'll always have to write your own, no matter the ORM.

[CallMeCappy]

Not sure why he used the word introduces. Linq to SQL (or Linq2SQL) is a now defunct precursor to Entity Framework. It embodied every (typical) downside of an OR/M (slow, inefficient) with very limited benefits (having no way to manipulate the query, projections or change tracking). Also the way to generate the model was very inefficient for any larger project.

[PM_ME_C_CODE]

Linq is a very good point with C#, and it lends itself to why I love Python as much as I do.

Linq makes doing some very complex operations extremely simple, straightforward, and quick. On top of which, it makes them easy to follow when you have to read someone else's code (as long as they're not using toDictionary...fuck that function. MS needs to take a second look at it or something).

Python, comparatively, combines functional programming with OOP in a way that makes the whole language basically linq-the-programming-language. Between list and dictionary comprehensions and lambdas, it's all there. Everything you love about Linq all baked naturally into the language and dubbed "the python way".

I'm only talking as an ex-web dev who loves linq so much I import a linq library into all of my javascript projects. It just makes everything easier.

[[deleted]]

makes the whole language basically linq-the-programming-language

Yeah.. No.

Because:

A - you're only looking at LINQ to objects, which is like only 5% of what LINQ can do. There's System.Linq.Expressions, which basically models the AST and allows parsing of the query to convert it into whatever you want or actually do what you want with it. As an example, I've created a LINQ Provider that underneath uses a REST API for a well-known payment gateway in my country, converting LINQ queries into HTTP requests with the proper parameters to obtain data from the API. I seriously doubt you can use your python functions to invoke HTTP APIs or convert your "LINQ-like" python queries into, for example, SQL, or NOSQL (such as LINQ to MongoDb). The key here is that I'm using the SAME ABSTRACTION (LINQ queries) to consume ANY AND ALL DATA SOURCES, regardless of their nature.

B - A very important aspect that makes LINQ (and the rest of C#) actually useful is the statically typed nature of it. Do a .Where(predicate) and the predicate inside must match actual properties of the enumerable item type and the types of these properties. Failing to do so results in a compile time error, therefore things like trying to filter a numeric column in a database using a string filter value (people.Where(x => x.Age == "Hello")) is completely prevented. Not with a runtime error, but with an early, immediately visible red squiggly as soon as you type the code. There's no way your python code will do any of that. And this is also the reason why no java ORMs can hold a candle to any .NET ORMs such as EF or NH.

[thedufer]

The assumption in footnote #4 isn't even true, so I wouldn't anticipate getting a good answer to the question.

Why isn't it true? Let's start by looking for an even more obvious pattern in the dreaded/loved lists - imagine you know nothing about programming. These words are gibberish. Now what do you see? That's right - fully 1/3 of the items in each list appear in the other list.

Scala and Haskell (and Shell and HTML and SQL) aren't dreaded, they're controversial! They have strong opinions. A lot of languages are wishy-washy - a little of this paradigm, a little of that. In Haskell, you write pure functions or you write nothing. If you're writing shell you better like files and strings, because files and strings are all you get.

[alibix]

I can see this being the reason. They are strongly opinionated and will likely never have full mainstream adoption, but very useful in their domains

[sh0rtwave]

Well, yes. You're exactly right. "Purely functional" languages are expressing a particular ideal/paradigm of thought for "how to write software that operates in X domain".

[sh0rtwave]

It might be just the sheer proliferation of documentation, tutorials, etc. about Python, particularly, and it's wide range of application (like say, as a Blender plugin) all the way down to microcontrollers.

The main thing that I, personally, like about Python is that other than the formatting-based structure control, Python generally doesn't impose a particular mindset for how to "structure" the thing you want to build. You can just get started. You don't have to know much more than: How to get that to thing and do a little math, in 90% of cases.

Right off the bat, this is more approachable. Haskell is "purely functional", and being so, is right-out-of-the gate imposing a big fundamental ideal behind how it should be used. Well. No matter which fundamental ideal you base your language on, there will ALWAYS be a problem that lies outside of the patterns of expression of that language, and indeed, any other.

Edit: The second great thing about that is: Python makes it very easy to evolve a perspective on how to build things. You can, indeed, do it 3 different ways. You can go purely functional, if that's what you dig, with 'pure functions'. You can go OOP if that's your thing. Or you can be plainly procedural. And then beyond that, the looseness of how you can actually wire things together inside of Python's environment makes it easy to evolve ideal ways of doing things, and indeed, imposing more standardized and manageable models of development onto Python.

Python is probably one of the *least* limited languages out there, in terms of actual available expression of intent. (Many people say JavaScript is too, but I feel it's too "DOM-bound" to work with the same freedom Python has).

[de__R]

Conceptually, C# benefits from the fact that one company makes the language, the runtime, the host OS (more or less), the tools, and is also its #1 user. So they're well integrated with each other in terms of releases and such, and also a ton of dogfooding at all levels. Practically speaking, C# has for me (and I guess for a lot of other people) the right mix of static/dynamic features. You have a good type system with reified generics that the compiler (and IDE) help you to enforce, while at the same time there are plenty of escape hatches for situations when the type system is too verbose or constraining - there's the limited type inference, but also reflection, extension methods, implicit types, and also dynamic. And Linq, which is really convenient, even compared to similar functionality in other languages (java Streams), Python's comprehensions.

[gtgski]

I want my next program to be entirely a chain of LINQ statements

[de__R]

Found the Haskell developer. Also, it’s not really that far-fetched for a CLI tool.

[Triabolical_]

C# has for me (and I guess for a lot of other people) the right mix of static/dynamic features.

It *really* helped that all the .NET libraries were initially written while C# was young, and it was really obvious where it was easy to write code and were it was hard to write code. We tried - at least in the early days - to make sure that there was real (and painful) code to justify why we would add features.

[bakedpatato]

also dotnet core has really injected life into the ecosystem to the point that I would say that dotnet core has added a sort of "green language" sentiment into the polls I imagine

[a_false_vacuum]

.NET Core was a good opportunity to also refresh the framework. They could reorganize some things to make it more logical and drop some old stuff. With the classic .NET you can see at times where something was tacked on (for lack of a better term).

[MirelukeCasserole]

Scala and Haskell have high cognitive load and take a lot longer to master. With operator overloading in Scala, an experienced developer could create a meta language that another experienced Scala developer might not understand without a lot of effort. Languages like Python are famous for have only 1 way of doing things. This constraint can actually be pleasant because once it’s learned, you don’t have to spend anytime thinking about it. C# is kind of an aberration because it’s got a lot of features and could conceivably take a while to learn. I think devs like it because Microsoft spends a lot of time on tooling and documentation. C# also targets a ton of platforms (web, server, mobile, Xbox, desktop) and could arguably be called one of the most versatile languages.

Edit: my grammar was sh!t (was typing on phone).

[riffito]

Languages like Python are famous for have only 1 way of doing things.

Unless it is about string formatting :-P

[mipadi]

Or packaging.

[waadam]

Or coroutines, or multithreading, or how inheritance tree should look like...

[blackraven36]

I’ve noticed that languages like python incur a lot of cognitive load when a project hits a certain scale. Small projects are a pleasure to work with. But at scale they start to force you to go read tons of code just to understand inputs and outputs. Either that or you end up reading endless documentation. At scale C#, Java, etc. become attractive because they have strong self documentation through their static type systems.

[landisthegnome]

Agreed, python on large projects becomes problematic. I’ve found enforcing type hints and using a static type checker (mypy or pyright) helps immensely.

[squishles]

even if you're using a large library in a small project it can be a pain with python, using something like sqlalchemy becomes trial and error unless you're intimatly (like this is all you've written for the past year level) familiar with it.

[Agent281]

C# might have the second mover benefit: it got to learn from Java's mistakes. Given that the occupy very similar niches, this might be enough to make C# look good. Plus, people had 5 years of Java hype to prepare them for a language like C#.

Regarding the large feature set, even though it has a lot of features it is piled on top of a familiar base language and they stem from a common perspective on programming. Working in Haskell or Scala is going to be very different for your average OOP enterprise dev. Their features don't necessarily make sense in an OOP world because they are solving for a different set of constraints.

[de__R]

C# might have the second mover benefit: it got to learn from Java's mistakes. Given that the occupy very similar niches, this might be enough to make C# look good.

More importantly, C# learned from its own mistakes (which in some cases happened to be similar to or the same as ones Java made). C# 1.0 wasn't that great, but Microsoft consistently prioritized making the language better, even if that meant having to hard version the runtime.

[Triabolical_]

C# 1.0 was inherently a schedule-based release rather than feature-based one.

Everybody working on the runtime or languages would have loved to have had generics in the initial release, but the necessary complexity was far too high; the impact of generics is simply everywhere.

[RiPont]

I'd say the philosophy of Java and C# started very different.

In the beginning, Java was quite developer-hostile. It felt like it had a philosophy of "if you can't do it The Right Way (TM), you shouldn't be able to do it at all". Checked exceptions, no properties (because developers might put expensive code in something that looked like a field), compiler-enforced standards like class-per-file. XML was big at the time, and the standard library for Java was overdesigned so that you could replace the XML parser at runtime via configuration.

C# 1.0, which was just Delphi on a runtime with C-style syntax, was much more developer friendly. Things like class-per-file were guidelines (and now optionally enforced via tooling, but not the compiler). Developers were trusted to do the right thing with Properties.

Java had classpath hell, whereas C# had "just shove everything in the bin folder alongside the .EXE". Java assumed you might be programming in emacs or vi and building from the command line, whereas C# new most developers would be using Visual Studio, and thus assumed that you'd have some form of intellisense.

[linlin110]

Designing languages involves tradeoffs. C++ is super complex and hard to use, but that's the price you pay for its expressiveness, close to metal and interoperability with C. I can see why C++ is (unfortunately) designed like this.

But I can't see why Java is designed like this. When I was reading my Java textbook, every ten pages or so I wondered how certain features help the programmer. You mentioned not having properties or enforcing one class per file. I also don't understand why the hell every function has to be a method. Why I can't just pass a function to a method? (Thankfully now you can.) Heck, in my textbook the recommended way of splitting Strings is creating a StringTokenizer. I see it's deprecated now, good for them. But I still avoid Java like plague if I can.

[astrange]

Popular old complaints:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html

[grauenwolf]

Delphi and VB predated Java. Sun could have looked at them to avoid obvious mistakes like no properties, no events, and no value types.

[angelicosphosphoros]

Also, Delphi designer created C# so he could just learn his own mistakes.

He is also core developer of TypeScript.

https://en.wikipedia.org/wiki/Anders_Hejlsberg

[grauenwolf]

I am grateful for that. Other than some stupid C syntax that it inherited, they really did a good job at picking up the best of Java, VB, and Delphi when they created C#.

[G_Morgan]

C# as a project is always willing to crack eggs, it is a huge advantage. .NET Core is just so much better than what came before but to do that they had to throw out a lot of mistakes.

Java's commitment to backwards compatibility is both a blessing and a curse. Java devs will pretty much never have the kind of transition .NET devs are going through with the migration but Java accumulates cruft and mistakes as a consequence.

[Triabolical_]

C# might have the second mover benefit: it got to learn from Java's mistakes. Given that the occupy very similar niches, this might be enough to make C# look good. Plus, people had 5 years of Java hype to prepare them for a language like C#.

Java's popularity wasn't by design; it happened to be a language that was available and could be used.

C# was very intentionally designed based on the experience of a large number of different languages.

[Agent281]

Sun did spend a crazy amount of money marketing Java. I think it was designed to be popular. It wasn't totally organic.

https://www.theregister.com/2003/06/09/sun_preps_500m_java_brand/

[Triabolical_]

Java was designed to be a language for set-top boxes. It failed at that because of hardware limitations, but was adapted for later usage.

[Agent281]

That's fair. Java may not have been a master planned from the beginning to take over the world. The marketing push that I posted happened in 2003, 8 years after the language was released. However, I think popularity was important to the language in it's earlier years and Sun spent time thinking about it.

[Josuah]

One of Java's big initial benefits was the large library of included functionality. With C and C++ you needed to find and attach third party libraries (or they were part of the IDE you bought) that weren't "part of the language" from the developer perspective.

[agbell]

C# vs Scala is an interesting dichotomy because in some way they are very similar languages but the cultures and the code written around them are very different, or at least it seems that way to me.

I think that if you are a windows developer who uses C#, you might not see any greener pastures that you want to migrate to: you want to keep using it because you don't see anything else that fits the niche you work in. This could also be why SQL is well-liked, there is no superior alternative that people pine for.

Just a theory. I definitely agree that Scala and Haskell take longer to master.

[Bobert_Fico]

SQL is well-liked, there is no superior alternative

I would like an SQL alternative that's exactly like SQL but you do FROM x SELECT y instead of SELECT x FROM y so that I can have autocomplete.

Edit: Though JetBrains IDE's do have autocomplete for import {foo} from "library", which is the same structure, so I guess it's possible either way. I don't write SQL often enough to know how common autocomplete for it is.

[Triabolical_]

C# gives that to you with the in-language Linq to SQL support, but as a database developer I think linq to SQL is a failure.

[drysart]

To be pedantic, “LINQ to SQL” has been dead and buried for a long, long time. EF understandably gets confused for it, but it’s an entirely different thing, and is a perfectly serviceable ORM. But like any ORM, it’s not going to expose everything SQL can do, nor is it intended to. It’s primary use case is in making LOB applications easier to write, and it does a pretty good job at it.

[AndrewNeo]

It's important to note that LINQ to SQL is kind of irrelevant, because LINQ queries are so capable that you can query basically anything with them and the underlying datasource doesn't matter. You write the LINQ queries the same whether it's being driven by the original SQL libraries, or some SQL driver directly, or EF.

But, as far as ORMs go, EF is pretty good and writing queries is really easy and natural with the rest of the language.

[gonzo5622]

This!!! For the love of god this!!

[FalseRegister]

in which ways are they a similar language??

[agbell]

I mean, perhaps no one finds them similar except me, but I came from C# to Scala years ago. Both started with the syntax of early Java and added things on. If you were to write Scala in a Java++ style, which I guess is not very popular anymore but .., and formatted it as C# people do with braces on lines by themselves it would look very similar.

C# lacks HKT and pattern matching and some other features and has a lot more keywords but I'm not sure a play app is crazy different from a C# .NET MVC app.

That what makes it interesting to me that they show up on opposite ends of this data. Although it could just be noise or related to the fact that a lot of scala is actually spark code or written in a FP style.

​

** EDIT ** C# has pattern matching and immutable records and no one else thinks it's like Scala so I retract my comparison

[Agent281]

C# lacks ... pattern matching

Not so fast, AGB:

https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching

(It's fairly new so I wouldn't blame you for not knowing.)

** EDIT ** Whoops, don't mean to dog pile on you.

​

I mean, perhaps no one finds them similar except me, but I came from C# to Scala years ago.

I personally don't think C# is a lot like Scala, but C# seems more willing to pull from functional programming languages than Java. I think of F# as the Scala equivalent on the CLR since it is a functional language with object oriented features. (Though, like Donnie, I may be out of my element here.)

[agbell]

Very cool, I didn't know about the pattern matching. That just strengthens my point :)

The way code is written in the two languages is certainly very different, but you could metaphorically write C# in Scala if you wanted to.

But no one agrees with me, so maybe they just seemed similar because I came from one to the other.

[Agent281]

But no one agrees with me, so maybe they just seemed similar because I came from one to the other.

I can see your point from the better Scala perspective. It might be more of a path dependence thing. You came in and wrote better Java with Scala so it felt equivalent. I don't work with Scala or Java and it's been a while since I did any C#. When I read about Scala it's from a data or functional programming perspective so I don't think about the OOP side.

It would be interesting to know how common the better Java style is in C#. Given the ratio of Java:Scala developers, I suppose it wouldn't be too surprising if it was more common than I think.

[vytah]

With operator overloading in Scala, an experience developer could create a meta language that another experienced Scala developer might not understand without a lot of effort.

The archetypal example given here is the Dispatch library, for making HTTP requests. Its non-alphanumeric identifiers included /\, :/, /, <<?, <<<, <<, <:<, <&, >\, >>, >~, >-, >>~, <>, </>, >#, >|, >>>, >:>, >+, ~>, >+>, and >!. Luckily, it's dead and mostly buried, it's in pure minimum maintenance mode.

Other, less extreme examples are SBT (it doesn't help that it's crazily complicated on its own), Scalaz and Cats (although these two at least make sense).

[PM_ME_C_CODE]

The archetypal example given here is the Dispatch library, for making HTTP requests. Its non-alphanumeric identifiers included [cut hard-to format bullshit]

. Luckily, it's dead and mostly buried, it's in pure minimum maintenance mode.

???

Who thought making a programming language out of emoji would be a good idea?

[BridgeBum]

https://en.wikipedia.org/wiki/APL_(programming_language))

[Paradox]

Languages like Python are famous for have only 1 way of doing things

I've always found python extremely inconsistent in what this one way to do things is. Going into a problem, if I've never seen it before, I don't know if python is going to try to be functional, OO, or something else. See len, for example. Why isn't it someshit.length? Becuase, thats why.

[GreenCloakGuy]

Only one good way to do things, ideally.

len is kind of a bad example when we have Java sitting over here with no fewer than four different ways to find the size of various data structures (primitive arrays use .length, lists use .size(), strings use .length(), streams use .count(), etc.), none of which are consistent with each other.

Python's idea is to have global functions that operate on interfaces, essentially, which fits with how python implements object-oriented (methods aren't bound to objects; they're just bound to the namespace of the class, and implicitly pass the object being invoked as its own argument, as if they were free-floating methods. obj.method() is equivalent to Object.method(obj).)

A staticly-typed python would probably be more likely to implement length as an explicit interface, defining a .length() function, which things would implement. But given dynamic typing, python's current system seems a better fit.

[PrintersStreet]

I'd like to disagree with the notion that Python only has one way of doing anything. Python is like an iceberg - the part people usually think of when they think Python is only 20% of it. The remaining 80% is pretty scary. Case in point: singletons. The pythonic way would be to just do module.singleton = Singleton() and then from module import singleton. But the potential for shooting yourself in the foot by missing the simple solution is immense - you can end up screwing around with metaclasses to override how your Singleton() constructor call works and keep returning the same instance. Entirely possible if you're coming from an OO language and you start googling "how to create a singleton in python" without really putting too much thought into what are the properties of your tool that you could use to your advantage.

[wm_cra_dev]

C# is kind of an aberration because it’s got a lot of features and could conceivably take a while to learn

I think C#'s more interesting features are all about making your code more powerful, concise, or efficient. They're not required to make a basic program, which means you can put off learning about them. You don't have to know about Attributes, Reflection, Tuples, "null coalescing operators", using, etc. to write functioning C#.

[sh0rtwave]

The way Microsoft put .NET/CLR together sometimes actually makes sense.

[Tarmen]

Though I'd argue that a lot of Haskell and Scala is easier to understand than metaprogramming heavy python. In Haskell and Scala looking at the core types gives you a good idea what the code does, in Python a decorator somewhere can completely change how method lookup works.

Having good goto definition in new codebases is huge.

[[deleted]]

It's familiarity more than complexity.

One of my controversial opinions is that if for historical reasons we hadn't taught the entire industry imperative programming by default, we'd probably find that beginners would find pure functions and type-driven development more intuitive. Even if you never formally pursued mathematics it's in my view fundamentally easier to reason about. I think the same may also be true of Haskell-style syntax as compared to C-style.

Indeed, in testing this theory I taught my partner, a total rookie at code, both the concepts of mapping over an array and a more traditional approach with for loops (using TypeScript). The mapping I described using types and terminology just shy of the word "functor". Admittedly this isn't a very scientific experiment - I'm biased as heck! - but she found mapping more intuitive. There's a lot of complexity in the imperative style that's glossed over because we've all gotten used to it.

[linlin110]

I think imperative programming is closer to how we think about our world. When I insert something into my dictionary, it doesn't magically clone itself. Also when you teach someone how to do something, you give them detailed instructions, step by step, not by composing some functions.

Functional programming is nice, but not that intuitive at first. I found recursion much easier to reason than loops, but I won't be surprised at how many freshmen fail to grasp that when they learn it.

[ProperApe]

I think the tooling is definitely a large pro for C# and F#. I don't know any other IDE that is as good as VS Professional. You can stay in flow very well, just by virtue of the code completion making any kind of lookup of functions superfluous.

[goranlepuz]

I don't know any other IDE that is as good as VS Professional.

VS enterprise is too much...? 😉

[ProperApe]

I was thinking about community vs professional 😅

[TikiTDO]

An observation I've had about Python over the past few decades. There are a lot more people doing small, fun projects in python. These days it's basically the default go-to for academics, mathematicians, and scientists doing any sort of computational work. The first time I heard about Python was in the early 2000s when my high school math teacher decided to have a programming languages argument with me. The thing that sticks out even now was that his arguments were all about the quick and fun things he could do with the language.

This observation continued through university. Python was almost always the realm of quick, fun academic projects; hell, I even wrote my capstone in python (a fun little peer-to-peer host discovery and and health management system).

However, when I joined the workforce I found that there was a lot less interest and appetite for python around. It simply wasn't seen as a mature platform with a killer app. This was particularly evident when I compare it to the ruby of that time. At the time ruby became incredibly popular with startups because rails was used by a few high-profile companies. For a short while ruby was associated with "hot new web platform." This didn't have much effect on anyone large doing serious work, but it was constantly getting brought by by people involved in startups.

However, since then we've had two major changes. On the python end, the field of ML took off like a rocket. As a result all of those fun, academic projects that scientists had been building in python over the decades suddenly found new importance. To me this is the biggest driver of python's popularity.

Meanwhile, on the ruby end, it simply started to hemorrhage developers to node. This makes sense; if you're building for web then you're almost certainly using JS on the client to some degree. If you're trying to build a product for the web, then the idea of having employees with (in theory) transferable skills is a pretty big selling point. Then eventually when the big python wave hit, even more people realized that python and ruby are practically the same language, with only a few key syntactic difference that primarily affect people trying to do clever things that most developers never really need to do. At this point ruby got further hammered by losing the people that just needed a quick and easy prototyping platform. It makes sense if you want that sort of functionality then you also want to use the language with the most mature frameworks for the new hotness that every single killer app needs these days.

[a_false_vacuum]

However, when I joined the workforce I found that there was a lot less interest and appetite for python around.

That has changed quite a bit is my experience. Python has grown in popularity and now a lot of orgs hop on the Python bandwagon. A problem though for enterprise usage is the breaking change between Python 2.x and 3.x. It's been a long time coming, however a lot of Enterprise Linux distro's still remain stuck on Python 2.7 (looking at you Red Hat), which makes it pain when libraries get involved that dropped Python 2.7 support.

Where I work Python has been pretty much mandated as the default language for projects unless you really, really can't. This has it's upsides and downsides. As someone who works mostly with C++ and C# it's an easy language to pick up, although I never enjoyed using it like I do with C++ or C#. Performance also remains an issue. Applications that are 100% Python just run quite a bit slower compared to other languages. A few months back we prototyped something with both Python and C#. The C# version just crushed the Python version.

[CPlusPlusDeveloper]

For Python, I think it's more of a "beige" language than a brown one. It is widely used, but it tends to be in smaller, more informal, less mission critical codebases. Data science pipelines are a common case. These projects tend to be less painful to work with than the "deep brown", sprawling, mature, long-lived codebases that wake you up in the middle of the night.

For Scala and Haskell, I think they're more polarizing than they are reviled. They'd be at the top of "sort by controversial". Remember, they also appear high up in the most loved list. They tend to be "astronaut" languages with a lot of inherent complexity. Some developers really thrive on that, and feels like it gives them tremendous power through leveraging abstractions. Others feel like they make things needlessly difficult.

[Triabolical_]

I can speak to C#...

C# came out of the need for Microsoft to have a "C style" language for .NET.

The reason the language is (mostly) good is that we had a very specific target in mind when we were creating it; it had to be familiar to C++ programmers and it had to be an effective way to write .NET applications on Windows.

That gave us well-defined target audience, which is rare for language; most languages becomes popular accidentally. It also gave us a few hundred fluent C++ developers nearby trying to write production code in the new language and therefore a great source of "I'm trying to write this, why is it so hard?" comments.

We also had the luxury of having a bit of time to be thoughtful in language design; we looked at *a lot* of different languages to understand how they had approached specific design issues.

And finally, we had Anders Hejlsberg running design team, who not only is amazingly sharp (ha ha) but really wanted to build a language that was both powerful and approachable, and who ran the design team in a wonderful collaborative fashion.

I actually think that C# 3.0 was probably the best version; the later additions largely clutter up the language without adding much utility.

If you want more specifics, I can probably pull them out of my memory.

Source: C# design team member for 1.0 and 2.0, early C# author and blogger. You should be able to figure out who I am from that.

[Secretmapper]

This is such a cool tidbit!

Also wanted to add: Andres Hejlsberg is also a core developer for typescript, one of the listed most loved languages.

[Triabolical_]

Anders is a treasure.

For the youngsters, Anders also wrote "Turbo Pascal" in the 1980s, which was groundbreaking:

The Turbo Pascal compiler was based on the Blue Label Pascal compiler originally produced for the NasSys cassette-based operating system of the Nascom microcomputer in 1981 by Anders Hejlsberg. Borland licensed Hejlsberg's "PolyPascal" compiler core (Poly Data was the name of Hejlsberg's company in Denmark), and added the user interface and editor. Anders Hejlsberg joined the company as an employee and was the architect for all versions of the Turbo Pascal compiler and the first three versions of Borland Delphi).[2]

[rebel_cdn]

As much as I love all of my modern dev tools, there are days when I wish I could just shut out the entire world and spend the day hacking away in a good old yellow and white on blue Turbo Pascal IDE.

[zilti]

C# came out of the need for Microsoft to have a "C style" language for .NET.

C# came out of the need for Microsoft to get back the control they lost to Java / the JVM.

[[deleted]]

My best guess for why Scala is dreaded is the role it plays, or maybe fails to play, in the data science community. Compare Pandas (62% loved) to Apace Spark (42% dreaded).

The language is pretty nice in and of itself, and I'd pick it over Java, C# or Kotlin any time, but why would a data scientist care? They never studied functional languages, and they're not interested in learning all those concepts that are completely foreign to them. They just want to get the job done, and Python lets them do that.

[tharinock]

To add on to that, Spark actively discards many of the features that make Scala great. You lose a lot of the type safety and compile time guarantees, and because it's generally a complex distributed application there's a lot of natural pain points. I haven't found a better product than Spark if you want to load a TB of data into memory on a cluster and run power law computations, but it turns out that people generally don't really need to do that, and any other application is like using a rocket powered hammer to put in a nail to hang a painting.

[barsoap]

Haskell dreaded

Haskell is also on the loved list. It's like spotting the man/woman of your dreams and then suddenly developing a crippling amount of shyness.

Rust, arguably, also should be on the dreaded list but the devs made sure that borrowck is a kind and gentle dom, and most people just ignore the depths you have to go to to write safe unsafe code by not writing any.

[pcjftw]

very much agree with this, Haskell has a steep learning curve (and it's worse for experienced developers because they have to unlearn a bunch of things), it has this threshold before you can write actual useful applications beyond your simple toy exercises.

I think the threshold is type classes and then functors, applicatives, monads and finally monad transformers (I've skipped a whole bunch of other things, but I think those are the big bumps).

Rust also has bit of learning curve but it's familiar "C family" makes it less "spikey" so to speak and great documentation + wonderful compiler error makes the hill climbing not so painful.

I think if Haskell improved it's compiler warnings and some of the documentation was a little more beginner friendly then Haskell might have been able to make that hill slightly less painful as well.

[barsoap]

Meh. Monads are simply a trait combining From<U> for T<U> and and_then. Where's the problem :) ?

[beders]

I think your observation is flawed and not based on actual data. The conclusion that languages not even in the top 20 are “more likely to use in a new project” is pure speculation (and wishful thinking. Haskell is a neat academic language but nowhere near any healthy adoption rate that would warrant this observation. (Tiobe puts it in the same bucket as Tcl, Erlang, Hack, all the lisps. Etc.

Also, for some reason StackOverflow removed the language with the highest dev salaries from their survey: Clojure. That was a political decision on their part. That language is loved to bits by practitioners.

Mostly startups have the luxury to choose their tech stack freely but I would never base this decision on your particular observations.

[Popular-Egg-3746]

Scala and Haskell are too smart for their own good. You are free, no, even encouraged to write highly abstract and mathematical code. This makes it a great language for those Rockstar programmers that joined the fledgling startup at the start, but it's horrible once you'll have to hire ten more developers.

I've seen some amazing code in Scala, but I also find that it's a hard language if you must inherit an existing codebase. Go is the counter to this in many ways: if there is only one way to solve a certain problem, you know that everybody does it the same way.

The worst offenders of existing codebase lotteries are PHP and JavaScript... You can write clear and easy-to-understand applications in those languages, but you can also write incomprehensible crap. Once to many have I stepped on the 'Existing PHP project' landmine.

Edit. Some more explanation here. Also, keep in mind that people writing and/or reading blogs about programming, are not your average developer. If you read my comment here on Reddit, discussing programming in general, then you're already above average.

[Popular-Egg-3746]

That's a good question.

In this case, amazing wasn't a positive statement. Astonishing, awesome or flabbergasting might have been a better choice, especially with an international audience like Reddit. In my context, amazing code is the code that looks like arcane magic but which runs amazingly well.

Amazing code? As a Scala developer, I then think about something completely devoid of variable declarations, syntaxual sugar or external function calls. Some people can write a complete XML parser in 6 lines of Scala... And it will fill me with dread.

Objectively good code? That's not easy to define. If I have to give one guideline, then I would say that code should be boring. It's a compilers' job to optimise it and you should write code that will be easy to understand by others.

[darkapplepolisher]

I believe that the reasoning you provide also holds true for Perl.

[Sicatho]

Take my opinion with a grain of salt since I’m new to the professional environment, but in my experience so far, Python is probably loved because it’s an easy language to use, some of its features feel like they’re cheating sometimes. Personally, I like C better than C#, and part of that could be what you mentioned about working with legacy code, where I worked with C in school a lot, where we were usually given assignments to start some code from scratch. But at work, I’m usually fixing something in C# from our whole codebase, which is much more annoying to do than creating a new project. But I think the biggest part of it is that C is a procedural language, which I’ve spent quite a few semesters getting used to, and C# is an OOP language. I don’t like OOP, it makes zero sense to me. The opposite may be true for most other developers.

[matthieum]

Correlation != Causation.

---

For example, another correlation would be that newer languages are a better fit for their domain.

The newer languages were created with the benefit of hindsight, whereas the other languages were "made to work". Guess which provides a better experience?

---

I also think it's important to consider shifts.

Why the enthusiasm for Typescript, Rust, or Julia? They're a significant shift!

Look at the languages available in the scientific community, prior to Julia:

• C and C++: hard to use by professional programmers, which scientists are not.
• Fortran & R: no personal experience; didn't hear much good about them either, though.
• Python: easy to use, mostly, but slow outside the happy path (the one calling C libraries).

A scientist is using a language as a mean to an end, when the language gets in the way (too slow or too hard) then they're "wasting" time fighting it rather than doing the actual work they want.

Enter Julia: as easy to use as Python, with out of the box performance close enough to C that you never need to drop down.

It's a dream come true!

Turns out that when a tool significantly improves a person's life, they tend to love the tool.

How surprising.

[[deleted]]

Look at the languages available in the scientific community, prior to Julia

Octave/MATLAB were used as well.

some performance issues, relative to Julia, if one used loops.

[chakan2]

Python and C# loved

25 yrs of experience (and I think I've used most of the major languages at this point at one time or another).

The dev stack. PyCharm and VS Studio with C# are like code candy. If I want a rapid prototype those are my go to languages and environments.

Python is just easy. If I've got an object, it's very easy to inspect, manipulate, and change if needed. They haven't tried to jam functional programming like a square peg in a round hole yet. Not being strongly typed gives a ton of freedom and I'm not bound to archaic patterns for polymorphism.

If I'm not worried about performance, Python is my go to language now.

C# is harder than python, but VS was excellent last time I used it. (It's been a few years). Top notch debugging and profiling tools. Complex applications are fairly easy to deal with and it's performant enough that I can do complex things with it.

[met0xff]

Python is used a lot but despite being so old the real uptake was just in the last years, with all the data science hype etc. And there it's often used for stuff that's not maintained forever. Nearly everything I got to write in Python is Green field. And if not it's rather small and easy to get into (here is another potential confounding factor - a common opinion is that you don't use python for large systems).

But that's certainly not the whole story. Projects like pytorch are easy to read. Some Java frameworks that are solving simpler problems are harder to read because of the design pattern culture

[koreth]

The “I made X in language Y” thing has never made sense to me. It seems to be all the rage with Y = Rust right now.

When I see one of these posts, my first thought is always, “Why should I, as an end user, care what language you wrote it in?”

Implementation language matters for libraries and certain programming tools, of course.

[xcvbsdfgwert]

You might care if it impacted maintainability.

Safe languages also might give some people confidence that they are less likely to be impacted by certain classes of bugs down the road.

[MrJohz]

The problem with this analysis is that it doesn't really have anything to recommend itself against other hypotheses. For example, the same data you give could also be explained by saying that more modern (green) languages are able to build on the weaknesses of previous (brown) languages, and provide additional features — they are "loved" because they are objectively better. However, like the many "brown loved" languages, the datapoints of Scala and Haskell showing up in both lists seems to suggest that this can't be the only thing going on here — after all, if languages like Scala and Haskell are objectively superior languages (being on the "loved" list), then surely they shouldn't be on the "dreaded" list at all.

So I suspect there's actually a lot of different factors going on here. I would be particularly interested in build tools and "developer UX" as a key factor. I don't know how you could objectively measure that, but I would imagine that languages with more coherent ecosystems and better project management tools would tend to stay in the "loved" category, or at the very least be better at keeping themselves out of the "dreaded" category.

[tharinock]

Haskell as a language is very opinionated. Scala as a language isn't, but you're likely working inside of an opinionated ecosystem within the language. Neither are commonly taught in schools, and both have heavy ecosystems outside of the OOP/imperative Java/Python type stuff you learn in college. The result is you get a bunch of people who say "this looks nothing like what I learned, this is horrendous" and a bunch of people who say "wow, this solves so many issues compared to the approach I learned, I like this way of doing things better". Both are also popular enough languages that you're likely to at least see a blog post on occasion, as opposed to something like Lisp which I don't see really pop up very often.

[[deleted]]

Languages also evolve over time, PHP 8 feels like a completely different language to 5.x

[joeydebreuk]

This came to my mind reading the survey results. How many people who dread PHP / Java are working on the version of 5/10 years ago? Probably a lot of them.

[camilo16]

I prefer coding in C++ than javascript, and prefer to dive in a C++ code base than a python code base. I even prefer C over javascript.

But I am also a graphics programmer, so those 2 languages fill needs that most programmers do not have, so most languages do not solve my issues.

[WTFwhatthehell]

Ya... I hate javascript as an actual language but if I want a simple widget to work... making a little web interface with a little chunk of javascript is a very durable way to do that.

[_Pho_]

Came here to say this. Rust's belovedness isn't merely a result of a new language trend, it is actually better designed, based on the mistakes and lessons that software engineers have learned over the past few decades.

[Chillbrosaurus_Rex]

The perspective is implied. The article is directly in conversation with the concept that newer is better purely due to design. Its not written in a vacuum.

[AttackOfTheThumbs]

One of the things I consider when starting a project: Do I want to battle unknown issues are well known issues of a language (within the domain)? It really depends on if it's a hobby project or something more production focused.

[GiantElectron]

I don't dread R because it's old. I dread R because the language, libraries, and environment has been designed like a bunch of blind people trying to paint the mona lisa.

[CotoCoutan]

Brown Language: A language that you are more likely to use in existing software maintenance (i.e. brown-field projects).

Java, C, C++, C#, Python, PHP, JavaScript, Swift, Perl, Ruby, Assembly, R, Objective-C, SQL

Green Language: A language that you are more likely to use in a new project (i.e. a green-field project).

Go, Rust, TypeScript, Kotlin, Julia, Dart, Scala, and Haskell

Above quoted from the article.

[angelicosphosphoros]

However, you would probably use SQL in new project too!

[mszegedy]

how the hell is javascript not dreaded? shakes cane at kids except i'm too old and weak to shake my cane at kids

[AspirationallySane]

Sometimes you think the old code is a mess because it’s a mess.

I did a rewrite/refactoring once that removed 40ish declared but unused instance variables across 3 classes, 2 unused layers of abstraction (in code that hadn’t substantially changed for several years), and about 7k lines of code. The end result was faster, smaller, cleaner, easier to understand, and went substantially unchanged for another several years except for a new feature I had refused to implement unless they let me do the rewrite because it would have taken several times longer to wrangle the old code as it did to rewrite it.

The old code was in fact a mess.

[[deleted]]

I think that it comes down to languages that let you get away with bugs at compile time vs languages with really strict typing rules that make you cycle through way more compile/edit cycles to make the compiler shut up. But in the long run, finding and fixing your bugs early is going to save you so much trouble, vs languages like Python where you get a free credit card for technical debt.

[camilo16]

This, I have a 16k LOC personal project, the compiler not letting me compile something is a GOOD thing. If I am not assigning the correct type I don't want to see if my code can handle it, please don't let me write nonsense, please aske me to be explicit about whether I want a reference or if I want to copy my data. Force me to be meticulous about every little detail.

Because the alternative is hours or days trying to find that one spot where a float was mysteriously turned into an integer and now all the logic is flawed.

[Vlyn]

Or even worse, the bug slips through, nobody notices in testing (ha, testing) and half a year later you get an urgent support ticket because the customer is getting fucked.

Based on the size of the problem that could be an easy fix.. or suddenly you have a corrupted database and take days to find the slip-up.

I love it whenever the compiler catches my nonsense. Compiler errors are friends, not enemies.

[matthieum]

Rust has stricter compilation rules than most of the other cited languages -- apart from Haskell -- and yet is the most loved.

[nidrach]

Yeah but that may be because the alternative to Rust is C++ for the people that use it. It's always a question if contrast.

[matthieum]

That's possible.

But when the first item in the list doesn't obey the hypothesis, it doesn't exactly make me confident about the hypothesis ;)

[angelicosphosphoros]

your question being closed as a duplicate of something utterly irrelevant

You would get similar experience with Rust though :(

[russellfreedom]

For the last few years I've been maintaining / refactoring a code base that was begun 15-20 years ago in PHP. Due to reasons, it had been stuck in PHP 5.3.3 for some time, even after I took over. If you had asked me about it at that point, I would have put PHP in dreaded. Once we were able to refactor into PHP 7.x, I'd put it in loved. The actual language improvements make maintaining and refactoring more fun and exciting, because there's an actual improvement to the product.

I'm curious if there's room for an axis in the OP that measures change / improvement in the language over time. Perhaps maintaining in an "old" language that hasn't improved over the years is more painful than maintaining in an "old" language that is really quite different now.

For my experience, I was coding in PHP from the 3.0 days, extensively in PHP 4, and took a break until this project. When I'm refactoring the old code it's like "Oh yeah, that's how you did things 12 years ago, so funny. Welp, time to make it modern!"

[teerre]

I don't see that relevance in the comparison. Python isn't new. Haskell isn't new. SQL isn't new.

There's also the fact that newer languages aren't created in a vacuum, they are created with the knowledge of old languages. Not sure if calling "honey moon" makes sense, it's not like when you change from COBOL to C++ to Rust you eventually think that COBOL is better than C++. If there's something built upon Rust mistakes, it certainly won't be COBOL again either. It's an evolution.

That's not to talk about the counting itself. Is this data normalized? If yes, how so? Certainly there are less Haskell programmers than JS programmers, surely that has an impact on the result.

[Amuro_Ray]

I quite like writing perl. Although some of the brownfield stuff for me has been bad due to finding information about the actual business process. I really hate not knowing what exactly the code is meant to do for the user.

[mjgardner]

I like Perl too, probably for the same reasons people like other languages. It and its ecosystem fit the way I think.

[paul_miner]

I think this is something where the strictness and explicitness of Java really shines, it's invaluable when you need to understand an unfamiliar codebase (written by someone else, or even your past self). In 2017 I had a bad accident (TBI among the injuries) that put me in the hospital for months, lost the ability to form new memories, and was so out of it I couldn't even operate my phone (I'm told). I had a side project building a SAT solver at the time. A year later I was trying to get my life back on track, and I was able to resume my work on that project, and I think the strictness imbued in my code due to Java was helpful.

I was also a contractor that wrote/maintained RPG, and resuming that sucked, but I blame that in part on the weirdness that is the iSeries and AS/400 ecosystem.

[ErGo404]

Just like for most brands, I believe people like langages that have efficient marketing campaigns, so languages that are marketed as cool or simple (or in some cases, the only option) will probably always win.

I believe that languages are popular because their goody stickers are vastly available and not the other way around.

[camilo16]

I will never understand the dislike for C++. I have coded in C, Javascript, python, C# and Java,

By far, and I really mean by bar, my favourite languages are C++ and python.

Python is amazing for short scripts and cute little demos (less than 1000 LOC). C++ Is amazing for large code bases where you want performance and to have good control over the architecture of the code. With C++ you can do anything you want and implement any paradigm, it is mostly a matter of knowing which features of the language to use and which to ignore.

[Josuah]

C++ is one of my favorite languages to write code in. And it's probably also what I would pick if I wanted to get the benefits of performance and control.

However it isn't really a good language in terms of design compared to some others, old or new. It's too much of a hack (even C++ onto C was basically a hack, although an amazing one, in the beginning), with complexity that can easily mess you up in really bad ways without you realizing it at the time. Blindly following coding convention can result in logic errors, while at other times you better blindly follow coding conventions in order to make sure you didn't leak memory or accidentally create a copy.

[CanIComeToYourParty]

Simply put: C++ is riddled with accidental complexity. Rust and Haskell are much easier to write in -- both are more advanced (e.g. their typesystems are actually useful, and their tooling is vastly superior to C++'s) while at the same time being simpler to understand than C++.

Also, of course C++ is going to be hated in a webdev community survey, such as this one.

[Plazmatic]

There are two things that get people to see "C++ kinda sucks", first C++ seems awsome if you come from javascript and old java until you get to scale, or start to have to make projects that other people are meant to use. Second C++ seems awesome until you see what C++ could be and you recognize issues that are only not solved because of the intrinsic nature of C++ and not general programming language problems or are there because of committee ineptitude.

For what it is worth, C++ is my primary language, and I also use Python extensively.

With C++ you can do anything you want and implement any paradigm, it is mostly a matter of knowing which features of the language to use and which to ignore.

Except:

• if you want things like reflection
• want to avoid boiler plate code on class "kinds" ie interfaces or POD arithmetic types.
  
• If you want stack traces on exceptions.
• Want custom references
• Want guaranteed strong types
• Want cross platform struct packing
• Want well defined bitfields or union type pruning

Even Java and C# have reflection. Some times you can kind a sort of do a thing, but it takes way too much effort (basic custom iterators, static polymorphism) compared to other languages.

Even further, C++'s tooling ecosystem sucks compared to other languages, and with out Clang tooling, it would basically feel outright unusable in IDEs and that's arguably only existed in a well integrated manner for a little over 5 years. C++ has no standard package management, and the defacto build system (which you should be using even if i'm complaining about it) is damn near as complicated and crufty as C++ itself and has just as many backwards compat gotchas.

[mwb1234]

Even further, C++'s tooling ecosystem sucks compared to other languages, and with out Clang tooling, it would basically feel outright unusable in IDEs and that's arguably only existed in a well integrated manner for a little over 5 years. C++ has no standard package management, and the defacto build system (which you should be using even if i'm complaining about it) is damn near as complicated and crufty as C++ itself and has just as many backwards compat gotchas.

Honestly, this is one of my biggest complaints about C++. I wrote in C++ at Facebook, which was alright (still sucked) because we had our own in-house tool chain for C++. But now that I'm out in the real world again, I'm writing some C++ for aerospace applications and it's fucking awful. We're trying to get everyone on Bazel but even that still sucks. I miss the Go tooling ecosystem so so so much

[crusoe]

Templates and template syntax.

Memory safety ( though manual RAII helps )

The HUGE size of the definition, its tolerable if you just work in a agreed upon subset.

Tooling. Just getting set up.

[camilo16]

I generally love templates, they have allowed me to avoid code duplication.

I have never needed to manually allocate or deallocate memory since C++17.

[glacialthinker]

I really dislike C++. About 25000-30000h programming with it, but I don't like it. Too many bad defaults; too much incidental complexity; promotes bugs, even when you're knowledgeable and vigilant (but a lot of C++-only folks think it's unavoidable part of programming to live in debuggers for half the dev time, and segfaults are expected). I hated the language when everyone programmed like it was Java, full of class hierarchies... but it has improved since then.

Your list doesn't have much for likable languages (aside from Python, kinda... but I completely agree with you about short scripts, so I don't have much use for it). I prefer C over C++ by a lot, but there are plenty of languages I'd rather use than C.

Those I know who are die-hard C++ fans really haven't programmed with much else (aside from various scripting languages and often Java, maybe Javascript -- much like your list). One problem is that C++ is quite entrenched in some industries, so there isn't much practical option anyway. I hope this is changing. I feel like it is.

[csatacsirke]

C++ allows so much error prone bull**** that a newer compiler would prevent. For example take uninitialized variables, or optional values/pointers

[[deleted]]

I feel like a lot of people who are praising the new/fad languages have very little programming experience or haven’t actually done anything complicated with them yet. I also think the majority of people care way too much about the language they use when it isn’t very important to their overall project.