Scala ...need to take away sharp knifes from people who have a tendency to cut themselves...

[Gregorrr]

Martin Oderskys Antwort (True Scala complexity | Hacker News) auf die neue Scala Kritik (True Scala complexity | @yaaang's blog).

Im Endeffekt geht es doch darum, dass ein Programmierer nicht in seiner eigenen Utopia lebt, sondern es gewisse Grenzen/Gesetze geben muss, um ein pragmatisches Programmieren im Team zu ermöglichen.

Wozu Java (statt C/C++), wieso ist Python so beliebt, Coding Conventions, usw.? Eine Programmiersprache ist in erster Linie für den Menschen da, sonst könnten wir alle in Assembler programmieren. Komplexität die nicht pragmatisch ist (außer im akadem. Umfeld ist schädlich, siehe Beitrag zur Komplexität)

Das tolle ist, dass Odersky wirklich hintendran ist versucht die Scala pragmatisch zu machen (und auch auf die Community hört). Ihm geht es also wirklich darum Scala als Ersatz zu Java zu etablieren.

Die Frage ist, ob es genügt, gewisse Features, nur als bei Compiler-Flag zur Verfügung zu stellen, oder ob man sie nicht eventuell ganz abschaffen sollte.

Ich persönlich halte es für sehr sinnvoll, die Komplexität (die nicht mehr pragmatisch ist) zu entfernen. Die missbräuchliche Möglichkeit ist einfach zu hoch. Bspw. kann ein Team genau festlegen: Mit diesen Kompiler-Flags wird kompiliert und somit wird die Verantwortung auf den Entscheider übertragen. Die Programmierer müssen sich daran halten.

Was denkt ihr über das bewusste "Beschneiden" einer Sprache?

 

[Marco13]

Hängt wohl davon ab, wie das aufgefaßt werden würde: Ist die Sprache ~"nur die Kindergarten-Version" wenn man die Features NICHT aktiviert, oder ~"eine expermientelle Hack-Sprache", WENN man sie aktiviert? Hätte eine einzige Zeile, die eins dieser Features verwendet, zur Folge dass man sie für das gesamte Projekt aktivieren müßte (und sie dann auch "automatisch" an anderen Stellen verwendet werden würde) ?
Ich sehe in sowas keinen wirklichen Nutzen... Es könnte zwar theoretische Vorteile haben, eine Art "Spielwiese" für neue Sprachfeatures zu haben, aber das sollte dann durch mehr als ein Compiler-Flag als solche gekennzeichnet sein.
(BTW: Hab den Artikel jetzt aber noch nicht gelesen)

 

[schlingel]

Ich persönlich halte es für sehr sinnvoll, die Komplexität (die nicht mehr pragmatisch ist) zu entfernen.

Amen, allerdings was im speziellen das nicht mehr pragmatisch ist, gibt Stoff um Seiten mit Diskussionen, nahe Flamewars, zu füllen. Siehe nur den Scala-Kritik-Thread hier im Forum. Genau aus diesem Grund gibt es solche Compiler-Flags die nichts anderes als Notlösungen sind.

Bspw. kann ein Team genau festlegen: Mit diesen Kompiler-Flags wird kompiliert und somit wird die Verantwortung auf den Entscheider übertragen. Die Programmierer müssen sich daran halten.

Das ist doch sowieso überall Standard. Wie sollte das sonst auch anders funktionieren? Einen Build-Server gibt's mehr oder weniger doch immer bei größeren Projekten.

Was denkt ihr über das bewusste "Beschneiden" einer Sprache?

Sehr viel. Denn nicht jedes Program das syntaktisch und semantisch korrekt ist, ist auch gut bzw. gut wartbar. Dementsprechend ist es notwendig Richtlinien für ein Team aufzustellen.

 

[schalentier]

Was denkt ihr über das bewusste "Beschneiden" einer Sprache?

Halte ich fuer ziemlichen Unfug. Waere es sinnvoll, einen Compilerschalter im javac einzubauen, um Generics abzuschalten (mal abgesehen von -source 1.4)? Oder fuer den gcc, um die C++ Templates abzuschalten? Oder die Pointerarithmetik?

Was passiert, wenn man sich spaeter doch noch umentscheidet, und Feature ABC wieder aktiviert (weil man das eben doch braucht)? Da koennten grossartige Probleme auftreten...

Generell finde ich es nicht sehr praktisch, wenn man den Compiler fuer ein groesseres Projekt quasi nach Belieben konfigurieren kann. Also ich kann einfach nicht erkennen, welche Vorteile das nun bringen soll. Mir reicht die Entscheidung/Diskussion, welche Sprache man nun hernimmt, meist anstrengend genug ;-)

Der Rant ist uebrigens sehr lesenswert, weil der Autor offenbar doch einigen Durchblick hat und nicht nur sinnlos rumschwallt. Zudem bestaetigt er meine bisherige Meinung zu Scala ;-)

 

[escalate]

Waere es sinnvoll, einen Compilerschalter im javac einzubauen, um Generics abzuschalten (mal abgesehen von -source 1.4)?

Ich brauche den nicht, aber es spricht auch nicht wirklich etwas dagegen. Wenn es jemand unbedingt will kann er Generic-Freiheit in seinem Code auch ohne Schalter erreichen...
Abschaltbare Reflection wäre vielleicht auch was.

Oder fuer den gcc, um die C++ Templates abzuschalten? Oder die Pointerarithmetik?

Wäre vielleicht auch keine so schlechte Idee. Immerhin kann man Exceptions abschalten

Was passiert, wenn man sich spaeter doch noch umentscheidet, und Feature ABC wieder aktiviert (weil man das eben doch braucht)? Da koennten grossartige Probleme auftreten...

Warum sollten da Probleme auftreten? So ein Schalter erzwingt doch nur, dass man auf bestimmte Features im eigenen Code verzichtet, so würde ich es mir zumindest vorstellen. Das kann man mit externen Tools oder Team-Richtlinien genauso erreichen.

Das in den Compiler einzubauen ist einfach nur praktischer und zuverlässiger.

Besonders gut wäre es, wenn man es optional einfach nur als Warnung einschalten könnte.

Der Rant ist uebrigens sehr lesenswert, weil der Autor offenbar doch einigen Durchblick hat und nicht nur sinnlos rumschwallt.

Das ist im Vergleich zu dem, was man sonst so zu dem Thema lesen "darf" schon ein sehr großer Unterschied. Perfekt ist er natürlich auch nicht, aber dazu steht genügend in den Kommentaren.

Aber ingesamt ein wirklich sinnvoller Beitrag.

Zudem bestaetigt er meine bisherige Meinung zu Scala ;-)

Wie, meintest du das Zitat hier?

"If there’s one thing more time-consuming than illustrating the complexities of the Scala language, it’s illustrating all the advantages, and I’ve already spent more time on this post than I’d care to admit."