Scala Scala-Kritik

[Landei]

Stephen Colebourne vergleicht Scala mit EJB2: Stephen Colebourne's blog: Scala feels like EJB 2, and other thoughts

Ehrlich gesagt kann ich sowas nicht verstehen, insbesondere weil ich weiß, wie es ist, mit EJB2 zu arbeiten. Scala ist ziemlich genau das Gegenteil davon. Sicher, einige der angesprochenen Punkte haben etwas für sich (und es wird auch an manchen noch gearbeitet), aber der Vergleich hinkt nicht, sondern er hat keine Beine. Zumindest die Kommentare sind interessant.

 

[SlaterB]

The trouble is that despite the pleading of aficionados, method signatures like this abound:

[c] def ++ [B >: A, That] (that: TraversableOnce)(implicit bf: CanBuildFrom[List[A], B, That]) : That[/c]

If you don't know Scala, you wouldn't have a hope of attempting to understand the code. In fact this is the equivalent to Java's addAll() on a list. (Its so complex that Scala tries to hide it from you in the documentation by giving you a simpler form instead.)

solche Sprachen wie Scala hatten von Anfang an keine Chance

 

[schlingel]

Mr. Colebourne ist ja dafür bekannt auf Scala herumzuhacken wo er kann. Wobei das von SlaterB zitierte Beispiel tatsächlich absurd komplex ist.

Aber EJB2 - obwohl auch teilweise viel zu komplex - ist etwas anderes. Hier hat man versucht einen Standard für ein LOB-Framework zu schaffen das es allen recht macht. Raus gekommen ist eine Kompromisslösung die teilweise nicht sehr glücklich ist.

2 verschiedene Baustellen, wenn man mich fragt. Edit:/ Colebourn hat klargestellt warum er die zwei Technologien vergleicht und IMHO auch nachvollziehbar. Hier nachzulesen.

Die Komplexität die auch noch mit einer noch nicht gesetzten API einhergehen zu scheinen hat ja auch Yammer dazu bewegt wieder ein Stückchen (nicht ganz!) von Scala wegzurücken.

Generell finde ich das alles ganz schade. Scala hat sehr vielversprechend ausgeschaut aber mittlerweile interessiert mich Clojure mehr.

Scala is @playframework. Anybody saying it feels like EJB 2 has understood nothing or is spreading FUD.

Quelle

Der Herr Odersky ist natürlich nicht sehr zufrieden dass da ein Anti-Scala Evangelist so viel Aufmerksamkeit bekommt =D

 

[schalentier]

[Bei EJB2] hat man versucht einen Standard für ein LOB-Framework zu schaffen das es allen recht macht. Raus gekommen ist eine Kompromisslösung die teilweise nicht sehr glücklich ist.

Nuja, je nach persoenlicher Perspektive, trifft das doch im Grunde auf Scala zu: Man hat versucht, eine Sprache zu schaffen, die alles kann (OOP, Funktional, ...) und ein komplexes Typsystem hat. Herausgekommen ist eine Loesung, die das zwar realisiert, aber in ihrer Komplexitaet zu ersticken droht.

So weit hergeholt ist der Vergleich imho nicht. Aber das ist ja nur ein kleiner Punkt, aus der doch recht umfangreichen Kritik ;-)

 

[AngryDeveloper]

Die Methode ist allerdings nicht das Äquivalent zu addAll() in Java. Für die ++ Methode hat Java gar kein Äquivalent.

 

[Marco13]

Ich habe mich noch nicht so intensiv mit Scala beschäftigt, wie ich es... ... gerne würde (oder würde, wenn ich nicht 8 Stunden am Tag arbeiten müßte) ... aber nach dem, was ich bisher gesehen habe, denke ich, dass Scala she viel Potential hat. Ein nicht unerhebliches Problem ist aber (IMHO und aus meinem eingeschränkten Blickwinkel!) dass es sehr viele Möglichkeiten bietet, die man "normalerweise" nicht braucht, und es scheint mit, als würden Codebeispiele schnell zu akademischen Schw.vergleichen a la "Guckt mal, mit was für kurzen (kyptischen) Zeilen man ganz viel erreichen kann". Der Einstieg wäre vermutlich leichter, wenn man sich an manchen Stellen auf's wesentliche beschränken würde, und eher pragmatische Lösungen, guter Stil und best practices vermittelt würden (die "fancy" Sachen entdeckt man später automatisch)

 

[fastjack]

Fakt ist die Syntax, die bei einer imperativen Sprache wie Java/C# und Co. nun mal für den Normalentwickler perse leichter zu lesen ist, als bei einer funktionalen. Wenn man funktional gut drauf ist und vielleicht schon Miranda/Haskell gemacht hat, hat man erheblich weniger Probleme mit Scala und Co. Es gibt natürlich auch imperative Ausnahmen. In wie weit jetzt die Hybridsprachen Vorteile bringen, wird die Zeit zeigen. Was ist eigentlich aus F# geworden?

Man sollte allerdings die vielen Vorzüge der funktionalen nicht unterschätzen. Aber Knackpunkt ist und bleibt, denke ich, immer die Syntax. Ok, manche sagen Scala ist leicht und einfach, weil sie funktional schon Erfahrungen hatten, aber diese Erfahrungen hat nicht jeder Entwickler.

P.S.: Natürlich werden bei so einem Vergleich (der von vornherein negativ auf Scala wirkt) wenige, bis gar keine Vorteile von Scala gebracht.

 

[schlingel]

