Re: Java -> ActionScript?

Jochen Theodorou schrieb:

[Adobe und Flash]

ahh, ok, verstehe. Wenn die jetzt noch Alternativen zu ihrem Player
erlauben ;)

Das Gnash-Projekt versucht eine Clean-Room-Implementierung zu liefern.
Sind allerdings "nur" auf Flash-7-Niveau. Gab es nicht auch mal einen
Flash-Player in Java? Außerdem enthält Squeak-Smalltalk einen Player,
allerdings für Flash-5 oder so. Wie legal diese Player sind: Keine
Ahnung. Wenn man sich jedenfalls von Adobe die SWF-Spec zieht, liest
man: "his license does not permit the usage of the specification to
create software which supports SWF file playback."

Man findet zwar auch genug Informationen für SWF im Netz (z.B.
http://www.digitalpreservation.gov/formats/fdd/fdd000248.shtml) doch
Adobe könnte natürlich immer noch die Patent-Keule ziehen...

Aber was wäre besser, wenn jeder einen Player bauen könnte? Gäbe es dann
etwas besseres als Flash-7 für die Wii? Oder einen in Java geschriebenen
Flash-9-Player? Solange der Player von Adobe kostenlos ist, ist das
alles nicht so schlimm. Und Geld dafür werden sie nicht nehmen, sonst
könnten sie sich gleich einsargen. Dann hätte Microsoft gewonnen.

Warum glaubst du sollte JS2 in der
Lage sein Java zu verdrängen?

Nein, nicht Java, sondern andere Scriptsprachen für Java.

du meinst andere Skriptsprachen auf der JVM. Bleibt abzuwarten wie
erfolgreich das sein wird.

Ja, ich meine JVM :)

Weil Ruby einen überraschenden Erfolg nur Rails zu verdanken hat.

Das mag schon sein, Java hat seinen überraschenden Erfolg auch nur den
Applets zu verdanken ;)

Jein. Wenn's Java dank guter Socket-Bibliotheken und der Einfachkeit,
Server zu bauen nicht auf diese Seite geschafft hätte, wäre die Sprache
heute nur noch Geschichte.

in Groovy könnte man folgendes haben:

http.send { foo(name) }

Was ich bei den Buildern nicht verstehe - wie funktioniert das Binden.
Ich vermute, {} ist eine Closure, die auch freie Variablen haben kann.
Dies liefert z.B. 5 (falls ich die Syntax richtig treffe):

def a(c) { return c.call() }
def n = 5
pprint (a { n })

Was würde bei deinem Beispiel da oben passieren, wenn ich foo als freie
Variable in dem Block { foo(name) } habe. Ich hätte gedacht, der Builder
funktioniert mit Hilfe eines "undefined method" Hooks, aber das kann es
nicht alleine sein.

doc."**name" { it."@staff" == "true" }

Offenbar kann man auch Strings und nicht nur Namen hinter dem "."
benutzen, wo mir die Bedeutung gar nicht klar ist. Ich hätte gedacht,
"." wird wie bei Java zu Übersetzungszeit gebunden. Offenbar ist es aber
nur wie bei JavaScript eine andere Syntax für [[getproperty]].

Hätte ich auch

doc["**name"] { it["@staff"] == "true" }

schreiben 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.

Viele builder sind in Java geschrieben, ich denke das qualifiziert das
als Builder ;) Bei GPath ist es im wesentlichen das gleiche.

Aber das ist entgegengesetzt zu meinen Punkt. Wenn die Builder nur
funktionieren, wenn man sie in Java schreibt, ist es Magie. Wenn man sie
in Groovy schreiben könnte dann wäre es so wie ich es mir wünsche - ein
Zeichen für eine ausdrucksstarke Sprache. In Ruby geht das ja, vgl. Markaby.

nunja, ich sprach von den Leuten, die es zu den Skriptsprachen zieht.

