Was kommt nach der Objektorientierung?
-
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...
-
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.
-
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.
