Dynamisch Typisieren

Dynamisch Typisieren

Moin Moin,

ich muss ein wenig dynamisch typisieren.
Ich bräuchte eine schreibweise mit der ich das mache. Ungefähr so:
leider funktioniert das so nicht ( manchmal wünsche ich mir diese schöne dynamische typisierung aus sprachen wie JavaScript oder Python ).

weiß jemand eine Lösung für mein kleines Dilemma?

Re: Dynamisch Typisieren

Warum gruselig?

Re: Dynamisch Typisieren

Gerade Python und co werden ja gerne als leicht zu lerndende Anfängersprachen verkauft. Ich finde es aber sinnvoll, sich mit einer stark typisierten Sprache beschäftigt zu haben, um gerade die Vorteile der dynamischen Typisierung schätzen zu lernen (ohne in ihre Tücken reinzulaufen)
"Gruselig" sollte nicht abwertend klingen. Ich stehe häufig wehmütig und anerkennend vor einem Stückchen Python

Re: Dynamisch Typisieren

ralf.wenzel hat geschrieben:

SaskuAc hat geschrieben:@Ralf: Weils häufig extrem schwer zu lesen und unschön ist. Außerdem kann es sehr fehleranfällig sein, wenn der Entwickler sich seiner Sache nicht sicher ist.

Das ist so bei abstrakten und generischen Codings. Dafür sind sie in höchstem Maße wiederverwertbar. Das eine kriegt man nicht ohne das andere.

Da hast du natürlich recht. Und das ist eigentlich ein Grund weshalb ich es unglaublich gerne habe, dynamisches Coding zu verwenden. Allerdings immer nur mein eigenes. Denn meistens ist anderweitiges dynamisches Coding meistens nicht gut dokumentiert und meistens, wie schon gesagt, unlesbar. Typisierung ist da jetzt nur ein Beispiel .. gibt ja viele weitere möglichkeiten Dynamisch zu programmieren.

Wir hatten einen genialen ( java script ) programmierer bei uns, der wirklich alles so extrem dynamisch geschrieben hat, dass man alles damit machen konnte. Außer es lesen. Wenn du z. b. ein dynamisch typisiertes Objekt hast, dass eine dynamische Methode aufruft ( ähnlich dem konstrukt " call method object->(methodname) " ) die dann wiederum einen Dynamischen Rückgabewert hat ... dann kannst es vergessen das auch nur ansatzweise lesen zu wollen.

Dynamik hat seine tollen Vorteile, aber irgendwie braucht man, imho, doch eine gewisse statik im Code. Sonst ist das ganze unwartbar. ( um jetzt mal den qualitätsexperten in dir anzusprechen )

Re: Dynamisch Typisieren

ralf.wenzel hat geschrieben: Das ist so bei abstrakten und generischen Codings.

Nicht zwingend. Gerade die Erzeugung finde ich auch extrem unglücklich und ich muss immer wieder nachschauen, wie es eigentlich geht.
Die Dynamik wäre ja nicht schlechter, wenn ich sowas schreiben könnte wie von SaskuAc vorgeschlagen: Der Compiler könnte (müsste) direkte Feldzugriffe auf dynstruc verbieten (CLEAR dynstruc-feld) und könnte trotzdem einen dynamischen Zugriff zulassen: CLEAR dynstruc-('feld').

ralf.wenzel hat geschrieben:Alles eine Frage der Dokumentation.....

Jein. Du kannst mir eine noch so tolle Dokumentation von Integralrechnung vorlegen, es stellt trotzdem nicht sicher, dass ich sie verstehe...

Re: Dynamisch Typisieren

ralf.wenzel hat geschrieben:Das ist jetzt "nur" eine Frage der Schreibweise und da gebe ich dir sogar recht. An der Komplexität ändert das nicht so viel.

Aber am verständnis und lesbarkeit des Codings, was ja auch wieder die Qualität erhöht.

Und die Dokumentation ist immer maximal so gut wie der Autor. da scheitert es leider schon manchmal. Denn Autoren gehen meistens davon aus, dass die Leser auf dem gleichem Wissensstand sind wie sie selbst. Und das funktioniert nunmal nicht immer, insbesondere nicht in so einer umgebung.

Re: Dynamisch Typisieren

SaskuAc hat geschrieben:

ralf.wenzel hat geschrieben:Das ist jetzt "nur" eine Frage der Schreibweise und da gebe ich dir sogar recht. An der Komplexität ändert das nicht so viel.

