1. 17
  1. 3

    Gonna open my mouth and remove all doubt… what’s the joke?

    1. 5

      I think this was just mistagged as satire and have corrected it. Though it’ll be pretty embarrassing if it also went over my head, what with taking my handle from x86 assembly.

      1. 1

        See the sibling. I’m all but certain it was intended as satire.

      2. 1

        Assembly programming didn’t stay in the 50s, it evolved along with high-level languages incorporating structural, functional, and objective-oriented programming elements. It plays well with modern APIs and DOMs

        I would be very surprised if this weren’t a joke.

        1. 2

          This could be tongue-in-cheek, but the bulk of the article looks serious.

          1. 2

            Judging by the rest of the site it is not a joke.

        2. 2

          Assembly programming is nowadays seen as niche at best. And more often than not as needlessly meticulous, demanding, and wasteful even for its niches.

          Assembly is hard. It is unfriendly. Programming in assembly language is slow and error-prone.

          Every word applies equally to C.

          p.s. I do 95% of my programming in assembly language (mostly RISC-V these days) or C. And most of the rest in Perl or sh.

          1. 1

            It really depends on what you mean by assembly language.

            Web assembly isn’t an assembly language in the traditional sense, the binary form is a byte code - same with .net IL.

            1. 1

              That was my first thought, too. Then again, you could argue that byte code is really just machine code for virtual machines. In that case wasm/ILAsm would probably fit the common definition of assembly as a low level language that provides a 1:1 mapping to a machine’s instruction set. By that definition however, modern day x86 assembly would fail the test[1][2].

              What’s really pusing it too far in my opinion though is the fourth example. Such a level of abstraction makes it nearly impossible to reason about the underlying architecture, which defeats the purpose of using assembly in the first place. By the same logic, you could call home-computer era BASIC dialects assembly, since you can infer the resulting machine code by looking at the interpreter implementation. It reminds me of my own history of learning programming, though. Assembly was the first language I learned properly (aside from a few brief excursions into Pascal in high school). As I progressed and started to get more comfortable with macros, I got a genious idea: How about creating a big library of macros that provides commonly needed functionality like printing text, mathy things, etc? Fortunately, before I got started on that project, I discovered that other people had already had the same idea, and had come up with this magic thing called C (among other things,of course).

              [1] https://www.youtube.com/watch?v=eunYrrcxXfw [2] https://xlogicx.net/index.html

              1. 1

                The mapping between assembly and machine code for x86 is not quite 1:1, but it’s close enough. Yes, you can try to choose encodings that are short, or don’t contain ROP gadgets; but the assembler does not make any major decisions on your behalf, and there is a 1:1 correspondence between instructions in assembly and instructions in machine code (one assembly instruction never gets turned into multiple machine code instructions, nor vice versa). There is never a major security, performance, or debuggability impact resulting from choices made by the assembler.

                Even for cases like arm for immediates, the choices made by the assembler are very simple and completely mechanical. (Though, by the time you get to something like the go assembler, you may have a point.)

                C is a completely different kettle of fish. Register allocation alone places it in a completely different category from assembly (even with macro libraries).

                Regarding .net and wasm, I don’t think there’s an argument there either. It would, of course, be possible to implement a .net or a wasm cpu. It would also be possible to make a hardware implementation of python—not bytecode, python source code—but I don’t think it would make sense to consider python machine code.

                We have to consider the intent behind these systems. x86 assembly was intended as a (fairly-)direct textual representation of x86 machine code. Python was intended as a high-level scripting language. And ‘.net assembly’ was intended as a (fairly-)direct textual representation of a bytecode implemented by a virtual machine.

              2. 1

                And what? x86 binary form is also quite literally a byte code. As are 6502 and z80 and VAX.

                There is no essential difference between bytecodes intended to be interpreted by a regular program and bytecodes intended to be interpreted by microcode.