6 ms·

Of course it isn't, but what's the alternative?

by usrnm 3y ago

lproven 3y ago
My favourite article about C in years. To answer your question off the top of my head, answering different bits of the issue, from the perspective of the era of active programming language R&D not themes on themes on themes as we have now... Limbo, Occam (Occam-pi, etc.), APL (I/J, Aplus, etc.), Oberon (Oberon 2, Oberon 07, Active Oberon, Zennon)...
- usrnm 3y ago
  I'm not familiar with these languages, but which of them is closer to the actual modern hardware than C, while still being abstract enough to be portable?
  - lproven 3y ago
    In what way did I imply that any of them were in any way closer? That was not my intention at all. You asked what alternatives there were. C is a systems implementation language, designed to be compiled to object code that will run on the bare metal. I offered some examples of alternatives to that role, as I thought you asked. I did say that they explored different aspects of the problem. As I said to someone else upthread: It does not need to be a relative statement in order to be correct. The statement "C is not close to the instruction set of a modern CPU" does not need to be validated by specifying examples of languages that are closer.
    - taeric 3y ago
      I think it is somewhat fair to take "what is the alternative" to be in relation to the headline claim. So, "what is the alternative that is low level?" I think I agree that it is fair to push back on the very idea of a "low level" language. But that feels somewhat banal. We get it, there are abstractions even at the lower levels nowadays that simply didn't exist back when. Similarly, if someone claims that Haskel isn't a "high level" language, what does that mean? And to be fair, we have screwed up terms so much it is embarrassing. I see arguments on whether or not LISP is a functional language quite often. There was an amusing discourse not long ago on whether SQL was declarative. Turns out, taxonomies are tough and strict taxonomies are near useless.
      - lproven 3y ago
        It's not my headline claim, and if one wants to enter into debate about what the article means, then step 1 is reading the article. As for the rest: well, yes, fair enough, but somewhat tangential to this subthread, I feel.
        taeric 3y ago
        I meant my first claim to be that it is charity to the question that it was written to reflect against the headline. Even with what comes in the article. Which, frankly, doesn't change much? Indeed, the core claim at the start of the article is "The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades." But, no they weren't. They were added to allow the CPUs to maintain resource utilization while executing code that they are taking a probabilistic stab at. There is some odd appeal to GPU programming, ignoring that the main reason GPU programming can do what they do, is because it is a foregone assumption that you will have to do the same operation across the entire visible scene. So, back to the question at hand, what is this "lower level language" that is being talked about? Best I can see from this article, it is "c" but with vectors and no aliasing? And many more core instructions? I know of basically no languages that make it clear that sqrt could be a CPU level instruction. And that one is somewhat trivial to name. It wasn't too long ago that we saw discussion of popcnt instruction. Is that a "primitive" part of any non-assembly language? It is a neat assumption to challenge, that C may be limiting what we can do. But, with how often the C and C with inline assembly dominate most any performance category, it is a steep hill to climb to show that that is what is limiting us. I also find the closing remarks about how "There is a common myth in software development that parallel programming is hard" to be kind of flippantly insulting. Would be like claiming any sport is easy because "look, you can teach grade school kids to play." Especially as I have seen plenty of bugs in actor-model languages to know it is no panacea. I agree it is easy to specify parallel activities. It gets a lot harder as you start adding in all of the deadlines and other work handoffs that are necessary for fast execution. Again, sports make a good example. Hitting a ball is easy. Running cross court to return a fast shot from an opponent is, essentially, the same thing. Far far harder, though.
