Welche Sprache für ehemaligen Turbo Pascal Fan

[accC]

Das ist sinnlos. Klar kommt da quatsch raus, weil es nicht sinnvoll ist. In anderen Programmiersprachen gibts einen Fehler, in Javascript kann man das tun, wird aber nicht damit arbeiten können. Gesunden Menschenverstand sollte man schon an den Tag legen, wenn man eine Programmiersprache lernt.

Eine gute Programmiersprache lässt dich das gar nicht tun oder macht es dir mindestens schwer es zu tun. Wenn du das bei Java versuchst, wird das Programm nicht einmal kompilieren. Das Problem ist ja nicht, dass jemand bewusst ein Objekt erzeugt und es mit einem Array addiert, so dämlich ist niemand. Bei einer riesigen Webapplikation mit mehreren hunderttausend Zeilen Code und mit dynamischer Typisierung und Typumwandlung, glaubst du wenn da hunderte Programmierer sitzen, weiß ein Programmierer genau, welche Art Rückgabe er wo an welcher Stelle zu erwarten hat? Ich beantworte dir die Frage: Nein!

Oha, du siehst keinen Markt? Nun, andere sehen einen.

Der Windows 8 Store hat keinen ernst zu nehmenden Markt. Dazu hat Microsoft lange nicht mehr die Position um es zu erzwingen und freiwillig nehmen die User das nicht an. Das hat man doch gemerkt.

Und erstens ist es nicht Ziel eines Programmiereinsteigers Programme für einen breiten Markt zu schreiben und zweitens war das nur ein Teil der Aussage

Wonach urteilst du dann, dass er JavaScript verwenden sollte, du redest die ganze Zeit von den Potentialen und dann sagst du selbst, dass es gar nicht interessiert.

Für viele Browser kann man Plugins mit Javascript schreiben, außerdem GTK, Qt, etc.
Das ist ein Vorteil.

Richtig und du musst nur die eigenarten von den verschiedenen JS-Engines und Browsern kennen, um JavaScript zu schreiben, das sich auf jeder Hardware/Software deterministisch verhält. Das ist ein gottverdammtes Nachteil. Was glaubst du, was jQuery für einen Abriss betreibt, damit sich mittels dieser Bibliothek erstellte Software deterministisch verhält?

Ich habe Javascript auch nicht als beste Einsteigersprache verkaufen, sondern nur dem JS-Bashing entgegenwirken wollen. Mein ursprünglicher Vorschlag war Python.

Ich lehne JavaScript auch nicht gänzlich ab. Ich denke nur, dass es je nach Zweck wesentlich dankbarere Programmiersprachen gibt. Java ist auch nicht perfekt und C / C+ / C# genauso wenig. Keine Programmiersprache ist 'perfekt'. Es kommt immer auf das Anliegen an. Wenn ich jemandem eine Sprache empfehlen sollte, ohne dass er speziellle Anforderungen stellt, würde ich ihm nicht gerade eine empfehlen, die kaum bis keine Unterstützung bietet. Gerade für solche Zwecke eignet sich eine Sprache, die gängelt ganz besonders.

 

[misterunknown]

Bei einer riesigen Webapplikation mit mehreren hunderttausend Zeilen Code und mit dynamischer Typisierung und Typumwandlung, glaubst du wenn da hunderte Programmierer sitzen, weiß ein Programmierer genau, welche Art Rückgabe er wo an welcher Stelle zu erwarten hat? Ich beantworte dir die Frage: Nein!

Das stimmt, ist aber von einem Einsteiger nicht unbedingt zu erwarten. Wie gesagt: Die Diskussion handelte sich mittlerweile um Javascript grundsätzlich.

Was glaubst du, was jQuery für einen Abriss betreibt, damit sich mittels dieser Bibliothek erstellte Software deterministisch verhält?

Ich kenne die Probleme, die Javascript hat. Deterministisch verhält es sich aber auch beispielsweise auf Node.Js-Basis. Und browserseitig ist ja die Benutzung einer Bibliothek wie jQuery nicht verkehrt.

Wenn ich jemandem eine Sprache empfehlen sollte, ohne dass er speziellle Anforderungen stellt, würde ich ihm nicht gerade eine empfehlen, die kaum bis keine Unterstützung bietet. Gerade für solche Zwecke eignet sich eine Sprache, die gängelt ganz besonders.

Stimmt. Java bzw. C# auf konsolenbasis eignen sich daher wahrscheinlich am besten, da die meisten Skriptsprachen ja dynamisch typisiert sind.

 

[LemonDrops]

Das Problem ist ja nicht, dass jemand bewusst ein Objekt erzeugt und es mit einem Array addiert, so dämlich ist niemand. Bei einer riesigen Webapplikation mit mehreren hunderttausend Zeilen Code und mit dynamischer Typisierung und Typumwandlung, glaubst du wenn da hunderte Programmierer sitzen, weiß ein Programmierer genau, welche Art Rückgabe er wo an welcher Stelle zu erwarten hat? Ich beantworte dir die Frage: Nein!

