Imagine what you could do with a smartphone if it were programmed entirely in assembly.
There is a reason (well actually there are many) that the vast majority of software development these days is done using more advanced languages.
Cross-platform support, which you might argue just falls under convenience, but if you're writing for a different CPU architecture, you've basically written 2 separate programs now and not one.
As opposed to one written in C, or a scripting language?
When you are coding every arithmetic operation by hand, it is trivial to detect e.g. integer overflows. And even produce the mathematically correct result for operations that temporarily overflow a 32/64 bit register.
(The exception is RISC-V, which seems designed exclusively as a target for C compilers and makes these operations more costly, thus guaranteeing that they won't be used even by compilers for safer languages)
Assemblers also won't remove any instruction you write because of reasoning about "undefined behavior". They won't change constant-time code into something that isn't.
There is a "soft limit" on the complexity of hand-written code, which encourages thinking more carefully about the design, and using data representations that are a good fit to both the problem and the machine.
Yes, all of that is more work, and requires specialized knowledge. But what I don't understand is why most programmers today think that is a bad thing?
Gotta love how when someone makes an wrapper around one feature of ffmpeg weighing over 100 MB, some say that's making great tools more accessible, and is saving the original dev so much time (and the gazillion people who will maintain it forever, because that's not the vanishingly small exception but the norm, The Thing That Must Be Planned For).
But when someone says the think making really tiny and bloat-free things by hand, and with 10x times the effort, the sky is falling, and people put more energy into denouncing what a human can achieve, vs. what modern compilers can do, than it would take to code the thing in brainfuck.
I think it's the corporate focus. Some people think doing something for money, and to multiply money, is intrinsically more "serious" than doing it for the love of it, or just for fun, and with no more of a goal in mind than skipping stones. And I think trauma plays a role, too: Someone mentions making a vanilla whatever (and it doesn't get more vanilla than assembly... it's the opposite of using a framework to be able to make 5 apps in 3 days), and people instantly come swarming to talk about the nightmare of inheriting that "code base".
I think it's a bad thing because I disagree with you that you'll write fewer bugs because you're coding everything by hand. In my experience how much manual work you need to do correlates 100% with how many bugs the software will have.
Hmm. maybe there's a bug in one of the lines of someone's code.
Guess I better get started investigating it. 'Cause once I'm done I've got to start porting it to RISC-V.
In general, writing something in assembly won’t be faster. Some expert can in certain cases come up with a better hot loop in asm, but for larger scopes we can’t be as diligent as a machine can be.
There isn't anything about assembly language that makes it inherently more effective or efficient than a high level language.
It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway.
I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.
Of course this all comes at a price: decreased programmer efficiency.
No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all.
They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize.
No stack frames if you don't need them. No memory accesses if you don't need them.
But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
If they don’t even solve the problem, then it is no competition.
One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
If you don't have to care about any of that you can save a lot of useless instructions.
And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
Humans are better at tiny hot loops. Not at all at anything larger than that.
And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.
You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.
At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug.
If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?
If I had millions of person-hours to RE all the apps I hate, I'd just write them in Rust or something.