5 ms·

Some people say that C isn't low-level (though I disagree). I personally don't think of C# as even remotely low-level.

by 0xTJ 8y ago

coldtea 8y ago
>Some people say that C isn't low-level Then again some people will say anything. It's how things are used in practice that matters.
tybit 8y ago
I think that’s the point of this article. No C# isn’t remotely a low level language, yet it has all these features that allow it to drop pretty low when necessary.
Posibyte 8y ago
The author takes this into consideration: * yes, I know ‘low-level’ is a subjective term I used to work in the embedded world, and there C has historically been considered a "high-level" language for many platforms. However, we have started to see languages like C# and Python make their way into the world of tiny micros thanks to more power coming to the platforms themselves and the clever work being done by MicroPython and Microsoft.
- htfy96 8y ago
  The problem is that most legacy code (especially firmwares) is C and will never have a chance to be rewritten in another language. If you get a chance into VLSI field you will be amazed that they are still relying on Tcl to do complicated stuffs. Only part of the world's software (most in IT companies) can afford rewriting in a new language regardless of costs/upstreams.
nearbuy 8y ago
I think the article is pointing out that C# offers many of the benefits of low level languages like C/C++, including some control over memory layout, passing by ref, calling conventions with P/invoke, and soon, SIMD intrinsics.
- Gibbon1 8y ago
  I tend to think being able to locate, describe and manipulate objects in native memory tends to define a low level language as is the ability to control latency. These are the reasons most garbage collected languages aren't low level. Garbage collection traditional means you can't meet hard latency contracts. And by definition you have no control over where garbage collected objects are in memory.
  - nearbuy 8y ago
    You can actually do some of that by pinning objects in unsafe blocks along with using the FieldOffset attribute. This is where the term "low level" is a bit ambiguous and relative. If you're trying to bit bang some serial protocol on a microcontroller with tight timings, C# and the GC are going to give you a hard time. But even C might give you a hard time here. I've had to drop down to inline assembly because it's much easier to count the cycles it'll take and insert a few nops where necessary to get the timing right. Then, if you're on a non-realtime OS like Windows or Linux, no language is going to give you hard latency constraints. Going further, it would be difficult to bit bang with tight timing constraints on x86 altogether due to speculative execution. So from that perspective, C, x86, and modern operating systems might all be too high level to achieve your goal. But for other goals, you might have a different answer. One interesting example was Xbox 360 games. Game developers have traditionally used C++, because they have performance and latency constraints: if you're targeting 60 fps, you don't want any frames taking more than 16.6 ms. Indie developers had to use C# to make games for the 360. Unfortunately, the .Net Compact Framework it used had an old, slow, non-generational GC, which would cause hitches. So games would do one of two things to avoid hitches. Either they'd design their games to make zero allocations per frame, or they'd design their memory layout to be very simple so the GC would run fast. Structs are very helpful here because they don't generally allocate on the heap. So was C# low level enough for game development on the Xbox 360? I'd say mostly. It gave you some hassle with the GC, but ultimately you had enough control over performance and latency to make it work.
qwerty456127 8y ago
It can be considered low-level as long as you consider CLR the target machine. In the same way Java is equally low-level for the JVM and Julia is for LLVM. But this is not strictly correct as the final target for whatever still is the physical machine (x86, ARM or whahtever) and neither C# nor Java are low-level relatively to it.
benj111 8y ago
I think theres a drift over time. If you're inputting hand assembled hex, then an assembler is high level. If you writing ASM, C is high level. C is now thought of as low level, I'm sure many formerly 'high' level languages will become low level also.

Some people say that C isn't low-level (though I disagree). I personally don't think of C# as even remotely low-level.

by 0xTJ 8y ago

Some people say that C isn't low-level (though I disagree). I personally don't think of C# as even remotely low-level.

>Some people say that C isn't low-level Then again some people will say anything. It's how things are used in practice that matters.

tybit 8y ago

I think that’s the point of this article. No C# isn’t remotely a low level language, yet it has all these features that allow it to drop pretty low when necessary.

Posibyte 8y ago

The author takes this into consideration: * yes, I know ‘low-level’ is a subjective term I used to work in the embedded world, and there C has historically been considered a "high-level" language for many platforms. However, we have started to see languages like C# and Python make their way into the world of tiny micros thanks to more power coming to the platforms themselves and the clever work being done by MicroPython and Microsoft.

htfy96 8y ago
The problem is that most legacy code (especially firmwares) is C and will never have a chance to be rewritten in another language. If you get a chance into VLSI field you will be amazed that they are still relying on Tcl to do complicated stuffs. Only part of the world's software (most in IT companies) can afford rewriting in a new language regardless of costs/upstreams.

nearbuy 8y ago

I think the article is pointing out that C# offers many of the benefits of low level languages like C/C++, including some control over memory layout, passing by ref, calling conventions with P/invoke, and soon, SIMD intrinsics.

Gibbon1 8y ago
I tend to think being able to locate, describe and manipulate objects in native memory tends to define a low level language as is the ability to control latency. These are the reasons most garbage collected languages aren't low level. Garbage collection traditional means you can't meet hard latency contracts. And by definition you have no control over where garbage collected objects are in memory.
- nearbuy 8y ago
  You can actually do some of that by pinning objects in unsafe blocks along with using the FieldOffset attribute. This is where the term "low level" is a bit ambiguous and relative. If you're trying to bit bang some serial protocol on a microcontroller with tight timings, C# and the GC are going to give you a hard time. But even C might give you a hard time here. I've had to drop down to inline assembly because it's much easier to count the cycles it'll take and insert a few nops where necessary to get the timing right. Then, if you're on a non-realtime OS like Windows or Linux, no language is going to give you hard latency constraints. Going further, it would be difficult to bit bang with tight timing constraints on x86 altogether due to speculative execution. So from that perspective, C, x86, and modern operating systems might all be too high level to achieve your goal. But for other goals, you might have a different answer. One interesting example was Xbox 360 games. Game developers have traditionally used C++, because they have performance and latency constraints: if you're targeting 60 fps, you don't want any frames taking more than 16.6 ms. Indie developers had to use C# to make games for the 360. Unfortunately, the .Net Compact Framework it used had an old, slow, non-generational GC, which would cause hitches. So games would do one of two things to avoid hitches. Either they'd design their games to make zero allocations per frame, or they'd design their memory layout to be very simple so the GC would run fast. Structs are very helpful here because they don't generally allocate on the heap. So was C# low level enough for game development on the Xbox 360? I'd say mostly. It gave you some hassle with the GC, but ultimately you had enough control over performance and latency to make it work.

qwerty456127 8y ago

It can be considered low-level as long as you consider CLR the target machine. In the same way Java is equally low-level for the JVM and Julia is for LLVM. But this is not strictly correct as the final target for whatever still is the physical machine (x86, ARM or whahtever) and neither C# nor Java are low-level relatively to it.

benj111 8y ago

I think theres a drift over time. If you're inputting hand assembled hex, then an assembler is high level. If you writing ASM, C is high level. C is now thought of as low level, I'm sure many formerly 'high' level languages will become low level also.