Was kommt nach der Objektorientierung?

Xin

Shade Of Mine schrieb:

Ich könnte das ewig weiter führen...

Ich habe mir jetzt Dein ganzes Posting durchgelesen.

Und eigentlich bleibt mir nur, Dir eine Frage zu stellen: Hast Du eigentlich irgendetwas von dem, was ich geschrieben habe gelesen?

Dravere

Xin schrieb:

Und eigentlich bleibt mir nur, Dir eine Frage zu stellen: Hast Du eigentlich irgendetwas von dem, was ich geschrieben habe gelesen?

Ich kann dir sagen, dass ich alle deine Beiträge vollständig durchgelesen habe und den Beitrag von Shade Of Mine voll unterstreiche.

Tipp: Statt immer zu denken, dass die anderen dich nur nicht verstehen, solltest du dir mal überlegen, ob du dich einfach nicht richtig ausdrückst?

Grüssli

Ich hab auf den ersten paar Seiten rumgeschaut, als der Thread erstellt wurde, und jetzt hier die letzten 2 Seiten mal überflogen. Frage: Hat Xin seine Idee mittlerweile verraten oder werden immer noch pseudokonstruktive Metadiskussionen gehalten?

Xin

Dravere schrieb:

Xin schrieb:

Und eigentlich bleibt mir nur, Dir eine Frage zu stellen: Hast Du eigentlich irgendetwas von dem, was ich geschrieben habe gelesen?

Ich kann dir sagen, dass ich alle deine Beiträge vollständig durchgelesen habe und den Beitrag von Shade Of Mine voll unterstreiche.

Tipp: Statt immer zu denken, dass die anderen dich nur nicht verstehen, solltest du dir mal überlegen, ob du dich einfach nicht richtig ausdrückst?

Jetzt mal im Ernst...

Shade Of Mine schrieb:

Vorallem weil du, wenn du so ein Problem noch nicht lösen musstest, es sofort als uninteressant und trivial hinstellst. Wie zB die Diskussion über Decimal und Datenbanken.

Zitat von mir: Für eine Klasse System.Decimal, die man auch in C++ repräsentieren kann auf sinnvolle Sprachfeatures zu verzichten, wie Const-Correctness, C++-Referenzen, Templates oder Mehrfachvererbung, halte ich für sehr fraglich. Diese Sachen sind in C# nicht repräsentierbar.

Da steht nichts von uninteressant. Da steht in C++ machbar. Und ob das trivial ist, müssen wir da ernsthaft drüber streiten? Bitte Hand hoch, wer eine Klasse, die Dezimalzahlen repräsentiert, als nicht trivial einstuft.

Shade Of Mine schrieb:

Ich habe schon verstanden, alles was du nicht in C++ schon gemacht hast, ist irrelevant und braucht man nicht. Soviel ist schon rüber gekommen

Zitat von mir zu einer solchen Behauptung: "Es gilt darum gute Lösungen für Probleme zu finden. Eine beliebte Lösung muss deswegen nicht richtig sein. Ein für mich uninteressantes Problem bleibt aber wichtig."

Ich weiß nicht, wogegen ich hier noch anreden soll. Ich weiß auch nicht, was bei Shade of Mine so rüberkommt, denn entweder muss ich hier jedem einzelnen dreimal erklären dass ich hier niemanden schlachten will, nur weil er nicht Java hasst oder ich weiß es auch nicht.

Shade Of Mine schrieb:

Also sind wir vielleicht schon so weit gekommen, dass wir aktzeptieren können dass C++ doch nicht immer ideal ist?

Zitat von mir: "Klar. Ich habe nie gesagt, dass andere Sprachen grundsätzlich schlecht sind - im Gegenteil. Ich sage, dass unterm Strich, wenn ich eine Sprache wählen muss, die Wahl auf C++ fällt, weil der Rest nicht an C++ rankommt."

Sorry, Leute... aber teilweise verlangt ihr von mir, dass ich mich für Sachen rechtfertigen muss, die von mir nicht in den Raum gestellt werden.
Gleichzeitig fragte ich mich, wer hier eigentlich den Sinn des Threads versteht. Es geht hier nicht um einen Schwanzvergleich gegenwärtiger Techniken. Es geht um einen Schwanzvergleich in der der Zukunft. Welche Sprache hat die beste Chance auf eine Zukunft?

Fassen wir vielleicht mal möglichst kurz zusammen, was meine Position ist.

Ich habe nie behauptet, dass C++ für alles ideal ist. Ich behaupte, dass C++ für große Projekte aufgrund der semantischen Stärke ideal ist, selbst dann, wenn es in einigen Teilen Mehraufwand bedeutet. Darum implementiere ich mein CMS in C++. Ich erwarte, dass dieses Projekt ein großes Projekt wird.

Dieser Thread dreht sich nicht um einen Schwanzvergleich von vorhandenen Techniken, sondern um die Frage, was morgen kommt. Es ist also durchaus legitim anzunehmen, dass C++ eine ähnlich ausgefeilte Library erhält, wie Java oder C# und diese Idee würde vermutlich nicht an einer Klasse für Dezimalzahlen scheitern.

Dynamische Typbehandlung zur Laufzeit ist mit statischen Sprachen möglich. Diese Behauptung stelle ich jetzt mal unbegründet in den Raum. Damit sollte wohl auch niemand ein Problem haben, oder etwa doch? Hat jemand Probleme sich die Konsequenzen vorzustellen?

Wir haben mit Java und C# zwei neue Linker erhalten. Sieht jemand ein Problem damit, das aktuelle Objektformat anzupassen und zu modernisieren? Oder zu ersetzen und mit einem Kompatiblitätslayer auszustatten? Wäre das eine Alternative gewesen zu zwei VMs, zwei JIT Compiler und den Verzicht auf bedeutende Sprach-Features?

Meine Meinung wäre, dass das die Zukunft darstellt und wir das Thema schon abgehakt hätten, wenn Java nicht in die Quere gekommen wäre. Weil wichtige Features entfernt wurden, halte ich Java für große Projekte für bedenklich - unabhängig davon, dass es trotzdem große Projekte in Java gibt - und Java für einen Behinderung der Sprachevolution von etwa 15 Jahren.

Diese Aussage steht so.

Und bevor jetzt dazwischen gegrätscht wird: Die Behauptung, dass es in Java und inbesondere in C# deswegen keine parallele Weiterentwicklung gegeben hätte, steht da nicht. Da steht auch nicht, dass Entwicklungen, die in C# und Java stattgefunden haben, in C++ aktuell ohne Mehraufwand zu übernehmen sind. Da steht, dass diese Weiterentwicklungen in C++ nachgepflegt werden müssen und ich der Überzeugung bin, dass C++ mit diesen Weiterentwicklungen am längsten überleben wird und dass wir etwa 15 Jahre verloren haben.
Da steht nicht, dass Normalfall-Projekte existieren, die in C# oder Java einfacher zu lösen sind. Derartige Schlussfolgerungen wurden von mir auch nicht provoziert - im mich da nochmal zu zitieren: "Lösungen für den Normalfall findest Du bei Java und C#."

Xin

TravisG schrieb:

Ich hab auf den ersten paar Seiten rumgeschaut, als der Thread erstellt wurde, und jetzt hier die letzten 2 Seiten mal überflogen. Frage: Hat Xin seine Idee mittlerweile verraten oder werden immer noch pseudokonstruktive Metadiskussionen gehalten?

