Was kommt nach der Objektorientierung?

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.

Xin

Shade Of Mine schrieb:

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

Danke für die Wertung, aber auch danke für's Kürzen

Shade Of Mine schrieb:

Xin schrieb:

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.

Ein Immutable ist schneller als ein Const... Okay, ohne Dir zu nahe treten zu wollen, aber Du weißt schon, was Du da so schreibst?... ich kann mich erstmal auf 'schneller' wie 'nicht langsamer' einigen, doch wäre ich dankbar, wenn Du mir den Unterschied zwischen einem Unveränderlichen und einer Konstanten kurz erläutern würdest, damit ich verstehe, warum Unveränderliche schneller als Konstanten sind?

Thread-Shareable ist richtig, es erleichtert vieles und je nach Problem lassen sich Immutables super optimieren.

Nehmen wir also mal an, dass Immutables schneller als Mutables sind, wird die Aussage leider auch nicht unbedingt besser. Hier übrigens mal ein mal im Vorgriff noch ein Zitat von Dir:

Shade Of Mine schrieb:

aber solche absoluten Statements sind einfach nur Mist.

Zurück zum Unvermeidlichen: Immutables müssen bei Änderung kopiert, bzw. neu erzeugt werden, auch da, wo man auf ein Immutable/Const-Objekt verzichten kann. Hier kostet es und "dann kaufe ich eben einen schnelleren Rechner" ist kein Argument, das erzählt man mir schon seit über 10 Jahren, ich habe die dritte Generation schnellerer Rechner und Mutable-Objekte sind in der Regel immernoch schneller.
Wir haben nämlich häufig gar keine hochparallelisierbaren Probleme, sondern einfach nur die Änderung eines Zustandes.

Beispiel Texteditor: Wir haben 10 Texte geöffnet. Wir haben das immutable Objekt Text, jeder Text besteht aus 10000 immutable Textlines. Und jetzt drückt der Benutzer eine Taste.
Das ist doch jetzt kein Ausnahmeszenario, oder?

Und jetzt möchte ich sehen, wie schnell das Mutable im Vergleich zum Immutable ist.
Ich persönlich bin hier altmodisch... ich würde zum Mutable greifen.

Shade Of Mine schrieb:

Was bieten dir C++ Referenzen was du in Java nicht hast?

Den Verzicht auf die Frage, ob die Java-Referenz Null ist. Das erfordert vom Entwickler Disziplin und vom Computer Laufzeit. Beides überflüssig mit C++-Referenzen, da gibt es einen klaren Vertrag, der vom Compiler überwacht wird und imho sicherer ist, als ein Entwickler, der überall gegen Null prüft.

Ansonsten frage ich mich, warum C# 'ref' und 'out' eingeführt hat, wenn Java alles hat. Vielleicht hatten die keine Lust für zusätzliche Rückgabeparameter ArrayListen zu missbrauchen oder laufend sinnfrei Objekte erstellen, zu kopieren und zu löschen, man weiß es nicht.

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?

Generics erzeugen keinen Code, sondern benutzen den gleichen Code für gleichartige, verwandte Datentypen. Templates erzeugen Code auch für vollkommen unterschiedliche Datentypen, die keine Beziehung zueinander haben müssen.

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.

Hmm... entweder bin ich echt zu blöd oder alles, was Du beschreibst mache ich in C++.

Kannst Du mir den Listener oder ISerializable mal zeigen, der in C++ nicht möglich ist? Zum Vergleich nehme einfach eine Klasse, die ausschließlich pure virtual Methods enthält, wenn Du das Interface ersetzt.

Was Dir fehlt sind nicht Interfaces, sondern Reflection. Die Basisklasse, die ich auch für die Datenbankgeschichten nutze, wurde geschrieben aufwendige Konfigurationen, die einen Graphen aus einer Vielzahl von unterschiedlichen Klassen nach XML zu serialisieren. Die Basisklasse lieferte Interface und Implementation. Die Konfiguration der Basisklasse ist das Problem: Reflection.

Dein Problem ist gegenwärtig. Falscher Thread.

Shade Of Mine schrieb:

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

Tut mir absolut leid, aber das ist für mich alles easy going in C++.

Tiefe Hierarchien werden von vielen verdammt, keine Ahnung warum. Mein Framework ist ein Legobausteinkasten. Aber dafür brauche ich definitiv keine Interfaces, im Gegenteil: Ich brauche Mehrfachvererbung. Hier habe ich nicht nur die Interfaces, gegen die ich programmieren muss und die Implementierung.

Shade Of Mine schrieb:

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.

Weißt Du, was Objectfiles sind und wie man Klassen dort abbildet?

Shade Of Mine schrieb:

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.

Das soll jetzt wirklich keine Beleidigung sein, aber ganz klar eine Kritik: Du bist mit Deinen Augen textlich sehr punktuell. Du gehst auf zwei Zeilen Text ein, ohne sie im argumentiven Konzept zu sehen. Ich hatte es vorher zusammengefasst und ich kann nicht vor jede Aussage eine Anleitung stellen, sonst wird's nämlich richtig lang.

Shade Of Mine schrieb:

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.