Die Unterscheidung ist IMHO eh willkürlich. IMHO sollte es zu
ausdrucksstärkeren Sprachen gehen. Java ist das nicht gerade. Groovy
bessert hier nach. Andere Sprachen wie Python oder auch Ruby sind eh
schon deutlich ausdruckstärker. Wobei ich hier wieder die Sprachen -
siehe oben - mit einem kleinen Kern vorziehe. Der Kern von Python ist
z.B. viel kleiner und viel regelmäßiger als der von Ruby, das von
Ausnahmen und Sonderfällen nur so wimmelt. Bei Groovy habe ich das
Gefühl - und daher bin ich leider kein so großer Fan davon - das ist
noch extremer als bei Ruby, weil man so nah an Java sein will wie
möglich und trotzdem besser.

Groovy is kein komplettes Superset von Java. Semantsich gleich garnicht,
syntaktisch stimmt es bis auf Kleinigkeiten. Python wäre mit einer mehr
C-Syntax IMHO viel erfolgreicher gewesen.

Geschweifte Klammern werden total überbewertet. Ich finde es total
befreiend, Python machen zu können. Wer eine Sprache nur dann versteht,
wenn sie geschweifte Klammern hat ... ach, ich spar's mir...

Und Scheme... die Syntax mag
ja einfach sein, aber ich habe auch gelernt, dass etwas nur dann
wirklich gut ist, wenn man auch die Grenzen erkennen kann. Und das ist
bei Scheme nun wirklich nciht gerade leicht. Die sprache ist einfach zu
flexibel.

Da stimme ich dir zu. Konzeptionell toll, aber manchmal ist es schon
schön, wenn ein bisschen Syntax aus dem Code zur Orientierung
heraussticht. Die Syntax sollte jedoch das Programm nicht begraben. Wenn
ich einen 5-Zeiler brauche, nur um ein "map" oder "collect"
auszudrücken, dann nervt das genau wie zu wenig Syntax.

es unterstützen und b) weil man es verwenden kann ohne es wirklich zu
verstehen.

Das kann man mit fast jeder Sprache :)

Bei manchen scheitert man dann aber schon an der ersten komischen
Fehlermeldung des Compilers und nix läuft. Bei JavaScript bekommt man's
jedenfalls zum Zucken und die Sprache ist recht verzeihend.

Vergiss die Hobby-User, die irgendwas mit JavaScript irgendwie
zusammenfummeln.

Die bleiben aber nicht alle Hobbyuser

Dennoch zielt JS2 nicht auf diese Gruppe. Und: Bei den meisten wäre es
besser, sie bieben es :)

Die Sprache ist IMHO wichtig, weil man versucht, immer
komplexere Webanwendungen im Browser zu realisieren und da kommt man
eben nicht um JavaScript herum.

gibt es dafür nicht Codegeneratoren und Bibliotheken? Meinst du wirklich
das schreiben viele selbst?

Ja. Siehe z.B. Extjs. Warum auch nicht. JavaScript ist eigentlich eine
recht elegante Sprache und es macht IMHO Spass, damit was zu machen.

Ich hatte spaßeshalber mal ausprobiert, wie man einen AST zum Auswerten
von Programmen in JS realisieren könnte und fand meine Lösung mit
Konstruktorfunktionen für eval-Funktionen schick:

