# Scala-Mythen



## Landei (8. Sep 2009)

In einer zeitweise etwas hitzigen Diskussion hat sich wieder einmal gezeigt, wie hartnäckig sich Gerüchte und Halbwahrheiten halten, nicht nur über Scala, sondern auch andere JVM-Sprachen wie Groovy - und über funktionale Sprachen sowieso. An dieser Stelle möchte ich die Mythenforschung aber auf Scala beschränken.

*"Scala ist eine Skriptsprache"*
Das ist eine dieser nicht auszurottenden Halbwahrheiten. Zuallererst sei bemerkt, dass man in Scala sehr bequem und einfach Scripte schreiben kann, diese Aussage also tatsächlich ein Körnchen Wahrheit enthält. Die erste Sache, die mich daran stört ist, dass sich viele "Skriptsprachen" zwar gut für die Automatisierung von Abläufen oder kleine Tools eignen, aber kaum für komplexere Systeme. Das trifft für Scala definitiv nicht zu, der Name wurde ja gerade deshalb gewählt, weil Skalierbarkeit eines der Hauptmerkmale sein sollte, und das ist gelungen: In Scala funktionieren fünfzeilige Scripts, aber auch riesige, verteilte Anwendungen - die Sprache wächst tatsächlich mit ihren Aufgaben. Der zweite Kritikpunkt ist die Gleichsetzung von "Skriptsprache" mit "dynamisch getypter Sprache". Aber das ist in Wahrheit sowieso nur ein "statistischer" Zusammenhang (obwohl die meisten Skriptsprachen dynamisch sind, gibt es doch genügend Ausnahmen). Der Fehlschluss in Bezug auf Scala ist allerdings leicht verständlich, denn viele Programmierer glauben immer noch, dass nur wo Typen "dranstehen" auch Typen drin sind. Aber Scala verfügt über Typinferenz, ein Feature, dass es seit Ewigkeiten in vielen funktionalen Sprachen wie z.B. Haskell findet. Kann der Compiler einen Typ "ableiten", muss ich ihn nicht angeben, so einfach ist das. Warum muss ich in Java einer Variable, der ich den Wert "Das ist ein interessanter Text" zuweise, noch den Typ String mitgeben? Der Compiler meckert doch, dass er einen String will, wenn ich als nächstes ein Date hineinstopfen will, warum muss ich dann eigentlich den Typ noch angeben, wenn er er das selbst herausfinden kann - und sowieso immer alles besser weiß? Probieren wir das einmal in Scala, am besten online:

```
var x = "Das ist ein interessanter Text"
//--> x: java.lang.String = Das ist ein interessanter Text
x = new java.util.Date()
//--> error: type mismatch;
//-->  found   : java.util.Date
//-->  required: java.lang.String
//-->        x = new java.util.Date()
//-->            ^
```
Obwohl ich nirgendwo einen Typ erwähne, hat meine Variable x den Typ "String", und der Compiler protestiert auch lauthals, wenn ich etwas anderes hineinstecken will. Messerscharfe Schlussfolgerung: Scala ist statisch getypt, auch wenn es auf den ersten Blick vielleicht nicht so aussieht!

*Scala ist nur eine Java-Variante*
Das ist dermaßen starker Tobak, dass ich bisher dachte, dass man darüber eigentlich nicht diskutieren bräuchte. Um Scala als eine Art aufgebohrtes Java mit verrückter Syntax zu sehen, muss man beim Draufscheuen schon ziemlich weit wegstehen und auch noch gegen die Sonne blinzeln. 
Natürlich ist es ein Trugschluss, dass Scala "eigentlich" eine Art Java ist, nur weil es auf der JVM läuft. Dann wären nicht nur JRuby und Jython "Java-Varianten", sondern auch Clojure, was total absurd ist, denn die Sprache ist so deutlich an Lisp angelehnt, dass man zweimal hingucken muss, um zu erkennen, was was ist. Ein weiteres Gegenargument ist, dass Scala auch auf Dot.Net läuft, was es nach dieser Logik gleichzeitig zu einer Visual Basic-Variante oder was auch immer machen würde.
Die beste Entkräftung dieses Mythos ist natürlich schlicht der Blick in Scalas Feature-Liste: Pattern-Matching, Closures, Typen höherer Ordnung, implizite Konvertierungen, strukturelle Typen und so weiter und so fort. Wer das nicht als Argument gelten lassen will, den frage ich ganz ernsthaft, warum er in dieser komischen COBOL-Variante namens Java arbeitet, denn beide Sprachen haben mindestens genausoviel miteinander gemein wie Java und Scala.

