3 ms·

Other than assembly language, all languages embody abstractions. I find understanding certain abstractions hard going because they don't mesh well with my view

Other than assembly language, all languages embody abstractions. I find understanding certain abstractions hard going because they don't mesh well with my view of the problem domain and my design for solution's implementation.

shrimp_emoji 4y ago
Yep. You think C is "low level", but it was once considered "high level", and the compiler does many things you don't want, and the standard's ambiguously-worded, and implementers have their own interpretations about the ambiguity, and also bugs in their compilers, and you eventually arrive at: "If you really want those instructions to happen in this function, without fear of magic, write them in assembly."
- raspasov 4y ago
  Then you realize that your CPU has hardware bugs, and you go design and manufacture your own CPU :).
  - taneq 4y ago
    “I don’t get much programming done these days, what with all the goat herding…”
    - Ygg2 4y ago
      You mean atom moving? I just move atoms until the program I desire is on the computer.
      - elcritch 4y ago
        Obligatory xkcd https://xkcd.com/378/ https://xkcd.com/378/
- flohofwoe 4y ago
  > but it was once considered "high level" C's position in the "low- vs high-level" hierarchy arguable hasn't changed much since it was created. There were already higher level languages in the 60's (e.g. languages which abstracted the underlying hardware much more than C, but those weren't useful for writing an operating system in).
  - kaba0 4y ago
    From what I have seen, there are two “contending” definitions for what is high-low level languages: one considers anything above assembly languages high-level, the other is less concrete, and would put for example managed languages into the high level category/towards that end of the spectrum, while C, Rust, C++ would be on the lower end, assembly even lower. I prefer the latter definition, as the former is, while objective, quite useless. The second definition could be expanded by a partial order between languages by “feature X can be emulated in it” with some caveats[1], and then we might even get Rust/C++ beat C for low-levelness, since C don’t have any way to force vectorization (compiler-specific intrinsics don’t count!). [1] since most languages employ FFI/linking, not even this definition is too specific — would probably have to write it as the “idiomatic language can emulate feature”
throwawaymaths 4y ago
This is silly. Assembly is an abstraction too. Do you think the CPU actually runs the code you give it? Of course not. There's microcode, register aliasing, speculative execution, etc. Even assembly itself has symbols and labels, which are themselves abstractions.
- deleted 4y ago
  [deleted]
- jacquesm 4y ago
  Did you really not understand the point the GP was trying to make or is this an attempt to be clever? Of course assembly is an abstraction, but it is the lowest level programming language that ordinary mortals can still write code in, which was the point the GP was making. Exactly nobody writes applications in microcode. Register aliasing and speculative execution have under normal circumstances no effect other than some performance which if the CPU just did as it was told by the assembly code (or actually, the machine code, the binary representation of the possibly optimized assembly) would still work exactly as advertised. You can also switch those off if they're features of the assembler, and if the CPU does them then you're going to have to live with it. If you really wanted to make the point that Assembly is an abstraction then macros would have probably been a better thing to mention.
  - chongli 4y ago
    If you’re trying to understand the behaviour of the computer then all of the layers of abstraction matter, right down to the logic gates. Spectre and Meltdown proved that software developers can’t just “trust the CPU to do the right thing.” Besides the issue of security, performance is also a thing. If you’re trying to squeeze every last cycle out of your program then you need to understand CPU cache hierarchies at the very least. That’s at a level far below assembly language, digging down into the physical layout of the machine.
    - jacquesm 4y ago
      I'm well aware of all of those levels. But they are not germane to the discussion about programming in general. They are important if you are doing some really specialist work (low latency, extreme performance, operating system design). But that wasn't the context at all.
tsimionescu 4y ago
Actually, x86 assembly also embodies plenty of abstractions. Not sure on ARM or RISC-V, but x86 assembly instructions are not executed the way you'd think by any modern processor. Essentially the processor reads a while bunch of instructions at once, splits each in the raw microinstructions, arranges them in a graph of dependencies, and then solves an optimization problem to find the best way to schedule nodes from that graph onto its internal execution pipelines. In real-world execution, you can't even tell what assembly instruction(s ) are the ones being executed at a partocular time - disparate parts of various instructions. Some instructions, like "mov ax, 0", don't even execute: they just serve to mark which the tens of real registers is now free to use for another symbolic register like bx.
- Brian_K_White 4y ago
  Scheduling and implementation are irrelevant to the complaint being made about high level languages. No matter what the cpu does internally to arrive at producing the requested output from the supplied instructions, it DOES produce exactly the reqested and expected output from the given instructions. What it does not do is for example maybe a + operator doesn't mean the same thing after some unknowable prior step changed the definition of +, or flatly not provide a means to manipulate some data in a way that a language author thought was crazy and no one could ever have a valid reason to do $thing like idk execute a string or something. Sure there are now optional settings and features you could consciously use, for example to enforce that data/exec seperation, but it doesn't just do it by it's own magic according to someone else's rules instead of your own code.

