sind denn alle Entwickler festgefressen....

[Jacques de Grand Prix]

Scala mit LLVM, sehr kühl. Danke für den Hinweis und die ausführlichen Antworten.

Im aktuellsten Commit erwähnt der Entwickler übrigens, dass er eine Garbage Collection hinzugefügt hat. https://github.com/greedy/scala

[Trockenobst]

bugmenot schrieb:
--------------------------------------------------------------------------------
> es geht ja schließlich um imperativ vs. deklarativ.
> Bloß weils deklarativ ist, muss man ja nicht auf Datenkapsellung oder
> Polymorphie verzichten. Funktionales-OO ist überhaupt kein Problem.

Der Punkt ist dass auch niemand mehr Java "prozedural" verwendet.
Das kann man, aber muss man es? Ich glaube es gibt sogar noch "goto".

Scala ist funktional, und dann soll man - weil es nicht anders geht - wieder
die alten Sachen verwenden bis es durchgängig ist? Wieso gibt es die
Builder, die Aktoren; Projekte wie "Lift"? Weil man eben nicht zurückgehen
will. Aber das geht nicht 100%. Warum dann überhaupt beginnen?

Das ist doch das Problem. Java ist selbst nicht wirklich durchgängig,
die Strukturen sind auch nicht wirklich durchgängig, z.B. was die Generics
angeht sind viele Bibliotheken noch nicht auf diesem Stand. Und das war
vor 3 Jahren.

> Auch gibt es genug Statistiken, die belegen das man Funktional nur ca. 1/4
> vom Original-Code braucht. Ich kann das aus eigener Erfahrung bestätigen,

Das hilft alles nichts, wenn das wichtigste Native Code ist. Das ist meine Ziel-
richtung. Ich kann ja nicht mal pure Java auf IOS laufen lassen. Die ganzen
Compiler und Co. sind supercrude. Backend: ja. Aber Mobile ist halt die
Zukunft und da nützt nichts was auf der JVM basiert.

Nicht ohne Deal zwischen Apple und Oracle. Der nie kommt.

[Trockenobst]

ShinGouki schrieb:
--------------------------------------------------------------------------------
> Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
> suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
> herrausvorderungen z.B: Garbage Collection.

Lustig wie man behauptet die Argumente sind schwach und dann kommt man
mit Pre-Alpha Bastellösungen und sagt: Ja damit kannst Du das nächste
Angry Birds oder die 1 Million Downloads Sparkassenlösung bauen.
Come on. Wunschdenken bezahlt nicht die Rente. Experimente muss man
sich leisten und der PayOff ist bei solchen Problemstellungen "Fraglich".

Ideologie ist einfach keine Basis.

> Man kann ganz sicher Scala in 1-2 Tagen so lernen das man es 'wie Java'
> verwenden kann.

Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
Nur hilft das außerhalb der JVM Welt nichts.

> Andere Sprachfeatures oder Syntax 'zucker' sorgen dafür das man sich in
> funktionalen Sprachen nicht so ausschweifend ausdrücken muss wie in z.B
> Java.

Scala/Funktionale Programmierung hat massive Vorteile in Cluster/Netz/High-
Thread Umgebung, wenn man große komplexe Prozesse zu managen hat.
Closures, Actors etc. haben massive Vorteile in verteilten transaktionellen
Modellen.

Aber nicht jeder braucht diesen Hammer.

[Tapsi]

Kartoffel schrieb:
--------------------------------------------------------------------------------
> Wieso? Von entweder oder war ja nie die Rede ;)
> Ganz klar die VM hat ein ganz dickes Defizit und das ist das man wahlweise
> immer noch keinen nativen Code kompilieren kann.

Das ist doch überhaupt keine Aufgabe einer VM. Wenn geht dieses Problem doch eher an die Adresse eines Java AOT Compilers. Ich verzichte eher auf nativen Code ( was zur Hölle soll eigentlich nativer Code sein? Du meinst wahrscheinlich prozessorspezifischen Code oder? ) und habe guten VM Byte Code den ich relativ unabhängig von der Hardware verteilen kann. Vor allem reiten ja immernoch viele auf der VM rum, obwohl diese mittlerweile ein echt gute Optimierungsverfahren für den Source hat und daher ziemlich performant ist.