*Scala ist eine dieser akademischen Spielsprachen*
Natürlich wird dabei übersehen, dass viele der heute eingesetzten Mainstream-Sprachen aus dem akademischen Bereich stammen. Aber der Irrtum geht noch tiefer, denn es wird unterschwellig unterstellt, Akademiker wüssten nicht, was "im richtigen Programmierleben" gebraucht wird. 
Das mag für einige Professoren zutreffen, aber bestimmt nicht für den Vater von Scala, Martin Odersky. In dieser Frage erübrigt sich jede Diskussion, denn seine bisherige Arbeit spricht für sich: Die von Sun verwendete Version von javac ist eine Weiterentwicklung eines Prototypen, den er geschrieben hat, und von ihm stammt Generic Java, das die Grundlage für die Generics in Java 1.5 war. Nur weil ein paar Papiere mit (für Otto-Normal-Programmierer) esotherischen Themen veröffentlicht wurden, heißt das noch lange nicht, dass Scala nicht praxisorientiert wäre. Im Gegenteil, gerade die für die Praxis so wichtige Interoperabilität mit Java zwingt Scala zu Kompromissen, durch die es aus akademischer Sicht ein wenig "unsauber" geworden ist. Wer einmal eine wirklich kompromisslos "akademische" Sprache erleben will, sollte sich Haskell anschauen. Aber selbst das findet mehr und mehr praktische Anwendung, was wiederum zeigt, wie schwach das "akademische" Argument in Wirklichkeit ist.

*Die Syntax von Scala ist häßlich und unverständlich*
Nun ja, die Schönheit liegt im Auge des Betrachters. Und natürlich ist vieles einfach Gewohnheit. Dass der Typ hinter der Variable kommt, ist nicht unüblich, wie man an den Vertretern der pascalartigen Sprachen (Pascal, Delphi, Modula, Oberon usw) sehen kann, und passt einfach besser mit dem Konzept der Typinferenz zusammen. Anderes Beispiel: vergleichen wir einmal die verschiedenen Deklarationensarten in Java und Scala.

```
//Java
String foo = ...
final String foo = ...
String foo(Bar bar){ ...
class Foo{ ... 
interface Foo{ ...

//Scala
var foo = ...
val foo =
def foo(bar:Bar) = { ...
class Foo { ...
trait Foo { ...
```
Fällt euch was auf? Genau, die Scala-Schreibweise ist einheitlicher. Nach der Eingewöhnungszeit fallen einem mehr und mehr Dinge auf, die in Scala syntaktisch sauberer und "orthogonaler" gelöst worden sind: Keine Extrawürste für primitive Typen oder Arrays, keine statischen Methoden, keine unnötigen returns, if-Anweisungen geben Werte zurück und so weiter. Und gepriesen sei, dass Semikolons optional sind, amen!
Natürlich gibt es auch Teile der Syntax, die erst einmal absolut abschreckend wirken, wie das "berüchtigte" List(1,2,3).foldLeft(0)(_+_). Waaaah, zwei Argumentlisten und dann noch ein japanisches Emoticon! Aber erinnert euch doch einmal an die Zeit, als ihr Java gelernt habt: Habt ihr nicht ähnlich geguckt, als ihr über die erste anonyme Klasse oder den ersten statischen Initialisierungsblock gestolpert seid? Mir sind jedenfalls beim ersten Anblick fast die Augen rausgepurzelt. Aber ich habe gelernt, damit umzugehen und diese Feautures mehr oder weniger sinnvoll einzusetzen. Und es hat mir auch nicht gescha.. gescha.. geschadet.

*Scala hat als JVM-Sprache die gleichen Beschränkungen wie Java*
Diese Aussage ist absolut richtig. Jede turing-vollständige Sprache hat die gleichen Beschränkungen wie das ebenfalls turing-vollständige Java, genauso wie ich jedes Java-Programm (bis auf Systemzugriffe wie I/O) auch in Brainfuck implementieren kann. Bezieht man die Aussage allerdings auf die Mächtigkeit der Sprachmittel, sieht man schnell, dass Scala vorne liegt. Scala implementiert Features wie Closures, Typen höherer Ordnung oder Endrekursion, die weit über "syntaktischen Zucker" hinausgehen. 
Es ist natürlich ein Fehlschluss zu glauben, nur weil Java in Bytecode übersetzt wird, würde es die Möglichkeiten, die die JVM mit ihrem Bytecode bietet, auch optimal nutzen. Es ist eine altbekannte Tatsache:  Nicht jedes valide Bytecode-Programm lässt sich in ein valides Java-Programm "übersetzen". Also müsste obige Aussage korrigiert werden zu: Scala ist als JVM-Sprache auf die Möglichkeiten von JVM-Bytecode beschränkt. Diese Aussage ist wahr, aber ebenso trivial und tautologisch wie die anfängliche Aussage über die Äquivalenz aller turing-vollständigen Programme.