- agumonkey 3y ago
  While I'm reading about limbo and occam, what do you think apl and oberon can express that C cannot ? talking about low level electronics benefits (apl array idioms are superb for sure)
  - pjmlp 3y ago
    Bounds checking by default. Actors, more precisely active objects in Active Oberon, the only one still actively being developed at ETHZ from Oberon linage.
    - lelanthran 3y ago
      >> what do you think apl and oberon can express that C cannot ? > Bounds checking by default. That's odd - I've written a C container library that checks bounds by default. Are you sure that C doesn't allow you to check bounds?
      - pjmlp 3y ago
        Absolutely unless you're using a compiler with language extensions for pointer management. A library isn't the language that is described by the ISO C standard document.
        lelanthran 3y ago
        > A library isn't the language that is described by the ISO C standard document. Sure, but the poster didn't ask "what comes with apl and oberon that doesn't come with C", they asked "what do you think apl and oberon can express that C cannot?" And you absolutely, positively can EXPRESS bounds checking in C. I'm not sure where you heard that this is impossible, but it's probable you misunderstood or that source is wrong.
        pjmlp 3y ago
        First of all your library doesn't come with C, otherwise it would be defined on the PDF I can buy from ISO. Secondly using if statements and conditional expressions isn't what bounds checking in a programing language is about. Here is some education material, https://en.wikipedia.org/wiki/Bounds_checking https://en.wikipedia.org/wiki/Bounds_checking > Many programming languages, such as C, never perform automatic bounds checking to raise speed. However, this leaves many off-by-one errors and buffer overflows uncaught. Many programmers believe these languages sacrifice too much for rapid execution.[1] In his 1980 Turing Award lecture, C. A. R. Hoare described his experience in the design of ALGOL 60, a language that included bounds checking, saying: Feel free to update the Wikipedia page and convince Wikipedia of your reasoning.
ahoka 3y ago
GNU assembler, nasm, if you really need to go low level, usually you don’t.
- papruapap 3y ago
  isnt assembler a high level language nowadays?
  - d_tr 3y ago
    Why would you think so? Assembler is what it has always been, i.e., mnemonics for machine instructions. Unless you are thinking about microcode, which is nothing new and I am not sure it should count as a "level" from the perspective of a programmer anyway.
    - semiquaver 3y ago
      By the standards of this article assembler on most architectures suffers from many of the same things that make C “not low level”: in particular it offers little control over cache hierarchy or coherency (modulo hint instructions like x86’s PREFETCH), nor instruction level parallelism. Of course, these aspects are entirely due to the fact that the dominant lingua-franca (C) has no ability to support these semantics. In large part the article argues that in most cases the abstract machines that ISAs describe differ so fundamentally from the reality of how code is executed on the underlying machine to make a truly low level language impossible to achieve.
  - illys 3y ago
    Your question seems provocative... but that's a very good question. I've always liked assembly programming and I got very puzzled when I discovered the processor metal have gone very far from the x86 instruction set I was writing. Il felt like the magic was gone. Indeed there is no direct match anymore between instructions and gate combinations on the processor die. There is a microcode translating x86 instruction into whatever electronics are below. Change this microcode, and you could have your processor speak a different binary code (matched to a assembler language).
rfoo 3y ago
Rewrite the world in Rust /s The real answer is: none. There are two problems, the first is you have to rewrite the world with the new language and hardware. The second is, unfortunately, language enthusiasts who are willing to rewrite the world AND can get job done want a language to target a sequential abstract machine (i.e. look like C).
- pjmlp 3y ago
  C++ is serving me well staying away from C as much as possible, since 1993.
olafura 3y ago
One example given in the article is Erlang VM which maps a lot better to modern processors. We currently have a problem where we can't have thousands of cores because, even today, so much code is designed to be fast on one core. We really have to move the asynchronous programming because synchronizing async hardware is both complex and inefficient. RISC V is probably going to help since it allows for a lot of experimentation.
creshal 3y ago
The article does mention a few areas of interest: - Languages with "better" (=more modern hardware friendly) loop constraints are easier to parallelize (Fortran, Erlang, …) - CPU architectures with better programmable vectorization (ARM SVE, Risc-V VE) are much easier to work with, if the language primitives allow it (see above) Porting software over to fortran/erlang on aarch64 is something you can already do today, if you want to. Rust/Zig/etc. and RISC-V could have a good opportunity here to figure out better ergonomics for vectorization and more hardware friendly cache coherency policies, too, but no clue if anyone in the relevant standard gremiums cares. In terms out "but what can I easily use as drop-in replacement?" Yeah, we're kinda stuck with C and languages that inherit its problems (current Rust/Zig/etc. included).
- xet7 3y ago
  Rust/Zig does not have enough portability, there is errors trying to compile to s390x: https://github.com/wekan/wekan-node20#trying-to-compile-llvm-for-zig-and-bun-at-s390x-fails https://github.com/wekan/wekan-node20#trying-to-compile-llvm... C89 compiles to 30+ CPU/OS: https://github.com/xet7/darkesthour https://github.com/xet7/darkesthour