Seinen Ansatz hat er bereits ganz am Anfang verraten.

Ansonsten seine? Eine? Wie 1.0?

Wenn ich eine Version als 1.0 bezeichne, dann wird die Laufen, aber nur ein grundlegendes Subset darstellen und eher die Basis für nachfolgende Versionen. Das Ziel für eine 1.0 ist lediglich es mir nicht dahingehend zu versauen, Dinge zu erweitern, die ich bis zur 1.0 noch nicht kenne. (PS: und natürlich den Boden für bekannte Ideen vorzubereiten - bevor da einer wieder "Subset" nicht versteht und loslegt, dass man keine neue Sprache braucht, die nur läuft... btw... Subset beinhaltet auch, dass Features bereits implementiert sind, die in anderen Sprachen so nicht aufkommen. Und ja, ich lasse das jetzt einfach so stehen, keiner muss irgendwas glauben, in dem Thread ging es nicht um eine Syntaxbeschreibung, sondern nur um die zukünftige Weiterentwicklung und den Ansatz ist ja schon beschrieben.)

Für eine Idee fange ich doch kein neues Projekt in der Größe an...

o4kareg

funktionale Sprachen sind nicht neu eigentlich die Ideen sind älter als imperative sprachen die sind mit Assembler x86 verbunden, rescherschiere mal
nach LISP sprache und maschine.

Es könnte aber kommen:

1)Echte Modelgetriebene Software Entwicklung: d.h. letzt endlich selbst IDE soll generiert und auf konkretes Domän angepasst werden. Bis jetzt beispiele von generierten IDES => keins :D. Dazu gehöhren auch GUI IDES auch nicht so viel geile Heute.

2)(eventuell Macro)Funktionen/Methoden auf Modulen bzw grossen Container als ein Class.

