Verleitet C++ zum komplizierteren denken?
-
otze schrieb:
Du hast eine Menge von Formen: Quadrate, Kreise, Dreiecke, Geraden, Ellipsen (usw usf).
Jetzt möchtest du gerne zwischen all diesen Formen Schnittpunkte berechnen. Es sollen dabei jederzeit neue Formen eingefügt werden können.
Löse das mal ohne double dispatching
Achtung, es folgt eine Parodie:
Das ist ganz leicht in Smalltalk und für user_l keine Herausforderung.
Man nimmt eine Liste (jawohl, keine eigene Klasse, die braucht man nämlich nicht, weil Smalltalk-Code automatisch echtes OOP ist) mit bis zu vier Ellipsen. Die Ellipen können kreisrund (zwei gleiche Halbmesser) sein oder elliptisch (zwei unterschiedliche Halbmesser) oder platt (ein Halbmesser=0) sein. Damit kann man Quadrate, Dreiecke, Kreise, Ellipsen und Geraden (vielleicht ein wenig projektive Geometrie) darstellen, die Schnittpunksbestimmung geht auch ganz natürliche Weise, wenn man es hinbringt, zwei Ellipsen zu schneiden, den Code erspare ich Dir mal.
-
~john schrieb:
Nach meinem Empfinden gibt es ein Problem mit [...], und nicht mit den Erfinder von Simula, C++, …
Soso. In einem Paper vom Simula-Miterfinder Dahl lese ich aber bspw. zu Java: "[...] Its syntax is unfortunately rather close to that of C++ and thus C [...]" . Ein paar Sätze vorher steht auch noch zu C oder C++, daß es schwer sei, komplexe Systeme korrekt zu implementieren, weil C ziemlich nahe am Maschinencode ist (frei wiedergegeben).
Ich weise auf das Wort "unfortunately" oben hin.
An Smalltalk bemängelt er das nicht.
In Zukunft bitte erst informieren, dann kritisieren, nicht wahr ?
~john schrieb:
Zum Beispiel das Laufzeitsystem von Smalltalk läßt sich nicht in Smalltalk programmieren,
Falsch.
Die klassische Smalltalk-VM ist nicht nur in Smalltalk spezifiziert (Kap. 26-30 im legendären Buch von Goldberg und Robson über die Implementation von Smalltalk-80), sondern auch in Smalltalk implementiert worden.
Der maschinenabhängige Teil kann von einer Teilsprache von Smalltalk namens "Slang" nach C übersetzt werden (die entsprechenden Methoden des Translators liegen in Smalltalk vor) und dann compiliert werden.
Nachweis: "The Story of Squeak, A Practical Smalltalk Written in Itself" von Kay, Ingalls, Kaehler, Maloney, Wallace.
Verzichtet man auf einige Performance, kann man ein in Smalltalk selbst formuliertes Smalltalk-System auf einem vorhandenen Smalltalk-System laufen lassen.
~john schrieb:
Schon einmal darüber nachgedacht warum das so ist? ( Offensichtlich nicht, denn dann würdest du nicht so einen Unsinn von dir geben.)
ich schon.
~john schrieb:
Smalltalk kann daher keine Universalsprache sein,
Das ist richtig. C/C++ auch nicht, man braucht zumindest eine CPU, die entweder C oder Maschinensprache versteht, so wie Smalltalk einen C-Compiler zur Compilierung der VM braucht (es sei denn man läßt die VM in einem bereits vorhandenen Smalltalk-System laufen). Und jetzt ?
~john schrieb:
Und das ist exakt die Ursache, weshalb Smalltalk nicht fürs Number Crunching geeignet ist.
Das ist richtig. Dafür kann man externe Libraries inbinden, neue primitives definieren oder plugins programmieren, die die Low-level-Arbeit erledigen.
Kodierst du CPU-Schaltpläne oder Webseiten in C++ ? Eben. Keine Sprache ist gleichermaßen gut für alles geeignet, das hat sich nach nunmehr über 50 Jahren Geschichte der Prog.Sprachen weitestgehend herumgesprochen.
-
volkard schrieb:
Nichts hast Du widerlegt. Du bist ausgewichen und hast deine Implementierung stets den neuen Anforderungen entsprechend umgefrickelt
was redest du da? ich habe 1 Implementation Vektor-Vektor-Produkt und 1 Implementation Matrix-Vektor-Produkt formuliert und damit deine double-dispatch-Behauptung widerlegt.
Wieso bist du und ~john so angriffslustig?
Ich jedenfalls kann noch sehr lange freundlich bleiben, weil ich genug Argumente vorbringen kann, die meine Punkte stützen.
-
u_ser-l schrieb:
Ich jedenfalls kann noch sehr lange freundlich bleiben, weil ich genug Argumente vorbringen kann, die meine Punkte stützen.
Wenn NULL Dir genug ist? Mir nicht.
Dabei zähle ich halt nicht mehr die Argumente mit, die vollständig zerbröselt sind und sich in Widersprüchen aufgelöst haben.
-
Vielleicht sollte man diese Diskursion beenden, bevor sich die Teilnehmer noch mit Äxten oder der gleichen bekriegen. Das wird zu nichts führen, weil jeder auf seinem Standpunkt verweilen wird. Smalltalk hat daseinsberechtigung, genauso wie C++ und C.
-
otze schrieb:
Du hast eine Menge von Formen: Quadrate, Kreise, Dreiecke, Geraden, Ellipsen (usw usf).
Jetzt möchtest du gerne zwischen all diesen Formen Schnittpunkte berechnen. Es sollen dabei jederzeit neue Formen eingefügt werden können.
Löse das mal ohne double dispatchingdas ist einfach zu konzipieren, der Schnittalgorithmus dürfte allerdings alles Andere als trivial sein: eine Klasse "Drawing", die die Ränder geometrischer Figuren als Liste repräsentiert, die aus verschiedenen Elementen zusammengesetzt sein können: Strecken, Ellipsenbögen und -Teilbögen (Spezialfall: Kreisbögen).
Diese Klasse enthält eine Methode "cutWithDrawing: ...", die einen allgemeinen Algorithmus beinhaltet, der aus 2 solchen Figuren Schnittpunkte oder Schnittmengen berechnet. Schnittmengenberechnung ist nicht trivial, aber mit linearer Programmierung und quadratischen Gleichungen und Ungleichungen machbar.
Es handelt sich im Wesentlichen um Vereinigungen von Lösungsmengen nichtlinearer/quadratischer Ungleichungssysteme im R^2. Die Schnittpunkte zu bestimmen, dürfte einfacher sein: quadratische Gleichungssysteme im R^2.
-
lol. meine lösung war eine parodie. dachte nicht, daß ich das noch dazuschreiben muß.
-
@~john:
wenn dich das Thema interessiert, kannst du im web nach +ducasse +smalltalk +books suchen.
-
Dann spiel ich eben den "beliebig erweiterbar" Joker aus:
Es soll ein neues Objekt hinzugefügt werden, das auf Basis einer beliebig schwingenden komplexen e-Funktion auf Basis von Polarkoordinaten dargestellt wird. Hierbei ist zu beachten, dass die Funktion periodisch in 2pi ist.
Der komplexwertige Teil des Ergebnis entspricht der Y koordinate während der Realteil der X-Koordinate entspricht(lies: Das Ding kann beliebige "Kreisähnliche" Objekte darstellen. Unter anderem auch Formen wie Kleeblätter. Ein Algorithmus zur numerischen Berechnung der Schnittpunkte existiert.)Ich hoffe, damit habe ich alle möglichen Ausflüchte mit abgedeckt. Wahrscheinlich nicht, aber egal.
-
otze schrieb:
Dann spiel ich eben den "beliebig erweiterbar" Joker aus:
Viel einfacher wäre es, nach dem Schneiden von Geraden, Kreisen und Ellipsenbögen ohne double dispatching zu fragen, ein wenig zu warten...
Ich schätze, entweder gibt's bald nur noch Ellipsenbögen in clipping rectangles, oder jedes Primitiv kann eine beschreibende Gleichung ausgeben und zum Schneiden wird zur Laufzeit ein externes Computeralgebrasystem verwendet.
-
pointercrash() schrieb:
Man kann aber auch verstehen wollen, was u_ser-l gemeint hat.
Schau Dir mal den Threadtitel an. Es ist selbstverständlich, daß C++ als Multiparadigmensprache komplizierter ist. Aber die optimale Lösung für Probleme ist nun einmal jedesmal eine andere. Smalltalk kennt nur eine Methodenart, die ist zwar flexibel aber auch dem entsprechend langsam. Um bei Volkards Vergleich zu bleiben: Die Smalltalker kennen nur den Zimmersmannshammer und meinen nun, das sei das optimale Werkzeug. Schrauben muß man so natürlich mit dem Hammer in den Wand klopfen und mit der anderen Seite brutal rausreißen.
C++ entspricht da dem kompletten Werkzeugkoffer. Erstmal Loch mit dem Bohrhammer bohren, mit dem Staubsauger reinigen, Dübel mit dem Hammer reinklopfen, Schraube mit dem Schraubendreher einschrauben. Das alles ist natürlich viel komplizierter aber am Ende hält die Sache auch besser. Für einige Probleme ist C++ nicht so gut gerüstet, da man die Arbeit von Hand machen muß, anstatt dies der Compiler für einem übernähme.
pointercrash() schrieb:
Das OOP- Zeugs bei C++ ist C-Syntax- mäßig in die Sprache geflickt
Es paßt von der Syntax her besser zu C als die Objective-C Konstrukte, da hier in normaler Syntax Methoden als spezielle Funktionen, die zu Objekten gehören aufgerufen werden. Aber das ist persönliche Vorliebe.
pointercrash() schrieb:
C++ mit late binding aufzubohren,
"Late Binding" halte ich genauso wie "dynamische Bindung" für eine extrem verunglückte Formulierung, da sie nicht eindeutig ist. In älteren Linker Handbüchern wird nämlich immer von late bzw. dynamic binding gesprochen, wenn man DSOs generiert und diese dann beim Laden gebunden werden. Und dabei taucht der Begriff OOP noch nicht einmal auf.
Was den Themenkomplex dynamic dispatch betrifft. Ja, das ist in C++ ein Problem, und man muß entsprechenden Aufwand betreiben. Nicht schön, und daher wird für viele Probleme C++ auch nicht eingesetzt. Es hat schon seine Gründe, weshalb Web Apps meist mit RoR, Python+WebFramework, Java, … realisiert werden.
pointercrash() schrieb:
wenn ich nur ein Loch in einen Karton bohren will - da reicht mir ein Bleistift.
Stimmt, aber der Profiwerkzeugkasten wird deshalb nicht schlecht, weil Du dessen Werkzeuge nicht brauchst. Er ist nur für Deine Probleme überdimensioniert. Aber hier gibt es Personen, die wollen einem beständig das Gegenteil einreden.
pointercrash() schrieb:
Nur - und das ist der springende Punkt - haben es die "C++ - Experten" vor mir geschafft, ein ehedem funktionierendes Gerät gründlich zu vermurksen
Na, da habe ich bei der Ursachenforschung so meine Zweifel. Wenn das Managment Vorgaben macht und anschließend beständig das Personal wechselt kann das nichts werden. Und das ist ziemlich unerheblich von der Sprache.
pointercrash() schrieb:
Wenn etwas so mächtig ist und so viel kann, daß man kaum jemanden findet, der das souverän bedienen kann, muß es sich in der Sicht eine Frage nach dem Sinn gefallen lassen.
Das Problem ist, daß viele zu viele Personen da draußen herumlaufen, die einem Gottkomplex haben. Anstatt auf etablierte C++ Standardtechniken zu setzen und die Standard Library oder Boost zu nutzen, meinen viele sie hätten es drauf etwas besseres erschaffen zu können. Das endet bei vielen "Experten" in Desaster. Wie schon recht früh in diesem Thread beschrieben, muß in so einem Fall natürlich die Sprache schuld sein. Das Ego dieser Personen verträgt keine andere Interpretation.
-
u_ser-l schrieb:
Die klassische Smalltalk-VM ist nicht nur in Smalltalk spezifiziert (Kap. 26-30 im legendären Buch von Goldberg und Robson über die Implementation von Smalltalk-80), sondern auch in Smalltalk implementiert worden.
Das habe ich befürchtet. Nein, ein in Smalltalk geschriebener Codegenerator macht Smalltalk eben nicht selbsthostingfähig! Wenn Smalltalk selbsthostingfähig wäre, müßte man die VM nicht in einer abgespeckten oder sonst irgend wie veränderten Sprache programmieren. Es wäre ein Compilerbackend für die jeweilige CPU-Architektur ausreichend, so wie das bei Ada, C, C++, … der Fall ist.
Da Smalltalk nicht in der Lage ist, auf LowLevel Ebene Zeiger zu verwalten, wie dies aktuelle Prozessoren verlangen, kann die Sprache nicht selbsthostingfähig sein. Auch läßt sich der GC in Smalltalk nicht formulieren, denn Smalltalk basiert auf der Annahme, daß die Smalltalk-VM gerade diese Fähigkeiten zu Verfügung stellt.
-
u_ser-l schrieb:
Wieso bist du und ~john so angriffslustig?
Wer will die ganze Zeit der Menschheit einreden C++ sei überkompliziert?
-
daß es so schwer ist, gute Argumente gegen Smalltalk zu finden, liegt einfach daran, daß Smalltalk nicht irgendeine OO-Sprache ist, sondern im Grunde genommen die OO-Sprache: denkt man (klassenbasierte) OOP konsequent zu Ende, wird Smalltalk oder etwas Ähnliches dabei herauskommen.
Smalltalk verkörpert die klassenbasierte OOP in ähnlicher Weise, wie Lisp das Listenparadigma und Forth das 2-Stack-Paradigma verkörpern oder die Arithmetik die Modelle der Peano-Axiome - die können auch nicht aus der Mode kommen, weil sie Lösungen abstrakter Aufgaben und keine Geschmacks- oder Ansichtssachen sind.
-
~john schrieb:
Das habe ich befürchtet. Nein, ein in Smalltalk geschriebener Codegenerator macht Smalltalk eben nicht selbsthostingfähig!
doch, nur nicht auf jedem beliebigen host, also z.B. nicht auf einer rohen CPU. Ein laufendes Smalltalk-System als host genügt bereits, um eine in Smalltalk geschriebene VM zu fahren, auf der dann das image mit dem eigentliche System läuft, wenn auch mit Verlust an Performance.
-
u_ser-l schrieb:
denkt man (klassenbasierte) OOP konsequent zu Ende, wird Smalltalk oder etwas Ähnliches dabei herauskommen.
Völlig ohne Beleg oder Versuch einer Begründung.
u_ser-l schrieb:
Smalltalk verkörpert die klassenbasierte OOP in ähnlicher Weise, wie Lisp das Listenparadigma und Forth das 2-Stack-Paradigma verkörpern oder die Arithmetik die Modelle der Peano-Axiome - die können auch nicht aus der Mode kommen, weil sie Lösungen abstrakter Aufgaben und keine Geschmacks- oder Ansichtssachen sind.
Komisch. Welche Auflage hatte das Buch, wo Du das her hast?
-
u_ser-l schrieb:
daß es so schwer ist, gute Argumente gegen Smalltalk zu finden, liegt einfach daran, daß Smalltalk nicht irgendeine OO-Sprache ist, sondern im Grunde genommen die OO-Sprache: denkt man (klassenbasierte) OOP konsequent zu Ende, wird Smalltalk oder etwas Ähnliches dabei herauskommen.
oh mann, hör auf deine eigene Sprache zu definieren, dein Problem ist nicht das klassenbasierte OOP, sondern, dass du denkst OOP kollidiert mit einem statischem Typesystem.
-
@user-l: ich würde dir als Smalltalk-nicht-kenner zugestehen, dass du in Bezug auf Smalltalk gute Antworten gegeben hast, aber nicht in Bezug auf C++.
Ich würde auch nicht im Traum drauf kommen zu behaupten C++ sei besser als Smalltalk, weil ich Smalltalk nicht kenne, aber du behauptest Smalltalk sei besser als C++ ohne C++ zu kennen.
Auch wenn deine Antworten ggf. Kenntniss in Smalltalk enthalten bewegen sich deine Beiträge bezüglich C++ auf frickyniveau:
du bewertest C++ nach Smalltalkkriterien, genau wie fricky C++ nach java oder C Kriterien beurteilt. Du setzt ohne nachzudenken vorraus, dass ein dynamisches Typsystem immer besser ist als ein statisches Typsystem. Du setzt ohne nachzudenken vorraus, dass OOP für jedes Problem die beste Lösung ist etc.
C++ hat sich bewusst für ein statisches Typsystem entschieden und es gibt Gründe dafür. Solange du nicht gegen diese Gründe _argumentierst_ anstelle zu sagen, dass das ein Problem an C++ ist sind deine Aussagen gegen C++ völlig wertlos.
-
JustAnotherNoob schrieb:
aber du behauptest Smalltalk sei besser als C++ ohne C++ zu kennen.
wo denn? Ich behaupte, daß die Objektorientierung in C++ nicht so konsequent ist wie in einigen anderen Sprachen. Was in der Natur der Sache (C-Kompatibilität, statische Typisierung) liegen kann, aber nicht muß, wie objective-C beweist.
Und ich bin überzeugt, daß jede klassenbasiert-Objektorientierte Sprache - und wenn nicht jede, so doch zumindest die meisten -, wenn man ihr genügend Zeit (Jahrzehnte) zur Weiterentwicklung und Reifung geben würde, syntaktisch und semantisch gegen eine Sprache wie Smalltalk konvergiert.
STL und boost sind Meilensteine, und sie liegen genau auf diesem Weg. Vielleicht könnte C++1x ein paralleles dynamisches Typsystem haben, C++2x eine konsequentere object-message-passing-Syntax und C++3x Zahlen, Klassen und Funktionen als Objekte samt Metaklassen ?
-
~john schrieb:
++fricky schrieb:
In java musste nix von hand freigeben, vor allem nicht 'ständig'.
Wieder jemand der ständig Resourenlöcher in Java produziert, weil er es nicht verstanden hat die notwendigen finally {foo.dispose()} Blöcke einzufügen. In Java muß Resourcen wieder von Hand explizit freigeben.
ach quatsch, so'n try{...}finally{...} siehste vielleicht alle 20000 zeilen. so häufig und wichtig ist es garnicht, wie ihr c++ fans vielleicht glaubt.
pointercrash() schrieb:
Um C++ gerecht zu werden, muß man es - wie volkard trefflich bemerkt hat - wirklich als Multiparadigmensprache sehen, es ist wie eine nahzu vollständig eingerichtete Werkstatt für Profis - so ziemlich alles geht damit.
'werkstatt für profis' ist reichlich übertrieben. ich würde eher sagen: chaotische bastelkiste, die mangelhaftes werkzeug und viele utensilien zum improvisieren enthält. man braucht viel praxis und kreativität, um was vernünftiges damit hinzubekommen. ein veranlagung zum 'komplizierten denken' ist natürlich auch nicht verkehrt.