F# wird immer mehr in die .Net-Welt integriert und spielt mittlerweile tatsächlich eine Rolle. Allerdings befürchte ich, dass in Zukunft Windows RT das selbe Schicksal für .Net bedeutet dass auch Java erlitten hat.
Ganz gut für Webentwicklung und LOB-Software aber nichts für Desktopprogramme. Außerdem ist F# mehr FP als OOP. Bei Scala ist das IMHO anders herum und F# hat zudem auch kräftige Unterstützung da MS hinter dem Projekt steht.
Scala hat ja nicht so eine große Rückendeckung wie die von MS. Z.B. ist ja F# auch die einzige Sprache die auch eine ausgzeichnete IDE gestellt bekommt. Der Vorteil das Sprachdesigner und IDE-Programmierer im "selben" Haus sitzen darf nicht unterschätzt werden.


PS: Ich glaube das imperative Programmiermodel ist genauso schwer/leicht nachvollziehbar wie das deklarative. Bei SQL habe ich auch noch nie jemanden sagen gehört der 0815-Coder wäre zu blöd dafür obwohl das auch dem deklarativen und nicht dem imperativen Model entspricht.

 

[fastjack]

Bei Scala ist das IMHO anders herum und hat kräftige Unterstützung da MS hinter dem Projekt steht

ok

Scala hat ja nicht so eine große Rückendeckung von MS

ist das nicht ein Widerspruch?!

 

[schlingel]

Hoppala, F# hat natürlich die kräftige Unterstützung und nicht Scala.

 

[fastjack]

Ok. Der Vergleich den Du mit SQL gemacht hast ist interessant. SQL ist von der Syntax her bei weitem nicht mit der von funktionalen Programmiersprachen zu vergleichen. Das spricht eigentlich schon wieder für das Syntaxargument. Es sind doch vielmehr verschiedene Denkweisen, die hinter beiden Konzepten stehen, einmal funktional und einmal imperativ, das bezieht sich dann auch auf die Syntax. Ob die Vermischung was bringt, wird die Zukunft zeigen. Hast Du schon mal mit Haskell eine GUI gebaut? Dann weist Du was ich meine.

Und nur mal so nebenbei: Ich habe nicht geschrieben das ein Entwickler zu blöde ist Scala zu programmieren, sondern das ein normaler Entwickler nun mal meistens mehr imperative Erfahrungen mitbringt.

[edit]SQL ist eine Abfragesprache, keine funktionale Sprache. Beides wiederum sind aber deklarative Sprachen.[/edit]

 

[schlingel]

SQL hat eine deutlich komplexere Syntax als z.B. Lisp. Das ändert dennoch nichts daran, dass beide deklarativ programmiert werden. Haskell ist dann natürlich wieder deutlich komplexer als SQL aber das hat auch mit dem Typsystem zu tun. (Schau z.B. mal in OCamel oder eben auch Lisp rein)

Es geht um die Art wie Probleme gelöst werden. Eine Umstellung passiert nie ganz schmerzlos und sich als OOP-Coder auf FP einzulassen ist IMHO schwieriger als, als C-Entwickler auf OOP umzusteigen aber das hängt nur mit eingefahrenen Denkmustern zusammen.