3)Implizierte Paralelisierung eventuell auf GPGPU oder verteilte (wie HAdoop)
(du schreibst einfacher set... add... Code und es wird umgewandelt in paraleles

Übrigens, Implizierte Paralelisierung von Haskell (dialect eden heisst es ) is gar nicht neu da geht: Eden => paraleller C code => verteilt auf maschienen

Dies ist unglaublich grosse Problemen mit denen man wird beschäftigen über die ganz grosse Zeitraum.

Shade Of Mine

Xin schrieb:

Da steht nicht, dass Normalfall-Projekte existieren, die in C# oder Java einfacher zu lösen sind. Derartige Schlussfolgerungen wurden von mir auch nicht provoziert - im mich da nochmal zu zitieren: "Lösungen für den Normalfall findest Du bei Java und C#."

Was ist eigentlich dieser Normalfall von dem du immer sprichst?

Aber naja, ich habe zB auf meine Aussage hin, dass ein 10 Zeiler in einer Scriptsprache für Textersetzung besser ist als ein C++ Programm, von dir als Antwort bekommen dass mir einfach nur gute String Klassen in C++ fehlen.

Was genau wolltest du damit dann ausdrücken? Ich habe das so verstanden, dass wenn ich eine bessere String Klasse als std::string hätte, C++ eine bessere Lösung gewesen wäre.

uU reden wir aneinander vorbei?

Shade Of Mine

Xin schrieb:

Dynamische Typbehandlung zur Laufzeit ist mit statischen Sprachen möglich. Diese Behauptung stelle ich jetzt mal unbegründet in den Raum. Damit sollte wohl auch niemand ein Problem haben, oder etwa doch? Hat jemand Probleme sich die Konsequenzen vorzustellen?

Technisch möglich ist alles. Aber ist auch alles immer sinnvoll?

zB finde ich in C# die Trennung Value Typen und Referenz Typen richtig cool. Aber in der Praxis ist das nicht immer so toll. Ähnlich wie in C++/CLI wo es manchmal furchtbar unpraktisch ist, dass es unterschiede zwischen native und managed Klassen gibt - wobei die Idee ganz nett ist (und manchmal ja auch richtig toll ist).

Ich denke nicht, dass man alles in eine Sprache stecken sollte. Ein gutes Beispiel hier ist C++/CLI. Es hat viele managed Features und dennoch alle C++ Features. Aber in der Praxis ist es meh...

Wir haben mit Java und C# zwei neue Linker erhalten. Sieht jemand ein Problem damit, das aktuelle Objektformat anzupassen und zu modernisieren? Oder zu ersetzen und mit einem Kompatiblitätslayer auszustatten? Wäre das eine Alternative gewesen zu zwei VMs, zwei JIT Compiler und den Verzicht auf bedeutende Sprach-Features?

Bedeutende Sprachfeatures? Nicht wirklich. C# geht nicht wirklich was wichtiges ab. C# und Java sind problemlos für Enterprise Projekte verwendbar.

Du sagst zB die wichtigen Features die fehlen sind
Const-Correctness -> wird ersetzt durch Immutable Types
C++-Referenzen -> hier sehe ich nicht wirklich was relevantes. Referenzen sind Syntax Zucker. Einzig relevanter Vorteil ist, dass man damit defensive Kopien verhindert - was man in Java zB über Interfaces löst.
Templates -> Generics. Natürlich sind Templates mächtiger als Generics, aber prinzipiell sind es wieder 2 Lösungen für 1 Problem. Je nach Situation ist das eine oder andere besser.
Mehrfachvererbung -> dafür bietet Java eben Interfaces, die in einigen Situationen viel besser sind als Mehrfachvererbung. Alles in allem sehe ich hier keinen riesen Unterschied.

Und was genau willst du haben? Binäre Kompatibilität von C# zu Java? Oder worauf genau zielst du ab? Das mit Linker habe ich nicht verstanden...

Meine Meinung wäre, dass das die Zukunft darstellt und wir das Thema schon abgehakt hätten, wenn Java nicht in die Quere gekommen wäre. Weil wichtige Features entfernt wurden, halte ich Java für große Projekte für bedenklich - unabhängig davon, dass es trotzdem große Projekte in Java gibt - und Java für einen Behinderung der Sprachevolution von etwa 15 Jahren.

Ich denke, dass Java sehr viel für die Computerwelt getan hat. Aber diese Diskussion ist rein hypothetisch. Niemand kann sagen was gewesen wäre wenn es Java nie gegeben hätte. Alleine der Blickwinkel den Java uns auf Softwareentwicklung eröffnet hat, ist mehr Wert als alles andere.

Auch wenn ich viele Sachen in Java nicht gut gelöst finde, so ist es doch eine tolle Mainstream Sprache. Selbst wenn man die Einfachheit mit der sich Java Programme erstellen lassen als einzig positives aufführt, so wäre es das immernoch wert gewesen.

C++ ist enorm komplex. Man braucht Jahre um es zu verstehen. Die Entwicklungskosten in C++ sind einfach hoch. Und mit C++0x ist es auch nicht wirklich besser geworden. Die Sprache ist ziemlich übersättigt mit Features und Sprachkonstrukten. Ich denke nicht dass es so toll wäre da noch eine Menge mehr Features reinzupacken.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Da steht nicht, dass Normalfall-Projekte existieren, die in C# oder Java einfacher zu lösen sind. Derartige Schlussfolgerungen wurden von mir auch nicht provoziert - im mich da nochmal zu zitieren: "Lösungen für den Normalfall findest Du bei Java und C#."

Was ist eigentlich dieser Normalfall von dem du immer sprichst?

GUI, Datenbank, Dateizugriff, Kommunikation.
Eben das worauf sich C# und Java spezialisierten, weil es Normalfall ist.

Kein Normalfall: Systemprogrammierung, Echtzeitgrafik, hoch effiziente Algorithmen. Es ist schade, dass diese Normalfall-Frameworks in C++ eher verstreut sind als unter z.B. std::gui zu finden sind. Und auch std::string ist mehr Container als sinnvoll nutzbare String-Klasse.

Hier kann man aber durchaus ansetzen und hätte man das vor 15 Jahren begonnen, hätte man die Zeit nicht verloren. Das Problem ist schließlich, dass solche Algorithmen von Entwicklern ausgelagert werden, die vielleicht Java fit sind, aber nicht in C++. Die Erfahrung reicht einfach nicht mehr für den Spezialfall. Der Normalfall sollte in meinen Augen aber Training für den Spezialfall sein und das funktioniert nur, wenn man eine Sprache hat, die Normalfall und Spezialfall abdecken kann.

Zumal z.B. im Job C#, Fortran, Python und C++ verwendet werden und die Zwischenschichten ein Spezialfall für sich sind. Diesen Spezialfälle brauchen wir nur, weil jede Sprache angeblich für irgendwas besonders gut geeignet ist. Ich könnte auch gut drauf verzichten.

Shade Of Mine schrieb:

Aber naja, ich habe zB auf meine Aussage hin, dass ein 10 Zeiler in einer Scriptsprache für Textersetzung besser ist als ein C++ Programm, von dir als Antwort bekommen dass mir einfach nur gute String Klassen in C++ fehlen.

Stimmt doch auch. Jede Skriptsprache hat doch bessere String-Verarbeitung als C++ mit den std::strings. Aber das sind Erweiterungen zu C++, die standardmäßig mitgeliefert werden. Ich halte es für legitim davon auszugehen, dass zukünftige std::strings eher an die Bedürfnisse von Strings angelehnt sind, dann würden meine Strings oder QStrings auch keinen Sinn mehr ergeben. Ich schreibe meine String-Klasse ja auch nicht, weil ich nichts besseres zu tun habe, sondern weil ich mit std::string nichts Sinnvolles anfangen kann, wenn ich Strings verarbeiten will.
STL ist gut und schön, aber das will doch keiner für "Normalfall"-Aufgaben.

Was auf den ersten Blick in C++ schwieriger wird ist Boiler-Plate zu entfernen. int main(void) für kleines Skript braucht kein Mensch. Ist bei mir nicht erforderlich, der erste Befehl leitet main() ein (sowie die Klasse, die main enthält und das Projekt, das wiederum die Klasse enthält) und main endet am Ende der Datei.

emit "Hello World";

Auch sowas kann man problemlos durch einen Compiler jagen. Das geht nicht nur bei Skriptsprachen. Es kann auch die vollständige Implementation eines Plugins darstellen, wenn man dem Compiler das von außen mitteilt.

Das erfolgte aber weniger Aufgrund von Skripts, als durch die Tatsache, dass ich C-Schülern erstmal ein Hello World vorsetzen muss und dann erklären darf, was Datentypen (int, void), Funktionen, Rückgabewerte oder Includes sind und dass man diese komischen Klammern halt machen muss, weil irgendwer das in den 70ern für sinnvoll erachtete sind. Bei C++/C#/Java werfen wir dann noch Namensräume und Klassen rein. Bevor ich dann bei "Hallo Welt" angekommen sind verstehen die nur noch Bahnhof. Oder ich unterrichte in der Form "Das müsst ihr jetzt noch nicht verstehen", bei solchen Dozenten frage ich mich aber immer, warum ich dann da sitze.
So kann man Step by Step aufbauen, was da im Hintergrund abgeht, bekommt man dann mit, wenn es interessant wird.

Shade Of Mine schrieb:

Was genau wolltest du damit dann ausdrücken? Ich habe das so verstanden, dass wenn ich eine bessere String Klasse als std::string hätte, C++ eine bessere Lösung gewesen wäre.

Nein. C++ wäre eine Lösungsmöglichkeit gewesen. Und eine, die in der aktuellen Fassung reichlich BoilerPlate hervorruft.

Aber dieser Thread geht um die Zukunft von Programmiersprachen, vielleicht habe ich schonmal daran erinnert Es gibt keinen Grund, warum C++18 nicht vielleicht sinnvolle Strings mitliefert. Eventuell spart man sogar die 5 Zeilen Boiler-Plate, aber die 5 Zeilen machen es dann auch nicht.

Shade Of Mine schrieb:

uU reden wir aneinander vorbei?

Ich habe das Gefühl, dass aus meinen Aussagen Dinge interpretiert werden, die da nicht stehen und die auch nicht logisch daraus geschlossen werden können. Ich schreibe hier auch keinen Fachaufsatz, sodass ich auch nicht ausschließen kann, dass jeder Satz frei jeglicher Interpretation ist, aber in dem Fall kamen bisher eher weniger Rückfragen, als deutlicher Gegendruck zu den schlechtmöglichsten Interpretationen meiner Aussagen.

Anders ausgedrückt, es ist sehr stark davon auszugehen, dass wir (und andere) komplett aneinander vorbei reden, deswegen rücke ich die Dinge ja auch immer auf den Standpunkt zurück, den ich hier vertrete.
Würden ich nicht davon ausgehen, dass wir aneinander vorbeireden, würde ich diesen Thread tatsächlich als gezielten Angriff und beleidigend betrachten.

Jodocus

Ich bin zwar nur hobbymäßig an C++ interessiert, aber ich schalte mich hier trotzdem mal ein:

> Es ist schade, dass diese Normalfall-Frameworks in C++ eher verstreut sind als unter z.B. std::gui zu finden sind.

GUIs sind für ein allgemeines C++ viel zu speziell. Niemand wäre mit einer std::gui zufrieden, weil die einen Ribbons haben wollen, die anderen irgendein Linux-Widget, was Windows nicht hat.

Stroustrup schrieb:

I fear that GUI is too complex and too controversial topic for the standards committee. The committee consists of volunteers and we don't have the resources to build a major GUI library. Also, a standards committee can't compete with commercial (and non-commercial) vendors.

Die 3rd-Party-Libraries für GUIs sind einfach immer besser, da kann eine standardisierte Library einfach nicht mithalten.

> Und auch std::string ist mehr Container als sinnvoll nutzbare String-Klasse.

Was erwartest du denn von einem String? Ich fand std::string bisher vollkommen okay. Viele mögen String nicht, weil sie nicht begreifen, dass stringstream (oder überhaupt Streams) diese Aufgaben hat, die sie string irgendwie ankleben wollen.
Wenn dir ein Algorithmus für std::string fehlt, kannst du ganz einfach einen in Form einer freien Funktion hinzufügen. Ich halte std::string für vollkommen okay.

Ich spreche evtl. im Interesse vieler, aber was ist überhaupt Xins Problem? Wir sind uns alle einig, dass C++ nicht die eierlegende Wollmichsau ist, dass aber C++ eher eierlegende Wollmichsau als Java oder C# ist. Alle Sprachen haben ihre Daseinsberechtigung. Wenn sie keine hätten, würden sich nicht mehr existieren. Für Aufgaben, die Java nun mal besser als C++ kann, ist Java auch geeignet. Das ist gesunder Menschenverstand.
Wo ist das Problem?

otze

Ich möchte mich mal von einer anderen Seite an das Problem annähern:

ich glaube, dass wenn es noch eine Sprache gibt, die sich in einem Bereich durchsetzt, es keine All-Purpose-Language, sondern eine DSL sein wird. Sollte eine Sprache im All-Purpose-Language erfolg haben wollen, muss sie entweder
a) ein Übersetzungsmodell in eine andere All-Purpose-Language
oder b) komplette Abwärtskompatibilität zu einer etablierten All-Purpose-Language
besitzen