(Diesen Text habe ich auch in mein Blog übernommen)


----------



## Landei (29. Sep 2009)

In der aktuellen c't ist ein längerer Artikel über Scala


----------



## marasek (3. Okt 2009)

Gibt es hier vielleicht noch ein paar Python-Fanbois, um die Sache spannender zu gestalten? Oder Verfechter von Ruby on Rails? Die glauben auch immer, mit ihrer Sprache seien alle Probleme der Softwareentwicklung beseitigt.

Was Skriptsprachen anbelangt, so sehe ich da mittlerweile keine klare Definition mehr. Heute schreiben die Leute ja mittlerweile halbe Betriebssysteme in JavaScript.

Wozu man Closures _braucht_ habe ich nie verstanden, und ich würde wohl jeden grillen, der sowas verwendet. Aber ich bin schon gegen die Verwendung des ternären Operators ;-)


----------



## bygones (3. Okt 2009)

marasek hat gesagt.:


> Gibt es hier vielleicht noch ein paar Python-Fanbois, um die Sache spannender zu gestalten? Oder Verfechter von Ruby on Rails? Die glauben auch immer, mit ihrer Sprache seien alle Probleme der Softwareentwicklung beseitigt.
> 
> Was Skriptsprachen anbelangt, so sehe ich da mittlerweile keine klare Definition mehr. Heute schreiben die Leute ja mittlerweile halbe Betriebssysteme in JavaScript.
> 
> Wozu man Closures _braucht_ habe ich nie verstanden, und ich würde wohl jeden grillen, der sowas verwendet. Aber ich bin schon gegen die Verwendung des ternären Operators ;-)



epic fail

wenn man nix verstanden hat und provoziert... dont feed the trolls


----------



## Landei (3. Okt 2009)

marasek hat gesagt.:


> Gibt es hier vielleicht noch ein paar Python-Fanbois, um die Sache spannender zu gestalten? Oder Verfechter von Ruby on Rails? Die glauben auch immer, mit ihrer Sprache seien alle Probleme der Softwareentwicklung beseitigt.
> 
> Was Skriptsprachen anbelangt, so sehe ich da mittlerweile keine klare Definition mehr. Heute schreiben die Leute ja mittlerweile halbe Betriebssysteme in JavaScript.
> 
> Wozu man Closures _braucht_ habe ich nie verstanden, und ich würde wohl jeden grillen, der sowas verwendet. Aber ich bin schon gegen die Verwendung des ternären Operators ;-)





> "Das ist wieder eine Ihrer wunderlichen Ansichten", sagte der Präfekt, der die Gewohnheit hatte, alles wunderlich zu nennen, was über seinen Horizont ging, und der daher in einer Welt voller Wunderlichkeiten lebte.


Edgar Allan Poe - Der entwendete Brief


----------



## 0x7F800000 (3. Okt 2009)

marasek hat gesagt.:


> Wozu man Closures _braucht_ habe ich nie verstanden, und ich würde wohl jeden grillen, der sowas verwendet. Aber ich bin schon gegen die Verwendung des ternären Operators ;-)





			
				David Hilbert hat gesagt.:
			
		

> Manche Menschen haben einen Gesichtskreis vom Radius Null und nennen ihn ihren Standpunkt.


<°)))><(


----------



## marasek (4. Okt 2009)

Hmm, anscheinend wird hier bei einigen die Grafik für den ;-)-Smiley nicht richtig angezeigt.

Ich wollte lediglich zum Ausdruck bringen, dass ich mit bestimmten möööchtigen Features nicht sonderlich grün bin, weil ich sie in schwer wartbarem Code gesehen habe / sie in weiterem schwer wartbaren Code erwarte.

Entschuldigt, wenn das falsch rüber kam.


----------



## Landei (4. Okt 2009)