Das schöne an C++ ist, dass es nicht jedem Trend hinterherspringt. Metro heißt schon nicht mehr Metro. CodeProject hatte diese Woche eine nette Mail: "Windows 8 Review: It's really that bad".
Dein Argument ist bereits behandelt worden: Niemand ist gezwungen ausschließlich std zu verwenden, aber für ein Fenster wäre es eine Hilfe.
Wenn Du Dich also fragst, warum meine Antworten lang ausfallen, dann frage Dich bitte auch, warum laufend die gleichen Fragen kommen, denn auch das folgende ist wieder nur eine Wiederholung.
Antworte ich hierauf nicht, kommt "Dir sind die Argumente ausgegangen", jetzt antworte ich auf die Frage erneut, das macht den Text länger.
Den Großteil Deines Postings hätte man getrost löschen können mit dem Verweis, sich bereits Beantwortetes durchzulesen, bzw. was ich mit Immutables vs Const machen soll... ignorieren wäre auch unhöflich.

Vielleicht sollte ich einfach schreiben, dass die Diskussion mit Dir zu nichts führt. Gegenseitige Ablehnung wäre Stagnation, bringt uns also auch nicht weiter. Also... Du darfst kürzen.

Shade Of Mine schrieb:

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.

Wir reden von Zukunft: Das bedeutet, dass wir nicht nur die Auswahl aus Qt, WxWidgets und Gtk haben. Wir können ganz einfach hingehen und z.B. WxWidgets auf Linie ziehen, so dass std::gui Anwendungen Betriebsystemgerecht gerendert werden.
Und wir könnten es auch mit Listenern ausstatten, wenn das im Standardisierungs-Komitee gut ankommt.

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

Cyres schrieb:

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.

Nur ein kleiner Einwand:
Bei Parametern sind C++-Referenzen top, aber Java-Referenzen entsprechen C++-Pointer, nicht C++-Referenzen! Syntax (".-Operator") und Name ("Referenz") und Marketing ("Java hat keine Pointer") waren darauf ausgerichtet, dem damals üblichen C++-Programmierer Sicherheit zu suggerieren, um zum Wechsel zu animieren.
Und die meisten Entwickler lesen, akzeptieren und denken nicht darüber nach, was sie gerade gelesen haben. Das gilt nicht nur in diesem Thread. Wenn irgendein Guru etwas gut findet, dann wäre ich ja blöd, dagegen zu sein.
Und genau deswegen führe ich regelmäßig solche Diskussionen. Ich bin so blöd gegen eine Armada von Leuten anzudiskutieren, die aus voller Überzeugung hinter technischem Rückschritt stehen und ihn verteidigen, weil sie damit billiger ausgebildet werden können und sich entsprechend ein kleineres Gehalt wünschen.
Natürlich ist Java Fortschritt! Aber halt nicht für die Informatik sondern für die Betriebswirtschaft. Ich kenne reichlich Leute, die begeistert iPads gekauft haben. Keiner konnte mir bisher sagen, wofür man das Ding sinnvoll einsetzen kann, wo ein Netbook oder Laptop nicht nur sinnvoller, sondern auch billiger wären. Beim Skypen steht mein Laptop auf der Tastatur, deren iPad kippt um und ich bewundere die Wohnzimmerlampe - gaaanz toll. Aber alle sind sich einig: Tablet-Rechner sind so cool.
Java ist das iPad für Entwickler.

Eine Java-Referenz ist eine Referenz über eine Positionstabelle, aber der Zugriff über die Positionstabelle ist transparent. Was übrig bleibt ist ein Pointer und der ist nicht transparent, sondern präsent. Das ist das Ding, mit dem man in Java arbeitet.
Darum kann man einer Java-"Referenz" auch null zuweisen und erhält bei Zugriff eine NullPointerException, die Java-Wohnzimmerlampe - gaaaanz toll. Aber alle sind sich einig: Java ist so cool...

Einer C++-Referenz kannst Du die Null nur mit Gewalt unterjubeln. Auch C++ kann umkippen und man sieht die Deckenlampe, aber die Tastatur als Standfuß beim Laptop hat sich trotzdem bewährt. Wenn's cool sein muss, kann man darauf natürlich keine Rücksicht nehmen

Mit ein Grund, warum Java ein gewaltiger Rückschritt ist. Pointer nennt man Referenz ohne die Konsequenzen zu implementieren, embedded Structs gibt es nicht mehr, jeder Furz muss mit New angelegt werden. Gaaaaanz toll...

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

redrew99 schrieb:

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.

Ufffz... jetzt muss ich aber mal ganz weit im Gedächtnisstack zurückgehen

Neue Ideen sind immer Ideen, die vorher keiner für möglich hält. Und da ist viel Alk und andere bewusstseinserweiternde Mittel dabei. Wenn man also etwas neues will, sollte man also genau da suchen.

redrew99 schrieb:

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.

Wir bräuchten ein Holodeck. Das habe ich allerdings noch nicht auf dem Schirm.

Aber was den Teil angeht 'in Teile zerlegen und mit den Teilen wieder das gleiche machen', das erinnert mich an einen Text-Editor, den ich vor 15 Jahren mal geschrieben habe. Da würde ich gerne mehr drüber hören.

