ACHTUNG. Das ist ein Archiv des alten forum.ruby-portal.de. Die aktuelle Mailingliste gibt es auf lists.ruby-lang.org/pipermail/ruby-de.

NOTICE. This is a ready-only copy of the old forum.ruby-portal.de. You can find the current mailing list at lists.ruby-lang.org/pipermail/ruby-de.

Die Programmiersprache Ruby

Blog|

Forum|

Wiki  


Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]

Ein neues Thema erstellen Auf das Thema antworten  [ 38 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 12:56 
Offline
Geselle

Registriert: 22 Feb 2005, 13:38
Beiträge: 129
Wohnort: Berlin, Lyon, Europa und Welt
DanielBovensiepen hat geschrieben:
Ansonsten sei noch die Plattformunabhängigkeit erwähnt. Seien wir mal ehrlich, Ruby ist nunmal nicht wirklich Plattformunabhängig.

Aber Java ist es oder was? Im Gegenteil, Java braucht seine eigene Plattform. Plattformunabhängig ist sowas wie C++. Java/.NET sind das nicht.

_________________



self.vote :berlingruen
· http://gruene-berlin.de/


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 13:08 
Offline
Böser Admin
Benutzeravatar

Registriert: 29 Jul 2005, 22:41
Beiträge: 2065
Wohnort: Beijing
Konrad L. M. Rudolph hat geschrieben:
DanielBovensiepen hat geschrieben:
Ansonsten sei noch die Plattformunabhängigkeit erwähnt. Seien wir mal ehrlich, Ruby ist nunmal nicht wirklich Plattformunabhängig.

Aber Java ist es oder was? Im Gegenteil, Java braucht seine eigene Plattform. Plattformunabhängig ist sowas wie C++. Java/.NET sind das nicht.

Also ich möchte hier jetzt nix lostreten. Aber auch für die einzelnen Plattformen brauchst du einen Compiler. Und die Standardlibs werden meisst auch ein *kleines* bisschen anders auf einer 64- oder 32-Bit Plattform implementiert. Jetzt stellt sich natürlich die Frage was nun wirklich Plattformunabhängig ist. Und schlußendlich kann ich sagen, ich kann Produkt X (egal ob in Java oder C++ geschrieben) nicht ohne weiteres auf jeder erdenklichen Plattform laufen lassen. Ein in purem Java geschriebenes Programm läuft aber erfahrungsgemäßer auf mehr Plattformen als ein in C++ geschriebenes, aber halt nicht auf allen (da gebe ich dir recht). Plattformunabhängigkeit existiert nicht *ohMeinGott* :D



der
Daniel

_________________
mruby.sh | Ruby-Mine | Homepage


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 13:41 
Offline
ri
Benutzeravatar

Registriert: 04 Okt 2005, 10:42
Beiträge: 740
Wohnort: Wien
Doch!

In Form von Webanwendungen, die in einem Browser ablaufen :lol:
Ist für den Client im Endeffekt so etwas wie Plattformunabhängig.

Mir ist schon klar, dass diese Aussage nicht ganz zu beweisen ist, aber ich denke in diese Richtung wirds in Zukunft rauslaufen.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 15:54 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
DanielBovensiepen hat geschrieben:
Ansonsten sei noch die Plattformunabhängigkeit erwähnt. Seien wir mal ehrlich, Ruby ist nunmal nicht wirklich Plattformunabhängig.

Ruby 2.0 (yarv?!) soll das doch genau werden, sonst macht eine virtuelle Maschine ja auch nicht allzu viel Sinn.

Gekko hat geschrieben:
In Form von Webanwendungen

Dann werden also nutzerspezifische Daten zwischen User-Interface (=Browser o.Ä.) und Anwendung (=irgendein Web-Service) übertragen.

Wie sähe denn das aus, wenn die Webanwendung ein Ruby-Interpreter ist und die Daten ein Ruby-Programm. Darum geht es doch in der Programmierung.

Dann würde das eigene Programm irgendwo im Netz ablaufen und wäre selber wieder eine Web-Anwendung.

Es müsste dann aber die Ruby-Webanwendung (=der angebotene Interpreter) auf allen Anbieterplattformen gleichartig laufen, da ansonsten meine Programme unterschiedlich ausgeführt werden würden, ich also auf einen ganz bestimmten Service-Typ beschränkt wäre.

Es würde sich also auf den ersten Blick für Ruby-Programmierer nichts ändern.

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 16:04 
Offline
Böser Admin
Benutzeravatar

Registriert: 29 Jul 2005, 22:41
Beiträge: 2065
Wohnort: Beijing
WoNáDo hat geschrieben:
DanielBovensiepen hat geschrieben:
Ansonsten sei noch die Plattformunabhängigkeit erwähnt. Seien wir mal ehrlich, Ruby ist nunmal nicht wirklich Plattformunabhängig.

Ruby 2.0 (yarv?!) soll das doch genau werden, sonst macht eine virtuelle Maschine ja auch nicht allzu viel Sinn.

Ist dies denn wirklich so? Ich bin immer noch der Meinung aus den bisherigen Informationen herauszulesen, dass gerade YARV deshalb ausgewählt wurde, weil damit der aktuell vorhandene Interpreter nur gepatcht wird. Soll heissen an der Interpreterbasis wird überhaupt nix geändert und so wird auch die POSIX abhängigkeit weiter bestehen. YARV verstehe ich im Moment nur als Booster für Ruby, nicht etwa als eine neue Laufzeitumgebung. Außerdem empfinde ich die Definition einer virtuellen Maschine als solche doch ein wenig sehr plump. Der Ruby Interpreter kann genauso als virtuelle Maschine angesehen werden, welche halt keinen primitiven Byte- bzw. Wordcode verarbeitet sondern eine hohe Sprache. Aber diese Diskussion hatten wir ja schon etwas früher. Von dorther sollte man nicht soviel in diese *Wundertechnik* VM hineinzwängen.



der
Daniel

_________________
mruby.sh | Ruby-Mine | Homepage


Zuletzt geändert von DanielBovensiepen am 24 Jul 2006, 22:05, insgesamt 1-mal geändert.

Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 24 Jul 2006, 21:27 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
DanielBovensiepen hat geschrieben:
YARV verstehe ich im Moment nur als Booster für Ruby, nicht etwa als eine neue Laufzeitumgebung.

Schade, wäre eine gute Gelegenheit etwas OS-Unabhängigkeit zu erreichen.

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 29 Jul 2006, 09:24 
Offline
Geselle

Registriert: 06 Jul 2006, 09:54
Beiträge: 149
WoNáDo hat geschrieben:
sma hat geschrieben:
Das [Parsen in einen AST] ist ein konstanter Aufwand einmal beim Einlesen des Quelltexts und kann daher IMHO für Performance-Betrachtungen ignoriert werden.
Wie sähe denn das aber für echt interaktives Ruby aus, also etwas, was jetzt rudimentär mittels irb existiert.

Ich halte den Zeitbedarf, gerade in einer interaktiven Bedienung, wo du niemals so schnell tippen kannst, wie der Computer deine Eingaben verarbeiten könnte, nach wie vor für vernachlässigbar. Wenn's eine Sekunde dauert, die Eingaben zu verarbeiten, dass ist das schon sehr, sehr lange. Ein moderner Prozessor kann in dieser Zeit bis zu 2 Milliarden Instruktionen ausführen - wahrscheinlich geht es sehr viel schneller, ein typisches Quelltextstück zu verarbeiten.

WoNáDo hat geschrieben:
So etwas gibt es ja auch bei anderen Sprachen (echt funktionale nicht, da verbietet das Paradigma ja Änderungen) - wie sehen denn da Erfahrungen aus mit der Portierung zu .NET oder auf die Java-VM aus (mich interessieren jetzt aber nicht eingeschränkte Sprachen).

Es gibt zwei Ansätze: Man kann einen Interpreter für die Sprache in einer .NET-Sprache oder in Java schreiben und dadurch diese neue Sprache portieren, oder man kann versuchen, einen Compiler für die Sprache in den Maschinencode der JVM bzw. .NET VM zu schreiben und dann die class files bzw. assembly zu laden und auszuführen.

Der Interpreteransatz funktioniert ohne weitere Probleme und in beiden Welten wahrscheinlich gleich gut, wenn es darum geht, per reflections an existierende API-Funktionen zu kommen. Er versagt zwangsläufig, wenn man erlauben möchte, Unterklassen existierender API-Klassen zu bauen oder in einer .NET-Sprache oder in Java Unterklassen von Klassen in der neuen Sprache zu bauen. Manchmal ist das aber auch nicht wichtig, etwa wenn die neue Sprache keine Klassen kennt.

Der Bytecode-Compiler-Ansatz würde Vererbung über Sprachgrenzen erlauben, ist aber nicht mehr so dynamisch wie der Interpreter-Ansatz. In Java geht's noch recht gut, weil dort ClassLoader dynamisch neue Klassen laden können und Klassen automatisch wieder garbage collected werden, wenn der ClassLoader und die Klasse nicht mehr referenziert werden. Die Klasse wird nicht mehr referenziert, wenn es keine Exemplare davon mehr gibt. Man kann jedoch nicht in Java existierende Klassen bzw. deren Exemplare ändern. Bei .NET - so habe ich mir sagen lassen - kann man nicht ganz so dynamisch wie in Java Klassen nachladen, doch man kann wohl im Hauptspeicher assemblies zusammensetzen und dann über eine neue Appdomain o.ä. einlesen ... ich meine mich aber zu erinnern, dass man diese dann nicht mehr so einfach wieder aus dem Speicher rausbekommt. Man müsste man schauen, wie IronPython das macht.

Die portierung als Interpreter wäre damit einfach und das ist der Weg, den JRuby z.B. geht. Groovy hingegen geht den Compiler-Weg unter Java. Rhino (ein JavaScript) beschreitet beide Wege. Alle Sprachen bieten eine interaktive Kommandozeile. Und es gibt auch BeanShell oder SISC oder Pnuts und eine reihe weiterer mehr oder weniger fertiger Sprachen.

DanielBovensiepen hat geschrieben:
Hierdrauf aufbauend denke ich, dass die größte Bedeutung von JRuby oder Ruby.net die ist, das über Ruby im allgemeinen nochmal reflektiert wird. Es werden mehr Testfälle geschrieben die Ruby noch weiter abdecken und es werden eventuelle Designfehler entdeckt.

Ich denke, das ist ein guter Punkt. Nur was würde man machen, wenn man Designfehler entdeckt? Einfach ändern? Dann würden wahrscheinlich viele Ruby-Anwender protestieren. Und je beliebter die Sprache, desto mehr Code existiert auch... Ein Design-Fehler ist IMHO zum Beispiel, dass Ruby nicht von Anfanga an Unicode-fähig war.

Ich denke übrigens nicht, dass es Ziel sein sollte (oder sein kann), dass eine .NET oder Java-Implementierung 100% kompatibel in dem Verhalten zu CRuby ist. Wäre zwar schön, ist aber glaube ich ein Traum. Es reicht aber IMHO, wenn man zumindest die bekannte Syntax benutzen kann, um damit gegen eine andere - hoffentlich zumindest ähnliche - Klassenbibliothek zu arbeiten.

WoNáDo führte an, dass reguläre Ausdrücke etwa nicht kompatibel wären. Hier denke ich, sollte man eher damit rechnen, dass jeweils die Engine der unterliegenden Plattform benutzt wird. Obwohl - wenn Ruby seine eigene hat - könnte man die natürlich portieren.

Stefan


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 29 Jul 2006, 11:11 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
sma hat geschrieben:
Ich halte den Zeitbedarf, gerade in einer interaktiven Bedienung, wo du niemals so schnell tippen kannst, wie der Computer deine Eingaben verarbeiten könnte, nach wie vor für vernachlässigbar. Wenn's eine Sekunde dauert, die Eingaben zu verarbeiten, dass ist das schon sehr, sehr lange.

Schön wäre es, aber Laufzeiten im längeren Minutenbereich (im Extremfall sogar Stunden) sind bei meinen Anwendungen der Normalfall. Allerdings sind das wirklich Extremanwendungen im Bereich Textanalyse.

sma hat geschrieben:
Es reicht aber IMHO, wenn man zumindest die bekannte Syntax benutzen kann, um damit gegen eine andere - hoffentlich zumindest ähnliche - Klassenbibliothek zu arbeiten.
...
WoNáDo führte an, dass reguläre Ausdrücke etwa nicht kompatibel wären. Hier denke ich, sollte man eher damit rechnen, dass jeweils die Engine der unterliegenden Plattform benutzt wird.

Für mich wäre Ruby, sollte es so einen Weg gehen, gestorben und ich würde auf der Stelle beginnen wieder zu Python zu wechseln.

Mein Kapital liegt in den Daten (=Analysehilfsbibliotheken). Die sollen weiter verwendbar sein.

Mag sein, dass hier ein versus-Knackpunkt zwischen Anwendungen im EDV-Bereich und Anwendungen im Internet-Bereich existiert. Als Anwender im EDV-Bereich hätte ich natürlich am liebsten eine Weiterverwendbarkeitsmöglichkeit wie von IBM durch JCL und die Binärformate garantiert (habe selber mal erlebt, dass ein 1969 übersetztes und gebundenes Binärprogramm vom Band 15 Jahre später an einer Nachfolgemaschine mit den gleichen Lochkarten problemlos lief).

Bei Internet-Anwendungen müssen dagegen neue Möglichkeiten schnell verfügbar sein, während der Schnee von gestern niemanden mehr vom Hocker reisst.

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 38 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
cron