Das ist paradox – Oder ist die Zeit noch nicht reif dafür?

Es gibt ja immer wieder Entwicklungen, Möglichkeiten, Wege, die sich nicht durchsetzen, nicht wahrgenommen oder nicht gegangen werden. Das hört sich jetzt tiefgründig an, ist aber ganz praktisch gemeint – nennen wir es das “Video 2000 Paradox”.

Die etwas älteren Semester haben schon eine Ahnung, was ich meine. Es geht um eigentlich überlegene technische Entwicklungen, die sich auf dem Markt einfach nicht durchsetzen können. So trat Anfang der 80er Jahre das VHS Videosystem seinen Siegeszug an und “Video 2000”, das technisch bessere Konkurrenzprodukt, war Geschichte (hier nachzulesen).

Ich möchte auf zwei ähnliche Dinge aufmerksam machen, bei denen ich Vermutungen anstellen möchte, warum diese Technologien sich nicht durchsetzen. Bei dem Videoformat Anfang der 1980er Jahre steckte natürlich viel Marketing hinter der Technik. Dieses Marketing war ausschlaggebend. Den Firmen kommt es nicht immer auf die beste Technologie an – sie wollen ihre Geräte verkaufen.

Bei meinen zwei Beispielen passt diese Erklärung aber nicht. Da kann man nur Vermutungen darüber anstellen, warum sich diese beiden Konzepte nicht durchsetzen. In beiden Fällen ist das sehr schade, denn es kann sich in zwei ganz wichtigen technologischen Bereichen ein längst überfälliger Standard nicht durchsetzen.

Das PNG Format.

Jeder, der Fotos mit einer Digitalkamera oder einem Handy macht kennt das Bildformat, in dem die Bilder als Standard gespeichert werden (abgesehen von den RAW Formaten, die Sensor-spezifisch und nicht einheitlich sind). Die Kameras nutzen als Standardformat das JPG-Format.

Dafür gibt es zunächst eine recht einfache und sehr plausible Erklärung. JPG hat sich etabliert, als das WWW immer mehr an Bedeutung gewann. Denn die ursprünglich etablierten Formate hatten große Nachteile. BMP, eine Bitmapdatei, konnte nicht komprimiert werden und das GIF Format, welches Transparenz und Animation darstellen kann, hatte nur einen Farbumfang von 256 Farben. JPG kann komprimiert werden. Und das funktioniert sehr gut – selbst bei hohen Kompressionsraten und damit kleinen Dateigrößen (war zur Zeit von 14400 Modems in den 90er Jahren ganz wichtig), wurden Bilder ansprechend dargestellt. Der große Nachteil von JPG: wenn man das Originalbild, also das nicht komprimierte Bild, nicht behält, dann ist die Kompression immer auch ein Qualitätsverlust. Möchte man eine vergrößerte Version eines JPG plötzlich benutzen, so wird man die schlechte Qualität erkennen.

Ein weiterer Nachteil: JPG kennt keine Transparenz. Entwirft man in einer Bildbearbeitung zum Beispiel ein Logo und möchte seinen Hintergrund transparent machen, weil man das Logo in unterschiedlichsten Umgebungen einsetzen möchte, dann kann man JPG vergessen. PNG lässt sich verlustfrei komprimieren, kennt den maximalen Farbumfang und kennt transparente Bereiche.
Man braucht also ein Format, das fast alle Vorteile vereint. Und das ist eben PNG. Diese Tabelle listet die wichtigsten Eigenschaften der gängigsten Bildformate auf. Die Vorteile von PNG im Vergleich zu JPG sind offensichtlich:

Format / Eigenschaft	GIF	JPG	PNG	TIFF
Kompression möglich	nein	ja	ja	nein
Kompression verlustfrei	nein	nein	ja	nein
Metadaten integrierbar	nein	ja	ja1	ja
Farbumfang	256	16,7 Mill.	16,7 Mill.	16,7 Mill.
Transparenz möglich	ja	nein	ja	nein
Animation möglich	ja	nein	nein	nein
CYMK Farbraum für Druck	nein	nein	nein	ja