redrew99 schrieb:

Das Gedächtnis ist definitiv kein Sinnesorgan.

Streck Deine Hand aus, schau auf Deinen Daumen. Der Daumen ist das, was Du bewusst und scharf siehst. Der Rest sind bekannte Bilder, die vorrangig Deinen Erwartungen entsprechen.

Vielleicht kennst Du das Basketball-Experiment: http://www.youtube.com/watch?v=2pK0BQ9CUHk

Wir geben bisher einfach Text ein. Wenn Du Dir COBOL ansiehst, dann ist das Prosa. Fortran ist Prosa. Algol60 ist strukturierter. Pascal ist wieder strukturierte Prosa, aber die Optik kommt auch hier ins Rennen. Einer der Gründe, weswegen sich C in meinen Augen durchgesetzt hat, ist die optische Wahrnehmung des Quelltextes. Unwichtiges wie begin und end wird durch optisch unauffällige { und } dargestellt, die gleichzeitig optisch gut von der Prosa zu unterscheiden sind. Andere Sprachen gehen den anderen Weg - sie verwenden überhaupt keine "Prosa", als Beispiel wäre da Brainfuck zu nennen. Man könnte Brainfuck auch höheren Konstrukten austatten, aber obwohl es nur wenig kann, versteht niemand mehr den Quelltext.

Zukünftige Sprachen müssen eine Wertung vornehmen und diese Wertung optisch präsentieren.
Ich denke, dass 3D-Modellierung den Menschen überfordert.

Ich arbeite im CAD Bereich. Unsere Kunden wollen 3D Modelle sehen; aber planen wollen sie in 2D. Es steckt schon im Wort. Ein Plan ist planar.
Modellierung erfolgt (bisher) immer nach Plan oder ist statisch.

Technische Modellierung (z.B. mit Inventor) behandelt komplexe Zusammenspiele, z.B. sich drehende Zahnräder. Das ist durch eine Programmzeile schwierig auszudrücken, weil das Objekt auch 3D ist. Eine Variablenzuweisung ist aber gar nicht so komplex. Ein Programm läuft in der Regel eindimensional ab. Multithreading hingegen - und hier könnte es interessanter werden, läuft mehrdimensional ab, aber eine Anweisung in Thread 1 ist nicht zwangsläufig mit einer Anweisung in Thread 2 verbunden. Ein Thread erzeugt sein eigenes eindimensionales Universum.

In Deiner Idee könnte aber grundsätzlich durchaus etwas Erforschenswertes drin sein.
Trink noch einen

redrew99 schrieb:

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.

Das ist zweifelsohne richtig, aber wie müsste eine Programmiersprache, bzw. ein Problem aussehen, damit dies für eine Programmiersprache prinziprelevant wird?

redrew99 schrieb:

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.

Als Programmierer arbeite ich zwar häufig mit Vektoren und der Würfel heißt dann "v". Ich habe aber keine Ahnung, wohin v zeigt, denn ein Algorithmus ist eine Beschreibung, wie man ein Problem löst, v ist nur ein Platzhalter.

redrew99 schrieb:

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.

Eins der ersten Programme, die ich in meiner Sprache laufen lies, war der Quicksort-Algorithmus, der ein Char-Array sortierte.

Könntest Du mir beschreiben oder zeichnen, wie Du Dir einen Sortieralgorithmus in 3D programmierst?

Cyres

Xin schrieb:

Java ist das iPad für Entwickler.

Danke, Made my Day - Da bin ich ja froh, dass ich beides nicht mag.

Wegen den Referenzen bei Java: stimmt, dass die null werden können hatte ich vergessen, mir seihe verziehen, ich programmiere nur Java, wenn ich es muss (Uni)

immer diese registrierten trolle hier

Antoras

@Xin

Ich glaube, du übersiehst bei manchen deiner Argumente noch, dass es für viele Entwickler nicht nur darauf ankommt wie viel einem in einer Programmiersprache ermöglicht wird, sondern wie viel Aufwand es ist dies alles zu ermöglichen.

Ist dir bewusst, dass man in Scala für eine eigene Listenimplementierung nur eine Schnittstelle mit 2 oder 3 Methoden implementieren braucht und dafür über 100 weitere Methoden kostenlos dazu bekommt? Das besondere dabei ist, dass man nicht nur eine korrekte Implementierung all dieser Methoden bekommt, sondern auch ein korrektes Interface. D.h. der Compiler garantiert mir, dass ich bei einem Aufruf einer Methode auf mein Implementierung auch wieder meine Implementierung als Rückgabewert erhalte und nicht irgendeine abstraktere Oberklasse. Diese Eigenschaft macht Scalas Collections zu der mächtigsten und fortschrittlichsten Colletion Bibliothek, die momentan unter allen existierenden Programmiersprachen verfügbar ist. Einzig allein Smalltalk kann etwas vergleichbares bieten - ist aber dynamisch typisiert.

