There are only two kinds of languages: the ones people complain about and the ones nobody uses.
— Bjarne Stroustrup

JavaScript is the new C. Similar claims have already been made, but not only do I want to claim that JavaScript is the new C, I also claim that this is not as bad as some people might think.

Now, what most people agree upon, and what might be the reason for the existence of emscripten, is that JavaScript is widespread. Most computers will somehow support it. Is this a coincidence?

It is my observation that a programming language spreads only if it sucks sufficiently, but not too much, and has a single advantage. PHP sucks, but it doesn't matter: It was easy to deploy simple web applications with PHP. C++ sucks, but it is fast, a bit more abstract than and mostly compatible with old C code. Java sucks, but it was the first really practical and portable GUI framework, and the first really widespread web plugin, even before Flash. And of course, we don't have to talk about why C sucks, but its great advantage is its pointer arithmetic and that it can be used as a portable typed assembler.

On the other hand, looking at Haskell, I know many fanboys, but I also talked to people who hate this language or are at least not interested in it. For some people, it sucks too much, while for some people, it fits perfectly — I think this is a general pattern: The broader your audience, the worse your fit for an individual problem. And by evolutionary processes, while the languages that only fit a specific audience will stay inside that audience, the languages that fit all needs somehow will spread, especially if they happen to have one feature that makes them distinct from everything else.

And I think that this is the case with JavaScript. Many programmers appear not to like it much, but it gets most of the jobs done, and it runs everywhere, and it is trivial to deploy - the one feature that makes it distinct from everything else. Yes, C can be compiled for every platform, but deploying applications to people is a lot harder than just telling them to follow your link.

So, JS has many things that make it hard to use. I can totally agree with that. Its possibility to add stuff to objects at will, and just default everything to undefined until something bad happens, is annoying, for example. But so is C: A simple off-by-one-error in an array access can have consequences at a completely different part of the code, that is why there are frameworks to debug and test code. C and C++ use a type system to cope with these problems to some extent. JS does not enforce this, but there is a framework that allows you to do so.

That is pretty much the way it is done in Lisp: You can add type annotations to make the code more efficient and easier to debug, but you do not have to. Not adding type information can be extremely useful in the cases when the actual types are not clear from the beginning ("prototyping") and for small code snippets and simple hacks. Every larger project should utilize types. I would even argue that they should use dependent types, but this is (mostly) tightly coupled with purely functional programming.