Of course it isn't, but what's the alternative?

by usrnm 3y ago

Of course it isn't, but what's the alternative?

My favourite article about C in years. To answer your question off the top of my head, answering different bits of the issue, from the perspective of the era of active programming language R&D not themes on themes on themes as we have now... Limbo, Occam (Occam-pi, etc.), APL (I/J, Aplus, etc.), Oberon (Oberon 2, Oberon 07, Active Oberon, Zennon)...

usrnm 3y ago
I'm not familiar with these languages, but which of them is closer to the actual modern hardware than C, while still being abstract enough to be portable?
- lproven 3y ago
  In what way did I imply that any of them were in any way closer? That was not my intention at all. You asked what alternatives there were. C is a systems implementation language, designed to be compiled to object code that will run on the bare metal. I offered some examples of alternatives to that role, as I thought you asked. I did say that they explored different aspects of the problem. As I said to someone else upthread: It does not need to be a relative statement in order to be correct. The statement "C is not close to the instruction set of a modern CPU" does not need to be validated by specifying examples of languages that are closer.
  - taeric 3y ago
    I think it is somewhat fair to take "what is the alternative" to be in relation to the headline claim. So, "what is the alternative that is low level?" I think I agree that it is fair to push back on the very idea of a "low level" language. But that feels somewhat banal. We get it, there are abstractions even at the lower levels nowadays that simply didn't exist back when. Similarly, if someone claims that Haskel isn't a "high level" language, what does that mean? And to be fair, we have screwed up terms so much it is embarrassing. I see arguments on whether or not LISP is a functional language quite often. There was an amusing discourse not long ago on whether SQL was declarative. Turns out, taxonomies are tough and strict taxonomies are near useless.
    - lproven 3y ago
      It's not my headline claim, and if one wants to enter into debate about what the article means, then step 1 is reading the article. As for the rest: well, yes, fair enough, but somewhat tangential to this subthread, I feel.
      - taeric 3y ago
        I meant my first claim to be that it is charity to the question that it was written to reflect against the headline. Even with what comes in the article. Which, frankly, doesn't change much? Indeed, the core claim at the start of the article is "The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades." But, no they weren't. They were added to allow the CPUs to maintain resource utilization while executing code that they are taking a probabilistic stab at. There is some odd appeal to GPU programming, ignoring that the main reason GPU programming can do what they do, is because it is a foregone assumption that you will have to do the same operation across the entire visible scene. So, back to the question at hand, what is this "lower level language" that is being talked about? Best I can see from this article, it is "c" but with vectors and no aliasing? And many more core instructions? I know of basically no languages that make it clear that sqrt could be a CPU level instruction. And that one is somewhat trivial to name. It wasn't too long ago that we saw discussion of popcnt instruction. Is that a "primitive" part of any non-assembly language? It is a neat assumption to challenge, that C may be limiting what we can do. But, with how often the C and C with inline assembly dominate most any performance category, it is a steep hill to climb to show that that is what is limiting us. I also find the closing remarks about how "There is a common myth in software development that parallel programming is hard" to be kind of flippantly insulting. Would be like claiming any sport is easy because "look, you can teach grade school kids to play." Especially as I have seen plenty of bugs in actor-model languages to know it is no panacea. I agree it is easy to specify parallel activities. It gets a lot harder as you start adding in all of the deadlines and other work handoffs that are necessary for fast execution. Again, sports make a good example. Hitting a ball is easy. Running cross court to return a fast shot from an opponent is, essentially, the same thing. Far far harder, though.