Mit CATs (Compile-time AST transformers), auch als Macros bekannt, und type provider befinden sich in Scala gerade Implementierungen von Techniken in Arbeit, die es sogar ermöglichen sollen z.B. Listenimplementierungen zu schreiben, die auf Datenbanken operieren (natürlich alles ohne die Probleme, die ORM libraries mitbringen). Endziel soll sein, dass die Entwickler der Bibliotheken wenig machen müssen und die Anwender überhaupt nichts.

C++ mag, wenn man die Menge aller ihrer Möglichkeiten ansieht, die beste Programmiersprache sein um Algorithmen effizient und sicher zu implementieren - auf der Ebene der Programmierung und Verarbeitung von Datenstrukturen und wartbarer Programme versagt diese Sprache meines Erachtens aber vollkommen.

Und mein bisheriger Eindruck von Genesys ist, dass es auf die gleiche Menge wie C++ abbildet. Die Sprache mag einige Ideen zur Implementierung von effizienten Algorithmen bieten - ich bezweifle aber, dass sie irgendetwas neues anbieten kann was in Scala oder Haskell nicht schon implementiert oder in Arbeit ist (die meisten der störenden Sachen, die du hier in diesem Thread angesprochen hast sind in Scala z.B. schon implementiert bzw. gelöst und erfahren durch eine aktive Community bereits viel Weiterentwicklung).

Ich hoffe für dich, dass du dich nicht in dem Vorhaben verrennst Sachen zu lösen, die bereits in Sprachen gelöst sind, die dir nicht sehr vertraut sind und mit denen du nicht konkurrieren kannst. In Scala z.B. kämpft man hin und wieder mit unnötig ineffizienten Programmen, die ein Resultat von generischen Implementierungen sind. Die Scala Community ist sich dessen bewusst, konzentriert sich aber nicht in erster Linie darauf, da sie weiß, dass Entwickler, die froh über jede gesparte Nanosekunde sind, wohl nicht in Scala entwickeln werden um von dessen Stärken Gebrauch machen zu können.

Xin

Antoras schrieb:

Ist dir bewusst, dass man in Scala

Wie schon gesagt, über Scala ist mir gar nichts bewusst, daher...

Antoras schrieb:

Ich hoffe für dich, dass du dich nicht in dem Vorhaben verrennst Sachen zu lösen, die bereits in Sprachen gelöst sind, die dir nicht sehr vertraut sind und mit denen du nicht konkurrieren kannst.

...hoffe ich das genauso

Ich schaue mir regelmäßig neue Sprachen an, um das abzusichern. Alle Sprachen der Welt zu lernen, kann ich aber nicht. Das ist auch nicht erforderlich, denn andere tun das auch nicht. Es ist schön, wenn ich in einer bedeutungslosen Sprache ein Feature entdecke, das toll ist und dass verdient, weiter beachtet zu werden. Die Schlussfolgerung, dass Scala unbedeutend wäre, wäre jetzt nicht angebracht... nur mal so zur Vorsicht.

Ich kann kein Experte für alle Programmiersprachen werden und Genesys wird sicherlich nicht perfekt für alle Probleme sein, das ist auch nicht das Ziel. Das Ziel ist, dass die Sprache dem Entwickler Möglichkeiten bieten muss, die Sprache an das Problem anzupassen.
Die Entwicklung von Genesys startete als Idee einer Programmiersprache. Im Konzept, dass sich über die letzten 10 Jahre herauskristallisiert hat, könnte man einen Nebeneffekt beschreiben, mit dem ich der Entwicklung von Genesys eine Richtung gebe: nämlich dass man damit angenehm programmieren kann.

Antoras schrieb:

für eine eigene Listenimplementierung nur eine Schnittstelle mit 2 oder 3 Methoden implementieren braucht und dafür über 100 weitere Methoden kostenlos dazu bekommt? Das besondere dabei ist, dass man nicht nur eine korrekte Implementierung all dieser Methoden bekommt, sondern auch ein korrektes Interface. D.h. der Compiler garantiert mir, dass ich bei einem Aufruf einer Methode auf mein Implementierung auch wieder meine Implementierung als Rückgabewert erhalte und nicht irgendeine abstraktere Oberklasse.

Das ist beeindruckend, aber was hindert mich, das mit einer Ableitung von einem Template zu machen? In meinem Forum kam damit einer damit an und warf das passende Buzzword dafür rein... ich hab's wieder vergessen.... <such>... "Curiously Recurring Template Pattern".
Ich kann zwar alles Programmieren, aber wenn Du mich nach dem Namen von irgendwas fragst, ist mein Name Hase und ich weiß von nix.

Meine Stringklasse ist auch nur ein Array<char>. Mit einem Array kann ich all die Sachen machen, die man mit einem String so machen kann. Suchen, Ausschneiden, Ersetzen, Umranden und all diese Funktionen liefern mir das zurück, was reingeht. Bei einem Array<char> ein Array<char>, bei einem String kommt ein String zurück. String ist lediglich der schönere Name, die Methoden sind weder reimplemtiert, noch aufgelistet, sie werden einfach geerbt. Und String enthält ein paar Funktionen wie upper() oder lower(), um mir eine entsprechende Kopie zu geben, oder setUpper() und setLower(), um das Original zu überarbeiten, falls es mutable ist. Die machen bei einem Array halt keinen Sinn.

