Panel 1: A person pointing to an active volcano is shown, shouting "Aahhh... run!" -- Panel 2: People run in panic, some are squished by rocks falling from above, some are burning. Another person is shown, saying "What's that?" -- Panel 3: The person from panel 2 is shown, standing in front of a sign saying "Volcano". Under the gap between V and o, there is a red wavy underline. The person sais "Oh my God... bad kerning", because the gap should be kerned.
(C) 2015 Christoph-Simon Senjak and Kroki.

External Content not shown. Further Information.

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos:

Quotes:

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.

Panel 1: An elderly man sits at a desk, on the desk is a tomato and a toothbrush. He holds up a small package. Subtext: "The daily stress as an asylum seeker can wear your teeth out. Our team from the Prof Goodest institute created a new adhesive cream to specifically fit these needs." -- Panel 2: Two neonazis and two asylum seekers are shown. One neonazi kicks one asylum seeker in the face, the other neonazi hits the other asylum seeker with a baseball bat. Subtext: "As you can see in our test, both asylum seekers are exposed to the usual hazards. Nuri wears a conventional adhesive cream. Bassam wears the new Polydent Asylum Plus." -- Panel 3: A new scene is shown. The two asylum seekers are shown. The left one sits in a wheelchair, and wears a body cast. His mouth is open, but only few teeth are left. The right one wears a cervical collar and walks on crutches. His mouth is open, only one tooth is missing. Subtext: "The result speaks for itself." -- Panel 4: A close-up view on the package is shown, it sais "Polydent Asylum + dental adhesive. ClustMillerTall."
Disclaimer: I thought about whether I should really publish this comic, as my special kind of humor could be misunderstood and give a wrong impression about my attitude. I do not want to offend anyone, I just hope to be thought-provoking.

So. Schauen wir uns erstmal meine Prognosen für 2014 an. - Mehr Überwachung könnte man so sehen, wenn man sich den NSA-Skandal anschaut. - Propleme mit den Flüchtlingswellen kann man wohl sagen. - Keine Amnestie für Edward Snowden. - Die Prognose zu Michael Schumacher war wohl zutreffend. - Hyrule Warriors wurde veröffentlicht. - Firefox OS hat bisher keine weite Verbreitung gefunden. - Emscripten glaube ich auch nicht. - Exoskelette sind noch nicht in Serie, das mit dem Rückenmark scheint immer Wahrscheinlicher zu sein, aber noch geht es nicht generell. - Die Sommerlochseuche war Ebola.

Und nun, ein paar vorsichtige Prognosen für 2015.

Politik:

  • Weitere PEGIDA-Demonstrationen, weitere brennende Flüchtlingsheime, das Übliche halt.
  • Die Folterenthüllungen der USA bleiben ohne Folgen.
  • Die Krim bleibt besetzt, die Sanktionen bleiben bestehen.

Kunst und Populärkultur:

  • Eine neue Star Trek Serie mit neuer Crew wird angekündigt.
  • Nintendo wird eine neue große Konsole ankündigen, auf der ein Android-System läuft.

Software und Technik:

  • Gentoo Linux wird SystemD einführen. SystemD wird auch auf Android portiert.
  • Wayland und Mir werden sich nicht durchsetzen, X11 bleibt der de facto Standard für Grafik unter Linux.
  • Smart Watches werden sich noch nicht durchsetzen.
  • 3D Drucker werden sich noch nicht durchsetzen.

Currently, I am trying to get familiar with Qt and C++. It makes C++ endurable, especially when combined with the new stuff from C++11. Basically, I don't want to tilt at windmills anymore - I wand to get some of my private projects finally finished. Still, this does not imply that I do not have an opinion about software.

And one strong opinion I have is that I usually prefer good terminal applications to GUI applications.

Let me first explain why I prefer plain text to "rich text", and why I prefer text-oriented software (like LaTeX) to graphic-oriented software (like LibreOffice). Don't get me wrong, LibreOffice is a decent piece of software. But like its competitor (MS Office) it makes people believe that "WYSIWYG" actually works, and even that their formatting will be conserved between different versions of the software. I can remember when I once had to fill in a list of a .doc file, which looked completely garbled, because the person I got it from had a font that I did not have installed, and another font was silently substituted. And more than once I saw people getting confused because the documents they printed omitted some characters, or changed their size. Ideally, formatting would not suffer from such minor changes, but in practice this is an extremely hard problem. In LaTeX, you will be aware of the font you used, and of all the packages and ressources you included. You will be aware of the formatting you use, because you have to type commands to do it. And you will be aware that there is a difference between your abstract document and the thing that is actually printed. Anyway, if it is sufficient, I prefer fixed-width ASCII or UTF-8 text. It consumes less memory, it is harder to garble, it has less clutter, and it is simple. In some cases, graphic is useful, like for mathematical formulae. But typesetting it is usually still easier with a text oriented format.

Text oriented formats can be edited using terminal applications, and plaintext can even be viewed in the terminal. As I said, I like good terminal applications, where "good", of course, means "good according to my opinion", and especially, just because an application is not good does not mean that it is bad. The problem is that there are a lot of terminal applications who share a philosophy of making it extremely hard for unexperienced users to learn. If you have to read a several pages long documentation and memorize all of the key combinations to use a terminal application, it is not "good" in the sense I mean. Even though vi and mutt might be powerful, and certainly not "bad", I still prefer emacs and thunderbird.

One of the first terminal programs I often used was the IDE of Quick Basic. Here is a screenshot:

Screenshot of Quick Basic.

