Sehe ich ganz ähnlich wie du. Die Frage ist, inwiefern sich Scala für den Einsatz in Unternehmenssoftware eignen würde.
Meiner Meinung nach sind für dieses Anwendungsgebiet aber auch in Scala leider schon *zu viele* Sprachfeatures verankert. Man müsste sich schon auf gemeinsame Konventionen im Projekt einigen, dass man gewisse "über-stylische" Dinge bewusst weglässt, damit auch noch andere Leute den Code verstehen können. Gerade von nem Wirtschaftsinformatiker kann man IMHO nicht erwarten, dass der Lust hat, intensiv die Sprachsyntax studieren zu müssen, um ein bestimmtes Codestück nachvollziehen zu können - nichts für ungut.
Das mögen manche hier sicherlich anders sehen, aber für Enterprise-Applications braucht es einfach eine Sprache mit steiler Lernkurve. Das sehe ich beim akademisch angehauchten Scala genau so wenig wie bei Ceylon. In diesem Kontext ist hässlicher Javacode eben doch oft praktikabler - zumal die dahinterstehende Technik sehr leistungfähig ist (gerade im Bereich der Enterprise Edition), was dazu führt, dass man letzlich lieber mit diesem hässlichen Javacode lebt, anstatt umzusteigen.
Und falls jetzt jemand argumentieren möchte, dass man in Scala ja auch native Java-Klassen nutzen kann: Tolle Sache. Aber da haben Unternehmensanwendungen, die relativ viel Gebrauch von diesen noch nicht in Scala integrierten Klassen machen, auch nicht viel. Da kann man dann auch gleich bei "echtem" Java bleiben...
Von Anonymous Coward am Sa, 16. November 2013 um 16:00 #
Meiner Meinung nach sind für dieses Anwendungsgebiet aber auch in Scala leider schon *zu viele* Sprachfeatures verankert. Man müsste sich schon auf gemeinsame Konventionen im Projekt einigen, dass man gewisse "über-stylische" Dinge bewusst weglässt, damit auch noch andere Leute den Code verstehen können. Gerade von nem Wirtschaftsinformatiker kann man IMHO nicht erwarten, dass der Lust hat, intensiv die Sprachsyntax studieren zu müssen, um ein bestimmtes Codestück nachvollziehen zu können - nichts für ungut.
Die Sprachspezifikation von Scala ist kleiner als die von Java. Wenn Du recht hast, dann trifft das auf Java erst recht zu.
Und falls jetzt jemand argumentieren möchte, dass man in Scala ja auch native Java-Klassen nutzen kann: Tolle Sache. Aber da haben Unternehmensanwendungen, die relativ viel Gebrauch von diesen noch nicht in Scala integrierten Klassen machen, auch nicht viel. Da kann man dann auch gleich bei "echtem" Java bleiben...
Unsinn, Scala bietet auch dann enorme Vorteile, wenn man im wesentlichen Java-Bibliotheken einsetzt.
Sehe ich ganz ähnlich wie du. Die Frage ist, inwiefern sich Scala für den Einsatz in Unternehmenssoftware eignen würde.
Meiner Meinung nach sind für dieses Anwendungsgebiet aber auch in Scala leider schon *zu viele* Sprachfeatures verankert. Man müsste sich schon auf gemeinsame Konventionen im Projekt einigen, dass man gewisse "über-stylische" Dinge bewusst weglässt, damit auch noch andere Leute den Code verstehen können. Gerade von nem Wirtschaftsinformatiker kann man IMHO nicht erwarten, dass der Lust hat, intensiv die Sprachsyntax studieren zu müssen, um ein bestimmtes Codestück nachvollziehen zu können - nichts für ungut.
Das mögen manche hier sicherlich anders sehen, aber für Enterprise-Applications braucht es einfach eine Sprache mit steiler Lernkurve. Das sehe ich beim akademisch angehauchten Scala genau so wenig wie bei Ceylon. In diesem Kontext ist hässlicher Javacode eben doch oft praktikabler - zumal die dahinterstehende Technik sehr leistungfähig ist (gerade im Bereich der Enterprise Edition), was dazu führt, dass man letzlich lieber mit diesem hässlichen Javacode lebt, anstatt umzusteigen.
Und falls jetzt jemand argumentieren möchte, dass man in Scala ja auch native Java-Klassen nutzen kann: Tolle Sache. Aber da haben Unternehmensanwendungen, die relativ viel Gebrauch von diesen noch nicht in Scala integrierten Klassen machen, auch nicht viel. Da kann man dann auch gleich bei "echtem" Java bleiben...