Diskussion:Scala (Programmiersprache)

gedanken...

• funktionen innerhalb von funktionen
• programmiermodell (analog java/.net)
• overlay des typsystems über java/.net
• pattern matching & case classes (XML..)
• traits / mixins
• operatorüberladung und block-syntax (siehe ruby..)
• singletons (object)
• echte OO, alles ist ein objekt (auch funktionen..)
• echt funktional, funktionen sind erstklassige werte

könnte alles noch rein.. -- ∂ 16:25, 16. Jul. 2007 (CEST)

Operatorüberladung vs Funktionen

"Dieses Verhalten wird oft fälschlich als Operatorüberladung bezeichnet. Tatsächlich jedoch werden bei diesem Vorgang Methoden erstellt, welche die Funktion von Operatoren darstellen." In welcher Sprache mit Operator-Überladung gilt dies denn nicht? Ist doch immer so, dass es "nur" normale Funktionen/Methoden sind, in die man halt üblicherweise Operator-Semantik ein-programmiert. -- 84.58.181.102 13:06, 11. Jun. 2009 (CEST)
Sehr schön/gut bemerkt die Formulierung ist etwas schwammig. Entscheidend hierbei ist das JEDE beliebige Methode (wenn die Parameter entsprechend definiert sind) als "Operator" verwendet werden kann. Das habe ich auch versucht im Abschnitt "einheitliches Zugriffsmuster" zu erklären 1 ist ein Objekt, 2 ist ein Objekt. 1 definiert die Methode "+" und so kann man schreiben:
(1).+(2) und das ist identisch mit:
1 + 2
Hier zu kommt das Methoden Bezeichner kaum eingeschränkt sind (siehe Scala Spezifikation bzw hier: boolean-algebra-internal-dsl-in-scala ). -- 12:00, 13. Jun. 2009 (CEST) (ohne Benutzername signierter Beitrag von 84.162.175.187 (Diskussion | Beiträge) )

Struktur typen

Bill Venners ( Co-Autor Programming in Scala) Hat hier : parleys Video Präsentation und JavaOne 2009 Präsentation, Seite 38,44 Ein recht gutes Beispiel für Struktur Typen und Ducktyping. Wenn ich Zeit finde werde ich die entsprechenden Informationen herausfiltern und hier im Scala einfügen. Ansonsten sind alle anderen herzlich dazu eingeladen ;) (nicht signierter Beitrag von 84.162.175.187 (Diskussion | Beiträge) 12:05, 13. Jun. 2009 (CEST))

Werte?

"Werte, Variablen und Methoden werden mittels Schlüsselwörtern val, var und def gefolgt von Typangaben deklariert bzw. definiert"

Was sind "Werte"? Ich vermute, damit sind Konstanten gemeint?

Laut Google sind das Konstanten. Schlechte Idee das "Wert" zu nennen. Jeder Entwickler kennt Konstanten. --37.5.75.105 11:51, 16. Jan. 2013 (CET)

Konzepte darstellen

Meines Erachtens fehlt am Anfang des Dokumentes eine Auflistung der wesentlichen Sprachfeatures, welche Scala von Java unterscheiden und Scala als eine natürliche Weiterentwicklung von Java charakterisieren. --Kelti 12:08, 13. Nov. 2009 (CET)

Überarbeitung

Ich habe die gesamte Seite überarbeitet und bin für Kritik offen. --Kelti 19:38, 7. Dez. 2009 (CET)

danke dir :) -- ∂ 20:25, 7. Dez. 2009 (CET)

Die Überarbeitung ist eigentlich recht gut gelungen. Vieles ist kürzer durch den Verweis auf die offizielle Seite. Einige wichtige Aspekte wurde beim "aufräumen" jedoch unter den Teppich gekehrt:

Abstrakte Typen : http://www.scala-lang.org/node/105 (ähnlich generischen Klassen)
Implizite Parameter : http://www.scala-lang.org/node/114 bzw. "Views" (deutscher Begriff? Sichten?) http://www.scala-lang.org/node/130

Pfad-abhängige Typen
frei: "Programmiersprachen welche die Definition von verschachtelten Typen erlauben bieten damit auch Zugriff auf den Pfad (Hierarchie) des Typs."
nach: http://programming-scala.labs.oreilly.com/ch12.html#PathDependentTypes
Existentielle Typen
auf der Mailing Liste, gab es eine Diskussion warum der Begriff nicht auf der offiziellen Hauptseite erklärt wird und schließlich wird hierauf verwiesen: http://www.drmaciver.com/2008/03/existential-types-in-scala/

Sollte irgendwo noch erwähnt werden das Scala "statischer" als Java ist?

CLR?

Sie kann auf einer JVM oder einer .NET-CLR ausgeführt werden.

Was ist denn eine CLR? Könnte jemand, der das weiß, an der Stelle ggf. einen Wikilink setzen? Danke! --Flo12 22:50, 7. Feb. 2010 (CET)