while not sleep
sheep++

[Trockenobst]

Jacques de Grand Prix schrieb:
--------------------------------------------------------------------------------
> Verstehe auch nicht, was gemeint wurde mit "in Scala neuimplementieren".
> Wahrscheinlich einfach nur unwissenheit darüber, dass alles auf der JVM
> benutzbar ist. Sprachdesigner wie zum Beispiel Ola Bini (von Ioke und einer
> anderen neuen) sprechen ja auch oft davon, dass man mit der JVM gleich ein
> fertiges Ökosystem bekommt.

Neuimplementieren nach funktionalen Gesichtspunkten.
Und das klappt ja auch in Java nicht.

Du hast Bibliotheken, die z.B. "Person" und "PersonList" Objekte haben,
was aber seit der Generifizierung in Java 5 nicht mehr notwendig ist.

Du hast dann List<Person> Objekte. Und dass ist in Scala für viele
Dinge nicht verfügbar. Bestimmte Dinge sind einfach funktional
besser zu lösen - warum gibt es sonst z.B. eigene Datenbankschichten
in Scala, oder auch das "Lift" Webframework?

Weil eben "irgendwas anderes nehmen" nur ein Hack ist. Ich hasse es
auch, wenn ich z.B. in C++ C Biliotheken nehmen muss, die weder STL
oder Boost-Standardobjekte verwenden. Das ist ein Systembruch.

Bei einer Neulösung könnte ich mir mit Aussicht auf schrittweise
Verbesserung tatsächlich diesen "Bruch" als temporär abtun. Aber das
ist ja schon bei Java nicht so. Viele große Bibliotheken behalten mit
einem Schulterzucken ihr "PersonList" Objekt bei.

Es ist eben dann nicht logisch auf "irgendwas" neues zu setzen, sondern
das ist ideologisch gepuscht. Das ist selbstverständlich erlaubt. Aber es
ergibt sich nicht. Momentan ist man bei purem Java mit +100 MB an Libs
besser aufgehoben als irgendeinen systemischen Hack zu machen.

Siehe z.B. Scala Traits:
http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5

Libs zu nehmen die nicht mit Traits optimiert sind, wirkt einfach ekelig.

> vorgestern oder so) aus. Darin werden auch die Vorteile dieses Paradigmas
> beschrieben: www.altdevblogaday.com

Carmack ist ein Millionär der halt gerne rumexperimentiert.
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Nur: niemand hat behauptet das funktionale Programmierung schlecht ist.
Ich beziehe mich hier auf die gelebte Realität vs. das was man alles für
Hürden überspringen muss um zu einem Ergebnis zu kommen dass bestenfalls
ein Wüstes zusammenstecken von Methodologien ist. Und wenn man das
Ergebnis durch die Brille der Ideologie anschaut, das auch so kommuniziert
werden muss - und nicht so tut, als wäre es nicht so.

Ich finde z.B. meine Rückentwicklung von Java zu C++ einen leichten Rückschritt,
speziell was Debugging und vor allem Memory und Threadverhalten angeht. Da
muss man verflucht genau aufpassen was man tut, sonst kommt man in Error-
höllen ohne Wiederkehr. Trotzdem ist es eben dass was der Markt vorgibt.

Man muss sich ja nur ansehen wo Scala entwickelt worden ist und wie es entwickelt
worden ist. Da hatten Leute unendlich Zeit und unendlich Ressourcen das Ding
für ihre Zwecke so lange zu quälen bis es passte. Der normale Entwickler hat das
eben nicht, und im Normalen Projekt passiert das auch nicht.

[Kartoffel]

Naja ob iOS dann wirklich "die" Zukunft sein wird werden wir sehen.
LLVM ist interessant und sollte beobachtet werden.

Ich habe Scala genutzt welche eine alte größere Java Jar angesprochen hat.
Und ja du hast vollkommen recht (wie auch auch schon schrieb) Funktional kannst du deine alten Jars sowieso nicht nutzen. SWING und co. natürlich auch nicht, aber man kann für diverse algos Scalas Funktionalität sehr angenehm nutzen. Bsp. mit Higher Order Funktionen. (welches es übrigens auch in Vala gibt ;)