Warum?
Die Programme werden immer Größer und komplexer. Programmiersprachen müssen daher Werkzeuge bieten, die diese Komplexität reduzieren. All-Purpose-Languages können dies aber nur in einem begrenzten Bereich, da für die Reduktion der Komplexität ab einem bestimmten Level spezifisches Wissen über das Problem erforderlich ist. Es ist zum Beispiel nicht davon auszugehen, dass eine Hochsprache jemals so gutes stringhandling bieten wird, wie Perl, oder andere Sprachen die extra dafür erschaffen wurden und keine anderen Probleme mehr lösen müssen.

Wir werden daher mehr Diversität in den verwendeten Sprachen erleben und damit in den verschiedenen Bereichen auch unterschiedliche Programmierparadigma. Gleichzeitig wird der Einfluss von universellen Sprachen zurückgehen und auch hier wird sich jede Sprache eine eigene Nische suchen. Was wichtiger wird, ist aber die Anbindung an die DSLs. Hier liegt Java durch die JIT-Technologie momentan ziemlich weit vorn.

Jede neue Sprache wird sich von nun an die Frage erlauben müssen, welches Problem sie lösen will. "Besser als andere Sprachen" zu sein, reicht nicht mehr aus.

Xin

Shade Of Mine schrieb:

Du sagst zB die wichtigen Features die fehlen sind
Const-Correctness -> wird ersetzt durch Immutable Types
C++-Referenzen -> hier sehe ich nicht wirklich was relevantes. Referenzen sind Syntax Zucker. Einzig relevanter Vorteil ist, dass man damit defensive Kopien verhindert - was man in Java zB über Interfaces löst.

Immutable Types sind eine Möglichkeit, kosten aber. Was kostet und nicht abschaltbar ist, wird keine andere Nische besetzen können.

Referenzen sind alles andere als Zucker... sonst wären sie so handlich wie es Zeiger sind.

Shade Of Mine schrieb:

Templates -> Generics. Natürlich sind Templates mächtiger als Generics, aber prinzipiell sind es wieder 2 Lösungen für 1 Problem. Je nach Situation ist das eine oder andere besser.

Stimmt und beide haben Berechtigung. Es ist eben nicht zwei Lösungen für ein Problem, sondern es sind semantisch vollkommen unterschiedliche Konstrukte.

Shade Of Mine schrieb:

Mehrfachvererbung -> dafür bietet Java eben Interfaces, die in einigen Situationen viel besser sind als Mehrfachvererbung. Alles in allem sehe ich hier keinen riesen Unterschied.

Ich programmiere jetzt seit 18 Jahren C++. Was mir bisher niemand erklären konnte war, wo eigentlich Interfaces besser sein sollen als Mehrfachvererbung. Das interessiert mich ehrlich, denn bisher sehe ich in Interfaces nur Nachteile.

Shade Of Mine schrieb:

Und was genau willst du haben? Binäre Kompatibilität von C# zu Java? Oder worauf genau zielst du ab? Das mit Linker habe ich nicht verstanden...

Die Objectfiles sind nicht geeignet Klassen abzubilden, was zu überflüssigem Aufwand führt, den man mit C# oder Java so nicht hat.

Shade Of Mine schrieb:

C++ ist enorm komplex. Man braucht Jahre um es zu verstehen. Die Entwicklungskosten in C++ sind einfach hoch. Und mit C++0x ist es auch nicht wirklich besser geworden. Die Sprache ist ziemlich übersättigt mit Features und Sprachkonstrukten. Ich denke nicht dass es so toll wäre da noch eine Menge mehr Features reinzupacken.

Womit wir an dem Punkt wären, wo ich vor Seiten schon schrieb, dass C++ scheiße ist - aber trotzdem das beste, was wir haben.

---------------------------------

Jodocus schrieb:

Ich bin zwar nur hobbymäßig an C++ interessiert, aber ich schalte mich hier trotzdem mal ein:

> Es ist schade, dass diese Normalfall-Frameworks in C++ eher verstreut sind als unter z.B. std::gui zu finden sind.

GUIs sind für ein allgemeines C++ viel zu speziell. Niemand wäre mit einer std::gui zufrieden, weil die einen Ribbons haben wollen, die anderen irgendein Linux-Widget, was Windows nicht hat.

Normal, die meisten wollen einfach ein Fenster haben und das ist abbildbar.

Ich bin mit Stroustrups Vision durchaus ganz gut vertraut. Und ich bin in vielen Dingen sogar sehr ähnlich gepolt wie Stroustrup. Aber nicht in allen. Ich weiß, dass grundlegende GUI realisierbar ist - das beweist Qt, wxWidgets und gtk.
Wer Ribbons will, muss sich dann ggfs. außerhalb des Standards bedienen. std::gui wäre eine naheliegende Möglichkeit, keine Pflicht.
Erklären wir einfach mal wxWidgets zu std::gui. Viele Fälle könnte man damit bereits abdecken, insbesondere den Normalfall. Mal eben ein kleines Tool hier... Mal fünf Buttons und ein Listview... wie man es in WinForms auch zusammenklatscht.

Jodocus schrieb:

> Und auch std::string ist mehr Container als sinnvoll nutzbare String-Klasse.

Was erwartest du denn von einem String? Ich fand std::string bisher vollkommen okay.

Zu weit weg aus der Sprache - Strings sind nicht nur Normalfall, sondern absolut grundlegend und sollten entsprechend grundlegend von der Sprache unterstützt werden, wie in Perl oder Python.

Jodocus schrieb:

Ich spreche evtl. im Interesse vieler, aber was ist überhaupt Xins Problem?

Wie kommst Du darauf, dass ich ein Problem hätte? Wir diskutieren hier Möglichkeiten der Zukunft. Das wäre eine Lösung, aber kein Problem. Wenn Du alles okay findest, hast Du erst recht kein Problem.

---------------------------------

otze schrieb:

ich glaube, dass wenn es noch eine Sprache gibt, die sich in einem Bereich durchsetzt, es keine All-Purpose-Language, sondern eine DSL sein wird. Sollte eine Sprache im All-Purpose-Language erfolg haben wollen, muss sie entweder
a) ein Übersetzungsmodell in eine andere All-Purpose-Language
oder b) komplette Abwärtskompatibilität zu einer etablierten All-Purpose-Language
besitzen

So sieht's aus.

otze schrieb:

Wir werden daher mehr Diversität in den verwendeten Sprachen erleben und damit in den verschiedenen Bereichen auch unterschiedliche Programmierparadigma. Gleichzeitig wird der Einfluss von universellen Sprachen zurückgehen und auch hier wird sich jede Sprache eine eigene Nische suchen. Was wichtiger wird, ist aber die Anbindung an die DSLs. Hier liegt Java durch die JIT-Technologie momentan ziemlich weit vorn.