erledigt. war übrigends in CLR verlinkt. -- ∂ 02:14, 8. Feb. 2010 (CET)

Sollte man nicht erwähnen, daß die Unterstützung für .NET der JVM-Version weit hinterherhinkt? --MartinStettner 08:47, 20. Jul. 2010 (CEST)

ja. mach! -- ∂ 12:37, 20. Jul. 2010 (CEST)

Hello World

einfacheres Hello World: http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-1 (nicht signierter Beitrag von 93.133.91.10 (Diskussion | Beiträge) 17:20, 3. Apr. 2010 (CEST))
Das Application Trait hat seltsame Auswirkungen, und sollte deshalb nur verwendet werden man man weiß um welche genau es sich dabei handelt. (nicht signierter Beitrag von Wikitester2501 (Diskussion | Beiträge) 15:01, 17. Apr. 2010 (CEST))

ich hab das vorm längerem mal geändert. falls jemanden die details interessieren: [1] -- ∂ 18:58, 14. Jul. 2010 (CEST)

Listen

Im Abschnitt Konzepte bzw. Syntax wird exzessiver Gebrauch von Auflistungen gemacht. Hat jemand etwas dagegen, wenn ich das in Fliesstext (mit Unterschnitten) ändere? --Gms 22:54, 21. Apr. 2010 (CEST)

ganz im gegenteil, mach! -- ∂ 18:38, 22. Apr. 2010 (CEST)

Kategorie OOP

Die Kategorie:Programmiersprache für die JVM ist eine Unterkategorie von Kategorie:Programmiersprache Java, welches eine Unterkategorie von Kategorie:Objektorientierte Programmiersprache ist. Demnach muss ebendiese nicht auch noch mal als Kategorie genannt werden. --Zahnradzacken 10:16, 12. Jul. 2010 (CEST)

Dann ist Kategorie:Programmiersprache für die JVM falsch eingeordnet.

Wie dem auch sei, die Auflistung der Kategorien ist für den Leser ein integraler Bestandteil des Artikels. "Funktionale Sprache" aufzuführen, und "OO-Sprache" nicht, wirkt sehr befremdlich. --Daniel5Ko 11:37, 12. Jul. 2010 (CEST)

Vielleicht liegt das Problem aber auch zusätzlich darin, dass Kategorie:Programmiersprache Java eigentlich gar keine Kategorie ist. Wer weiß... --Daniel5Ko 00:28, 13. Jul. 2010 (CEST)

So, habe die Kategorisierung von Kategorie:Programmiersprache für die JVM mal geändert. Mal sehen, ob das als einigermaßen sinnvoll empfunden wird, oder sofort Widerstand auf den Plan ruft. Es erscheint mir bisher zumindest als nicht-schlechte Lösung. ;) --Daniel5Ko 00:58, 13. Jul. 2010 (CEST)

Ja, finde ich sinnvoll. Danke --Zahnradzacken 11:39, 13. Jul. 2010 (CEST)

PS: Was meinst du damit, dass Kategorie:Programmiersprache Java keine Kategorie sei? --Zahnradzacken 11:40, 13. Jul. 2010 (CEST)

Nun, wenn das was du tust (Artikel aus Kategorien K entfernen, wenn sie bereits in einer Unterkategorie von K verzeichnet sind) richtig und sinnvoll sein soll (wovon ich nicht gänzlich überzeugt bin, aber ich tendiere ganz leicht da hin), muss wenigstens einigermaßen eine Art Transitivität und Linearität vorliegen. Die kann man erreichen, indem man Zyklen (bzw. Beziehungen, die sich sehr leicht als solche interpretieren lassen) entfernt, was jetzt geschehen ist. Eine weitere Möglichkeit ist, Kategorien zu verbieten, die eigentlich eher Bedeutungswolkenzentren sind und keinesfalls auch nur annähernd als mengenähnlich angesehen werden können (die Untermengenrelation und deren Transitivität wird von solchen Kategorien treffsicher zerstört). Zur zuletzt genannten Art von Kategorie zählt in meinen Augen Kategorie:Programmiersprache Java. --Daniel5Ko 22:51, 13. Jul. 2010 (CEST)

Ob das, was ich tat, richtig war, weiß ich nicht. Ich habe mich da in dem Fall blindlings an Wikipedia:Kategorien#Hinweise für Autoren No. 4 gehalten. Besser wäre wohl gewesen, die Einordnung der neuen Kategorie zu hinterfragen. Zyklen müssen natürlich vermieden werden, aber wie du hier einen vermutet hast, ist mir noch nicht klar. Die andere Möglichkeit sehe ich etwas anders (sofern das bei dir nicht bloß Rhetorik war): Solche problematischen Kategorien (und dass das Problem in diesem Fall besteht, ist mir nun plötzlich bewusst geworden) sollten nicht verboten werden – besser jemand betrachtet es als Tag, als die Kategorie verhungern zu lassen. Statt dessen müsste diese Gedankenwolke durch sinnvolle, neue Kategorien entlastet werden. Sowas sollte dann aber besser an einem anderen Ort diskutiert werden. [Und was meinst du damit, dass die Untermengenrelation zerstört würde? Mengen sind Mengen, egal, was drin ist] --Zahnradzacken 23:30, 13. Jul. 2010 (CEST)

