[Python-de] Bitte widersprechen

[Achim Domma]

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