function Lit(v) {
return function(env) { return v; }
}
function Var(n) {
return function(env) { return env[n]; }

function Add(e1, e2) {
return function(env) { return e1(env) + e2(env); }
}

Add(Var("a"), Lit(4))({a: 3})

Kannst du in Groovy oder Python genauso machen - aber nicht in Java. Was
ich ein bisschen schade finde ist, dass ich [] nicht überschreiben kann.
Das hat Python vor 16 Jahren schon besser gelöst.

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.

gut, kann ich verstehen. Aber mich interessiert eher die Nutzung dieser
Bibliotheken.

Da helfen Typen doch auch. Denk an Code Completion in der IDE.

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.

ah, ok, also wird sich für die meisten nicht wirklich was ändern...
Natürlich wird JS2 dann eine Menge Altlasten mitbringen....

Die Last der Rückwärtskompatibilität...

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.

also bist du gegen Programming by Convention?

Ich bin gegen Programming by Magic. Es kommt auf die richtige Menge an.
Ist schwer genau zu sagen, was zu viel ist und was geht. Bei Rails gibt
es häufig drei oder mehr Wege, etwas auszudrücken. Das fängt bei Ruby
schon an, dass man auf mindestens 4 Wege etwas zurückgeben kann:

if cond then return 1
return 1 if cond
unless not cond; return 1; end
1 unless !cond

Usw. Mag für den Schreiber nett sein, hier seine Kreativität auszuleben,
aber als Leser muss man alle Varianten kennen, um das Programm zu
verstehen. Das kann es unnötig schwer machen, auch wenn die
verschiedenen Versionen eigentlich die Lesbarkeit erhöhen helfen sollen.

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...

warum?

Weil Microsoft schneller sein wird bzw. Mozilla/Adobe zu langsam. Wie
gesagt, für Ende 2008 ist die JS2 Spec angekündigt und dann muss Mozilla
das noch in den Firefox einbauen, denn die Referenzimplementierung in
Standard-ML werden sie nicht integrieren sondern wahrscheinlich
Spidermonkey und Tamarin irgendwie verheiraten - beides C-Programme.

Möglicherweise könnte man da was mit PyPy machen. Ich hatte da gerade
ein paar Papers gelesen. PyPy ist der Versuch, einen Python in Python zu
schreiben und damit das Ergebnis effizent läuft, kompilieren sie
letztlich in eine Niedrigsprache, z.B. C oder Bytecode für .NET, JVM und
die LLVM. Da es komplexes Python zu schwer ist, effizient zu
kompilieren, gibt es RPython (R=Restricted), ein Subset, welches sich
effizient übersetzen lässt. Quasi ein C oder Java mit der Syntax von
Python.

Der interessante Unterschied ist jedoch, sie haben das normale Python,
um erstmal das RPython-Programm zu schreiben (ich erwähnte letztes Mal
ja schon so Metaprogrammierung für Multimethoden, die Python beherrscht)
und all sowas kann man nutzen.

Die Macher ziehen daher von Konferenz zu Konferenz und preisen ihr
System als ideale Basis für diverse Sprachen an, denn natürlich kann man
damit nicht nur Python übersetzen. Ich meine, es gibt einen JavaScript,
Scheme und Prolog-Interpreter als PoC und gerade diese Tage läuft (oder
lief) ein Sprint, die Squeak-VM in Python zu bauen, um sie dann mit PyPy
zu übersetzen.

Finde ich total spannend :)

Das schicke ist wie gesagt, wenn's einmal in Python existiert, können
sie auf .NET und JVM und LLVM (und damit diverse andere OSes)
übersetzen. Das JVM-Backend ist aber wohl leider rudimentär. Man hat
sich (sicherlich, um Aufmerksamkeit und Fördergelder von Microsoft zu
bekommen) auf .NET konzentriert wie es aussieht.

Ich denke das ist Ansichtssache. Das Ziel war besser als Java zu sein,
nicht schön zu sein ;)

Falsches Ziel, wenn du mich fragst. Bzw. falsche Reihenfolge. Ich will
beides: Eine elegante Sprache die auch noch besser ist als Java.

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.

ich denke wenn ich heute eine fertig spezifiziete Sprache auf die JVM
umsetzen müsste, dann würde ich das vielleicht nicht in 2 Monaten
schaffen, aber 2 Jahre bräuchte ich sicher nicht. Kommt auch darauf an
was die Sprache können soll und ob es eine fertige Grammatik gibt. Aber
es ist nunmal was anderes wenn du eine Sprache fortwährend
weiterentwicklest, diskussionen zu führen hast wie das und das zu
funktionieren hat usw.

Ich hatte ja JS2 angeboten ;)

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.

