Jede Programmiersprache hat ihre Eigenheiten, Vor- und Nachteile. Man kann zwar mit JavaScript auch Server-Anwendungen schreiben, das ist aber aufgrund der spezifischen Nachteile von JavaScript mit starken Schmerzen verbunden (was manche Firmen nicht davon abhält).
Da stimme ich dir schon zu, aber das hängt nicht selten mit der jeweiligen Problemstellung zusammen und oft, weniger als man denkt mit "Ah, das ist Server, GUI, ...". Ein paar Unternehmen (Microsoft, das neue MySpace, etc.) würden dir da wohl widersprechen. Es liegt dann meist viel mehr an den Einzelheiten, als man denkt. Wenn du dir so die Top 500 Websites ansiehst hast du da Implementierungen von C, über Python, Perl, Java, Scala bis hin zu JavaScript und diversen LISP-Dialekten. Alles erfolgreiche Projekte.
Ich würde mich von den Diskussionen hier nicht verwirren lassen und erstmal mit einer Sprache anfangen und vertraut werden (z.B.
Python), bevor man in die "
analysis paralysis" abgleitet und gar nicht erst anfängt.
Wieder kommt es darauf an was man wirklich spezifisch macht und genau da liegt das Problem. Man kann Sprachen nicht wirklich einteilen. Weil du Python erwähnt, was so häufig erwähnt wird. Ich hatte schon einige Projekte, wo ich ständig über die Dinge gestolpert bin, die erst Python 3 fixen würde. Das sind generell betrachtet Feinheiten, aber auch wenn Python für das konkrete Projekt, rein an den groben Eigenschaften wohl von den meisten Leuten als gute Wahl gesehen werden würde, war es wie sich herausstellte das Unsinn. Python 3 andererseits hat keine Community und ich sehe mittlerweile Parallelen zu Perl 6 und Python 2
Korrekt. Mit steigender Projektgröße verkehrt sich so mancher Vorteil (z.B. dynamische Typisierung) in einen Nachteil um. So mancher Nachteil (z.B. die Abwesenheit von Namespaces) wird so richtig eklig. Mit steigender Projektgröße kommen auch andere Vorzüge einer Sprache (z.B. Qualität der IDEs, Ökosystem, etc.) viel stärker zum Tragen.
Da stimem ich dir ebenfalls teilweise zu. Generell haben aber größere Projekte auch das Problem, das viele und vor allem viele schlechtere Programmierer drin sind. Dynamische Programmiersprachen eignen sich eher für Leute mit Selbstdisziplin, die von Anfang an Tests schreiben, ihren Code anständig dokumentieren, etc. Sollte man auch mit statischen Programmiersprachen machen. Aber grundsätzlich stimme ich dir da zu, weil du da eben schönere Interfaces hast, die erzwungen wurden und viele Leute, die dynamische Sprachen nutzen sehr faul sind und unstrukturiert arbeiten. Leider führen andererseits statische Sprachen und vor allem sehr stark typisierte Sprachen und große Dev-Teams dann auch immer mal wieder in eine Richtung, wo man genau dieses Minimum hernimmt und sagt "Die Sprache wird's schon richten". Dann ist der Code trotz Typisierung mies und alle versuchen ständig alles "irgendwie" zum Laufen zu bekommen. Ist zumindest meine Erfahrung. Will damit auch niemanden zu nahe treten, aber ich hab das alles schon gesehen und mir einen Reim daraus gemacht. Ist wohl entsprechend subjektiv.
Manche Zeitgenossen treffen aber auch einfach völlig unreflektiert Aussagen, obwohl sie offensichtlich noch nie Software jenseits von "Hello World" entwickelt, geschweige denn in einem größeren Projekt gearbeitet haben.
Jup. Wenn dann noch Hypes und irgendwelche Gurus, die als Götter verehrt werden und Elitarismus wie es ihn in vielen Projekten lange Zeit gab reinspielt, so in Richtung "Unsere Sprache ist unfehlbar und perfekt", dann wird's ganz grauslich und man neigt schon mal eine Sprache auf Grund der miesen Community nicht zu nutzen.
Es gibt Sprachen, die beherbergen so viele unangenehme subtile Überraschungen, dass selbst fähige Leute - auch nach jahrelanger Beschäftigung mit der Sprache - immer wieder auf die Schnauze fallen. Die Unzulänglichkeiten der Sprache den Anwendern in die Schuhe zu schieben, halte ich für den falschen Ansatz. Die Diskussion sollten wir aber gegebenenfalls in einem separaten Thread führen.
Da hast du Recht, aber ich habe ehrlich gesagt noch keine Sprache gesehen, wo das nicht der Fall ist. Sogar in purem C gibt es einige davon. Überraschungen gibt es in C, Java, Python, ... genauso wie in JavaScript und Perl. Manchmal finde ich da Sprachen wo mit denen zu rechnen ist, aber sogar angenehmer, weil sich die Leute damit beschäftigt haben und da meistens irgendetwas ganz laut schreit. Wenn man seine Sprache als quasi unfehlbar sieht und sich das so lange durch schummelt schlägt es mitunter in Production auf. Soll aber nicht heißen, dass ich deiner Aussage nicht zustimme. Das sind Randfälle, die ich einfach schon gesehen habe und die vor allem in Java und Python auftreten, weil die Einstellung dort solche Probleme ermuntert. Kurzum: Ich stimme dir zu, auch wenn ich durchaus Real Life Ausnahmen kenne.
Manchmal gibt es aber Rahmenbedingungen bei Entwurf und Weiterentwicklung einer Sprache (z.B. Abwärtskompatibilität), die zu einem sehr zweifelhaften Resultat führen können, auch wenn fähige Leute daran sitzen.
Vollste Zustimmung. Wollte damit aber eigentlich ausdrücken, dass immer mal wieder Gedanken hinter einem Feature stehen, die man erkennen muss bevor man weiß, um zu verstehen wie man damit umgeht. Um's klar zu machen: Es ist blöd, wenn die schwer ersichtlich sind, das unterschreibe ich gern, nur kann dieses schwer ersichtlich sein daran hängen, dass man zuvor mit Sprachen gearbeitet hat, die schlicht und ergreifend einen anderen Ansatz haben und nicht so funktionieren wie man es gewohnt ist. Jemand der sein ganzes Leben mit Unix zu tun hatte wird ein anderes System mitunter sehr schwer verstehen. Ist ein wenig wie mit natürlichen Sprachen. Wenn du Deutsch kannst ist Englisch für dich meist einfacher, als Japanisch. Für jemanden, der Chinesisch kann wird Englisch wohl schwerer sein.
Das gab es zu allen Zeiten (Cobol lässt grüßen). Nach ein paar Jahren in der Branche wartet man aber gerne den "
hype cycle" ab, bis aus dem Hype etwas Brauchbares geworden ist. Über den Tellerrand sollte man natürlich trotzdem schauen, die Welt bleibt nicht stehen.
Vor allem hat man dann auch ein schönes Ecosystem, einen Jobmarkt, etc. Ich glaube es ist auch eine Frage, wieviel Risiko für ein Projekt angedacht ist. Wenn du schnell irgendwas, proof-of-concept-mäßig hinhauen willst/musst, dann ist eine dynamische "unsaubere" Sprache, die gerade einen Hype erfährt, auf die neuen Technologien setzt, die du brauchst und es da viele entsprechende Libraries gibt, du keine Altlasten hast, etc. vielleicht eine exzellente Wahl. Kommt nicht von Ungefähr, dass Ruby das große Ding war und jetzt alles ihre WebSocket-Geschichten und Demos mit JavaScript-Servern machen (Mozilla zum Beispiel). Das ist aber für große Projekte vielleicht nicht so toll. Twitter hatte ja genau dieses Problem. Zunächst auf Ruby on Rails aufgesetzt, dann JRuby verwendet, dann auf andere JVM-Sprachen gegangen, weil ihr Prototype den Proof of Concept geliefert hat, aber dann Scaling ein Problem wurde. Andererseits hätten sie wenn sie mit Java begonnen hätten mitunter das Problem gehabt, dass alles ein Weilchen länger gedauert hätte, sie keine Investments oder User bekommen hätten und gestorben werden. Vielleicht auch nicht.
Was ich mit dem ganzen nur sagen will ist, dass man als Programmieranfänger meist (es betraf mich und alle, denen ich dabei zugesehen habe) einfach zwei Probleme hat. Sprachen ganz starr in Kategorien einteilen und quasi nicht wirklich zu verstehen, dass du alles mit jeder Sprache machen kannst (auch wenn sie vielleicht von vielen aus guten und schlechten Gründen nicht für das Richtige gesehen wird) und zweitens aus diversen Gründen zwischen Sprachen zu hoppeln und nie wirklich eine zu verstehen, was aber notwendig ist und für die Zukunft helfen wird. Deshalb habe ich beides erwähnt: Über den Tellerrand schauen ist nicht schlecht, aber dafür sollte man extrem viel Zeit einplanen, weil man sich für gewöhnlich durch vieles durchackern muss und ernsthafte, große Projekte schreiben muss bevor man eine Aussage trifft. Viele tun das nicht. Dann hat man vor allem in dynamischen Sprachen das Problem, dass jemand von C kommt und der Code dann (weil dynamische Sprachen flexibel sind) dann auch wie C-Code aussieht (vielleicht auch weil die Syntax angelehnt ist) und am Ende meint man die Sprache sei mies, weil man die Vorteile, die Philosophie dahinter und die Gedanken des Entwicklers der Sprache nie wirklich verstanden hat. Gerade am Anfang ist es deshalb extrem wichtig mal eine Sprache zu nehmen und wirklich zu verwenden, auch wenn man auf Probleme stößt. Die wird man einfach finden. Wenn es die perfekte Sprache gäbe, dann würden sie ja alle schon längst verwenden.
Ist auch ganz witzig. Meist. wenn eine neue Sprache aufkommt, kann man schon vorhersagen, wer drauf aufspringen wird und wer nicht. Aber ich drifte echt ab. Sorry!