Aber am verständnis und lesbarkeit des Codings, was ja auch wieder die Qualität erhöht.

Das denke ich auch: Je komplexer etwas ist, desto größer wirken sich kleine Vereinfachungen aus.

Re: Dynamisch Typisieren

Die Sache mit der Dokumentation hakt doch schon an den sprachlichen Fähigkeiten des Entwicklers. Es geht nicht nur darum, ob der Entwickler sich mit der Doku Mühe gibt und einen entsprechenden Detaillierungsgrad für erforderlich hält, sondern auch, ob er überhaupt in der Lage ist, komplexe Zusammenhänge nachvollziehbar in Worte zu kleiden. In dieser Hinsicht halte ich uns hier schon für eine Art Elite, denn allein aus der Tatsache, dass wir willens und in der Lage sind, uns hier über solche Themen textuell auszutauschen, ergibt sich, dass wir darin geübt sind. Möglicherweise auch, dass wir das grundlegende Talent mitbringen. Ich zweifle, dass das jedem gegeben ist, und wer merkt, dass er in einem Forum gar nicht mitdiskutieren kann, weil er sich nicht ausreichedn gut ausdrücken kann, der wird es bleiben lassen. Das geht runter bis in den Bereich der Zeichensetzung. Ein inhaltlich richtiger Text kann extrem schwer verständlich werden, wenn der Autor nicht weiß, wie er seine Kommas zu setzen hat.

Ich kenne Entwickler, die richtig scharfsinnig sind, wenn man mit ihnen redet, aber deren Quelltextkommentare sich teilweise geradezu legasthenisch lesen. Und ich tendiere zu der Vermutung, dass ihre Zahl (bzw. ihr prozentualer Anteil an der Gesamtentwicklerpopulation) recht hoch ist.

Gute sprachliche Ausdrucksfähigkeit ist eine relativ selten gesäte Gabe. Ich erinnere mich noch an meine Uni-Zeiten, was wir da in den Vorlesungen teilweise für Unterlagen bekommen haben. Die konnte man nur im Kontext mit den Vorlesungen und Tutorien verstehen, und nein, ich glaube nicht, dass das Absicht war. In einem einzigen Fach gab es Unterlagen, die so gut waren, dass man sie einfach durchlesen und hinterher die Klausuren schreiben konnte, ohne je den Hörsaal von innen gesehen zu haben. War von einem WM erarbeitet worden. Leider war das das Fach, bei dem der Professor auch die beste Vorlesung gemacht hat...

Wie dem auch sein mag, sehr gute Dokumentation ist leider einfach nicht machbar, weil die Fähigkeiten der Entwickler es nicht hergeben. Man kann es auch nicht einfach fordern, denn Entwickler, die komplexe Sachverhalte verstehen, komplexen Code beherrschen und damit stabil laufende und ausreichend performante Programme abliefern, sind so schon knapp. Also ist es auch von daher schon ein erstrebenswertes Ziel, die Komplexität so weit wie möglich zu vereinfachen, denn man muss mit dem Humanmaterial arbeiten, das man hat bzw. bekommen kann.

Ralf hat geschrieben:Die zentrale Frage ist: Wird etwas einfacher, weil es statischer ist? Die Wartung wird nicht einfacher, weil ein abstrakt identischer Prozess mehrfach vorhanden ist.

Das ist nicht notwendigerweise so. Wie SaskuAc bereits angedeutet hat, gibt es Programmierer, die im Zweifel erst mal alles und seinen Hund dynamisieren, ohne sich Gedanken darüber zu machen, welcher Teil der Dynamik tatsächlich gebraucht wird. Bei solchen Teilen würden sich also ggf. keine mehrfachen Prozesse ergeben, wenn man auf sie verzichten würde.

Und selbst wenn ein Verzicht auf Dynamik bedeutet, dass ein "abstrakt identischer Prozess mehrfach vorhanden" ist, muss das nicht immer ein Nachteil sein. Wenn die Einsatzgebiete hinreichend gut getrennt sind, dann hat man halt gewisse Doku doppelt, dafür aber besser nachvollziehbar. Das halte ich für besser, als eine einheitliche Doku, die keiner versteht.

Natürlich gibt es auch Fälle, bei denen es besser ist, den abstrakt-gleichen Prozess nicht mehrfach abzubilden. Das muss man im Einzelfall entscheiden. Ich wehre mich nur gegen Deine Pauschalisierung.