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.
@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.
@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 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?
@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.
@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 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.
@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
@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.