Re Zirkularität: Die Kategorie Java gehört natürlich in die Kategorie JVM-Sprache, und unabhängig davon, ob das tatsächlich so eingeordnet war (darum die Einschränkung "[sehr leicht als solches interpretierbar]"), war das umgekehrte bereits der Fall. Da haben wir den Zyklus.

Re Tag vs. Kategorie-als-Menge-mit-transitiver-Untermengenrelation: Das eine ist in höchstem Maße inkompatibel zum anderen. Wir haben damit ca. 2 oder 3 Möglichkeiten, das "falsche" auszuräumen:

1. problematische Kategorien wie oben,
2. die Vorstellung, man müsste/könnte Kategorisierungsredundanz aufgrund der Transitivität auflösen,
3. Zirkularität. (gut, das ist trivial und wahrscheinlich kein Punkt)
4. [Mist! Wie macht man eingerückte Aufzählungen?] [So :) --Zahnradzacken 15:14, 14. Jul. 2010 (CEST)] [Aber sind das dann nicht 4 Aufzählungen mit jeweils einem Punkt? Ah, scheinbar nicht, wie die Verwendung einer nummerierten Aufzählung zeigt. :) --Daniel5Ko 16:24, 14. Jul. 2010 (CEST)]

Re Zerstörung der Untermengenrelation: Bei diesen Bedeutungswolkenzentren hat man das Problem, dass Einordnungen in der Gegenrichtung durchaus sinnvoll sein können. Das führt, mengenmäßig interpretiert, zu einem kurzen Zyklus der Form $A\subseteq B,B\subseteq A$, was dann $A=B$ ergibt, was kaum im Sinne des Erfinders sein kann. Kurz: (glaube ich nach wahrscheinlich nicht-ausreichender Überlegung) Benutzung von Kategorien als Tags, zusammen mit Transitivität macht im schlimmsten Fall alle Kategorien gleich. ;) --Daniel5Ko 01:16, 14. Jul. 2010 (CEST)

Aber eigentlich will ich die Diskussion nicht fortführen. Viel zu Meta. Lass uns zum Konkreten zurückkehren. Die Üblichkeiten werden wir schon mitkriegen. :) --Daniel5Ko 01:24, 14. Jul. 2010 (CEST)