agumonkey 3y ago
While I'm reading about limbo and occam, what do you think apl and oberon can express that C cannot ? talking about low level electronics benefits (apl array idioms are superb for sure)
- pjmlp 3y ago
  Bounds checking by default. Actors, more precisely active objects in Active Oberon, the only one still actively being developed at ETHZ from Oberon linage.
  - lelanthran 3y ago
    >> what do you think apl and oberon can express that C cannot ? > Bounds checking by default. That's odd - I've written a C container library that checks bounds by default. Are you sure that C doesn't allow you to check bounds?
    - pjmlp 3y ago
      Absolutely unless you're using a compiler with language extensions for pointer management. A library isn't the language that is described by the ISO C standard document.
      - lelanthran 3y ago
        > A library isn't the language that is described by the ISO C standard document. Sure, but the poster didn't ask "what comes with apl and oberon that doesn't come with C", they asked "what do you think apl and oberon can express that C cannot?" And you absolutely, positively can EXPRESS bounds checking in C. I'm not sure where you heard that this is impossible, but it's probable you misunderstood or that source is wrong.
        pjmlp 3y ago
        First of all your library doesn't come with C, otherwise it would be defined on the PDF I can buy from ISO. Secondly using if statements and conditional expressions isn't what bounds checking in a programing language is about. Here is some education material, https://en.wikipedia.org/wiki/Bounds_checking https://en.wikipedia.org/wiki/Bounds_checking > Many programming languages, such as C, never perform automatic bounds checking to raise speed. However, this leaves many off-by-one errors and buffer overflows uncaught. Many programmers believe these languages sacrifice too much for rapid execution.[1] In his 1980 Turing Award lecture, C. A. R. Hoare described his experience in the design of ALGOL 60, a language that included bounds checking, saying: Feel free to update the Wikipedia page and convince Wikipedia of your reasoning.

ahoka 3y ago

GNU assembler, nasm, if you really need to go low level, usually you don’t.

papruapap 3y ago
isnt assembler a high level language nowadays?
- d_tr 3y ago
  Why would you think so? Assembler is what it has always been, i.e., mnemonics for machine instructions. Unless you are thinking about microcode, which is nothing new and I am not sure it should count as a "level" from the perspective of a programmer anyway.
  - semiquaver 3y ago
    By the standards of this article assembler on most architectures suffers from many of the same things that make C “not low level”: in particular it offers little control over cache hierarchy or coherency (modulo hint instructions like x86’s PREFETCH), nor instruction level parallelism. Of course, these aspects are entirely due to the fact that the dominant lingua-franca (C) has no ability to support these semantics. In large part the article argues that in most cases the abstract machines that ISAs describe differ so fundamentally from the reality of how code is executed on the underlying machine to make a truly low level language impossible to achieve.
- illys 3y ago
  Your question seems provocative... but that's a very good question. I've always liked assembly programming and I got very puzzled when I discovered the processor metal have gone very far from the x86 instruction set I was writing. Il felt like the magic was gone. Indeed there is no direct match anymore between instructions and gate combinations on the processor die. There is a microcode translating x86 instruction into whatever electronics are below. Change this microcode, and you could have your processor speak a different binary code (matched to a assembler language).

rfoo 3y ago

Rewrite the world in Rust /s The real answer is: none. There are two problems, the first is you have to rewrite the world with the new language and hardware. The second is, unfortunately, language enthusiasts who are willing to rewrite the world AND can get job done want a language to target a sequential abstract machine (i.e. look like C).

pjmlp 3y ago
C++ is serving me well staying away from C as much as possible, since 1993.

olafura 3y ago

One example given in the article is Erlang VM which maps a lot better to modern processors. We currently have a problem where we can't have thousands of cores because, even today, so much code is designed to be fast on one core. We really have to move the asynchronous programming because synchronizing async hardware is both complex and inefficient. RISC V is probably going to help since it allows for a lot of experimentation.

creshal 3y ago

The article does mention a few areas of interest: - Languages with "better" (=more modern hardware friendly) loop constraints are easier to parallelize (Fortran, Erlang, …) - CPU architectures with better programmable vectorization (ARM SVE, Risc-V VE) are much easier to work with, if the language primitives allow it (see above) Porting software over to fortran/erlang on aarch64 is something you can already do today, if you want to. Rust/Zig/etc. and RISC-V could have a good opportunity here to figure out better ergonomics for vectorization and more hardware friendly cache coherency policies, too, but no clue if anyone in the relevant standard gremiums cares. In terms out "but what can I easily use as drop-in replacement?" Yeah, we're kinda stuck with C and languages that inherit its problems (current Rust/Zig/etc. included).

xet7 3y ago
Rust/Zig does not have enough portability, there is errors trying to compile to s390x: https://github.com/wekan/wekan-node20#trying-to-compile-llvm-for-zig-and-bun-at-s390x-fails https://github.com/wekan/wekan-node20#trying-to-compile-llvm... C89 compiles to 30+ CPU/OS: https://github.com/xet7/darkesthour https://github.com/xet7/darkesthour