Ob sich Scala mal im Mainstream durchsetzen wird weis ich nicht..... aber ich glaube an die Sprache weil sie auch sehr gut OO kann.

@john carmack funktional in c++
Das Funktional in C++ nicht sonderlich "spass" macht leuchtet mir ein ;-)

[Trockenobst]

Tapsi schrieb:
--------------------------------------------------------------------------------
> echt gute Optimierungsverfahren für den Source hat und daher ziemlich
> performant ist.

Das hilft nur nicht wenn sie für 50% der aktuellen Plattformen die relevant
sind nicht verfügbar ist. http://en.wikipedia.org/wiki/IOS_SDK#Java

Und komme mir nicht mit kruden Crosskompilern. Da haben sich schon ganz
andere Leute ihre Haare vom Kopf gefrustet.

[Tapsi]

ShinGouki schrieb:
--------------------------------------------------------------------------------
>
> Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
> suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
> herrausvorderungen z.B: Garbage Collection.

Mir fehlt da einfach der Riesenvorteil ( außer Vllt. das man keine Runtime braucht ) gegenüber der Verendung einer VM.

> Ein Argument was schon einmal viel möchte xh nocheinmal unterstreichen :
> den grossen Firmen ist herzlich egal mit welcher Programmiersprache ihre
> Programme laufen, solange billig. Also bei kleinen Projekten wird man eher
> mal Scala ausprobieren können als in bei großen legacy Anwendungen oder
> anderen Team Projekten.


> Scala im Einsatz:
> Jeder der hier davon schwärmt. Hat sicherlich noch nicht das Vergnügen
> gehabt Scala in einen vorhandenen Java 'Build-Prozess' einzubinden.
>
> Scala verändert die Möglichkeiten für Programmierer auf der JVM. aber bevor
> entscheider daraus Vorteil ziehen können wird wohl trotzdem noch etwas
> Zeit vergehen.

Scala muss ja auch erstmal in realen Projekten Meter Beweis stellen, dass es gegenüber Java ausschlaggebende Vorteile hat. Das Problem bei kleinen Beispielen ist ja oft, dass sie halt klein sind und die größeren Probleme außer acht lässt. Ich bekam mal die Webung für Scala von nem Freund der meinte alles besser weil man keine Getter/Setter braucht. Ich weiß nicht wie es bei euch ist, aber dass kann doch kaum mehr als kleiner syntaktischer Zucker gemeint sein. Besonders da solche Sachen eh von IDEs selbst generiert werden.

while not sleep
sheep++

[Tapsi]

Trockenobst schrieb:
--------------------------------------------------------------------------------
> Das hilft nur nicht wenn sie für 50% der aktuellen Plattformen die
> relevant
> sind nicht verfügbar ist. en.wikipedia.org#Java

Da stand doch gerade noch IOS SDK?!?! Das Java auf geschl. Plattformen wie iOS nicht verfügbar ist kann man nicht Oracle vorwerfen und schon gar nicht der Spache selbst.

EDIT: 50% ist ja voll,aus dem Himmel gegriffen und m.E. völlig falsch. Es ist auf mind. einer großen Mainstream Platform nicht verfügbar... das wäre richtig.


> Und komme mir nicht mit kruden Crosskompilern. Da haben sich schon ganz
> andere Leute ihre Haare vom Kopf gefrustet.

Hmm ein gutes Konzept ist Streaming. Das sah ( in einem frühen Alphatest ) sehr viel versprechend aus. ;)

while not sleep
sheep++



1 mal bearbeitet, zuletzt am 29.04.12 21:07 durch Tapsi.

[Jacques de Grand Prix]

Trockenobst schrieb:
--------------------------------------------------------------------------------

> Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
> Nur hilft das außerhalb der JVM Welt nichts.

Hast du auch sowas wie "Programming Groovy" von den Pragmatic Programmers gelesen? Da gibt es ein etwa 40-Seitiges Kapitel "Groovy for the Java eyes".