Sicherlich ist die Diskussion mühselig, aber dennoch notwendig in. Beispiel: in der englischen Wikipedia gibt für den Scala - Programmiersprache Artikel u.a. folgende Kategorien: Scala programming language | JVM programming languages | Java programming language family | Java platform Meiner Meinung nach totales Kategorie Chaos. wikiteste2501 21. Jul. 2010 (CEST) (13:36, 21. Jul 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Damit können sich die Trivial-Editoren und Metadiskussions-Liebhaber gerne beschäftigen. Inhaltlich ist ungefähr der ganze Informatik-Bereich in der deutschen Wikipedia katastrophal (oder, naja: zumindest die Randbereiche, die mich interessieren). Und das liegt nicht an fehlenden Belegen oder falschen Kategorisierungen, sondern eben an furchtbarem Inhalt. Ich versuche, mich hauptsächlich darum zu kümmern. (Und dabei deutsche Rechtschreibung zu verwenden.) --Daniel5Ko 22:13, 21. Jul. 2010 (CEST)

Zustand

Ich möchte hier mal auf den schlimmen Zustand des Artikels hinweisen. Er besteht nur aus Wörtern oder aus englischen Sätzen. Deutschsprachige Belege währen von Vorteil. Vielen Dank und freundliche Grüße, alofok's talk 11:21, 21. Jul. 2010 (CEST)

Danke für den wertvollen Hinweiss! Ich habe bereits bei der Überarbeitung versucht für die englischen Fachbegriffe entsprechende deutsche Wörter zufinden. Also wenn du Lust hast einfach überarbeiten! wikiteste2501 21. Jul. 2010 (CEST) (13:36, 21. Jul 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Sorry, dafür bin ich der falsche Mann was es IT&EDV angeht. Ich kann maximal sichten. Gruß, alofok's talk 13:44, 21. Jul. 2010 (CEST)

In der IT stammen Fachbegriffe in der Regel aus dem englischen Wortschatz. Daran sollte sich auch die deutschsprachige Wikipedia halten. In den 1970-er Jahren gab es zwanghafte Versuche, deutsches Vokabular einzuführen. Das hat zu Absonderlichkeiten wie dem pflichtwertigen Fehlwert als Übersetzung für default value geführt. Mit solchen Begriffen kann weder ein Spezialist noch ein gutwilliger Durchschnittsleser etwas anfangen. Meine Empfehlung: Fachbegriffe belassen wie sie sind.

Die Kapitel Testen und IDEs enthalten Aussagen, die teils trivial und teils nur für angehende Entwickler interessant sind. Meines Erachtens könnten sie ersatzlos entfallen bzw. noch weiter gekürzt werden (nur Links belassen?). Auch das Kapitel Siehe auch ist fragwürdig, denn es überschneidet sich semantisch mit der Infobox. Falls es hierfür Zustimmung gibt, kann ich mich darum kümmern.

Die Kritik, dass im Artikel anstelle vollständiger Sätze lediglich Aufzählungen in Form von Einzelworten vorkommen, trifft zu. Das gilt insbesondere für das Kapitel Geschichte. Aber aus einem Begriff wie Continuations einen vollständigen Satz zu formen bedeutet zwangsweise den Einstieg in die Erläuterung des Begiffes. Das würde ich gerne vermeiden, da der Artikel dann zu detailliert wird. Außerdem entstünden Redundanzen zu anderen Artikeln. Teilweise könnte man aber die derzeitigen Links zur englischsprachigen Scala-Seite durch Links auf Begriffe der deutschsprachigen Wikipedia ersetzen. Dadurch ginge zwar der direkte Bezug zu Scala verloren aber es entspäche dem Geist von Wikipedia. Findet ein solches Vorgehen Zustimmung?

--Kelti 10:17, 22. Jul. 2010 (CEST)

Das zwanghafte Übersetzen ins Deutsche finde ich genauso bescheuert wie das zwanghafte Beibehalten englischer Begriffe aus Angst vor schlechter Übersetzung. So oder so: Wenn es etablierte Übersetzungen gibt, sollte man diese Bevorzugen – vielleicht gibt es einen gleichlautenden Artikel dazu oder es wird früher oder später ein solcher entstehen.

Redundanz zur Infobox finde ich nicht fragwürdig, ansonsten müsste man auch die Einleitung streichen. Ich finde die Konvention sinnvoll, dass Infoboxen redundant sein müssen, weil sämtliche Information aus dem Fließtext heraus zu entnehmen sein sollte; der Zweck der Infobox wäre dann lediglich ein visuelles Bonbon.

Die Abschnitte Testen und IDE finde ich auch grauenhaft trivial, vielleicht kann man sie in anderer Form irgendwo einarbeiten?

Auf jeden Fall sieht es schrecklich aus, wenn jede Kleinigkeit im Fließtext durch Links zur Scala-Seite belegt ist. Dafür sollte man Referenzen verwenden (wenn nötig). Die Idee der Wikilinks ist gut. In dem Zusammenhang könnte auch gerne ein Artikel zu Continuations entstehen.

--Zahnradzacken

die geschichte hab ich mal kurz durchgedreht, da fehlt aber natürlich noch einiges. ansonsten: klingt gut, hau rein :) -- ∂ 11:15, 22. Jul. 2010 (CEST)

Hallo Kelti!
Danke schon mal für die Änderungen! Ein paar Anmerkungen:
Ich halte die Überschrift Plugins, Frameworks leider für etwas unglücklich. Den der Begriff "Plugin" bekommt im Context immer eine andere Bedeutung wobei hier natürlich IDE Plugins gemeint sind. Die Continuations z.B. sind in Scala als Compiler Plugin (http://www.scala-lang.org/node/140) implementiert und muss als solches auch über spezielle Parameter aktiviert werden. Es existieren noch weitere Plugins. Ich finde dies ist ein sehr nützliches Feature (Compiler Plugins zu schreiben bzw. das ein API dafür vorgesehen ist). Also sollten wir das Feature "Compiler Plugins" erwähnen und den Begriff im Zusammenhang mit IDEs weglassen?!
Außerdem was hältst du von den Punkten die ich oben bereits erwähnte:
http://de.wikipedia.org/wiki/Diskussion:Scala_%28Programmiersprache%29#.C3.9Cberarbeitung
Könnte man das noch irgendwo bei Konzepte unterbringen?
Noch eine Sache die in die Katagorie "Geschichte" passen würde, Scala hat 2010 ja zum ersten mal am Google Summer of Code teilgenommen. Die ersten Ergebnisse (kollaboratives ScalaDoc 2) sind auch schon verfügbar. 18:27, 22. Jul. 2010 (CEST) wikiteste2501

Einige der Anregungen habe ich in den Artikel aufgenommen, aber nicht alle. Es wurden hier und bei Diskussion:Scala_(Programmiersprache)#.C3.9Cberarbeitung Konzepte erwähnt, die meines Erachtens den Rahmen des Artikels sprengen würden. Implizite Parameter, Views, Pfad-abhängige Typen, Existentielle Typen und API für Compiler-Plugins habe ich weggelassen. In der derzeitigen Form stellt der Artikel einen angemessen Kompromiss dar zwischen einer vollständigen Auflistung der Sprachfeatures und der angestrebten Kürze und Prägnanz innerhalb von Wikipedia. Wir wollen ja kein komplettes Lehrbuch verfassen. Falls allerdings das allgemeine Interesse doch stärker sein sollte als ich vermute, könnte man natürlich Unterseiten anlegen - wie dies beispielsweise für Java mit der Unterseite Java-Syntax im Lauf der Zeit geschehen ist. --Kelti 11:57, 24. Jul. 2010 (CEST)

Hallo Kelti,
Ich würde auch sagen das nicht alle obigen Features unbedingt in den Artikel müssen. Dennoch würde ich sagen das zumindest "implicits" eine Erwähnung verdienen da sie eines DER mächtigsten Features von Scala darstellen (z.b. auch erwähnt in "Programming in Scala"). Durch diese werden erst : Views, Typklassen (siehe Haskell) ermöglicht. 15:30, 23. Jul. 2010 (CEST) wikiteste2501

Implicits sind sicher ein sehr starkes Feature des Compilers. Im täglichen "Brot- und Butter-Geschäft" eines Entwicklers werden sie wahrscheinlich selten eingesetzt - eher beim Compilerbau oder im akademischen Umfeld. Mir fällt es schwer, die Wirkungsweise prägnant zu beschreiben ohne dabei die weit reichenden Konsequenzen zu vernachlässigen. Vielleicht versuchst du dich einmal an einer Formulierung. --Kelti 21:08, 24. Jul. 2010 (CEST)

die neuen collections setzen massiv implicits ein, im täglichen geschäft ist pimp my library richtig nützlich. ich hab mal was dazu geschrieben, ihr seid natürlich herzlich eingeladen es verständlicher zu formulieren [2]. -- ∂ 21:40, 24. Jul. 2010 (CEST)

Danke ∂, Kelti!
Ich denke so können wir erst einmal den Artikel stehen lassen bis weitere, konstruktive Vorschläge eintreffen. Mit freundlichen Grüßen
15:21, 25. Jul. 2010 (CEST) wikiteste2501

implicit

Wäre es sinnvoll, den "implizit" Abschnitt als Unterpunkt des Typsystems führen? (nicht signierter Beitrag von Kelti (Diskussion | Beiträge) 19:49, 25. Jul 2010 (CEST))

Hallo Kelti,
Ich habe einmal bei "Programming in Scala" sowie bei "A Tour of Scala/offizielle Webseite" nach gesehen. In beiden Fällen wird das Typsystem nicht im Zusammenhang (bzw. garnicht) erwähnt. Es ist ein Feature des Compilers sowie z.B. der XML - Support. Also ich würde das hier so lassen. 15:21, 25. Jul. 2010 (CEST) wikiteste2501

EU fördert Open-Source-Sprache Scala

Vielleicht nicht ganz uninteressant dazu heise-Artikel 84.60.47.188 18:29, 15. Jan. 2011 (CET)
Einfach einbauen unter dem Punkt "Geschichte"! :) 18:48, 16. Feb. 2011 (CEST) wikiteste2501

Syntax

"Typinferenz: Der Compiler den Typ einer Variable aus dem Kontext herleiten." Dieser Satz kein Hauptverb. "kann"/"versucht"? Was fehlt da? (nicht signierter Beitrag von 137.248.4.10 (Diskussion) 12:27, 16. Feb. 2011 (CET))
Danke für das Korrekturlesen. Ist geändert. 18:48, 16. Feb. 2011 (CEST) wikiteste2501

Beispiele

Als Beispiel ist im Artikel nur ein "Hello World" vorhanden. Ich denke da könnte man noch etwas mehr ergänzen, ich würde da ganz einfach mal die Beispiele aus dem Haskell Artikel vorschlagen (entsprechend übersetzt):
http://de.wikipedia.org/wiki/Haskell_%28Programmiersprache%29#Beispiele
Möchte jemand andere Beispiele sehen? Ideen, Vorschläge?
18:59, 22. Feb. 2011 (CEST) wikitester2501

Versionsgeschichte

Mittel-/langfristig wäre es wohl sinnvoll ein separates Kapitel für die Neuerungen/Änderungen in den verschiedenen Versionen zu haben (vgl. Java (Technik) #Versionen, damit man nicht bei jeder neuen Version den Abschnitt "Geschichte" umstricken muss. Gerade im Hinblick auf Version 2.9, die in einigen Wochen veröffentlicht wird. -- Soc88 11:01, 22. Mär. 2011 (CET)

Erledigt! -- Soc88 20:52, 23. Mär. 2011 (CET)

Deutlich kompakter?

Im Vergleich mit Java ist der Sourcecode deutlich kompakter.

Wenn ich mir die folgenden Beispiele anschaue, stimmt das praktisch nie.

variable: Typ
Wäre in java:
Typ variable;
Also nicht kompakter.

val wert: Int = 42
Ist in java sogar kürzer:
int wert = 42;

Nein, das wäre in Java final int wert = 42;

def methode(parameter1: String, parameter2: Boolean): Unit
Hier ebenso, Java variante ist "kompakter":
Unit methode(String parameter1, Boolean parameter2);

Also wenn jemand der Meinung ist, dass Scala Code wirklich "kompakter" als Java Code ist (was ja durchaus sein kann), dann sind die Beispiele mehr als schlecht gewählt. -- 193.47.161.197 09:55, 13. Mai 2011 (CEST)

stimmt, in diesen beispielen merkt man davon nichts, obwohl der text das suggerierte. ich hab's mal leicht angepasst, aber das ist natürlich nur eine notlösung. -- ∂ 10:40, 13. Mai 2011 (CEST)

Die Sätze waren unglücklich verwoben, der "Vergleich zu Java" bezieht sich auch auf die folgenden Sätze, die Aussage über kompakten Code hatte mit den Beispielen aber nichts mehr zu tun. Sie war aber sowieso zu stark, man kann auch mit Scala Code schreiben, den man mit Java dann kürzer ausdrücken kann. Für präzisere Aussagen (wie "für jeden Java-Code gibt es einen kompakteren Scala-Code, der dasselbe tut") bräuchte man seriöse Quellen, wenn es sie denn gäbe. --Zahnradzacken 16:47, 13. Mai 2011 (CEST)

Um mal auf dieses Beispiel hier einzugehen:

Java:
public void methode(String parameter1, Boolean parameter2){ System.out.println("Buu");}
//Scala, in scala sind alle methoden per DEFAULT public
def methode(parameter1: String, parameter2: Boolean) = println("Buu")
//Diese Methode hat auch den return typ: unit, ohne das er ausgeschrieben einzeilige Methoden benötigen keine {} Klammern sondern lediglich ein =
Ach so und bitte mal eine HashMap in Scala/Java definieren :D 00:13, 20. Mai 2011 (CEST) wikiteste2501

Und was willst du damit aussagen? --Zahnradzacken 14:15, 20. Mai 2011 (CEST)

Das Scala zumindest gleichauf ist mit Java Code und in einign Fällen sogar DEUTLICH kompakter siehe HashMap oder case classes? 17:29, 21. Mai 2011 (CEST) wikiteste2501

Und ich hab drei Gegenbeispiele:

1. • var x:Float = 1
   • float x = 1;
2. • var variableMitAussprechbaremNamen=1+1+1+1+1
   • int x = 5;
3. • var res = if (cnd) option1 else option2
   • Choice res = cnd? option1 : option2;

Man kann jeweils in beiden Sprachen Code schreiben, der das gleiche tut, aber länger ist. Dass man anders herum mit Scala immer mindestens gleichauf sein kann, kann man nicht anhand von Beispielen zeigen. --Zahnradzacken 20:22, 20. Mai 2011 (CEST)
Zwei deutliche Beispiele (IMHO):

1.
// Java
HashMap<String,Person> persons = new HashMap<String,Person>();
// Scala
val persons = new HashMap[String,Person]

2.Java:
class Person { private String firstName; private String lastName; private int age; public Person(String firstName, String lastName, int age){ this.firstName = firstName; this.lastName = lastName; this.age = age; } public void String getFirstName() {return this.firstName;} public void setFirstName(String firstName) { this.firstName = firstName; } public void String getLastName() {return this.lastName;} public void setLastName(String lastName) { this.lastName = lastName; } public void int getAge() {return this.age;} public void setAge(int age) { this.age = age; } }
Hashcode und equals sind werden bei case classes ebenso mit generiert!
// Scala
case class Person( var firstName: String, var lastName: String, var age: Int)

Ich würde nicht sagen das Scala immer kürzer ist. Aber insgesamt, insbesondere durch case classes, ist Scala Code im gesamten Projekt schon deutlich weniger. Die meisten Quellen die ich gelesen haben Sprechen von einem Einsparpotential von 2,5. 22:57, 20. Mai 2011 (CEST) wikitester2501

Wie gesagt, Beispiele verdeutlichen nur. Aber deine Quellen könnten eine Bereicherung für den Artikel sein, sofern es sich nicht bloß um Blogs handelt.

Wie wäre denn eigentlich der passende Scala-Code, wenn man in deinem Beispiel bei Java

public boolean setAge(int age){if (age < 0) return false; this.age=age; return true;}

hätte? Die ganze Idee von Settern und Gettern ist ja, dass man Kontrolle haben will. --Zahnradzacken 14:29, 21. Mai 2011 (CEST)

Hallo Zahnradzacken :)
Meine beiden Beispiele habe ich hier entnommen: http://www.slideshare.net/deanwampler/seductions-of-scala Seite 94-109. Du kannst Scala die setAge Methode genau so schreiben, übersetzt würde sie wohl so aussehen:

def setAge(age:Int) = if(age < 0) false else {this.age=age; true}

Der Rückgabetyp wird vom Compiler per Typinferenz bestimmt. Man könnte ihn aber auch explizit angeben. In der Praxis wird das häufig gemacht wenn der Rückgabetyp z.B.: ein komplexes Objekt o.ä. ist. 18:54, 23. Mai 2011 (CEST) wikitester2501

ich hab mich mal erfrecht, da noch zwei klammern zu spendieren, ohne die wird's nicht gehen. aber mal im ernst: setter, und erst recht nicht-triviale setter, sind sowas von letztes jahrtausend... var in case classes macht auch niemand. -- ∂ 19:31, 23. Mai 2011 (CEST)

Das var Beispiel war tatsächlich nur auf eine "normale" Klasse bezogen. Aber die zwei Klammern waren tatsächlich nicht notwenig 2.9.0final:

class Person(var age:Int){
     | def setAge(age:Int) = if(age < 0) false else this.age=age; true } 
//valide :)

21:07, 23. Mai 2011 (CEST) wikitester2501

valide schon, tut aber nicht was du denkst. was du geschrieben hast ist äquivalent zu

class Person(var age:Int) {
  def setAge(age:Int):AnyVal = { if (age < 0) false else this.age = age }
  true
}

denn ein methoden-body besteht immer aus genau einem ausdruck. -- ∂ 21:39, 23. Mai 2011 (CEST)

stimmt ich hätte die REPL ausgabe kontrolieren sollen :S 21:53, 23. Mai 2011 (CEST) wikitester2501

*lach* oder eben doch den return-typ hinschreiben und dich anmeckern lassen. wozu hat man schließlich ein typsystem :) -- ∂ 11:30, 24. Mai 2011 (CEST)

