Difference between Systems programming language and Application programming languages

Question

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

Solution 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.

Solution 2

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 :)

Solution 3

These are not exact concepts, but in essence, systems programming languages are suitable for writing operating systems (so they have low-level concepts such as pointers, integration with assembler, data types corresponding to memory and register organization), while the application programming languages are more suitable for writing applications, so they generally use higher-level concepts to represent the computation (such as OOP, closures, in-built complex datatypes and so on).

Solution 4

In general, a systems programming language is lower level than applications programming languages. However, the language itself has nothing to do with it.. it's more the particulars of the implementation of the language.

For example, Pascal started life as a teaching language, and was pretty much strictly applications.. however, it was evolved into a systems language and was used to create early versions of MacOS and Windows.

C# is not, typically a systems language because it cannot do low-level work, although even that line is blurred as managed operating systems come into being.

Solution 5

i don't think there is a final answer here anymore.

perl and python come by default with almost every linux distro...both can inline C...both can do job control and other "low level" tasks...threading etc.

any language with a good set of system call bindings and/or FFI should be as fundamentally system-aware as C or C++.

the only languages i would discount as being systems languages are those that specifically address another platform (jvm, clr) and actively seek to prevent native interaction

View more solutions

Comments

[jmj]

wiki.answers.com/Q/…

[Admin]

C should have stayed "systems" programming ;-)

[Peter G. McDonald]

C might not be best choice for a lot of applications, but there are still enough applications where C is a good choice. C is also being revived as the basis on parallel programming languages (eg. CUDA, OpenCL). It's popularity (not withstanding the impact of legacy support) can't be denied (eg. www.tiobe.com Programming Language Index). I develop in a range of languages, but I'll always have a soft spot for C, call me masochistic; I love assembly language too ;-)

[Stephen C]

"... I believe mostly are native compiled, rather than to byte code and JIT'ed / interpreted". For JNode, the base system and core plugins are native compiled, the rest is JIT compiled (without any interpretation).