NG Programmiersprache?

[thatway]

Nexus schrieb:

KuhTee schrieb:

Totschlag

Eigentlich habe ich ja nur meine Aussage von zehn Seiten vorher wiederholt.

Nexus schrieb:

thatway schrieb:

Dravere schrieb:

Gegenfrage: Wieso sollte man [Mehrfachvererbung] verbieten?

Weil man es nicht braucht.

Was für ein Argument. Man braucht recht wenig, um zu programmieren.

thatsway, du hast bisher noch nichts erwähnt, das gegen Mehrfachvererbung spricht. Und nein, "man braucht es nicht" ist kein Argument. Das meinte ich.

Ich hab schon öfters gesagt, dass man doch nur Mosterklassen erzeugt. Oder vielleicht versteht ihr es mit den Worten von Wikipedia:

http://de.wikipedia.org/wiki/Mehrfachvererbung schrieb:

Als Einwand gegen Mehrfach-Klassenvererbung wird häufig genannt, dass sie das Design unnötig kompliziert und undurchsichtig machen können.

Aber ihr seid ja alle so perfekt, dass das nicht zählt, weil ihr ja nie etwas unnötig kompliziert machen würdet. Und das Diamond Problem wird euch auch nie passieren. In meiner Firma wird anscheinend zufälligerweise nur der Code von genau den einzigen paar C++ Programmierern refactort die nicht ganz perfekt waren und Mehrfachvererbung rein gehackt haben um Teile von Klassen auch wo anders verwenden zu können und so kaotische Abhängigkeiten erzeugten.

knivil schrieb:

Also das hier sind die Next Generation Programmierer? Da hilft dann auch keine Sprache!

Mehrfachvererbung For Teh Win.

[ipsec]

Man kann so ziemlich alles missbrauchen. Genauso könnte man Funktionsüberladung verurteilen (man könnte ja abs(int) derart überladen, dass es bunte Kreise auf den Bildschirm zeichnet und der frühere Code x = abs(5) , der sich auf abs(double) verließ, funktioniert nicht mehr) oder Operatorüberladung (damit kann man das Design unnötig undurchsichtig machen. Was ist, wenn jemand bei seiner Matrix -Klasse plötzlich + und - in der Bedeutung vertauscht?) oder Properties in C# (ein banales x = variable.wert kann intern das System rebooten) oder objektorientierte Programmierung im Allgemeinen (Klassen können das Design sehr komplex und undurchsichtig machen) usw. usw.
Bei der Argumentation landen wir irgendwann bei Brainfuck, dort kann man in der Hinsicht wenigstens nichts falsch machen.
Dass Mehrfachvererbung unter Umständen zu Designfehlern führt, weil der Programmierer sich schnell was zusammengehackt hat, was ohne Mehrfachvererbung gar nicht ginge, ist ja eine ganz andere Frage.
Trotzdem ist das kein Argument dagegen.

[thatway]

volkard schrieb:

thatway schrieb:

Ihr könnt ja mal hier ein paar Entwurfsmuster mit Mehrfachvererbung verlinken, damit ich mal die Vorteile von Mehrfachvererbung kennen lern. (Ein Beispiel in einem alten Buch, das ich mir sicher nicht kaufe, ist kein Link. ) Mal sehen, was da so kommt.

Ah, hier wird die Argumentation verbogen.
Statt der Frage, ob MI gelegentlich sinnvoll ist, wird umgebogen auf die Frage, ob MI für mehrere Entwurfsmuster jüngst aufgeschrieben wurde.
Das verkennt aber, daß man gerne Entwurfsmuster einigermaßen Sprachenunabhängig faßt, sodaß sie in Sprachen mit und ohne MI klappen, daß Entwurfsmuster mehr Richtlinien sind als Gesetze, wenn man den Trick kapiert, soll man sie gerne auch ein wenig anders implementieren, und viele Dinge mehr.

Falsch interpretiert, die Frage drängte sich mir nur wegen so einer fachlichen Grundlagen Kritik auf.

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

[Nexus]

thatway schrieb:

http://de.wikipedia.org/wiki/Mehrfachvererbung schrieb:

Als Einwand gegen Mehrfach-Klassenvererbung wird häufig genannt, dass sie das Design unnötig kompliziert und undurchsichtig machen können.

So kann man argumentieren, aber nicht nur gegen Mehrfachfachvererbung. In C++ gibt es sehr viele Sprachmittel, die das Design bei falschem Gebrauch unnötig kompliziert machen (das hört man teilweise auch als Punkt von C++-Kritikern). Im Gegenzug können sie aber auch Zusammenhänge vereinfachen, für Mehrfachvererbung gilt das Gleiche.

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.

[IPH]

ipsec schrieb:

Man kann so ziemlich alles missbrauchen. Genauso könnte man Funktionsüberladung verurteilen (man könnte ja abs(int) derart überladen, dass es bunte Kreise auf den Bildschirm zeichnet und der frühere Code x = abs(5) , der sich auf abs(double) verließ, funktioniert nicht mehr) oder Operatorüberladung (damit kann man das Design unnötig undurchsichtig machen. Was ist, wenn jemand bei seiner Matrix -Klasse plötzlich + und - in der Bedeutung vertauscht?) oder Properties in C# (ein banales x = variable.wert kann intern das System rebooten) oder objektorientierte Programmierung im Allgemeinen (Klassen können das Design sehr komplex und undurchsichtig machen) usw. usw.
Bei der Argumentation landen wir irgendwann bei Brainfuck, dort kann man in der Hinsicht wenigstens nichts falsch machen.
Dass Mehrfachvererbung unter Umständen zu Designfehlern führt, weil der Programmierer sich schnell was zusammengehackt hat, was ohne Mehrfachvererbung gar nicht ginge, ist ja eine ganz andere Frage.
Trotzdem ist das kein Argument dagegen.

Diese fehler sind eher klein und lassen sich einfach beheben. Außerdem muss schon böser Wille vorhanden sein um das zu machen.
Ein Fehler im Design durch Mehrfachvererbung ist meist weit schwerer zu beheben als eine Funktion umzubennen, außerdem kann man diese Fehler auch ohne bösartigkeit oder komplette Inkompetenz machen.

[ipsec]

Du hast schon recht, aber man kann auch ohne Bösartigkeit oder komplette Inkompetenz ein Auto zu Schrott fahren. Soll man deswegen jetzt Autos verbieten?

[trolldich]

@thatway: Was willst du als nächstes alles verbieten?

- Pointer
- Referenzen
- Assembler
- alle kompilierbare Sprachen
- C
- C++

Mal im erst, Mehrfachvererbung wird halt ab und an benötigt, ob du nun damit klar kommst oder nicht. Wer bist du? So ein Java-Weichei, der nur in VMs programmiert weil er sich nicht in die böse weite Welt hinaus traut? Du wohnst wahrscheinlich noch bei Mami weil die Welt da draußen ja so böse ist und alles mögliche passieren könnten.

[knivil]

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.

[rapso]

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.

[knivil]

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.

[rapso]

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.

[knivil]

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.

[volkard]

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.

[thatway]

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.

[Zeus]

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.

[Nexus]

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.

[NG?]

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.

[Zeus]

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
}

[SideWinder]

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

[NG?]

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.