Wed, 31 Dec 2014 20:55:10 GMT
Happy new year everybody. Sorry, no time for a Comic and Link List this time. But a lengthy text:
I always liked intensive, or even heated discussions about programming languages. It is an interesting topic, and there are many positions. We are in the information age, programming is the modern alchemy, you will hardly find any profession that does not somehow depend on computers, even if it's not technical at all. In a lecture, a professor once said that was is a misconception that programming languges are for computers, they are for humans. Indeed, the computer's language consists of the well-known "bits and bytes", even assembler code is usually a lot harder for the computer to understand, before its conversion to binary code. Programming languages are a compromise: Human minds work different than computers (at least at the time this is being written - considering the technical developments of the last 50 years, I always try to be careful with predictions), and programming languages are a trade-off. And there are several opinions about the details of this compromise.
I myself like Common Lisp and (Chicken) Scheme, because of their level of abstraction. Especially, consistent abstraction. I do not like C++, because many abstractions are not consistent in the sense that they really always work.
There are so many opinions, and I like discussions about them, but at some point I noticed that this is a never-ending story. There will always be new programming languages, new libraries, and new issues. And they will all be similar, except for details - details that one only gets to know by actually using the language. It is a good thing to have a "main" programming language. So I tried to be pragmatic. Common Lisp is nice, and it has a great community, but the lack of maintained libraries made every project tedious.
At first, I tried to make JavaScript this new "main" language. JS is fast and highly portable. Unfortunately, it seems that one goal of JS is to hide errors. Debugging array-bounds-errors felt like debugging raw C code, while the speed was rather comparable to Python.
Then I tried Java. Java was the second programming language I ever learned. Java was ok. I could say a lot of bad things about Java, but Java is widespread, and has a huge standard library, and reaches a high level of portability. But this high level of portability comes at a price: Java has an own ecosystem, and as soon as you need external dependencies, things get more complicated. For me, this was the case with BRLTTY's braille API. It is possible to run it under Windows, I guess, but it is not as easy, at least I could not manage to run it. There goes portability.
The next option was just using raw C. But then again, I wanted to define settings with default values. The "Unix-Way" would have been to create a hidden folder with a configuration file. But then I would need a parser for that file, and implement a lot of functionality that has probably been implemented thousands of times. I found GSettings, which is part of the GLib. I implemented it, it worked. But while the GLib is portable, the list of supported platforms of GTk is tiny, compared to the list of supported platforms of Qt. And as I use KDE anyway, I tried it.
Qt is a programming language, disguised as a C++ library. It takes the few good parts of C++ and uses them to create a real object system with signals and slots. With C++11's lambda forms, C++14's constexprs and Qt's parent-child-system for memory management, it almost feels like C++ was a high-level-language. Qt might be bloated, but other runtimes are bloated too. At least Qt has an armada of commercial programmers, and will therefore probably stay portable and downward-compatible. And that is what I care about most.