3 ms·

I don't think it was ever claimed that C was a low level language. In fact I have always heard it as the canonical reference for an example of a high level lang

by somat 3y ago

I don't think it was ever claimed that C was a low level language. In fact I have always heard it as the canonical reference for an example of a high level language. I will admit that in this day and age C feels like a low level language. Lower level is something that maps more directly to machine operation (assembly, maybe forth). Higher level is something that has it's own semantics of operation and need to be converted to into the machine operation, the more conversion the higher the level.

woodruffw 3y ago
It is somewhat common to describe C as “low level” in introductory programming or CS classes (before the student would know what an abstract machine is). Lots of people carry misunderstandings from that early simplification forwards in their careers, especially if their only interaction with C is academic and not professional.
- philipov 3y ago
  When C was declared to be "high level", there did not exist a level higher than C. Now that there are more levels above C, it is not the highest level language out there, which makes it low level compared to them. It is not the lowest level, but it's not a misunderstanding to call it low level. The playing field is not the same as it was 50 years ago, so relative terms like "low" and "high" have naturally changed referends.
  - coldtea 3y ago
    Huh? Tons of languages at levels "higher than C" existed at that time C was created, and they were popular too. LISP (1960), Smalltalk (1972), BASIC (1963), FORTRAN (1957), COBOL (1959) and countless others. Heck, ALGOL (1958, 1968) was much higher level than C too.
  - pjmlp 3y ago
    Yes it did, outside Bell Labs.
- noirscape 3y ago
  It's also that the definition of high vs low level has shifted in the past decade. Nowadays a "high level language" is one where the person using it doesn't necessarily have to think about memory usage and allocation, since that's the task of a garbage collector - you accept a small amount of inefficiency in order to get a program that works "good enough" in 99.9% of all cases (since we're not on ancient devices anymore and most programmers don't write code that upsets the garbage collector in novel ways). By this criteria, Java, C#, Python, JavaScript, Ruby and so on are "high level languages" in that the programmer rarely has to think about this sort of thing; the underlying GC takes care of memory concerns. There's a reason you see these languages used more for end-user tools like webdev, scripting and desktop applications - the penalty is considered worth it (since it often ends up only shaving off milliseconds at most). By contrast a low level language basically makes the programmer an active participant in memory management, with all the footguns that come with it. C and Rust are both two extremes of this - C just lets you do whatever, any form of memory control is up to you, segfaults included. Meanwhile Rust deliberately prevents you from doing anything that could possibly cause segfaults through its borrow checker. In some ways C can give you a lot more freedom to be efficient in how you allocate/deallocate your memory (or in the case of Rust - write code that is always memory safe), but you do trade things for it (in C you basically have to be really meticulous about free()-ing memory while in Rust you have to eat a lot of complexity upfront to not upset the borrow checker). Also contrasting to high level languages, the modern domain of lower level languages tend to be things like drivers, kernels, RDBMSes and the like, rather than conventional user-facing applications (which it also was used for in the past since most of the previously mentioned languages are either pretty young or took quite some time to mature). Still useful, just a different set of expectations, since those are the components that have to be fast so the rest doesn't have to be as hyperefficient.
  - adamrezich 3y ago
    > in C you basically have to be really meticulous about free()-ing memory only if you malloc()/free() for every allocation/deallocation. if you use any other allocation strategy then this is never an issue. for example: see the "Rewriting the memory management" section in this article: https://phoboslab.org/log/2023/08/rewriting-wipeout https://phoboslab.org/log/2023/08/rewriting-wipeout > I'm not sure what the original PSX version did, but the PC version had a lot of malloc() and little fewer free() calls scattered around. Now I can assure you that the game doesn't leak any memory, because it never calls malloc(). > Instead, there's a fixed size statically allocated uint8_t hunk[MEM_HUNK_BYTES]; of 4mb that is used from both sides: > A bump allocator takes bytes from the front of the hunk. This is used for everything that persists for many frames. When the game starts, it loads a bunch of assets that are needed everywhere (UI graphics, ship models and textures etc.) into this bump allocater and then remembers the high water mark of it. When you load a race track, it loads all assets needed on top. After finishing a race, the bump allocator is reset to the previous high water mark. > On the other side, a temp allocator takes bytes from the end of the hunk. Temporary allocated objects need to be explicitly released again. This is used when loading a file into memory. The file is read at once and unpacked onto the bump allocated side. When done, the temp memory for the file is released again. > Temporary objects are not allowed to persist over multiple frame. So each frame ends with a check to ensure that the temp allocator is empty. > Somewhat related, the OpenGL renderer does the same with the textures: It bumps up texture memory (more precisely space in the texture atlas) and resets it to the previous level when a race ends. if you use a system like this—either malloc() just once (or a few times) at the start of your program and then never manually free(), or just use statically-allocated arrays—then you never have to worry about "meticulous free()ing". I'm not sure why this never seems to be taught in early CS courses that teach C—it seems that basically everyone comes away thinking malloc()/free() OCD is the only way to manage memory with C, and is thus undesirable compared to the ease of use of garbage collection.
