Arne Babenhauserheide
Jedes Programm besteht aus vielen Teilprogrammen, die wir vollständig verstehen können.
Statische Typisierung koppelt diese Teile leider leicht zu stark.
Ja, Typescript "ihr solltet `any` verbieten", dich meine ich. Unter vielen anderen.
Eine Lösung für den richtigen Grad an Typisierung habe ich allerdings noch nicht.
Arne Babenhauserheide
@vampirdaddy Zu starke Kopplung, weil die Typen oft an unterschiedlichen Orten genutzt werden.
In meiner Funktion habe ich dann die gleichen Typen wie in der anderen Funktion und wenn ich die Datenstruktur in der einen verändere, muss ich auch den anderen Ort ändern.
Das lässt sich durch explizite Dto-Typen vermeiden, das ist aber nicht das einfachere.
vampirdaddy
@ArneBab Wieso zu starke Kopplung? Gut, ich muss dann ggfs explizit konvertieren - aber dafür habe ich dann auch die Gewähr, dass mit die Funktion nicht Runtime-Errort.
Ich kann eine explizite Typprüfung in die Funktionen legen - verliere dann aber Fehlererkennung zur Compile-Time.
Arne Babenhauserheide
@vampirdaddy Das Grundproblem (für das ich noch keine Lösung habe) ist, dass Typen die Verbindung von unterschiedlichen "Orten" sind (aufrufende und aufgerufene Stelle), aber an viele unterschiedliche aufgerufene Stellen weitergereicht werden.
Definiere ich sie beim Aufrufer oder beim Aufgerufenen?
Alice (ruft auf)
Brian (wird aufgerufen, nimmt Typ Toni)
Carol (wird aufgerufen, nimmt TYp Toni)
Wo definiere ich Toni?
Arne Babenhauserheide
@vampirdaddy Entweder das, oder über explizite Konvertierung.
Ich bin am Suchen, weil mir bei uns beim Wechsel von Javascript auf Typescript aufgefallen ist, dass Typen Leute dazu animieren, Pyramiden zu bauen.
Sie definieren damit Komplexität, weil sie die Sicherheit haben wollen, dass ihr Code immer richtig sein muss, weil sonst der Compiler meckert.
Komplexität, die bei geänderten Anforderungen große Änderungen braucht. Obwohl der eigentliche Code nur minimale Änderungen bräuchte.
vampirdaddy
@ArneBab
Okay, ich sehe das Problem - geht nur unelegant in einer von allen eingelesenen, shared Präambel-Datei.
Wenn die Typen zu eng definiert sind und dann die Struktur so weit ändern, dass die Funktionen angepasst werden müssen - dann muss ich entweder jeweils konvertieren oder alle anpassen.
Arne Babenhauserheide
@vampirdaddy Als Mehrwert von Typen sehe ich, dass bestimmte Klassen von Fehlern unmöglich werden (solange die Typen stimmen), und dass leichter zu erkennen ist, welche Datenstrukturen Funktionen nutzen (automatisch geprüfte Dokumentation).
Hardwarenahe Typen bringen außerdem Effizienz (Typescript nicht).
Aber das hat seinen Preis und ich glaube nicht, dass was ich gerade bei Typescript sehe wirklich das Optimum ist.
Arne Babenhauserheide
@vampirdaddy (mit jsdoc haben Leute übrigens viel weniger Pyramiden gebaut. Da waren Typen eher wirklich geprüfte API-Dokumentation und wurden nicht einfach geschrieben, weil der Linter sagte „das könnte any sein!“.
Arne Babenhauserheide
@vampirdaddy Ich bin nicht sicher. WIe gesagt: ich kenne bisher keine Lösung, die ich wirklich gut finde.
Ich habe zwar Ideen, aber noch nichts, dem ich hinreichend vertraue.
Meine bisherigen Gedanken gehen eher in die Richtung, Hierarchien von Typen zu vermeiden und früher zu primitiven Typen zurückzugehen — und sie vielleicht neu zu verpacken.
vampirdaddy
@ArneBab
Ah - Überspezialisierung der Typen, ähnlich wie Klassen in Java?
Da sind generische Typen besser, die den Verarbeitungstyp festlegen - so dass die Variablengröße und Verarbeitung sauber definiert ist
Number: Int, Float (ggfs. unterschiedliche)
Multidim: Vector, Matrix, Complex
String
generic: Array, Dictionary, Stack, FIFO/Buffer (Ringbuffer)
composite: JSON-style, not predefined
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.