Difference between Systems programming language and Application programming languages

What are the differences between a systems programming language and Application programming language ?

5 Answers 5

A few factors should in my opinon come into consideration

1. In a system programming language you must be able to reach low-level stuff, getting close to the real hardware world. In an application language instead there is a sort of "virtual world" (hopefully nicer and easier to interact with) that has been designed with the language and you only need to be able to cope with that.
2. In a system programming language there should be no concession in terms of performance. One must be able to write code that squeezes out all the juice from the hardware. This is not the biggest concern in an application programming language, where the time needed to actually write the program plays instead a greater role.
3. Because of 2 a system programming language is free to assume that the programmer makes no mistake and so there will be no "runtime error" guards. For example indexing out of an array is going to mean the end of the world unless the hardware gives those checks for free (but in that case you could probably choose less expensive or faster hardware instead). The idea is that if you assume that the code is correct there is no point in paying even a small price for checking the impossible. Also a system programming language shouldn't get into the way trying to forbid the programmer doing something s/he wants to do intentionally. the assumption is that s/he knows that is the right thing to do. In an application programming language instead it's considered good helping the programmer with checking code and also trying to force the code to use certain philosophical schemas. In application programming languages things like execution speed, typing time and code size can be sacrificed trying to help programmers avoiding shooting themselves.
4. Because of 3 a system programming language will be much harder to learn by experimentation. In a sense they're sort of powerful but dangerous tools that one should use carefully thinking to every single statement and for the same reason they're languages where debugging is much harder. In application programming languages instead the try-and-see approach may be reasonable (if the virtual world abstraction is not leaking too much) and letting errors in to remove them later is considered a viable option.

As with a great many things in IT, the line is blurry. For example, C started its life as a systems programming language (and was used to implement Unix), but was and is used for applications development too.

Having said that, there are clearly some languages better suited to systems programming than others (eg. C/C++ are better suited than COBOL/FORTRAN for systems programming). Likewise there are languages that are better suited to applications development and not systems programming eg. VB.NET.

The language features that stand out from the examples above, are the low level features of the systems programming languages like C/C++ (eg. pointers, bit manipulation operators, etc). There is of course the old joke that C is a "Sea" level language (sitting somewhere between the assembly level and the "high" level).

Warning: I'm coming at systems programming from the perspective of OS developer / OS tool developer.

I think it is fair to say, notwithstanding the projects to develop OSes with Java (though I believe mostly are native compiled, rather than to byte code and JIT'ed / interpreted), that systems programming languages target native machine code of their target platforms. So languages that primarily target managed code / interpreted code are less likely to be used for systems programming.

Anyway, that is surely enough to stir up some comments both in support and in opposition :)