Alifatisk 3y ago
> I don't think it was ever claimed that C was a low level language. When I was introduced to C during high school, my teacher presented C as a low-level language compared to what we previously studied (which was Ruby). And I just ate that up because C looked less readable than Ruby, today (10 years later) I have to disagree with my teacher. C is not a low-level language, it has access to the lower level parts, sure. But it is an high level language!
Normal_gaussian 3y ago
Im curious - what is it about forth that makes you consider it to map more closely to the machine? I've done a handful of forth projects as part of a code-dojo years ago. I wouldn't have considered it low-level.
- domust 3y ago
  It's fortran, not forth.
  - monocasa 3y ago
    They're talking about forth, not Fortran.
    - augustk 3y ago
      Someone should make a Forthran (I wonder what it would look like though).
- creshal 3y ago
  Forth is easy to make custom hardware for, even if it's a poor fit for the commonly available hardware architectures. RPN + Stack lends itself to a very simple implementation (no registers needed, easy layouting, etc.).
- deleted 3y ago
  [deleted]
- somat 3y ago
  Fort is strange, it requires a virtual forth machine to run(I have heard of hardware that runs forth directly but it is exotic), this should automatically exclude it from the low level camp. however this machine ends up almost trivial to write and is very simple. so once you start writing forth it feels low level, like there is very little between you and the cpu. As a consequence, just like assembly, forth people tend to reinvent the world. Note that I am not far in the forth rabbit hole at all, any interest I may show is incidental, a side effect of my interest in postscript, which is very much a high level language.
denton-scratch 3y ago
> I don't think it was ever claimed that C was a low level language. It was introduced to me as "glorified PDP11 Assembly Language". So the claim has been made at least once. Granted, there are people here commenting that maybe assembly language is not "low-level". I'm lost for words.

by somat 3y ago

woodruffw 3y ago

It is somewhat common to describe C as “low level” in introductory programming or CS classes (before the student would know what an abstract machine is). Lots of people carry misunderstandings from that early simplification forwards in their careers, especially if their only interaction with C is academic and not professional.

philipov 3y ago
When C was declared to be "high level", there did not exist a level higher than C. Now that there are more levels above C, it is not the highest level language out there, which makes it low level compared to them. It is not the lowest level, but it's not a misunderstanding to call it low level. The playing field is not the same as it was 50 years ago, so relative terms like "low" and "high" have naturally changed referends.
- coldtea 3y ago
  Huh? Tons of languages at levels "higher than C" existed at that time C was created, and they were popular too. LISP (1960), Smalltalk (1972), BASIC (1963), FORTRAN (1957), COBOL (1959) and countless others. Heck, ALGOL (1958, 1968) was much higher level than C too.
- pjmlp 3y ago
  Yes it did, outside Bell Labs.
