Heim

Diskussion:Eiffel (Programmiersprache)

Ein falscher Fehler, Herr Tesuji. Mit Reverenz ist wirklich Reverenz gemeint (im Sinne von Ehrerbietung, Verbeugung, vor den Ingenieurtechnischen Leistungen nämlich). Referenz mein allgemein laut Duden Beziehung, Empfehlung, das macht hier keinen Sinn. Und die Bedeutung, die dieser Begriff bzgl Computersprachen (etwa Verweis) hat, sollte auch nicht verwendet werden, da zu speziell.

In der Tat, ich habe wohl unbewusst an letztere Bedeutung gedacht und entschuldige mich für diese voreilige Korrektur. Tesuji 13:05, 4. Jun 2003 (CEST)
Diese Änderung ist gerade nochmal vorgekommen und wurde von mir revertiert --Karljunk 22:10, 1. Apr 2005 (CEST)
Warum nicht einfach "Hommage" oder sowas? Oder eben "Verbeugung", "Verneigung"? Ich wollte grad ebenfalls das "v" zum "f" machen ;) denke mal daß das Wort kaum einer kennt - bzw. 'ne Alternative wäre es noch, aus dem Wort einen Link auf einen Artikel "Reverenz" zu machen ;) dann wüßte man immerhin, daß dieses Wort existiert.

Inhaltsverzeichnis

Überladen von Operatoren

Das stand offenbar von Anfang an im Artikel. Gibt es aber in Eiffel nicht, und zwar mit Absicht. Jedes Feature hat eine Signatur, und die bleibt bei der Vererbung erhalten. Höchstens können die Typen durch Unterklassen-Typen der originalen Typen ersetzt werden, die aber konform zu den Oberklassen sein müssen. --Karljunk 04:53, 19. Mär 2005

Ich zitiere mal aus einer Publikation von Interactive Software Engineering Inc. von 1987:
operator overloading
The term "operator overloading" is not entirely adequate since the issue is whether functions may be assigned names that will be used in prefix or infix form in calling expressions. This is a syntactic, not a semantic issue; the more impotant form of overloading, the semantic one, is provided in the object-oriented context by redefinition and dynamic binding.
C++ offers the possibility of using an operator (from a set of predefined ones) as function name. Eiffel offers "prefix" and "infix" operators, which achieve the same purpose. So there is no significant difference between the two languages here.
dibe 00:16, 23. Mär 2005 (CET)
Ich zitiere mal aus Eiffel, the Language (1992), Seite 17, nach dem die Vorteile von "dynamic Binding" erklärt wurden: "This technique is particularly attractive when compared to its closest equivalent in traditional approaches. In Pascal or Ada, you would need records with variant components, ... The Ada facilities for overloading and genericity do not bring any improvement to this respect ...". Ich wüsste nicht, wo sonst in diesem Buch noch von "overloading" die Rede ist. Tatsächlich ist wohl das Überladen von Funktionen und Operatoren durch Ada populär geworden. Dort kann man schon seit jeher - lange bevor die objektorientierte Programmierung populär wurde, Funktionen und Operatoren mehrfach definieren mit jeweils verschiedenen Parameterlisten. Dies ist sicherlich von Übel, denn wie leicht kann man einen aktuellen Parameter mit einem ungewollten Typ erwischen, und der Compiler akzeptiert es, führt aber dann eine ganz andere Routine aus als gedacht. Solche Fehler sind sicher schwierig zu finden. Das C++ Beispiel, dass sich unter [Überladen] findet, geht in Eiffel genausowenig, da es der gleiche Scheiß wie in Ada ist. Wenn man sowas objektorientiert machen will, dann muss man ganz anders vorgehen, nämlich wie z. B. bei der Funktion abs in NUMERIC, die durch dynamisches binden auch auch auf sowohl INTEGER als auch DOUBLE targets angewandt werden kann. Dann heist es aber nicht abs(n), sondern n.abs. Das ist etwas so fundamental anderes, dass ich denke, der Begriff Überladen sollte nur für den objektorientierten Ansatz nicht verwendet werden sollte. In C++ geht natürlich beides, aber nur eines sollte Überladen heißen. Und das ist der "traditional approach".
--Karljunk 18:20, 23. Mär 2005 (CET)
Ich kenn mich mit Ada nicht so aus, komme eher von C++, wo "operator overloading" eigentlich nicht viel mehr meint als Operatoren für Klassen zu definieren; aber da das auch im vom mir zitierten Text gesagt wird, "operator overloading" sei nicht eine entirely adequate bezeichnung, sollte man vielleicht nur schreiben: Definition von Prä- und Infix-Operatoren möglich.
dibe (z.Z. ausgeloggt)
Habe ich eben so ähnlich eingefügt. Mir schien es sinnvoll, die Wesensgleichheit von Operator auf Funktion in Eiffel hervorzuheben. --Karljunk 18:05, 30. Mär 2005 (CEST)