Eine Woche hat das bei mir auch etwa gedauert, aber danach noch viel in der (eher miserablen) Groovy-Wiki und bei MrHaki nachgeguckt. Mit funktionaler Programmierung meist du nur Closures bzw. Funktionen höherer Ordnung, oder?

Denn es ist halt realistisch Scala in ein bis zwei Wochen zu erlernen, mit den Besonderheiten der Funktionalen Programmierung. Richtig mit Rekursion und sowas wie Lazy Evaluation und von mir aus auch Monaden kommt man dann aber immer noch nicht zurecht.

[Kartoffel]

Tapsi schrieb:
--------------------------------------------------------------------------------
> Kartoffel schrieb:
> ---------------------------------------------------------------------------
> -----
> > Wieso? Von entweder oder war ja nie die Rede ;)
> > Ganz klar die VM hat ein ganz dickes Defizit und das ist das man
> wahlweise
> > immer noch keinen nativen Code kompilieren kann.
>
> Das ist doch überhaupt keine Aufgabe einer VM. Wenn geht dieses Problem
> doch eher an die Adresse eines Java AOT Compilers. Ich verzichte eher auf
Ach Gottchen.. dann eben Aufgabe der JRE.
> nativen Code ( was zur Hölle soll eigentlich nativer Code sein? Du meinst
http://de.wikipedia.org/wiki/Native-Code?title=Native-Code&redirect=no

> wahrscheinlich prozessorspezifischen Code oder? ) und habe guten VM Byte
> Code den ich relativ unabhängig von der Hardware verteilen kann. Vor allem
> reiten ja immernoch viele auf der VM rum, obwohl diese mittlerweile ein
> echt gute Optimierungsverfahren für den Source hat und daher ziemlich
> performant ist.
Wer hat den behauptet das die VM schlecht oder langsam sei? Ich glaub du missverstehst mich.
Meine Meinung ist das einer der Hauptgründe warum sich Java nicht auf dem Desktop durchgesetzt hat die benötigte VM ist. Sprich sie muss vor allem beim ersten Programmstart langsam geladen werden. Zudem wäre nativer Code sofort schnell während Java oder Scala erst "ge-JIT-tet" werden muss.

Ich finde diese hartnäckige "write once run anywhere" Ideologie falsch und behaupte mal das diese Ideologie daran schuld ist das sich Java auf dem Desktop nicht durchgesetzt hat. Was spricht dagegen javac -Target=windows oder javac -Target=Linux oder javac -Target=bytecode
?

Das ganze erinnert mich irgendwie an Richard Stallman und seiner unabdingbaren Einstellung zu GNU.

[Tapsi]

Kartoffel schrieb:
--------------------------------------------------------------------------------

> Ach Gottchen.. dann eben Aufgabe der JRE.

Ja was denn? Das sind zwei verschiedene Dinge.... du sagtest die VM sollte weg weil sie kein nativen Code erlaubt usw... was aber auch wieder falsch ist, da die JVM ( zumindest die HotSpot VM ) zur Laufzeit Maschinencode erzeugt. Ein guter Vorteil einer VM, dass man plattformunabhängigen Code erzeugt ( im Bezug auf die VM ) und diesen einfach verteilen kann und jede VM für sich für das zu Grunde liegende System optimierten Code erzeugen kann. Komfortabler als jede für jedes System einzelne spezialisierte Binärprogramme erstellen zu müssen (IMHO).


> Wer hat den behauptet das die VM schlecht oder langsam sei? Ich glaub du
> missverstehst mich.

Dann Sry ;)

> Meine Meinung ist das einer der Hauptgründe warum sich Java nicht auf dem
> Desktop durchgesetzt hat die benötigte VM ist. Sprich sie muss vor allem
> beim ersten Programmstart langsam geladen werden. Zudem wäre nativer Code
> sofort schnell während Java oder Scala erst "ge-JIT-tet" werden muss.

Mja das stimmt. Obwohl ich den Unterschied bei Anwendungsprogrammen kaum gravierend finde. Leider ist das Installieren eines Plugins immernoch das größte Problem von Java . Hier finde aber Projekte gut die eine VM in das Setup-Programm kapseln.. weil dies gerade für die meisten User dann wieder kein Problem darstellt Java Programme zu verwenden. Aber ich glaube Oracle hat diese Art der Verteilung vor kurzen verboten oder?


