Datentypen Typisierung zu streng?

[Antedeluvisch]

Hallo, ich habe eine kurze Frage als relativer Anfänger: Ein Kommilitone besteht darauf dynamische Typisierung sei letztendlich besser als die statische Typisierung von Java.
Er meint die Compilerfehler, die dadurch aufgezeigt wurden kommen zum Teil erst durch die strenge Typisierung zu stande (treten also ansonsten gar nicht auf) und bedeuten letztlich nur Mehrarbeit.

Hat er da recht oder? Danke für die Info

 

[Noctarius]

Er hat so lange Recht, bis er das erste Mal eine Zahl braucht aber seine dynamische Typisierung meint er hätte einen Text.

Zum Beispiel so:

var foo = '100';
var bar = 1;
var i = foo + bar;

Was ist i jetzt? Ein String mit '1001' oder der int-Wert 101?

Sagen wir so es hat beides Vor- und Nachteile. Strikte Typisierung mit guter Typenerkennung ist das schönste. Scala ist da echt nett

 

[ARadauer]

Naja darüber kann man streiten.... aber ich denke das strenge Typisierung eine Menge vorteile in bezug auf Qualität bietet.

letztlich nur Mehrarbeit.

Man verbringt wesentlich mehr Zeit fehler auszumerzen als Code zu schreiben. Ich denke die Typsicherheit von Java spart schlussendlich einen Haufen Zeit...

Ich verstehs aber dass Anfäger, vor allem die aus dem PHP Bereich, das anders sehen... wie man es gewöhnt ist....

 

[Antedeluvisch]

Er hat so lange Recht, bis er das erste Mal eine Zahl braucht aber seine dynamische Typisierung meint er hätte einen Text.

Zum Beispiel so:

var foo = '100';
var bar = 1;
var i = foo + bar;

Was ist i jetzt? Ein String mit '1001' oder der int-Wert 101?

Ich habe meine Kommilitonen auf das Beispiel angesprochen, vielen Dank dafür.

Er meinte nur beispielsweise in PHP sähe das so aus, das von Ruby spar ich jetzt mal:

foo = '100';
bar = 1;
i = foo + bar;
j = foo . bar;

Bei i werde das Ergebnis durch den Operator Integer, j ein String, da Punkt eine Zusammenführung als Text macht.
Darüberhinaus könne er den Typ explizit mit "(Typ) Variable" festlegen.

Wisse man nicht welchen Typ und Wertebereich man bekommt, hätte man aber so oder so ein Problem. Mögliche Usereingaben wären als "evil" (so ein Depp!) anzusehen und müssten eher logisch als vom Typ überprüft werden.

 

[Antedeluvisch]

aber ich denke das strenge Typisierung eine Menge vorteile in bezug auf Qualität bietet.

Hast Du da ein paar fundierte Argumente für mich? So kann ich meinem Komm nicht antworten.

Man verbringt wesentlich mehr Zeit fehler auszumerzen als Code zu schreiben. Ich denke die Typsicherheit von Java spart schlussendlich einen Haufen Zeit...

Ich verstehs aber dass Anfäger, vor allem die aus dem PHP Bereich, das anders sehen... wie man es gewöhnt ist....

Oder ist es wirklich mehr der gewohnte Stil den man hat? Ich kann mir aber kaum vorstellen, dass man mit einem Luschi-System gut arbeiten kann!?

 

[Noctarius]

Das ist richtig und klar kann man das Problem immer umgehen (siehe PHP). Andere Sprachen nutzen aber keine 2 verschiedenen Operatoren ;-)

Das kannst du ihm ja mal zeigen zum Thema statische Typisierung und Scala
Weblogs Forum - Getting Dynamic Productivity in a Static Language
Scala Blog: Manifests: Reified Types
http://www.deskchecked.com/wp-content/uploads/2009/11/OSDC-2009-On-Scala.pdf

 

[bygones]