Und hier gehen wir ganz entschieden wieder auseinander. Ich sehe in Java bestenfalls einen Übergang und den auch weniger in Java als der der mitgelieferten VM.

otze schrieb:

Jede neue Sprache wird sich von nun an die Frage erlauben müssen, welches Problem sie lösen will. "Besser als andere Sprachen" zu sein, reicht nicht mehr aus.

Und genau das versuche ich umzusetzen. Mit einigen hundert Detailverbesserung in der Basissprache, wo ich gerade schonmal dabei bin...

Mechanics

@Xin: keine Lust zu quoten, zu viel Text. tl;dr wäre hier nicht ganz verkehrt, aber ich find den Thread doch irgendwie lustig deswegen hab ichs gelesen...

Kurz nochmal wegen Qt vs. Winforms. Ich wills ja nicht so hinstellen, als ob ich Qt nicht mögen würde, ich mags ja. Aber es kann wirklich nichts, was Winforms nicht auch kann, bzw. ich vermisse da nichts. Internationalisierung in Winforms ist doch völlig ok gelöst. Das ist nicht viel Aufwand, dafür ist es flexibel und du kriegst perfekte Ergebnisse hin, wenn du etwas Arbeit reinsteckst. Qt ist sprachbedingt (;)) etwas unflexibel. z.B. dieses MVC Modell. Es ist ja an sich toll und ich finds echt super im C++ Umfeld, sowas ist MFC Lichtjahre voraus. Aber es ist doch irgendwo auch unflexibel und funktioniert nur in den Fällen gut, an die die Qt Entwickler auch gedacht haben. In anderen Fällen mag es mit viel Aufwand und Workarounds halbwegs funktionieren, und es gibt Fälle, da wirds richtig übel... Aber ich will mich nicht beschweren, ich bin damit auch soweit auch ziemlich zufrieden und es ist das beste, was ich in C++ kenne. Nur sehe ich keinen Grund zu sagen, es wäre besser als Winforms oder gar WPF. Und was Layouts in Qt angeht, habe ich sie in Winforms nie vermisst. Es ist ein anderes Layouting Konzept, aber es funktioniert genauso gut, nur nicht so umständlich und fehleranfällig. Ist nicht immer ganz einfach mit den ganzen QLayouts durchzublicken, wo man sich vertan hat, wo eine falsche SizePolicy gesetzt ist usw.

Du hast auch mal geschrieben, dass C++ für große Projekte wegen der semantischen Stärke ideal ist. Hier sind wir einer Meinung. Ich wollte auch unbedingt an einem großen Projekt in C++ mitarbeiten und tu es auch. Bei großen Projekten spielen die meisten Probleme von C++ keine so entscheidende Rolle mehr und C++ kann seine Stärken besser ausspielen. Hier hat dir ja auch niemand widersprochen. Was die meisten hier versuchen klar zu machen ist, dass es sehr viele Projekte gibt (wahrscheinlich 90% oder mehr), wo C++ einfach nicht die beste Wahl ist. Die meisten Entwickler verdienen ihr Geld mit deutlich kleineren Projekten (wozu ich auch mittelgroße Projekte zähle, die widerum auch deutlich in der Unterzahl sind verglichen mit den ganz kleinen Projekten). Und bei solchen Projekten passt C++ einfach nicht, bzw. sie wären in anderen Sprachen 10x schneller und eleganter gelöst.

Echtzeitgrafik und "hocheffiziente Algorithmen" sind auch so ein Thema... Die sind in C++ nicht automatisch schneller. Sehe ich leider an unserer Software. Da gibt es sowohl hochkomplexe und hocheffiziente Algorithmen als auch Echtzeitgrafik. Ist alles in C++ geschrieben. Trotzdem ist sehr vieles sehr ineffizient und könnte man auch in Java 10x performanter schreiben. Weil die Software sehr stark gewachsen ist, sehr viel kann, sehr viele Sonderfälle berücksichtigen muss usw... Obwohl das Design insgesamt durchaus nicht katastrophal ist und viele Komponenten eigentlich richtig gut sind, ist das Gesamtgebilde nicht sehr gut wartbar/erweiterbar und überhaupt nicht performant. Komplettes Redesign (unter Berücksichtigung aller nun bekanten Anforderungen) wäre angebracht, ist aber von Kosten und vom Aufwand her überhaupt nicht drin. Deswegen bringen da auch einzelne hocheffizient (und Assembler-optimierte) implementierte Algorithmen gar nichts, wenn außen rum noch tausend andere Sachen ausgeführt werden und das ganze dann ewig dauert. Also, C++ ist noch lange nicht automatisch performant. Und ein Performance Unterschied von 10% lässt sich ganz leicht und billig durch einen etwas schnelleren Rechner ausgleichen.

otze

Xin schrieb:

Und genau das versuche ich umzusetzen. Mit einigen hundert Detailverbesserung in der Basissprache, wo ich gerade schonmal dabei bin...

Ich glaube, dass wir immer noch aneinander vorbei reden. Ich glaube, dass der Markt nur noch Platz für sehr spezielle Sprachen hat. Sprachen wie matlab, die auf eine einzige Problemkategorie ausgelegt sind (in dem Fall: mathematische Probleme) und bei allen anderen Problemstellungen beliebig schlecht sind. Das heißt, das sich Platz für kleine Sprachen sehe, die sich einfach in andere Hochsprachen einbetten lassen. Meinetwegen auch durch direkte Codeübersetzung. Compilerzeit ist mir egal, was teuer ist ist meine Entwicklungszeit(und die Bugsuche durch zu hohe Komplexität).

Was ich mir zum Beispiel wünschen würde, ist eine funktionale Sprache basierend auf Prinzipien des data-oriented-programming* die für (nicht)-lineare Algebra ausgelegt ist. Mein jetziges Projekt ließe sich sicherlich mit so etwas in einem 10tel des Codes verglichen mit C++ implementieren.

Antoras

@Xin

Was mich interessieren würde, ist, in welchen genauen Anwendungsbereich Genesys passen soll. Soll die Sprache im großen und ganzen eine bessere Alternative zu C++ und dessen Stärken sein (z.B. Performance) oder auch in Teilbereiche passen in denen andere Programmiersprachen stärker sind (z.B. hohe Abstraktionen und statische Typsicherheit wie bei Haskell oder Scala)?

Bisher meine ich herauslesen zu können, dass Genesys dabei helfen soll performant implementierte Algorithmen statisch sicherer umsetzen zu können oder deren Wiederverwendung durch mehr Generizität verbessern soll. Ist das korrekt? Wenn ja, soll man diese Generizität auch in abstrakterer Form (deklarative Beschreibung von Algorithmen wie in der funktionalen Programmierwelt) einsetzen können?

TyRoXx

Xin schrieb:

Jodocus schrieb:

Ich bin zwar nur hobbymäßig an C++ interessiert, aber ich schalte mich hier trotzdem mal ein:

> Es ist schade, dass diese Normalfall-Frameworks in C++ eher verstreut sind als unter z.B. std::gui zu finden sind.

GUIs sind für ein allgemeines C++ viel zu speziell. Niemand wäre mit einer std::gui zufrieden, weil die einen Ribbons haben wollen, die anderen irgendein Linux-Widget, was Windows nicht hat.

