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.
They are machine dependent.
X86, ARM, AVR, IBM360, PDP8, or what? Just saying 'assembly' is not all that interesting. Processor architecture(s) would be interesting to know.
"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?"
...More productivity down the drain.
A) Why don't you ask them and learn?
B) I politely disagree that they are automatically "far less productive". I am an embedded programmer and have only used tiny amounts of assembly over the last decade. However, if I had more tiny projects, and my bosses weren't akin to cats chasing flashlight spots to where I could stick with the same processor for more than a year, I'd consider it for sure. Why? Because I never seem to get to just "code and go" anymore. As an example, last week I had to reinstall my multi-gigabyte Eclipse IDE for the SECOND time this past year (this time due to a debugger corruption). In such IDEs, all the higher libraries (and their paths) need to be in place, and compiled too (which doesn't always go perfectly). Whereas my former officemate would open any text editor (his was Corel Word Perfect(!)) to write his assembly, then compile on the command line, then upload the binary.
I don't know how many hours I've spent learning and fixing IDEs. Then, a year to two later, the IDE changes again after the chip's OEM "upgraded" it!
There's more than one reason to want optimization. There's optimizing for speed in a full algorithm, in which case assembler isn't that important. But optimizing for speed in localized locations can be very important. Ie, the faster your interrupt handlers are the better I/O throughput you can get, or faster context switches, etc. If you're programming on a DSP for instance, you almost always want the best speed and that often means assembler or assembler wrapped inside of macros or special directives. There's also optimization for size, and occasionally assembler helps there as well to cram in as much as you can in the limited space.
And of course you need to *know* assembler even if you don't write it. It's how you decode core dumps, figure out what your code is doing, and lets you treat the machine as more than a black box (I've seen people with efficient algorithms that weren't so fast because they didn't understand what was fast or slow under the hood).
People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.
If you're writing intel code you'll probably see better speedup using c++17 parallel policies or some other parallelization framework, but sometimes it is necessary to optimize small segments of code. Premature optimization is the root of all evil and effective use of templates and metaprogramming can go a long way without much effort. Embedded devices should be treated to same way. Write a high level implementation in the highest level language available to you and hand optimize only when necessary.
I've compared c++ stl implementation of algorithms to c implementations and my c++ almost always runs faster with significantly less code. Small programs that calculate trivial results are always faster in low level languages, but real programs need complicated structures and its almost always infeasible to hand optimize those effectively.
If you do not know assembly, you cannot be a really good coder and you cannot even understand how common attacks on code work these days or why some things run much slower than others. That said, actually coding in assembly is something you only do when there are very good reasons to and mostly as assembly embedded in C.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There are also some pretty stupid limitations in C, for example, no access to the "carry" bit. Usually it does not matter, but if it does, embedding assembler is the way to deal with that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.