Parameterlisten?!?

"Falls die Signatur einer Methode n Parameterlisten enthält ..." Ich bin zwar ein Programmierer aus dem letzten Jahrtausend, aber: eine Methode hat nur eine Parameterliste die n Parameter enthält. Noch was anderes: wie sehen denn nicht-triviale setter dieses Jahrtausends aus? 87.162.44.157 15:30, 30. Nov. 2011 (CET)

Zu den mehreren Parameterlisten siehe angegebenen Einzelnachweis oder Scala language spec. Punkt 4.6. --Daniel5Ko 18:04, 30. Nov. 2011 (CET)

Danke für den Hinweis. Die "Erklärung" an der Stelle war mir zu unverständlich, daher habe ich mal gegoogled und das hier: http://www.weiglewilczek.com/fileadmin/Publications/Einstieg_in_Scala_2__JS_02_01.pdf gefunden. Vielleicht ist das auch für andere hilfreich. 87.162.44.157 10:45, 1. Dez. 2011 (CET)

Hallo 87.162.44.157,

ja ein Hinweis auf Currying wäre wohl angebracht gewesen. Wenn man zuvor nur Programmiersprachen mit einer Parameterlist kannte ist es halt ein neues Konzept. Im übrigen könnte man im Curry Artikel gleich mal Beispiele für scala und haskell einfügen. Die englische Wikipedia hat sogar ein Java Beispiel :O Also lass dich nicht entmutigen sondern einfach weiter fragen als auch editieren, es gibt viel zu tun :) mfg 18:28, 22. Dez. 2011 (CEST) wikiteste2501