Normal, die meisten wollen einfach ein Fenster haben und das ist abbildbar.

Ich bin mit Stroustrups Vision durchaus ganz gut vertraut. Und ich bin in vielen Dingen sogar sehr ähnlich gepolt wie Stroustrup. Aber nicht in allen. Ich weiß, dass grundlegende GUI realisierbar ist - das beweist Qt, wxWidgets und gtk.
Wer Ribbons will, muss sich dann ggfs. außerhalb des Standards bedienen. std::gui wäre eine naheliegende Möglichkeit, keine Pflicht.
Erklären wir einfach mal wxWidgets zu std::gui. Viele Fälle könnte man damit bereits abdecken, insbesondere den Normalfall. Mal eben ein kleines Tool hier... Mal fünf Buttons und ein Listview... wie man es in WinForms auch zusammenklatscht.

Qt ist ein aufgeblasenes Monstrum, das "Handy mit dem man sogar telefonieren kann". Grundlegend ist etwas ganz anderes.
wxWidgets ist so hässlich, dass man es nicht C++ nennen darf.
GTKmm ist in Ordnung, aber auch noch viel zu umfangreich für C++.

Mit dem jetzigen Standardisierungskonzept und den extrem hohen Qualitätsansprüchen würde es 30 Jahre dauern, bis man sich auf ein std::gui geeinigt hätte. Dann nochmal 20 Jahre, bis Microsoft das halbwegs implementiert hat. Ob dann überhaupt noch GUIs in der heutigen Form benutzt werden, ist äußerst fraglich.

Sinnvolle Ergänzungen wären beispielsweise Dateisystem und Netzwerk.

Xin

Mechanics schrieb:

Kurz nochmal wegen Qt vs. Winforms. Ich wills ja nicht so hinstellen, als ob ich Qt nicht mögen würde, ich mags ja. Aber es kann wirklich nichts, was Winforms nicht auch kann, bzw. ich vermisse da nichts.

Ich habe das ich vorhin schon bei Shade of Mine markiert.

Ich bitte darauf zu achten, dass man mir im Thread vorgeworfen hat, mich nur für meinen Bedarf zu interessieren. Das funktioniert so aber nicht, wenn dann Argumentationen so ablaufen.

Mechanics schrieb:

Internationalisierung in Winforms ist doch völlig ok gelöst. Das ist nicht viel Aufwand, dafür ist es flexibel und du kriegst perfekte Ergebnisse hin, wenn du etwas Arbeit reinsteckst

Wir machen das in der Firma. Es ist eine Katastrophe. Absolutes Nogo.

Tut mir leid, da bin ich selbst vom Amiga aus den frühen 90ern besseres gewohnt.

[quote="Mechanics"]Ich programmiere wenig GUI, bzw. habe in den letzten 10 Jahren kaum GUI geschrieben. Davon vieles in WinForms. Mit Gtk habe ich vor ca. 7 Jahren was aufwendiges fabriziert, aber GUI ist so... langweilig. Ich lerne zurzeit Qt, weil sich wieder ein wenig GUI abzeichnet. Ich kann es also mit WinForms nicht vergleichen. Layouts sehe ich nicht als Problem an, das hat jede andere GUI Lib auch - also außer WinForms und MFC...

Mechanics schrieb:

Du hast auch mal geschrieben, dass C++ für große Projekte wegen der semantischen Stärke ideal ist. Hier sind wir einer Meinung.

Ich verbuche das mal als Erfolgserlebnis

Mechanics schrieb:

Die meisten Entwickler verdienen ihr Geld mit deutlich kleineren Projekten (wozu ich auch mittelgroße Projekte zähle, die widerum auch deutlich in der Unterzahl sind verglichen mit den ganz kleinen Projekten). Und bei solchen Projekten passt C++ einfach nicht, bzw. sie wären in anderen Sprachen 10x schneller und eleganter gelöst.

Kommt auf die Frameworks an, die man so griffbereit hat. Ein Kollege fragte mich mal, mit welcher Sprache er ein Problem lösen soll, weil das in C++ so kompliziert. Ich habe ihm knapp 20 Klassen aus meinem Framework kopiert, am nächsten Tag war er fertig und total begeistert.

Der Mangel an offensichtlichen Hilfsmitteln ist in C++ aktuell ein Problem. Aber das lässt sich ja ändern. Für mich tue ich das und so füllt sich mein Framework über die Jahre.

Mechanics schrieb:

Echtzeitgrafik und "hocheffiziente Algorithmen" sind auch so ein Thema... Die sind in C++ nicht automatisch schneller. Sehe ich leider an unserer Software. Da gibt es sowohl hochkomplexe und hocheffiziente Algorithmen als auch Echtzeitgrafik. Ist alles in C++ geschrieben. Trotzdem ist sehr vieles sehr ineffizient und könnte man auch in Java 10x performanter schreiben. Weil die Software sehr stark gewachsen ist, sehr viel kann, sehr viele Sonderfälle berücksichtigen muss usw... Obwohl das Design insgesamt durchaus nicht katastrophal ist und viele Komponenten eigentlich richtig gut sind, ist das Gesamtgebilde nicht sehr gut wartbar/erweiterbar und überhaupt nicht performant. Komplettes Redesign ...

Dir fällt schon auf, dass "ineffizient" und "hocheffizient" Gegensätze sind?
Nichts wird effizient im Vergleich zu Java, nur weil man C++ nutzt. Man muss sich dann auch hinsetzen und die Möglichkeiten von C++ wenigstens effizient oder hocheffizient ausnutzen. Dass man ineffiziente C++ Software in Java 10x performanter wird, ist auch klar.

Mein Framework ist meine Privatsache. Ich habe keinen Kostendruck, ich habe nur den Druck verhältnismäßig kompromisslos entwickeln zu wollen. So ist es auch schon mehrfach passiert, dass ich jegliche Entwicklung stoppte und das Framework säuberte. Das nimmt dann auch mal ein halbes Jahr in Anspruch, wo ich nur optimiere und aufräume.

Meine Sprache erzeugt u.a. Bytecode. Es gibt einen selbstgeschriebenen Interpreter dafür. So macht es Perl auch. Während Perl bei dem Test über 15 Jahre Entwicklungszeit hinter sich hatte, und als schnelle Interpretersprache gilt, war meine Sprache unoptimiert, sondern auf normalen Niveau programmiert und eine Liste mit noch ausstehenden Optimierungen vor mir hatte. Zeitlich lagen die Testprogramme im Promillebereich hinter Perl. Bei einem Programm mit einer Ausführungsdauer von 10 Sekunden, lag ich also im Bereich von 10-50ms hinter Perl.
Diese Compilergeneration existiert nicht mehr. Daran habe ich gelernt, dass C++ scheiße ist und ich C++ nicht als Basis für meine Sprache nutzen möchte und begann radikal umzubauen und einen einfacheren Testinterpreter einzubauen.

Mechanics schrieb:

Und ein Performance Unterschied von 10% lässt sich ganz leicht und billig durch einen etwas schnelleren Rechner ausgleichen.

Das kommt auf das Problem an. ^^
Eventuell sind 10% von sehr viel immernoch sehr viel. ^^

------------------------------------

otze schrieb:

Ich glaube, dass wir immer noch aneinander vorbei reden.

Und ich glaube, dass wir voll auf einer Linie sind. ^^

------------------------------------