Nein, es ist nicht wirklich wunderschön, das darf man gerne verbessern. Und mir ist auch aufgefallen, dass es nicht wunderschön ist.
Aber auch keine reine Katastrophe.

Ist das, was Du beschreibst?

Antoras schrieb:

Diese Eigenschaft macht Scalas Collections zu der mächtigsten und fortschrittlichsten Colletion Bibliothek, die momentan unter allen existierenden Programmiersprachen verfügbar ist.

Ich gucke mir das sehr gerne an.

Wenn Du Spaß daran hast, kannst Du mich auch gerne zu Scala oder Haskell anleiten und mir die Besonderheiten zeigen, die Du schätzt. Da nehme ich mir gerne die Zeit für.

Antoras schrieb:

Mit CATs (Compile-time AST transformers), auch als Macros bekannt, und type provider befinden sich in Scala gerade Implementierungen von Techniken in Arbeit, die es sogar ermöglichen sollen z.B. Listenimplementierungen zu schreiben, die auf Datenbanken operieren (natürlich alles ohne die Probleme, die ORM libraries mitbringen). Endziel soll sein, dass die Entwickler der Bibliotheken wenig machen müssen und die Anwender überhaupt nichts.

Dieses Endziel ist genau mein Punkt. Das Fundament der Sprache muss so stark belastbar sein, dass der Entwickler wenig tun muss, also auch wenig schreiben muss und wenig lesen muss.

CAT klingt interessant. Mit dem AST hantiere ich auch gerne und viel. Ich teste die Implementation über einen AST-Interpreter, weil das schneller geht als Bytecode zu erzeugen und leichter zu debuggen ist. Bytecode erzeugen kann ich schon, das pflege ich wieder nach, wenn die Sprache soweit steht und bequem ist.

Antoras schrieb:

Und mein bisheriger Eindruck von Genesys ist, dass es auf die gleiche Menge wie C++ abbildet. Die Sprache mag einige Ideen zur Implementierung von effizienten Algorithmen bieten - ich bezweifle aber, dass sie irgendetwas neues anbieten kann was in Scala oder Haskell nicht schon implementiert oder in Arbeit ist (die meisten der störenden Sachen, die du hier in diesem Thread angesprochen hast sind in Scala z.B. schon implementiert bzw. gelöst und erfahren durch eine aktive Community bereits viel Weiterentwicklung).

Klingt doch super.

Du sprichst hier sehr positiv von Scala. Da Du Dir vermutlich nicht die Zeit nehmen wirst, mir einen Crash-Kurs im einen oder anderen zu geben und mir die Vorzüge zu präsentieren, hast Du vielleicht gute Quellen.

Bei Haskell habe ich mal nach einem Seminar geguckt, mal eben ein halbes Jahr in eine neue Sprache investieren, soviel Zeit habe ich nicht, dafür gibt es zuviele Sprachen. Also brauche ich die Highlights konzentriert. Hast Du da was für mich?

Antoras

Xin schrieb:

Nein, es ist nicht wirklich wunderschön, das darf man gerne verbessern. Und mir ist auch aufgefallen, dass es nicht wunderschön ist.
Aber auch keine reine Katastrophe.

Ist das, was Du beschreibst?

Ja, auf die Schönheit der Implementierung wollte ich hinaus. Du magst es nicht als Katastrophe ansehen, andere dagegen vllt. schon. Und für die ist es dann ein Hinderungsgrund das einzusetzen. Als Library-Designer nehme ich mehr Dinge in Kauf wie als deren Anwender.

Xin schrieb:

Wenn Du Spaß daran hast, kannst Du mich auch gerne zu Scala oder Haskell anleiten und mir die Besonderheiten zeigen, die Du schätzt. Da nehme ich mir gerne die Zeit für.

Schwer zu erklären was mir gefällt wenn ich keine 5 Seiten füllen möchte. Um beim Beispiel Lesbarkeit zu bleiben: Typinferenz ist für mich mittlerweile verdammt wichtig. Wenn der Compiler es nicht schafft alle benötigten Typen, die zum Benutzen einer Bibliothek erforderlich sind, aus dem Kontext zu inferieren wäre das für mich ein Grund diese Bibliothek nicht zu benutzen. Das würde sonst einfach zu schnell zu kompliziert werden und oft erfordern, dass ich die eingesetzte Sprache zu 100% beherrsche. Das will ich aber meist nicht (und kann es auch nicht). Ein kleines Beispiel aus Scala dazu:

scala> 1 to 3 map (_+1)
res21: scala.collection.immutable.IndexedSeq[Int] = Vector(2, 3, 4)

scala> Predef.intWrapper(1).to(3).map(((x$1) => x$1.$plus(1)))(collection.immutable.IndexedSeq.canBuildFrom)
res22: scala.collection.immutable.IndexedSeq[Int] = Vector(2, 3, 4)