weiß nicht, ob das nicht eher verwirrend ist - currying heißt ja eine funktion mit einer parameterliste in eine kette von funktionen mit je einem parameter umzuwandeln, das ist zwar ein ähnliches thema aber ganz und gar nicht das selbe. man kann in scala eine funktion mit mehreren ein-elementigen parameterlisten schreiben, das entspräche manuellem currying, aber das ist nur ein spezialfall dessen, was in scala geht. -- ∂ 23:38, 22. Dez. 2011 (CET)

Hallo ∂,

worauf beziehst du dich? Den Scala-Artikel oder den Currying Artikel? An einer von beiden Stellen würde ich ein Codebeispiel IN Scala ganz nett finden, oder? 12:39, 23. Dez. 2011 (CEST) wikiteste2501

den scala-artikel. im artikel currying wäre scala imho erst recht fehl am platze. allenfalls könnte mandort neben der lambda-notation noch javascript o.ä. einbauen, was mehr leute lesen können. -- ∂ 01:21, 24. Dez. 2011 (CET)

XML

Die Änderung vom 28. März 2013 ersetzt die ursprüngliche Formulierung "Zum Sprachumfang gehören grundlegende XML-Operationen ... " durch "In Scala ist bereits eine Bibliothek enthalten welche grundlegende XML-Operationen ... ". Es ist so, dass im Kapitel 10 der Sprachspezifikation die angesprochene grundlegende XML Funktionalitäten definiert ist. Diese Vermengung einer Programmiersprache mit einer Auszeichnungssprache - in diesem Fall XML -, halte ich zwar für ausgesprochen unglücklich. Aber sie existiert. --Kelti (Diskussion) 09:41, 30. Apr. 2013 (CEST)