Natürlich möchte ich auch keine UI mit Prolog oder Haskell schreiben (bei Haskell hab ich's schon probiert, brrr ...) da das Objektmodell wie die Faust aufs Auge passt wenn es um die Gestaltung von Oberflächen geht. Dementsprechend setzen sich ja auch immer mehr XML-Technologien als UI-Technologien durch. (Android, WPF/Silverlight, HTML5, etc.)

In diesem Fall sage ich einfach einmal die Mischung macht's.

 

[Landei]

Nur zur Klarstellung: Die Kritik an der ++-Methode ist völlig daneben. Die komplizierte Signatur ist nötig, weil die Methode komplizierte Dinge macht: Verkettet man eine Integer-Liste mit einer Integer-Liste, kommt eine Integer-Liste heraus. Verkettet man eine String-Liste mit einer Integer-Liste, kommt eine Any-Liste heraus (Any ist in etwa java.lang.Object). Verkettet man eine Integer-Liste mit einer Integer-Sequenz (Ober-Trait von Liste), kommt eine Integer-Sequenz heraus. Die Methode verhält sich also sehr "intelligent" und tut ihr bestes, um den "vernünftigsten" Rückgabetyp zu liefern. Bei der Nutzung der Methode braucht einen das alles nicht zu kümmern, da ist einfach toll, dass das Ding tut "was es soll".

 

[Marco13]

Bei der Nutzung der Methode braucht einen das alles nicht zu kümmern, da ist einfach toll, dass das Ding tut "was es soll".

Das ist einer der Aspekte, die ich oben andeuten wollte, aber nicht so direkt angedeutet habe: Wenn man als Java-Entwickler wissen will, was z.B. ein ArrayList#addAll macht, dann macht man STRG+Klick auf den Methodennamen, und sieht, was dort passiert. Bei Scala ist das nicht mehr so einfach, weil man schnell bei solchen "Monstern" wie dem ++ landet - da hilft weder Code noch API-Doku, es IST einfach kompliziert. Das ist keine Kritik: Vielleicht ist sie im Einstein'schen Sinne gerade so kompliziert, wie sie sein MUSS ... aber zumindest hat mich das ein bißchen abgeschreckt....

 

[schalentier]

Bei der Nutzung der Methode braucht einen das alles nicht zu kümmern, da ist einfach toll, dass das Ding tut "was es soll".

Schoen, und was wenn es mal nicht das tut, was es tun sollte? Also wenn sich ein Bug in einem solchen Monster versteckt?

Nach der gaengigen Argumentation pro Scala heisst es ja immer, solche kruden Zeilen sieht man als "Endanwender" eh nicht, weil das ja nur versteckt in Frameworks so aussieht. Das is aber imho Quatsch, auch als Benutzer moechte ich gerne die Methoden verstehen, die ich benutze. Natuerlich nicht immer, aber besonders dann, wenn mal irgendwas nicht so klappt, wie ich es erwarten wuerde.

Wenn ich mir dann vorstelle, wie es waere mich durch hunderter solcher Zeilen quaelen zu muessen... Ganz ehrlich, da schreib ich die addAll Methode lieber fuenfmal mit verschiedenen Parametern oder mach am Ende nen ach so boesen Cast.

 

[darekkay]

Aber trifft das nicht auch auf Java (und alle andere Sprachen) selbst zu?

Angenommen man hat noch nie den Ausdruck

int muh = "muh".equals("muh") ? 1 : 2;

gesehen. Auf den ersten Blick nicht verständlich (obwohl herleitbar). Hat man es einmal gelernt, so findet man Stellen, wo dieser Code gut passt (was auch nicht immer der Fall ist). Hier tut's aber bestens - ich find's jedenfalls einfacher, als

int muh = 0;
if(muh.equals("muh"){
 muh = 1;
}
else{
 muh = 2
}

Hat man sich erstmal in Scala eingearbeitet und kann ihre Syntax gut beherrschen, versteht man solche "Monster" auch. Man kann doch nicht sagen: "hey, ich kann Java, kann aber diesen Scala-Ausdruck gar nicht verstehen. Er sieht aber ziemlich böse aus.". Java != Scala.

 

[Landei]

@Schalentier: Na gut, wenn du es genau wissen willst:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

[c]TraversableOnce[/c] ist das anzuhängende Stück. [c]CanBuildFrom[/c] ist ein implizites Argument (es gibt also in einem Kontext einen Default-Wert, wenn man selber keinen angibt). Es codiert, was das "beste" Resultat ist, was wir bekommen können. Ein [c]BitSet[/c] kann z.B. als [c]Traversable[Bool][/c] angesehen werden. Wenn ich zwei [c]BitSet[/c]s verkettet werden, oder ein [c]BitSet[/c] und ein [c]Seq[Bool][/c], gibt es ein [c]CanBuildFrom[/c], das aussagt, dass da auch wieder ein [c]BitSet[/c] rauskommen kann. Wenn ich aber ein [c]BitSet[/c] mit einer [c]List[Int][/c] verketten will, wird nur ein allgemeineres [c]CanBuildFrom[/c] gefunden, dass dann nur einen Typ wie [c]Seq[Any][/c] erlaubt. Wenn du eigene Datentypen hast, kannst du dir entsprechende implizite [c]CanBuildFrom[/c]-Objekte schreiben, um "intelligente" Konvertierungen zu erlauben.

 

[SlaterB]

@darekkay
es gibt solche und solche Syntaxen,
mit Java-Kenntnissen kann man sich sofort oder mit wenig Mühe in C++, Pascal und allen zivilisierten imperativen Programmiersprachen,
vergangene, heutige und zukünfige, zurechtfinden,
manche Sprachen gehen aber so strukturell anders vor, dass es keinen Zugang für die Allgemeinwelt gibt, nur für wirklich begeisterte

sicher ist es auch zu lernen, aber vielleicht so wie man eine Fremdsprache lernt,
das ist für manche auch ein Klacks, für viele aber lebenslang eine Mühe,
Java & Co. sind die Muttersprache

 

[darekkay]

@darekkay
es gibt solche und solche Syntaxen,
mit Java-Kenntnissen kann man sich sofort oder mit wenig Mühe in C++, Pascal und allen zivilisierten imperativen Programmiersprachen,

Dass man sich mit imperativen Kenntnissen in eine funktionale Sprache nicht sofort einarbeiten kann, ist aber irgendwie klar, oder?
Ich habe nie mit Scala programmiert, kenne aber die Schwierigkeit beim Umdenken auf funktionale Sprachen (Haskell & Co.). Und so scheint es mir logisch, dass man ohne Einarbeitung eben nicht sofort losprogrammieren und alles verstehen kann.

 

[SlaterB]

wozu dann dein Vergleich mit dem ?-Operator?
dein vorheriges Posting klang ja eher nach 'das ist xy nur mit neuen Namen'
na wie auch immer

inwiefern Java einerseits so leicht und bekannt wie das imperative Java sein soll
und anderseits so fremdartiges neues enthält, ist gewiss der Grundkonflikt, ja

 

[darekkay]

wozu dann dein Vergleich mit dem ?-Operator?
dein vorheriges Posting klang ja eher nach 'das ist xy nur mit neuen Namen'
na wie auch immer

Ok, diesen Vergleich hätte ich mir eigentlich sparen können. Sollte aber mehr oder weniger klarmachen, dass komplizierte Ausdrücke (welcher Art auch immer) wenn erstmal gelernt sind, nicht mehr so kompliziert sind. Eine Antwort auf "Omg, soooo ein unverständlicher Code, gut dass ich die Sprache nicht lernen werde/muss".

 

[SlaterB]

Nachtrag:
über SQL, Lisp und wer weiß was würde sich kaum jemand beschweren,
die haben nebenbei gesprochen ebenso etwas sauberen Aufbau meiner Meinung nach,

vor allem versuchen sie aber eben nicht gleichzeitig imperativ/ wie Java zu sein,
daher wird Scala immer die volle Härte an Kritik abbekommen

 

[schalentier]

@Schalentier: Na gut, wenn du es genau wissen willst:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

[c]TraversableOnce[/c] ist das anzuhängende Stück. [c]CanBuildFrom[/c] ist ein implizites Argument (es gibt also in einem Kontext einen Default-Wert, wenn man selber keinen angibt). Es codiert, was das "beste" Resultat ist, was wir bekommen können. Ein [c]BitSet[/c] kann z.B. als [c]Traversable[Bool][/c] angesehen werden. Wenn ich zwei [c]BitSet[/c]s verkettet werden, oder ein [c]BitSet[/c] und ein [c]Seq[Bool][/c], gibt es ein [c]CanBuildFrom[/c], das aussagt, dass da auch wieder ein [c]BitSet[/c] rauskommen kann. Wenn ich aber ein [c]BitSet[/c] mit einer [c]List[Int][/c] verketten will, wird nur ein allgemeineres [c]CanBuildFrom[/c] gefunden, dass dann nur einen Typ wie [c]Seq[Any][/c] erlaubt. Wenn du eigene Datentypen hast, kannst du dir entsprechende implizite [c]CanBuildFrom[/c]-Objekte schreiben, um "intelligente" Konvertierungen zu erlauben.

Nur um sicher zu gehen: D.h. mit impliziten Argumenten kann man quasi programmieren, was fuer einen Rueckgabetyp eine Methode hat? Bei Listen also z.B., entscheidet ein Stueck Code (irgendwo), ob es eine List<Integer>, List<Long> oder List<Whatever> rauskommt?

Da muss ich erstmal drueber nachdenken... ;-)

 

[Landei]

Nur um sicher zu gehen: D.h. mit impliziten Argumenten kann man quasi programmieren, was fuer einen Rueckgabetyp eine Methode hat? Bei Listen also z.B., entscheidet ein Stueck Code (irgendwo), ob es eine List<Integer>, List<Long> oder List<Whatever> rauskommt?

Da muss ich erstmal drueber nachdenken... ;-)