Antoras schrieb:

Was mich interessieren würde, ist, in welchen genauen Anwendungsbereich Genesys passen soll. Soll die Sprache im großen und ganzen eine bessere Alternative zu C++ und dessen Stärken sein (z.B. Performance) oder auch in Teilbereiche passen in denen andere Programmiersprachen stärker sind (z.B. hohe Abstraktionen und statische Typsicherheit wie bei Haskell oder Scala)?

Zum ersten Teil klares ja, das ist der Part mit dem ich gestartet bin.

Bzgl. Scala und Haskell kann ich die Antwort so direkt nicht geben, ich habe lediglich mal eine Lisp-ähnliche Sprache gelernt und ein bisschen Lisp. Haskell steht recht weit oben auf meiner Todo-Liste. Ich habe mal nach einem Seminar geguckt, aber das Angebot scheint eher "überschaubar".
Mit Vergleichen zu Sprachen, die ich nicht beherrsche würde ich mich also bestenfalls hier lächerlich machen.

Zum Thema Typsicherheit fahre ich eine zweischneidige Nummer. Ich bin der Überzeugung, dass man dem Entwickler nicht trauen kann, also die Sprache sehr restriktiv vorgehen muss und den Entwickler dazu soweit wie möglich zwingen muss sauber und diszipliniert zu programmieren. Gleichzeitig bin ich aber auch der Meinung, dass ich nicht alles vorhersehen kann, also dem Entwickler auch immer eine Möglichkeit geben muss, aus dem Sicherheitskäfig auszusteigen und perverse Sachen zu erlauben. Dann muss im Quellcode aber eine suchbare Alarmleuchte blinken, die auch als Marker durch den Compiler wandert.

Antoras schrieb:

Bisher meine ich herauslesen zu können, dass Genesys dabei helfen soll performant implementierte Algorithmen statisch sicherer umsetzen zu können oder deren Wiederverwendung durch mehr Generizität verbessern soll. Ist das korrekt? Wenn ja, soll man diese Generizität auch in abstrakterer Form (deklarative Beschreibung von Algorithmen wie in der funktionalen Programmierwelt) einsetzen können?

Hier sträube ich mich etwas gegen "wie in der funktionalen Programmierwelt", da ich zwar denke, einen brauchbaren Überblick zu haben, aber eben keine aktuelle, rein funktionale Sprache beherrsche.

Grundsätzlich denke ich erstmal eher an Templates, kenne die deklarative Programmierung allerdings aus Prolog und bin vom dem Konzept angetan. Ich habe allerdings bisher weder eine Umsetzung dafür, noch plane ich die deklarative Beschreibung konkret, wie sie in Prolog oder soweit mir bekannt auch in Haskell auftritt. Das passt so nicht 1:1 in die Syntax, die ihren Ursprung ganz klar bei C++ hat, auch wenn syntaktisch PHP inzwischen näher an C++ liegt als Genesys.

Und auch wenn mir klar ist, dass das jetzt so aussieht, als würde ich versuchen mich hier aus der Schlinge zu ziehen - ich plane auch nicht, nicht deklarativ zu arbeiten. Die Idee ist bekannt und interessant, der Fokus liegt zur Zeit allerdings derzeit auf ganz anderen Dingen.

...

Und nachdem ich jetzt mal ein paar Minuten hier sitze und gegrübelt habe... das müsste im Design bereits funktionieren - implementiert ist es soweit allerdings noch nicht. Das ist das Blöde, dass man in Programmiersprachen, die man gerade entwickelt, sowenig Programmiererfahrung hat.

Die Syntax passt wie gesagt nicht 1:1. Konzeptionell dürfte sollte das mit "einer" spezielleren Templatemethode zu realisieren sein, die aber quasi mehrfach spezialisiert ist. Das Design wurde aber nicht im Hinblick auf deklarative Programmierung formuliert. Da sollte ich durchaus nochmal drüber schlafen, weil soweit bin ich eigentlich auch nicht davon entfernt. Aus dem Blick von Haskell wäre mein Konstrukt bei der Verwendung allerdings eher Boilerplate.

Ich lasse das mal noch ein paar Tage in Hinterkopf garen... ansonsten hätte ich für die letzten Zeilen sicher keine 20 Minuten gebraucht...

So, Computer aus... in meinem Kopf fliegen jetzt Schreibweisen für deklarative Algorithmen hin und her... verdammt...

Shade Of Mine

Ich gehe nur auf die wichtigen Features einer Programmiersprache ein. Der Rest fuehrt eh zu nichts.

Xin schrieb:

Shade Of Mine schrieb:

Du sagst zB die wichtigen Features die fehlen sind
Const-Correctness -> wird ersetzt durch Immutable Types
C++-Referenzen -> hier sehe ich nicht wirklich was relevantes. Referenzen sind Syntax Zucker. Einzig relevanter Vorteil ist, dass man damit defensive Kopien verhindert - was man in Java zB über Interfaces löst.

Immutable Types sind eine Möglichkeit, kosten aber. Was kostet und nicht abschaltbar ist, wird keine andere Nische besetzen können.

Immutables sind schneller als const. Immutable bedeutet naemlich, dass du ploetzlich optimieren kannst wo du mit const nicht optimieren kannst. Weiters sind immutable Objekte per Definition Thread-sharable. Das erleichtert vieles.

Referenzen sind alles andere als Zucker... sonst wären sie so handlich wie es Zeiger sind.

Hast du auch ein Argument? Was bieten dir C++ Referenzen was du in Java nicht hast?

Shade Of Mine schrieb:

Templates -> Generics. Natürlich sind Templates mächtiger als Generics, aber prinzipiell sind es wieder 2 Lösungen für 1 Problem. Je nach Situation ist das eine oder andere besser.

Stimmt und beide haben Berechtigung. Es ist eben nicht zwei Lösungen für ein Problem, sondern es sind semantisch vollkommen unterschiedliche Konstrukte.

Welchen relevanten Unterschied siehst du denn zwischen Generics und Templates? Die Implementierung ist eine andere, keine Frage aber wodurch sind Generics fuer dich ein komplett anderes Konzept als Templates?

Shade Of Mine schrieb:

Mehrfachvererbung -> dafür bietet Java eben Interfaces, die in einigen Situationen viel besser sind als Mehrfachvererbung. Alles in allem sehe ich hier keinen riesen Unterschied.

Ich programmiere jetzt seit 18 Jahren C++. Was mir bisher niemand erklären konnte war, wo eigentlich Interfaces besser sein sollen als Mehrfachvererbung. Das interessiert mich ehrlich, denn bisher sehe ich in Interfaces nur Nachteile.

Interfaces bieten tiefe Vererbungshierachien an. In C++ ist soetwas wie Listener zu implementieren nicht wirklich gut moeglich. Man nimmt stattdessen einfach signal/slot - ist ja durchaus OK. Aber es ist eben eine komplett andere Loesung. Interfaces erlauben ploetzlich viel mehr Vererbung zu haben. zB ist serialisierung in vielen Sprachen ueber Vererbung geloest. Ich erbe von ISerializable und schon kann ich mich serialisieren. Soetwas waere in C++ nicht moeglich. Generell laeuft es darauf hinaus dass man in Sprachen ohne Interfaces deshalb flache Hierachien hat und in Sprachen mit Interfaces tiefe.