Currying

Currying ist kein zentrales Sprachmerkmal von Scala; und es ist auch nicht, im Vergleich zu anderen funktionalen Programmiersprachen, in einer speziellen Weise implementiert; so denke ich, dass dafür kein separater Abschnitt gerechtfertigt ist. Ich werde das dann mal zusammenkürzen. --Zumbo (Diskussion) 11:14, 11. Apr. 2014 (CEST)

Verwendungszwecke

Im Artikel ist beschrieben, wer Scala verwendet.

Es fehlt eine genauere Ausführung, für welche Zwecke sich Scala besonders eignet. Wie sieht es z.B. mit der Ansteuerung von Datenbanken aus? Sind auch Offline-Anwendungen sinnvoll mit Scala zu programmieren? --Turan MUC (Diskussion) 13:48, 11. Mai 2014 (CEST)

Kritik

Ich kann in folgendem Abschnitt keinen Nutzen erkennen:

Da Scala grundsätzlich Code für dieselbe JVM generiert wie Java und andere JVM-basierende Sprachen, also keine grundsätzlichen, technischen Vorteile bietet, stellt sich für eine Kritik nur die Frage, inwiefern sich Vorteile hinsichtlich der Entwicklungszeit, Fehlertoleranz und Projektleitung ergeben, so wie die Qualität der Scala-Bibliotheken bezüglich Geschwindigkeit, Fehlerfreiheit und Verwendbarkeit.