Wenn der Programmierer dass nicht weiß, sollte er es in Erfahrung bringen. Kann er es nicht in Erfahrung bringen, ist das nicht das Problem von Javascript, sondern ein Problem der Professionalität. Wir haben eine Dokumentation und Unit-Tests. Ich kann also ganz einfach sagen was eine Funktion zurück gibt und ob sie funktioniert. Es ist kein Problem genau das per Return zurück zu geben, was man möchte.
Wenn jemand zwei Objekte addiert (Arrays gibt es in Javascript nicht als eigenständigen Typen, es gibt nur einen Constructor für ein Array Objekt) ist das problematisch, sollte aber nicht passieren. Läuft man Gefahr, dass das möglich ist, dann kann man darauf prüfen. Das ist kein Problem von JS, es ist ein Problem der Unerfahrenheit. Ein Fehler wird irgendwann auftreten, spätestens im Unit-Test werde ich sehen, dass meine Methode nicht wie erwartet funktioniert.


Es gibt Teile an Javascript die nicht toll sind, aber diese muss man nichts nutzen. Dafür gibt es Tools wie JS-Lint die einem dabei helfen solche Dinge zu vermeiden. JS hat aber auch viele gute und sehr gute Ansätze. Es ist mächtig und hat viele Vorteile, mit großer Macht kommt große Verantwortung. Letztendlich gibt es keinen Grund sich für JS schlecht zu fühlen. JS ist sehr beliebt und eine der wichtigsten Sprachen die wir haben. Entwickler sind gesucht und verdienen gutes Geld.

 

[Brother John]

Ich bin noch immer der Ansicht: Das richtige Tool für die passende Gelegenheit.

+1

Hab nochmal mit ihm gesprochen. Lazarus gefällt ihm scheinbar

Wäre nicht meine erste Wahl, genau wegen der angesprochenen Ressourcenmanagement-Problematik. Aber besser Lazarus, als dass er mit einer anderen Sprache, mit der er sich weniger wohlfühlt, aus Frust auf der Strecke bleibt. Sprache wechseln ist einfacher als man gerade als Anfänger denkt – es sei denn, man will auf einer Plattform zum echten Guru werden.

Ein Fehler wird irgendwann auftreten, spätestens im Unit-Test werde ich sehen, dass meine Methode nicht wie erwartet funktioniert.

*Falls* es denn einen Test genau dafür gibt und *falls* der Programmierer den auch laufen lässt. Das ist der Vorteil vom statischen Typsystem + Compiler. Ich habe die *Garantie*, dass der Fehler erkannt wird anstatt nur eine mehr oder weniger hohe Wahrscheinlichkeit. Dynamische Typisierung hat ihre Vorteile. Geringe Fehleranfälligkeit out-of-the-box gehört eher nicht dazu.

 

[Larius]

Ein Fehler wird irgendwann auftreten, spätestens im Unit-Test werde ich sehen, dass meine Methode nicht wie erwartet funktioniert.

Nein. Ganz klares nein an dieser Stelle von mir. Du kannst keinesfalls mit Unittests eine 100% Garantie darauf geben das dein Code so, wie er dort steht, funktioniert. Aus einem einfachen Grund nicht: Betriebsblindheit. Du weißt als Entwickler was die Funktion tut, du testest es genau auf diese Eigenschaften drauf. Wenn da aber jetzt jemand verdammt lustig ist und den Server in so einen undefinierten Zustand bekommt das auf einmal deine Funktion rumzickt kannst du nicht einfach hergehen und sagen "Aber meine Unittests zeigen das ich keine Schuld habe!". Genauso kannst du zwar eine 100% Zweig/Pfadabdeckung haben und wirklich alles pipifein getestet haben aber dann greifst du auf 1 Klassenvariable zu deren Wert undefiniert ist weil eine Exception geflogen ist vor dem Initialisieren und dann hast du den Arsch bis zu den Ohren offen. Mit solchen Aussagen wäre ich also verdammt vorsichtig.

Genauso ist eine Dokumentation nur so gut wie sie auch gepflegt wird. Wenn nicht jede Änderung dokumentiert bzw. nachgetragen wird kannst du nicht genau sagen was eine Funktion zurückliefert. Ja du kannst Annahmen anhand des Funktionsnamen treffen aber du kannst nicht zu 100% sagen ob dir die Funktion "GetUserFromDatabase" nicht doch nur einen Int-Wert zurückliefert weil der User in einer Klassen-Variable steht und True/False auf Int abgeändert worden ist weil irgendjemand lustig war bzw. nicht nachgedacht hat.