Was kommt nach der Objektorientierung?

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

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