Der ECMA Eiffel Standard

Ich habe die Seite mal überarbeitet, um die Änderungen durch den ECMA-Eiffelstandard und diesen selbst einzupflegen.

Außerdem ist SmartEiffel (leider) kein "richtiger" Eiffel-Compiler mehr. 1. weicht es schon jetzt von bisherigen Eiffel-Gepflogenheiten weit ab (z.B. Unterscheidung von Groß/Kleinschreibung inzwischen verpflichtend; auch bestimmte Benennungen (Klassen immer GROSS, formale generische Parameter müssen Postfix _ besitzen, Features klein), die vorher nur Stilfragen waren). 2. haben die Entwickler mehrfach auf ihren Mailinglisten angekündigt, den ECMA-Standard nicht umzusetzen und in ihre eigene Richtung weiterzuentwickeln.

Eine interessante Neuentwicklung ist GEC, der Eiffel-Compiler der Gobo-Bibliothek. Dieser wird wohl über kurz oder lang den Platz von SmartEiffel einnehmen (Mutmaßung und daher nicht im Artikel eingefügt).

wird GEC den Status von SmartEiffel einnehmen?

Das wage ich zu bezweifeln, weil gec versucht ja sofern ich recht informiert bin ECMA-Eiffel zu implementieren, was sehr umstritten ist. Es gibt einige Meinungen, dass der Dialekt von SmartEiffel besser den Ideen von Eiffel (im ursprünglichen Sinn) entspricht, als der "Standard". Meine Prognose ist, dass SmartEiffel eine Sprache wird die sich verbessert, und es erleichtert sichere Software zu entwickeln. Der ECMA-Standard - von dem man munkelt, er könne überhaupt nicht auf sinnvolle Art und Weise implementiert werden führt viele von den Dingen ein, die Sprachen wie C++ so hässlich machen. (z. B. wird meiner Meinung nach viel zu viel implizit gemacht: automatic boxing, convertion features, ... was zu immer undurchsichtigerem Code führt). Die Ausführungs-Performance von SmartEiffel gegenüber ISE Eiffel ist ja unumstritten und kann wohl auch mit dem ECMA-Standard nie erreicht werden. Natürlich ist bei SmartEiffel einiges schief gelaufen und es werden immer wieder Änderungen in der Sprache eingeführt, die die Rückwärtskompatibilität einschränken, aber das ist etwas das ich Fortschritt nennt - auch wenn es auch in meinen Augen nicht immer gerechtfertigt war.

EiffelStudio unter GPL

"mit SmartEiffel (ehemals SmallEiffel, siehe Abschnitt Weblinks) und dem sich aktuell in Entwicklung befindlichen GEC (aus der Gobo Klassenbibliothek, siehe Abschnitt Weblinks) mindestens zwei Open-Source-Compiler." wiederspricht "Anfang April 2006 wurde der Quelltext von EiffelStudio, eine plattformübergreifende integrierte Entwicklungsumgebung von Eiffel Software, als Freie Software veröffentlicht." - es gibt also 3 Open-Source-Compiler, wobei einer aus der akademischen Welt, einer in Privatleistung und einer durch Firmenentwicklung entstanden ist. Der letzte Paragraph sollte in den ersten integriert werden. Ausserdem könnte man nennen, dass EiffelStudio unter der GPL publiziert wurde. --Schoelle 16:51, 1. Feb. 2007 (CET)