Ja, aber recht eingeschränkt: Der Compiler muss natürlich überprüfen, dass die Auswahl des zu nutzenden impliziten Objekts wirklich eindeutig ist, und natürlich muss der Typ immer schon zur Compilezeit feststehen.

Aber man kann trotzdem interessante Sachen damit anstellen, z.B. kann man das Feature auch als Form von Dependency Injection benutzen. Manche impliziten Argumente werden auch vom Compiler geliefert, z.B. Manifests, die reifizierte Generics ermöglichen (also z.B. erlauben, ein neues Array von T zu erzeugen, wenn ich den generischen Typ T habe, was ja bekanntlich in Java nicht ohne weiteres geht).

In Scala sollte man sich an das Spiderman-Prinzip halten: "Mit großer Macht kommt auch große Verantwortung". Implizite Argumente sind eine coole Sache, und es ist gut, dieses Feature in seiner Werkzeugtasche zu haben, aber natürlich sollte man damit nicht übertreiben.

 

[bygones]

Nur zur Klarstellung: Die Kritik an der ++-Methode ist völlig daneben. Die komplizierte Signatur ist nötig, weil die Methode komplizierte Dinge macht

seit wann muss eine Methode kompliziert sein bzw eine komplizierte Signatur haben, wenn sie komplizierte Dinge macht ? Diese Argumentation ist daneben. Eine gute Sprache bzw ein guter Sprachstil erlaubt es eben genau komplizierte Sachen nicht kompliziert auszudruecken.

Das hat jetzt nix mit Scala an sich zu tun, sondern generell.

 

[Marco13]

Ich glaube, das bezog sich darauf, dass man die Methodensignatur ja "nicht sieht", und man einfach
result = a ++ b
schreiben kann - einfacher geht's wohl kaum Aber das ist es, was ich oben angedeutet hatte: Als Java-Programmierer hat man das "so drin", sich die API-Doku und den Code anzusehen, und DAS ist dann kompliziert. (Oder anders, direkt auf deinen Einwand bezogen formuliert: An irgendeiner Stelle muss die Komplexität ja stecken - auch wenn man sie nicht sieht...)

 

[schlingel]

Jegliche Komplexität die man glaubt nicht sehen zu müssen beißt einen im unpassendsten Moment in den Hintern. Und das aus dem finsteren Hinterhalt den man vorher Abstraktion nannte.

Soweit jedenfalls meine Erfahrung =D

 

[timbeau]

Ich finde, dass man sich wirklich erst dann über Abstraktion beschweren sollte, wenn es zu Problemen kommt. Ich bezeichne mich als reativ unerfahren mit weniger als 5 Jahren Programmiererfahrung und kann da vielleicht nicht mitreden aber ich musste nie wirklich den Source-Code der JDK-Sourcen "debuggen" damit meine Programme laufen.

Wenn also wie hier in Scala es Methoden gibt, die einem echt komplizierte Sachen sehr erleichtern, muss ich halt gucken ob ich diese Dinge nutze. Das Schöne ist doch, dass ich meine Listen auch anderes zusammen führen kann

 

[Gregorrr]

Wer denkt, dass Scala etwas für die breite Messe ist, der verschließt seine Augen vor der Realität.

Massentauglichkeit == Praktik

Zunächst bräuchte Scala eine Killer-App/Technologie. Bei Java war es vornehmlich das Web (backend). Bei Scala habe ich die Killer-Applikation noch nicht entdeckt, eventuell ist es Parallele Programmierung, wir werden sehen.

