NG Programmiersprache?
-
~john schrieb:
thatway schrieb:
Das führt immer nur zu diesen Superklassen die alles sind anstatt das die Funktionalität aufgeteilt wird.
Eben dies ist nicht der Fall. Der Klassiker ist wohl das Problem der Serialisierung. In den meisten Programmiersprachen wird dies per Interface gelöst, welches dann von jeder konkreten Klasse implementiert werden muß. Das ist ganz klassisch eine "ist-ein"-Beziehung. Und es gibt keinen wirklichen Grund das ganze auf Interfaces zu beschränken, echte Klasse funktionieren genauso gut.
Dein Argument geht voll an meiner Aussage vorbei. Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist? Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst? Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable... und dann hoffst du das die nicht alle eine gleiche Methode "serialize" wollen?
-
Naja wenn du diese Meinung vertrittst solltest du vielleicht auf OOP verzichten. Vererbung ist nun mal ein Konzept der OOP und bewährt sich ja ganz gut.
Und mal ganz im Ernst: wenn man jede Form von Aufwand scheut sollte man nicht Programmieren.
Bei deinem Beispiel verstehe ich das Problem auch nicht wirklich. Auch wenn man den JFrame durch ein JPanel ersetzt muss man nicht viel ändern, in beiden Fällen nicht. Denn wenn man schon auf die Idee kommt das ganze auszutauschen, dann wird man die Klasse wohl kaum als spezielles Fenster betrachten, und dann auch nur Methoden nutzen die beide Klassen (JFrame und JPanel) von der Oberklasse geerbt haben (wo wir wieder bei der Nützlichkeit von Vererbung wären ^^).
-
player4245 schrieb:
Naja wenn du diese Meinung vertrittst solltest du vielleicht auf OOP verzichten. Vererbung ist nun mal ein Konzept der OOP und bewährt sich ja ganz gut.
Vererbung wird viel zu oft missbraucht an Stellen, wo andere Mittel besser wären. Wenn man dann keine Vererbung benutzen willst, wird einem direkt vorgeworfen, man würde nicht objektorientiert programmieren
Mit der Meinung steh ich auch nicht allzu alleine da. Mal das erstbeste Buch aufschlagen: Exceptional C++.
Vererbung wird sogar von erfahrenen Entwicklern häufig zu oft benutzt.
Bevorzugen Sie Aggregation ("Komposition", "Layering", "HAT-EIN", "Deligierung") gegenüber Vererbung. Drücken Sie IST-IMPLEMENTIERT-MIT immer durch Aggregation und nicht durch Vererbung aus.
-
thatway schrieb:
Dein Argument geht voll an meiner Aussage vorbei.
Nein, Du verstehst das Problem wohl eher nicht.
thatway schrieb:
Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist?
Nein, das ist nicht der Fall.
thatway schrieb:
Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst?
Ein brauchbares Framework entwerfen, was das kann. Das ist im aktuellen C++ mangels dynamic dispatching eher ein Quahl (daher die Featureliste von mir), aber es geht trotzdem.
thatway schrieb:
Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable...
Nein, wenn Du das machst, hast Du einen heftigen Designfehler gemacht. Das Frameworks muß wissen, wie es die integralen Datentypen auf das jeweiligen Backend serialisiert. Die Applikation muß dann nur das Backend auswählen, und jede konkrete Klasse muß sagen welche Dinge serialisiert werden müssen. Daher kann auch nur die konkrete Klassen "wissen" was zu serialisieren ist. Aus diesem Grund kommt eine Dekomposition auch nicht in Frage.
Schau Dir doch einfach mal ein entsprechendes Framework in einer Sprache an, die dynamic dispatching hat und entsprechend flexibel ist.
-
player4245 schrieb:
Und mal ganz im Ernst: wenn man jede Form von Aufwand scheut sollte man nicht Programmieren.
Genau das ist der springende Punkt. Vererbung ist eben kein Aufwand. Es ist viel einfacher zu erstellen als komplizierte Beziehungsgeschichten.
player4245 schrieb:
Bei deinem Beispiel verstehe ich das Problem auch nicht wirklich. Auch wenn man den JFrame durch ein JPanel ersetzt muss man nicht viel ändern, in beiden Fällen nicht. Denn wenn man schon auf die Idee kommt das ganze auszutauschen, dann wird man die Klasse wohl kaum als spezielles Fenster betrachten, und dann auch nur Methoden nutzen die beide Klassen (JFrame und JPanel) von der Oberklasse geerbt haben (wo wir wieder bei der Nützlichkeit von Vererbung wären ^^).
Weißt du jetzt schon ob du deinen Code in einem Jahr noch erweitern / wiederbenutzen willst? Oft eben nicht und Vererbung ist eben nicht allgemein - sie bindet. Bei den paar Zeilen Beispielcode sieht man das noch nicht so, aber du hast da schnell mal ein paar Tausend Zeilen Code zusammen. Spätestens wenn du zu den Methoden noch Attribute aus der Oberklasse nutzt gibt es praktisch keine Möglichkeit mehr den Code wiederzuverwenden.
Du darfst nämlich nicht vergessen, dass nicht nur die Superklasse zur Wiederverwendung dienen soll, sondern auch eine Unterklasse.
-
~john schrieb:
thatway schrieb:
Dein Argument geht voll an meiner Aussage vorbei.
Nein, Du verstehst das Problem wohl eher nicht.
thatway schrieb:
Warum sollte eine Klasse jetzt nicht so eine Monsterklasse werden, wenn sie auch noch für die Serialisierung zuständig ist?
Nein, das ist nicht der Fall.
thatway schrieb:
Was machst du dann wenn du ein Objekt auf verschiedene Arten serialisieren willst?
Ein brauchbares Framework entwerfen, was das kann. Das ist im aktuellen C++ mangels dynamic dispatching eher ein Quahl (daher die Featureliste von mir), aber es geht trotzdem.
thatway schrieb:
Implementiert die Klasse dann XMLSerializable, BinarySerializable, DBSerializable...
Nein, wenn Du das machst, hast Du einen heftigen Designfehler gemacht. Das Frameworks muß wissen, wie es die integralen Datentypen auf das jeweiligen Backend serialisiert. Die Applikation muß dann nur das Backend auswählen, und jede konkrete Klasse muß sagen welche Dinge serialisiert werden müssen. Daher kann auch nur die konkrete Klassen "wissen" was zu serialisieren ist. Aus diesem Grund kommt eine Dekomposition auch nicht in Frage.
Schau Dir doch einfach mal ein entsprechendes Framework in einer Sprache an, die dynamic dispatching hat und entsprechend flexibel ist.
Schön, wie du alles verdrehst. Du warst doch für Mehrfachvererbung was dann ja zu "XMLSerializable, BinarySerializable, DBSerializable" führen würde und jetzt willst du plötzlich dynamic dispatching und tust so als ob ich die Designfehler mach...
-
thatway schrieb:
Schön, wie du alles verdrehst.
Geh auf die erste Seite des Threads schau Dir noch einmal meine Liste an und Du wirst darin sowohl Mehrfachvererbung wie auch Dynamic Dispatching finden. Es hat seine Gründe, weshalb ich beides in einer Sprache haben will. Ich habe meinen Standtpunkt im Verlauf des Threads nicht verändert, auch wenn Du mir anders unterstellst.
thatway schrieb:
Du warst doch für Mehrfachvererbung was dann ja zu "XMLSerializable, BinarySerializable, DBSerializable" führen würde
Wenn Du nicht weißt wie man das richtig entwirft, mach dafür nicht Deine Mitmenschen verantwortlich. Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, darin kannst Du solche Grundlagen nachlesen.
-
~john schrieb:
thatway schrieb:
Schön, wie du alles verdrehst.
Geh auf die erste Seite des Threads schau Dir noch einmal meine Liste an und Du wirst darin sowohl Mehrfachvererbung wie auch Dynamic Dispatching finden. Es hat seine Gründe, weshalb ich beides in einer Sprache haben will. Ich habe meinen Standtpunkt im Verlauf des Threads nicht verändert, auch wenn Du mir anders unterstellst.
thatway schrieb:
Du warst doch für Mehrfachvererbung was dann ja zu "XMLSerializable, BinarySerializable, DBSerializable" führen würde
Wenn Du nicht weißt wie man das richtig entwirft, mach dafür nicht Deine Mitmenschen verantwortlich. Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, darin kannst Du solche Grundlagen nachlesen.
Ist wohl sinnlos mit dir, kommen ja doch nur verlogene Unterstellungen.
-
Dravere schrieb:
von zum Beispiel C++ ausgehen, dann die Makros und Templates rausschmeissen, dafür in die eigentliche Sprache hinein eine Code-Generator Sprache implementieren. Ich habe mir sogar schon mal Gedanken darüber gemacht,
Lisp, Scheme oder PLT-Scheme.
-
Michael E. schrieb:
player4245 schrieb:
Naja wenn du diese Meinung vertrittst solltest du vielleicht auf OOP verzichten. Vererbung ist nun mal ein Konzept der OOP und bewährt sich ja ganz gut.
Vererbung wird viel zu oft missbraucht an Stellen, wo andere Mittel besser wären. Wenn man dann keine Vererbung benutzen willst, wird einem direkt vorgeworfen, man würde nicht objektorientiert programmieren
Einer hat mir mal seine tolle Vererbungshierarchie gezeigt und am Ende war Logger die Basisklasse, damit er überall log(...) aufrufen kann und dann meinte er noch ganz stolz, das ist objektorientierte Programmierung.
-
CCD schrieb:
Warum? Komposition fördert die lose Kopplung und die Testbarkeit eines Systems und ist oft flexibler.
Für die Wiederverwendung von Funktionalität kennt die OOP zwei sehr bekannte Kandidaten: Die Vererbung (whitebox – reuse) und die Komposition (blackbox – reuse). Verwendet man Funktionalität wieder durch das Ableiten von einer Klasse, so ist die Subklasse abhängig von der Elternklasse. Dies macht ein System in vielen Fällen unnötig komplex, schlechter Testbar und erschwert das Austauschen von Funktionalität zur Laufzeit. CCD hat für das korrekte Ableiten das [LSP] Prinzip bereit, das es dabei zu befolgen gilt.
Bei der Komposition verwendet eine Klasse eine andere. Verwendet man dazu eine klar definierte Schnittstelle fördert das die Entkopplung. Auch können verschiedene Implementationen einfach ausgetauscht werden.
Bevor man sich also der Liskov Substitution stellt, fordert FCoI sich die Frage zu stellen, ob man der Komposition nicht Vorrang geben kann.
"Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)
-
Als NG Sprache sollte sie eine IDE wie Delphi haben mit ebensolch viel und chicken Steuerelementen.
Keinen völlig neuen Syntax mit sich bringen. ( Nicht ohne Grund schauen Java und C# da auf C++ ).
GC nur optional.
Neben der Prozeduralen und OOP auch Funktionelle Paradigmen haben.
Effizient in der Ausführung.
-
Zabou schrieb:
Als NG Sprache sollte sie eine IDE wie Delphi haben mit ebensolch viel und chicken Steuerelementen.
Ok windows only; eine meinung die man vertreten kann
Keinen völlig neuen Syntax mit sich bringen. ( Nicht ohne Grund schauen Java und C# da auf C++ ).
Wir hätten niemals voon der Fortran 77 oder Cobol Syntax weggehen sollen.
(die Java/c#/c++ syntax ist schrecklich)GC nur optional.
Wo würden wir hin kommen wenn die echten Profis nicht zeigen können wie cool sie sind indem sie ohne gc arbeiten. Außerdem ist eine gespaltene Gemeinde immer gut.
Neben der Prozeduralen und OOP auch Funktionelle Paradigmen haben.
Prozedural und und (pur) funktional sind bisweilen recht gegesetzlich. Eine Imperative/OOP grundsprache die funktionale Aspekte beinhaltet funktioniert besser (siehe ruby).
Effizient in der Ausführung.
effizienz ist mittelfristig eher viele cores unterstützen als einfach schnell zu sein. Ich kann in laden gehen und einen Mac pro mit 16 (virtuellen) Kernen kaufen. Da kann eine anwendung lieber 5 mal langsamer sein dafür aber 16 core nutzen.
-
IPH schrieb:
Effizient in der Ausführung.
effizienz ist mittelfristig eher viele cores unterstützen als einfach schnell zu sein. Ich kann in laden gehen und einen Mac pro mit 16 (virtuellen) Kernen kaufen. Da kann eine anwendung lieber 5 mal langsamer sein dafür aber 16 core nutzen.
stell dir eine Sprache vor die 16 Cores verwenden kann und 5 mal so schnell ist.
-
Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5
-
IPH schrieb:
Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5
Was, Warum? Die meisten Bildverarbeitungs-, Numerik-, Such/Sortier-algorithmen lassen sich z.B. total einfach parallelisieren, ohne irgendwelchen Sprach-Schnickschnack. Warum braucht ihr da immer ne funktionale Programmiersprache mit was auch immer?
-
knivil schrieb:
Dravere schrieb:
von zum Beispiel C++ ausgehen, dann die Makros und Templates rausschmeissen, dafür in die eigentliche Sprache hinein eine Code-Generator Sprache implementieren. Ich habe mir sogar schon mal Gedanken darüber gemacht,
Lisp, Scheme oder PLT-Scheme.
Nicht das was ich will, sonst würde ich Lisp oder Scheme verwenden und nicht mir Gedanken über eine neue Sprache oder einem Dialekt zu C++ machen.
Grüssli
-
Die Qualitaet des Videos ist nicht besonders berauschend: http://cs.byu.edu/colloquia/2009-02-26 . Aber wieso etwas neues erfinden, wenn es schon alles gibt.
Was, Warum? Die meisten Bildverarbeitungs-, Numerik-, Such/Sortier-algorithmen lassen sich z.B. total einfach parallelisieren, ohne irgendwelchen Sprach-Schnickschnack. Warum braucht ihr da immer ne funktionale Programmiersprache mit was auch immer?
1.) Es ist einfacher, das Problem funktional mit einer parallelen Variante von map zu spezifizieren. Auch paralleles Quicksort etc. sieht fast genauso aus, wie die normale Variante. Sowas nennt man Abstraktion. Um Parallelitaet muss sich nicht mehr explizit gekuemmert werden.
2.) FFT ist nicht trivial parallelisierbar, genauso wenig das numerische Loesen einer Differentialgleichung. Beim Traversieren von Graphen muss man auch aufpassen, wenn man keine Flaschenhaelse einbauen will.
3.) Alle trivialen Faelle sind uninteressant, da sie in jeder Sprache einfach sind. Man braucht Unterstuetzung fuer alle nicht-trivialen.
4.) Ich will mich nicht mehr explizit um die Anzahl der OS-Threads kuemmern, Haskell mit seinen Sparks bietet einen schoenen Ansatz.Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5
Das ist wahrscheinlich ok, der Speedup waere dann immer noch linear in der Anzahl der Knoten. Auch ist die JVM nicht die beste Plattform.
-
knivil schrieb:
Aber wieso etwas neues erfinden, wenn es schon alles gibt.
-
Okay, erwischt.