Quelle: "Die Effizienz sowohl bezüglich der Geschwindigkeit als auch bezüglich des Speicherbedarfs ist bei Native Code in etwa mit der von C++ vergleichbar."

Mag sein, dass das zutrifft, es sollte aber mit einer Referenz auf ein Buch, einen Magazinartikel, oder eine Webseite belegt werden. --Provi-neu 15:12, 10. Jul. 2007 (CEST)

Darf man denn erfahren, warum gerade an dieser Aussage des Artikels Zweifel bestehen? dibe 19:04, 12. Jul. 2007 (CEST)
Weil unbelegte Effizienzaussagen nicht vertrauenswuerdig sind. --Provi-neu 19:45, 12. Jul. 2007 (CEST)
Ist ein Verweis auf die Diplomarbeit von Peter Häfliger ok? Dieser hat mathematische Algorithmen in Eiffel implementiert und deren Geschwindigkeit mit der von C verglichen (ist natürlich etwas anderes als C++). Dort schreibt er: Procedural Eiffel can even be faster than direct C. This is in accordance with the fact that even in my best attempt, I was unable to beat fully optimized C with my direct assembly program. [...] ISE code is usually slower, but the overhead is less than 30% and all Eiffel implementations are faster than unoptimized C code. (http://se.inf.ethz.ch/projects/peter_haefliger/peter_haefliger_da.pdf - Seite 70). --Schoelle 16:44, 13. Jul. 2007 (CEST)
Da ist jetzt aber schon wieder keine Angabe ob wirklich "sowohl bezüglich der Geschwindigkeit als auch bezüglich des Speicherbedarfs". Und die Diskrepanz, dass im Artikel C++ stand, bei dir aber C. Und ein Beispiel konstituiert keine Vergleichbarkeit. Ich bin dafuer, den Satz etwas konservativer zu formulieren und dann wieder einzufuegen. --Provi-neu 18:08, 13. Jul. 2007 (CEST)
Ist ja klar, war nur eine erste Idee, um die Aussage besser zu formulieren. Eine weitere Referenz wäre http://shootout.alioth.debian.org/ - natürlich mit den bekannten Einschränkungen. Dort gibt es Ergebnisse zu SmartEiffel. Hier bracht SmartEiffel 60% mehr Zeit als g++, bei der Speichernutzung sind diese vergleichbar. Genaue Vergleiche von Geschwindkeiten von Programmiersprachen sind sowieso müssig. Eiffel hat z.B. immer den Overhead des GC. Auf der anderen Seite machen alle Eiffel compiler eine globale Analyse für dynamic binding, haben dadurch O(1) Aufwand, im Gegensatz zu O(n) bei 'virtual' Methoden in C++.
Es bleibt die Frage, ob all das hier überhaupt hineingehört, die Performance ist ja compilerabhängig und nicht Teil der Programmiersprache. Bei einem Eiffel-Interpreter sähe die Sache bestimmt anders aus. Bei einem C++-Interpreter wohl auch.--Schoelle 16:19, 16. Jul. 2007 (CEST)
Den Shootout würd ich lieber nicht verlinken. ;) Ja, vielleicht gehören Effizienzaussagen allgemein nich in Wikipedia. --Provi-neu 21:24, 16. Jul. 2007 (CEST)
Stimmt. Was bleibt ist einfach ein fauler Beigeschmackt, weil es natuerlich viel einfacher ist, eine Sprache fuer eine VM oder einen Interpretiert wird zu entwickeln, als eine Sprache die effizient compliert werden kann. Irgendwie wuenschte ich, man koennte dies aufnehmen. --Schoelle 12:40, 17. Jul. 2007 (CEST)
So, ich habe den "Compiler" Abschnitt überarbeitet, aufgeräumt und die Aussagen zur Performance entschärft. Ich glaube, dass es somit neutraler geworden ist, ohne die Kernaussagen zu verwischen. --Schoelle 12:59, 17. Jul. 2007 (CEST)