NG Programmiersprache?



  • Zur Mehrfachvererbung: Ich habe ein Objektsystem in Scheme nach dem Vorbild von C++ entworfen, mit Mehrfachvererbung und all den Problemen. Ich benutze Mehrfachvererbung bei 2 von 20 Klassen basierend auf diesem Objektsystem und muss das entsprechend bei der Objektkonstruktion beachten. (Den Kontext zu schildern sprengt den Rahmen hier.) Java bietet auch Mehrfachvererbung ueber Interfaces. Geht aber einen anderen Weg und vererbt eben nicht die Implementation sondern nur das Interface. Das gleiche kann in C++ erreicht werden, wenn man von Klassen mit pure virtual Funktionen erbt. Man mag darueber streiten, was besser ist. Ich gehe auch in C++ meist den Weg ueber pure virtual. Jedoch manchmal wuenscht man sich eben doch Mehrfachvererbung. In Java muss man einen work around basteln, C++ schraenkt das nicht ein. Genauso kann man bei Templates vs. Generics argumentieren. Policy based design wie in Modern C++ beschrieben ist eben nicht in Java moeglich. Jedoch werden es die wenigsten vermissen. Fuer Container sind Generics in Java ausreichend. Hier geht Java eben auch einen anderen Weg.

    Was sie aber meiner Ansicht nach wirklich verbockt haben, ist das Verbot von Operatorueberladung. Selbst Guy Steele (stark am Design und der Spezifikation von Java beteiligt) wuenscht sich Operatorueberladung. Warum ist goto noch in C++ oder C oder auch in anderen Sprachen? Ganz selten ist es eben doch sinnvoll. Es zu verbieten stellt manche vor unloesbare Probleme, auch wenn es nur wegen der Abwaertskompatibilitaet erhalten wurde.

    Nachtrag zu Java: Habe z.B. von Rich Hickey (Entwickler von Clojure) gehoert, dass man die Sprache Java hassen, aber die JVM lieben kann. Ist ein Stueck ausgereifter Technologie.



  • Zeus schrieb:

    Ich interessieren mich über eure Gedanke wie eine Programmiersprache aussehen, bieten muss, damit Sie im Betracht käme, euch näher mit der Programmiersprache zu beschäftigen bzw. auch damit zu arbeiten?

    P.S: An Flamerei bin ich nicht interessiert.

    ohne die 20 seiten hier gelesen zu haben.

    Ich wuerde mir immer was neues anschauen, nutzen wuerde ich es aber erst wenn es eine Problemstellung loest die mit den bisherigen mitteln zu aufwendig zu loesen ist.



  • rapso schrieb:

    Ich wuerde mir immer was neues anschauen, nutzen wuerde ich es aber erst wenn es eine Problemstellung loest die mit den bisherigen mitteln zu aufwendig zu loesen ist.

    Angsthase! Manchmal muss man den Schritt zu etwas Neuem wagen. Wie will man sonst die Grenzen oder Vorteile der neuen Sprache oder aehnliches erkennen.



  • knivil schrieb:

    rapso schrieb:

    Ich wuerde mir immer was neues anschauen, nutzen wuerde ich es aber erst wenn es eine Problemstellung loest die mit den bisherigen mitteln zu aufwendig zu loesen ist.

    Angsthase! Manchmal muss man den Schritt zu etwas Neuem wagen. Wie will man sonst die Grenzen oder Vorteile der neuen Sprache oder aehnliches erkennen.

    Auf dem selben weg wie man rausfindet ob quadratische oder runde reifen besser sind
    1. Jemanden fragen der sich auskennt
    2. beobachten was gaengig ist
    3. Auf eigene kenntniss vertrauen und grobe informationen nutzen um unsinn zu rejecten.

    das leben ist zu kurz um jeden fehler selbst begehen zu muessen als lern/entwicklungs methode.



  • Auf dem selben weg wie man rausfindet ob quadratische oder runde reifen besser sind

    Letztens hier verlinkt: http://de.wikipedia.org/wiki/Strohmann-Argument

    1.) Wie willst du wissen oder beurteilen, wer sich damit auskennt?
    2.) Jaja, dann fallen so Begriffe wie Industriestandard und Java. Nur weil es gaengig ist, heisst es noch lange nicht, dass es gut oder richtig ist.
    3.) Laufen muss man auch selber lernen. Dazu gehoert auch umfallen. Auch wenn man es bei anderen sieht und sucht zu vermeiden, man wird trotzdem umfallen.

    Wie willst du je Neuland entdecken, wenn du nur ausgelatschte Pfade beschreitest, die Verantwortung auf andere abwalzt, indem du ihren Rat befolgst. Ich erwarte keine Revolution, aber vielleicht findet man eine kleine schoene Wiese. Immer noch besser als im Java-Kaefig vom Geschrei taub zu werden.

    PS: Das sind alles nichts sagende Metaphern, aber vielleicht mag der ein oder andere nach einem Koernchen Wahrheit suchen.



  • knivil schrieb:

    Auf dem selben weg wie man rausfindet ob quadratische oder runde reifen besser sind

    Letztens hier verlinkt: http://de.wikipedia.org/wiki/Strohmann-Argument

    Auch hier unzutreffend.
    Keiner wollte Dir unterschieben, Du würdest eckige Reifen für gut halten.



  • Nexus schrieb:

    thatway schrieb:

    Aber vielleicht kennst du ja ein paar C++ Idioms die Mehrfachvererbung verwenden und die mich von Mehrfachvererbung überzeugen können.

    Wäre Policy-Based Design so ein Idiom? Dieses wird ab und zu auch eingesetzt, um die Schnittstelle einer Klasse über die Policy zu erweitern. Indem das Template von mehreren Policies erbt, stellt es deren öffentliche Methoden ebenfalls zur Verfügung. Mehrfachvererbung kommt hier ins Spiel, sobald mehrere Policies vorkommen (oder das Template nebenbei von einer hardgecodeten Klasse erbt). Ist zwar eher ein Spezialfall von Mehrfachvererbung, aber vielleicht kannst du damit mehr anfangen.

    Wenn ich hier, nach Idioms mit Templates oder allgemeinen wozu man Templates, Const-correctness usw. braucht, gefragt hätte, dann hätte man Seitenweise Links, Frameworks und andere sinnvolle Beispiele liefern können und nicht nur ein paar Spezialfälle oder Beispiele bei denen man eigentlich nur Interfaces und nicht Mehrfachvererbung braucht. Das mein ich mit "man braucht es nicht". Das Verhältnis von sinnvollen Beispielen zu Desginfehlern mit Mehrfachvererbung die ich gesehen hab ist einfach viel zu schlecht, als dass mich das von Mehrfachvererbung überzeugen könnte.



  • Du verkennst etwas. Interfaces wie du sie kennst sind kastrierte Form vom MI. Außerdem ist es gegen die Philosophie von C++ irgendwie eine Einschränkung zu machen. Falls du es brauchst bietet es dir C++. Setzt du es falsch ein, ist es dein Pech. Außerdem will dich keiner hier überzeugen, du bist frei selbst paar Libs wie Loki oder SmartWin anzusehen und dir ist freigestellt MI zu verwenden oder nicht.



  • thatway schrieb:

    Wenn ich hier, nach Idioms mit Templates oder allgemeinen wozu man Templates, Const-correctness usw. braucht, gefragt hätte, dann hätte man Seitenweise Links, Frameworks und andere sinnvolle Beispiele liefern können und nicht nur ein paar Spezialfälle oder Beispiele bei denen man eigentlich nur Interfaces und nicht Mehrfachvererbung braucht. Das mein ich mit "man braucht es nicht". Das Verhältnis von sinnvollen Beispielen zu Desginfehlern mit Mehrfachvererbung die ich gesehen hab ist einfach viel zu schlecht, als dass mich das von Mehrfachvererbung überzeugen könnte.

    Wenn du dich an schlechtem Code orientierst, ist es nicht verwunderlich, dass dir Mehrfachvererbung unangebracht vorkommt. Aber das ist schon wieder sowas Allgemeingültiges, das nicht Mehrfachvererbung im Speziellen betrifft. Oder glaubst du etwa auch all den Predigern, dass Zeiger böse sind, und fühlst dich durch Tausende Anfänger (und nicht selten sogar Fortgeschrittene), welche die gepredigten Fehler machen, bestätigt?

    Und was den Spezialfall betrifft: Ich hoffte, der würde dich mehr überzeugen, da du dir unter dem Allgemeinen scheinbar nichts vorstellen konntest (auf mein Codebeispiel bist du ja nach meiner Nachfrage nicht mehr eingegangen). Aber ich scheine mich geirrt zu haben. Wahrscheinlich ist es das Klügste, du schaust dir einfach ein paar modernere Bibliotheken in C++ an.

    Übrigens: Du kannst mir ja gerne sagen, wie man Policy-Based Design mit Java-Interfaces hinbekommt. Durch das Fehlen von State ist man viel zu stark eingeschränkt.



  • Zeus schrieb:

    Ich interessieren mich über eure Gedanke wie eine Programmiersprache aussehen, bieten muss, damit Sie im Betracht käme, euch näher mit der Programmiersprache zu beschäftigen bzw. auch damit zu arbeiten?

    Keine Ahung, ob es sowas schon gibt, aber hierarchische Module mit Zugriffsrechten fände ich interessant.

    In einem Modul sollten Klassen und Funktionen sein, die wie bisher aufeinander zugreifen können. Für das Modul sollte man dann angeben können, auf welche Klassen, Funktionen und Interfaces Module von außerhalb zugreifen können. Außerdem sollten Module selbst wieder Module enthalten können die dann auch wieder public oder private sein können.



  • Sowas?:

    module A
    {
    	// Lib ist für A-Module sichbar
    	private using Lib
    
    	// Lib ist für jeden sichbar
    	public using Lib
    
    }
    
    module Lib
    {
    	public using X
    	public using Y
    }
    
    module X
    {
    	private using Y
    }
    
    module Y
    {
    	private using X
    }
    


  • NG? schrieb:

    Zeus schrieb:

    Ich interessieren mich über eure Gedanke wie eine Programmiersprache aussehen, bieten muss, damit Sie im Betracht käme, euch näher mit der Programmiersprache zu beschäftigen bzw. auch damit zu arbeiten?

    Keine Ahung, ob es sowas schon gibt, aber hierarchische Module mit Zugriffsrechten fände ich interessant.

    In einem Modul sollten Klassen und Funktionen sein, die wie bisher aufeinander zugreifen können. Für das Modul sollte man dann angeben können, auf welche Klassen, Funktionen und Interfaces Module von außerhalb zugreifen können. Außerdem sollten Module selbst wieder Module enthalten können die dann auch wieder public oder private sein können.

    So ähnlich wie Java nur konsequenter ausgeführt?

    MfG SideWinder



  • Wie und ob man sowas einfach in ein File schreiben kann, weiß ich nicht genau.

    Vielleicht könnte man sowas ähnliches wie eine Baumstruktur machen.

    Module A
    {
    public:
       class C
       function F
    
    implementation:
       class C {...}
       class D {...}
       function F{...}
       Module M
       {
       public:
          class X
       implementation:
          class X{...}
          class Y{...}
       }
    }
    
    Module B
    {
    public:
    ...
    implementation:
       class Foo
       {
          include A.C
          ...
          ... new C
       }
    }
    

    Klasse Foo von Modul B kann also nur auf Klasse C und Funktion F von Modul A zugreifen.
    Keiner von Modul B kann auf Klasse D oder Modul M aus Modul A zugreifen, weil die nur im Implementierungsteil sind. Include A.D wäre ein Compile-Error in Modul B.
    Klasse C aus A kann auf Klasse D aus A und auf Klasse X aus Modul M zugreifen. usw.

    Irgendwie müsste man sich noch überlegen, wie man das auf einzelne Dateien aufteilen kann, statt so tiefer Klammerung.



  • Kann man ganz leicht in den meisten Sprachen bauen. Man bietet einfach einen Header/Export/Namespace .. irgendwas an, dass eben nur das gewuenschte exportiert. Der Zugriff auf nicht exportierte Elemente wird meist mit einem Compilererror beendet, da der entsprechende Name in der entsprechenden Uebersetzungseinheit unbekannt ist.


Anmelden zum Antworten