Kritik kommt darin gar nicht vor. Er besteht nur aus der höchst fragwürdigen Behauptung, es gebe keine "grundsätzlichen, technischen" Unterschiede zu anderen JVM-Sprachen. Das ergibt sowenig Sinn, wie man von zwei x-beliebigen Sprachen, die beide x86-64-Maschinencode produzieren, behaupten würde, es gäbe keine wesentlichen technischen Unterschiede. Es geht schliesslich um Sprachen, nicht um Zielplattformen. Alles, was in der zweiten Satzhälfte angesprochen wird, sind sehr zentrale Ansatzpunkte für die Kritik von Programmiersprachen. Aber eben, für diesen Artikel müsste man sie zuerst einmal konkret ausformulieren. --Zumbo (Diskussion) 14:46, 19. Mai 2014 (CEST)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.18.1
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.18.1
• http://code.google.com/p/scalaz/
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://code.google.com/p/scalaz/
• http://docs.oracle.com/javase/specs/jls/se5.0/html/conversions.html#5.1.2
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://docs.oracle.com/javase/specs/jls/se5.0/html/conversions.html#5.1.2

– GiftBot (Diskussion) 10:16, 4. Dez. 2015 (CET)

Plattform != Betriebsystem

Ist es möglich Betriebsystem durch das Wort Platform auszutauschen? In diesem Kontext macht es kaum Sinn, da eine JVM oder LLVM kein Betriebsystem sondern ein Compiler ist. --Blauer Kakadus (Diskussion) 00:24, 27. Mai 2020 (CEST)

Ein Compiler ist keine Plattform. JVM ist kein Compiler, sondern eine virtuelle Maschine. Bei LLVM als Plattform meint man den virtuellen Befehlssatz davon und nicht den Compiler. --Diaspomod (Diskussion) 13:35, 27. Mai 2020 (CEST)

Ok eine virtuelle Maschine ist auch kein Betriebssystem. Aber Betriebssystem ist irreführender als Plattform. Deswegen würde ich dafür plädieren das auch zu ändern. --Blauer Kakadus (Diskussion) 21:59, 21.06.2020 (CEST) (ohne (gültigen) Zeitstempel signierter Beitrag von Blauer Kakadus (Diskussion | Beiträge) 22:00, 21. Jun. 2020 (CEST))

im Artikel von Java steht unter Betriebssystem "plattformunabhängig" und bei C# steht "alle, für die eine CLI-Implementierung existiert (z. B. Microsofts .NET Framework oder Xamarins Mono)" Man sollte diese Kategorie überall konsistent halten. Man könnte schreiben "alle, für die es eine Implementierung der JVM, JavaScript oder LLVM gibt"

Ok dann sollten die Einträge, JVM, JavaScript und LLVM aus dem Betriebsystem Eintrag raus. Das verwirrt nur. --Blauer Kakadus (ohne (gültigen) Zeitstempel signierter Beitrag von Blauer Kakadus (Diskussion | Beiträge) 10:15, 24. Jun. 2020 (CEST))

die Betriebsysteme müssen eine Implementierung der JVM, von JavaScript oder LLVM anbieten. Bitte schließe deine Beiträge mit einer Signatur ab. --Diaspomod (Diskussion) 03:50, 25. Jun. 2020 (CEST)