Difference between Systems programming language and Application programming languages

Question

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

Answer 1

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.