Desweiteren muss eine Massen-Sprache einen Programmierer auf eine bestimmte Menge einschränken, damit man sich in bestimmter Zeit noch über ein Thema unterhalten kann. Schonmal aufgefallen, dass die Scala-Leute sich Monate-lang über ein simples Thema zerfetzen können? Klare Regeln verhindern das. Java ist deshalb so erfolgreich, weil es das Programmieren um einiges vereinfacht. Das Code wird bei Scala nicht unbedingt leichter verständlicher, nur kurzer...

Das Typ-System ist ja wohl mal lachhaft. Wieso braucht man überhaupt so ein extremes Typsystem? In C wurde so viele Programme entwickelt - ohne Mega-Typsystem. Wie kann sowas praxis-tauglich sein?

Das schlimmste ist die Scala-Community: Alles ahso intelligente (was durchaus stimmt) Programmierer, die sich aber herablassend über Joe den Java-Programmierer äußern (bzw. Java im Allgemeinen), aber die Sprache für jedermann sein soll? Die eigenen Fehler werden doch nicht besser, wenn man sich herablassend über andere äußert. Was ich schon alles lesen musste von Scala-Evangelisten, die einfach nicht durchschauen, dass zwar alles toll ist was sie machen, dass aber Praxisbezug was ganz anderes ist.

Scala ist eine tolle Sprache, keine Frage, aber praxitauglich?

 

[Bronko]

Hallo zusammen,
ich zähle mich auch zu den Gelegenheits-Entwicklern. Vor ein paar Jahren habe ich noch Geld mit Shareware verdient und man sehe und staune mit einer SWING Anwendung auf dem Desktop Meine Scala Kenntnisse sind mäßig. Momentan nutze ich meine "alten" Java Klassen von Scala aus und entwickle in Scala unter Eclipse weiter.
Ich möchte auch kurz meinen Senf dazu geben.

Ich empfand Java mit der Zeit als zu Statisch und umständlich. (IMHO) Ich denke das Hauptfeature von Java ist das OOP. Nicht mehr nicht weniger. Scala dagegen wirkt so als ob sich da jemand viele Gedanken gemacht und aus der Praxis kommt. Mein Lieblings Feature sind die Higher-Ordner Funktionen und die Rekursion... achja und solche kleinen Schmeichelein das man idr. keinen Variablen Typ deklarieren muss. Ich muss aber auch zugeben das ich bisher nicht alle Features von Scala nutze bzw. mir angeeignet habe. Ich bin mir auch bewusst das die Besagten "Monster" nicht sofort verständlich sind. Vielleicht mit viel praktischer Erfahrung ?! Dont know.

Wenn ich jetzt Abwegen müsste zwischen einer extrem Modernen Sprache (alleine schon wegen dem Thema MultiCore) bei der ich ewt. Fremdcode schwer lesen/begreifen kann weil "Monster" usw. und Java welche sich seit Jahren kaum weiterentwickelt frage ich mich bzw. müssen wir uns alle fragen wie sieht es mit unserer eigenen Entwicklung aus ? Sollen wir 20 Jahre das Java/C "dogma" hochhalten weil das "spiel" leichte kost ist ?

EDIT: Sorry für Rechtschreibfehler :shock:

 

[Landei]

Schonmal aufgefallen, dass die Scala-Leute sich Monate-lang über ein simples Thema zerfetzen können?

Weil es so extrem richtig ist, etwas wirklich richtig hinzubekommen, bevor es überall verwendet wird. Ist die Katze erst einmal aus dem Sack, ist es enorm schwierig, die Jugendsünden wieder gradezubiegen. Wäre es nicht schön, Sun hätte sich ein paar mehr Gedanken über java.util.Date oder die Varianz von Arrays gemacht?

 

[schalentier]

Ich denke das Hauptfeature von Java ist das OOP.

Das is Unsinn. Gugg dir mal eine richtige OOP Sprache, wie z.B. Ruby an. Da kann Java mit seinen vielen berechtigten Nicht-OOP-Optimierungen bei weitem nicht mithalten.

Das Hauptfeature ist die Einfachheit und die gute Lesbarkeit. Das was auch Basic und Pascal so beruehmt gemacht haben ;-)

Scala dagegen wirkt so als ob sich da jemand viele Gedanken gemacht und aus der Praxis kommt.

Scala ist ein rein akademisches Projekt, initiiert und gepflegt von einem reinen Akademiker. Nicht falsch verstehen, ich hab ueberhaupt nix gegen Akademiker - aber es hat eben nichts mit "aus der Praxis" zu tun.

Das ist auch mein Hauptkritikpunkt: Moeglicherweise sind die ganzen Features von Scala toll - aber ich frage mich, ob es tatsaechlich einen wirklichen praktischen Nutzen fuer z.B. ein (imho) ueberkomplexes Typsystem gibt.

Ich hab in einem meiner letzten Projekte ein doch recht umfangreiches Projekt mit Ruby on Rails (mit-) realisiert. Da gibts ueberhaupt keine Typen, dafuer isses komplett OOP - und ich hab die Typen nicht wirklich vermisst.

Sollen wir 20 Jahre das Java/C "dogma" hochhalten weil das "spiel" leichte kost ist ?