Beides bedeutet ein und dasselbe, nur letzteren ist unbenutzbar. CanBuildFrom ist das "Geheimnis" hinter der Mächtigkeit von Scalas Collections. Benutzen kann die Collections jeder - verstehen wie sie funktionieren aber nur die wenigsten. Müsste ich CanBuidFrom explizit notieren würde ich Scala sofort wieder in die Tonne kippen. Und da bin ich nicht der einzige: Is the Scala 2.8 collections library a case of “the longest suicide note in history”?

Xin schrieb:

Du sprichst hier sehr positiv von Scala. Da Du Dir vermutlich nicht die Zeit nehmen wirst, mir einen Crash-Kurs im einen oder anderen zu geben und mir die Vorzüge zu präsentieren, hast Du vielleicht gute Quellen.

Bei Haskell habe ich mal nach einem Seminar geguckt, mal eben ein halbes Jahr in eine neue Sprache investieren, soviel Zeit habe ich nicht, dafür gibt es zuviele Sprachen. Also brauche ich die Highlights konzentriert. Hast Du da was für mich?

Das hier finde ich ist eine ganz interessante Einführung (wenn Teile davon auch schon wieder veraltet sind):

Scala – Teil 1: Einstieg
Scala – Teil 2: FP und OOP
Scala - Teil 3: Typen und Pattern Matching
Sonderdruck Scala

Einer der besten Vorträge über Scala, über den ich bisher gestolpert bin, ist von einem indischen Professor: Why Scala? ...by a hilarious Indian guy

Die gehen alle nicht sonderlich ins Detail sondern geben mehr einen Gesamtüberblick. Wenn du detailliertere Informationen über das ein oder andere Feature haben möchtest, dann sage es einfach.

Shade Of Mine

Xin schrieb:

Ein Immutable ist schneller als ein Const... Okay, ohne Dir zu nahe treten zu wollen, aber Du weißt schon, was Du da so schreibst?... ich kann mich erstmal auf 'schneller' wie 'nicht langsamer' einigen, doch wäre ich dankbar, wenn Du mir den Unterschied zwischen einem Unveränderlichen und einer Konstanten kurz erläutern würdest, damit ich verstehe, warum Unveränderliche schneller als Konstanten sind?

Das man ueber sowas diskutieren muss finde ich ziemlich komisch.

Ein const Objekt in C++ ist mutable. Das bedeutet dass es jederzeit seinen Status aendern kann - auch wenn alles was ich sehe ein konstantes Objekt ist.

Ein immutable hat immer den selben Wert, egal was. Ergo ermoeglicht es viel mehr optimierungspotential. Const ist cool, weil man einem handle einfach ein const drauf klatschen kann - immutable ist hier unflexibel. Aber aus reiner Performance sicht, ist immutable besser. Das merkt man schon zB wenn man sich funktionale Sprachen und automatische parallelisierung ansieht...

Beispiel Texteditor: Wir haben 10 Texte geöffnet. Wir haben das immutable Objekt Text, jeder Text besteht aus 10000 immutable Textlines. Und jetzt drückt der Benutzer eine Taste.
Das ist doch jetzt kein Ausnahmeszenario, oder?

OK. ich diskutiere hier nicht weiter.
Das ist doch einfach nur dumm.

Kleiner Tip: wenn du einen Texteditor mit
vector<string const> const texteditor;
definierst, dann hast du echt andere Probleme...

Xin

Antoras schrieb:

Xin schrieb:

Nein, es ist nicht wirklich wunderschön, das darf man gerne verbessern. Und mir ist auch aufgefallen, dass es nicht wunderschön ist.
Aber auch keine reine Katastrophe.

Ist das, was Du beschreibst?

Ja, auf die Schönheit der Implementierung wollte ich hinaus. Du magst es nicht als Katastrophe ansehen, andere dagegen vllt. schon. Und für die ist es dann ein Hinderungsgrund das einzusetzen. Als Library-Designer nehme ich mehr Dinge in Kauf wie als deren Anwender.

Okay, aber das ist dann ein Feature, dass seit den 90ern geht, wir sind hier auf gleicher Ebene wie bei OOP. Es geht auch in C, aber es macht in C++ mehr Spaß, also hat man C++ erfunden.
Und hier geht es in C++ auch, aber es macht anders mehr Spaß.

Antoras schrieb:

Xin schrieb:

Wenn Du Spaß daran hast, kannst Du mich auch gerne zu Scala oder Haskell anleiten und mir die Besonderheiten zeigen, die Du schätzt. Da nehme ich mir gerne die Zeit für.

Schwer zu erklären was mir gefällt wenn ich keine 5 Seiten füllen möchte.

Stroustrup hat in "Design und Entwicklung" 400 eng bedruckte Seiten geschrieben. Ich habe jede davon gelesen. Aber der hatte auch was mitzuteilen.
5 Seiten sind kein Thema. ^^

Antoras schrieb:

Um beim Beispiel Lesbarkeit zu bleiben:

1 to 3 map (_+1)

Predef.intWrapper(1).to(3).map(((x$1) => x$1.$plus(1)))(collection.immutable.IndexedSeq.canBuildFrom)

(_+1) verstehe ich wohl nicht, bzw. was das Ergebnis dieser Operation ist. Eine Liste mit 2, 3, 4?

Antoras schrieb:

...

