Post by llotharPost by UlrichWelche Version?
Die Spracherweiterung von Version 2.x werden von keinem anderen Übersetzer unterstützt.
Also ich hatte mir mal Component Pascal angesehen, damit könnte ich
leben.
Das ist natürlich auch eine ausgezeichnete Sprache. Eine automatische Speicherreinigung ist eingebaut, die Quellen sind offen
und eine Linux-Version ist im Ofen, aus der sich relativ leicht auch eine für MacOS X gewinnen lassen sollte.
Bei MacOS X steht noch Intel dabei - ist diese Version von MacOS X wirklich schon auf dem Markt? Wenn nicht, wird es wohl
schwierig sein, ein Entwicklungssystem dafür zu bekommen.
Meines Wissens verwendet Component Pascal aber einen eigenen Speicherreiniger und bietet auch kaum Generizität - jedenfalls
nicht in dem Umfang wie die als experimentell gekennzeichnete Generizität von OO2C V2.
Post by llotharPost by UlrichPost by llothar- Is Available on Linux (PPC+Intel), MacOSX (PPC+Intel), WinXP
- Uses the Boehm Weisser GC and not a questionable own implemenation.
Das scheint mir eine ziemlich seltsame Bedingung zu sein. Gibt's dafür eine
Begründung?
Na ja einen portablen generational GC der multithreading gut
unterstützt schreibt man nicht einfach so. Das was ich bisher in
anderen Sprachen als implementierung gesehen war, war schlicht übel
schlecht und buggy. Ich muss u.U. mehrere hundert MByte (in 20-30
Millionen Objekten) an aktiven Daten im Speicher halten können.
Verstanden - es geht also um die Leistungsmerkmale.
Ich hab den Speicherreiniger von Component Pascal nicht studiert, aber denjenigen von der ETH. Ich vermute, dass derjenige von
Component Pascal daraus hervorgegangen ist. Derjenige von der ETH verwendet keine Generationen und ist auch nicht konservativ
sondern hocheffizient, indem er kaum zusätzlichen Speicher benötigt und die Größe dieses temporär benötigten Speichers sogar am
Angebot ausrichten kann.
Prinzipiell scheint mir ein Speicherreiniger, der auf die Sprache abgestimmt ist, deutlich mehr Potential zu bieten als einer
wie der von Böhm, der mit jeder Sprache kombiniert werden kann, weil er sich immer auf der sicheren Seite bewegt.
Post by llotharPost by UlrichPost by llotharIt must (!!!) support the atomar malloc if the object does not
contain pointers.
Warum nur, wenn keine Zeiger vorhanden sind? In Bezug auf welche Ereignisse ist hier "atomar" zu verstehen?
Muss sein, da sonst Fragmentierung im Heap nicht zu vermeiden ist,
ausserdem kann man so memory mapped datenstrukturen mit einem C++
Placement new ähnlichen Konzept benutzen. Atomar bezieht sich auf den
Boehm-Weisser GC und bedeutet der Compiler muss erkennen ob der
Speicherblock keine anderen Pointer enthält. Nenne es einfach nicht
vollständig konservative C garbage collection.
"Atomar" wär also im ursprünglichen Wortsinne von "fysisch unteilbar" zu verstehen, bedeutet also einen zusammenhängenden
Speicherbereich. Ich befürchte, dass sich damit das Fragmentieren des dynamischen Speichers nicht verhindern lässt, sobald
Speicherblöcke unterschiedlicher Größe angefordert und freigegeben werden.
Die Speicherverwaltung des Oberon-Systems der ETH verhält sich aber diesbezüglich anstandslos.
Post by llotharPost by UlrichPost by llothar- Source available (but doesn't need to be free) and license must allow
me to hack
- Fast (must compile a 1.000.000 line system)
Tut mir leid, dass ich hier fragen muss: Wie lange darf das Übersetzen dieser 1 Mio Zeilen dauern und wie lang dürfen die Zeilen
sein? Wie schnell sind die Maschinen (PPC+Intel etc. - siehe oben!), auf denen der Übersetzer laufen soll? Es ist nämlich so,
dass alle mir bekannten Oberon-Übersetzer problemlos Module mit mehr als 1 Mio Zeilen übersetzen und dass sie, wenn sie auf
einer entsprechend schnellen Maschine angeworfen werden, kaum länger als einen Augenblick dafür benötigen. Wenn man dagegen eine
langsame Maschine verwendet, dauert es etwas länger.
Also ich hab für Eiffel gerade einen 2,8 GHz Rechner mit 1,5 GB
Speicher. Werde aber demnächst auf einen Dual AMD 4,4 umsteigen. Was
hier gemeint ist das gutes incrementelles Kompilieren möglich sein
muss. Nicht wie bei einigen Sprachen das alles übersetzt wird (GNU
Eiffel versucht das zu optimieren, scheitert aber bedauerlicherweise
sehr oft daran).
Alles klar: Das ist bei Modula-2, Modula-3 und allen Oberon-Dialekten in vorbildlicher Weise erfüllt.
Post by llotharPost by UlrichPost by llothar- Allow me to handle dynamic allocated garbage collected and untraced ojects.
- Compiled programs must be fast.
Hierzu stellt sich dieselbe Frage wie zur geforderten Geschwindigkeit des Übersetzers - aber noch eine weitere: Welche Art von
Operation kommt besonders häufig vor? Ist es wichtig, dass die Arithmetik sehr schnell ist? Wird viel mit Gleitkommazahlen
gerechnet? Sollen die Laufzeitüberprüfungen aktiv sein? Werden gute Algorithmen und Datenstrukturen verwendet? [Dies ist viel
wichtiger als ein sogenannte effiziente Maschineninstruktionen oder Optimierungen.]
Es gibt so gut wie keine einzige Gleitkommazahl.
Es werden bereits gute Algorithmen verwendet, trotzdem muss so das
maximum an Speed generiert werden. Alleine schon die Nicht-Optimierung
von virtuellen Methoden aufrufen kann für mich kritisch werden.
Wichtig ist ausserdem Startgeschwindigkeit des Programms.
Das ist ein Punkt, zu dem ich kaum Rat anbieten kann. Nur soviel: Modula-2, Modula-3 und alle Oberon-Dialekte kennen nur
virtuelle Methoden und die werden - soweit mir bekannt - nie durch direkte Prozeduraufrufe ersetzt.
Meine Meinung dazu: Wenn das ein kritischer Punkt ist, liegt möglicherweise eine Gestaltungsschwäche vor. In der Literatur wird
jedenfalls empfohlen, Methoden mit einer spürbaren Aufgabe zu betrauen, zu der das indirekte Aufrufen in einem unerheblichen
Verhältnis steht. Mit anderen Worten: Die Ausführungszeit einer Methode sollte deutlich höher sein als der Zeitverlust gegenüber
Prozeduraufrufen.
Meiner Meinung nach sollten auch Prozeduren deutlich mehr zu tun haben als das Zusammenbauen ihrer Parameterliste beim Aufrufen
benötigt.
Post by llotharPost by UlrichPost by llotharI'm currently moving a away from my Eiffel solution to another
language, as the free GNU Eiffel compiler is terribly bad with huge
program texts (~ 350 K at the moment).
Eiffel ist eine sehr gute Sprache. Wenn es nicht um das Sparen von Lizenzgebühren geht, wie oben bemerkt, dann käme vielleicht
Ich bin bereit zu zahlen, nur habe ich in EiffelSoftware nicht wirklich
so grosses Vertrauen. Ihr Small-Developer Program ist mit 500 Euro pro
Plattform ja auch noch bezahlbar. Ich will eigentlich keine FOSS mehr
haben sondern nur noch OSS - nachdem ich sowohl beim GUI wie auch beim
Compiler langsam merke das FOSS nur Probleme macht.
Bei "FOSS" und "OSS" komm ich nicht mehr mit, weil das meinem Verständnis nach dasselbe ist.
Wodurch ist das Vertrauen in EiffelSoftware beeinträchtigt? Ich kenne Meyer Betrand persönlich und ich finde ihn eine
blitzgescheiten und hochgebildeten Ingenieur.
Post by llotharPost by Ulrichauch ein anderes Eiffel-Entwicklungssystem in Frage. Eiffel bietet einige Merkmale, die in keiner anderen Sprache zu finden
sind. Ich würde wahrscheinlich nicht von Eiffel weggehen, nur weil eine Eiffel-Entwicklungsumgebung nichts taugt.
Es ist nicht die IDE, es ist der Compiler und da bin ich mit dem
Codegenerator sehr zufrieden (bis auf die Tatsache das er kein
MultiThreading unterstützt, aber das habe ich in den Compiler
gepatched).
Chapeau!
Ich meinte mit "Entwicklungssystem" alles, was unbedingt nötig ist - also mindestens Übersetzer und Laufzeitsystem.
Post by llotharPost by UlrichPascal kann man grundsätzlich ausschließen. Es gibt zwar Leute, die Pascal empfehlen und nicht einmal wissen, dass
verschachtelte Routinen seit Anfang an zum Pascal-Standard gehören, aber eine Alternative zu Eiffel ist es nicht wirklich, auch
wenn es stark erweitert wurde. Wenn schon eine Wirthsche Sprache außer Oberon in Frage kommt, dann sicher Modula-2. Daneben käme
wohl auch Modula-3 in Frage, welches Speicherreinigung und Objektorientierung bietet - beides fehlt in den meisten
Modula-2-Angeboten.
Modula-3 ist tot, sorry, dann könntest du ja auch gleich Sather
empfehlen.
Sather ist, soviel ich noch weiß, als ich es mir vor einigen Jahren in Karlsruhe ansah, interpretiert.
Modula-3 ist immerhin nicht extrem komplex und wahrscheinlich von 1 Person innerhalb des Projekts zu warten. Wenn die
Leistungsmerkmale gut sind und gute Schnittstellen zu anderen Sprachen und Komponenten vorhanden sind, ist es bei einem
längerfristigen Projekt nicht wichtig, wieviele Leute in der Sprache entwickeln - vorausgesetzt, sie ist nicht zu schwierig zu
lernen, weil sie z.B. völlig exotisch ist. Das ist aber bei Modula-3 nicht der Fall: Es ist ähnlich genug, so dass
Pascal-Programmierer es zügig lernen können.
Post by llotharPost by UlrichPost by llotharPorting would be done by writing an Eiffel->Oberon compiler.
If anybody knows about any other language / Compiler implementation please tell me.
Es gibt so viele Sprachen und Entwicklungssysteme, dass es schwer fällt, etwas zu empfehlen, wenn man das Projekt nicht kennt.
Auch Oberon bietet einige einmalige Merkmale, die sich aber nur lohnen, wenn man sie auch wirklich benötigt.
Na ja, geht so. Ich habe ehrlich gesagt nicht eine einzige Sprache
gefunden die mich überzeugt. Eiffel + Sather schon, von der Sprache
her. Aber dann ist da die Praxistauglichkeit, die haben dann leider
Java,C#,C++. Vermutlich werde ich mir langfristig (ich kalkuliere 10
Jahre die dieses Projekt noch leben soll) einen eigenen einfachen
Compiler schreiben der das macht was ich brauche.
Das hört sich sehr gut an. Wenn man sehr hohe, spezielle Anforderungen stellt, findet man wahrscheinlich keine Sprache, die
alles befriedigt, weil Sprachen normalerweise allgemein konzipiert sind. Dann käme es darauf an, mit einem System anzufangen,
das möglichst nah am gewünschten Ergebnis liegt und so einfach zu verstehen ist, dass man es selbst mit vernünftigem Aufwand
anpassen kann.
Post by llotharAuch Common Lisp schaue ich mir alle paar Monate wieder an, aber diese
Syntax, nein danke. Ich kann einfach nicht (setq x (+ x 1)) anstatt
x:=x+1 schreiben, das will ich nicht sehen, ich will,will,will es
nicht. Ich habe schon überlegt ob ich nicht einen Eiffel->CLOS
Preprocessor schreiben soll. Das müsste aufgrund des hohen Featuresets
von Common Lisp + CLOS ja eigentlich nicht so schwer sein.
Autsch. Viel Spaß beim Fehlersuchen. Ist CLOS nicht interpretiert?
Post by llotharWas mir bei Oberon wirklich probleme macht ist das es keine Generics
gibt (könnte ich ja noch verkraften) und viel wichtiger das es keine
Agent ähnlichen Eiffel Mechanismen gibt (also eine poor mans version
von function closures). Mit den aktuellem Oberon sieht das
Programmieren von Callbacks in GUI Programmen ziemlich übel aus.
Sehr interessante Kritik. Seit es Objektorientierung gibt, komme ich persönlich problemlos ohne Generizität aus. Und auch das
Installieren von Routinen mit eigenem Zustand in Gerüsten ist mit Objekten aus meiner Sicht kein Problem. Da würde ich gern ein
Beispiel sehen, welches das erwähnte üble Aussehen zeigt.
Post by llotharD käme für mich noch am ehesten in Frage, aber zur Zeit ist Debugging
die Hölle und da wird immer noch soviel an den Features geändert das
ich nur schreiend die Mailing Liste wieder verlassen kann. Eine Sprache
die mir bei einer fehlgeschlagenen precondition einfach das Program
terminiert ohne eine Meldung und einen Stacktrace auszugeben ist nicht
nutzbar.
Eine Entscheidung für D wär auch etwas waghalsig, da man doch nicht abschätzen kann, ob sie am Leben bleibt. Zudem ist sie
ziemlich komplex.
Post by llotharUnd ja ich gebe zu ich habe am Anfang mit meiner GNU Eiffel
Entscheidung ziemlichen Mist gebaut, das bereue ich und buche es als
teures Lehrgeld ab.
Ich will jetzt halt nicht nochmal so enden, weil zweimal solches
Lehrgeld zu zahlen kann ich mir nicht leisten. Daher grübel ich schon
seit etwa einem halben Jahr über diese Frage.
Vielleicht war die Entscheidung für GNU Eiffel doch kein Fehler, weil der Programmtext eine hohe Qualität aufweist. Wenn GNU
Eiffel nicht zusehr vom Eiffel-Standard abweicht, würde es sich vielleicht lohnen, die Störfaktoren selbst zu beseitigen. Das
wär vielleicht besser, als eine eigene Sprache zu entwickeln und zu implementieren.
Was ich bisher weiß, lässt das Projekt attraktiv erscheinen. Kann ich mitarbeiten?