> Ich finde diese hartnäckige "write once run anywhere" Ideologie falsch und
> behaupte mal das diese Ideologie daran schuld ist das sich Java auf dem
> Desktop nicht durchgesetzt hat. Was spricht dagegen javac -Target=windows
> oder javac -Target=Linux oder javac -Target=bytecode
> ?

Ich dachte so etwas wollte man ja vermeiden plattformspezifischen Code schreiben zu müssen. ( Obwohl man es hier und da dann doch machen muss )
Naja ich gehe davon aus dass man wirklich die Fragmentierung vermeiden wollte und eine für alle VM Implementierung gültige Spezifikation einer Sprache haben wollte wo Datentypen immer eine fest definierte Größe haben usw. . Von dem Standpunkt finde ich die Verwendung einer VM auch sehr klug.


> Das ganze erinnert mich irgendwie an Richard Stallman und seiner
> unabdingbaren Einstellung zu GNU.

Kann ich nicht beurteilen... keine Anung :/

while not sleep
sheep++

[Kartoffel]

Man hat sich quasi aus der Desktop Akzeptanz herraus Fragmentiert ;-)

[ShinGouki]

Trockenobst schrieb:
--------------------------------------------------------------------------------
> ShinGouki schrieb:
> ---------------------------------------------------------------------------
> -----
> > Scala ohne VM ist bereits angefangen, einfach mal nach: Scala + LLVM
> > suchen. Dieser Ansatz bringt Vorteile, Nachteile sowie große
> > herrausvorderungen z.B: Garbage Collection.
>
> Lustig wie man behauptet die Argumente sind schwach und dann kommt man
> mit Pre-Alpha Bastellösungen und sagt: Ja damit kannst Du das nächste
> Angry Birds oder die 1 Million Downloads Sparkassenlösung bauen.
> Come on. Wunschdenken bezahlt nicht die Rente. Experimente muss man
> sich leisten und der PayOff ist bei solchen Problemstellungen "Fraglich".
>
> Ideologie ist einfach keine Basis.
>

Ja genau das meinte ich ja bisher habe ich wirklich wenige Argumente für scala gehört, leider.
> > Man kann ganz sicher Scala in 1-2 Tagen so lernen das man es 'wie Java'
> > verwenden kann.
>
> Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
> Nur hilft das außerhalb der JVM Welt nichts.
Aha und was beinhaltet dieses 'funktionale Programmierung' dann? Der Punkt der Blogs von John Carmack und Michael Feathers ist ja das man Vorteile mit der funktionalen Programmierung hat, auch außerhalb der JVM.
> > Andere Sprachfeatures oder Syntax 'zucker' sorgen dafür das man sich in
> > funktionalen Sprachen nicht so ausschweifend ausdrücken muss wie in z.B
> > Java.
>
> Scala/Funktionale Programmierung hat massive Vorteile in
> Cluster/Netz/High-
> Thread Umgebung, wenn man große komplexe Prozesse zu managen hat.
> Closures, Actors etc. haben massive Vorteile in verteilten
> transaktionellen
> Modellen.
Netz und High-Thread Umgebung hört sich interessant an, schon mal an sowas gearbeitet?
> Aber nicht jeder braucht diesen Hammer.
Nein den wir heißen ja auch alle anders.

Grundsätzlich gefällt mir dieser Beitrag hier:
http://forum.golem.de/kommentare/wirtschaft/freie-softwareentwickler-welche-programmiersprachen-angesagt-sind/welche-programmiersprache/62537,2982697,2982697,read.html#msg-2982697

also der Anfang, es ist ENORM wichtig über den Tellerrand hinaus zuschauen. Es ist wichtig Begriffe zu lernen und eigene Erfahrungen im Zusammenhang zu machen.
Funktionale Programmierung ist ein anderes Paradigma und dafür braucht es einiges an Zeit um sich darauf einzustellen:
http://www.infoq.com/presentations/Functional-Thinking

Und wer noch ganz mutig ist und Langeweile hat kann hier mal reinschauen:
(und die sich dafür interessieren wie die Zukunf der Programmierung aussehen könnte)
https://www.tele-task.de/archive/video/realhq/14029/