Einer der besten Vorträge über Scala, über den ich bisher gestolpert bin, ist von einem indischen Professor: Why Scala? ...by a hilarious Indian guy

Ich kann Dir jetzt nicht konkret sagen, wann ich mir die Sachen angucke. Aber ich habe sie in mein Wiki kopiert, sie gehen nicht verloren.

Antoras schrieb:

Die gehen alle nicht sonderlich ins Detail sondern geben mehr einen Gesamtüberblick. Wenn du detailliertere Informationen über das ein oder andere Feature haben möchtest, dann sage es einfach.

*lach* Schreib ein Scala-Tutorial auf proggen.org, dann gibst du nicht nur mir einen Gesamtüberblick

Aber ich schreibe mir auch Deinen Usernamen dazu und komme vielleicht darauf zurück.

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

Shade Of Mine schrieb:

Xin schrieb:

Ein Immutable ist schneller als ein Const... Okay, ohne Dir zu nahe treten zu wollen, aber Du weißt schon, was Du da so schreibst?... ich kann mich erstmal auf 'schneller' wie 'nicht langsamer' einigen, doch wäre ich dankbar, wenn Du mir den Unterschied zwischen einem Unveränderlichen und einer Konstanten kurz erläutern würdest, damit ich verstehe, warum Unveränderliche schneller als Konstanten sind?

Das man ueber sowas diskutieren muss finde ich ziemlich komisch.

Ein const Objekt in C++ ist mutable. Das bedeutet dass es jederzeit seinen Status aendern kann - auch wenn alles was ich sehe ein konstantes Objekt ist.

In einer Multithreading-Anwendung kann das passieren, richtig. In einem Thread geht das nicht.

Hier verlange ich vielleicht wirklich zuviel, wenn ich dem Programmierer, der sich an komplexe Algorithmen gibt, ein gewisses Grundverständnis darüber abverlange, was er da tut. Ich vergesse immer wieder, dass man irgendwann wird man zum Programmieren gar nicht mehr programmieren lernen muss, sondern einfach UML Diagramme malt.

Objekte, die über Threadgrenzen hinaus existieren, haben andere Anforderung als die Normal-Applikation. Das bedeutet nicht, dass bewährte Verfahren dafür ungeeignet wären oder abgelöst würden, so dass andere Einschränkungen entstehen. Hier haben wir aneinander vorbei geredet.

Shade Of Mine schrieb:

Ein immutable hat immer den selben Wert, egal was. Ergo ermoeglicht es viel mehr optimierungspotential. Const ist cool, weil man einem handle einfach ein const drauf klatschen kann - immutable ist hier unflexibel. Aber aus reiner Performance sicht, ist immutable besser. Das merkt man schon zB wenn man sich funktionale Sprachen und automatische parallelisierung ansieht...

Ich glaube allerdings weiterhin nicht, dass eine Sprache, die bewusst Leistungseinschränkungen toleriert am Ende überleben kann, ergo glaube ich nicht, dass mutable Objekte, die per Const-Correctness durch einen Thread wandern, verschwinden werden.

Das Problem ist relativ einfach: Es gibt so wenig, dass sich parallelisieren lässt. Wie den Texteditor. Ein Thread reicht, um auf eine Eingabe des Users zu warten und je größer das zu bearbeitende Konstrukt sein, desto wichtiger ist, dass es bei einer Änderung nicht neu erstellt werden muss.

Shade Of Mine schrieb:

OK. ich diskutiere hier nicht weiter.
Das ist doch einfach nur dumm.

Kleiner Tip: wenn du einen Texteditor mit
vector<string const> const texteditor;
definierst, dann hast du echt andere Probleme...

Lieber Shade, lass doch mal den Schattenwerfer an die Tastatur, sonst sehe ich hier auch schwarz.
Und da man immer mit etwas Positiven schließen soll und mir auch was aufgefallen ist: Ich finde es gut, dass Du const hinter den Datentyp schreibt. Sieht man sonst so selten.

Shade Of Mine schrieb:

Aber aus reiner Performance sicht, ist immutable besser. Das merkt man schon zB wenn man sich funktionale Sprachen und automatische parallelisierung ansieht...

Sorry, aber ein Immutable macht noch lange keinen Code der keine Seiteneffekte hat, den man einfach mal so wie bei funktionalen Sprachen automatisch parallelisieren kann.

Antoras

Xin schrieb:

Okay, aber das ist dann ein Feature, dass seit den 90ern geht, wir sind hier auf gleicher Ebene wie bei OOP. Es geht auch in C, aber es macht in C++ mehr Spaß, also hat man C++ erfunden.
Und hier geht es in C++ auch, aber es macht anders mehr Spaß.

Es sieht in heutigen Sprachen vor allem schöner aus.

Xin schrieb:

(_+1) verstehe ich wohl nicht, bzw. was das Ergebnis dieser Operation ist. Eine Liste mit 2, 3, 4?

Ja, habe das oben mal dahingehend abgeändert.

Xin schrieb:

*lach* Schreib ein Scala-Tutorial auf proggen.org, dann gibst du nicht nur mir einen Gesamtüberblick

