Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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.
hmm, da gibt es doch sicher bessere Punkte,
Unveränderlichkeit ist zum Glück kein exklusives Feature von Scala/ Funktionaler Programmmierung
und nur eine Frage der richtigen APIs,
dass das nicht uneingeschränkt gut ist und immer noch einen Kopf verlangt zeigt das bekannte Beispiel
'Schleife mit String + String' vs. StringBuilder,
wobei Listen sicher bisschen intelligenter sind als alles zu kopieren
meine Güte, das wird ja zur ganzen Abkehr von Java/ C++,
soviel habe ich in den diversen Scala-Forum-Threads/ Internet-Seiten bisher glaube ich noch nicht gehört,
das muss erstmal sacken/ sich wiederholen bis das anzugreifen ist
@inv_zim: Kommt drauf an. Wenn du wirklich firm in Scala bist, und die Aufgaben auch einigermaßen in Java lösbar wären (also z.B. wenig DLL-Anbindungen und anderer Systemkrams), sähe ich keinen Grund, auf Scala zu verzichten.
hmm, da gibt es doch sicher bessere Punkte,
Unveränderlichkeit ist zum Glück kein exklusives Feature von Scala/ Funktionaler Programmmierung
und nur eine Frage der richtigen APIs,
dass das nicht uneingeschränkt gut ist und immer noch einen Kopf verlangt zeigt das bekannte Beispiel
'Schleife mit String + String' vs. StringBuilder,
wobei Listen sicher bisschen intelligenter sind als alles zu kopieren
Ja, aber die veränderlichen Java-Collections kannst du jedenfalls für sowas schonmal in die Tonne kloppen, und viel hat sich in Java in dieser Richtung bisher nicht bewegt...
meine Güte, das wird ja zur ganzen Abkehr von Java/ C++,
soviel habe ich in den diversen Scala-Forum-Threads/ Internet-Seiten bisher glaube ich noch nicht gehört,
das muss erstmal sacken/ sich wiederholen bis das anzugreifen ist
Ja, aber die veränderlichen Java-Collections kannst du jedenfalls für sowas schonmal in die Tonne kloppen, und viel hat sich in Java in dieser Richtung bisher nicht bewegt...
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
...
und wieso sollte gerade funktionale vs imperative Programmierung bei MultiCore relevant sein?
Es ist nicht notwendigerweise Aufgabe der Programmiersprache an sich... vielleicht eher des Compilers "Automatische Parallelisierung" ist IMHO quasi der heilige Gral des Compilerbaus. Aber ich denke, dass es gerade an dieser Stelle wichtig ist, zu unterscheiden zwischen Multicore und Manycore.
Mutlicore haben wir schon und nutzen es in Java locker-flockig aus dem Handgelenk, teilweise ohne es zu merken, und SEHR effizient. Ich meine nicht nur die ~10 Threads, die ohnehin schon am laufen sind, wenn man ein Swing-Fenster aufmacht, sondern auch solche Dinge wie Executors (ThreadPoolExecutor & Co) mit denen man schön und einfach mehrere Tasks verwalten und in mehreren Threads auf mehreren Kernen ausführen kann. Auf einem Quad- oder Hexacore kann man damit bei bestimmten Aufgaben schon einiges rausholen. Die Anzahl der Kerne wird sich in Zukunft alle 18 Monate verdoppeln - es wird als immer wichtiger, solche Mechanismen in eine für den "normalsterblichen Programmierer" anwendbaren Form zur Verfügung zu haben. Das Fork-Join-Framework von Java 7 ist der nächste Schritt. Aber die Erstellung und Verteilung dieser Tasks ist sowohl dort als auch bei den schon angesprochenen Executors immernoch Aufgabe des Programmierers - auch wenn es Java einem da mit Anonymen Klassen, Collections schon SEHR leicht macht.
Und das könnte man vielleicht als einen der wichtigsten Punkte bezeichnen, der Multicore und Manycore unterscheidet: Bei Multicore und Java-Threads geht es praktisch immer (oder zumindest auch) um Task-Parallelität. WAS genau die Threads machen, ist ziemlich egal, sie arbeiten unabhängig voneinander parallel nebeneinander her (im Idealfall - natürlich gibt es bei manchen Tasks Synchronisationspunkte).
Manycore ist also eine andere Kategorie. Das sind quasi die GPUs, die jetzt immer mehr Anwendungen finden. Man hat dort nicht 4 oder 8 Kerne, sondern 1000 oder 2000, und wenn man will hat man dort (virtuell) mehrere Millionen Threads. Das "Problem" ist: Diese Threads machen alle das gleiche! Genauer gesagt geht es dort nicht um Task-Parallele Programmierung, sondern im Daten-Parallele. Jeder der vielen hunderttausend Threads macht das gleiche, aber auf unterschiedlichen Bereichen eines großen Datenblocks.
Die beiden (Multi- und Manycore) wachsen wohl zusammen oder nähern sich teilweise an - auf jeden Fall werden sie schon kombiniert (das ist das, was bei OpenCL immer als "Heterogenität" bezeichnet wird).
Wenn du wirklich firm in Scala bist, und die Aufgaben auch einigermaßen in Java lösbar wären (also z.B. wenig DLL-Anbindungen und anderer Systemkrams), sähe ich keinen Grund, auf Scala zu verzichten.
Selbst wenn ich firm wäre, streng nach Truck-Faktor gesehen: Wenn ich aus irgendwelchen Gründen ausfalle, geht die Suche nach einem Scala Entwickler los. Klar ist "keine Verbreitung" kein Argument um zu begründen, warum eine Sprache keine Verbreitung erfährt, aber "kein Grund, auf Scala zu verzichten" ist eben auch kein Grund, Scala einzusetzen
Mit dieser Einstellung wird sich aber niemals eine neue Sprache durchsetzen. Zunächst denkt jeder "wieso soll ich das lernen, ich kann doch schon XXX, damit kann ich auch schon alles machen". Dann heißt es "es wird doch nirgends wirklich eingesetzt". Wer findet den Paradox?
Außerdem kann ich das "wenn ich mal ausfalle, muss nach einem neuen Scala-Entwickler gesucht werden" nicht nachvollziehen. Scala-Entwickler gibt's mit Sicherheit nicht so viele, wie Java-Entwickler. Es gibt aber auch nicht so viele Firmen, die in Scala entwickeln. Vielmehr sollte sich hier der Vorteil für dich ergeben: solltest du einmal die Firma wechseln, solltest du keine großen Probleme haben, einen neuen Scala-Job zu bekommen, da du eben verhältnismäßig wenig Konkurrenz erwarten solltest.
Es ist und bleibt natürlich ein Risiko - für dich und für die Firma. Aber was wäre, wenn sich damals jeder gesagt hätte: "Wie jetzt? Wozu brauche ich denn Objekte? Ich komme mit C doch bestens klar?"
@Marco13
Laut meinen eigenen Erfahrungen mit SWING sieht die von dir beschriebene Multithreading Fähigkeit von SWING nicht so gut aus. Das die gesamte GUI einfriert ist mir nicht fremd. Auch der Autor in dem von mir oben beschrieben Buch sieht das änhlich. Meine Erfahrungen schüren aus einem Projekt welches je nach Auslastung 10 bis 100 Threads erzeugte. Wer genaueres wissen möchte (welches Projekt) bitte via PM.
Mir wäre auch am liebsten der Compiler würde alles für mich erledigen aber irgendwie hat SUN das Thema verschlafen und Oracle... naja. Ich weis auch nicht ob Scala das all-heil mittel ist. Ich weis aber das Oracles Roadmap nicht so rosig aussieht und Scala locker 3-5 Jahre Vorsprung hat (Scala insgesamt gesehen).
Es ist und bleibt natürlich ein Risiko - für dich und für die Firma. Aber was wäre, wenn sich damals jeder gesagt hätte: "Wie jetzt? Wozu brauche ich denn Objekte? Ich komme mit C doch bestens klar?"
Da gebe ich dir Recht. Wie auch oben schon geschrieben, ich kann mir vorstellen dass der Umbruch auf irgendeine Art und Weise in der nächsten Zeit kommt. Aber Firmen gehen so ungerne Risiken ein, gerade bei solchen Geschichten. Und ich auch nicht. Wenn ich dort anfange, um wirklich die Richtung für die Programmierung vorzugeben, dann hätte ich bei Scala ganz definitiv Schiss. Ich hatte zu diesem Thema mal einen Thread aufgemacht in dem ich mich zu C# erkundigt hatte, und dort wurde von einigen gesagt, wenn sie als Arbeitgeber rauskriegen würden, dass ich auf ihre Kosten etwas neues probiere, würde ich rausfliegen. Das ist berechtigt.
Und ja, wenn man Scala kann hat man bei einem Jobwechsel gute Karten. Aber ich bin mir auch nicht sicher, dass ich in einer recht Infrastrukturschwachen Gegend die ländlich gelegen ist großartig Scala Jobs finde. Dann schaue ich mir lieber noch C# und C++ an um meine Chancen auf dem Arbeitsmarkt zu erhöhen. Ich muss nicht dafür sorgen, dass eine neue Sprache verbreitet wird, ich muss dafür sorgen dass meine Miete gezahlt wird, das Abbuchen per EC Karte nicht mit einem peinlichen "Vorgang nicht durchführbar" endet und dass das System bei meinem Arbeitgeber zuverlässig und gut funktioniert.
Neue Sprachen setzen sich durch, wenn sie einen konkreten Vorteil haben, oder es eine Killeranwendung gibt.
Natuerlich kann man mit dem Geldgeber oder dem Chef argumentieren. "Lass uns doch Scala nehmen, denn dann haben wir [hier den Vorteil einsetzen]."
Bei Turbo Pascal war das eine (fuer damalige Zeiten) ueberragende IDE.
Bei Java war das urspruenglich sicherlich die Plattformunabhaengigkeit durch den Einsatz einer VM. Dazu noch ein relativ vernuenftiger Kompromis zwischen OOP und Performance (primitive Datentypen).
Bei Ruby war war das Ruby on Rails. Ein aus der Praxis stammendes Framework, um Webanwendungen voellig anders zu entwickeln, als mit JEE.
Bei Erlang ist das die super Skalierbarkeit durch FP, kombiniert mit praxistauglichen API und Tools.
----
Was genau bietet mir Scala, so dass sich der Aufwand, dort einzuarbeiten und Scala evtl. als Technologie im naechsten Projekt zu nutzen, lohnt?
Ich sehe einfach keinen richtigen Vorteil in Scala.
Für große Projekte geht es nunmal um Dinge wie:
- Wartbarkeit
- Codequalität
- Codeverständniss
Die Fluktuation in großen Projekten ist nunmal recht hoch, vor allem beim Übergang in die Wartung. Wenn jeder Entwickler Wochen benötigt um den Code zu verstehen ist das Budget schnell am Ende.
Im letzten Projekt (im mehrstelligen Milionenbereich) lag der Fokus auch ganz klar auf Einfachheit. Die Fluktuation dort war enorm (ca. 20 Zu- und Abgänge alle 2 Monate). Neue Entwickler konnten innerhalb von 1-2 Tagen schon produktiv arbeiten weil der Code ganz klar verständlich war. Wenn ich da jetzt Skala einsetze und jeder Entwickler jedes Problem anders löst sitzen wir ganz schön in der Patsche.
Und das ganze nur weil Skala manche Dinge besser kann als Java?
Neue Sprachen finde ich an sich schon gut, aber nur wenn diese Sprachen auch ein neues Einsatzgebiet haben. Entweder sehr spezielle Sprachen (quasi-DSLs) oder auf ein bestimmtes Szenario zugeschnitten.
Scala ist für mich irgendwie "Dieselben Probleme in derselben Umgebung mit denselben Mitteln aber anderer Syntax lösen" - ich sehe da keinen großen Vorteil.
-Weniger Quell Code
-dadurch weniger Fehler
-Alte Java Projekte weiter zu nutzen.
-Wahlweise .net oder Java VM zu nutzen
-Gute Performance https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
-Wahlweise OOP oder FP zu Entwicklen.
-"Gutes" von Erlang Thema Aktoren und Nebenläufigkeit
-IDEs müssen nicht neu "erfunden" werden. bsp. Ecplise
usw. usw.
@KSG9|sebastian
Bei dem von dir genanten Beispiel würde ich auch so verfahren wegen der Fluktuation und dem gegebenen das es einfach mehr Java Entwickler gibt. Es gibt aber auch Projekte (beispiele oben) wo das ganze anders aussieht und man vorteile aus den vorteilen nutzen kann. Ist halt Situations bedingt.
alten Code und alte IDEs weiternutzen solltest du nicht aufzählen als Vorteil gegenüber KEIN Wechsel
(warum ein neues Auto kaufen? nun zum einen bekommst du noch 500 Euro Schrott-Geld für das alte, ..)
der Rest klingt nur nach interner Syntax, schlicht besseren Code,
ein fulminantes Ergebnis, gewiss, wenn das wirklich erreicht wird
------
nebenbei:
Actor ist nur vorgegebener Code, im Grunde ein Thread oder hat der irgendwas geheimes eingebautes?
große Library-Mengen sind zwar schön und gut, würde ich aber nicht als Kern-Kompotenz einer Sprache ansehen,
Java ist auch ohne Hibernate, Web-Frameworks usw. gut,
je näher eine Library in die Sprache integriert ist, desto mehr Vorteile bietet das in gewisser Hinsicht, etwa dass alle dasselbe verwenden,
aber ich sehe das auch etwas kritisch, man verliert die Kontrolle über die Funktionalität, kann sie vielleicht nicht austauschen, auf Fehler reagieren
[..]
When actors call thread-blocking operations, such as receive (or even wait), the worker thread that is executing the current actor (self) is blocked.
[..]
Thread-blocking operations can be avoided by using react to wait for new messages (the event-based pendant of receive). However, there is a (usually small) price to pay: react never returns.
[..]
Note that using react inside a while loop does not work! However, since loops are common there is special library support for it in form of a loop function. It can be used like this:
'special library support', das ist ein rotes Tuch für mich,
gewisse Grundfunktionalität muss eine Programmiersprache bieten, primitive Datentypen, Sockets, IO, Threads, GUI-Support, sowas kann man quasi nicht selber bauen, native Funktionen,
aber alles weitere sollte sich doch möglichst in verständlichen Code selber ergeben,
ich finde es toll dass in Java die Implementierung von Listen & Co. bis auf das letzte Array nachvollziehbar sind und in Uni-Vorlesungen nachgebaut werden,
System.in und System.out oder Socket-Input/ Output sind wohlüberlegte austauschbare Stream-Schnittstellen, auch die Streams kann man weitgehend in der Inplementierung prüfen
wenn dagegen Code nur eine Anderanderreihung von vorgegebenen Schlüsselwörtern wie Actor oder react ist, in 'vorgegebenen loop-Konstrukten',
was ist das dann noch für eine Programmiersprache, was macht man bei nötiger Abweichung wie gleichzeitiger Reaktion auf zwei Input-Quellen oder wer weiß was für ein Beispiel?
in dem Bereich mag im Gegensatz zur Syntax Java gar komplizierter als Scala sein, aber gibt dem Programmierer Kontrolle,
im Speichermanagement wurde das aufgegeben, ohne Zeiger weniger Einfluss,
aber ob das in anderen Bereichen auch ein Fortschritt ist?
In Erlang ist das ein Stueckel (funktional programmierter) Code, der keinen Zustand hat. Man kann nur eine reinkommende Nachricht verarbeiten und an andere Prozesse (so heissen die dort imho) Nachrichten schicken.
Ein Erlang Prozess nutzt dabei keinen OS-Thread, sondern hat eine eigne Implementierung dafuer. Deshalb kann man ohne Probleme Tausende, Hundertausende oder Millionen von Prozessen erzeugen. Die verteilen sich dann nicht nur auf die Kerne in der CPU, sondern wahlweise auch ueber mehrere Rechner im Netzwerk. Ohne das man irgendwas am Code machen muss. Dafuer darf man keine Zustaende speichern ;-)
Wie das bei Scala genau funktioniert, weiss ich nicht. Irgendwer?
Scalas eingebaute Aktoren orientieren sich stark an Erlangs, sind aber als Bibliothek realisiert, also völlig transparent (so man denn in die Tiefen des Codes absteigen will). Alternativ gibt es das Akka-Framework. Mittelfristig wird es da sicher eine gemeinsame Lösung geben (Scala + Akka wird ja jetzt schon als "TypeSafe-Stack" von Odersky und Bonér bezeichnet).
Aktor-Programmierung hat ein ganz anderes "Feeling" als threadbasierte Programmierung. Zur internen Realisieung von Aktoren kann man Threads verwenden, aber auch ein Eventmodell (was deutlich mehr Aktoren erlaubt, als man mit Threads haben könnte).
Scalas eingebaute Aktoren orientieren sich stark an Erlangs, sind aber als Bibliothek realisiert, also völlig transparent (so man denn in die Tiefen des Codes absteigen will). Alternativ gibt es das Akka-Framework. Mittelfristig wird es da sicher eine gemeinsame Lösung geben (Scala + Akka wird ja jetzt schon als "TypeSafe-Stack" von Odersky und Bonér bezeichnet).
Aktor-Programmierung hat ein ganz anderes "Feeling" als threadbasierte Programmierung. Zur internen Realisieung von Aktoren kann man Threads verwenden, aber auch ein Eventmodell (was deutlich mehr Aktoren erlaubt, als man mit Threads haben könnte).
Die einzige Möglichkeit auf der JVM Parallelität durchzuführen ist es Threads auszuführen, die ja in der Sprache Java eingebaut sind. Wie ist es dann möglich, dass mehr Actors zur Ausführung kommen können als Threads? Was bedeutet in diesem Sinne threadless?
Was nehme ich denn am besten für die parallele Programmierung?
- Ursprünglichen Actors?
- Event-Actors
- Akka
- Scalaz
- weitere Möglichkeiten?
Wieso gibt es so viele Möglichkeiten und worin unterscheiden sie sich?
Wer sagt denn, dass Scala-Code weniger verständlich ist?
Ich habe Informatik studiert und mich mit der Thematik beschäftigt, welche Programmiersprachen sich langfristig auszahlen, also die wirtschaftlicheren sind. Und das Argument, man finde für dieses und jenes keine Entwickler, zieht einfach nicht. Ich kenne eine Firma, da hat man innerhalb weniger Jahre zig verschiedene Sprachen genutzt und eine Sau nach der anderen durch das Dorf getrieben.
Wartbarkart, Codequalität und Codeverständnis sind Domänen von Hochsprachen und insbesonderen von jenen mit funktionalen Ansätzen. Ich wüsste nicht, was an Scala so unverständlich sein soll. Nur weil man bestimmte verrückte Konstrukte schreiben kann, heißt das nicht, dass die auch jemand verwendet. Und in den Firmen kommen dann viel verrücktere Sachen zum Einsatz, wie z. B. PL/SQL. Ich finde die Sprache gruselig, weil ich nicht einsehe, warum man mir für eine simple Funktion so viele Hürden in den Weg räumt, dass ich diese zehn mal durch den Compiler jagen darf.
Aus meiner Erfahrung als Softwareentwickler weiß ich, was häufiger Fehlerursachen sind: Falsche Annahmen ("Dieser Wert ist niemals null.") und Seiteneffekte (, die dann z. B. verursachen, dass ein Wert null wird, woran man nie gedacht hätte.)
Funktioniale Programmierung schickt sich an, diese Probleme zu zähmen. Und die Anwendungen der Zukunft laufen auch darauf hinaus. Früher hat man in Assembler und C geschrieben, weil man die Ressourcen sparen musste. Aber heute? Aber es gab auch andere Konzepte, z. B. beim Emacs. Bei Emacs ist nur der Kern der Anwendung in C. Das meiste Zeug ist in Lisp geschrieben, was den Emacs unglaublich stabil macht. Stabil in der Anwendung und stabil in der Entwicklung. Es wurden nie brachial neue Konzepte eingeführt, wo dann alles drunter und drüber geht. Es gibt eine Menge Quellcode, die sich seit zwanzig Jahren nicht geändert haben dürfte (das meine ich mit stabil), denn in Lisp schreibt man nicht, wie man bewerkstelligt, sondern was man bewerktstelligt. Seiteneffekte sind wenig und dann gut dokumentiert, z. B. "Schreiben in Modeline".
Funkioniale Programmierung ist aber auch gerade für den Kern einer Anwendung interessant. An den Kern bestehen besonders hohe Anforderungen an Stabilität, Korrektheit und Robustheit. Funktioniale Programmierung verringert die Seiteneffekte (bekannt!) und man kann Teile des Programmes verifizieren, wenn es denn sein muss.
Die Fluktuation in großen Projekten ist nunmal recht hoch, vor allem beim Übergang in die Wartung. Wenn jeder Entwickler Wochen benötigt um den Code zu verstehen ist das Budget schnell am Ende.
Imperativer Quellcode ist selten guter Quellcode. Wenn ich so lese, was Kollegen zusammenschreiben. Katastrophe! Jeder hat seinen eigenen Stil. Jeder kann seinen eigenen Stil haben, wenn dann sein Code bombenfest ist. Das erreicht man eher mit funktionaler Programmierung und Scala als mit imperativer Programmierung in Java.
Und das ganze nur weil Skala manche Dinge besser kann als Java?
Wieso manche Dinge? Viele Dinge! Scala ist eine funktioniale Programmiersprache mit einem ausgefeiltem Typsystem, das die gerade die typischen Gemeinheiten der imperativen Welt verhindert.
Scala ist für mich irgendwie "Dieselben Probleme in derselben Umgebung mit denselben Mitteln aber anderer Syntax lösen" - ich sehe da keinen großen Vorteil.
Falsch. Es sind ganz andere Mittel. Bei Java war anfangs "Einfachheit" Trumpf. Dann hat sich aber herausgestellt, dass es schlecht ist, wenn die Leute bei jedem Iterator einer Liste casten und zwangsläufig Fehler machen. Mit Java 1.5 hat man Generics eingeführt, sodass Java auch für größere Projekte tauglich wurde. Natürlich kenne ich auch Leute, die schon das Generics-Konzept nicht intellektuell greifen können und sich das alte, "einfache" Java zurücksehnen. Java ist eigentlich eine Schrottsprache, weder Fisch noch Fleisch. Interessant an Java sind nur JVM, JDK und die zahlreichen Bibliotheken (z. B. Apache).
Der Artikel im Linux-Magazin zeigt eigentlich eine positive Entwicklung auf. Weniger akademisch daherkommende Sprachen wie Python, Ruby, Groovy und F# machen die ängstlichen Programmierer mit funktionialer Programmierung vertraut. Die nennen sich nicht funktionaler, aber Python hat schon sehr viele Konzepte der funktionialen Programmierung übernommen. Mit den Dekoratoren wurde sogar schon eine Art Makro eingeführt, wie man sie aus Lisp kennt.
Die einzige Möglichkeit auf der JVM Parallelität durchzuführen ist es Threads auszuführen, die ja in der Sprache Java eingebaut sind. Wie ist es dann möglich, dass mehr Actors zur Ausführung kommen können als Threads? Was bedeutet in diesem Sinne threadless?
Was nehme ich denn am besten für die parallele Programmierung?
- Ursprünglichen Actors?
- Event-Actors
- Akka
- Scalaz
- weitere Möglichkeiten?
Wieso gibt es so viele Möglichkeiten und worin unterscheiden sie sich?
Akka unterscheidet sich nicht grundsätzlich von den eingebauten Aktoren, aber in vielen Details (z.B. der Ablaufsteuerung und ob Nachrichten getypt sind) , und gilt als robuster.
Es gibt ab Scala 2.9 auch parallele Collections, die auf Javas Fork-Join Framework aufsetzen.
Scalaz ist eine Bibliothek für höhere, an Haskell angelehnte Abstraktionen. Parallele Programmierung ist dort zumindest nicht das Hauptanliegen.
Was "besser" ist, hängt sehr stark vom Problem ab: Wieviel muss jeder Teilprozess vom Gesamtproblem sehen, wie verhält sich Rechenaufwand zu Kommunikationsaufwand, wer muss mit wem kommunizieren u.s.w.
Ziel waren Messungen von Benchmark,Code größe usw. obwohl Scala auf genau der selben "blöden" VM läuft wie Java schneidet es besser ab. Ein Blick würde sicherlich nicht schaden
Java ist eigentlich eine Schrottsprache, weder Fisch noch Fleisch. Interessant an Java sind nur JVM, JDK und die zahlreichen Bibliotheken (z. B. Apache).
diese Argumentation ist ziemlich einseitig, funktionale Sprachen gab es schon vor Java,
aber haben sich nun über Jahrzehnte offensichtlich als praxisuntauglich erwiesen,
Scala kann genauso wie Java imperativ schreiben, ist Scala auch Schrott?
offensichtlich ist der imperative Anteil doch nicht so schlecht, doch erforderlich,
allenfalls kann man einzelne Inseln/ Methoden funktionial schreiben aber ein Hauptprogramm wird immer grundsätzlich imperativ geprägt bleiben,
was ist eigentlich an dem imperativen Java-Schrotthaufen Apache interessant?
dass zufällig auf der ganzen Welt kein funktionaler Webserver existiert?
Gegenfrage... warum ist OOP "so schlecht" das Twitter zu Scala (und funktional) gewechselt ist ?
Wie kommt es das im Google Test Scala besser als Java abschneidet (performance) ?
Herr Odersky und sein Team scheinen die Java VM ganz gut zu kennen.
Das Funktionale Entwicklung wie seinerzeit wie OOP nicht für einen Hype sorgen wird ist doch klar. Ich kann nur nochmals empfehlen sich mit dem Thema mehr zu beschäftigen und sich mal auf das ganze einzulassen und nicht sofort Reflex artig zu reagieren. Es gibt im Netz eine menge Quellcode welcher für eingefleischte Java Entwickler abstossend wirkt. Wie schon mal geschrieben einfach mal 40 Euro investieren :rtfm:
es gibt 200 Programmiersprachen auf dem Markt und wer weiß wie viele Wechsel pro Jahr, wie soll man daraus was ablesen?
oder wäre es nicht viel aussagekräftiger dass auf jede Scala-Firma (noch) 99 Java-Firmen kommen?
Scala dürfte mehr eine API wie die diversen Web-Frameworks sein, jede Nische passt für irgendjemanden haargenau
Ich habe Informatik studiert und mich mit der Thematik beschäftigt, welche Programmiersprachen sich langfristig auszahlen, also die wirtschaftlicheren sind. Und das Argument, man finde für dieses und jenes keine Entwickler, zieht einfach nicht.
Warum gibts dann diese Konstrukte, wenn man sie nicht verwendet (verwenden sollte)? Auch ist es eine Tatsache, das garantiert einer ausm Team dann eben doch genau das verwenden wird.
Aus meiner Erfahrung als Softwareentwickler weiß ich, was häufiger Fehlerursachen sind: Falsche Annahmen ("Dieser Wert ist niemals null.") und Seiteneffekte (, die dann z. B. verursachen, dass ein Wert null wird, woran man nie gedacht hätte.)
Mit guten Tests sind das die besten Fehler. Da bekommste nen Stacktrace und in 5min haste die Stelle gefunden, wo es knallt. Die wirklichen "Fehler" sind sich aendernde Anforderungen. Um die schnell einbauen zu koennen, braucht man vor allem eine hohe Codequalitaet, einfachen und lesbaren Code und eine halbwegs aktuelle Dokumentation. Das hat ueberhaupt nichts mit der Sprache zu tun.
Genau, Performance ist natuerlich immer noch wichtig, aber nicht mehr so wichtig wie frueher. Es ist einfach wirtschaftlicher, wenn ich eine langsamere, dafuer besser wartbare Anwendung hab, als eine superschnelle, bei der Aenderungen viel laenger brauchen, bis sie umgesetzt sind.
Dein Emacs Beispiel ist schoen, imho aber einfach auf guten Code zurueckzufuehren. Und das hat was mit Disziplin und Erfahrung zu tun, weniger was mit der Sprache ansich.
Imperativer Quellcode ist selten guter Quellcode. Wenn ich so lese, was Kollegen zusammenschreiben. Katastrophe! Jeder hat seinen eigenen Stil. Jeder kann seinen eigenen Stil haben, wenn dann sein Code bombenfest ist. Das erreicht man eher mit funktionaler Programmierung und Scala als mit imperativer Programmierung in Java.
Wieso manche Dinge? Viele Dinge! Scala ist eine funktioniale Programmiersprache mit einem ausgefeiltem Typsystem, das die gerade die typischen Gemeinheiten der imperativen Welt verhindert.
Der Punkt ist nun aber, du wirst "intellektuell beschraenkte" Menschen in jedem Softwareprojekt finden. Klar, du kannst als Teamleiter ihre Sorgen einfach abtun und ihnen sagen, dass sie zu dumm sind.
Genau diese Einstellung, "Ach ihr kleinen Popelprogrammierer, lasst mich doch in Ruhe, ihr schreibt einfach euren einfaeltigen Fachcode mit meinem tollen und schnellen (Scala-) Framework", zeigte keine besonders hohe emotionale Intelligenz. Und die ist in einem Team viel wichtiger, als Superspezialexpertenwissen.
Twitter und Scala: Imho haben die einfach nur die Messagequeue in Scala neu geschrieben. Der Rest ist weiterhin Ruby on Rails. Das macht auch Sinn, denn die Messagequeue muss sehr viele Requests verarbeiten (also richtig viele). Dort lohnt sich der Einsatz von FP.
Google Test: Auch interessant ist die unterirdische Compilezeit. Verglichen mit Java dauert das laut dem GoogleTest, ca. 4x laenger. Unser aktuelles Projekte wuerde also statt 8 Minuten, 32 Minuten compilieren...
Google Test: Auch interessant ist die unterirdische Compilezeit. Verglichen mit Java dauert das laut dem GoogleTest, ca. 4x laenger. Unser aktuelles Projekte wuerde also statt 8 Minuten, 32 Minuten compilieren...
In einer produktiven Umgebung und gerade bei CI wird man kaum scalac sondern fsc verwenden. Und mit fsc ist der Unterschied schon gar nicht mehr so groß.
Steht aber ja auch im Text.
Edit:
Aber auch mit scalac würde ein großes Projekt nicht gleich 4x länger zum kompilieren dauern.
Bei den kleinen Google Codeschnippsel fällt das starten von scalac eben mehr ins Gewicht als der Kompiliervorgang.
@SlaterB
Natürlich ist das kein Argument wo wer was nutzt aber dein Argument mit dem Apache ist auch nicht viel besser. Von wegen Hähne Ei Problem. "Die Nische" wie du Scala nennst kann OOP und FP UND deine alten Java Klassen ansprechen. Was erwartest du von einer Modernen Sprache noch alles ? Du kannst den FP kram auch völlig ausser acht lassen und "nur" die besseren OOP Eigenschaften von Scala nutzen.
@schalentier
Zumal auch nur veränderter Quelltext compiliert wird.
Ich nutze Eclipse mit der Standard Installation von Scala welcher den Fast Scala Compiler nutzt. Also wenn der langsamer sein soll wie der javac dann weis ich auch nicht mehr. Soviel ich weis läuft der fsc ständig im Hintergrund und muss nicht bei jeden Compiliert Vorgang neu gestartet werden.
Wieso ist den keinen bei der Google Ausarbeitung aufgefallen das die Java VM richtig gut gegen C++ aussieht anstatt negatives zu Scala zu suchen? Klar ist C++ immer noch schneller aber der Optimierungs Aufwand scheint nicht ohne zu sein. Und das Scala erstaunlicherweise besser wie Java da steht (performance) scheint auch irrelevant zu sein?
Benchmark Time [sec] Factor
C++ Opt 23 1.0x
C++ Dbg 197 8.6x
Java 64-bit 134 5.8x
Java 32-bit 290 12.6x
Java 32-bit GC* 106 4.6x
Java 32-bit SPECGC 89 3.7x
Scala 82 3.6x
Scala low-level* 67 2.9x
Scala low-level GC* 58 2.5x
Go 6g 161 7.0x
Go Pro* 126 5.5x
Klar ist C++ immer noch schneller aber der Optimierungs Aufwand scheint nicht ohne zu sein. Und das Scala erstaunlicherweise besser wie Java da steht (performance) scheint auch irrelevant zu sein?
Und wie gut hat Assembler abgeschnitten? Wie du schon selbst mitbekommen hast - C und C++ (?) ist gerade für die Performanz bekannt, aber der Programmieraufwand ist umso höher. Bei den heutigen Rechnern muss man tatsächlich abschätzen, wo die Performanz wirklich wichtig ist (Low Level), und wo sie ohne Weiteres vernachlässigt werden kann.
Allerdings klingt der Scala-Compiler wirklich nicht schlecht, vor allem wenn man den alten Java-Code noch nutzen kann. Bei Gelegenheit mal reinschauen.. ^^
Und wie gut hat Assembler abgeschnitten? Wie du schon selbst mitbekommen hast - C und C++ (?) ist gerade für die Performanz bekannt, aber der Programmieraufwand ist umso höher. Bei den heutigen Rechnern muss man tatsächlich abschätzen, wo die Performanz wirklich wichtig ist (Low Level), und wo sie ohne Weiteres vernachlässigt werden kann.
Allerdings klingt der Scala-Compiler wirklich nicht schlecht, vor allem wenn man den alten Java-Code noch nutzen kann. Bei Gelegenheit mal reinschauen.. ^^
Klar ist der Scala Code auf den ersten Blick nicht verständlich. Aber den nutzt ja auch niemand. In Scaladoc steht bei List noch folgendes:
Code:
def ++ [B] (that: GenTraversableOnce[B]): List[B]
Bis auf die Typen unterscheidet sich dieses Konstrukt nicht von dem aus Ruby. Gut, man sollte dabei noch verstanden haben, dass B ein parametrisierter Typ ist und wie diese funktionieren. Aber das wird man heute von einem Entwickler ja wohl noch erwarten dürfen.
Man muss nicht verstanden haben was der Sinn des impliziten Parameters ist und auch nicht woher er kommt, genauso wenig wie man Varianzen verstanden haben muss, die diesen Code erst lauffähig machen. Man kann den Code nutzen, der einem von Scaladoc angezeigt wird. Wirklich gebraucht hab ich das voll Wissen über die Konzeption der Scala-Bibliotheken bisher nur als ich eben genau diese Bibliotheken durch eigenen Code erweitert habe.
Als Anwender der Bibliotheken interessiert mich das aber alles nicht.
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.
Wenn man in die Sourcen blickt, dann kann man von niemandem mehr davor geschützt werden, dass man mit der dunklen Seite der Macht konfrontiert wird, das ist richtig. Richtig ist aber auch, dass sich Scala auf einer höheren Abstraktionsebene wie Java oder andere imperative Programmiersprachen befindet, deren Sinn es ist, dass man sich eben gerade nicht mit den Implementierungen auseinanderzusetzen braucht.
Durch die höhere Abstraktion wird Redundanz vermieden, was weniger Fehler verursacht. Ein Beispiel:
Code:
// in Scala
intList map (elem => elem*2)
intList map (elem => elem.toString)
// in Java
intList.mapToDuplicate()
intList.mapToString()
In Scala wird ein und dieselbe Methode wird unterschiedliche Aufgaben genutzt. Wenn ich also sicherstellen kann, dass diese Methode beim ersten Mal das Richtige macht, dann weiß ich auch, dass sie es für alle weitere Aufrufe mit unterschiedlicher Aufgabe tut. In Java dagegen benötigt man mehrere Implementierungen für ähnliche Aufgaben, was einen dazu zwingt jede Implementierung auch einzeln zu testen.
Scala Collections sind ein Spezialfall weil in ihnen besonders viele Konzepte zusammenfließen. "Normaler" Code dagegen nutzt diese Konzepte jedoch meist nicht. Wenn man sich dort mit dem Implementierungen auseinandersetzt wird man auch deutlich weniger Überraschungen erleben und dadurch, dass in Scala viel mehr Code wiederverwendet wird als in Java folgt daraus, dass es einfacher ist die Implementierungen zu verstehen.
Die Konzepte in Scala sind ja noch nicht einmal kompliziert, sie funktionieren gleich wie die von Java.
Warum gibts dann diese Konstrukte, wenn man sie nicht verwendet (verwenden sollte)? Auch ist es eine Tatsache, das garantiert einer ausm Team dann eben doch genau das verwenden wird.
Mit guten Tests sind das die besten Fehler. Da bekommste nen Stacktrace und in 5min haste die Stelle gefunden, wo es knallt. Die wirklichen "Fehler" sind sich aendernde Anforderungen. Um die schnell einbauen zu koennen, braucht man vor allem eine hohe Codequalitaet, einfachen und lesbaren Code und eine halbwegs aktuelle Dokumentation. Das hat ueberhaupt nichts mit der Sprache zu tun.
Dein Emacs Beispiel ist schoen, imho aber einfach auf guten Code zurueckzufuehren. Und das hat was mit Disziplin und Erfahrung zu tun, weniger was mit der Sprache ansich.
Wie sieht es aus, wenn Code gewartet werden soll, der vllt. schon 10 Jahre alt ist? Bei dem zu wenig Kommentare vorhanden sind und der einfach schlecht geschrieben ist?
Es kann doch wohl nicht schaden, dass Leute, die so einen Code schreiben, von der Sprache da ein wenig an der Hand gehalten werden.
Perfekten Code in der Industrie kann niemand garantieren. Das geht nur bei mir daheim wo ich kein Zeit- und Budgetdruck habe. In der Industrie soll in möglichst kurzer Zeit möglichst viel erreicht werden - die Qualität bleibt doch da bei einem Großteil der Firmen (Behauptung von mir) vollkommen auf der Strecke. Wie soll man auch einem Manager klar machen, dass es möglich sein soll, dass Code in 10 Jahren noch gewartet werden kann, wenn jener Manager genau weiß, dass er in 5 Jahren nicht mehr in der Firma arbeitet. Guter Code interessiert den also herzlich wenig.
Es gibt viel weniger als in imperativen Sprachen. Alleine schon die Anzahl der Möglichkeiten, die man hat wenn man Schleifen benutzt (verschiedene Schleifentypen, Abbruchbedingungen in Schleifen). Wenn man auf Schleifen verzichtet fällt das alles weg. Dem gegenüber stehen z.B. map+filter vs. fold, wobei ich das noch nicht einmal als unterschiedliche Stile betrachten würde. Die Methoden sind nicht schwer zu verstehen, man spart aber viel Zeit beim überlegen welche Schleife man jetzt wie nutzen möchte.
"Die Nische" wie du Scala nennst kann OOP und FP UND deine alten Java Klassen ansprechen. Was erwartest du von einer Modernen Sprache noch alles ? Du kannst den FP kram auch völlig ausser acht lassen und "nur" die besseren OOP Eigenschaften von Scala nutzen.
die ideale Zukunft kann man schwerlich im Voraus sehen,
es wäre zumindest extrem hilfreich gewesen wenn die Java-Syntax so weit wie möglich beibehalten worden wäre,
im Idealfall alle APIs auch in Scala kompilieren würden,
man müsste nicht so programmieren, man hätte auch neue Schlüsselwörter wie var einführen können,
aber war es wirklich nötig, komplett alles auf dem Kopf zu stehen, von einfachster 'Datentyp Variablenname'-Reihenfolge an?
sanfte Erweiterungen wie evtl. Closures in Java xy sind schon bedeutend genug
-------
gewisse einfache Erweiterungen wie das zuletzt genannte
wären zwar eher positiv,
Funktionale-Programmierung absolut beschränkt auf einzelne Zeilen/ Methoden,
überhaupt nicht den imperativen Programmfluss störend, genau wie es Collections.sort(Comparator) schon ewig gibt, nur gesparte Syntax,
aber üblicherweise findet man doch Code-Beispiele wie
Code:
type Tagged[U] = { type Tag = U }
type @@[T, U] = T with Tagged[U]
def tag[U](l : Long) : Long @@ U = l.asInstanceOf[Long @@ U]
trait Millis
case class Foo( l: Long @@ Millis ) {
final def canEqual( x: Any ) : Boolean = x.isInstanceOf[ Foo ]
override def equals( x: Any ) : Boolean = (this eq x.asInstanceOf[ AnyRef ]) || (x match {
case f: Foo if( (f.l: Long) == (l: Long) && f.canEqual( this )) => true
case _ => false
})
}
Foo( tag[ Millis ]( 33L )) == Foo( tag[ Millis ]( 34L )) // false
Foo( tag[ Millis ]( 33L )) == Foo( tag[ Millis ]( 33L )) // true
die komplett andere Grundsyntax und verrückte Extremprogrammierer, die jedes Problem unlesbar lösen,
das schreckt sehr ab, außer vielleicht eben genau die Experten der Sprache, die sich in manchen zufälligen Runden bei Twitter & Co. (als Arbeitgeber) treffen und dann sicher faszinierende Programme zusammenbauen können,
aber was hilft das den 1 Mio. Standard-Programmiern auf der Welt?
Das sind doch bloß Spielereien. Das wird niemand produktiv einsetzen. Hier geht es in erster Linie um Forschung - was ist möglich, was nicht, was könnte man besser machen.
Ich arbeite auch viel an solchen Code-Schnippseln. Nicht weil ich vorhabe das produktiv einzusetzen, sondern weil es Spaß macht und weil ich wissen will was denn die Vorteile sind, wenn ich das einsetze. Irgendwann entsteht daraus das was für uns alle heute selbstverständlich ist.
Ich hab einmal in C Exceptions und Vererbung implementiert. Das sieht nicht schön aus, ist unhandlich aber es hat funktioniert. Irgendwann, lange vor meiner Zeit, hat jemand das Gleiche getan und als die Person gesehen hat, dass es nicht toll ist so etwas in Sprache X zu machen hat sie eine neue Sprache kreiert. Die neue Sprache hatte dann Schlüsselwörter, anhand denen der Compiler genau den Code generieren konnte, der davor mühsam von Hand implementiert werden musste. Heute weiß so gut wie niemand mehr wie die ganzen Konzepte, die wir tagtäglich nutzen, auf unterster Hardwareebene umgesetzt werden. Aber es ist eben nicht erforderlich das zu wissen.
Irgendwann wird jemand kommen und die Konzepte, die Scala vorschlägt in einer neuen Programmiersprache umsetzen. Nur mit dem Unterschied, dass die Konzepte durch Schlüsselwörter in der Sprache repräsentiert werden. Und dann wird sich niemand mehr beschweren. Man wird es nutzen eben weil es funktioniert.
Das alles ist nur für einen kleinen Kreis an Personen interessant, aber dieser kleine Kreis an Personen ist später dafür verantwortlich, dass Fortschritt erst möglich gemacht wird. Man muss sich nicht für Forschung interessieren, aber deswegen darf man sie doch nicht verdammen und sie als Referenz nehmen und behaupten, dass das immer so gemacht wird.
weiß nicht ob das ein Argument für oder gegen Scala von dir ist,
aber eine sinnvolle praktisch einsetzbare Programmiersprache ist eben die, für die in Foren nicht 'Forschung' betrieben wird,
sondern Uni-Aufgaben gestellt und einfache GUI- oder Liste-sortieren-Programme besprochen werden,
deswegen fällt die Wahl zwischen Java und Scala so leicht
edit:
natürlich könnte man nach dem Argument auch gleich nach BlueJ wechseln, jaja darf bemeckert werden
In der neuen "iX Developer Programmieren heute" gibt's einen kleinen (subjektiven) Programmiersprachen-Trend-Artikel. Dort gibt es eine kleine Tabelle, darunter die Spalte "praktisches Nutzen". Ich war gespannt, was bei Scala stehen würde und musste lachen, als ich "sehr gute Anbindung an Java/JVM" gelesen habe. Mehr nicht.
die rekursive Variante in diesem Fall kannst du in Java doch auch schreiben wenn dir Rekursion besser als Schleifen gefällt,
dieses Vergleichsbeispiel zieht nicht
wohlwissend dass die meisten solcher Minifragen genau so gestellt sind dass die Antwort 'oh ja, Scala ist besser' lauten muss..,
da war
weiß nicht ob das ein Argument für oder gegen Scala von dir ist,
aber eine sinnvolle praktisch einsetzbare Programmiersprache ist eben die, für die in Foren nicht 'Forschung' betrieben wird,
sondern Uni-Aufgaben gestellt und einfache GUI- oder Liste-sortieren-Programme besprochen werden,
deswegen fällt die Wahl zwischen Java und Scala so leicht
edit:
natürlich könnte man nach dem Argument auch gleich nach BlueJ wechseln, jaja darf bemeckert werden
Wenn du "Forschung" in Java sehen willst, schau dir mal functionaljava, lambdaJ oder <Eigenwerbung>highJ</Eigenwerbung> an. Macht das Java jetzt untauglich?
Dass es so wenig Sortierte-Listen-Beispiele für Scala gibt, liegt daran, dass es da nicht viel zu zeigen gibt: Was soll man groß zu [c]List(5,7,3,7).sorted[/c] oder [c]List("one","two","three").sortBy(_.size)[/c] sagen? Und Swing kann man genauso verwenden wie in Java (das Scala-Swing braucht noch etwas, bis es wirklich den vollen Umfang von Java-Swing abdeckt).
Wenn du "Forschung" in Java sehen willst, schau dir mal functionaljava, lambdaJ oder <Eigenwerbung>highJ</Eigenwerbung> an. Macht das Java jetzt untauglich?
wenn das ein Normalsterblicher das bei Java kaum findet, während man bei Scala für irgendwas anderes als Forschung erst suchen muss,
entscheidet einen Tauglichkeitspunkt zu einer der beiden Sprachen
Dass es so wenig Sortierte-Listen-Beispiele für Scala gibt, liegt daran, dass es da nicht viel zu zeigen gibt: Was soll ich groß zu [c]List(5,7,3,7).sorted[/c] oder [c]List("one","two","three").sortBy(_.size)[/c] sagen?
wenn es keine Uni-Studenten oder sonstige Community-Mitglieder gibt, die über Implementation gewisser einfacher Algorithmen wie BubbleSort nachdenken, sondern nur vorgegebene Strukturen, wie gesagt rotes Tuch 'special library support', verwenden,
dann mag das für die Experten schön und gut sein, ist für die Allgemeinheit aber ebenso eine bedenkliche Aussage über die Sprache..
(edit: ok, die List-Funktionen sind sicher direkt in der Sprache definiert, so wirkt aber alles dort, was wiederum ein positiver Punkt ist )
und ich weiß dabei, dass das etwas im Gegensatz zum vorherigen 'Forschung'-Punkt steht,
nur ist Forschung in Scala Syntax-Kauderwelsch, Forschung in Java der einfache Umgang mit Schleifen
...und ich weiß dabei, dass das etwas im Gegensatz zum vorherigen 'Forschung'-Punkt steht,
nur ist Forschung in Scala Syntax-Kauderwelsch, Forschung in Java der einfache Umgang mit Schleifen
Das ist wieder eine dieser typischen Halbwahrheiten. Ich mag die "enhanced for loop" und verwende sie, wo es geht, aber bei Scala hat man ein bisschen weiter geforscht, und hat dort "for comprehensions", die wesentlich weiter gehen (z.B. das Filtern von Werten oder Sammeln der Ergebnisse erlauben). Auch wenn diese von Haskell inspiriert sind, findet sich etwas sehr ähnliches bei Microsoft, nämlich LINQ (um das wir die Dot-Netter wirklich beneiden können).
Das obige diente nur als Beispiel für eine funktionale Methode mittels Rekursion welche zudem Deklarativ ist und nicht wie üblich Imperativ. Wie schnell du in Java einen StackOverflow hättest sei mal dahingestellt (Tail Rekursive Optimierung).
Ich könnte dir jetzt auch einen Higher Order Schnipsel posten aber ich bin mir sicher du würdest auch bemerken das man das ja auch in Java halt nur anders realisieren kann und ich würde dir darauf hin antworten das ich das vor langer zeit auch in Assembler hätte können
Die Scala-Actors haben an sich wirklich nicht viel mit der Sprache zu tun (Akka-Actors gibt es ja auch für Java) aber man sieht daran gut die praktischen Eigenschaften der Sprache, die es erlauben, angenehm benutzbare Abstraktionen zu bauen.
Java ist auch ohne Hibernate, Web-Frameworks usw. gut,
Ich finde es mit oder ohne Hibernate und Web-Frameworks nicht gut, aber das ist ein anderes Thema
je näher eine Library in die Sprache integriert ist, desto mehr Vorteile bietet das in gewisser Hinsicht, etwa dass alle dasselbe verwenden,
aber ich sehe das auch etwas kritisch, man verliert die Kontrolle über die Funktionalität, kann sie vielleicht nicht austauschen, auf Fehler reagieren
Warum verlierst du da irgendwie die Kontrolle? Du kannst die Library jederzeit austauschen, auch Teile davon oder einfach Java-Threads verwenden. Habe ich auch schon gemacht.
Ich habe z.B. schon mal einen eigenen Scheduler für Scala-Actors geschrieben. Den Code in der Lib fand ich sogar relativ verständlich obwohl das teilweise schon komplex wird.
'special library support', das ist ein rotes Tuch für mich,
loop und react sind doch ganz normale Funktionen, was hat das mit roten Tüchern zu tun?
gewisse Grundfunktionalität muss eine Programmiersprache bieten, primitive Datentypen, Sockets, IO, Threads, GUI-Support, sowas kann man quasi nicht selber bauen, native Funktionen,
Primitive Datentypen hätte ich lieber nicht in der Sprache; wir wollen doch objektorientiert programmieren und ich schreibe lieber bla.toInt als Integer.valueOf(bla) . Das eine ist für mich sofort verständlich, das andere schon etwas seltsam...
ich finde es toll dass in Java die Implementierung von Listen & Co. bis auf das letzte Array nachvollziehbar sind und in Uni-Vorlesungen nachgebaut werden,
Wir haben in der Übung z.B. die Scala-Listen, verschiedene Bäume, lazy Streams, funktionales Mergesort und die Parser Combinators (das ist wirklich schräges Zeug für Scala-Nichtkenner; wundert mich, dass das noch keiner gebracht hat ) nachgebaut und viel dabei gelernt...
So gings in etwa los bei uns:
Java:
abstract class Intlist
case object Nil extends Intlist
case class Cons(head : Int, tail : Intlist) extends Intlist
val listTest = Cons(1, Cons(2, Nil))
Bäume sind dann ähnlich schnell hingeschrieben und das weitere ergibt sich dann.
Die Beispiele aus dem Buch der Java-Algorithmenvorlesung fand ich da wesentlich hässlicher und kryptischer.
(Hochschul)-Bildung ist ein gutes Stichwort; wenn mehr Leute mit den funktionalen Konzepten, am besten in Kombination mit einer praktischen Sprache in Kontakt kommen sieht es in ein paar Jahren schon ein wenig besser aus, wenn es um das Verständnis von Scala-Code geht .
Immerhin haben fast alle Master-Studenten bei uns Scala schonmal benutzt, teilweise sogar in recht praktischen Projekten. Sind nicht viele, aber immerhin.
Dass es für eine Firma mit zahlreichen Java-Entwicklern, die das seit Jahren machen und es vielleicht auch schon an der Uni / FH oder in der Ausbildung gelernt haben sehr schwer und eher fragwürdig wäre, von heute auf morgen auf Scala umzusteigen ist wohl klar.
wenn dagegen Code nur eine Anderanderreihung von vorgegebenen Schlüsselwörtern wie Actor oder react ist
Die Quelle sollte eigentlich egal sein, es geht ja nur darum auf bestimmte Nachrichtentypen und -inhalte zu reagieren. Das kann man durch das case-Konstrukt ausdrücken.
Das ist eben keine Spezialsyntax für genau einen Anwendungsfall, sondern einfach die Anwendungen von ganz allgemeinen Konstrukten wie pattern matching oder Funktionen, die andere Funktionen übergeben bekommen.
in dem Bereich mag im Gegensatz zur Syntax Java gar komplizierter als Scala sein, aber gibt dem Programmierer Kontrolle, im Speichermanagement wurde das aufgegeben, ohne Zeiger weniger Einfluss,
aber ob das in anderen Bereichen auch ein Fortschritt ist?
Das ist die große Frage: warum sollte man ausgerechnet bei Java aufhören und nicht nach besseren Abstraktionen suchen, die uns die Arbeit einfacher machen?
> warum sollte man ausgerechnet bei Java aufhören
impliziert eine eindimensionale Straße, erst Pascal oder was auch immer, dann C++, dann Java und nun Scala,
so ist es aber nicht, an jeder Kreuzung gibt es 20 Abzweigungen, auch Java war nicht von Anfang an direkter einziger Nachfolger,
auch wenn die Situation damals sicher deutlicher war als jetzt bei Scala,
jedes Jahr gibt es eine neue Sprache mit neuen Fortschritten, die meisten schaffen es nicht, zum Teil einfach nur weil es noch bessere Varianten gibt oder der Sprung zu gering ist/ mit zuviel Nebenaufwand verbunden, lohnt sich nicht,
es wird sich zeigen was aus Scala wird, aber man kann nicht von einem automatischen Aufstieg ausgehen
> warum sollte man ausgerechnet bei Java aufhören
impliziert eine eindimensionale Straße, erst Pascal oder was auch immer, dann C++, dann Java und nun Scala
so ist es aber nicht, an jeder Kreuzung gibt es 20 Abzweigungen, auch Java war nicht von Anfang an direkter einziger Nachfolger,
auch wenn die Situation damals sicher deutlicher war als jetzt bei Scala,
Sicher, eindimensional war die Entwicklung noch nie, es geht eher mehr in die Breite, da die Anwendungen im Laufe der Zeit auch vielseitiger werden. C++ war nicht der Nachfolger und Java ist in vielen Bereichen auch kein wirklicher Nachfolger von C++, der es wirklich abgelöst hat.
Scala wird Java sicher nicht komplett ersetzen können und das sollte auch nicht das Ziel sein.
Das ist ja auch noch nie wirklich passiert, Fortran und Basic sind immer noch recht lebendig und sogar für Neuentwicklungen interessant
es wäre zumindest extrem hilfreich gewesen wenn die Java-Syntax so weit wie möglich beibehalten worden wäre,
Das ist doch passiert, eigentlich wurde nur geändert, was einfach schlecht oder unpassend war. Ich weiß gar nicht, wo diese dramatischen Syntaxänderungen eigentlich sein sollen...
Ist ja nicht so, dass das alles zufällig entstanden ist; die Macher haben sich schon ein paar Gedanken gemacht
Martin Odersky hat schon vor über 15 Jahren daran gearbeitet, Java zu verbessern; er ist für die Anfänge von Java Generics verantwortlich und war der Autor von javac. Die Sprache Pizza war ein Vorläufer von Scala und das war als Java-Erweiterung gedacht. So richtig hat das seiner Meinung nach aber nicht funktioniert, weil die Einschränkungen durch die Syntax zu groß waren.
aber war es wirklich nötig, komplett alles auf dem Kopf zu stehen, von einfachster 'Datentyp Variablenname'-Reihenfolge an?
Mit Typinferenz ist das die schönste Lösung und ich finde es sehr hilfreich für die Lesbarkeit, die "Signalwörter" (private) val / var / def / class / case ... immer direkt am Anfang zu haben.
Außer bei Methoden lässt man den Typ in den meisten Fällen einfach weg, also einfach String, Map<A, B> usw. durch val ersetzen und fertig
IntelliJ ist auch so nett und wandelt Java-Code beim Einfügen in Scala-Code automatisch um...
aber üblicherweise findet man doch Code-Beispiele wie
Code:
type Tagged[U] = { type Tag = U }
type @@[T, U] = T with Tagged[U]
Ich habe schon viel abschreckerenden Java-Code gesehen...
Aber ich muss schon sagen, die Idee ist ziemlich witzig, musste ich gleich mal ausprobieren
Man kann doch nicht erwarten, dass man ohne Vorwissen gleich alles verstehen kann.
Eine Sprache die quasi genauso aussieht wie Java und sich nicht anders verhält kann ja auch keine deutlichen Verbesserungen bringen. Wie soll denn das gehen?
Ich bin eher bei Projekten wie Ceylon skeptisch (interessant ist das aber allemal), die benennen einfach diverse Schlüsselwörter um, fügen ein paar Sachen ein und was herauskommt ist aber doch wieder sehr nahe an Java.
Da kann ich dann auch fragen, ob sich überhaupt ein Umstieg lohnt, wenn man bedenkt, dass sich Java auch in solchen kleinen Schritten weiterentwickelt?
Wenn man Scala nur wie Java benutzt (geht ja fast 1:1) und sich gar nicht auf neue Konzepte einlässt wird man auch nicht allzu viel davon haben. Von Anfang an aber gleich die erweiterten, vor allem die funktionalen Aspekte verstehen zu wollen ist aber auch nicht einfach möglich.
Ich frage mich auch öfter, wie man (hauptsächlich Java-) Umsteiger am besten heranführen kann: ob es besser ist, komplett auf funktionale Programmierung zu setzen, oder ob doch der "sanfte" Umstieg der richtige Weg ist. Ist wohl eher ein Thema für einen neuen Thread
Ich habe versucht rauszufinden welche Vorteile bringt einem die Programmiersprache Scala...
Bis jetzt konnte ich wirklich keinen Vorteil finden.
Man sagt es ist möglich mit Scala kürzere Programme zu schreiben. Ich frage mich bloß ist es den wirklich so wichtig heutzutage?
Ist es wirklich wichtig statt 10 Zeilen 4 zu haben und das auf Kosten der Lesbarkeit? Ich meine, ich habe quicksort in Scala angeschaut...
Code:
def quickSort[A <% Ordered[A]](xs: List[A]): List[A] = xs match {
case Nil => xs
case y :: ys => ys partition (_ <= y) match { case (l1, l2) => quickSort(l1) ++ (y :: quickSort(l2)) }
}
Für mich ist Scala ein Rückschritt in der Entwicklung der Programmiertsprachen. Es ist zu weit weg von der "allgemeinen" Syntax, der Scalacode ist unleserlich, nicht intuitiv zu verstehen und erfordert zusätzlichen Zeitaufwand durch Einarbeitung von neuen Mitarbeiter, Studenten, Praktikanten usw... Einsatz von Scala könnte also teuerer sein.
Natürlich, es gibt bestimmt Fälle in denen man mit Scala das eine oder das andere Problem "besser" lösen kann. Aber das unterscheidet Scala nicht von anderen 100ten exotischen "Hauptsache-Anders"- Programmiersprachen, die ebenfalls ihre kleinen Vorteile haben.
Und schon haben wir eine "rein objektorientierte Sprache". Hura! Endlich!... Und jetzt? :bahnhof:
Also ich finde es schön dass es zb in C++/Java primitive Datentypen gibt. Sie sind für mich wie kleine Helfer, wie Bauer im Schach, wie eine Ausnahme eines Regels... Alles unter ein Dach zu bringen, wie in Scala, finde ich überhaupt nicht innovativ, dafür aber ziemlich primitiv.
Soweit ich weiss wurde Scala entwickelt zu den Zeiten als Java immer populärer und weltweit anerkannt wurde und als es klar wurde dass OO doch kein Unsinn ist. Vielleicht war Scala bloß ein verzweifelte Versucht etwas vom VM-Kuchen abzubekomen. Oder man dachte sich (aus uraltem Drang nach "anders sein"), "hey lasst uns mal eine neue Sprache entwickeln, es soll etwa wie Java funktionieren nur die Syntax ist einwenig anders, sonst glaubt uns ja keiner, dass es eine neue innovative Sprache ist. So kann man "smarte" Anwendungen schreiben, wir nennen die Sprache Scala und es wird voll der Bringer!".
Also ich sage es nicht weil ich ein hoffnugsloser java fan bin. Ich finde viele Programmiersprachen toll. Als ich eine Webcamandwendung schreiben musste, habe ich c/c++ benutzt. Für einige Datenbankanwendungen mit Frontend haben wir java mit servlets, javascripts, php, (html) verwendet. Ich liebe und hasse zugleich das "loose typing" von javascript und ich kann die Zeiger in C nicht besonders leiden, aber insgesamt sind es tolle Programmiersprachen und wenn man die beherrscht (ich hoffe irgendwann mal), dann ist man glaube ich auf der sicheren Seite.
Falls es irgendwelche Anwendungsbereiche gibt in denen Scala unübetroffen ist, und zwar nicht durch kurzen Code, dann wäre ich sehr dankbar für die aufklärung, denn ich bin immer offen für neue Sprachen aber eben nur, wenn die oben genannten wirklich versagen...
Und ich dachte schon niemand will den berühmten quicksort aus dem Wiki Posten ;-)
Du hättest nicht nur schnell schnell Quellcode aus dem Wiki kopieren sollen sondern selbst da ein wenig lesen können.
Ich finde Java blöd und unnütz. Ich kann jedes Problem auch in Assembler lösen.
*gähn *
Ich lese sehr ungern Füllcode ohne wirklichen Inhalt, daher kommt mir das sehr entgegen. "Kürze" halte ich aber eher für einen Nebeneffekt, für mich hat die Sprache einfach viel bessere Möglichkeiten, auch komplexere Zusammenhänge recht logisch auszudrücken und ich mag es absolut nicht Code zu schreiben, der von den Inhalten ablenkt.
Dass man das ohne Erfahrung damit noch nicht wirklich abschätzen kann sollte wohl klar sein...
Ich habe es schon geschrieben: wie soll man denn auch etwas signifikant besser machen, wenn es im Endergebnis wieder genauso aussehen und funktionieren soll wie Java?
Ist es wirklich wichtig statt 10 Zeilen 4 zu haben und das auf Kosten der Lesbarkeit?
Für Leute, die sich ein wenig damit beschäftigen steigt die Lesbarkeit eher. Wie gesagt, Übungssache.
Quicksort war auch das erste, was ich in Scala gesehen habe. Verstanden habe ich am 1. Tag auch nicht viel davon, aber man kennt doch als anständiger Informatiker den Algorithmus und kann sich dann auch sicher mit etwas Hirnschmalz die Funktion der einzelnen Teile zusammenreimen. Wenn das nicht ausreicht gibt es noch diese tolle Erfindung namens "Buch" (oder scaladoc).
Jetzt frage ich mich eher, warum man das überhaupt anders hinschreiben sollte.
Es ist zu weit weg von der "allgemeinen" Syntax, der Scalacode ist unleserlich, nicht intuitiv zu verstehen
und erfordert zusätzlichen Zeitaufwand durch Einarbeitung von neuen Mitarbeiter, Studenten, Praktikanten usw... Einsatz von Scala könnte also teuerer sein.
Von Studenten wird man wohl noch erwarten können, dass sie das zu schaffen. Dass eine Umstellung in Unternehmen ein Risiko und zusätzlicher Aufwand ist wird jedem klar sein. Da muss man sicher die Nachteile gegen die Vorteile abwägen (dabei vielleicht auch ein wenig langfristiger denken.)
Also ich finde es schön dass es zb in C++/Java primitive Datentypen gibt. Sie sind für mich wie kleine Helfer, wie Bauer im Schach, wie eine Ausnahme eines Regels... Alles unter ein Dach zu bringen, wie in Scala, finde ich überhaupt nicht innovativ, dafür aber ziemlich primitiv.
Vielleicht auch eine Begründung, was daran so toll ist? Vor allem bei Java bekommt man durch das Autoboxing und Ausnahmeregeln auch wieder zusätzliche versteckte Komplexität und Performance-Fallen hinein und ich sehe dafür überhaupt keine Argumente außer "legacy"...
Bei den "kleinen Helfern" musste ich aber wirklich lachen, danke
Soweit ich weiss wurde Scala entwickelt zu den Zeiten als Java immer populärer und weltweit anerkannt wurde und als es klar wurde dass OO doch kein Unsinn ist. Vielleicht war Scala bloß ein verzweifelte Versucht etwas vom VM-Kuchen abzubekomen. Oder man dachte sich (aus uraltem Drang nach "anders sein"), "hey lasst uns mal eine neue Sprache entwickeln, es soll etwa wie Java funktionieren nur die Syntax ist einwenig anders, sonst glaubt uns ja keiner, dass es eine neue innovative Sprache ist. So kann man "smarte" Anwendungen schreiben, wir nennen die Sprache Scala und es wird voll der Bringer!".
Jetzt wirds aber wirklich albern. Ein bisschen informieren kann man sich vorher schon, bevor man sowas fabriziert. Zum Beispiel geht das hier in diesem Thread, da stehen schon einige Antworten auf deine Fragen und Bedenken...
Ich habe versucht rauszufinden welche Vorteile bringt einem die Programmiersprache Scala...
Bis jetzt konnte ich wirklich keinen Vorteil finden.
Man sagt es ist möglich mit Scala kürzere Programme zu schreiben. Ich frage mich bloß ist es den wirklich so wichtig heutzutage?
Ist es wirklich wichtig statt 10 Zeilen 4 zu haben und das auf Kosten der Lesbarkeit? Ich meine, ich habe quicksort in Scala angeschaut...
Code:
def quickSort[A <% Ordered[A]](xs: List[A]): List[A] = xs match {
case Nil => xs
case y :: ys => ys partition (_ <= y) match { case (l1, l2) => quickSort(l1) ++ (y :: quickSort(l2)) }
}
Für mich ist Scala ein Rückschritt in der Entwicklung der Programmiertsprachen. Es ist zu weit weg von der "allgemeinen" Syntax, der Scalacode ist unleserlich, nicht intuitiv zu verstehen und erfordert zusätzlichen Zeitaufwand durch Einarbeitung von neuen Mitarbeiter, Studenten, Praktikanten usw... Einsatz von Scala könnte also teuerer sein.
Das Thema Lesbarkeit ist so eine Sache, persönlich finde ich das man sich langsam von der Beschränktheit des ASCII-Zeichensatzes verabschieden könnte. Kleines Beispiel, in ADA (und in Java auch) kann man Sourcecode in Unicode schreiben, als ich letztens eine Formel tippte habe ich tatsächlich das stilisierte Summenzeichen für ein Integral als Variablennamen verwendet.
Nimm das mit der Syntax nicht zu ernst, Programmiersprachen sind Mittel zum Zweck. Die Darstellung der Konzepte der verwendeten Programmiersprache sollte vorallem eingängig sein und das in einer ansprechenden Art und Weise zu tun, damit haben aber recht viele Programmiersprachen zu kämpfen und bisher ist IMHO in der Hinsicht auch nocht nicht der ultimative Durchbruch gelungen.
Wichtig ist das du die aktuell zwei "großen" Herangehensweisen an Probleme begreifst, die Funktionale und die Imperative. Das "Modell"-Objektorientierung schließt dabei weder das Eine noch das Andere aus. Und es ist völlig egal welche Sprache du dafür nimmst die das Eine, das Andere oder Mischformen unterstützt, du wirst selten eine "hübsche" oder "ansprechende" Syntax finden und oft ist es auch persönlicher Geschmack.
Also bevor du nur nach dem "Aussehen" urteilst schau in die jeweilige Sprache rein und philosophiere darüber ob die dir angebotene Syntax adäquat ist um die von der Sprache unterstützten Konzepte gut umzusetzen.
Und falls sich jetzt jmd fragen sollte, nein ich verwende kein Scala, meine Hauptsprachen sind Java und in meiner Freizeit übe ich mich in Common Lisp mit dem Plan irgendwann auf Clojure zu wechseln.
Zugegeben: Ich finde die syntax dort auch ziemlich kryptisch - angefangen bei ... schlecht googlebaren Elementen wie "<%" bis zu Dingen, die für einen Java-Programmierer auf den ersten Blick wohl einfach nur "(unangenehm) ungewohnt" aussehen. [Das hier IST ein Arrayzugriff!!!111einself ]
Aber ich denke, dass eine höhere Abstraktion Vorteile haben kann (oder für manche Sachen vielleicht sogar notwendig ist). Weil hier das Stichwork Quicksort gefallen ist, schlage ich nochmal den Bogen zu einem meiner Beiträge weiter oben : Einer der Hauptgründe, weswegen ich mir Scala mal ansehen wollte, war, dass ich gehofft hatte, dass es damit möglich sein könnte, eine Domänenspezifische Sprache zu erstellen, die ähnlich kompakt und mächtig ist wie NESL. Die Frage, warum 10 Zeilen beinahe-Pseudocode (auch wenn sie ein "<%" enthalten) vorteilhaft sein können, stellt sich vielleicht gar nicht mehr, wenn die Alternative dazu aus 1700 Zeilen kryptischem Spezialcode besteht: Making Parallel Programming Easy and Portable . Das geht eben praktisch nur so schön, wenn man eben nicht mit einer for-Schleife auf einem rohen Array rumhantiert (aka Code schreibt, bei dem eine 1:1-Übersetzung in Assembler reine Fleißarbeit wäre) sondern das, was zu tun ist auf einer höheren Ebene beschreibt.
