Slashdot Mirror
TIOBE's Language-Popularity Index Sees A New Top 10 Language: Assembly (tiobe.com)
TIOBE's "Programming Community Index" measures the popularity of languages by the number of skilled engineers, courses, and third-party vendors. Their July report indicates that Assembly has become one of the 10 most popular languages:
It might come as surprise that the lowest level programming language that exists has re-entered the TIOBE index top 10. Why would anyone write code at such a low level, being far less productive if compared to using any other programming language and being vulnerable to all kinds of programming mistakes? The only reasonable explanation for this is that the number of very small devices that are only able to run assembly code is increasing. Even your toothbrush or coffee machine are running assembly code nowadays. Another reason for adoption is performance. If performance is key, nobody can beat assembly code.
The report also noted that CFML (ColdFusion) jumped from #102 to #66, Maple from #94 to #74, and Tcl from #65 to #48. But Java still remains the #1 most-popular language, with C and C++ still holding the #2 and #3 positions. Over the last five years, C# and Python have risen into the #4 and #5 spots (made possible by PHP's drop to the #6 position) while JavaScript now holds the #7 position (up from #9 in 2011). Visual Basic .NET came in at #8, and Perl at #9.
The report also noted that CFML (ColdFusion) jumped from #102 to #66, Maple from #94 to #74, and Tcl from #65 to #48. But Java still remains the #1 most-popular language, with C and C++ still holding the #2 and #3 positions. Over the last five years, C# and Python have risen into the #4 and #5 spots (made possible by PHP's drop to the #6 position) while JavaScript now holds the #7 position (up from #9 in 2011). Visual Basic .NET came in at #8, and Perl at #9.
There are good reasons to work in assembly, particularly in systems programming. Or if you don't want to pay licensing fees for an OS, you may need to implement functions in assembly that are not possible in a high level language like C (manipulating machine state registers, implementing barriers, etc.).
I have been using assembly for various architectures for my entire career and most of my teenage life, I don't see any reason why it would ever go away. Mostly the number of people doing high level development has increased so radically that it honestly surprises me that it makes #10. Optimization for performance is definitely not a reason I'd expect to see asm hit #10 - most companies don't spend enough time on their applications to get to the point where they can optimize intelligently, and writing something in assembly is not always or a performance enhancer.
Then I assume you're paying a third party to supply libraries for you, operating systems, startup code, BSPs, etc. Which means those third parties are using the assembler even if you aren't. I do embedded for a living, and I have to do assembler - not everyone working on the software does but some people do.
As a contractor, I have seen a large number of projects where the client wanted optimizations done for both space and performance so they could try to squeeze one more feature into an already barely capable processor. In all but one of those cases, it turned out to be more cost efficient to replace the microcontroller with a more modern one. In about a third of the cases, my solutions actually *reduced* unit cost because the client had been paying a higher per unit price for their uCs than what is currently available for much more powerful options. The most extreme example was stripping an old Freescale processor out of a product and replacing it with a modern cypress PSOC. The old processor cost $11.03 per unit, and the PSOC cost $1.57. The per unit savings paid for my contract cost in less that 2 years (including the new features they wanted). It almost never makes sense to resort to assembly unless there is a reasonable expectation of selling millions of units per year, and even then, it'll be close because powerful uCs have become so damn cheap lately. I can do it if thats what the customer really wants, but my job is to maximize the customers return on their investment in my time. I do very well because my customers get what they really want, not necessarily what they initially come to me asking for.
If you're out of compute power, your best bet is to look into getting a faster uC, or getting a PSOC, where you can offload a significant portion of your compute expense into programmable hardware.
I wish I had a good sig, but all the good ones are copyrighted
There are a lot of processors out there that aren't complicated. On an 8 bit microcontroller with an instruction set size of only a few dozen, it's not hard to beat compiled code.
Play Command HQ online
Counter-intuitive as it may seem at first, the smaller your instruction set, the higher the chance that the compiler is actually better at optimizing than you are, unless you have a LOT of experience writing and optimizing assembler code. Mostly because the smaller the set, the longer the code gets and the more you have to take into account certain side effects from instructions. I spent quite a few hours puzzling why the compiler would completely rearrange the instructions only to notice that it gained a bit of an advantage from creative pipeline restructuring and carefully manipulating certain jumps.
The only area where humans outperform compilers reliably is conditional jumps. Because humans can usually more readily tell from the intended program flow which branch is more likely to be executed and can optimize the programs in that way. Hand that information to the compiler and I hold any bet that it will outperform you any day.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors
You are using all the same arguments C/C++ programmers used in 1995 but if the discussions wasnt about assembly language but instead the discussion was a comparison of compilers from 1995 with compilers from 2015 you would be telling us how terrible those 1995 compilers were at optimization even then.
..and if you are "confounded" by caches, pipelines, superscaler techniques, and so on ("cause surprise or confusion in (someone), especially by acting against their expectations.") then its because you are ignorant of the architecture. Your ignorance doesnt define reality.
..and notice how its now 10% faster... or 20% faster... there is a range because it depends which gcc compiler version is used (older versions produce better code.) If gcc has such a large variance in performance, if newer versions are slower, then what are we to think of the veracity of your claims? I'll tell you what: they arent veracious claims. They are wishful thinking.
The fact is that it doesnt require an expert to beat a compiler at optimization. The fact is that your idea of an "average assembly language programmer" is actually a terrible assembly language programmer. When you dont consider someone that learned C/C++ a month ago an average C/C++ programmer, why do you then consider someone thats literally never actually taken assembly serious as the benchmark average?
Recently a programmer undertook the task of converting the strongest open source chess engine (stockfish) to 80x86 assembly language. He still has done no optimization. He has literally just done a straight simple conversion and its already 10%...20% faster and is now easily beating the C++ compiler version in tournaments.
"His name was James Damore."
The smallest device I have written code for is a PIC with 512 bytes of RAM and 256 bytes of ROM. It had a C compiler. It is also lacking in connectivity for making trendy IoT devices. So what are all these devices that can only run assembly code?
I think a more likely explanation is that fad languages come and go, and now that globalization has driven the value out of programming, and kids are leaving the industry, they are mostly going, leaving only the languages that have stood the test of time behind.
Perhaps THOBE is mistaking the fact the NASA put up the full assembly code for the Apollo 11 guidance computer on Github and the interest in that (6000+ stars) for a revival of the language instead of a historical artefact.
Check it out here and don't forget to start it, together we can confuse THOBE and make Assembly the #1 language of the world again! ;-)
https://github.com/chrislgarry...
First of all, many, if not most, computers run software so trivial on microcomputers so small, installing a compiler for them would just be _way_ more effort than to just code to program in C. Typical examples are the microcontrollers in electric toothbrushes or other smaller embedded systems. It's hard to get your software running on a 4 bit microcontroller as modern C makes assumptions like having your memory addressible at a byte level.
Then there is another, in my opinion more important, point. Assembler is a great teaching aid. It shows you what the computer actually does. Understanding things like pointers is trivial in Assembler so you can learn a lot from it. Also in Assembler every control structure hurts, as you need to keep track of it yourself. This nudges you towards writing simpler code, away from thousands of nested if statements and functions with hundreds of lines. Those are desirable traits in all programming languages.
No language is suitable for everything, but most languages have at least one are where they are really useful.