The argument about which programming language reigns supreme is about to get a lot more clear with the release of research on the best and worst languages for dev workflow.
In this episode of LinearB Labs, CTO Yishai Beeri reveals what the company’s data scientists have discovered about programming-language productivity following analysis of thousands of dev teams and hundreds of thousands of pull requests.
Industry-changing research on which programming languages linger under excessively long shipping lifespans and which ones are impressively efficient, this pod should help settle debates that have been entirely subjective up to this point.
If your programming language of choice ends up on the wrong side of the spectrum, don’t fret. Yishai and team also came up with recommendations to overcome the hurdles and bottlenecks for languages that require better workflow.
Episode Highlights Include:
- (2:18) Where did this research come from?
- (10:30) Measuring dev workflow for programming languages
- (13:39) Which languages have the longest PR lifespans?
- (18:06) Programming languages with the highest workflow efficiency
- (20:46) Biggest surprises in the data
- (26:56) What can teams do to bring down PR size?
- (31:33) Comparing different programming languages in terms of real use
While you’re here, check out this video from our YouTube channel, and be sure to like and subscribe when you do!
You’re invited to Interact on October 25th!
Want to know how engineers at Slack and Stripe connect their dev teams’ work to the business bottom line? Or how team leads at Shopify and CircleCI keep elite cycle time while minimizing dev burnout and maximizing retention?
These are just two of the topics we’ll tackle at Interact on October 25th.
A free, virtual, community-driven engineering leadership conference, Interact is a one-day event featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.
Register now!
Top comments (16)
I'm not shocked/surprised to hear that reviewing C++ PR's is problematic. Starting with C++ 2011, the language started devolving rapidly into symbol soup. The C++ 2014 draft that became C++ 2017 is even worse. When you throw Boost into the mix, it gets exceptionally bad. When I write C++ these days, I avoid all of the modern hot garbage that was added to the language and stick to a hybrid classic C and C++ mix. C was also apparently on the high end and that is most likely because C sits barely above the assembly language level. It tends to takes a lot more code to accomplish anything significant in C, but well-designed C (and C++) will generally outperform other languages by factors of up to hundreds and even thousands of times faster. C/C++ vs. most other popular languages: The tradeoff is performance vs. the time to write and maintain the code. Unlike most languages, C/C++ is traditionally used to target embedded systems.
Symbol soup makes languages unreadable and therefore significantly less maintainable. Generally, the more symbol-heavy a language tends to be, the longer it will take to accomplish anything useful in that language and reviewing code changes will therefore take longer. C++ and, to a lesser degree, C have symbol soup issues.
I'm going to guess that the reason Java and C# are at the other end of the spectrum is because of the toolchains that those developers tend to use (IntelliJ and Visual Studio). Visual Studio has the best debugging toolset hands down. So despite being massive system resource hogs, devs may be more efficient in those IDEs when doing regular code merging. There are a ton of IDEs and editors for C/C++ so the ecosystem there is quite large and everyone writing C/C++ has their preferences, but basically two editors/debuggers for Java (IntelliJ and Eclipse) and just one for C# (Visual Studio). Debugging C/C++ anywhere other than Windows + Visual Studio is generally a nightmare in my experience (sorry, gdb, but you ain't cutting it). Even on Windows though, debugging C/C++ from crash dumps has always been a nightmare and only ever provides rudimentary hints as to what went wrong in the code. No one's ever really figured out how to solve that issue. Just trying to explain why Java and C# are likely doing so well here in this analysis.
PHP did well because PHP is a great language for prototyping ideas. There's no code to compile (unlike C/C++), it generally outperforms Python/Ruby/NodeJS/etc. by a factor of 2-3 times (but still hundreds of times slower than C/C++ which is the price that is paid for using interpreted languages), is memory efficient (unlike NodeJS), PHP has a very C-like set of functions, it runs on the command-line (most people think PHP is only for web servers), and is cross-platform and also a first-class citizen on Microsoft Windows (unlike Python, Ruby, NodeJS, etc. where Windows support is a clear afterthought). So for someone like me who writes C/C++, does most of my work on the command-line, and runs Windows as my primary desktop OS, PHP is an incredibly natural fit for day-to-day, high performance command-line scripting tasks. PHP is also constantly evolving with their newer stuff always being optional rather than being forcefully shoved down everyone's throat. So I just cherry-pick the stuff and use those things that I like (e.g. PHP classes) and then proceed to avoid the rest like the plague that it is (e.g. PHP namespaces, autoloaders, Composer, etc). I also occasionally develop new extensions for PHP in C. I'm not surprised to hear PHP was on the lower end of the spectrum as PHP itself provides some solid debugging tools (e.g.
var_dump()) but there are plenty of custom options, including XDebug that integrates with plugins for various text editors/IDEs.Javascript probably does better than Python in this analysis because web browsers have Developer Tools where code can be debugged and even make temporary changes inside the web browser itself. I've written plenty of HTML, CSS, and Javascript inside my web browser and then copy-pasted from the browser/Developer Tools into my local files for whatever project I'm working on. Again, this all seems to be leaning toward the tools that developers in a language will tend to be using. Better editing/debugging tools again seems to equate to less time spent reviewing code in PRs.
In conclusion, this all seems to be less about the language (unless the language has devolved into symbol soup like C++ has) and seems to be more about what tools are being used by developers that are writing and maintaining code in those languages. When factoring in the tools that devs are using, the results make sense.
Change is fine as long as it doesn't devolve a language into unreadable symbol soup. The adoption of STL into C++, a non-performant library, was the start of that downhill spiral.
PHP is excellent for CLI scripting.
Not ego but experience.
I'm going to continue developing software as I see fit. I'm well respected among my peers. Let's keep Dev upbeat. Thanks!
Attempting to attack a person's character is not a good way to start a positive discussion:
That's a structured personal attack on someone else. Your other replies came across to me as being similar in nature. This is Dev and I try (but don't always succeed - hey, I'm human too) to stay away from obviously problematic comments like that. Again, I have no ill will toward you and everyone's different, so no harm done.
At no point in this discussion, including my original post, have I attempted to attack anyone nor their language preference (if such is construed, I apologize) nor expressly said that developing software in C or C++ is bad/terrible but rather focused entirely on providing an analysis of why PRs likely take longer in some languages - aka providing possible context to various points brought up in the podcast. I believe that there's nothing wrong with any language that anyone chooses to use as long as it gets the job done. Obviously, lots of things get done every day in every single compiled and scripting language ever made and, when near-the-metal performance matters, system languages like C and C++ are ideal.
I just said what I do and was trying to provide a possible context to others who might read the post to maybe better understand the results from the podcast. The podcast authors seemed surprised at some of the results, but to me the results made sense and I was sharing why. I may have come on perhaps a bit strongly in spots (saying "modern hot garbage" WAS excessive) that obviously riled you up (sorry about that!) but I was writing my commentary as I listened to the podcast and I do have opinions. If everyone kept their opinions and insights and ideas to themselves, healthy debates would never happen and nothing would ever get done. I'm glad people have opinions/ideas and even constructive criticism. That's how we progress and learn together as a society. If there's anything I need to change about myself, it is that I probably should avoid phrases like "modern hot garbage" that will elicit a negative reaction. A better initial response would have been, "Using the phrase 'modern hot garbage' seems a bit excessive to me and some people might feel personally attacked/offended. I'd love to hear why you said that. Perhaps I can provide some answers to any issues you have with the C++ language." I think that would have saved a whole lot of back and forth.
I do think keywords vs. symbols should be a concern when designing a language. Finding a good balance between keywords vs. symbols has always been tricky. Keywords are, for the most part, searchable on search engines while symbols generally are not. Symbols, on the other hand, take less time to type in, occupy fewer bytes, and are easier for parsers to process for syntax correctness. Some languages are very keyword heavy (e.g. COBOL) while others are very symbol heavy (e.g. APL). People today write code in both of those languages. Are those languages terrible/bad? If it gets the job done, no one should care. The only downside is that PRs might take a bit longer to resolve in languages that live closer to either end of the spectrum. That's just good information to know up front but shouldn't stop anyone from using any given language and that was my main personal takeaway from this podcast.
For more info from our data team, check out LinearB's Engineering Benchmark research and compare your team's metrics to industry standards here: linearb.io/engineering-benchmarks/
They are one of the most reputable companies in the academic writing service industry. Their mission is to assist students in achieving academic success by providing do my dissertation them with custom research papers written by qualified writers. They recognise the significance of this for students because they understand how difficult it can be to complete tasks like this on your own.
Really informative podcast! Thanks for sharing
Why did you say so please. As far as i am concerned PHP is an awesome language with an awesome community
Interesting findings. I hope your data team makes this available to the public.
great post