bin fan von dynamischer Typisierung... statische braucht man nur fuer die IDE....

oh wahrscheinlich noch warum...

der compiler bzw das system weiß meist gut genug was für typen genommen werden können. Die "unsicherheit" des programms muss man so und so über unit tests widerlegen, ergo ist statische Typ. Mehrarbeit !

 

[Antedeluvisch]

Das ist richtig und klar kann man das Problem immer umgehen (siehe PHP). Andere Sprachen nutzen aber keine 2 verschiedenen Operatoren ;-)

Das kannst du ihm ja mal zeigen zum Thema statische Typisierung und Scala

Uiii, Scala mag ich überhaupt nicht, das kommt mir fast wie Ruby vor. Der Syntax ist unschön und wird durch zu viele Verkürzungen schlecht lesbar. Lieber eine Zeile mehr und man kann auch verstehen was andere da geschrieben haben. Da ist mir Java viel lieber, aber bin erst Anfänger.

 

[AwsmDude]

Scala ist alles andere als schlecht lesbar.

 

[Antedeluvisch]

bin fan von dynamischer Typisierung... statische braucht man nur fuer die IDE....

Selbst da meint mein Komm als Gegenbeispiel gäbe es die IDE von Small Talk, die als erste von Refactoring bis was-weiss-ich noch alles ohne statische Typen das gleiche gemacht habe.

 

[Noctarius]

Ich bin auch nur so lala Scala-Fan aber das Type-System ist absolut super. Auch die Syntax hat viele schöne Dinge aber genau wie du sagst ist es mir oft zu kurz gemacht. Trotzdem ist z.B. ForEach für Maps eine feine Sache.

Scala sieht generell komisch aus, da es sich oft an den Ansatz von funktionaler Programmierung hält und die Syntax ist halt immer anders

Selbst da meint mein Komm als Gegenbeispiel gäbe es die IDE von Small Talk, die als erste von Refactoring bis was-weiss-ich noch alles ohne statische Typen das gleiche gemacht habe.

Dazu muss die IDE aber eine Typisierung durchführen Sagen wir so, dynamische Typisierung hat Vorteile aber auch Nachteile. Genau wie statische Typisierung. Ich bin trotzdem eher Fan von letzterem, allein weil man als Außenstehender schneller erkennt was der Sinn einer Variable ist ohne den Ablauf nachzuvollziehen.

Bei dynamischer Typisierung sagt mir [c]var id = getId();[/c] nur, dass ich eine ID habe, muss ich dazu ein Datenbankschema machen was nehm ich dann? Int? String? [c]int id = getId();[/c] sagt mir die Lösung ohne Debuggen, ohne Codeflow-Analyse.

Dynamische Typisierung ist ok, solange man Variablen wenigstens deklarieren muss. Schlimm wird eine Kombination aus dynamischer typisierung und impliziert deklarierten Variablen.

var dynDataField = 'test';
printf(dynDataFeild);

Der Code macht mal gerade einen leeren String und such so einen Fehler mal, immerhin ist die Syntax ja gültig

 

[Andi_CH]

Hallo, ich habe eine kurze Frage als relativer Anfänger: Ein Kommilitone besteht darauf dynamische Typisierung sei letztendlich besser als die statische Typisierung von Java.
Er meint die Compilerfehler, die dadurch aufgezeigt wurden kommen zum Teil erst durch die strenge Typisierung zu stande (treten also ansonsten gar nicht auf) und bedeuten letztlich nur Mehrarbeit.

Hat er da recht oder? Danke für die Info

Nein, hat er nicht. Es ist nur viel bequemer wenn man nicht planen will (So fertig provoziert )

Ich habe mit Pascal, Modula und Ada begonnen, dann kamen Assembler und C, ich bin heute noch ein bekennender Fan von Ada - das ist eine noch strenger typisierte Sprache als Java.
Der Einstieg ist ziemlich aufwändig auch bis das erste Programm mal das tut was man will, aber wenn ein Programm kompiliert werden kann, ist die Chance sehr hoch, dass es auch läuft (Ja! auch Ada kann man kaputt programmieren wenn man unbedingt will)