shrimp_emoji 4y ago

Yep. You think C is "low level", but it was once considered "high level", and the compiler does many things you don't want, and the standard's ambiguously-worded, and implementers have their own interpretations about the ambiguity, and also bugs in their compilers, and you eventually arrive at: "If you really want those instructions to happen in this function, without fear of magic, write them in assembly."

raspasov 4y ago
Then you realize that your CPU has hardware bugs, and you go design and manufacture your own CPU :).
- taneq 4y ago
  “I don’t get much programming done these days, what with all the goat herding…”
  - Ygg2 4y ago
    You mean atom moving? I just move atoms until the program I desire is on the computer.
    - elcritch 4y ago
      Obligatory xkcd https://xkcd.com/378/ https://xkcd.com/378/
flohofwoe 4y ago
> but it was once considered "high level" C's position in the "low- vs high-level" hierarchy arguable hasn't changed much since it was created. There were already higher level languages in the 60's (e.g. languages which abstracted the underlying hardware much more than C, but those weren't useful for writing an operating system in).
- kaba0 4y ago
  From what I have seen, there are two “contending” definitions for what is high-low level languages: one considers anything above assembly languages high-level, the other is less concrete, and would put for example managed languages into the high level category/towards that end of the spectrum, while C, Rust, C++ would be on the lower end, assembly even lower. I prefer the latter definition, as the former is, while objective, quite useless. The second definition could be expanded by a partial order between languages by “feature X can be emulated in it” with some caveats[1], and then we might even get Rust/C++ beat C for low-levelness, since C don’t have any way to force vectorization (compiler-specific intrinsics don’t count!). [1] since most languages employ FFI/linking, not even this definition is too specific — would probably have to write it as the “idiomatic language can emulate feature”

throwawaymaths 4y ago

This is silly. Assembly is an abstraction too. Do you think the CPU actually runs the code you give it? Of course not. There's microcode, register aliasing, speculative execution, etc. Even assembly itself has symbols and labels, which are themselves abstractions.

deleted 4y ago
[deleted]
jacquesm 4y ago
Did you really not understand the point the GP was trying to make or is this an attempt to be clever? Of course assembly is an abstraction, but it is the lowest level programming language that ordinary mortals can still write code in, which was the point the GP was making. Exactly nobody writes applications in microcode. Register aliasing and speculative execution have under normal circumstances no effect other than some performance which if the CPU just did as it was told by the assembly code (or actually, the machine code, the binary representation of the possibly optimized assembly) would still work exactly as advertised. You can also switch those off if they're features of the assembler, and if the CPU does them then you're going to have to live with it. If you really wanted to make the point that Assembly is an abstraction then macros would have probably been a better thing to mention.
- chongli 4y ago
  If you’re trying to understand the behaviour of the computer then all of the layers of abstraction matter, right down to the logic gates. Spectre and Meltdown proved that software developers can’t just “trust the CPU to do the right thing.” Besides the issue of security, performance is also a thing. If you’re trying to squeeze every last cycle out of your program then you need to understand CPU cache hierarchies at the very least. That’s at a level far below assembly language, digging down into the physical layout of the machine.
  - jacquesm 4y ago
    I'm well aware of all of those levels. But they are not germane to the discussion about programming in general. They are important if you are doing some really specialist work (low latency, extreme performance, operating system design). But that wasn't the context at all.

tsimionescu 4y ago

Actually, x86 assembly also embodies plenty of abstractions. Not sure on ARM or RISC-V, but x86 assembly instructions are not executed the way you'd think by any modern processor. Essentially the processor reads a while bunch of instructions at once, splits each in the raw microinstructions, arranges them in a graph of dependencies, and then solves an optimization problem to find the best way to schedule nodes from that graph onto its internal execution pipelines. In real-world execution, you can't even tell what assembly instruction(s ) are the ones being executed at a partocular time - disparate parts of various instructions. Some instructions, like "mov ax, 0", don't even execute: they just serve to mark which the tens of real registers is now free to use for another symbolic register like bx.

Brian_K_White 4y ago
Scheduling and implementation are irrelevant to the complaint being made about high level languages. No matter what the cpu does internally to arrive at producing the requested output from the supplied instructions, it DOES produce exactly the reqested and expected output from the given instructions. What it does not do is for example maybe a + operator doesn't mean the same thing after some unknowable prior step changed the definition of +, or flatly not provide a means to manipulate some data in a way that a language author thought was crazy and no one could ever have a valid reason to do $thing like idk execute a string or something. Sure there are now optional settings and features you could consciously use, for example to enforce that data/exec seperation, but it doesn't just do it by it's own magic according to someone else's rules instead of your own code.