Je mächtiger das Feature, umso mächtiger kann man sich damit in den Fuß schießen - aber das ist eine Binsenweisheit. Wenn ich Holz hacken will, nehme ich auch eine scharfe Axt und keinen Vorschlaghammer, auch wenn erstere "gefährlicher" ist. 
Wenn wir uns immer am unteren Ende des Fähigkeits-Spektrums orientieren würden, gäbe es keinen Fortschritt - oder wie ein amerikanischer Kollege etwas drastisch ausgedrückt hat: Es muss auch jemand geben, der die Burger wendet.


----------



## byte (4. Okt 2009)

marasek hat gesagt.:


> Hmm, anscheinend wird hier bei einigen die Grafik für den ;-)-Smiley nicht richtig angezeigt.
> 
> Ich wollte lediglich zum Ausdruck bringen, dass ich mit bestimmten möööchtigen Features nicht sonderlich grün bin, weil ich sie in schwer wartbarem Code gesehen habe / sie in weiterem schwer wartbaren Code erwarte.
> 
> Entschuldigt, wenn das falsch rüber kam.



Du hast produktiven Scala Code gesehen? Wo arbeitest Du?


----------



## bygones (4. Okt 2009)

marasek hat gesagt.:


> Hmm, anscheinend wird hier bei einigen die Grafik für den ;-)-Smiley nicht richtig angezeigt.
> 
> Ich wollte lediglich zum Ausdruck bringen, dass ich mit bestimmten möööchtigen Features nicht sonderlich grün bin, weil ich sie in schwer wartbarem Code gesehen habe / sie in weiterem schwer wartbaren Code erwarte.
> 
> Entschuldigt, wenn das falsch rüber kam.



dont blame the technique if people are too dumb to use it.

so einfach ,-)


----------



## marasek (4. Okt 2009)

Landei hat gesagt.:


> Je mächtiger das Feature, umso mächtiger kann man sich damit in den Fuß schießen - aber das ist eine Binsenweisheit. Wenn ich Holz hacken will, nehme ich auch eine scharfe Axt und keinen Vorschlaghammer, auch wenn erstere "gefährlicher" ist.
> Wenn wir uns immer am unteren Ende des Fähigkeits-Spektrums orientieren würden, gäbe es keinen Fortschritt - oder wie ein amerikanischer Kollege etwas drastisch ausgedrückt hat: Es muss auch jemand geben, der die Burger wendet.



Äh ja, aber "Burger wenden" ist jetzt nicht mehr wirklich ein Niveau, auf dem ich mit Dir an dieser Stelle weiterdiskutieren muss.


----------



## bygones (6. Okt 2009)

marasek hat gesagt.:


> Wozu man Closures _braucht_ habe ich nie verstanden, und ich würde wohl jeden grillen, der sowas verwendet. Aber ich bin schon gegen die Verwendung des ternären Operators ;-)


sorry muss das nochmal aufgreifen.

closures sind einfach ein angenehmerer Weg um boiler-plate-Interface code loszuwerden. Gegen Closures zu sein wuerde auch heissen gegen interface implementierungen zu sein.


```
final String s = "huhu";
button.addActionListener( new ActionListener() { 
   public void actionPerformed(ActionEvent e)  { 
           System.out.println(s);
   }
}
```
gegen

```
def s = "huhu";
button.addActionlistener { System.out.println(s) }
```

und du bist sicher dass 1. loesung leichter zu lesen ist ?


----------



## marasek (6. Okt 2009)

bygones hat gesagt.:


> sorry muss das nochmal aufgreifen.
> 
> closures sind einfach ein angenehmerer Weg um boiler-plate-Interface code loszuwerden. Gegen Closures zu sein wuerde auch heissen gegen interface implementierungen zu sein.
> <schnipp>
> ...



Ich würde weder noch verwenden, denn es wird selten Fälle geben, in denen ein ActionListener lediglich "huhu" ausgeben muss, dass zudem noch hartkodiert im Quelltext steht - vermutlich wirst Du das in der Praxis auch eher selten so machen.

Wenn aber der ActionListener eine eigene Klasse ist, dann benötige ich weder Closure noch die Möglichkeit, anonyme Klassen zu definieren (die ich auch nicht mag).


----------



## tfa (6. Okt 2009)

marasek hat gesagt.:


> Ich würde weder noch verwenden, denn es wird selten Fälle geben, in denen ein ActionListener lediglich "huhu" ausgeben muss, dass zudem noch hartkodiert im Quelltext steht - vermutlich wirst Du das in der Praxis auch eher selten so machen.
> 
> Wenn aber der ActionListener eine eigene Klasse ist, dann benötige ich weder Closure noch die Möglichkeit, anonyme Klassen zu definieren (die ich auch nicht mag).



Aber wenn du 25 Knöpfe hast, wirst du auch 25 Actionlistener (oder Actions, oder ButtonModels) benötigen. Oder willst du das alles in einer Klasse machen?
Und für solche Zwecke wären Closures ideal, da hier meist sowieso nur eine Anweisung gebraucht wird. Das print "huhu" war doch nur ein Beispiel.


----------



## Marco13 (6. Okt 2009)

Nun, das ActionListener beispiel ist zwar einerseits einleuchtend, aber spätestens bei einem MouseMotionListener gibt's schon ZWEI Methoden, und da funktioniert das nicht mehr so einfach - daher sehe ich das in diesem speziellen Fall eher als "syntactic sugar" an. Das soll nicht heißen, dass es nicht in anderen Bereichen sinnvoll und praktisch sein kann, aber bevor man eine Sprache um so ein mächtiges (und leicht falsch zu verwendendes) Feature erweitert, sollte man sich schon ein paar Gedanken darum machen...


----------



## bygones (6. Okt 2009)

och leute jetzt haengt euch doch nicht an einem kleinen bsp auf (btw - allmaehlich wird der beitrag hier verschmutzt ;-) )

wer stur gegen nahezu alles ist wird auch nicht andere bsp annehmen und wer meint closure seien reiner syntactic sugar ebenso.


----------



## SlaterB (6. Okt 2009)

bygones hat gesagt.:


> und wer meint closure seien reiner syntactic sugar ebenso.



wenn du das mal nicht selber antreibst  :


bygones hat gesagt.:


> closures sind einfach ein angenehmerer Weg um boiler-plate-Interface code loszuwerden.


----------



## byte (6. Okt 2009)

marasek hat gesagt.:


> Ich würde weder noch verwenden, denn es wird selten Fälle geben, in denen ein ActionListener lediglich "huhu" ausgeben muss, dass zudem noch hartkodiert im Quelltext steht - vermutlich wirst Du das in der Praxis auch eher selten so machen.
> 
> Wenn aber der ActionListener eine eigene Klasse ist, dann benötige ich weder Closure noch die Möglichkeit, anonyme Klassen zu definieren (die ich auch nicht mag).



Stimmt. Der ActionListener würde wohl eher einige Zeilen Code ausführen, die ich in einer Methode onButtonClicked() kapseln würde. Die Closure müsste also lediglich die Methode aufrufen.


----------



## bygones (6. Okt 2009)

SlaterB hat gesagt.:


> wenn du das mal nicht selber antreibst  :



oh... got me ;-)


----------



## marasek (6. Okt 2009)

tfa hat gesagt.:


> Aber wenn du 25 Knöpfe hast, wirst du auch 25 Actionlistener (oder Actions, oder ButtonModels) benötigen. Oder willst du das alles in einer Klasse machen?
> Und für solche Zwecke wären Closures ideal, da hier meist sowieso nur eine Anweisung gebraucht wird. Das print "huhu" war doch nur ein Beispiel.



Das kommt jetzt auf den Einzelfall an. Ich kann ebensogut einen Listener machen und in dessen Methode den auslösenden Knopf abfragen und auf Grundlage dessen reagieren.


----------



## Landei (8. Okt 2009)

Wer behauptet, Closures wären ausschließlich "syntaktischer Zucker", hat eine wichtige Sache nicht verstanden. Closures können *wirklich* mehr als Java's anonyme Klassen. Ein Beispiel aus meinem eSCALAtion Blog:


```
def funny = {
  var x = 0
  ( () => {x+=1; x}, () => {x+=10; x})
}
//--> funny: (() => Int, () => Int)

val (c1,c2) = funny
//--> c1: () => Int = <function>
//--> c2: () => Int = <function>

println(c1())
//--> 1
println(c2())
//--> 11
println(c2())
//--> 21
println(c1())
//--> 22
```

"funny ist eine Methode, die eine lokale Variable x enthält und zwei Closures zurückliefert, die x um eins oder zehn erhöhen. Der Witz ist, dass beide Closures Zugriff auf dasselbe x besitzen und die Änderungen der „anderen Seite“ sehen können."

