The runtime for .Net applications is included with Windows these days, so can ship your compiled C# program without users needing to get a runtime. By your definition is it then an assembled language or an interpreted language.
C#, C++, and C are three different languages, btw.
As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)
C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.
That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.
Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.
Sun made hardware which natively runs Java bytecode.
Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.
The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.
An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.
Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
C#, C++, and C are three different languages, btw.
As to C++ and C, they often rely on dynamically linked libraries, but dependencies are an unrelated issue for any language. You'll note I never brought it into the Java discussion; going into dependencies is another moving-the-target distraction tactic (don't worry, I won't blame you for inventing it...it's been in use for a while.)
C++ and C can produce binaries which require no dependencies, simply by avoiding the standard library.
That said, I will admit to using the wrong term a moment ago; runtime is a dependency library, whereas what I'm referring to with Java is the software responsible for executing the bytecode on the target machine.
Dependencies shouldn't enter into this discussion, all languages (practically speaking) have to be able to resolve dependencies.
Also a case of moving-the-target. I already stated earlier that there were impractical means by which virtually any assembled languages can be interpreted, and virtually any interpreted/interpreted-compiled languages can be assembled. This does not count because it has no bearing on standard deployment.
The inescapable point: Java is, for all practical intents and purposes, never assembled to a machine code binary file, such that it can be shipped to an end-user (w/ or w/o dependency libraries compiled to the same), and executed directly on a standard Intel, AMD, or ARM processor without needing an additional program to interpret (or, if you want to get pedantic, AOT/JIT-compile) the (byte)code.
An interpreted language has a software layer between the final, shipped result of compilation and its ultimate execution on the target machine.
Ergo, Java is compiled-interpreted. It is NOT assembled. It is also NOT interactive. (But, yes, it's still a real language.)