Solange das Framework meinen Bedarf abdeckt ist alles bestens. Und die
Infrastruktur hilft sicher auch schneller zu einem Ergebnis zu kommen.
Aber meistens sind es all die kleinen Details, die dann doch einen
Strich durch die Rechnung machen. Zum Beispiel, nehmen wir an deine
Sprache unterstützt eine Methoden mit einer variablen Anzal von
argumenten als ersten Parameter. Und nehmen wir an deine VM tut das
auch.... nur leider als letzten Parameter. Pech gehabt.

Du hast im Prinzip recht, aber da Microsoft die DLR aus IronPython
ableitet und auch sicherstellt, das JS und Ruby damit gehen, ist schon
recht viel abgedeckt. Spannend wäre vielleicht noch, etwas wie Erlang
auszuprobieren oder gleich Prolog, aber eigentlich würde ich da wenig
Probleme erwarten.

Semantik sowieso dahin. ich ahtte mir überlegt sowas zu machen:

def bar(NullObject o) {...}

NullObject gibt es schnon, aber bisher nur um Methoden auf null
auszuführen, nicht um einen Methodenparameter zu matchen.

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.

stimmt... wie macht das Scala?

Scala kennt keine non-null-Typen (falls sie das nicht geändert haben)
aus Kompatibität zu den Hostsprachen JVM und CLR.

das meinte ich weniger, wenn man mal die casts ausblendet und mit Object
arbeitet geht das ja schon fast in Java so.... nicht dass die Casts
unwichtig wären ;) Nein, ich meinte, dass wenn du ein Feld in der Klasse
A hast und die Klasse A ist dynamisch, hat aber ein Feld als Tiel der
Klassendefinition... also

dynamic class A {
foo:int
}

oder so ähnlich.... ob man diesem foo neue Logic geben kann, sodass es
es zum Beipsiel auch Strings nimmt, statt nur ints.

Weiß ich nicht. Ich hoffe, man kann's nicht ändern und foo nicht
überschreiben. Sonst wird's extrem komisch.

was mich bei einer Skriptsprache hier halt stört ist das Laufzeit und
Compilezeit ja miteinander verschmelzen.

Seit Jahren sage ich ja schon, es sollte den Unterschied zwischen
Laufzeit und Compilezeit gar nicht geben. Das ist künstlich und
verhindert Metaprogrammierung.

Allerdings ist es wie so oft auch nicht die Qualität, die darüber
entscheidet wleches System benutzt werden wird. Manchmal geht es nur
darum zur richtigen Zeit am richtigen Ort zu sein. So ungerecht das auch
sein mag. Allerdings fällt es mir schwer zu glauben das Flash komplett
von Silverlight verdrängt wird... selbst wenn Silverlight relatic
erfolgreich sein würde.

Wenn Youtube auch Silverlight statt Flash für das Anzeigen von Videos
unterstützen würde, dann hätte Microsoft eine Chance. Diese Plattform
ist IMHO ein wesentlicher Grund, warum jeder Flash installiert und meist
auch aktiviert hat.

--
Stefan Matthias Aust
.

Relevant Pages

  • Re: Problem with processing XML
    ... I had a discussion with Java people lately and they were all for Ruby, ... Python is easy to learn, ... So, there is a learning curve, but it's much shorter than what you already ...
    (comp.lang.python)
  • Re: Why Ruby over Python?
    ... >> why you might prefer ruby. ... Someone there said that Python is more like Java ... I have learned many programming languages in the last two years ...
    (comp.lang.ruby)
  • Re: Why Ruby over Python?
    ... Someone there said that Python is more like Java ... and Ruby is more like Smalltalk. ... I have learned many programming languages in the last two years ...
    (comp.lang.ruby)
  • Re: iniziare a programmare
    ... studiare python o ruby (anche se ora vorrei leggere qualcosa su python, ... javascript(ma quest ultimi non sono utili al fine del post) ... Ruby si accorge immediatamente di cosa intendo quando voglio dire che ... Java è macchinoso. ...
    (it.comp.macintosh)
  • Re: why is "self" used in OO-Python?
    ... When you define a method in Java there is an implicit 'this' passed to the ... Python cannot tell when you define a function whether the function ... Some languages don't allow you to encapsulate ...     def phone: ...
    (comp.lang.python)