Das sieht hier wie Spielerei aus, hat aber sehr nützliche Anwendungen, wie man hier nachlesen kann. Ein anderes interessantes Anwendungsgebiet sind DSLs.

@marasek: Werde mit deinem ternäroperator- und zahnlosen Java alt und glücklich, wenn dir der Blick über den Tellerrand zu mühsam, zu gefährlich oder zu unnütz erscheint, oder wenn der Tellerrand für dich schlicht zu hoch ist. Versuche aber bitte nicht, andere davon abzuhalten: Sie werden über dich drüberklettern, und das tut weh...


----------



## SlaterB (9. Okt 2009)

zwei anonyme Klassen können doch auch auf ein und dieselbe Variable zugreifen?


----------



## tfa (9. Okt 2009)

Nicht auf freie Variablen, nur auf finale.
Anonyme Klassen sind kein gleichwertiger Ersatz für Closures.


----------



## SlaterB (9. Okt 2009)

erfordert also wieder etwas mehr Schreibarbeit, 
aber das kann ja nicht mit 'Closures können wirklich mehr als Java's anonyme Klassen.' gemeint sein


----------



## tfa (9. Okt 2009)

SlaterB hat gesagt.:


> aber das kann ja nicht mit 'Closures können wirklich mehr als Java's anonyme Klassen.' gemeint sein


Doch, unter anderem ist auch das damit gemeint.


----------



## Marco13 (9. Okt 2009)

Und (auch wenn es mich nervt, wenn ich eine klare Aussage mache, und die (in einem Thread, der ohnehin schon auf bedauerliche Weise abdriftet) dann (vielleicht aufgrund willentlicher Falschinterpretation?) noch einmal klarstellen muss) : Ich habe gesagt: "...daher sehe ich das *in diesem speziellen Fall eher* als "syntactic sugar" an. Das soll nicht heißen, dass es *nicht in anderen Bereichen sinnvoll und praktisch sein kann*, ..." - reicht die Hervorhebung, oder muss ich mich noch weiter rechtfertigen? :noe:


----------



## Landei (12. Okt 2009)

Ist zwar schon etwas her, aber ich hatte das erst jetzt gelesen. Falls du dich auf meinen Beitrag beziehst: Du musst dich hier überhaupt nicht rechtfertigen, denn erstens stand dort: "Wer behauptet, das Closures *ausschließlich*..." und zweitens war mein Beitrag gar nicht auf dich, sondern auf so herrlich pauschale Aussagen wie...



> Wenn aber der ActionListener eine eigene Klasse ist, dann benötige ich weder Closure noch die Möglichkeit, anonyme Klassen zu definieren (die ich auch nicht mag).



... von marasek gemünzt.

Trotzdem bin ich der Meinung, "syntaktischer Zucker" ist oft sehr wichtig (und jeder, der schonmal Map<Integer,List<String>> map = new HashMap<Integer, List<String>> geschreiben hat, sollte da eigentlich zustimmen). "Syntaktischer Zucker" macht gewisse Gedankengänge erst möglich, weil er erlaubt, Probleme von einem neuen Blickwinkel aus zu sehen. Das mathematische Wissen ist auch erst "explodiert", als man "syntaktische Zucker" namens Operatoren eingeführt hatte (Gauß schrieb seine Gleichungen noch mit den lateinischen Worten für "gleich", "plus" u.s.w.). Für mich ist die Evidenz für Sapir-Whorf überwältigend, und die Geringschätzung für "syntaktischen Zucker" darum absolut unverständlich.


----------



## SlaterB (12. Okt 2009)

um nochmal auf meinem Punkt zurückzukommen:

Syntax ist schön und gut, kann sich niemand erwehren,
dennoch scheint es mir die explizite Aussage


Landei hat gesagt.:


> Wer behauptet, Closures wären ausschließlich "syntaktischer Zucker", hat eine wichtige Sache nicht verstanden. Closures können *wirklich* mehr als Java's anonyme Klassen. Ein Beispiel [..]


seltsam, wenn das doch anscheinend in Java auch geht, von Syntax abgsehen


----------



## marasek (12. Okt 2009)

Landei hat gesagt.:


