Help me sort programming languages a bit

Question

Hi, so I asked here few days ago about C# and its principles. Now, if I may, I have some additional general questions about some languages, because for novice like me, it seems a bit confusing. To be exact I want to ask more about language functions capabilities than syntax and so.

To be honest, its just these special functions that bothers me and make me so confused. For example, C has its printf(), Pascal has writeln() and so. I know in basic the output in assembler of these functions would be similar, every language has more or less its special functions. For console output, for file manipulation, etc. But all these functions are de-facto part of its OS API, so why is for example in C distinguished between C standard library functions and (on Windows) WinAPI functions when even printf() has to use some Windows feature, call some of its function to actually show desired text on console window, becouse the actual "showing" is done by OS. Where is the line between language functions and system API?

Now languages I don't quite understand - Python, Ruby and similar. To be more specific, I know they are similar to java and C# in term they are compiled into bytecode. But, I do not unerstand what are its capabilities in term of building GUI applications. I saw tutorial for using Ruby to program GUI applications on Linux and Windows. But isn´t that just some kind of upgrade? I mean fram other tutorials It seemed like these languages was first intended for small scripts than building big applications.

I hope you understand why I am confused. If you do, please help me sort it out a bit, I have no one to ask.

Answer 1

To be more specific, I know they are similiar to java and C# in term they are compiled into bytecode.

Ruby and Python are both interpreted languages, http://en.wikipedia.org/wiki/Interpreted_language, and their code is not translated into bytecode prior the execution.

Answer 2

So.

For your first question, the interface between the C API and the OS API is the C runtime. On Windows this is some incarnation of MSVCRT.DLL, whereas on Linux this is glibc.

For the second, the native language for most GUI toolkits is either C or C++. Higher-level languages seeking to use them require bindings which translate back and forth between the language and the C/C++ API.

For the third, these high-level languages only appear to be used for "small scripts". The simple fact is that they are far more expressive than C or C++, which means that they have equal or more capabilities than a C or C++ program while being written in fewer lines of code.

Answer 3

C is portable. That means that on different systems the assembler output for printf will be different... this is something the compiler does based on what your target system is. Write C code and compile as a Linux app and the output will be different than as a Win32 app, and also different than if you compile the exact same code for an iPhone or something like that.

Internally, the C standard libraries might wrap a call to Win32 API when you call printf, but that's not really your concern in most cases. The C standard library (like printf and other I/O for files and stuff) wraps the low-level OS or hardware code needed to do what you want.

It's worth noting the same effect happens in Java, but in a different way. At a broad level: In Java, the code you write always compiles to the same byte-code. But then when the JVM runs this byte-code, the JRE translates it to machine-specific instructions at run-time, rather than at compile-time on C.

Answer 4

If I assume this is your central question:

Where is the line between language functions and system API?

Then imagine if you will this analogy:

OS API system calls are like lego bricks and lego components.

Programming 'functions' are merely an arrangement of many lego bricks. Such that the combination results in a tool.

Thus different languages may 'arrange' and create the tool in different ways.

If I asked you to create a car with lego's, you could come up with many different designs.

Answer 5

At the bottom you have the OS kernel itself - code that runs in a special CPU mode that allows direct access to otherwise protected resources. You will never have to deal with this unless you're an OS developer.

Then comes a do-not-cross line seperating this "kernel space" from "user space". Everything you do as "normal" developer is done in user space.

The OS kernel exports a limited number of very basic functions into user space, dubbed "system calls". Open a file, read / write a number of bytes, closing the file, for example.

Because these system calls usually require some Assembler code developers don't want to be bothered with, they are "wrapped" in (usually) C code functions: open(), read(), write(), close().

Now come two sets of APIs available to the developer: The OS API, and the standard language API.

The standard language API provides functions that can be used on any platform supporting the language: fopen(), fputc(), fgetc(), fclose(). It will also provide higher-level functions that make life easier: fprintf(), for example.

The OS API provides its own set of functions. These are not portable to a different operating system, but might be more intuitive to use, or more powerful, or merely different. OpenFile(), ReadFile(), WriteFile(), CloseFile(). Again, higher-level functions might be available, i.e. PrintLn().

The two sets of functions might partially rely on each other, or make system calls directly, but that shouldn't bother you too much. You should, however, decide beforehand which set of functions you will want to use for your project, because mixing the two sets - while not a mistake in itself - opens a whole new can of worms (i.e., potential errors).

Answer 6

C's printf() is a wrapper. You can use it and compile your code under any OS, but the resulting machine code will be different. In Windows, it might call some function inside the Windows API. In Linux, it will use the Linux API. You ask why is the Windows API distinguished. That's because, if you're programming for Windows, you can use it to do some OS-specific things like create GUIs, manipulate console text instead of just printing, asking for OS resources, and stuff like that. An API like that exists for Linux and Mac (and I guess all the other OS's) too, and they let you do more or less the same things. Unlike printf(), though, they are not portable.

You ask what is the line between language functions and the system API. The language functions simply call the OS's API. You can call these yourself, but then you won't be able to compile your code on different systems.

Python and Ruby (and some others) are interpreted. They are compiled to bytecode behind the scenes, but all the user sees is that double-clicking the source file will run it. No need to compile. That means, obviously, that they're slower than compiled languages. However, their dynamic nature makes for faster development, since you usually need less code to do the same thing (I said usually).

That doesn't mean these languages can't be used for "big" applications: There are GUI libraries for them. That's because these are general purpose languages, unlike some others like Bash.