Naja, offensichtlich hat Java/C einige Vorteile, sonst waere es nicht so verbreitet. Warum sollte man ein gutes System abschaffen, wenn es keine dringenden Bedarf dafuer gibt? Nicht immer is alles, was aelter als 20 Jahre ist, per se schlechter als irgendeine x-beliebige, neue Innovation. Zumal ich nicht glaube, dass bei Java schon alles ausgereizt ist. Ich hab neulich das Play! Framework entdeckt, die nutzen in der aktuellen 1.Xer Version noch Java. Aber wie und mit welchen Mitteln, find ich ziemlich cool (Leider wollen die in der Version 2 komplett auf Scala umsteigen - und haben mich damit als Nutzer verloren - aber vielleicht gibts ja irgendwann nen Fork von der 1.2.4 :-D ).

 

[Bronko]

Also als Java anfing gab es noch kein Groovy
Ich denke als Java um 1995 das Licht der Welt erblickte waren die Hauptfeatures OOP und die VM.

Ich muss dir recht geben das Scala viele Akademische Neigungen hat und auch sehr sehr gerne von Akademiker akademische beispiele aufgezeigt werden um die Vorteile von Scala aufzuzeigen welche nicht Praxis relevant sind oder anders gesagt Software besteht nicht nur aus neben-läufige Berechnungen. ABER...
Wie ich schon oben sagte Higher Order Funktionen, Pattern Matching,Rekursion sind alles andere als Praxisfremd alleine mit diesen Features kommst du schneller, eleganter und unkomplizierter zu deinen Algorithmen. Nebenbei sinkt auch das Bug riskio weil du die ganzen schönen schleifen + if-then nicht mehr hast.


Java/C Dogma:
Nachdem was du schreibst müsste der VW Käfer immer noch das Beste Auto der Welt sein
Die Frage bleibt immer noch willst du wirklich die nächsten 20 oder 50 Jahre so weitermachen und das obwohl du weist das es da "draußen" noch Scala,F#,Cloujue usw. gibt ? (Beispiele beliebig auswechselbar)

Ich empfehle jeden der 40 Euronen über hat dieses Buch: Scala für Umsteiger: Amazon.de: Friedrich Esser: Bücher
Der Autor zeigt Scala im Praktischen Einsatz quasi "in der freien Wildbahn".

 

[SlaterB]

wie gesagt wurde, was es da draußen gibt muss nicht ohne Prüfung besser sein als das Vorhandene,
und man darf den unermesslichen Gewinn des Vorhandenen nicht außer Acht lassen,
was wäre die Datenbankwelt ohne die Standardsprache SQL,
was wäre das Internet ohne simple Dinge wie HTML & Co.
ohne simple Dinge von Microsoft und Apple wären Computer in den 80ern stehen geblieben statt heute alles zu dominieren,
und ohne breite Programmiersprachen wie Java oder C-irgendwas wäre Programmierung heute nicht so verbreitet dass es Tausende studieren und in simplen Foren wie diesem hier diskutieren

auch diese Dinge waren mal Fortschritte, es wurde nicht auf dem vorherigen Stand stehengeblieben,
aber es waren doch Fortschritte die sich duch Sinnhaftigkeit auszeichnen, und sei es eben Einfachheit,
das kann man nicht einfach so auf beliebiges übertragen,

'Scala,F#,Clojure' klingt für mich nach drei Dingen einer Kategorie, die sich noch nie in der Geschichte gegen Konkurrenz durchgesetzt haben,
das kann man bedauern und wie Windmühlen stoisch bekämpfen, aber darauf zu wetten ist wohl keine gute Idee

 

[Bronko]

Ich würde niemals behaupten und generell sagen das altes schlecht ist und neues gut. Ich will sagen das die Menschen auch mal Menschenaffen waren und sich weiterentwickelten oder Zellen -> Organismen usw. usw. usw. Nebenbei kannst du in Scala das "althergebrachte" also Java Klassen und Archive weiter nutzen.

Ich bin davon überzeugt wenn du eine Studie betreibst in den du 10 Unbelastete Menschen einmal Scala und einmal Java oder C lehrst die Wahrnehmung ganz anders aussieht. Vor allem erstickst du das Argument mit dem althergebrachten.

 

[Noctarius]

Ich find Scala ist eine tolle Alternative zu Pseudocode. Wir dokumentieren damit das Regelwerk im Wiki. Klappt super und ist für jeden ersichtlich (wenn man keine ausgefallenen Features nutzt).

 

[schlingel]

Diese ganze Diskussion hat sich schon so weit vom ursprünglichen Thema bzw. der Kritik EJB2 und Scala sind in ihrer Struktur gleich kaputt sind entfernt, dass das ganze ja gar nicht mehr lustig ist.

Zum einen hat nie jemand behauptet, dass es schlecht ist neue Sprachen zu entwickeln bzw. sie auch zu verwenden. Dass aber LOP-Entwickler nicht auf jeden Zug aufspringen können sollte auch klar sein. Im Gegensatz zu F# besitzt Scala nun einmal nicht die Unterstützung von großen LOB-Frameworks weshalb ich das schon verstehe, dass man sich lieber auf Java verlässt. Z.B. wird oft in JBoss-Foren gesagt schau in den Source. Bei so einem riesigen Projekt durchzusteigen wird durch Scala nicht einfacher wie der nächste Punkt zeigt.

Zudem zeigt ja auch die Kritik von Yammer - ein Grund weshalb sie teilweise wieder zu Java zurückkehren - dass Scala eben nicht einfach ist. Zu viele Arten wie Probleme gelöst werden können und zu komplex für einen Anfänger. Für einen Programmierer sind FP und andere Paradigmen sicher interessant aber gerade als Java-Entwickler hat man auch viel mit Business zu tun weshalb man immer drei Mal überlegt ob man sich die Investition antut. Wer weiß schon wann der ROI dann wirklich erreicht ist!?