Das Gegenteil ist C - Einstieg einfach, erster Programmentwurf in no time ABER bis dann alle Laufzeitfehler gefunden sind ..... das kann dauern.

Strenge Typisierung und konsequentes Umsetzen derselben verschiebt den Aufwand Fehler zu suchen nach vorne in die Programmierphase und es ist eine uralte Weisheit, dass es viel günstiger ist, die Fehler schon am Anfang zu finden...

In kleinen Teams von sehr disziplinierten Entwicklern (das ist IMHO allerdings ein Widerspruch ) kann es durchaus auch mit C oder Assemblerähnlichem Typenverständnis funktionieren, aber es wird die Ausnahme sein.

Vorsicht mit Widerspruch wer noch nie wirklich etwas im anderen System durchgezogen hat, kann gar nicht beurteilen was besser ist und akademische Ansätze neigen dazu in der Praxis nicht immer realisierbar zu sein. (Hm - so ganz verklemmen kann ich mir Provokationen halt doch nicht ;-) )

Wen konkrete, projektbezogene Aussagen interessieren darf gerne direkt anfragen

 

[Andi_CH]

.... da hab ich doch noch etwas vergessen - strenge Typisierung lässt sich natürlich auch in Assembler oder C umsetzen, aber welcher Mensch ist schon konsequent genug mit sich selbst?
Ich mag die Unterstützung von Compilern ;-)

So nebenbei SmallTalk kenne ich auch - es gibt meiner Meinung nach gute Gründe warum sich das nicht wirklich durchgesetzt hat ...

 

[bygones]

Bei dynamischer Typisierung sagt mir [c]var id = getId();[/c] nur, dass ich eine ID habe, muss ich dazu ein Datenbankschema machen was nehm ich dann? Int? String? [c]int id = getId();[/c] sagt mir die Lösung ohne Debuggen, ohne Codeflow-Analyse.

herangezogenes bsp meiner ansicht nach... so wie wenn ich sage

Map<MyType<String>, Collection<OtherType<Comparable>>> map = new HashMap<MyType<String>, Collection<OtherType<Comparable>>>();

das soll einer besser lesen können ?!

So oft wie das da oben geschieht, geschieht auch dass man für einen bestehenden Code noch mal eben das Datenbankschema erstellen muss...

var dynDataField = 'test';
printf(dynDataFeild);

das muss zum Fehler führen. Dynamische Typisierung heißt nicht implizierte Deklarierung

 

[Noctarius]

herangezogenes bsp meiner ansicht nach... so wie wenn ich sage

Map<MyType<String>, Collection<OtherType<Comparable>>> map = new HashMap<MyType<String>, Collection<OtherType<Comparable>>>();

das soll einer besser lesen können ?!

Nein, deswegen hassen auch alle diese Art und sie wird in Java 7 wegfallen können, zu mindestens in der Instanzierung. Wenn aber einer so ein Generic Konstrukt baut ist an der Architektur schon was falsch

as muss zum Fehler führen. Dynamische Typisierung heißt nicht implizierte Deklarierung

Les' mal was darüber steht "richtig ekelhaft wird die Kombination aus ..."

 

[bygones]

Nein, deswegen hassen auch alle diese Art und sie wird in Java 7 wegfallen können, zu mindestens in der Instanzierung. Wenn aber einer so ein Generic Konstrukt baut ist an der Architektur schon was falsch

und ich sage noch wenn ein Code so steht und dann kommt ein Code-unwissender um mal eben datenbankschema aufzusetzen - ist auch falsch schon komplett falsch gelaufen

Les' mal was darüber steht "richtig ekelhaft wird die Kombination aus ..."

hab ich .... wollte es nur nochmal unterstützen