noirscape 3y ago
It's also that the definition of high vs low level has shifted in the past decade. Nowadays a "high level language" is one where the person using it doesn't necessarily have to think about memory usage and allocation, since that's the task of a garbage collector - you accept a small amount of inefficiency in order to get a program that works "good enough" in 99.9% of all cases (since we're not on ancient devices anymore and most programmers don't write code that upsets the garbage collector in novel ways). By this criteria, Java, C#, Python, JavaScript, Ruby and so on are "high level languages" in that the programmer rarely has to think about this sort of thing; the underlying GC takes care of memory concerns. There's a reason you see these languages used more for end-user tools like webdev, scripting and desktop applications - the penalty is considered worth it (since it often ends up only shaving off milliseconds at most). By contrast a low level language basically makes the programmer an active participant in memory management, with all the footguns that come with it. C and Rust are both two extremes of this - C just lets you do whatever, any form of memory control is up to you, segfaults included. Meanwhile Rust deliberately prevents you from doing anything that could possibly cause segfaults through its borrow checker. In some ways C can give you a lot more freedom to be efficient in how you allocate/deallocate your memory (or in the case of Rust - write code that is always memory safe), but you do trade things for it (in C you basically have to be really meticulous about free()-ing memory while in Rust you have to eat a lot of complexity upfront to not upset the borrow checker). Also contrasting to high level languages, the modern domain of lower level languages tend to be things like drivers, kernels, RDBMSes and the like, rather than conventional user-facing applications (which it also was used for in the past since most of the previously mentioned languages are either pretty young or took quite some time to mature). Still useful, just a different set of expectations, since those are the components that have to be fast so the rest doesn't have to be as hyperefficient.
- adamrezich 3y ago
  > in C you basically have to be really meticulous about free()-ing memory only if you malloc()/free() for every allocation/deallocation. if you use any other allocation strategy then this is never an issue. for example: see the "Rewriting the memory management" section in this article: https://phoboslab.org/log/2023/08/rewriting-wipeout https://phoboslab.org/log/2023/08/rewriting-wipeout > I'm not sure what the original PSX version did, but the PC version had a lot of malloc() and little fewer free() calls scattered around. Now I can assure you that the game doesn't leak any memory, because it never calls malloc(). > Instead, there's a fixed size statically allocated uint8_t hunk[MEM_HUNK_BYTES]; of 4mb that is used from both sides: > A bump allocator takes bytes from the front of the hunk. This is used for everything that persists for many frames. When the game starts, it loads a bunch of assets that are needed everywhere (UI graphics, ship models and textures etc.) into this bump allocater and then remembers the high water mark of it. When you load a race track, it loads all assets needed on top. After finishing a race, the bump allocator is reset to the previous high water mark. > On the other side, a temp allocator takes bytes from the end of the hunk. Temporary allocated objects need to be explicitly released again. This is used when loading a file into memory. The file is read at once and unpacked onto the bump allocated side. When done, the temp memory for the file is released again. > Temporary objects are not allowed to persist over multiple frame. So each frame ends with a check to ensure that the temp allocator is empty. > Somewhat related, the OpenGL renderer does the same with the textures: It bumps up texture memory (more precisely space in the texture atlas) and resets it to the previous level when a race ends. if you use a system like this—either malloc() just once (or a few times) at the start of your program and then never manually free(), or just use statically-allocated arrays—then you never have to worry about "meticulous free()ing". I'm not sure why this never seems to be taught in early CS courses that teach C—it seems that basically everyone comes away thinking malloc()/free() OCD is the only way to manage memory with C, and is thus undesirable compared to the ease of use of garbage collection.

Alifatisk 3y ago

> I don't think it was ever claimed that C was a low level language. When I was introduced to C during high school, my teacher presented C as a low-level language compared to what we previously studied (which was Ruby). And I just ate that up because C looked less readable than Ruby, today (10 years later) I have to disagree with my teacher. C is not a low-level language, it has access to the lower level parts, sure. But it is an high level language!

Normal_gaussian 3y ago

Im curious - what is it about forth that makes you consider it to map more closely to the machine? I've done a handful of forth projects as part of a code-dojo years ago. I wouldn't have considered it low-level.

domust 3y ago
It's fortran, not forth.
- monocasa 3y ago
  They're talking about forth, not Fortran.
  - augustk 3y ago
    Someone should make a Forthran (I wonder what it would look like though).
creshal 3y ago
Forth is easy to make custom hardware for, even if it's a poor fit for the commonly available hardware architectures. RPN + Stack lends itself to a very simple implementation (no registers needed, easy layouting, etc.).
deleted 3y ago
[deleted]
somat 3y ago
Fort is strange, it requires a virtual forth machine to run(I have heard of hardware that runs forth directly but it is exotic), this should automatically exclude it from the low level camp. however this machine ends up almost trivial to write and is very simple. so once you start writing forth it feels low level, like there is very little between you and the cpu. As a consequence, just like assembly, forth people tend to reinvent the world. Note that I am not far in the forth rabbit hole at all, any interest I may show is incidental, a side effect of my interest in postscript, which is very much a high level language.

denton-scratch 3y ago

> I don't think it was ever claimed that C was a low level language. It was introduced to me as "glorified PDP11 Assembly Language". So the claim has been made at least once. Granted, there are people here commenting that maybe assembly language is not "low-level". I'm lost for words.