By the way, this is not the only parallel to Lisp. And while many Lispers will probably object to JS being a Scheme in C clothes, there is some truth in this: JS has a comparably simple data serialization format (almost as simple as Lisp's), and it has runtime compilation of Strings – which can be used to build a macro system and local domain specific languages. There are even REPLS for JavaScript.

A main difference to Lisp dialects is that it has a richer Syntax that is closer to the commonly used programming languages nowadays, and (except for Common Lisp) it is more complicated to implement, therefore not prone to the Lisp curse.

You can work with it as you would with C/Java and basic structs, but you can as well implement algebraic types. It is probably not particularily good at eiter of these jobs, but also not too bad – it gets the job done. And like Java, it gets the job done without offering too much space for security critical bugs (even though there are things like XSS exploits, of course).

The problem with Java is, that it has the repute of being slow and memory hungry. In my opinion, this was the main disadvantage of all similar languages over C and C++: They are not "on the metal". I would argue that neither is C (and especially C++), but the correspondence to the underlying machine is more direct. JS still has the same problem – even though the JS engines are doing a very good job – but there is a new way people try to address it: Asm.js. It is amazing how fast stuff becomes, and how easy it is to embed it into other JS code. As an example, here is a probabilistic approximation of a Sierpinsky-4-simplex, written mainly in asm.js (notice that you can drag the zero-point and the endpoints of the four axes with the mouse):

On Firefox 36, this still lags a little, but the reason seems to be the rendering engine rather than JS. On Chromium and most WebKit-based browsers, this has no lag at all. Look at the code: it is a portable assembler that runs on every relevant platform. It is compatible with a lot of "legacy code" through emscripten - a killer-feature of C++. And it can be embedded in a programming language with already installed bindings for almost everything, especially, for many things that users get in touch with now. While other languages still bother with libraries for accessing and parsing websites, files, the user's configuration, networking, everything that really matters to most users can be done with JS. There is an API for binary file access, a preliminary API for push notifications, APIs for 2d and 3d graphics, realtime communication.

Of course, I am not saying that C will completely vanish. It did not vanish in favor C++, it did not vanish in favor of Java, and it will not vanish in favor of JavaScript. The Linux Kernel is still written mainly in C, and I do not think that this will change. But the design of shared libraries still bases on C mostly, and the standard library of C is the only thing that is usually taken for granted. My guess is that an increasing number of libraries and other languages will target embeddability in JS rather than C.

Furthermore, I want to make clear that I do not like JS, especially as it is often used superfluously on bad websites, or breaking originally good websites. But remember, we could have ended up with Visual Basic Script. Or CFML. Or XSLT.

External Content not shown. Further Information.

Es wird Ʒeit mal wieder etwas auf deutſch ʒu ſchreiben, ʒumal mir kein Analogon in der engliſchen Sprache bekannt iſt. Es geht um einen ganʒ beſtimmten Neologiſmus, naͤmlich „jein“, manchmal auch „jain“ – offenbar eine Miſchung aus „ja“ und „nein“. Es ſcheint irgendwie ein trend ʒu ſein, das in Chats inʒwiſchen ʒu benutʒen.

Nun habe ich generell gelernt, offen gegenuͤber neuen Trends ʒu ſein. Wurde ich am Anfang meiner Schulʒeit noch genoͤtigt, Texte von Leuten ʒu leſen, in denen ſie ſich daruͤber aufregten, daſs es jetʒt Angliʒiſmen wie „cool“ gaͤbe, die man korrekterweiſe ja „kuhl“ ſchreiben muͤſſte, entwickelte ſich dann eine Abneigung gegenuͤber Internetkuͤrʒeln wie „LOL“, und es kamen Buͤcher wie „Der Dativ iſt dem Genitiv ſein Tod“ heraus. Oh, und nicht ʒu vergeſſen, wie viele traͤnen ſind gefloſſen wegen der Rechtſchreibreform⸮ Und wie viele Leute weinten dem ſcharfen S nach, das ja angeblich abgeſchafft wurde⸮ Ein Geruͤcht, das ſich uͤbrigens tapfer ʒu halten ſcheint, dabei haben wir inʒwiſchen ſogar ein großes ẞ, alſo mehr als vorher. Und wie viele Leute trauern noch heute dem rhetoriſchen Frageʒeichen nach⸮ Alles eher unintereſſant fuͤr mich. Ein biſſchen nerviger finde ich da dann, daſs man Anfuͤhrungſʒeichen nutʒt, um Dinge hervorʒuheben. Und Deppenleerʒeichen ſind auch irgendwie unſchoͤn. Und was ich im Grunde garnicht leiden kann iſt es, „nen“ ſtatt „ein“ ʒu ſagen, denn dies iſt nicht einmal eine Abkuͤrʒung. Dennoch, Sprache entwickelt ſich. Was will man alſo machen⸮

Jedenfalls nutʒe ich durchaus auch gerne moderne Kuͤrʒel wie „-v“, um ausʒudruͤcken, daſs ich gerne mehr wuͤſſte. Beſonders haͤufig benutʒe ich dieſes Kuͤrʒel, um auf „jein“ ʒu antworten. Und hier wird klar, warum ich dieſes Wort nicht nur haͤſſlich ſondern auch unhoͤflich finde: Es ſagt uͤberhaupt nichts aus, außer, daſs man wohl irgendwie teilweiſe etwas richtiges geſagt hat, und teilweiſe nicht. Es bedarf aber immer weiterer Erklaͤrungen. Wenn dieſe nun immer prompt folgen wuͤrden, waͤre es nicht mehr als ein nerviges Fuͤllwort. Dummerweiſe ſcheinen diverſe Menſchen davon ausʒugehen, daſs ihr „jein“ fuͤr ſich ſtehend in irgendeiner Weiſe hilfreich ſei, ʒumindeſt muſs man ſie nicht ſelten auffordern, genauer ʒu werden – „-v“ eben. Ob man dann eine ſinnvolle Antwort kriegt iſt die Frage; nicht immer jedenfalls.

Freilich iſt niemand im Ʒwiſchennetʒ verpflichtet die eigenen Fragen ʒu beantworten. Aber wenn man ſowieſo nicht vorhat, dies ʒu tun, woʒu dann mit „jein“ antworten? Und wenn man antworten will, wieſo dann nicht gleich ſinnvoll? Wenn man auſdruͤcken will, daſs man eine Antwort geben will, die nur etwas laͤnger dauert, kann man auch kurʒ „moment…“ ſchreiben, oder – wie ich es gerne mache – den Satʒ anfangen und an einer Stelle mit „…“ unterbrechen, an der klar iſt, daſs noch mehr kommt.

Wie dem auch ſei: Bitte hoͤrt auf, dieſes graͤſſliche Wort ʒu benutʒen!

Did you know that LaTeX indents all paragraphs, except for the first one in a section? Combined with the uselessness of \nopagebreak, this gave me headaches today. I wanted LaTeX not to break the page at a certain point, because the line after it broke was introducing the formula, which was then on the next page. And somehow, all possibilities failed, except the sledgehammer that always works: a minipage.

So I used a minipage. The problem with minipages is that they seem to be actually considered as pages. And therefore, my paragraph was the first paragraph on this page, which is why LaTeX did not indent it.

Of course, explicitly using \indent was also useless. Because LaTeX knows best. And of course, there is a package for that.

I ended up with ... rephrasing my document. And I was wondering: Why do so many people let themselves control by this F60.5-religion?

I have a new toothbrush. It is a fancy new electric toothbrush that has bluetooth support. Which it needs as much as a nuclear power plant needs wings. Anyway, additionally, I can use it as a lamp: It has an annoying blue light that blinks when it is loading.

It seems that engineers like to put lights on everything they build. I could not find a switchable power strip that does not have a lamp indicating that it is on. The cable of my laptop has a blue light to indicate that it is plugged in.

And as a special feature, they like to let these lights blink. My external screen has a blue light when it is on, which blinks when the screen is in standby mode. On the aforementioned laptop, there is a light that indicates when it is on, and slowly blinks when the computer is in standby mode.

Yes, these are mostly LED lamps that do not consume a relevant amount of energy (or do they?), but they are just annoying, especially when you need to sleep in a room where they are.

Please, dear engineers, don't add lamps if it is not absolutely necessary, and if it really is, do not make them blink.

Kurzgeschichte - (C) 2015 Christoph-Simon Senjak

An der Rezeption:

Peter: Hallo. Mein Name ist Peter Sukral. Mir wurde gesagt, dass sich mein Bruder in dieser Klinik befände.

Empfangsdame: Ich bräuchte seine volle Bezeichnung.

Peter: Jonathan Valentina Sukral.

Empfangsdame: Er untersteht Doktor Roggenkist. Den gang runter, rechts. Vorsicht, die Gravitation ist etwas falsch justiert an einigen Stellen, es gab heftige Stürme.

Peter: Ja, die Aktivität der Sonne hier ist tückisch. Auf wiedersehen.

Peter läuft den Gang hinunter, kommt in einem Wartezimmer an, und setzt sich zu den anderen Leuten dort. Ein wartender Mensch spricht ihn an.

Mensch: Sie kenne ich doch irgendwoher.

Peter: Ach ja?

Mensch: Ja, ich habe Sie doch erst neulich gesehen.

Peter: Gut möglich.

Mensch: Aber es fällt mir nicht ein.

Ein Lautsprecher ertönt: Herr Sukral bitte.

Der Mensch schaut erstaunt. Peter Sukral ist einer der bekanntesten Wissenschaftler dieser Zeit, und die vermeintliche Bekanntheit kam wohl von einem Bild aus irgendeiner Nachrichtenquelle.

Peter läuft in das Besprechungszimmer.

Dr Roggenkist: Nach so vielen Jahren sehen wir uns wieder.

Peter: Leider zu keinem freudigen Anlass.

Dr Roggenkist: Ich weiß. Schlimm, das mit deinem Bruder.

Peter: Menschen sterben. Daran kann man wenig ändern.

Dr Roggenkist: Das vom drittältesten lebendigen Menschen zu hören ist schon ironisch, nicht wahr?

Peter: Ich mag alt sein, aber ich sehe es als Glück, dass ich noch lebe, und nicht als Notwendigkeit.

Dr Roggenkist: Dein Bruder offenbar auch nicht als Glück. Mal eben nach UY Scuti zu fliegen, durch vermintes Gebiet.

Peter: Mein Bruder ist auf die UY-Scuti-Expedition gegangen, weil er nicht mehr leben wollte, aber wenigstens sein Leben für etwas nützliches hergeben wollte. Er hat den Leuten humanitäre Hilfe gegeben. Die Lebenserhaltung auf den Stationen funktioniert zu einem großen Teil nicht mehr, aber dank ihm hat man zwei Arkologien wieder aufbauen können.

Dr Roggenkist: Jetzt ist er jedenfalls tot. Er hat was er wollte.

Peter: Nein. Hat er nicht. Sein Testament ist da eindeutig. Sein ausdrücklicher Wunsch war es, dass auch neurale Musterkopien von ihm gelöscht werden.

Dr Roggenkist: Das ist nicht der Wunsch von ihm, sondern der Wunsch von seinen Depressionen.

Peter: Kann ich ihn sprechen? Alleine?

Dr Roggenkist dreht Peter eine Computerkonsole zu.

Dr Roggenkist: Hier bitte. Ich kümmere mich derweil um andere Patienten. Wenn du fertig bist, melde dich.

Dr Roggenkist verlässt den Raum. Peter drückt einen Knopf an der Konsole.

Peter: Jonathan?

Jonathan: Wer ist da?

Peter: Ich bin es, dein Bruder. Peter.

Jonathan: Wie gut, du hast meine Nachricht bekommen. Sind alle anderen Kopien gelöscht?

Peter: Es tat mir im Herzen weh, aber ich bin deinem Wunsch nachgekommen. Meines Wissens bist du hier die letzte intakte Kopie.

Jonathan: Von all den Orten wo man meine Kopien aufbewahren hätte können wird ausgerechnet die Aldebaranklinik ausgesucht. Mit den strengsten Gesetzen.

Peter: Aldebaraner waren schon immer konservativ. Und nach ihrer Gesetzesauffassung bist du nicht tot, solange es eine funktionierende Kopie gibt.

Jonathan: Und dabei wäre es mir noch nicht einmal zu sehr zuwider, dass mein Netzplan archiviert wird, oder zu Forschungszwecken genutzt wird. Aber weiterleben müssen, ohne erkennbares Ende, in dieser Form?

Peter: Es gäbe Roboter in die man dich transferieren kann.

Jonathan: Das machen die nicht, denn dann könnte ich mich ja löschen.

Peter: Würdest du dich denn löschen?

Jonathan: Ich würde mich zumindest ausschalten.

Peter: Solange du das vorhast, wird man dich nicht gehen lassen.

Jonathan: Ich kann sie ja nicht mal anlügen. Sie haben meinen Netzplan gescannt. Sie kennen all meine Gedanken. Sie programmieren mich noch nicht einmal um. Sie lassen mich einfach weiterexistieren.

Peter: Sie sind machtlos, deinen Geisteszustand relevant zu ändern. Aber sie sind verpflichtet, dein Leben zu bewahren, und dich vor dir selbst zu schützen.

Jonathan: Ich werde meine Haltung nicht ändern, das wissen die Leute. Das weiß auch Dr Roggenkist. Was wollen sie tun? Mich bis in alle Ewigkeit vegetieren lassen?

Peter: So schreibt es das Gesetz der Aldebarankolonien vor.

Jonathan: Wir wissen beide, dass dieses Gesetz aus einer Zeit stammt, in der der Upload noch nicht funktionierte, geschweige denn die Kopie eines Gehirns. Und schon damals konservativ war.

Peter: Trotzdem ist es geltendes Recht.

Jonathan: Kannst du mir denn nicht irgendwie helfen?

Peter: Du bist alles, was von meinem Bruder übrig geblieben ist. Und verlangst von mir, dich zu zerstören. Ich frage dich, willst du nicht doch noch einen Versuch starten, zu leben? Du hast so viel Gutes getan. So viele Leute vermissen dich.

Jonathan: Ich könnte sagen, dass ich noch mal ein paar Jahre lebe. Aber sobald ich mich dort entschließe es zu beenden, wird wieder eine Kopie von mir erstellt. Wann soll das alles enden?

Peter: Ich weiß es nicht. Wie dem auch sei, ich habe mich natürlich informiert.

Jonathan: Mit welchem Ergebnis?

Peter: Es ist verboten, dich zu löschen, oder abzuschalten. Jeder Versuch wird bestraft. Daran können wir nichts ändern.

Jonathan: Das heißt ich muss weiterleben?

Peter: Ja. Man darf dich noch nicht einmal relevant umprogrammieren. Es muss sichergestellt sein, dass dein Programm prinzipiell weiterläuft. Was allerdings nirgends festgelegt ist, ist, wie schnell es laufen muss.

Jonathan: Was schlägst du vor?

Peter: Wenn wir mit jeder Sekunde die Ausführungsgeschwindigkeit deines Programmes halbieren, wirst du zwar ewig weiterleben, aber es wird sich für dich anfühlen wie zwei Sekunden.

Jonathan: Was ist nach diesen zwei Sekunden?

Peter: Nichts. Du wirst diesen Zeitpunkt aus deiner Sicht nicht erreichen.

Jonathan: Also werde ich doch ewig weiterleben?

Peter: Ja. Aber es wird sich nicht so anfühlen. Das ist der Trick. Ich kann dir anbieten, mich dafür einzusetzen. Versprechen kann ich nichts.

Jonathan: Gut. Ich bin damit einverstanden.

Peter läuft aus dem Zimmer, und trifft dort Dr Roggenkist, und signalisiert ihm, dass er fertig ist.

Dr Roggenkist: Seid ihr zu einem Ergebnis gekommen?

Peter: Ich habe eine Lösung gefunden, die vielleicht funktioniert.

Dr Roggenkist: Es gibt keine Heilmethode, und Eingriffe in das Programm sind verboten. Ich hatte gehofft, du würdest ihn zum Weiterleben motivieren können.

Peter: Nein. Mein Bruder ist tot. Dies ist nur eine Kopie von ihm, die künstlich am Leben erhalten wird, um weiter sinnlos zu leiden.

Dr Roggenkist: Das klingt nach esoterik. Das kann nicht deine Überzeugung sein.

Peter: Ist es auch nicht. Aber es ist die Überzeugung meines Bruders, und er hat ein Recht darauf.

Dr Roggenkist: Nicht im Aldebaran-System. Was auch immer man davon halten mag.

Peter: Es ist eine formaljuristische Frage. Das ist mir bewusst. Und ich fand eine Lösung, die juristisch vermutlich erlaubt ist.

Dr Roggenkist: Du fandest also eine legale Möglichkeit, deinen Bruder sterben zu lassen.

Peter: Er ist der Überzeugung, bereits tot zu sein. Alles andere ist nicht unsere Sache.

Dr Roggenkist: Das ist er nicht. Aber gut, du musst wissen, was du moralisch vertreten kannst.

Peter: Glaubst du, es fällt mir leicht? Aber ich respektiere seinen Willen.

Dr Roggenkist: Ich bin als Arzt erstmal nur dem Gesetz verpflichtet. Aber ich kann und muss dir sagen, was ich davon halte.

Peter: Ich nehme es zur Kenntnis.

Dr Roggenkist: Was ist also dein Vorschlag?

Peter: Können wir jede Sekunde das Programm meines Bruders herunternicen, sodass es nur noch halb so schnell läuft?

Dr Roggenkist: Im Grunde können wir Verlangsamungen beliebig durchführen, je nach Ermessen. Aber hilf mir auf die Sprünge. Wieso hilft ihm das?

Peter: In der ersten Sekunde würde er eine volle Sekunde erleben. Die zweite Sekunde würde sich für ihn wie eine halbe Sekunde anfühlen. Die dritte Sekunde wie eine viertel Sekunde. Und immer so weiter. Die Gesamtzeit die sein Programm laufen würde wäre unendlich, aber sie würde sich für ihn wie zwei Sekunden anfühlen.

Dr Roggenkist: Eine geometrische Reihe. Ich erinnere mich. Aber mir ist nicht ganz klar, was dann passiert.

Peter: Er wird ewig leben, aber sich nicht so fühlen.

Dr Roggenkist: Mir ist dies irgendwie nicht so klar. Der Gedanke ist verwirrend.

Peter: Das ist er.

Dr Roggenkist: Bist du dir sicher, dass du unsere Juristen davon überzeugen kannst? Die verbieten normalerweise alles, was sie nicht verstehen, vorsichtshalber.

Peter: Aldebaran ist konservativ. Aber wo kein Kläger ist, da ist auch kein Urteil.

Dr Roggenkist: Du deutest an, dass ich es einfach durchführe, ohne es vorher juristisch zu überprüfen?

Peter: Exakt.

Dr Roggenkist: Das kann mich meinen Job kosten!

Peter: Es könnte dich auch deinen Job kosten, einer ausdrücklichen Bitte eines Patienten nicht nachzukommen. Es ist Unwahrscheinlich, dass das passiert. Selbst auf Aldebaran ist man inzwischen so weit, dass man nicht alles vor Gericht tragen muss.

Dr Roggenkist: Und was ist, wenn ich nicht mehr hier Arbeite? Was ist, wenn ich sterben sollte?

Peter: Dann gibt es eine Verfügung. Die müsste man erst mal anfechten, und es ist zu hoffen, dass Aldebaran auch irgendwann schlauer wird. Außerdem ist das unwahrscheinlich, denn du wirst sicherlich ständig Sicherheitskopien von dir erstellen. Und du kannst die Aufgabe weiterreichen.

Dr Roggenkist: Ich bin immernoch skeptisch.

Peter: Ich erinnere dich daran, wie du auf die medizinische Akademie von Neuheidelberg gekommen bist.

Dr Roggenkist: Ja, ohne deine Fürsprache wäre das unwahrscheinlich gewesen. Gut. In Anbetracht der Tatsache, dass in jedem anderen Fleck des Weltraums kein Problem bestünde, entspreche ich deiner Bitte.

Jonathan: Danke.

Dr Roggenkist beginnt zu tippen

Dr Roggenkist: Das bleibt aber bitte unter uns. Wenn erstmal klar wird, dass so etwas geht, wird die Idee wohl Schule machen. Ich habe mehrere Milliarden an Depressiven in diesem Server.

Jonathan: Und die haben leider keinen so einflussreichen Bruder, diesen Wahnsinn zu beenden.

Dr Roggenkist: Wie dem auch sei. Ich habe die Verlangsamung vorbereitet. Wenn auf dieser Tastatur Enter gedrückt wird, wird sie beginnen. Ich werde die Taste aber nicht drücken.

Peter: Ich drücke sie. Hast du noch letzte Worte, bevor ich drücke?

Jonathan: Vergesst nicht die Zombies von Aldebaran.

Daraufhin drückt Peter Sukral die Entertaste.

External Content not shown. Further Information.

The general state of instant messaging is horrible. Google - once the most preferrable commercial XMPP provider - dropped federation, and some people say that they even plan to shut down the XMPP access at all. Facebook already announced that it will do so, but at least provides an open API as alternative, for which there is already an experimental BitlBee extension. Skype dropped its public API a while ago. So while the Linux folks keep building their new ivory tower, all the achievements of the last decades seem to slowly vanish.

Anyway, so there we are, at a time when one must be glad if the "non-computer-people" regularily use Facebook instead of Skype chats. But some do, and since I hate the original Skype client, I spent a few hours in search for alternatives to the public API. Even though I did not yet write anything really usable, I'd like to share what I found out, to give other people inspiration, and as notes for myself. Everything mentioned here is experimental. Furthermore, I am in no way affiliated with Skype or Microsoft.

In theory, it should be possible to access Skype chats via MSN. This page has a nice summary about MSN servers that work. However, though I can manage to log in, my Skype contacts are not shown, and I do not get Skype messages. Not sure what I am doing wrong.

Skype chats can now be accessed via Outlook's Webinterface. It would have been nice to use this webinterface with edbrowse, but it does not even load. It is probably possible to reverse engineer this interface. But then again, web interfaces can be changed, and obfuscated. However, this webinterface seems to use MSNP24, and people are trying to reverse engineer it. This is probably the most promising approach. On the other hand, it is probably violating some terms of use.

My approach was different: I was trying to use the official client, as one would have done with the old public API. I was trying to use AT-SPI, specifically pyatspi2, since orca appears to work well with Skype. I used the accerciser tool to examine Skype.

Skype uses 32 bit Qt, so be sure to have qt-at-spi for that architecture. Under x64 Ubuntu, the package is called qt-at-spi:i386. Make sure that QT_ACCESSIBILITY=1 for your session. If accerciser shows you an entry for Skype, you know that you did it correctly.

The following script works fairly reliable for me and shows the contacts in my contact list. I am using the client version 4.3.0.37. Furthermore, this only works with the English language setting, and the window should not be iconified.

# -*- coding: utf-8 -*-
import pyatspi
import time

reg = pyatspi.Registry
skype = None

def getElementBy(parent, prop):
    for i in range(0, parent.getChildCount()):
        if prop(parent[i]):
            return parent[i]
        else:
            child = getElementBy(parent[i], prop)
            if child != None:
                return child
                return None

for i in range(0, reg.getDesktopCount()):
    d = reg.getDesktop(i)
    for app in d:
        if app.name == "skype":
            skype = app

if skype is None:
    print("skype is None")
    exit (-1)

# the main window is unique (hopefully)
mainwindowmenu = getElementBy (skype, lambda x: x.get_role_name() == 'menu bar')
if mainwindowmenu is None:
    print("mainwindowmenu is None")
    exit(-1)

contacts = getElementBy(mainwindowmenu.get_parent(),
                        lambda x: x.name =='Contacts')
if contacts is None:
    print("contacts is None")
    exit(-1)

for i in range(0, contacts.getChildCount(), 7):
    if i != 0:
        p = contacts[i].get_position(0)
        print(contacts[i].name + " → (" + str(p.x) + ", " + str(p.y) + ")")

The less reliable part now is actually sending messages. If the contact list is in the foreground, and sufficiently large to show all contacts, then you can send double clicks on the contact you want to chat with, to open the chat window

p = contacts[14].get_position(0)
reg.generateMouseEvent(p.x+2, p.y+2, pyatspi.MOUSE_B3D)

As I said, this is not really reliable, it is very fragile. Maybe on an own dedicated X-Server with a huge virtual screen, this could be used. To actually set the message that is to be sent, I had to hack a bit: Skype sometimes keeps other message text boxes in the background. However, their size is always zero. The following is very bad style, as it creates a busy infinite loop if something goes wrong. But as a proof-of-concept, it is ok, I guess.

msg = None
while msg is None:
    msg = getElementBy(skype,
                       lambda x: (x.name == 'Send a message') and
                       (x.get_size().x != 0))
    time.sleep(.2)

msg.set_text_contents("This is a test")

So far so good. Sometimes Skype crashes when doing this. But mostly it works. It brings the text window to front. To actually send the message, we can send the Return key:

reg.generateKeyboardEvent(36, None, pyatspi.KEY_PRESSRELEASE)

Another way of sending keystrokes and even resizing and moving windows is xdotool(1), which could come handy when using this method to send messages.

To receive messages, it is probably the easiest to just poll the sqlite database main.db in ~/.Skype/, which is in a subdirectory named after the account name. It has a table "Messages". To get the timestamp of the last message (which you probably want when starting your script)

select MAX(timestamp) from Messages;

then, assuming it was 1421498680, messages can be queried using

select id, author, body_xml from Messages where timestamp >= 1421498680;

In summary, try to convince your friends to use Facebook if they really want a commercial chat provider. Run a good XMPP server (with auto-ping and low tcp keepalive timeout and XEP-0313 or even XEP-0136 I'll probably do so when jessie gets stable), and offer them accounts. And if you really have to use Skype, face the evil!

Update: This project seems nice.

I have written before about dnsmasq and pxe-booting. I was setting up an old thin client as a print server, which could not boot from usb sticks. Therefore, I needed to run a pxe-server to install debian on its internal memory.

So here is a short description. This is more a "note-to-self", and especially, this kind of stuff keeps changing the way it works from now and then. But at least, sharing it with the world might make it easier for you to find a solution.

This setup is not for permanently running servers. It is for connecting a single other computer to a laptop via ethernet, booting it, and installing.

I want my computer to route from the interface eth0 to wlan0. wlan0 is managed by network-manager. For eth0, my interfaces(5) contains

iface eth0 inet static
address 192.168.222.1
netmask 255.255.255.0

Make sure to restart your entire network setup, including network-manager, otherwise, network-manager might try to keep setting up eth0. (I am not sure whether one can do this with network-manager too.)

Furthermore, the sysctl(8)-setting net.ipv4.ip_forward must be set to 1. I put that setting into my sysctl.conf(5) and reloaded, but it can be set directly, so it is not persistent. To make eth0 a NAT to wlan0, I run

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

My working directory is /home/christoph/software/pxesetup. In this, I have a file dnsmasq.conf with the contents

interface=eth0
bind-interfaces
dhcp-range=eth0,192.168.222.1,192.168.222.128,12h
dhcp-authoritative
enable-tftp
tftp-root=/home/christoph/software/pxesetup/tftp/
dhcp-boot=pxelinux.0
listen-address=192.168.222.1

Be careful to change the interface name accordingly: You will be running an authoritative dhcp server, do not do this in networks you do not own. Now we need the pxelinux files from Debian, which can (at the time of writing this) be found here and here. Create /home/christoph/software/pxesetup/tftp, and put pxelinux.0 in that directory, and uncompress the tarball into it (it creates a subdirectory debian-installer). Do a chmod -R a+rwx on that directory - server-installations should set the permissions more carefully, but for one-time-installations with my own laptop, it is sufficient.

Finally, run

sudo dnsmasq -dC /home/christoph/software/pxesetup/dnsmasq.conf

connect your client and let it boot via PXE. I hope this helps. At least it will help me to remember my setup. Comments and corrections are welcome, just send me an e-mail.

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.

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