5 ms·

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?

by usrnm 3y ago

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.
      - lproven 3y ago
        I don't really know what you're talking about, TBH. You are bringing GPU programming into it, which I never mentioned at all. Again: saying "X is not big" is not a relative claim. Saying "X is the biggest" is a relative claim but nobody's saying that. "Low level" means "close to the metal". The way C is often described is as "a portable assembly language". The article is saying that is not true. That the model of computation, of processor operation, that C represents is a 1970s model of how computers work and it barely fits onto modern machines at all. I can't name anything closer to the metal or lower level, but it doesn't matter; it is irrelevant to the discussion.

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?

by 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.
    - lproven 3y ago
      I don't really know what you're talking about, TBH. You are bringing GPU programming into it, which I never mentioned at all. Again: saying "X is not big" is not a relative claim. Saying "X is the biggest" is a relative claim but nobody's saying that. "Low level" means "close to the metal". The way C is often described is as "a portable assembly language". The article is saying that is not true. That the model of computation, of processor operation, that C represents is a 1970s model of how computers work and it barely fits onto modern machines at all. I can't name anything closer to the metal or lower level, but it doesn't matter; it is irrelevant to the discussion.