(Das sich F# nicht durchgesetzt hat ist eine verdrehte Aussage. F# ist eine Komplementärsprache die sehr wohl ihren Platz hat.)

Und zu guter Letzt: du hast genauso ein engstirniges Argument mit dem "Neuhergebrachten". Denn Neues ist per se noch nicht besser ;-)

 

[Landei]

Das Hauptfeature ist die Einfachheit und die gute Lesbarkeit. Das was auch Basic und Pascal so beruehmt gemacht haben ;-)

Scala ist ein rein akademisches Projekt, initiiert und gepflegt von einem reinen Akademiker. Nicht falsch verstehen, ich hab ueberhaupt nix gegen Akademiker - aber es hat eben nichts mit "aus der Praxis" zu tun.

Epic fail! Niklaus Wirth war auch so ein "reiner Akademiker"...

 

[schlingel]

Möge das Flamen beginnen. :applaus:

 

[schalentier]

Lol, ne, aus dem Alter bin ich raus ;-)

Ich habe ja auch nur gesagt, dass Scala nicht aus der Praxis kommt, wie behauptet wurde.

PS @ Landei: erstmal komplett recherchieren ;-)

Ohne Turbo Pascal hätte die Sprache Pascal sicher das gleiche Schicksal ereilt wie viele an Universitäten vorher und nachher geborene „Kunstsprachen“, z. B. Prolog, Modula-2 oder Oberon (die letzten beiden auch von Niklaus Wirth), die heute praktisch verschwunden sind. Hejlsberg entwickelte die Sprache und das System pragmatisch weiter: Von Anfang an wurde die Laufzeitbibliothek um Routinen ergänzt, die Zugriff auf das System ermöglichten – ganz entgegen dem ursprünglichen Konzept von Wirth.

Und der Herr Hejlsberg war selbststaendig, dann bei Borland und nun isser bei Microsoft :-D

 

[Landei]

Die Änderungen von Hejlsberg mögen wichtig gewesen sein, aber das "akademische" Grundkonzept von Pascal hat sich jedenfalls als tragfähig genug erweisen, und ich bezweifle, dass das ein "Praktiker" hätte leisten können.

Scala ist schon durch die JVM-Anbindung praxisorientiert. "Akademische" Sprachen wie Haskell und Prolog zeichnen sich ja gerade durch ihre "Sauberkeit" und ihren Minimalismus aus - also das Gegenteil von dem, was Scala immer vorgeworfen wird. Viele "Unebenheiten" in Scala sind genau diesem Praxisbezug geschuldet: Null-Referenzen, keine Compiler-Garantieen für puren Code, unvollständige Endrekursion, die seltsame Typhierarchie (AnyVal, AnyRef), Type-Erasure (mit Manifesten als Notbehelf), kein volles Currying, Probleme im Umfeld Methoden <-> Funktionen u.s.w. Alle diese Probleme sind in "akademischen" Sprachen lange gelöst, aber Scala hätte dafür die JVM- und Java-Kompatibilität aufgeben müssen.

Natürlich kommt noch etwas zusätzlicher Ballast dazu, weil Scala eine Hybridsprache ist. Aber gerade diese Hybridisierung bringt auch Synergien und neuartige Lösungsmöglichkeiten hervor, und ich finde dass es das deshalb auch wert ist. Scala ist einfach bestimmten Problemen gewachsen, denen Java nicht (oder nur durch massiven Bibliothekseinsatz) gewachsen ist. Aber jedem das seine, ich mag diese manchmal etwas frickeligen Taschenmesser und du die bewährten und grundsoliden Faustkeile, so sei es dann halt...

 

[inv_zim]

Das Problem der Komplexität liegt doch nicht darin, dass ich als Entwickler sage "Das ist so komplex, das gucke ich mir gar nicht erst an." Ich habe bisher nur ein wenig mit der Konsole gespielt, und bin vom Sprachkonzept begeistert. Aber obwohl ich sogar in meiner Freizeit programmiere, ist mir meine Zeit für Scala einfach zu schade. Für die Praxis im Berufsleben bringt mir das absolut gar nichts. Die Programmierung im Hintergrund mag durchaus elegant sein, aber wo ist jetzt der exakte Grund für Scala? In so ziemlich jeder Nische gibt es mittlerweile quasi Standardsprachen, die sich auf verschiedene Aspekte konzentrieren. Wenn ich jetzt in einer leitenden Position sitzen würde, und es käme der Vorschlag "Wir führen Scala ein", würde ich fragen, was der Vorteil und was der Aufwand wäre. Und wenn die Vorteile so gering sind, bei einem dermaßen hohen Schulungsaufwand für die Entwickler, wäre die Entscheidung direkt gefallen.
Aber funktionale Aspekte fließen ja jetzt immer mehr in andere Sprachen ein, vielleicht sieht das ja in ein paar Jahren ganz anders aus, dass es einfach einen "weichen Übergang" gibt.

 

[Bronko]

@inv_zim
Genau das was du "forderst" den weichen Übergang genau das macht Scala ja.

Hmmm, ich hab das Gefühl das sich viele Scala angesehen haben und auch damit rumgespielt haben. Aber sich wirklich mal darauf eingelassen oder gar Entwickelt haben wohl wenige und genau da scheint das Problem zu liegen.