Was bedeuten die Abkürzungen?

GIF –> Graphics Interchange Format
JPG –> Joint Photographic Experts Group (daher auch JPEG als gleichbedeutende Abkürzung)
PNG –> Portable Network Graphics
TIFF –> Tagged Image File Format

¹ Metadaten folgen nicht dem ITPC oder EXIF Standard

Diese Tabelle zeigt, was PNG kann – es gibt kein rationales Argument, was gegen die Ablösung von JPG als Standardformat für Bilder spricht. Für ein Format wie TIFF spricht der CMYK Farbraum, der in der Druckindustrie relevant ist. Für GIF spricht ferner die Möglichkeit, kleine Videosequenzen als Animationen in ein Bildformat zu verwandeln.  Für die Weiterverarbeitung in Druckerzeugnissen können sowohl PNG als auf JPG Dateien in CMYK Farbräume überführt werden.

Der einzige plausible Grund, warum Digitalkameras immer noch JPG statt PNG erzeugen ist in der Fußnote versteckt. PNG speichert die Metadaten nicht in Standards ab. Metadaten sind alle Informationen zu einem Bild, mit denen Bilder später in Datenbanken klassifiziert werden können. Ein nicht unerheblicher Nachteil, der aber durch eine Erweiterung des PNG Standards behoben werden könnte.

Ich jedenfalls würde mir einen Umstieg auf PNG wünschen. Es würde einige Arbeitsschritte bei der Verwendung von Fotos, insbesondere auf Webseiten, vereinfachen oder sogar überflüssig machen.

PYTHON

Wer ganz praktisch Software schreibt, sei es im beruflichen Alltag oder als Nerd, versteht nach einiger Zeit, dass alle höheren Programmiersprachen denselben logischen Prinzipien folgen:

• Bedingung
• Fallunterscheidungen
• Zählschleifen

Es gibt im Grunde nichts anderes in der Informatik. Lediglich das ganze Drumherum ist anders. Da werden Speicher optimiert, in dem man statt mit Variablen mit “Pointern” arbeitet. Da gibt es Prozeduren, Klassen, Module usw.  - die Syntax ist unterschiedlich, die Logik bleibt jedoch immer gleich. Würde man das auf “normale” Sprachen anwenden bedeutet das: die Vokabeln sind gleich, aber die Grammatik ist variabel.

Für mich gibt es daher nur einen wirklich wesentlichen Faktor, der die Programmiersprachen trennt: { } oder nicht. Sprachen, die ihre Codeblöcke in Klammern gruppieren oder nicht. Ich, der ich mit “Locomotive Basic” und später “Visual Basic” aufgewachsen bin, hasse alle Sprachen, die mit Klammern arbeiten. Denn diese Klammern verleiten eben nicht zu einem sauberen, übersichtlichen Programmierstil. Meiner Meinung nach bewirken sie das exakte Gegenteil. Denn ob Klammern vernünftig eingerückt sind oder ob man eine Bedingung in eine einzige Zeile schreibt, ist für das Kompilieren völlig egal.

Warum gibt es diese Klammern überhaupt? Sie dienen bei der Kompilierung eines Programms zur Abgrenzung von Anweisungen zur Übersetzung in die eigentliche Maschinensprache. Ganz abartig wird es dann noch, wenn einzelne Zeilen mit einem Semikolon abgeschlossen werden müssen. Also Java, PHP, C#, C, C++ – ich hasse das!

Unter Windows bleibe ich hartnäckig bei Visual Basic. Visual Basic kommt ohne klammern aus, verlangt aber praktisch überhaupt keinen Programmierstil. Muss man sich also mal in die Gedankenwelt eines anderen Programmierers reindenken, z.B. wenn jemand vor etlichen Jahren mal eine Access Datenbank mit seinem eigenen “VBA-Dialekt” erstellt hat, dann kann das ganz schön spaßig sein. Codefragmente über etliche Module verteilt fügen sich erst nach langem suchen und dem Aufmalen von Flowchart-ähnlichen Zusammenhängen zu einer Logik zusammen. Da wäre eine Programmiersprache von Vorteil, die keine Klammern nutzt und Konventionen hat, die alle Programmierer zu einer identischen Form der Codierung zwingt. Wenn diese Programmiersprache dann auch noch einfach und effektiv ist, im besten Fall auch noch plattformunabhängig, dann müsste sie doch eigentlich die bisher geltenden Standards ersetzen.

