Fortsetzung JS-Diskussion aus "GreaseMonkey zum Individualisieren des Forums"
-
Alle die immer an JavaScript rumnörgeln zeige ich zz gerne dieses Video
https://www.youtube.com/watch?v=Trurfqh_6fQ
allgemein sollte man sich Videos von Douglas Crockford ansehen.
-
emphatisant schrieb:
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Das ist etwa das gleiche Niveau wie
"Ich mag C++ nicht, weil ich kann mich nicht mit einer Sprache abfinden, die keinen Garbage Collector hat, weil Pointer machen alles unsicher"Stimmt. Der Satz war vielleicht ein wenig zu strikt formuliert.
Dynamische Typisierung ist ein erklärtes Feature. Viele Sprachen haben das. Python, Perl, PHP, (C++-Templates,) etc.
Gut, dass du C++-Templates eingeklammert hast.
Die schaffen das Spagat zwischen Typsicherheit und dynamischer Typisierung.
Aber nur weil viele Sprachen etwas haben, heißt das noch lange nichts. Viele Sprachen haben das auch nicht.Dynamische Typisierung ist nachweisbar beliebt bei vielen Programmierern.
Aber nicht bei mir.
Siehe das Zitat hier: http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages
Statische Typisierung bedeutet nicht "Kompiliert => Korrekt". Im Gegenteil. Man kämpft mit dem Typsystem um es zum kompilen zu bekommen und gewinnt dadurch nichts. Der allererste Unit-Test einer dynamischen Programmiersprache zeigt dir den Fehler auf und das noch bevor dein Programm kompiliert hat. Und nicht nur Typfehler, sondern alle Arten von Fehlern, die der C++-Compiler schweigend durchgehen lässt. Bugs finden und beheben ist in dynamischen Programmiersprachen einfacher als in statischen.Kannst du mir bitte ein Beispiel geben, weil so ganz weiß ich nicht, worauf du hinauswillst.
Meine Aussage ist vielleicht etwas übertrieben und du kannst gerne dagegen argumentieren, aber bitte denke nicht über JavaScript als schlechte Kopie von C++. Genauso kann man nicht über C++ als schlechte Kopie von Java denken (siehe Zitat oben). Lasse dich auf das Denken ein und entscheide erst dann, nachdem du erste Erfahrungen gesammelt hast.
Ja, das kann vielleicht mein Fehler gewesen sein, als ich in Javascript programmiert habe.
Genauso wie viele C Idiome in C++ packen, hab ich wohl versucht C++-Idiome in Javascript zu stopfen.
Eigentlich klar, dass das nicht geht.
Gibt es vielleicht irgendwo eine Quelle, wo man gängige dynamische Typisierungsidiome findet?@PRIEST:
Wenn ich Zeit hab, schau ich mir das Video mal an.
-
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Eine Diskussion pro/contra dynamische Typisierung macht keinen Sinn. Das Thema wurde zur genüge durchanalysiert. Alles hat seine vor und seine nachteile.
Deine Kritik an JS ist also, dass es dynamic typing hat?
OK, ich dachte echt schon dass es mal eine sinnvolle diskussion gibt. Ne ne ne ne...
PS:
ich finde solche Diskussionen nicht wert. Denn sie sind so oberflächlich. Das erinnert mich dann immer an eine Mode Diskussion. Aber nein, man kann doch nicht Braun mit Blau mischen, OMG wie furchtbar.Ne, typisierungen haben ihre Vorteile und ihre Nachteile - jeder ernsthafte Programmierer sieht das ein. Natürlich gibt es vorlieben und einige bevorzugen dieses andere jenes - das ist ja kein Problem. Und man kann auch gerne sagen dass sich diese oder jene Sprache nicht gut anfühlt - aber das ist halt keine ernsthafte Kritik an der Sprache.
Ich dachte echt wir haben jetzt was fundiertes. JavaScript hat nämlich historisch bedingt schon einiges kontroverses zu bieten. Aber wir reden hier nur über so primitive Sachen wie Typisierung und Syntax rum.
-
Shade Of Mine schrieb:
Nathan schrieb:
Ich kann mich auf gar keinen Fall mit der dynamischen Typisierung anfreunden.
Eine Diskussion pro/contra dynamische Typisierung macht keinen Sinn. Das Thema wurde zur genüge durchanalysiert. Alles hat seine vor und seine nachteile.
Ja, da stimme ich dir vollkommen zu.
Deine Kritik an JS ist also, dass es dynamic typing hat?
OK, ich dachte echt schon dass es mal eine sinnvolle diskussion gibt. Ne ne ne ne...
Entschuldigung.
PS:
ich finde solche Diskussionen nicht wert. Denn sie sind so oberflächlich. Das erinnert mich dann immer an eine Mode Diskussion. Aber nein, man kann doch nicht Braun mit Blau mischen, OMG wie furchtbar.Ne, typisierungen haben ihre Vorteile und ihre Nachteile - jeder ernsthafte Programmierer sieht das ein. Natürlich gibt es vorlieben und einige bevorzugen dieses andere jenes - das ist ja kein Problem. Und man kann auch gerne sagen dass sich diese oder jene Sprache nicht gut anfühlt - aber das ist halt keine ernsthafte Kritik an der Sprache.
Ich dachte echt wir haben jetzt was fundiertes. JavaScript hat nämlich historisch bedingt schon einiges kontroverses zu bieten. Aber wir reden hier nur über so primitive Sachen wie Typisierung und Syntax rum.
Über Syntax regt man sich ein,zweimal auf und gewöhnt sich dran.
Aber Typisierung ist nicht auf diesem Level zu sehen.
Typisierung ist keine "so primitive Sache". Typisierung beeinflusst Design, sowohl der Corefeatures als auch der eigenen Programme. Grundlegend.
Ich muss zugeben, ich habe mich oben falsch ausgedrückt:
Erst die Mischung aus dynamischer Typisierung und schwacher Typisierung macht die komplette Sprache, so kaputt, wie sie ist (gut, nciht nur, anderes ist auch nur unintutiv hoch 15).
Beispiel, Operator ==:
0 == 0 -> true, logisch
0 == false -> true, logisch, false ist 0
'0' == '0' -> true, logisch
'0' == 0 -> true, ok, string wird zu Zahl konvertiert
'0' == false -> true, '0' wird zu 0 und 0 ist false
'false' == false -> false, ah ja, ok merken wir uns: Bei verschieden Operanden wird beides offenbar zu einer Zahl konvertiert
null == 0 -> false, was? null ist nicht 0? Das funktioniert sogar in C++! OK, obige Regel gilt nicht mit 0
null == '0' -> false, ok null ist auch nicht 0
null == NaN -> false, ok, das war eigentlich zu erwarten
null == undefined -> true, ah, null ist undefined
null == false -> false, was? wenn etwas false ist, dann doch wohl null!
OK, null ist nicht false, aber !null ist true! Was? null ist nicht false, aber !null ist true! WTF? (Gleiches Spielchen mit undefined)
(Gut, man könnte jetzt mit === argumentieren, aber wo ist das entsprechende für < ? (Beispiel unten))
Weiter:
Logik sagt uns: Wenn !(x < 0) und !(x > 0) dann x == 0.
Javascript sagt: null < 0 = false, null > 0 = false, aber null != 0. Jup, das ist logisch ... nicht.
Der Spaß geht weiter mit Arrays:
[1, 2, 3] < [1, 2, 5] -> true, ok, das ist intuitiv
[1, 3, 1] < [1, 2, 5] -> false, ok, das ist intuitiv
[1, 2, 3] > [1, 2, 3] -> false, ok
[1, 2, 3] < [1, 2, 3] -> false, ok
[1, 2, 3] == [1, 2, 3] -> false, WTF? Das ist gleich! Das ist das selbe Array!
Zum Glück gibts ja noch <= :
[1, 2, 3] <= [1, 2, 3] -> true, ja, ok, wenn dus sagst...function-Objekte:
var func1 = function() {}; var func2 = function() {};func1 < func2 -> false
func1 > func2 -> false
func1 == func2 -> richtig: false, hach ich liebe die Regeln mit < und > bei Javascript... nicht.Und nebenbei:
Math.min() ist nicht kleiner als Math.max(). Jup, Math.min() ist also größer als Math.max()? Ach, nein, ist es auch nicht. Aber sie sind - as always - auch nicht gleich.var foo = [0];foo == foo -> true, logisch, sind ja gleich
foo == !foo -> true, was, sind sie doch nicht? Wie jetzt ist foo jetzt foo oder !foo?
Mein Glaube an die Logik hat sich soeben verabschiedet...
Und der Grund dafür ist dynamische Typisierung. Ist es zuviel verlangt gewisse Operatoren unter gewissen Umständen zu verbieten? Ja?
Ich will über das da oben nicht nachdenken müssen. Ich will es nicht.
Muss ich noch weitermachen?
-
Was du schreibst ist laecherlich. Ich wuerdige das keiner weiteren Antwort. Finde ich schade, denn es gibt vieles was bei JavaScript diskussionswuerdig waere. Aber die typisierung, ne, das ist zum lachen.
-
epTical schrieb:
Ich will einen Fehler, wenn ich mich bei einem Variablenname vertippe und nicht, dass stattdessen eine neue Variable eingeführt wird.
Den bekommst du doch auch oO?! Verwechselst das wohl mit PHP!
Nee, was kriegst du denn da für einen Fehler?
function f() { var namex = 1; namey = 2; // legt ne globale Variable 'namey' an }
-
Shade Of Mine schrieb:
Was du schreibst ist laecherlich. Ich wuerdige das keiner weiteren Antwort. Finde ich schade, denn es gibt vieles was bei JavaScript diskussionswuerdig waere. Aber die typisierung, ne, das ist zum lachen.
Das ist diskussionswürdig!
Hast du meinen Beitrag überhaupt gelesen?Aber da du offenbar keine Lust hast mit mir zu diskutieren, sondern dich lieber wie ein bockiges Kind verziehst, kann der Thread auch geschlossen werden.
Dein Verhalten find ich nämlich lächerlich, aber das hat hiermit nichts zu tun.
-
Nathan schrieb:
Das ist diskussionswürdig!
Nein, ist es nicht.
Das ist Allgemeinbildung für Programmierer. Das Thema kann gegoogled werden, es gibt keine Argumente die neu sind.
-
Shade Of Mine schrieb:
Nein, ist es nicht.
Das ist Allgemeinbildung für Programmierer. Das Thema kann gegoogled werden, es gibt keine Argumente die neu sind.Ist aber eines der Standardargumente gegen PHP und der Grund weshalb in der Sprache === eingeführt wurde, was natürlich aus bestimmten Gründen ebenfalls kaputt ist. logische Operatoren müssen logisch sein. Ich schliße mich da Nathan an: warum gibt es in den obigen Fällen keine Fehler? Warum müssen Objekte, die logisch nicht vergleichbar sind, vergleichbar sein?
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Natürlich kann es Sinn machen und Argumente geben, aber sind diese Argumente auch tragfähig im Vergleich mit den Gegenargumenten?
Wee sieht es da denn noch mit Wartbarkeit und Fehleranfälligkeit aus? Wenn eine Funktion nicht meckert, wenn ein Argument null ist, aber dann irgendein Müll hintenr auskommt, wie soll mand enn den Fehler finden? Muss man wirklich jdes funktionsargument eigenhändig mit typeof und null-tsts guarden?
Ich bin kein Experte in JS, eigentlich sogar ziemlich unbedarft, also von daher die Frage: wie wird das in der Praxis gehandhabt?
------
Ich sehe ein, das man bei einer scriptsprache für das Web keinen Compiler haben will und statische Typisierung sowie Type-checking nicht unbedingt machbar ist. Aber dann muss die Sprache beschränkt sein.
-
otze schrieb:
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Ist es in Java auch nicht. Manche finden Reference-Semantics besser als Value-Semantics.
-
jawas schrieb:
otze schrieb:
Warum ist [1,2,3] == [1,2,3] nicht wahr?
Ist es in Java auch nicht. Manche finden Reference-Semantics besser als Value-Semantics.
Aber 2==2? und müsste bei reference semantik nicht [1,2,3] < [1,2,3] vollkommen undefiniert sein? oder werden die Zeigeraddressen verglichen und das Ergebnis ist zufällig? warum hier value semantik?
-
otze schrieb:
Warum müssen Objekte, die logisch nicht vergleichbar sind, vergleichbar sein?
Ist in C++ auch nicht anders
Das hat mit der automatischen Umwandlung von Typen zu tun. Man beachte zB das safe bool idiom in C++.Warum ist [1,2,3] == [1,2,3] nicht wahr?
Siehe Java.
Weil es nicht das selbe Objekt ist.Du vergleichst hier referenzen.
Wee sieht es da denn noch mit Wartbarkeit und Fehleranfälligkeit aus? Wenn eine Funktion nicht meckert, wenn ein Argument null ist, aber dann irgendein Müll hintenr auskommt, wie soll mand enn den Fehler finden? Muss man wirklich jdes funktionsargument eigenhändig mit typeof und null-tsts guarden?
Willkommen in der Welt der schwachen dynamischen Typisierung. Ich erklaere hier jetzt wirklich nicht was da die Vorteile sind - es laesst sich googlen.
Ich bin kein Experte in JS, eigentlich sogar ziemlich unbedarft, also von daher die Frage: wie wird das in der Praxis gehandhabt?
Einfach mal zB das hier lesen: http://stackoverflow.com/questions/2690544/what-is-the-difference-between-a-strongly-typed-language-and-a-statically-typed
dyanmisch weak typing ist eine Design Entscheidung. Sie bietet vorteile gegenueber strong static typing und nachteile.
btw, JavaScript kennt auch nicht wirklich unterschiedliche Typen nach denen man starkes Typisierung machen koennte - denn alle User Defined Datatypes sind vom Typ Object
Aber OK, machen wir daraus einen JavaScript Anfaenger Fragen Thread. Wenn jemand Fragen hat warum etwas so ist wie es ist in JavaScript, einfach mal fragen.
PS:
was richtig cool waere, ich weiss es ist eine wunschvorstellung von mir, wenn man an ein neues Thema offen heran gehen wuerde. Anstelle von "Ich kenne JS nicht, aber JS muss ja sucken" waere ein "Ich kenne JS nicht, weshalb macht X denn Y in JS?" soviel cooler.
-
Nathan schrieb:
Ich kann mich ja mit der Seltsamen Art Klassen zu "definieren" anfreunden.
Erstes Problem: in Javascript gibt es keine Klassen und wenn man mit der Sprache Spaß haben möchte, sollte man auch aufhören in Klassen zu denken. Das grundlegende Abstaktionsmittel in Javascript ist die Funktion. Diese ist dort sehr viel mächtiger als traditionell in imperativen Sprachen üblich.
Ich kann mich mit Java-like new Syntax zum Erzeugen von Objekten anfreunden.
Genauso gehört auch 'new' in JS zu den Sachen um die man besser einen Bogen macht. Es gibt zwar durchaus ein paar Anwendungsgebiete, aber die ergeben sich dann mit ein bisschen Erfahrung von selbst. Als Anfänger: Finger weg.
In Javascript programmiert man eher wie in Lisp, nicht wie in Java oder C++. Es ist eine nette funktionale Sprache mit C-ähnlicher Syntax. Das kann man nutzen. Man kann sich das Leben aber auch schwer machen, indem man mit einem imperativen oder klassenbasierten OOP-Mindset an die Sache herangeht. Diese Teile der Sprache sind wirklich nicht toll.
Bei C++ sehen die meisten Forenteilnehmer doch auch ein, dass man mit einem Java-Ansatz nicht unbedingt schönen Code schreibt. Das gilt durchaus auch für andere Sprachen.