Programming-language popularity by GitHub pull requests
lemire.me
lemire.me
Meanwhile, the languages near the "bottom" are quite stable languages to work in (as well as a pleasure). They even /almost/ noticed it themselves when mentioning golang 2.0 coming out soon, but assumed that that would make it 'popular' again.
The author did narrow it down into what it mostly accurate represents though:
> Nevertheless, in my view, the number of pull requests is an important indicator of how much people are willing and capable of contributing to your software in the open source domain.
For that reason, I am consuming a very large salt crystal alongside this information.
Their metric is just to search for "$LANG programming" in various engines, then assign arbitrary weights depending on the search engine used. It doesn't really measure anything, and has already been gamed intentionally, since it's so simple.
Every metric is going to have its pitfalls, but at least this one seems to be measuring something that approaches reality.
If you replace “has already been” by “can be”, I think all of that applies to this, too.
According to that the top 3 are js, python and java, in some order. I think it’s a good Litmus-test to fail statistics that have a different top ranking (TIOBE being beyond useless, having listed Visual Basic as 6th some time ago?!)
That actually does not surprise me. It's considered a step up from (and often used with) Excel, which is also everywhere.
Also, the 3 lines of scripts it is used for is hardly a big amount. Excel is big, but when companies grow out of it they go for integration with “proper” applications instead.
Nix has been getting attention among my friends. I’m still in “wait and see”. The next big thing after TS won’t be an incremental improvement. It will solve big problems like:
- Too many ways to do things. (Remove ambiguity. Instead, make choices for me so others’ code is predictable. Apple approach. Does Swift do this?)
- Naming suffering from backwards compatibility. (For…in vs for…of etc.)
- AI integration?
PHP is losing to JS due to 7.0 or whatever. Scala surprised me!
Or did I miss something?
I guess, PR data shows you what needs to be updated frequently. Personally, I like getting code right and shipping it and never thinking about it again. But for "here's how to reproducibly install the newest possible version of foobarbaz" yeah, a lot of updates are going to be needed, simply because "the latest version of foobarbaz" is likely a moving target.
Very true, also public pull request are not friendly to dark matter enterprise software :)
Yes, this is generally true, so the workaround is to put your function in a class, and use an interface + dependency injection to mock what you need. Sometimes it's a hassle.
With `dynamic` and `DynamicObject`/`ExpandoObject` proxies (or even lower level System.Dynamic/System.Linq.Expression fun) you can mock anything you want to in C#.
Those tools go all the way back to the early days of Linq (and useful but somewhat broken DLR visions like IronPython). If you need to time travel even further back in the .NET stack, or if you are just allergic to/deathly afraid of the DLR as some people seem to be, System.Reflection.Emit has been there since day 1. It's awful to work with and even worse low-level experience than the DLR, but it is capable of a lot of things. If you've got an up-to-date compiler you can go the other direction and use the recent Source Generators to do all the same low-level things but this time in the context of Roslyn and at build/compile-time.
Obviously, that doesn't necessarily make it a good idea that just because you can do such things that you should do such things, but C# has far more powerful raw tools at its disposal than many people realize.
A lot of the boilerplate in DDD styles is simply a preference for it and (over-)design patterns as comfort food.
It's a further aside, but hand-written "Fakes" patterns require more up-front work but often seem to me much better than automated Mocks. I've never seen a good DDD pattern focus on good "Fakes", though, and sometimes I find DDD complexity gets in the way of good "Fakes".
There are obviously good reasons auto-mocking frameworks became popular as it can be too easy to fall into performance traps or to try to maintain two separate dependency stacks (and get dangerously close to all of your units tests as just baroquely complex integration tests), one of which may easily get out of date/diverge and is extremely fragile, especially if you don't have good abstractions up front. It's too easy for how easy you can build your "fake" data sources to accidentally create a lower common denominator of what you can safely test, either limiting the types of queries that you feel like you can add to production code (forcing you to avoid things that your production DB supports, but an SQLite or In Memory storage can't easily fake) or create growing missing coverage boundaries between "testable" and "production" code.
On the flip side though, the benefits of hand-written fakes should be that you better prove out your abstractions and how they are factored (if it is too hard to manually fake a dependency, then maybe that becomes a sign that the dependency needs to be refactored and/or a better abstraction found for it), and the tests overall more resemble your production code and how it operates in the wild. (Versus how I feel excessively mocked code starts to resemble "stage plays" that don't necessarily approach or model real world usage and behavior and it often remains too easy to "stage play" even when your abstractions are wrong/not helping you enough.)
The piece of code in question had a very straightforward task: look at some bytes in the input and produce a string label to be stored alongside the whole input value. There are 5 different labels tied to equal number of fixed byte sequences.
I would like to think that most people would solve this problem using an if/else or a switch statement inside a function. Instead, what we got is a group of matcher classes, a mapping of matchers to enum values representing the labels, another mapping of enum values to actual strings, and a class that actually calls those matchers and does the mapping.
I really hope this is not the DDD way and instead we just managed to find a team that's prone to massively overcomplicate solutions to simple problems.
1: https://www.reddit.com/r/csharp/comments/qomcps/comment/hjo1...
IMHO, there is a huge misconception regards C# regards their OOP enforcement. Most classes you ever write for business logic in C# are nothing more than namespaces/grouping containers. And that is for good. There are so little business logic object hierarchies (aka the Pattern world or OOP fantasy world). The other reason to write classes are object to transfer data (no logic). There are the sinful years of DTOs (which are an OOP abomination) but that is obsolete for some years already in favor of records.
Exactly - if you included my organization's private scope alone (an org of ~10 people), there would be 90 additional repositories and ~1.5k PRs/yr worth of C# action available to pad the stats.
This, to me, is a lesson worth hearing: sometimes the feature you think is most important, the ones your customers are saying are most important, is not, and is not even close. The biggest software problem after PARC solved GUIs was distribution. The browser won 80% of apps out of the gate, but when the rest of the way with XHR.
It's really a startling turn of events when you think about it.
Java is much better in that regard.
Is Go 2.0 imminent? Any sources and details of this?
I think this is great for stability, and as a result Go looks to be avoiding the Python 2 to 3 ten-year-migration.
According to the graph here: https://madnight.github.io/githut/
Unfortunately, I don't have enough BigQuery Credits ($) to re-run the bot filter for the entire history, that's why you see the down spike.
(just kidding)
JavaScript has warts, but if you drink enough, you can pretend it's Scheme. Python isn't a language but a family of languages. Guido thought it was a good idea to change the semantics AND syntax between minor revs, so... no... having to re-code my apps every two years is a deal-killer for me. Sadly, the same applies to rust. I'm not the biggest fan of C++, but a friend pointed out some of the more recent language additions make it a much better language. And they added them without removing reverse compatibility. Or at least to a greater degree than python and rust.
Also, if you're picking a language to use based mostly on a popularity contest, you get what you deserve. Start with understanding what your needs are, then pick a language that allows you to model your computational requirements in a way that meets those needs. Maybe after that look at associated tools and libraries (I'm mostly concerned with debuggers since I usually debug things with a debugger rather than print statements). Then maybe think about popularity, you probably do want to be able to hire people, but it always seemed to me to be a premature optimization to say "oh. Java is real popular, so we're going to use Java 'cause we can hire people who claim to know it."
But there are some niche financial engineering teams I know who are very happy with using niche OCaml derivatives. They're completely okay with hiring people with Lisp or Scheme or "popular" ML derivative experience and then giving them a couple months to learn what's going on locally.
And heck, I've been on projects where we used COBOL and it was exactly the right language for that job. Was thinking about this the other day... I sort of miss Pascal and Delphi. meh. Life moves on.
Certainly you're not claiming Python hasn't made breaking changes in the syntax or semantics over the years?
I mean... this still compiles with my c compiler:
??=include <stdio.h>
int main( argc, argv )
int argc;
char *argv[];
??<
printf( "hello %d %s\n", argc, argv[0] );
??>
I read that as Java and Scala both are second tier languages. After looking at the graph I realized he was lumping the two together. They are 11.3% and 1.7% respectively.
If Scala were a "better Java" that grouping would make sense. But some Scala projects are so different in the paradigm that the slight interoperability between the two languages is completely irrelevant.
I'm not a big fan of Python's jumble of competing build tools but personally, I stick to venv + pip and it generally works out. However, having dealt with both maven and npm, the headaches with npm's build process are so annoying, its not even funny. Comparatively maven is rock-solid even if you may not like its xml-based configuration.
See also: https://octoverse.github.com/2022/top-programming-languages (which we publish annually and has a few related stats)
As a side note, I'm pretty shocked that the OSS community is "just fine" with leaving their projects on github after MS took over and scanned all their code for machine learning.
Another thing, it seems like Python developers might be apt to push/pull more often, in smaller commits compared to say, Java programmers.
Java is everywhere in any enterprise that does internal software development. The quality of that code is another discussion. You will also be likely working on very legacy code bases that are in the process of finally moving from Java 8 to Java 11.
I've seen places where you would never find a Go job and Java is nearly 80% of software jobs... but OTOH if you're working on stuff related to cloud tooling, Go is very dominant and you will almost never see Java.
Poke around this site for some info about Hoon and Urbit: https://developers.urbit.org/