So eine Sprache gibt es, aber sie fristet immer noch ein Nischendasein. Sie wird zwar immer beliebter, ist aber noch keine wirklich relevante Programmiersprache. Sie heißt Python und hat ein einfaches Prinzip: der Compiler erkennt Code-Blöcke anhand von Einrückungen durch Tabulatoren.

Ein Beispiel:
So sieht ein einfacher Pseudocode-Block mit einer Bedingung in C, C++ oder Java aus:

if (bedingung == erfüllt)
{mache etwas}
else
{mache etwas beim Gegenteil}

Diese Anweisung kann aber auch so geschrieben werden:

if (bedingung == erfüllt) {mache etwas} else {mache etwas beim Gegenteil}

Oder so (was am ehesten den Konventionen für saubere Code-Strukturierung entspricht):

if (bedingung == erfüllt){ 
  mache etwas 
}
else
  { 
    mache etwas beim Gegenteil
}

Alle drei Beispiele werden vom Compiler gleich interpretiert.

Bei Python gäbe es nur diese eine Möglichkeit der Darstellung. Eine andere würde vom Compiler nicht verstanden werden. Es gibt keine Klammern (ein Segen bei verschachtelten Schleifen) und die Konvention wird quasi vom Compiler vorgegeben:

if bedingung == erfüllt:
  mache etwas
elif:
  mache etwas beim Gegenteil

Jetzt stellt sich hier die Frage, warum sich kein Paradigmenwechsel unter den Programmieren abzeichnet? Warum ist so etwas wie Python nicht schon längst Standard?

Naja, das hat zum Einen mit der Macht der Gewohnheit zu tun. Erfahrene Programmierer, die von Anfang an mit C++ oder C arbeiten, haben sich an die Nachteile längst gewöhnt. Würde man sie zu Python bekehren wollen, dann wäre das in etwa so, als würde man jemandem, der das 10-Finger-Prinzip beherrscht zu einem 2-3 Finger System zwingen wollen. Heute lernt niemand mehr die 10-Finger-Technik – sie zu Beherrschen aber als ineffektiv zu bezeichnen, wäre sicher falsch. Das ist einer der Gründe, warum sich Python bisher nicht ganz oben in der Liste der am meisten genutzten Programmiersprachen etabliert hat. Und natürlich ist es so, dass laufende, sich im produktiven Einsatz befindliche Software nicht so ohne weiteres umschreiben lässt. Zumal wenn es dafür keinen betriebswirtschaftlichen Grund gibt.

Ein weiterer Grund, den man aber nicht gelten lassen kann, ist die angebliche Ineffizienz von Sprachen wie Python oder Visual Basic gegenüber z.B. C/C++. Das ist nur dann relevant, wenn man den Verwendungszweck mit einbezieht. Schreibt man ein Anwenderprogramm z.B. für Windows, dann ist die Programmiersprache völlig unwichtig. Wichtig ist dann nur das Framework und der benutzte Compiler. Wenn Sie also ein Programm für Windows in Visual Basic.net schreiben oder in C# – es wird in der Effizienz des Programms keine Unterschiede geben.

Und Effizienz ist das Stichwort: wieviel Zeit, wieviel Geld geht uns verloren, weil Software aufgrund unterschiedlicher Konventionen ständig verändert, angepasst und neu verstanden werden muss? Welches Konzept wäre am besten für eine Vereinheitlichung geeignet? – Meiner Meinung nach das Konzept hinter Python.

Mehr zu Python finden Sie hier: https://www.python.org/