On Monday, 16 October, 2017 04:35 PM, Thomas Güttler wrote:

Dann tu es bitte. Bitte widerspreche zu konkreten Punkten mit klaren Argumenten. Das würde mich freuen.

Ich tendiere bei sowas etwas ruppig rüber zu kommen und über's Ziel hinaus zu schießen. Da ich aber gerade im Süden bei immer noch 25+ Grad auf einem Balkon sitze, versuche ich's mal! ;-) Du schreibst oben zwar, daß es sich nur um deine Ansichten und nicht um die einzige Wahrheit handelt, die Ausführungen unten sind aber genau so geschrieben, als wären sie absolut. Für weniger erfahrene Entwickler oder Anfänger (dein Zielpublikum) ist es absolut unmöglich zu erkennen, was deine persönliche Perferenzen sind und für welche Aussagen du gute Gründe hast. Selbst wenn du gute Gründe hast, sind diese evtl. nur in "deiner Welt" valide oder eben auf deinem aktuellen "Skilllevel". Es ist natürlich legitim, diesen Stand zu dokumentieren. Meiner Ansicht und Erfahrung nach, richtest du damit aber mehr Schaden als Nutzen an, wenn du den Kontext und Hintergrund nicht explizit machst. Jetzt aber ganz konkret: - 10-Finger-Tippen: Sollte man in meinen Augen können, aber ist es wirklich so wichtig? Wieviel Zeit verbringst du mit Schreiben von Code und wieviel mit Lesen? - SQL ist kein bißchen langweilig. Wie kommst du darauf? In "meiner Welt" würde ich NIEMALS einem Tool eine Datenmigration überlassen. Dafür sind die Datenmengen viel zu groß. Und ganz sicher würde ich nicht Django verwenden. Wenn überhaupt ein ORM, dann SqlAlchemy. Das heißt nicht, daß deine Aussage falsch ist. Mir fehlt nur - wie oben beschrieben - der Kontext. Deine Aussage paßt auf ein SEHR eingeschränkten Bereich von Problemen. Selbiges gilt für NoSQL: Ich bin da auch kein großer Fan davon und froh, daß "meine" Sachen noch mit Postgersql lösbar sind. Aber es gibt nunmal Probleme, für die wirst du Cassandra brauchen. - Conditional data structures: Das Argument zählt nur für SEHR einfache GUI Anwendungen. Da ist dein "empty"-Place eine einfache Lösung. In den meisten Fällen wirst du für "empty" trotzdem Spezialbehandlungen haben und dann eine "magic number" in der Gegend rum reichen müssen. Für mich hat Displaylogik nichts in den Daten zu suchen. Wenn's den Platz nicht gibt, gehört für mich da ein NULL hin. Damit umzugehen ist Aufgabe der GUI. - Nullable boolean columns: No way! Mag sein, daß das wieder für einfache GUIs paßt, aber in "meiner Welt" hat in der Datenbank zu stehen, was die Daten ausdrücken wollen. Dazu muß der Entwickler natürlich wissen, was NULL ist und wie man damit umgeht. - Avoid nullable character columns: In "meiner Welt" auch indiskutabel. Wie oben: Wenn dein Ansatz für dich paßt, ist das ok. Aber die Aussage gilt in der Form nicht allgemein. Für mich macht es oft einen großen Unterschied, ob der String explizit da, aber leer ist, oder ob er gar nicht gefüllt ist/war. - Beim CRD Absatz verstehe ich nicht wirklich, was du sagen willst. - Avoid Threads and Async: Was machst du denn auf Multicore-Maschinen? Sagen wir 64 Cores? Ja, du kannst mehrere Prozesse starten, was das Debugging nicht gerade leichter macht. Je nach Szenario verbrennst du dann jede Menge Rechenzeit mit der Interprozesskommunikation. Und im Fall von extremem IO kommt nichts an die Performance mit async in Kombi mit mehreren Prozessen. Und in anderen Fällen sind Threads die einfachste und effizienteste Lösung auf solchen Maschinen. Du hattest ja oben KISS erwähnt. Um dem zu folgen zu können, sollte man alle Optionen kennen und können. - Source code generation is a stupid idea: Hast du da schon was geändert oder hatte ich vorher oberflächlich gelesen? Mir scheint der Absatz jetzt mehr auf "SOURCE code" zu fokussieren, womit ich besser leben kann. Der Punkt ist ein großes Thema, dem deine Ausführungen nicht gerecht werden. Ich halte es heute für eine schlechte Idee, mit Texttemplates o.ä. Source Code zu erzeugen und diesen dann zu compilieren oder auszuführen. Daneben gibt es aber 1001 andere Optionen, die die Schwachpunkte dieses Ansatzes nicht haben. Im übirgen bin ich mir recht sicher, daß TypeScript nicht textbasiert in Javascript übersetzt wird. Ohne es geprüft zu haben, würde ich Wetten annehmen, daß TypeScript in eine Art AST übersetzt und dieser dann als JavaScript serialisiert wird. - Regex: Ähnlich wie oben bei SQL: "Know your tools" und den Kontext. Ja, es ist Bullshit, mit Regex JSON & Co parsen zu wollen. Das ist aber kein Regex-Problem sondern ein Userproblem. Ein Entwickler, der seine Hausaufgaben gemacht hat, weiß, daß man z.B. HTML eigentlich nicht wirklich mit Regex parsen kann. Aber wenn du z.B. in einem Freitext nach "auschließlich Zahlen in Klammern" suchst, sind Regex nicht zu übertreffen. Ja, ist nicht der Usecase, den du beschrieben hast. Meiner aber schon. - Keep custom IDE configuration small: Also doch vi benutzen? ;-) - Passing around methods ...: Ich mag Python u.a. weil ich mehrere Paradigmen zur Hand habe. Und stellst du gerade den Sinn von funktionaler Programmierung in Frage? - "git rebase" vs "git merge": Das Ergebnis ist nicht nur Sourcecode. Das Ergebnis ist auch die History, die ich mir anschauen kann. Je nach Projekt und Anforderungen macht merge vs rebase einen riesen Unterschied. - This is untestable code: Ich habe noch niemanden gesehen, der diese Argumentation mit ausreichend großen und komplexen Datenmengen aufrecht erhalten kann. ;-) - Learn one programming language, not ten: Du kennst "Pragmatic Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur in diesen Strukturen denken und hat in der Regel Scheuklappen an. Javaentwickler können oft z.B. nur OO denken. Soweit erstmal. Nur nochmal zur Sicherheit: Ich behaupte nicht, daß deine Aussage grundsetzlich falsch wären. Aber sie sind auch nicht so allgemeingültig, wie sie formuliert sind. Und das ist für dein Zielpublikum irreführend. Grüße, Achim