The top line shows a main menu, similar to the one that can be found in many GUI applications. I opened the third item "View". The entry "SUBs..." is marked - it is currently selected. Next to the items, there are their global keybindings. And single characters of the Items are in white instead of black - these are mnemonic codes, which would be underlined in most GUIs. You can see scroll bars and a blue text field in the background. The red rectangle you can see on the text field is the mouse cursor. On the bottom line, you can see the tooltips of the selected entry. There are a lot of things done to make this UI usable for newbs. Still, it has global keybindings, so it can be used quickly by experienced people. It is not perfect, though. I don't see a reason why the scroll bars are always there and why there is an additional frame around the text field, which wastes space. Now, let me give you another screenshot:

Screenshot of the Mutt help screen.

The menu above looks like the main menu from Quick Basic, but it is not. It is just a list of some key bindings that can currently be used. This is Mutt's help screen. I cannot really say why, but many people consider Mutt "hard to use", and it is not just because you have to write a configuration file. You have to read the help file, or you will not be able to use it. There is no real "learning curve". Either you know the commands you need, or you can't use it. You cannot "explore" the program. This is the kind of UI I do not like. One can get used to it, and people who got used to it usually insist that they "like it that way". Well, having the possibility to disable a main menu and customize keybindings is a feature that good software should have. But an exploratively learnable piece of software would be nicer.

An advantage of Mutt over QuickBasic would be that it might be more accessible. QuickBasic imitates what GUIs do. But most GUI toolkits have an accessibility bridge like AT-SPI that can read out menu items. Still, both Mutt and QuickBasic can be used with BRLTTY, and probably Mutt is a little better in that case. However, not having an accessibility bridge is not an intrinsic property of terminal UIs. In theory, it would be possible as well, it just isn't implemented yet (to my knowledge). On the other hand, as far as I know, the more widely used screen readers have script support, and special scripts for many applications that would not be (well-)accessible on their own, but they can still fail with some applications - it is easy to design a GUI application to death. Parsing the output of a terminal application like QuickBasic should be possible, and with a reasonable API, it should be simple to learn to write customization scripts. So while at the current state it might be easier to write accessible applications with standard GUI toolkits, it is a lot easier to completely garble their accessibility that it is for terminal applications.

One major disadvantage of terminal applications is, of course, that they cannot show Graphics. In some cases, graphics are inevitable. Some applications like w3m use tricks to do so in a graphical environment, and there are terminal protocols that support line drawing. The obvious question one might ask then is, why use a terminal program at all. Links2 has a graphical mode which can show images and otherwise behave like a terminal: Good Websites mostly contain text with only few images, but when they use images, they either have an Alt text, or they usually have a purpose:

Screenshot of the links2 in graphical mode showing a comic from uxul.de

As long as graphics will not be used as pure design elements for applications, most of the benefits of terminal applications remain. In the case of links2, however, there is no good support of CSS and JS, which makes it almost useless for most modern websites.

Further disadvantages are not having multiple windows, no common look and feel, and often no mouse support or support for common key bindins. All of this, including an accessibility bridge, graphics and multiple windows, could in theory be changed. Especially, just because this can be done with GUIs does not mean that it is usually used to improve software.

In fact, many GUI applications could as well be terminal UIs. Many "music players", besides sophisticated design, only consist of a progress bar and a few slide rulers. Most chat clients and SIP phones could be replaced by terminal applications, and video players and video phones could be terminal applications, except for the one graphic element that shows the actual video. Many of these applications just suffer from having bloated and inaccessible GUIs.

In my opinion, terminal applications are usually easier to program, easier to reason about, clearer laid out, easier to script, and there are well-established remote access protocols (SSH, MOSH).

External Content not shown. Further Information.

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Comics/Images/Audios/Videos:

External Content not shown. Further Information.

So I wrote a simple wavefront parser using POSIX regular expressions. It suddenly stopped working, while I was trying to port the whole thing to Qt. The parser itself is not very beautiful, but it did its job well so far, so why change it?

Well, I found out the problem lies in the following line:

sscanf(mytokens[1+i], "%lf", coords+i);

The variable mytokens[1+i] contains a string that contains a float, say, -0.697203. coords is an array of float values. However, suddenly, it always contained zero. I added the following line to debug this issue:

fprintf(stderr, "%s %lf\n", mytokens[1+i], coords+i);

The output consisted of lines of the form

-0.212040 0,000000
1.092960 0,000000
-0.679962 0,000000
-0.110031 0,000000
1.123250 0,000000

I noticed that the second numbers all have a comma as separator - which is common in Germany. And my locale is set to de_DE.UTF-8. And sscanf seems to also parse according to this locale.

Running my application with LANG=C worked again.

Update:

Maybe I should have given the solution to the problem. Well, the locale is set by Qt apparently. I could set it using setlocale(3), but then I would risk clashes with other parts of Qt.

Instead, as I use C++ anyway, I used a std::stringstream, and its method imbue. A quick and dirty replacement for sscanf looked like

static void parse_double (const string& dbl, double& ret) {
    locale l("C");
    stringstream ss;
    ss.imbue(l);
    ss << dbl;
    ss >> ret;
}

Two Borg (Star Trek) are working at a central plexus. The left one sais: "I can remember, when I was at your age, plexuses were still operated by biological brains, no need for all of this fancy new technology, fewer parts that could break!" The right one thinks: "Oh boy..."

Popular Culture:

Nerd Culture:

Science, Software, Hardware:

Zeroth World:

Comics/Images/Audios/Videos:

Quotes: