Warum tendieren Informatiker (Achtung: Verallgemeinerung) eigentlich immer (und nochmal) alles (und ein letztes mal) zu verkomplizieren?
Warum Linux? Warum C++? Warum JS? Warum jetzt das x-te version control system, eines komplizierter als das nächste?
Warum zur Hölle muss jedes „Werkzeug“ so entwickelt werden, dass der Endanwender möglichst viele Probleme damit hat?
Sieht man den Handwerker ein 1000-Teile Puzzle legen um seinen Akkubohrer zusammenzusetzen?
Ich will ein Problem lösen und die Tools sollen mir dabei helfen. Stattdessen verlagern sie das Problem einfach nur indem sie selbst zum neuen Problem werden ohne das eigentliche Problem gelöst zu haben aber mit dem Versprechen das zu tun.
Zum Beispiel dieser GPU debuggers für OpenGL und Android. War vorher in Android Studio integriert, wurde jetzt in der neuesten Version aus unbekannten Gründen wieder entfernt. Hier mal die Installationsschritte (und die sind absolut kein Einzelfall. Ich behaupte ich kann das Problem in der selben Zeit debuggen wie ich brauche um das Ding zum laufen zu kriegen):
Install Go 1.8
Install Mingw-w64 Toolchain
Install msys2.
Open the MSYS2 MinGW 64-bit terminal.
Type: pacman -Syu --noconfirm and press enter.
Close and reopen the msys2 terminal.
Note that pacman may need to update itself before updating other packages, so repeat the above two steps until pacman no longer updates anything.
Type: pacman -S mingw-w64-x86_64-gcc --noconfirm and press enter.
Close the msys2 terminal
Install Android SDK
Unzip the Android SDK to a directory of your choosing.
Using the unzipped tools\android.bat download:
Android 5.0.1 (API 21)
SDK Platform
Android SDK Build-tools 21.1.2
Install the Android NDK
Unzip the Android NDK to a directory of your choosing.
Install CMake.
Install Ninja
Unzip the Ninja executable to a directory of your choosing.
Ja, das beobachte ich teilweise auch. Ich denke, dass man da schon etwas differenzieren sollte. Wenn es um irgendein Hobby-Projekt geht, das jemand auf GitHub stellt, oder irgendwas experimentell-ausgefeiltes, was nur von den Experten der jeweiligen Domäne verwendet werden soll/kann, dann kann es zumindest „gerechtfertigt“ sein, wenn das Aufsetzen etwas Aufwand erfordert. Die Infrastruktur, die notwendig ist, um „Nutzern“ das Leben „leicht“ zu machen, kann groß bis gigantisch sein. Nicht alles kann als „Doppelklick-Zum-Installieren-Mit-InstallShield“-Paket ausgeliefert werden. Und die Rechtfertigung hat da dann sogar einen ökonomischen Aspekt - etwas plakativ: Wenn der Entwickler 20 Stunden für einen Installer investieren müßte (oder auch nur 5 Stunden für einen einfachen Build-Script), dann ist es besser, wenn die 10 Nutzer stattdessen jeweils 20 Minuten selbst rumbasteln müssen. (Auch, wenn das frustrierend sein kann, weil es natürlich nie so funktioniert, wie es in der README steht ;))
Aber … bei sowas wie einen Debugger in einer IDE, die (Kritik: ) die einzige ist, die es für eine bestimmte Plattform gibt, und zu deren Verwendung kackdreist hunderttausende von Entwicklern genötigt werden, sieht das ganze etwas anders aus.
(Zugegeben: Ein bißchen unbehaglich finde ich das Gegenteil davon auch. Ein unscheinbares npm install macht so viel und ist so eine große, blacke box, dass etwas mehr Kontrolle manchmal wünschenswert erschiene).
Aber… auf den konkreten Fall bezogen… (vielleicht bin ich da ja „abgehärtet“, aber … ) … das sieht doch noch vergleichsweise überschaubar aus?! Zumindest scheint jeder der genannten Punkte ein „Blatt“ zu sein (im Sinne von etwas, was mit einen Installer installiert werden kann). Richtig nervig wird es, wenn sowas dann eine Auflistung von 5 Dingen ist, bei denen jeweils wieder eine „How-To-Build-This-Carp“-README enthalten
Ich vertrete da die These, dass Einiges nicht kompliziert genug sein kann, um professionell wirken zu können.
Professionelles muss derart gestaltet sein, dass da nicht jeder durchsteigt, sonst könnte es ja auch jeder bauen und vertreiben.
Im Gegensatz zu Softwareprodukten, die sich jeder zusammenbauen kann, wenn er einen PC sein Eigen nennt und sich mit Programmiersprachen auseinandersetzt, kann nicht jeder einen Akkuschrauber in seiner Werkstatt bauen, weil dazu Equipment nötig ist, dass weit weniger erschwinglich ist, als ein PC.
Fazit: Software wird immer komplizierter aber ein Akkuschrauber bleibt ein Akkuschrauber.
Meine Theorie: Aktuell kann man sich recht einfach neue Sprachen/Frameworks erstellen und wir haben einfach viele viele Egos die der Meinung sind sie können es besser und deshalb bauen sie einfach mal was neues.
Aber andersrum hat man auch sehr viele Entwickler mit Halbwissen die einfach blind auf jeden Zug aufspringen, oftmals würde ich auch behaupten sie kommen ausm Webumfeld und wollen deshalb überall ihr … JS drin haben.
Mein Lieblingsbeispiel in letzter Zeit: Das Tutorial zu Hyperledger Fabric:
“Lade dir die Sourcen mit curl von Github herunter, installiere npm, nodejs, und 40 Pakete”
Habe mich gewundert, da Hyperledger auf Go läuft und nur über REST mit Clients kommuniziert. Und npm, nodejs und 40 Pakete (mit Dependencies auf Perl?? und auf Windows auf eine Version von Visual Studio???) brauchte ich nur für den Demo REST Client der ein paar Commands absetzt. W T F.
Überlege gerade noch das Tutorial in einen “Easy Mode” umzuschreiben, sowas schreckt nur noch ab.