Hab ich schon gemacht auf http://scalatutorial.wordpress.com/
Nach den ersten 150 Seiten oder so bin ich jedoch stecken geblieben weil ich die Zeit nicht mehr aufbringen konnte...

Xin schrieb:

Das Problem ist relativ einfach: Es gibt so wenig, dass sich parallelisieren lässt. Wie den Texteditor. Ein Thread reicht, um auf eine Eingabe des Users zu warten und je größer das zu bearbeitende Konstrukt sein, desto wichtiger ist, dass es bei einer Änderung nicht neu erstellt werden muss.

Man muss ja nicht alles kopieren, nur das was sich geändert hat. Unveränderliche Datenstrukturen liegen größtenteils in der gleichen Komplexitätsklasse wie die Veränderlichen. Ein Element an einen Baum hängen geht z.B. gut in O(log n). Bei Unveränderlichkeit beinhaltet das aber noch das Kopieren von log n Elementen...

knivil

die Sprache an das Problem anzupassen.

Prgrammiere einfach in den naechsten Jahren in Lisp oder Scheme. Vielleicht hast du(wer auch immer sich angesprochen fuehlt) einen A-Ha-Moment. http://www.youtube.com/watch?v=5-OjTPj7K54

Scheme hat ein nettes Konstrukt: call-with-current-continuation. Damit ist es recht einfach Coroutinen oder McCarthy's amb-Operator zu implementieren. Prolog in wenigen Zeilen quasi. Es gibt viele weitere Moeglichkeiten fuer dieses einzigartige Feature. In Haskell sind Monaden sehr angesagt und es gibt auch eine die ContinuationMonad (als Beispiel).

Beispiel Texteditor: Wir haben 10 Texte geöffnet. Wir haben das immutable Objekt Text, jeder Text besteht aus 10000 immutable Textlines. Und jetzt drückt der Benutzer eine Taste. Das ist doch jetzt kein Ausnahmeszenario, oder?

Ja, wie wuerde man das Funktional mit "immutable" Datenstrukturen machen .. Altes Problem mit alter Loesung: Fingertrees.

Funktionale Sprachen bieten so viel, dass es nicht lohnt ueber die Zukunft der Programmierung zu diskutieren, wenn die grundlegenden Konzepte unbekannt sind. Es muss nicht Haskell sein, ML etc. ist auch gut. Dem geneigten Leser mit reichlich Vorkenntnissen empfehle ich immer Pearls of Functional Algorithm Design oder Algebra of Programming .

Cyres

Xin schrieb:

Ich schaue mir regelmäßig neue Sprachen an, um das abzusichern. Alle Sprachen der Welt zu lernen, kann ich aber nicht.

Sieh dir mal die Guards in Haskell an, eine Art switch-case für boolsche Ausdrücke

knivil schrieb:

Funktionale Sprachen bieten so viel, dass es nicht lohnt ueber die Zukunft der Programmierung zu diskutieren, wenn die grundlegenden Konzepte unbekannt sind. Es muss nicht Haskell sein, ML etc. ist auch gut.

hast du schon mal real-world Software von signifikanter Größe in haskell programmiert?

Cyres

Funktionale Programmiersprachen haben durchaus sehr schöne Möglichkeiten (wie die oben erwähnten Guards), aber größere Projekte kann man unmöglich vernünftig in einer Solchen Sprache stemmen.

Antoras

knivil schrieb:

Scheme hat ein nettes Konstrukt: call-with-current-continuation. Damit ist es recht einfach Coroutinen oder McCarthy's amb-Operator zu implementieren.

Funktioniert das auch in Clojure?

Cyres schrieb:

Funktionale Programmiersprachen haben durchaus sehr schöne Möglichkeiten (wie die oben erwähnten Guards), aber größere Projekte kann man unmöglich vernünftig in einer Solchen Sprache stemmen.

Was sind denn die schönen Möglichkeiten an Guards? Die sind bloss lächerlicher Zucker (und dann noch nicht einmal funktional, sogar Perl kennt die). Wenn man Guards als Highlight des Funktionalen ansieht, dann ist natürlich klar, woher der Glaube kommt, "grössere" Projekte wären in funktionalen Sprachen unmöglich.

Haskell wird durchaus schon ernstzunehmend angewendet: http://www.haskell.org/haskellwiki/Haskell_in_industry.

Funktionale und imperative Programmierung unterscheiden sich auf Code-Level natürlich fundamental. Trotzdem besitzen beide die Möglichkeit Abstraktion zu bieten. Schaut man aus einer High-Level-Sicht auf die Programme, gibt es kaum Unterschiede. Daher ist es unsinnig zu behaupten, grössere Projekte wären in FP prinzipiell unmöglich.

die abstraktionen sind aber von unterschiedlicher Art.

in der OOP werden die Interna eines Objekts durch Interfaces (also durch seine Eigenschaften nach außen) abstrahiert. Ein Objekt kann seine Identität behalten, wenn sich sein Zustand ändert.

welche Abstraktion in der FP steht diesem gegenüber?

bei Zustandsänderung ein neues Objekt anzulegen widerspräche eigentlich dem Prinzip vom zeitvariablem Zustand von Objekten.