> Anyone with a degree in CS knows this is not true.
Not sure what you are trying to imply here? Perhaps it's to say that all code can be compiled down to machine instructions? -- Well, that would negate a lot of benefits of using some of the higher level languages and/or their portability of architecture claims. So yes, my statement stands true unless you do compile down to machine code for your target platform.
> Additionally there are quite a few native code compilers for Java and C#.
I'm not very familiar with C#, but it's worth noting that Java does indeed get compiled down to native machine instructions during runtime (mostly noticeable on long-running applications and especially in "hot zones" of code). It's been claimed that the optimizing compiler embedded in the JVM is one of the best around, and usually will result in code running at the same performance level as C on the same platform (again for long running code allowed).
> I don't know? Maybe because every other system programming language since the late 70's had a module system?
There aren't exactly many languages that are considered to be "System Programming Languages". For most of the *nix's (all?), it's C (which as noted does not have a native module system). For Windows, it's mostly C++, which also has no native module system. One should ask what benefits a module system would bring to a mostly bare-bones language like C that could not be achieved in the 40+ years it's been around?
Ada, Eiffel, D, Go, Rust, OCaml, Common Lisp, Haskell, Scheme Dylan, among many others, provide native ahead of time compilers in their default toolchains.
All look pretty high level to me.
C# can be compiled ahead of time with ngen since .NET 1.0.
Singularity compiles Sing# (an extension of C#) to static binaries
Windows Phone applications get compiled to native code on the store. The mobile phones only see native code.
.NET Native will bring the same functionality to desktop applications.
Mono compiles C# to native code in iOS and offers the same functionality on other systems.
The now defunt CosmoOS used C#, compiled to native code, as their systems programming language.
There isn't no such thing as "The JVM". It is a specification with a reference implementation, that any JVM vendor can be certified against.
Just like any other language vendor can be certified against the respective ECMA or ISO standard for their respective languages.
Aonix PERC, JamaicaVM, J9, SubstrateVM, JikesRVM, ART are all examples of Java environments that offer the option to compile straight to native code.
> Ada, Eiffel, D, Go, Rust, OCaml, Common Lisp, Haskell, Scheme Dylan, among many others, provide native ahead of time compilers in their default toolchains.
I think you and Alupis have different definitions of the term "system programming language". In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.
I think a good indication for a system programming language is the ability to write its runtime system in itself. Any language with non-optional GC collection fails this test, because you couldn't write the GC in that language.
> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.
No, because I have listed Ada in my list.
> Any language with non-optional GC collection fails this test, because you couldn't write the GC in that language.
Better improve your CS skills. Ever heard of Cedar, Modula-3, Oberon, Active Oberon?
EDIT: Just for the kicks, here is Oberon's GC implementation, in Oberon!
>> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.
> No, because I have listed Ada in my list.
I have no idea how that would refute my statement.
> Better improve your CS skills.
Don't be so condescending.
> Oberon GC in Oberon
I stand corrected: You're right, the GC runtime for a language with non-optional GC can be written in the language itself.
I guess a better, more precise indicator are the following two requirements:
1) Native support for calling OS services, for example through system calls (specifically, reservation of memory space).
2) Pointers, pointer arithmetic, and reading/writing memory through pointers.
I don't see how one could implement the GC runtime without these features. (Note that native support for heap-allocation means that GC is optional anyway). What do you think?
> I have no idea how that would refute my statement
Ada is used for building systems running on bare metal.
> Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers.
Oberon variants and Modula-3 support GC pointers and have been used to write full OSs.
Pointer arithmetic is possible in code regions marked as unsafe.
The Oberon based ones were used for several years at Swiss Federal Institute of Technology.
Spin (Modula-3) didn't had such luck, as DEC and Olivetti got closed down.
Just read the code provided in the link for Oberon's example.
The problem is that many think GC == Java, while during the years Java was getting loose into the world, there where languages like Cedar, Oberon and Modula-3 that while having a GC do offer the fine grain control one needs for system programming.
> Note that native support for heap-allocation means that GC is optional anyway
Not really. In safe systems programming language the GC is always there and you need to mark the code as unsafe when allocating from foreign heap. Meaning you are responsible for not tainting the whole code base.
For example, in the Oberon OS only the Kernel and driver modules do manual allocation.
Actually, Java 9 is getting the missing features from safe systems programming languages (some of them will only come in Java 10).
Not sure what you are trying to imply here? Perhaps it's to say that all code can be compiled down to machine instructions? -- Well, that would negate a lot of benefits of using some of the higher level languages and/or their portability of architecture claims. So yes, my statement stands true unless you do compile down to machine code for your target platform.
> Additionally there are quite a few native code compilers for Java and C#.
I'm not very familiar with C#, but it's worth noting that Java does indeed get compiled down to native machine instructions during runtime (mostly noticeable on long-running applications and especially in "hot zones" of code). It's been claimed that the optimizing compiler embedded in the JVM is one of the best around, and usually will result in code running at the same performance level as C on the same platform (again for long running code allowed).
> I don't know? Maybe because every other system programming language since the late 70's had a module system?
There aren't exactly many languages that are considered to be "System Programming Languages". For most of the *nix's (all?), it's C (which as noted does not have a native module system). For Windows, it's mostly C++, which also has no native module system. One should ask what benefits a module system would bring to a mostly bare-bones language like C that could not be achieved in the 40+ years it's been around?