Was kommt nach der Objektorientierung?

[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.

[LampOfGod]

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

[buchstaben]

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?

[hexpert]

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.

[buchstaben]

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.

[JFB]

In Haskell gibt es ein Modulsystem. Öffentliche Schnittstellen lassen sich (explizit) exportieren (bzw. importieren ), der Rest bleibt als Implementierung verborgen.
Funktioniert wunderbar und mindestens genausogut wie private/public-Angaben in Objektorientierten Sprachen.

[knivil]

@buchstaben: http://www.youtube.com/watch?v=5KT2BJzAwbU

[Xin]

knivil schrieb:

@buchstaben: -

In meinem Forum hätte den Link entfernt, hier fehlen mir in diesem Board die Rechte dazu.

Hier kann ich nur den Hinweis geben, dass wenn man keine Ahnung hat, eine Erklärung hilfreicher wäre als ein überflüssiger Link.

[ioioioio]

Eigentlich verändern sie auch in Haskell Sachen, siehe Monaden.

[redrew99]

Xin schrieb:

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

Nein, kannte ich bislang nicht, die Problematik allerdings schon.
(Ist übrigens ganz lustig, natürlich habe ich die Person, oder was auch immer dazwischen läuft, nicht gesehen.)
Das Beispiel ist aber trotzdem sehr gut. Denn die Wahrnehmung funktioniert nur aufgrund der großen Ähnlichkeiten und der Bewegungsgeschwindigkeit der Teilnehmer nicht.
Könnte man beides beeinflussen, was bei einem 3d-Programm problemlos möglich sein sollte, wird man auch den Typen erkennen, der sich da unerkannt
durch die Mitte bewegen will.

Xin schrieb:

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.

Das glaube ich auch sofort, aber nur, weil man (noch) nicht wirklich in 3d planen kann.

Xin schrieb:

Ich denke, dass 3D-Modellierung den Menschen überfordert.

Könnte sein, daß viele Menschen damit völlig überfordert wären.
Richtige Profis sollten das aber packen. Natürlich nicht von heute auf morgen.
Man müßte wahrscheinlich schon längere Zeit damit zubringen, das zu erlernen.
Wäre halt eine größtenteils neue Programmiersprache.

Generell ist wahrscheinlich die Frage, ob man die Komplexität, die mit Textprogrammen möglich ist, auf den 3d-Bereich übertragen kann.
Im Prinzip geht es ja viel um Visualisierung, im 2D-Bereich ist man damit bislang klar gescheitert, ob eine zusätzliche Dimension daran wesentlich was ändert, wäre wohl entscheidend.

Xin schrieb:

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?

Ein simples Beispiel:
Man nehme zwei Behälter, einen gefüllten, einen leeren, dazwischen ein Sieb und öffne den ersten.

Über komplexe Algorithmen müßten sich Mathematiker Gedanken machen,
im Prinzip müßten aber durch die dritte Dimension auch effektivere Sortieralgorithmen möglich sein.

[hustbaer]

redrew99 schrieb:

Xin schrieb:

Ich denke, dass 3D-Modellierung den Menschen überfordert.

Könnte sein, daß viele Menschen damit völlig überfordert wären.
Richtige Profis sollten das aber packen. Natürlich nicht von heute auf morgen.
Man müßte wahrscheinlich schon längere Zeit damit zubringen, das zu erlernen.
Wäre halt eine größtenteils neue Programmiersprache.

Um programmieren zu können muss man sowieso schon viele Dinge können.
Willst du noch eine Fähigkeit hinzufügen, die man bloss braucht weil sich jemand eingebildet hat dass 3D Tools kuhl wären?

Ich halte das für gar keine gute Idee.
"Ein Profi kann das lernen" ist schnell gesagt. Wie viel das in der Praxis kostet, und was daraus im Endeffekt dann für ein Schaden entsteht ist eine ganz andere Sache.

[redrew99]

hustbaer schrieb:

Um programmieren zu können muss man sowieso schon viele Dinge können.
Willst du noch eine Fähigkeit hinzufügen, die man bloss braucht weil sich jemand eingebildet hat dass 3D Tools kuhl wären?

Die möglichen Vorteile einer 3d-Programmierung hatte ich schon genannt.
Um Coolness geht es nicht.

hustbaer schrieb:

Ich halte das für gar keine gute Idee.
"Ein Profi kann das lernen" ist schnell gesagt.

Jupp, das Argument ist auf jeden Fall berechtigt.

hustbaer schrieb:

Wie viel das in der Praxis kostet, und was daraus im Endeffekt dann für ein Schaden entsteht ist eine ganz andere Sache.

Sry, aber genau die gleiche Kritik kann ich bei jeder Programmiersprache anwenden. Das ist einfach nur ein typisches Totschlagsargument.

[hustbaer]

redrew99 schrieb:

hustbaer schrieb:

Um programmieren zu können muss man sowieso schon viele Dinge können.
Willst du noch eine Fähigkeit hinzufügen, die man bloss braucht weil sich jemand eingebildet hat dass 3D Tools kuhl wären?

Die möglichen Vorteile einer 3d-Programmierung hatte ich schon genannt.
Um Coolness geht es nicht.

Hast du? Dann hab' ichs nicht gesehen. Also keine konkreten Vorteile. "Könnte sein dass man damit was besser machen kann" (sinngemäss) ist auch so ein "Totschlagsargument" wie du es nennst.

redrew99 schrieb:

hustbaer schrieb:

Wie viel das in der Praxis kostet, und was daraus im Endeffekt dann für ein Schaden entsteht ist eine ganz andere Sache.

Sry, aber genau die gleiche Kritik kann ich bei jeder Programmiersprache anwenden. Das ist einfach nur ein typisches Totschlagsargument.

Es mag ein Totschlagsargument sein, aber es stimmt halt auch. Nicht nur hier, sondern auch "allen Programmiersprachen".

Wobei ich einen grundlegenden Unterschied sehe: Das Erlernen einer neuen "klassische" Programmiersprache erfordert in den wenigsten Fällen komplett neue Fähigkeiten.
Das Erlernen bzw. Verwenden einer "3D Programmierpsrache" erfordert dagegen dreidimensionales Vorstellungsvermögen - und das ist eine Fähigkeit die Programmierer mit "klassischen" Programmiersprachen kaum brauchen.

Es geht also nicht nur um den Aufwand etwas ganz neues zu lernen, sondern auch bzw. viel mehr darum, dass du zusätzliche "Fähigkeiten" voraussetzt. Und mit "Fähigkeiten" meine ich etwas was nicht unbedingt erlernbar ist. Der eine kanns, der andere nicht, und wird's auch nie lernen.

Damit engst du den Kreis derer die sich zum Programmierer eignen (mMn. stark) ein.

ps: es hat schon einen Grund dass die "dummen" (=einfach zu erlernenden) Programmiersprachen wie Java und C# so beliebt sind