Protocol buffers - oder: Was in einer Firma wie Google alles schiefgehen kann

Es gibt da eine Datei, https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/ops/ops.pbtxt , die ich gerne lesen würde. Dafür soll man wohl protocol buffers verwenden können. Vermutlich.

Die Frage ist nicht, wie das geht. Die wird niemand beantworten können.

Die Frage ist eher, wie eine Firma wie Google es dermaßen verbocken kann. Welche Prozesse innerhalb einer Firma bewirken, dass so etwas in die Öffentlichkeit gekackt wird? (Ja, sehr deutlich, aber das haben sie halt schon richtig verbockt…)

Dürfte ich Fragen, wo da denn das Problem liegt? Sind es die 33.000 Zeilen? Ist es das Datei Format?
Ich kenne noch die Zeiten mit Soap, da gab es vergleichbares mit der WSDL-Datei. Allerdings alles in XML.
Damit hat man sich dann das passende Gegenstück in Java generieren lassen und lustig drauf los programmiert. Das waren dann auch ähnlich viele Zeilen.

Der Prozess des Generierens und Verwendens der Klassen.

Die Hürden sind vielfältig. Dass das ganze eine binary erfordert, ist eher ein Detail - die kann man downloaden, dann händisch ins src-Verzeichnis (!) kopieren und irgendwie laufen lassen. Die Parameter dieser Binary richtig zu tweaken (anhand der üblichen Fehlermeldungen) ist Frickelei. Diese Frickeleien erstrecken sich auf weitere Kleinigkeiten, wie relativer (d.h. nicht wirklich „falscher“, aber doch „unpassender“) Pfade in den .PROTO-Dateien. Warum man zwischendrin ein mvn install machen musste, hat sich mir nicht ganz erschlossen. In welcher Welt sind wir hier? Java oder nicht? Wie auch immer.

Dass die Codegenerierung nun 98 Dateien (!) mit 2.2 MEGA (!) byte Java-Code erzeugt hat, nur um etwas zu parsen, was sich von JSON im wesentlichen durch ein paar fehlende Doppelpunkte unterscheidet, wirkt aber schon, als würde da jemand versuchen, gezielt eine Infrastruktur aufzubauen, die nur der elitäre Kreis derer verwenden können, die entweder bei Google arbeiten, oder bereit sind, absurd viel Zeit zu verbrennen.

Das ganze ist auch nur Yak-Shaving. Warum will ich das parsen? Nun, um die ganzen „ops“ und „atts“ die in dieser Datei definiert sind, lesbar aufzulisten, bzw. zu verarbeiten. Warum will ich die auflisten? Weil sie ansonsten nur implizit, indirekt und versteckt (mit manchmal „leichtAnderenNamen“ oder „leicht_anderen_namen“) in einer Python-Doku verschmiert zu finden sind. Warum will ich die finden? Weil ich die Java-API von TensorFlow verwenden will. Warum will ich die verwenden? Weil (Java die besteste Sprache der Welt ist :wink: und) alle TensorFlow für irgendwas verwenden - z.B. für classification models. Warum will ich ein classification model erstellen? Langeweile :stuck_out_tongue_winking_eye:

Nur um das richtig zu verstehen, in den ersten zwei Absätzen geht es um das Erstellen von Protocol Buffers. OK, das sieht “interessant” aus.

Was ich aber nicht ganz kapiere ist wie hier vermerkt https://www.tensorflow.org/install/install_java
das man lediglich eine Maven-Dependency zu seinem Projekt hinzufügen muss um ein Java-Binding zu haben. Da gehe ich mal davon aus, dass da auch entsprechend Doku mitkommt.

Es ist verständlich und auch schöner, wenn man das alles aus Sourcen bauen kann. Dennoch wenn es nur darum geht, das ganze mit Java zu verwenden um sich ein Model zu erstellen, dann sollte das doch erstmal reichen? Ich wäre ohne es jetzt ausprobiert zu haben und darauf vertrauend, dass dies funktioniert, damit erst einmal zufrieden.

3 Beiträge wurden in ein neues Thema verschoben: TensorFlow mit Java

Google hat sein eigenes SCM, Build Tool, mit anderen Worten:
Die leiden ganz stark unter dem “Not invented here” Syndrom

Oft setzen die Standards bzw. implementieren bestehende, manchmal “entwischt” auch mal was in die Aussenwelt das eher intern bleiben sollte.
ProtoBuf und Bazel gehoeren fuer mich zum letzterem.

Erinnert mich an meinen eigenen Rant vor einiger Zeit hier. Richtete sich auch gegen Google.
Um die Library in Java einzubinden musste man mehrere Linux-Programme und ihre Dependencies manuell installieren - auf Windows wird das zum Spaß für die ganze Familie, die DLLs in die richtigen Ordner zu verschieben und zu verlinken. Yeay!
(Wie das erste mal OpenGL… schwarzer Bildschirm und niemand kann einem sagen warum)
Nur um dann festzustellen, dass die Bindings zu 90 % unvollständig waren.
Anstatt die Bindings selbst kurz direkt zur Verfügung zu stellen lässt man lieber tausende andere Leute durch die Hölle laufen.

Aber hey, dass ist nunmal die andere Seite der Fassade und das ist dein Job.

@maki Ja, irgendwann hatte ich mal die Artikel um

https://research.google.com/pubs/pub45424.html

herum gelesen, und mir gedacht: Gut, man kann eine Parallelwelt erstellen…

Das Problem besteht dann halt ggf. darin, dass man immer mal auf ein geleaktes Fragment dieses Monolithen zugreifen muss, und eben nicht die anderen 1999999000 Zeilen griffbereit hat…

Das sehe ich ähnlich. Wenn man sich die Protobuf-Webseite mal ansieht, wird dort ja auch ganz klar beschrieben, wofür es entworfen wurde. Für eine heterogene Softwarelandschaft, wie sie offenbar bei Google existiert.
Die Versionierung (Kompatibilität unterschiedlich gepflegter Software), die binäre Umsetzung (mit dem Ziel einer effizienten Bandbreitennutzung) und die Sprachunabhängigkeit (Generatoren für verschiedene Zielsprachen) waren wohl die Hauptanforderungen für den Entwurf von Protobuf.