汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
我“过去”写了很多汇编程序，我可以向你保证，当我用高级语言写程序时，我的效率要高得多。
其他回答
C语言优于一个好的宏汇编器的地方是C语言类型检查。循环结构。自动栈管理。(几乎)自动变量管理。动态内存技术在汇编是一个巨大的痛苦在屁股。与C或更好的foo.insert()列表相比，正确地执行链表是非常可怕的。还有调试——嗯，谁更容易调试谁也不存在争议。他们在那儿轻而易举就赢了。
我几乎一半的职业生涯都是用汇编程序编写的，这让我很容易用汇编程序思考。它帮助我了解C编译器在做什么，这再次帮助我编写C编译器可以有效处理的代码。用C编写的一个经过深思熟虑的例程可以在汇编程序中输出你想要的东西——而且它是可移植的!由于跨平台的原因，我已经不得不将一些旧的asm例程重写回C，这并不有趣。
不，我将坚持使用C，并处理与使用HLL获得的生产时间相比偶尔出现的轻微性能放缓。
$$$
一家公司雇佣一名开发人员来帮助将代码转化为$$$。越快地生成有用的代码，公司就能越快地将代码转化为利润。
高级语言通常更擅长生成大量有用的代码。这并不是说集会没有它的位置，因为在有些时候和地方，没有别的方法可以。
因为事情总是这样:时间流逝，美好的东西也会消逝:(
但是当你编写asm代码时，这与编写高级语言的感觉完全不同，尽管你知道它的效率要低得多。这就像你是一个画家:你可以自由地画任何你喜欢的东西，完全没有限制(嗯，只有CPU的功能)……这就是我喜欢它的原因。很遗憾这种语言消失了。但只要有人还记得它并对它进行编码，它就永远不会消亡!
早期的发现之一(你可以在布鲁克斯的《神秘的人月》中找到，这是20世纪60年代的经验)是，人们使用一种语言的效率或多或少与使用另一种语言的效率一样高，每天调试的代码行数也差不多。显然，这并不是普遍的事实，如果做得太过分，可能会崩溃，但对于Brooks时代的高级语言来说，这是普遍的事实。
因此，提高工作效率的最快方法是使用一行代码就能做更多工作的语言，这确实有效，至少对于像FORTRAN和COBOL这样复杂的语言，或者给出一个更现代的例子C。
除了其他人对可读性、可维护性、更短的代码从而更少的错误和更简单的回答之外，我还将添加一个额外的原因:
程序的速度。
Yes, in assembly you can hand tune your code to make use of every last cycle and make it as fast as is physically possible. However who has the time? If you write a not-completely-stupid C program, the compiler will do a really good job of optimizing for you. Probably making at least 95% of the optimizations you'd do by hand, without you having to worry about keeping track of any of it. There's definitely a 90/10 kind of rule here, where that last 5% of optimizations will end up taking up 95% of your time. So why bother?