Durch die tiefen Hierachien ist es auch ploetzlich einfacher moeglich gegen Interfaces zu programmieren um den Code generisch zu halten.

Shade Of Mine schrieb:

Und was genau willst du haben? Binäre Kompatibilität von C# zu Java? Oder worauf genau zielst du ab? Das mit Linker habe ich nicht verstanden...

Die Objectfiles sind nicht geeignet Klassen abzubilden, was zu überflüssigem Aufwand führt, den man mit C# oder Java so nicht hat.

Keine Ahnung wo du jetzt Objectfiles und Klassen hernimmst.

Womit wir an dem Punkt wären, wo ich vor Seiten schon schrieb, dass C++ scheiße ist - aber trotzdem das beste, was wir haben.

Und das ist der Punkt: absolute Statements.
Das fuerht hier zu nichts.

C++ ist nicht das beste was wir haben, denn ich kann fuer unzaehlige Anwendungsfaelle bessere Sprachen finden. C++ ist toll, keine Frage, aber solche absoluten Statements sind einfach nur Mist.

Ich weiß, dass grundlegende GUI realisierbar ist - das beweist Qt, wxWidgets und gtk.

Qt released 1-2 mal pro Jahr eine neue Version. Der Standard wird alle 10 Jahre mal verbessert. Wenn man sich jetzt die GUI Entwicklung ansieht so hat sich eine Menge getan in den letzten 10 Jahren und seitdem der neue Standard raus ist, gibt es sogar schon wieder was komplett neues: Metro.

Es ist unrealistisch anzunehmen dass man so Library schaffen koennte die ueberall gut laeuft (gtk ist unter Windows zB untragbar!) und dennoch nur alle 10 Jahre updates erfaehrt. So funktioniert die Welt nicht. Dazu muesste der Standard viel schnellere Updates bekommen.

Cyres

So, ich beteilige mich auchmal an der Disskussion

Shade Of Mine schrieb:

Hast du auch ein Argument? Was bieten dir C++ Referenzen was du in Java nicht hast?

Es ging ja eher um den Vergleich zwischen C++ Referenzen und C++-Pointern und dass Referenzen syntaktischer Zucker sind, sie sind nicht überall da einsetzbar wo Pointer einsetzbar sind, aber man kann sie zum Beispiel sehr gut in der Parameterübergabe verwenden. In Java sind die Objekte prinzipiell nichts anderes als C++-Referenzen.

Shade Of Mine schrieb:

Welchen relevanten Unterschied siehst du denn zwischen Generics und Templates? Die Implementierung ist eine andere, keine Frage aber wodurch sind Generics fuer dich ein komplett anderes Konzept als Templates?

Erstmal sind Generics eine Auswertung zur Laufzeit, Templates werden vom Compiler vorher umgewandelt in Typen. Dadurch gibt es (abgesehen von Performance) die Möglichkeit der Spezialisierung, dazu kommen seit C++11 die Variadic Templates, die die Templates nochmal um ein vielfaches interessanter machen.

Shade Of Mine schrieb:

Interfaces bieten tiefe Vererbungshierachien an. In C++ ist soetwas wie Listener zu implementieren nicht wirklich gut moeglich. Man nimmt stattdessen einfach signal/slot - ist ja durchaus OK. Aber es ist eben eine komplett andere Loesung. Interfaces erlauben ploetzlich viel mehr Vererbung zu haben. zB ist serialisierung in vielen Sprachen ueber Vererbung geloest. Ich erbe von ISerializable und schon kann ich mich serialisieren. Soetwas waere in C++ nicht moeglich. Generell laeuft es darauf hinaus dass man in Sprachen ohne Interfaces deshalb flache Hierachien hat und in Sprachen mit Interfaces tiefe.

Das ist ausnahmslos alles in C++ mit Mehrfachvererbung auch Möglich (virtual abstract methods). Au0erdem erklär mir bitte mal, wie du ein JFrame und ein Observable in ein Objekt gleichzeitig kriegst? Viel spass dabei, weil methoden wie setChanged() sind protected. Ich betrachte es dabei übrigens nicht als guten Stil eine Methode notify() zu schreiben, die die Funktionalität public macht.

redrew99

Xin schrieb:

Ich tue mich sehr schwer damit, Ideen als Unfug abzutun, wenn ich sie nicht verstehe. Diese Idee verstehe ich nicht, habe aber den Verdacht, dass Du derzeit auch kein Konzept hast. Jedenfalls lassen "könnte mir vorstellen" und "eventuell möglich" darauf schließen.

Ja, natürlich ist das erstmal nur eine Idee, und vielleicht auch nur eine Schnapsidee.

Xin schrieb:

Könntest Du ein konkretes Beispiel, einen konkreten Anwendungsfall beschreiben - unter Berücksichtigung, das der Mensch nur in der Lage ist, 2D Informationen mit einer ungefähren Entfernung wahrzunehmen, aber nicht 3D-Informationen.
Um den Unterschied zu verdeutlichen: Du siehst den Monitor, Du siehst, dass er etwa 60cm vor Dir steht, aber Du siehst nicht, was hinter dem Monitor ist. Der Mensch sieht immer einen kleinen Ausschnitt der ihm zugewandten Ebene.
Das Hauptsinnesorgan des Menschens ist das Gedächtnis, nicht das Auge. Entsprechend wird jede Kommunikationsform scheitern, die den Menschen überfordert.

Das sehe ich nicht so. Einen Monitor in 3d könnte man von allen Seiten betrachten, ihn transparent machen, vergrößern, verkleinern,um ihn herumgehen, ihn in Teile zerlegen und mit den Teilen wiederum das gleiche machen.

Daß der Mensch immer nur einen kleinen Ausschnitt der ihm zugewandten Ebene sieht ist richtig, das ist aber bei einem Monitor in 2D ebenfalls so. Sobald die Inhalte größer als die Fläche des Monitors sind, leidet die Übersicht.

Das Gedächtnis ist definitiv kein Sinnesorgan. Aber wenn Du meinst, daß Informationen in 3d schwerer zu merken sind als in 2d, bin ich der Ansicht, daß das sein kann, aber nur wenn die Informationen unvorteilhaft dargestellt sind. Schau Dir dochmal die Seiten eines Würfels in 3d und in 2d an. Wenn ich Dir die Frage stellen würde, welche Seiten des Würfels benachbart sind, ist
das bei einem 2d-Würfel viel schwieriger zu erkennen als bei einem 3d-Würfel.

Xin schrieb:

redrew99 schrieb:

So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt. Der "Vektor" könnte darüberhinaus Buttons haben oder andere Eigenschaften(evtl. Displays?), um weitere Verändungen vornehmen zu können. Auch mit Tönen könnte man arbeiten.

Bis auf die Töne verstehe ich nur Bahnhof und da pfeift bei mir der Zug.

Wenn ich in 3d einen Vektor erzeugen möchte, nehme ich einfach einen dafür vorgesehenen Behälter,
sagen wir einen Würfel. Und um den Datentyp des Vektors zu bestimmen, könnte man dem Würfel eine bestimmte Farbe verpassen.

Xin schrieb:

Und was soll die dritte Dimension abbilden?

Meine Vorstellung ist die, daß 3d-Programmieren nach Möglichkeit nichts mehr mit geschriebenem Code
zu tun hat. Der Großteil des Codes, der heute geschrieben wird, müßte durch 3d-Objekte dargestellt werden.