Post by Jochen Theodorouwitzig finde ich ja die Gründerzusammensetzung... Guillaume ist der
Projektmanager von Groovy und Initiator von Grails, Grame ist der
Projektmanager von Grails und hat es aus den Kinderschuhen herausgeführt
, und Alex... der ist noch ganricht lange dabei, hat aber die
Performance in Groovy aufs Korn genommen... er war vorher bei JetBrains.
Was ist daran witzig? Das es nur Techniker gibt und keine
Vollblut-Kaufleute? ;)
Post by Jochen TheodorouG2One bietet dann Training und kommerziellen Support für Firmen im
[...]
schienen viele darüber sehr erfreut zu sein. Tja, wird sicher
interessant, ist das erste Startup bei dem ich bin...
Ich wünsche euch Erfolg... das klingt doch nach einem Traumjob.
Post by Jochen TheodorouPost by Stefan Matthias AustIch wollte suggerieren, dass JS2 die Chance hat, die anderen Sprachen
inklusive Groovy zu verdrängen. Sie wird - wenn sie tatsächlich in Flash
und Firefox eingebaut wird - eine extrem große Verbreitung bekommen und
damit wichtig als Entwicklungssprache für Webanwendungen werden.
ok, dann mal die Gegenfrage... warum hat das Javascript nicht geschafft?
Was? Das verdrängen anderer Scriptsprachen auf der JVM? Nun, Rhino war
und ist erfolgreich. Eine stabile Software, vollständig und nicht nur
ein halber proof-of-principle wie 90% der anderen Sprachen. JS ist ja
sogar als default bei Java 6 dabei. Das nenne ich geschafft...
Post by Jochen TheodorouWarum ist Javascript nicht Actionscript? Was wird Adobe daran hindern
JS2 in Action Script 4 abzuwandeln?
Sie selbst. Das erklärte Ziel ist Kompatibilität, damit sie sagen
können, dass man Flash genauso einfach wie Webseiten programmieren kann.
Denen ist an noch einem Dialekt nicht gelegen. Der Einstieg in
ActionScript war einfach, da ich JavaScript und Java kannte. Dennoch
gibt es in AS3 Unterschiede zu JS1, da sie eben Konzepte aus Java für
das "programming in the large" übernommen haben.
Post by Jochen TheodorouWarum glaubst du sollte JS2 in der
Lage sein Java zu verdrängen?
Nein, nicht Java, sondern andere Scriptsprachen für Java.
Post by Jochen TheodorouWarum sollte JS2 zum Beispiel in der Lage
sein Ruby zu verdrängen?
Weil Ruby einen überraschenden Erfolg nur Rails zu verdanken hat. Ein
"Rails" in JavaScript könnte viele Leute zu JavaScript bringen (wie ihr
es ja auch mit Groovy und Grails macht). Als Steve Yegge erwähnte, dass
er als internes Projekt Rails auf Rhino portiert hatte, was das
Interesse riesig.
Post by Jochen Theodoroudazu brauche ich aber doch keine XML syntax direkt in der Sprache!?
Es ist praktisch. Wenn ich dem Server ein XML-Dokument schicken muss und
einfach
http.Send(<foo>{name}</foo>)
schreiben kann, ist das bequem und besser als Strings zu benutzen, wo
ich auch leicht man ein End-Tag vergessen könnte. Natürlich kann ich XML
auch bequem parsen, etwa
var list = doc..name(@staff == 'true')
was mir dann ein Array aller der <name>-Elemente gibt, die ein Attribut
"staff='true'" haben. Der Vorteil ist, die Syntax ist ähnlich zu XPath
und kommt auch mit Namensräumen klar, die wahrscheinlich bei etwas wie
GPath, das mit Java bzw. Groovy-Syntax auskommen muss, zu Problemen
führen könnten. Oder wie würdest du angeben, dass du nur Elemente
<x:name xmlns:x="urn:example:1"/>
finden willst, nicht aber andere Elemente mit dem lokalen Namen "name"?
Post by Jochen Theodorouso ist ;) Ausserdem sind beides allgemeine Konzepte der
Programmiersprache, die nicht nur mit XML genutzt werden können.
Das ist definitiv ein Vorteil. Ich würde aber sagen, etwas wie GPath
oder Builder sollten noch nicht einmal Konzepte der Sprache sein,
sondern diese sollte so flexibel sein, dass man sich das als Library
selbst bauen kann (was vielleicht in Groovy geht). In JS1 oder AS3 hast
du da keine Chance, aber durch die Meta-Funktionen in JS2 könnte es gehen.
Post by Jochen TheodorouPost by Stefan Matthias AustEs ging mir nicht so sehr um den Vergleich mit Groovy sondern darum,
dass JS2 deutlich mehr Stoff enthält als JS1. Man kann schon fast
argumentieren, dass diese Sprache jetzt viel zu kompliziert wird und der
Erfolg von JS1 in deren Einfachheit begründet lag. JS2 ist deutlich
komplexer und größer als Java.
was ja eigentlich gegen den Trend spricht, denn der geht eigentlich
wieder zur flachen Lernkurve, zur einfachen Handhabung und zur geringen
Komplexität.
Sag das C# 3.0 :) Ich denke, es geht eher in Richtung "erwachsene"
Sprachen, d.h. die existierenden User wollen immer mehr und daher
wachsen die Sprachen - auch Java.
Weniger wäre IMHO natürlich mehr, aber dann kommen wie zu Sprachen wie
Python oder Scheme und die sind irgendwie nie so beliebt wie die fetten
Sprachen. Groovy ist als Superset von Java ja auch komplexer.
Post by Jochen TheodorouJavascript wurde gerne benutzt weil a) die meisten Browser
Wieso Vergangenheitsform?
Post by Jochen Theodoroues unterstützen und b) weil man es verwqenden kann ohne es wirklich zu
verstehen.
Das kann man mit fast jeder Sprache :)
Vergiss die Hobby-User, die irgendwas mit JavaScript irgendwie
zusammenfummeln. Die Sprache ist IMHO wichtig, weil man versucht, immer
komplexere Webanwendungen im Browser zu realisieren und da kommt man
eben nicht um JavaScript herum. Und die Bibliotheken wachsen - man
schaue sich man Dojo (ugg) an, oder YUI oder Ext oder auch nur den
Quelltext von Google Maps. Viel JavaScript. Und da haben sich die Macher
von JS2 gesagt, Klassen, Typen, usw. sind hilfreich.
Post by Jochen Theodoroumein erster Gedanke war das man versucht hat Javascript zu
"javasieren"... ich weiss kein echtes Wort, aber warum sonst bringt man
da statische Typen ein, Klassen und auch Interfaces? Interessant wäre
Das habe ich auch so verstanden.
Post by Jochen Theodorouauch die Frage ob ein Javascript programm auch auf einem Javascript2
System läuft.
Das ist das Ziel.
Aus dem Grund reparier man dann auch nicht so Dinge wie "typeof null ==
'object'" oder spezifiziert gewisse Dinge so, wie der IE es macht, passt
also die Spec an die Realität der Browser an.
Post by Jochen TheodorouMan muss sich mal anschauen wie eine von den jüngeren
Programmiersprachen gross geworden ist. Ruby hatte Ruby on Rails. Ich
bezweifle dass Railsfans ihr Ruby gegen Javascript eintauschen möchten.
Ich weiß nicht, Ruby ist sicherlich nicht die beste Sprache. Ich finde
z.B. Python deutlich eleganter. Mich stört der Ansatz, den andere
sicherlich lieben, dass es immer mehr als einen Weg gibt. Rails ist
nett, aber hat viel, viel Magie und ist vergleichsweise schwer zu lernen.
Das Argument, Client- und Server-Seite in der selben Sprache entwickeln
zu können, ist IMHO recht stark und könnte helfen. Allerdings befürchte
ich, eher wird es eine Lösung (Silverlight) geben, mit der man Ruby auf
dem Client machen kann, als dass JS2 fertig wird...
Post by Jochen TheodorouUnd wo wäre Ruby heute ohne Rails?
Ein Exot wie Smalltalk...
Post by Jochen TheodorouGroovy ist noch nicht sonderlich
gross, aber wir haben es immer als Teil einer Javatoolbox verkauft. Eben
um das Leben mit Java einfacher zu machen. Wir wollten es nie als das
neue Java verkaufen.
Was auch schlau ist. Dennoch: Ruby ist da sicherlich - aufgrund des
Sun-Blessing - ein großer Konkurrent. Es scheint mir, ihr habt
inzwischen die kritische Masse erreicht, dass IDE-Hersteller es als
Vorteil ansehen, Groovy zu unterstützen. Damit wird natürlich die
Sprache auch bekannter... leider finde ich sie vom Design noch
schlechter als Ruby, was auch schon zu sehr ein gequirltes Perl mit
einem Schuss Smalltalk und Python ist.
Würdest du zum Beispiel Scott Davis
Post by Jochen Theodorou(http://www.nofluffjuststuff.com/speaker_view.jsp?speakerId=18) fragen,
dann würde er dir sagen, dass er die Zukunft nicht bei einer einzelnen
Sprache, sondern bei einer Kooperation sieht.
Mit diesem Argument bin ich schon vor Jahren losgezogen und dennoch es
funktionierte schon vor 10 Jahren nicht. Warum jetzt? Weil die Welt
komplizierter geworden ist? Der 80%-Programmierer ist glaube ich froh,
wenn er eine Sprache leidlich beherrscht und ihm fehlt typischerweise
das Abstraktionsvermögen, etwa VB.NET und C# als die selbe Sprache zu
erkennen...
Post by Jochen TheodorouEben die richtige Sprache
für den richtigen Einsatzzweck. Das sieht man ja auch an der JVM zum
Beispiel.
An der JVM sehe ich nur, dass es Java sein muss. Alles andere ist ein
Krampf. Wäre die VM gut, müsste es zwei Monate und nicht zwei Jahre
dauern, eine neue Sprache wie Groovy auf die VM aufzusetzen.
Das DLR-Rahmenwerk von Microsoft ist wahrscheinlich der bislang beste
Versuch, das Implementieren neuer Sprachen zu vereinfachen, indem sie
alles, das, was es so verdammt schwer macht, die Dynamik einer modernen
Sprache auf die starre VM zu zwingen, übernehmen.
Post by Jochen TheodorouWer an Javascript2 herangeht mit dem Gedanken dass es die anderen
Sprachen verdrängen wird sollte sich meiner Meinung nach einiges an Zeit
nehmen, denn das wird es brauchen. Ich will nicht behaupten dass es
keine Chance hat, es wird wahrscheinlich nur nicht so schnell gehen...
Naja, mit "nette sprache, hat vielleicht eine zukunft" kann ich ja gar
nicht provozieren. Und selbst jetzt ist es ja nur ein Dialog zwischen
und beiden geworden :)
Post by Jochen Theodoroulangsam anfangen und sich dann beständig steigern. Ja, es ist komplexer
als Java, weil es mehr Syntax hat und weil es mehr Konzepte hat, aber
man wird halt nicht gleich ins kalte Wasser geschmissen. Wie das jetzt
bei JS2 sein wird.. keine Ahnung.
Wieso? Du kannst da alles benutzen, was du von JS1 kennst - oder von
Java. Und dann mehr lernen. Oder dich da nähern die die
20%-Programmierer und sagen, oh schick, die haben jetzt dieses und jedes
Konzept endlich auch. Sagen wir es so: Der Abstand zu Haskell wird
kleiner ;)
Post by Jochen TheodorouIch denke es kommt wirklich mehr auf das Marketing an... ich glaube zum
Beispiel das ausserhalb des Javabereichs kaum einer Groovy kennen wird.
Ist das ein langfristiges Ziel?
Post by Jochen TheodorouPost by Stefan Matthias AustIst IMHO für ein praktikables Typsystem wichtig, da es
null-Referenz-Fehler statisch vermeiden hilft.
hmm... ich stimme dir nicht zu. Muss dass denn statisch sein? Sicher...
Compilerzentrisch gedacht hat man mehr davon wenn es statisch ist, aber
das setzt auch ein Typsystem vorraus, das sich mal gerne in den
Vordergrund schiebt. Also nehmen wir mal Typ! als Notation dafür dass es
def foo(x) {bar(x)}
def bar(X! x) {1}
soll bedeuten foo bekommt ein Argument mit unbekannten Typ und ruft bar
auf, welches ein X nimmt und das argument für bar darf nicht null sein.
so die erste Frage wäre hier nun ob ein solcher Aufruf ohne das !
erlaubt wäre. in Groovy ist es das, hat das argument den falschen Typ,
gibt es eben eine MissingMethodException zur Laufzeit und gut ist.
Das finde ich verwirrend. Ich erwarte einen TypeAssertionError oder
ähnliches. Also etwas das mir sagt "hey, die Methode will einen
non-null-Wert und du hast - böse, böse - null übergeben, jetzt musst du
mit dem Laufzeitfehler leben" Aber wieso fehlt die Methode?
Wenigstens sollte dann die Fehlermeldung lauten "für die existierende
generische Funktion 'bar' finde ich leider für den Typ 'Null' keine
Methode. Es gibt nur Methoden für ...es folgt eine Auflistung aller
Methoden mit ihren Typen..."
Post by Jochen TheodorouVerständniss. Wenn ich aber einen statischen check haben will ob der
Aufruf bar(x) zuulässig ist, oder nicht, dann wird daraus nichts. Dann
muss man das prüfen. Und weil man nicht weiss was das x von foo(x) ist,
ist folglich der Aufruf bar(x) illegal...
Für mich wäre
def bar(X! x) { ... }
die Kurzform für
def bar(X x) {
assert x != null;
...
}
Ich würde das "!" definitiv nicht in den statischen Methodendispatch von
Java hineinziehen, sodass man bar(X) und bar(X!) als getrennte Methoden
haben kann. Was ginge (siehe oben), wäre bar(X:Null) und
bar(X:SomeType), doch "null" als Singleton von "Null" zu betrachen, ist
nicht Java und würde die Semantik komplett ändern und Schwierigkeiten
mit existierenden Mehoden machen.
Wichtig bei !-Annotationen ist IMHO eher, dass ich die
Standardbibliothek nachtypisieren kann, also etwa
class Object {
def toString():String!
}
damit der Compiler wissen kann, dass
def x(s: String!) {...}
x(o.toString())
immer geht und anderfalls eine Warnung oder sogar ein Fehler gemeldet wird.
Post by Jochen Theodoroukommt auf die Definition an...
Die Definition ist, dass es mehr als einen Parameter gibt, über den
dispatcht wird, also sowas:
def add(a:Int, b:Int) { a + b }
def add(a:String, b:String) { a.concat(b) }
def add(a:Int, b: String) { add(a.toString(), b) }
Post by Jochen Theodorouclass A{
def foo(x){bar(x)}
def bar(Object x){1}
}
class B extends A {
def bar(String y) {super.bar(x)+2}
}
def a = new A()
assert a.foo(new Object()) == 1
assert a.foo("String!!!") == 3
Du meinst bestimmt "new B()" denn dein A hat die zweite bar-Methode ja
gar nicht.
Was passiert bei
Object x = "String";
b.bar(x)
Ist das Ergebnis 1 (wie bei Java) oder 3 (wenn der Dispatch zur Laufzeit
ausgeführt wird)? Wenn es 3 ist, würde ich sagen, ja, das sind
Multimethoden, da sie ja zusätzlich über "this" dispatchen.
Post by Jochen Theodorousollten wir uns dazu entschliessen Generatoren wirklich zu unterstützen,
dann würden wir wohl auch yield verwenden und den Stackframe der
momentanen Funktion/Methode sichern. Den kompletten Stack brauchen wir
ja nicht, nur den einzelnen Stackframe. Dann müsste man auch keine
Threads missbrauchen ;)
Ich finde Generation (in Python) extrem praktisch. Gerade zusammen mit
comprehensions, also sowas
[a.x() for a in some_generator if 0 < a < 10]
was noch ein bisschen kompakter ist als
some_array.filter(lambda a: 0 < a < 10).map(lambda a: a.x())
und gar nicht für generatoren ohne extra itertools-Lib geht...
Post by Jochen Theodoroune, ok... ich meinte mehr... heisst das jetzt man hat sich explizit
gegen continuations entschieden und sieht das als einen Vorteil an? Und
als Grund gibt man die Effizienz an? hmm.... klingt nach einer seltsamen
Entscheidung.
Finde ich auch... daher erwähnte ich es.
Post by Jochen Theodorouden Properties ist... schon wieder ein dynamisches Element, das man
explizit aktivieren muss und sich mit der statischen Sicht beisst... Da
int x = foo.y
unter welchen Umständen compiliert das? Compiliert es wenn foo eine
"statische" Klasse hat und ein entsprechendes Property/Feld (wie auch
immer das da heisst) namens y und muss dieses y den Typ int haben, oder
kann es auch Typenlos sein?
Gute Frage. Ich würde aus dem Bauch heraus sagen, in einem strict-mode
kompiliert das nur, wenn y den Typ "int" hat (egal ob ! implizit in int
enthalten ist oder nicht). In einem anderen Modus kompiliert das mit
einem Test, der zur Laufzeit prüft, dass y bitte keine null oder
undefined (was es auch noch in JavaScript gibt) enthält und wirft einen
entsprechenden Fehler, also etwas wie
let x:int = assert_int(foo.y)
mit
function assert_int(x:*):int {
if (x === null) throw TypeAssertionError("must not be null");
if (x === undefined) throw TypeAssertionError("must exist");
return x;
}
Post by Jochen TheodorouCompiliert es auch wenn foo eine dynamische
Klasse hat und kein Feld/Property y?
Ja. Denn foo.y ohne y ist undefined.
Post by Jochen TheodorouOder wenn es eines hat, muss das
dann ein int sein? Kann man in einer dynamischen Klasse ein vorhandenes
Feld "überschreiben"? usw.
Ja. Du kannst folgendes machen:
a.foo = 4;
a.foo = function() { ... }
a.foo()
a.foo = Foo
new a.foo
das macht die Sprache ja gerade so schick :)
Ein pragmatischer Ansatz ist wahrscheinlich der von Python 3k. Die
erlauben, wenn ich's richtig verstanden habe, dass man jetzt
def foo(a:int, b:str) as Foo:
...
schreiben kann doch alles, was da passiert ist, dass int, str und Foo
jetzt im Funktionsobejekt abgelegt werden, sodass man zur Laufzeit
darauf zugreifen kann. Es ist also einfach eine zusätzliche Annotation.
Wer jetzt eine statische Typprüfung haben will, schreibe sich etwas,
dass den AST abläuft und Dinge und Sachen macht. Wer Typprüfung zur
Laufzeit haben will, schreibe sich z.B. sowas:
@strict
def foo(a:int, b:str) as Foo:
...
und "strict" ist eine Funktion, zur Übersetzungszeit von foo aufgerufen
wird und dort eine weitere Funktion wrappt, die dann folgenden Effekt hat:
def foo(a, b):
check(a, int)
check(b, str)
...
return check(..., Foo)
Der eigentliche Interpreter ist so gut wie gar nicht aufwendiger
geworden, das Laufzeitsystem schleppt ein paar Referenzen auf Typen mehr
mit sich herum und jeder kann sich bauen, was er möchte. Was damit auch
geht, sind natürlich Multimethoden
@multimethod
def add(a:int, b:str)
@multimethod
def add(a:str, b:int)
Die Funktion "multimethod" muss jetzt "add" derart wrappen, dass es
Methoden in einer generischen Funktion werden und diese muss ungefähr so
aussehen:
class GF:
def __init__(self): self.methods = []
def __add__(self, func): self.methods.append(func); return self
def __call__(*args):
atypes = (type(a) for a in args)
def match(mtypes): ...
for m in self.methods:
if match(m.types, args): return m(*args)
wobei match prüfen kann, ob die Typen der Methodenparameter auf die
Typen der Argumente passen. Leider ist das nicht ganz so einfach, da man
die speziellste Methode finden muss und nicht nur eine, die passt.
Dieser Algorithmus ist wohldokumentiert, doch ist kenne ihn nicht
auswendig und werde ihn jetzt nicht suchen.
Außerdem haben das Python-Entwickler schon mehr als einmal gebaut :)
Post by Jochen TheodorouGeschmack entspricht. Wenn das wirklich so wäre, dann wird man pausenlos
zu statischer Programmierung gezwungen.... dann hätten sie die
dynamischen Teile auch gleich ganz rausschmeissen können, denn das mit
dem "optionale Typen" ist dann nur ein Alibi.
Ich glaube, es ist letztlich ein ganz oder gar nicht. Nur 100% statische
Typisierung garantiert keine Typfehler zur Laufzeit. Es ist eher so,
dass man beiden Gruppen von Entwicklern etwas bieten möchte. Die einen
können statisch typisieren (und sich einschränken) und die anderen
können es lassen (und mit dem Risiko von Exceptions zur Laufzeit leben).
Post by Jochen TheodorouPost by Stefan Matthias AustNein, ich meinte, AS3 als Quelle und daraus erzeuge ich dann Java. Statt
anders herum wie ich mir ursprünglich dachte.
äh... ja... ich meinte Javaquelltext erzeugen, oder irgendwas was
"direkt" auf der JVM läuft, also Bytecode ;)
Java wäre wohl einfacher, weil man das besser debuggen kann. Muss dann
ggf. bei jump und so aber mit fiesen label-Tricks arbeiten.
Post by Jochen TheodorouPost by Stefan Matthias AustWäre mir persönlich nicht wichtig, ist aber wahrscheinlich interessant.
Rhino kann's ja auch. Daher würde ich diese Integration als prinzipiell
gelöst betrachten :)
was kann Rhino?
Mit Java interagieren.
Ich glaube allerdings, ich hatte dich nicht richtig verstanden und nicht
geschaltet, dass du Annotationen meintest. Ich denke, die gehen nicht,
weil Rhino eher stiefmütterlich gepflegt wird und die noch nicht bei
Java 1.5 angekommen sind... so traurig...
Post by Jochen TheodorouPost by Stefan Matthias AustIch sprach von dem JIT der Flash-VM und klagte, dass ich für Flash (also
AS3) keinen Interpreter schreiben kann, der zur Laufzeit Bytecode (ABC)
erzeugt, der dann ge-JIT-et wird. Bei Java geht das ja durch geschickten
Einsatz von ClassLoadern.
achso.... halt ne... was hat das mit ClassLoadern zu tun?
Na ohne ClassLoader kein dynamisches Nachladen von Code zur Laufzeit.
Post by Jochen TheodorouIch denke Flash wird wie üblich daran kranken, dass Adobe die Tools
nicht freigeben will und auch versucht das Basteln neuer Tools durch
andere zu verhindern (Lizenz und Patente). Zu Silverlight gibt es
immerhin schon Plugins für Firefox und es gibt Moonlight für Linuxer.
Wie lange wird Novell Microsoft das Plattform-übergreifend-Alibi
bescheinigen, wenn sie davon nix haben. Silverlight ist ja die Angel für
WPF und damit Vista und damit wieder Windows-only. Eigentlich kann es
Microsoft nicht recht sein, wenn das Betriebssystem egal wird.
Post by Jochen TheodorouWenn es jetzt noch eine alternative freie Entwicklungsumgebnug geben
wird, dann sieht die Zukunft für Flash schlecht aus meiner Meinung nach.
Du kannst heute mit Flash machen, worauf die bei Silverlight noch
wartest. Es gibt fertige VMs für Windows, Linux und Mac, es gibt gute
kommerzielle und einge okay-IDEs in frei. Mit Flex kannst du heute mit
IDEA anfangen, Code zu schreiben. Der ganze Flex-Code ist einsehbar und
irgendwann auch opensource. Die VM ist spezifiert und es gibt eine
Referenzimplementierung.
Was du nicht hast, ist die Grafikengine von Flash aber die wirst du bei
Silverlight auch nicht bekommen. Flash kann nur JavaScript und
ActionScript - das aber Browserübergreifend identisch und Silverlight
nutzt das JavaScript des Browsers. Irgendwann kann Silverlight auch
Python und Ruby und C#, gleiches wurde prompt für Firefox auch
angekündigt (aber das ist AFAIK noch eine reine Luftnummer). Bei
Microsoft musst du die IDE VS2008 ebenfalls kaufen - kostenlose
Alternativen sind Magelware.
Post by Jochen TheodorouIch denke allerdings JavaFX hat dann im Bereich Mobiltelefone noch
Chancen denke ich... wie lange weiss ich aber nicht. Flash wird
sicherlich auch nicht einfach verschwinden.... die Vor- und Nachteile
kommen ja erst so nach und nach hoch...
Das iPhone ist bereits so mächtig, das hat kein spezielles Phone-OS
(Symbian, die ganzen propriäteren System wie Series 40 und was es sonst
noch so gibt) und Motorola selbst auf Linux - da kann man dann auch
einfach existierende Sprachen portieren und braucht keine gekrippelten
Java-Versionen mehr...
--
Stefan Matthias Aust