Ich hab damals mit C64 und Amiga angefangen mit der Programmiererei und wie es sich gehört in Assembler. Nun ja Basic laß ich mal aussen vor, aber der umstieg vom Assembler denken zu Java viel mir damals mega schwer. Wir sind alle Gewohnheitstiere und das wird auch im Alter nicht besser aber vielleicht sollte man doch ab und zu positiv an neues gehen

 

[schlingel]

Wir sind alle Gewohnheitstiere und das wird auch im Alter nicht besser aber vielleicht sollte man doch ab und zu positiv an neues gehen;-)

So wichtig und richtig diese Naivität beim Lernen ist, so katastrophal kann das sein, wenn das Unternehmen dabei finanziellen Schaden nimmt.

 

[Bronko]

Es ist wie es immer ist in einem Internet Forum es gibt die Pro-Leute und die Contra-Leute
(Mich natürlich eingeschlossen)

Thema Naivität:
Zitat von Scala - Popularity and Use Grow | The Scala Programming Language
The number of leading companies that are successfully using Scala for critical business applications has grown enormously. It is common knowledge that more companies like Twitter, LinkedIn, Foursquare, the Guardian, Morgan Stanley, Credit Suisse, UBS, HSBC and Trafigura are now using Scala. As a consequence, demand for Scala developers has grown dramatically while at the same time Scala has matured and spawned a solid support ecosystem. It's worth looking at some of the indicators to see how the world wide popularity and momentum continues to increase.

Ich möchte jetzt mal provokant fragen auch wenn ich mich damit unbeliebt mache..... wie stellt ihr euch die Zukunft vor? Thema MultiCore oder gar ManyCore in Java mittels OOP?

 

[schlingel]

Ich denke es wird alles in Richtung FP/OOP-Hybrid gehen. Allerdings glaube ich nicht das Scala dabei die Nummer 1 spielen wird. (Aber das liegt wohl mehr daran, dass ich mich zur Zeit einfach mehr für andere Sprachen interessiere. You never know ) Allerdings sollten sich da Unternehmen hinter die neue "offizielle" JVM-Sprache klemmen und nicht so wie jetzt, dass jeder sein eigenes Süppchen kocht und niemand weiß was da raus da am Schluss raus kommt.

Punkto Zukunft: Vor allem was MS und deren Research Lab raushaut ist interessant und zukunftsweisend.

 

[SlaterB]

Ich möchte jetzt mal provokant fragen auch wenn ich mich damit unbeliebt mache..... wie stellt ihr euch die Zukunft vor? Thema MultiCore oder gar ManyCore in Java mittels OOP?

auch auf die Gefahr hin ohne Wissen was dämliches zu schreiben:
was sollte es die Aufgabe der Programmiersprache, die sich um Objekte, Typsicherheit und Sichtbarkeit kümmert, sein, über ein oder mehrere Prozessorkerne nachzudenken?
Nebenläufigkeit ist ganz einfach ein Feature wie Threads in Java, relativ unabhängig von den restlichen Konzepten

die Grundsprache ist unabhängig von ihrer Verwendung, ob Web-Applikationen, 3D-Engine oder Datenbank-Transaktion (edit: oder GUI),
vielleicht nicht in allen Bereichen optimiert, aber wenn das die Kosten der Abstraktion sind, dann wird das gerne in Kauf genommen

und wieso sollte gerade funktionale vs imperative Programmierung bei MultiCore relevant sein?

 

[Landei]

auch auf die Gefahr hin ohne Wissen was dämliches zu schreiben:
was sollte es die Aufgabe der Programmiersprache, die sich um Objekte, Typsicherheit und Sichtbarkeit kümmert, sein, über ein oder mehrere Prozessorkerne nachzudenken?
Nebenläufigkeit ist ganz einfach ein Feature wie Threads in Java, relativ unabhängig von den restlichen Konzepten

Ja, aber das Thread-Konzept ist nicht notwendigerweise die beste Lösung für jedes Problem (siehe z.B. Aktoren, STM), und der Java Joe produziert fast unweigerlich Mist, wenn er auf einmal und ohne gute Schulung multithreaded Code schreiben soll.

und wieso sollte gerade funktionale vs imperative Programmierung bei MultiCore relevant sein?

Schon mal eine ArrayList in Java aus unterschiedlichen Threads heraus benutzt und vergessen zu synchronisieren? In einer Sprache wie Haskell muss man überhaupt nicht synchronisieren, weil da alles unveränderlich und seiteneffektfrei ist.

 

[inv_zim]

Die Frage ist auch wieder hier der Schwerpunkt der Anwendungen. Ich habe ab Januar einen neuen Job und darf als einziger Entwickler quasi die Programmierung in einem Industriebetrieb planen und ein Konzept aufstellen. Geschäftsanwendungen, Auftragsbearbeitung, Kommunikation mit Speditionen, etc. Ist jetzt ernsthaft jemand hier in diesem Thread der mir empfiehlt, auf Scala zu setzen?

 

[Bronko]

Weil immer nur ein Core den selben Speicherbereich abarbeiten kann + Seiteneffekte.

Effiziente MultiCore Entwicklung funktioniert nur wenn du genau das gegenteil von OOP machst.
Zum Beispiel wird mit mehreren Cores/Threads eine Klasse oder deren Methoden abgearbeitet dann kann immer nur ein Core/Thread die Sache abarbeiten weil wie oben beschrieben der Speicherbereich geLockt wird und die Methoden Seiteneffekte auf Variablen ausüben (nicht zwingend). Immer dann wenn veränderlichen Variablen auftauchen Lockt der Core. FP ist was das betrift genau das gegenteil von OOP.

@inv_zim
Ist doch klar nimm das was du am besten kannst