Was kommt nach der Objektorientierung?
-
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.
-
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...
-
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 DesignoderAlgebra of Programming.
-
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?
-
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.
-
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.
-
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.
-
@buchstaben: http://www.youtube.com/watch?v=5KT2BJzAwbU
-
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.
-
Eigentlich verändern sie auch in Haskell Sachen, siehe Monaden.
-
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.
-
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.
-
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.
-
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
-
redrew99 schrieb:
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.Die Bewegungsgeschwindigkeit von Quelltext ist 0 - sofern nicht gescrollt wird.
Das sollte auch so bleiben, ich würde es jedenfalls als unschön finden, wenn sich Algorithmen vor mir verstecken...redrew99 schrieb:
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.
Man wird nie in 3D planen können, sondern nur modellieren. ^^
Und hier kommt eben der Punkt, dass wir nicht 3D sehen könne, also den Überblick verlieren werden.
Wir haben nunmal nur 2D Sinnesorgane. Und damit stellen wir uns eine 3D Welt vor. Wenn wir hinter ein Objekt greifen wissen wir aber nicht, ob da die Flasche Wasser, ein nicht isoliertes Stromkabel oder ein Wurmloch ist.
Wir wissen, dass unser Hirn mit auf 2 * 2D arbeitet. Wir kombinieren Zusatzinformationen (Hinder dem Objekt fühlt es sich nach Glas an, es schmerzt und riecht nach verbrannten Fleisch oder die Hand erscheint an einer anderen Stelle im Zimmer. Vorstellen können wir uns das nicht. Für das Wurmloch bräuchten wir eine vierte Dimension, in der wir die drei ertastbaren Dimensionen krümmen könnten wie ein Blatt Papier im 3D-Raum, so dass sich der 3D-Raum wieder berührt. Verstehst Du, was ich erkläre? Kapiert kein Mensch.
Ich verstehe nichtmals alle Algorithmen im 2D.redrew99 schrieb:
Richtige Profis sollten das aber packen. Natürlich nicht von heute auf morgen.
Ich habe nur ein Diplom der Informatik, arbeite in CAD-Bereich. Ich habe nicht das Gefühl, dass ich eine 3D-Programmierung in den nächsten 5 Jahren verkraften würde.
redrew99 schrieb:
Wäre halt eine größtenteils neue Programmiersprache.
Eigentlich wäre es auch keine Sprache mehr. Eine Sprache ist eindimensional, es sei denn, Du liest Postings kursorisch. Das kann ich nicht, weil meine Wahrnehmung eingeschränkt ist (der Daumen der ausgestreckten Hand). Du liest also die Zeile in einer Dimensionsrichtung ab.
Du kannst ja auch nicht zwei Sprechern gleichzeitig zuhören. Alles eindimensional.Der erste Schritt wäre also erstmal eine 2D-Sprache zu entwickeln - und zu begründen.
Wir benutzen zwei Dimensionen für Text, weil die Zeilenlänge begrenzt ist. Welchen Vorteil bringt
die dritte Dimension in der Semantik einer Sprache?redrew99 schrieb:
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.Was ist ein Behälter? Was wird hier sortiert? Wie erkläre ich "Behälter" und "Sieb" meiner CPU?
Eine Progammiersprache ist - auch wenn diese Ansicht derzeit deutlich aus der Mode gekommen ist - immer Vermittler zwischen Entwickler und Maschine. Und eine Sprache muss effizient sein, denn Brute-Force-Sprachen, wie Prolog sind zwar geniale Ideen, aber im Alltag trotzdem nicht zu gebrauchen.
hustbaer schrieb:
ps: es hat schon einen Grund dass die "dummen" (=einfach zu erlernenden) Programmiersprachen wie Java und C# so beliebt sind
Du sprichst mir aus der Seele.
-
Richtige Profis sollten das aber packen
Komische Aussage. Rate mal, warum Java so erfolgreich ist. Damit fuer die meisten Programmteile eben keine Profis* erforderlich sind.
*Profis: Mag jeder anders definieren.
Brute-Force-Sprachen, wie Prolog sind zwar geniale Ideen
Hust ... Manche steuern damit Militaerhubschrauber. Und ja, Lisp war im Weltall. Kann das Java von sich behaupten?
-
knivil schrieb:
Und ja, Lisp war im Weltall. Kann das Java von sich behaupten?
Ohne ein Beispiel nennen zu können würde ich darauf wetten.
Die (relativ kleine) Firma in der ich arbeite hat vor wenigen Jahren Messgeräte für die ISS geliefert. Die waren unabhängig von den Systemrelevanten Geräten und wurden "nur" für Experimente verwendet. Bald startet eine Neue Mission, diesmal auch noch mit Software aus unserm Haus die auf einem Notebook betrieben wird und die Messgeräte steuert.
Der ESA ist es scheiß egal welche Sprache da zum Einsatz kommt, solange sehr gut Dokumentiert wird. V.a. bei Änderungen. Hochgeschickt wird eine abgewandelte Delphi-Software weil sie seit Jahren auf der Erde im Einsatz ist (auch wenn sie totaler Müll ist, unter uns gesagt). Die Alternative wäre C# gewesen nur ist die Basissoftware dazu leider noch nicht so lange im Einsatz und das zählt für Änderungsmanagement-Junkies mehr als die Qualität.
Was ich sagen will: Es hätte genauso gut Java sein können und ich bin mir sicher dass da oben etliche Millionen Zeilen Code jeder bekannten Sprache im Einsatz sind.