> Trotzdem bin ich der Meinung, "syntaktischer Zucker" ist oft sehr wichtig (und jeder, der schonmal Map<Integer,List<String>> map = new HashMap<Integer, List<String>> geschreiben hat, sollte da eigentlich zustimmen). "Syntaktischer Zucker" macht gewisse Gedankengänge erst möglich, weil er erlaubt, Probleme von einem neuen Blickwinkel aus zu sehen. Das mathematische Wissen ist auch erst "explodiert", als man "syntaktische Zucker" namens Operatoren eingeführt hatte (Gauß schrieb seine Gleichungen noch mit den lateinischen Worten für "gleich", "plus" u.s.w.). Für mich ist die Evidenz für Sapir-Whorf überwältigend, und die Geringschätzung für "syntaktischen Zucker" darum absolut unverständlich.



In z. B. PHP ist das definitiv einfacher. Die Frage ist dann für mich eher: soll & kann ich einen in PHP komfortabel möglichen Stil 1:1 auf Java übertragen? Es ist dann eher sinnvoll, ein paar Objekte mehr zu schreiben. In PHP macht man eher mal $color = array("red"=>255, "green"=>255, "blue"=>255), aber das ist nicht OOP.

Den sprachlichen Ansatz würde ich teilen, wenngleich Sapir-Whorf meiner Erinnerung nach als widerlegt gilt bzw. sich als nicht sonderlich tragfähig erwiesen hat. Programmieren ist für mich wie Sprache, deswegen bevorzuge ich wohl eine explizite, "geschwätzige" Syntax.


----------



## 0x7F800000 (12. Okt 2009)

@SlaterB:


SlaterB hat gesagt.:


> auch geht, von Syntax abgsehen


In anderen Threads ähnlicher Art wurde es doch schon zigfach erwähnt: _"geht mit anderer Syntax"_ ist bei einer Diskussion über verschiedene turingvollständige Sprachen wenig aussagekräftig. Alles geht mit jeder dieser Sprachen. Aber in Java wäre für dieselbe Funktionalität wie in Landei's beispiel eine zusätzliche Interface und zwei anonyme Klassen notwendig. Da bräuchte man alleine Aufgrund der vielen Klammer schon etwa 10 Zeilen, während in Landei's beispiel alles in eine einzelne kurze Zeile reinpasst.

@Landei: 
zwecks Gleichgewichtserhaltung werf ich mal eine Scala-kritische Frage rein: 
Wieso wird bei Scala an jeder Ecke plakattiert, wie toll sich damit alle möglichen DSL's umsetzen lassen, während man da die am weitesten verbreiteten Grundrechenarten nicht ordentlich implementieren kann? Konkreter: Operatorwertigkeit von [c]^[/c] lässt sich imho nicht gradbiegen, und [c]**[/c] ist aus demselben Grund auch keine Alternative... ???:L
Hab jetzt ein bisschen rumgegoogld, aber keine Hinweise auf nennenswerte Bemühungen entdeckt, die Operatorwertigkeit flexibler zu machen. :bahnhof:

@marasek:


> In z. B. PHP ist das definitiv einfacher. Die Frage ist dann für mich eher: soll & kann ich einen in PHP komfortabel möglichen Stil 1:1 auf Java übertragen? Es ist dann eher sinnvoll, ein paar Objekte mehr zu schreiben. In PHP macht man eher mal $color = array("red"=>255, "green"=>255, "blue"=>255), aber das ist nicht OOP.


Was genau ist hier die Aussage? Dass PHP im vergleich zu Java äußerst furchtbar & inkonsistent ist, weiss man auch so...


----------



## bygones (12. Okt 2009)

marasek hat gesagt.:


> deswegen bevorzuge ich wohl eine explizite, "geschwätzige" Syntax.


ich bevorzuge auch lieber sprechende frauen, wenn sie aber einem zuviel ins Ohr suelzen wirds nervig.

uebersetz: explizit, geschwaetzig gern, unnoetiges gelaber ('boilerplate) bitte nicht

;-)


----------



## SlaterB (12. Okt 2009)

0x7F800000 hat gesagt.:


> Aber in Java wäre für dieselbe Funktionalität wie in Landei's beispiel eine zusätzliche Interface und zwei anonyme Klassen notwendig. Da bräuchte man alleine Aufgrund der vielen Klammer schon etwa 10 Zeilen, während in Landei's beispiel alles in eine einzelne kurze Zeile reinpasst.


ein Interface + anonyme Klassen braucht man vielleicht an sich für Closures, das ist ja hinlänglich bekannt,

bei


> Der Witz ist, dass beide Closures Zugriff auf dasselbe x besitzen und die Änderungen der „anderen Seite“ sehen können."