https://github.com/damelang/nile

[ShinGouki]

Jacques de Grand Prix schrieb:
--------------------------------------------------------------------------------
> Trockenobst schrieb:
> ---------------------------------------------------------------------------
> -----
>
> > Ich habe Groovy und funktionale Programmierung in einer Woche gelernt.
> > Nur hilft das außerhalb der JVM Welt nichts.
>
> Hast du auch sowas wie "Programming Groovy" von den Pragmatic Programmers
> gelesen? Da gibt es ein etwa 40-Seitiges Kapitel "Groovy for the Java
> eyes".
>
> Eine Woche hat das bei mir auch etwa gedauert, aber danach noch viel in der
> (eher miserablen) Groovy-Wiki und bei MrHaki nachgeguckt. Mit funktionaler
> Programmierung meist du nur Closures bzw. Funktionen höherer Ordnung,
> oder?
>
> Denn es ist halt realistisch Scala in ein bis zwei Wochen zu erlernen, mit
> den Besonderheiten der Funktionalen Programmierung. Richtig mit Rekursion
> und sowas wie Lazy Evaluation und von mir aus auch Monaden kommt man dann
> aber immer noch nicht zurecht.

Monaden sind eigentlich nicht wirklich kompliziert nur erst einmal ungewohnt. Die oben genannten Quelen hören sich für diese Themen zumindest fragwürdig an ;)

[Tapsi]

Das befürchte ich auch :/

while not sleep
sheep++

[Coding4Money]

ShinGouki schrieb:
--------------------------------------------------------------------------------
> Ein Argument was schon einmal viel möchte xh nocheinmal unterstreichen :
> den grossen Firmen ist herzlich egal mit welcher Programmiersprache ihre
> Programme laufen, solange billig. Also bei kleinen Projekten wird man eher
> mal Scala ausprobieren können als in bei großen legacy Anwendungen oder
> anderen Team Projekten.

Auch die großen Firmen haben es nicht immer leicht das passenden Know-How zu finden. Mich würde es da schon wundern, wenn eine größere Firma mit eigener IT-Abteilung ohne guten Grund auf eine Sprache setzt, die nur von einem Bruchteil der Entwickler wirklich beherrscht wird.
Wenn ich da ein Java oder C# Programm habe, dann finde ich schon eher einen passenden Entwickler, als wenn ich jetzt einen Entwickler mit F# oder Scala-Erfahrung suchen muss.

[Tapsi]

Vollkommen Richtig... und es wäre schlicht zu teuer bei Problemen neue Leute zu finden bzw. die Kosten für die Weiterbildung der eigenen Mitarbeiter zu zahlen.

while not sleep
sheep++

[Freepascal]

> Die Antwort warum Scala nicht dabei ist, ist recht einfach zu beantworten.
> Scala ist zu schwer zu erlernen. Man hat lieber eine Horde dummer
> Java-Programmierer als eine Handvoll kreativer die Scala beherrschen. Ich
> fand Scala schon anspruchsvoller als bissl Java zu lernen mMn.

Sprachen sind immer einfach. Was anspruchsvoll sein kann, ist das Projekt, das man damit umsetzt. Wer irgendwelche Fähigkeiten von der eingesetzten Programmiersprache ableiten will, zeigt nur, dass er nicht viel Ahnung von Softwareentwicklung hat.

[Helicon]

Freepascal schrieb:
--------------------------------------------------------------------------------
> > Die Antwort warum Scala nicht dabei ist, ist recht einfach zu
> beantworten.
> > Scala ist zu schwer zu erlernen. Man hat lieber eine Horde dummer
> > Java-Programmierer als eine Handvoll kreativer die Scala beherrschen.
> Ich
> > fand Scala schon anspruchsvoller als bissl Java zu lernen mMn.
>
> Sprachen sind immer einfach. Was anspruchsvoll sein kann, ist das Projekt,
> das man damit umsetzt. Wer irgendwelche Fähigkeiten von der eingesetzten
> Programmiersprache ableiten will, zeigt nur, dass er nicht viel Ahnung von
> Softwareentwicklung hat.

+1