gehts aber wirklich nur um das x und da muss man doch in Java nicht viel mehr als
final Object x;
schreiben, schon kann jederman darauf zugreifen (etwas komplizierter vielleicht mit inneren Zustand, statt direkt x zu verändern)


----------



## Landei (14. Okt 2009)

0x7F800000 hat gesagt.:


> @Landei:
> zwecks Gleichgewichtserhaltung werf ich mal eine Scala-kritische Frage rein:
> Wieso wird bei Scala an jeder Ecke plakattiert, wie toll sich damit alle möglichen DSL's umsetzen lassen, während man da die am weitesten verbreiteten Grundrechenarten nicht ordentlich implementieren kann? Konkreter: Operatorwertigkeit von [c]^[/c] lässt sich imho nicht gradbiegen, und [c]**[/c] ist aus demselben Grund auch keine Alternative... ???:L
> Hab jetzt ein bisschen rumgegoogld, aber keine Hinweise auf nennenswerte Bemühungen entdeckt, die Operatorwertigkeit flexibler zu machen. :bahnhof:



Das stimmt und ist ärgerlich. Operator-Prioritäten lassen sich in kaum einer Sprache festlegen (mir fällt nur Prolog ein). Scala erlaubt mit der "Doppelpunkt-Regel" wenigstens, die Assoziativität zu ändern, das ist zumindest ein Anfang. Aber DSLs in Scala zu entwickeln ist nicht trivial, und manche Sachen lassen sich schlicht nicht umsetzen. Ich denke, die nächste Generation von Mainstream-Sprachen (wenn Scala "bewährt" bzw. "tot" ist) wird wesentlich weitergehende Möglichkeiten zur "Syntax-Kontrolle" bieten als Scala's DSLs oder lisp-artige Makros. Dabei gibt es schon jetzt Sprachen, die das können, wie das ziemlich unbekannte Seed7. Trotzdem ist Scala für mich ein Schritt in die richtige Richtung.


----------



## 0x7F800000 (14. Okt 2009)

Landei hat gesagt.:


> Das stimmt und ist ärgerlich.


Das ärgerliche dran ist nicht die tatsache, dass es nicht funktioniert, sondern vielmehr die Tatsache, dass dieses Opfer völlig umsonst ist: dass kein Mensch weiß, welche Wertigkeit der XOR-Operator eigentlich hat, konnte man in meiner letzten Umfrage imho recht deutlich sehen. Hätten die Entwickler dieser Konvention nicht gefolgt, dann hätten sie wohl inzwischen 10x soviele Mathematiker an ihrer Seite gehabt: genauer gesagt würde Scala auf Dauer praktisch alle mathematischen DSL's plattmachen, weil es den syntaktisch in nichts nachstehen würde (bzw. würde der Code fast genauso aussehen, wie ursprünglich). :bahnhof:


----------



## kama (6. Mrz 2010)

Hallo,



marasek hat gesagt.:


> Oder Verfechter von Ruby on Rails?


Man darf Ruby nicht mit Ruby on Rails verwechseln...Hier wird Java mit Scala verglichen...also die Sprache. Hier wäre es also korrekter Ruby zu schreiben.

Wenn ich Java mit Spring zusammen nehme (oder besser Spring Roo) dann kann ich das mit Ruby on Rails vergleichen, da Ruby on Rails ein Framework ist....und Spring bzw. Spring Roo ebenfalls...

MfG
Karl Heinz Marbaise


----------



## Landei (7. Mrz 2010)

0x7F800000 hat gesagt.:


> Hätten die Entwickler dieser Konvention nicht gefolgt, dann hätten sie wohl inzwischen 10x soviele Mathematiker an ihrer Seite gehabt: genauer gesagt würde Scala auf Dauer praktisch alle mathematischen DSL's plattmachen, weil es den syntaktisch in nichts nachstehen würde (bzw. würde der Code fast genauso aussehen, wie ursprünglich). :bahnhof:


Sprachen, die weitgehend der mathematischen Notation folgen, gibt es schon, z.B, Fortress


----------



## 0x7F800000 (8. Mrz 2010)

Landei hat gesagt.:


> Sprachen, die weitgehend der mathematischen Notation folgen, gibt es schon, z.B, Fortress


Hehe, auch schick^^ Irgendwie wollte ich langfristig sowas haben, hätten die das nicht implementiert, hätte ich früher oder später selbst damit angefangen [jaa, sicher^^] 

Wäre später evtl. einen blick wert.


----------

