Verleitet C++ zum komplizierteren denken?

[*john 0]

u_ser-l schrieb:

Du kannst du mich so oft der Unkenntnis bezichtigen wie du willst.

Aha, keine Argumente mehr. Die Tatsache, daß du C++ und die in C++ nicht verwendeten Konzepte nicht kennst und schon gar nicht verstanden hast, ist eine offensichtliche Tatsache. Das zeigt sich an deinen Programmbeispielen.

Es wäre so einfach zu zeigen, daß man in Java Resourcen nicht von Hand explizit verwaltet, wenn es denn der Wahrheit entspräche. Offensichtlich ist nur, daß du und andere keine konkreten Beispiele bringen, wie man es denn ohne explizite Freigabe von Resourcen hinbekommt.

[audacia]

u_ser-l schrieb:

C++ ist nicht OOP in dem Sinne, in welchem etwa Smalltalk OOP ist, und kann es auch gar nicht sein, solange es Sprachmittel gibt, die erlauben, mittels Zeigern den Speicher zu manipulieren.

Spätestens wenn du selbst zu linguistischen Workarounds wie "OOP in dem Sinne, in welchem" greifen mußt, solltest du doch mal beginnen, deinen Standpunkt infrage zu stellen

Was du ansprichst, hat mit objektorientierter Programmierung nichts zu tun. Das fragliche Kriterium nennt sich Typsicherheit; C++ ist nicht typsicher, Java schon, und Smalltalk vermutlich auch. Das ist in der Theorie ein wichtiger Aspekt, weil Typsicherheit WPO und allgemein Optimierungen signifikant vereinfacht. (In der Praxis sind die am besten optimierenden Compiler dennoch C++-Compiler )

[pointercrash**]

Man kann aber auch verstehen wollen, was u_ser-l gemeint hat.
Das OOP- Zeugs bei C++ ist C-Syntax- mäßig in die Sprache geflickt und bietet nicht die extreme Flexibilität zur Laufzeit wie z.B. Smalltalk oder die Objective-C- OOP. Die Versuche, C++ mit late binding aufzubohren, sind schon von Berufeneren als mir als krude und halbgar kritisiert worden.
Dafür kann man mit C++ auch hardwarenahe Treiber schreiben - das soll mal jemand mit Smalltalk probieren :p .

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. Ohne umfassende Ausbildung verlier' ich aber an der Seilsäge eher ein paar Finger, als daß ich damit Freiformen schneide. Und bis ich so alle Werkzeuge kenne, gibt es viel zu lernen - und C++ hat einen geradezu monströsen Umfang. All das brauch' ich aber nicht, wenn ich nur ein Loch in einen Karton bohren will - da reicht mir ein Bleistift. Um den Vergleich beizubehalten: Mir genügt z.B. ein kleiner, gut sortierter Werkzeugkasten, aus dem ich mich aufgabenbasierend bediene. Wenn ich am PC ein paar bunte Buttons haben will, genügen mir Delphi oder VB, seit ein paar Wochen spiel' ich auch mit Java rum. Für den Microcontroller ist C völlig ausreichend - zumindest für mich. Heißt, für meine Belange wäre C++ völlig überflüssiger Ballast.

Ich hab' mich trotzdem mal damit befasst, war so 'ne Handbedieneinheit, größtenteils in C geschrieben, bis irgendein Schlauli von Product Manager bemerkt hat, daß der Compiler jetzt auch C++ kann und die Fortentwicklung in C++ befohlen hat. Weil der ursprüngliche Programmierer das nicht so wollte, sind in der Folge nacheinander fünf, sechs andere Leute an der Sache gesessen, wobei sich immer mehr Seltsamkeiten in das Gerät geschlichen haben. Ich habe mich für die Geschichte interessiert, als ich dann die Source gesehen habe, ist mir schlecht geworden. Erstmal war der Mischmasch von C und C++ ausgesprochen unglücklich (ich hätte z.B. erwartet, daß hardwarenah alles in C bleibt, war aber nicht so) und ich mich mit völlig unterschiedlichen Programmierstilen konfrontiert sah. Die Sachen, die ich kapiert habe, fand ich zu umständlich und vieles hab' ich gar nicht erst kapiert, wie das funzen soll. Das alles natürlich aus Sicht eines C- Programmierers.

Ich mußte einsehen, daß man dazu einen Werkstattleiter braucht, das in Ordnung zu bringen und keinen Heimwerker mit Akkubohrschrauber und habe zurückgegeben. Nur - und das ist der springende Punkt - haben es die "C++ - Experten" vor mir geschafft, ein ehedem funktionierendes Gerät gründlich zu vermurksen und keiner hat den oder die Fehler gefunden. Das bedeutet, daß Leute, die C++ nicht nur können, sondern wirklich beherrschen, wohl äußerst rar sind.

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.
Vielleicht liegt ja wirklich der Sinn darin, daß die "echten Experten" was haben, damit sie sich über andere lustig machen können ... wer weiß?

[volkard]

~john schrieb:

Aha, keine Argumente mehr. Die Tatsache, daß du C++ und die in C++ nicht verwendeten Konzepte nicht kennst und schon gar nicht verstanden hast, ist eine offensichtliche Tatsache. Das zeigt sich an deinen Programmbeispielen.

Smalltalk kennt er auch nur rudimentär, sonst hätte er double dispatching schonmal gesehen und dessen Sinn verstanden.

[volkard]

pointercrash() schrieb:

Werkstattparabel

Auch völlig ohne Fachwissen würde ich in der ordentlichen Werkstatt lieber arbeiten. Da gibt es gleich fünf passende Schraubendreher und nicht nur einen, und ich kann den allerpassendsten nehmen. Ich habe einen ordentlichen Amboß, der unverständlicherweise in allen Werkzeugkästen weggelassen wurde! Einen Schraubstock. Werkbänke. Gute Beleuchtung. Staubsauger.
Und die großen elektrischen Maschinen (vor allem die elektrische Hobelbank) machen mir doch Angst, also schalte ich sie nicht an.
Aus Angst vor der Seilsäge den Raum nicht zu betreten, nee, das ist nicht mein Stil. Ich geh da einfach rein und arbeite los und schneide mir keine Finger ab.
Und wenn ich viel sägen muß, lese ich mir halt das Handbuch zur Säge durch (ja, ich lese immer die Handbücher, selbst zu einem Toaster) und finde heraus, wie man damit gescheit arbeitet, zunächst allein durch Nachdenken, danach durch gelegentliche kleine Anwendungen.

[zwutz]

volkard schrieb:

pointercrash() schrieb:

Werkstattparabel

Auch völlig ohne Fachwissen würde ich in der ordentlichen Werkstatt lieber arbeiten. Da gibt es gleich fünf passende Schraubendreher und nicht nur einen, und ich kann den allerpassendsten nehmen. Ich habe einen ordentlichen Amboß, der unverständlicherweise in allen Werkzeugkästen weggelassen wurde! Einen Schraubstock. Werkbänke. Gute Beleuchtung. Staubsauger.
Und die großen elektrischen Maschinen (vor allem die elektrische Hobelbank) machen mir doch Angst, also schalte ich sie nicht an.
Aus Angst vor der Seilsäge den Raum nicht zu betreten, nee, das ist nicht mein Stil. Ich geh da einfach rein und arbeite los und schneide mir keine Finger ab.
Und wenn ich viel sägen muß, lese ich mir halt das Handbuch zur Säge durch (ja, ich lese immer die Handbücher, selbst zu einem Toaster) und finde heraus, wie man damit gescheit arbeitet, zunächst allein durch Nachdenken, danach durch gelegentliche kleine Anwendungen.

200m² Werkstatt, aber wer nen Mülleimer da drin haben will, muss ihn sich selber bauen :p (zugegeben, er läuft dann immerhin hinter einem her, erkennt und vernichtet zuverlässig jeden Müll und räumt sogar das Werkzeug wieder auf)

[pointercrash**]

volkard schrieb:

... Aus Angst vor der Seilsäge den Raum nicht zu betreten, nee, das ist nicht mein Stil. Ich geh da einfach rein und arbeite los und schneide mir keine Finger ab.
Und wenn ich viel sägen muß, lese ich mir halt das Handbuch zur Säge durch (ja, ich lese immer die Handbücher, selbst zu einem Toaster) und finde heraus, wie man damit gescheit arbeitet, zunächst allein durch Nachdenken, danach durch gelegentliche kleine Anwendungen.

Ne, der Witz ist, daß Du das Handbuch komplett lesen mußt, bevor auch Du nur einen Schnitt - und sei er in die Finger - machen kannst. Wie man sieht, sind ja viele selbsternannte C++- Experten nicht dazu in der Lage, sich einen vollständigen und anwendungssicheren Überblick zu verschaffen.
Vielleicht macht's Dir Spaß, aber mir ist das einfach zuviel Gedöns, wenn ich mit anderen Tools schneller zu Potte komme.

[volkard]

zwutz schrieb:

(zugegeben, er läuft dann immerhin hinter einem her, erkennt und vernichtet zuverlässig jeden Müll und räumt sogar das Werkzeug wieder auf)

...und er schubst einen dabei aus Versehen in die Säge.
Ungefähr das ist das Threadthema, verleitet eine große Werkstatt einen dazu, unproduktiven oder sogar gefährlichen Unfug zu treiben?

[pointercrash**]

volkard schrieb:

...und er schubst einen dabei aus Versehen in die Säge.
Ungefähr das ist das Threadthema, verleitet eine große Werkstatt einen dazu, unproduktiven oder sogar gefährlichen Unfug zu treiben?

Das kannten wir schonmal unter dem Slogan "gefährliches Halbwissen", nur daß die ComputerBild da wohl kaum Abhilfe schaffen wird.

[u_ser-l]

volkard schrieb:

Smalltalk kennt er auch nur rudimentär, sonst hätte er double dispatching schonmal gesehen und dessen Sinn verstanden.

dafür, daß du Behauptungen über double dispatching gemacht hast, die ich mit wenigen Zeilen Smalltalk widerlegt habe, bist du ganz schon aggressiv.

ist mir aber egal. Wenn es dich ärgert, daß du mich nicht widerlegen kannst, ist das nicht mein Problem.

[otze]

u_ser-l schrieb:

dafür, daß du Behauptungen über double dispatching gemacht hast, die ich mit wenigen Zeilen Smalltalk widerlegt habe, bist du ganz schon aggressiv.

Hast du nicht. Du kanntest offensichtlich das Problem nicht richtig. Sonst hättest du das Beispiel nicht 10mal korrigieren müssen und es wäre nicht so ein übelst hässlicher (und unperformanter) Code dabei rausgekommen.

Wir könnten das Beispiel aber nochmal etwas verkomplizieren, und dann würde ich gerne deine Lösung dazu hören:

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

[volkard]

u_ser-l schrieb:

dafür, daß du Behauptungen über double dispatching gemacht hast, die ich mit wenigen Zeilen Smalltalk widerlegt habe, bist du ganz schon aggressiv.

Nichts hast Du widerlegt. Du bist ausgewichen und hast deine Implementierung stets den neuen Anforderungen entsprechend umgefrickelt, statt es ordentlich zu machen und das vorgehen, was da dauernd in den Smalltalk-Büchern steht, zu wählen. Dabei hast Du die Implemetierung ohne Not langsamer gemacht. Die Eine-Hashtable-Implemetierung hast Du GAR NICHT vorgebracht, weil die nicht zu deiner Frickellösung paßt und Du doch dispatchen müßtest. Du hast aufgegeben. Um das zu vertuschen, hast Du eine Lösung mit mehreren Hashtables gezeigt.
Anscheinend hast Du auch keinen meiner Links verfolgt. Tu das doch mal. Da stehts doch drin.
http://books.google.de/books?id=cwIgvtFOCyEC&pg=PA191&lpg=PA191&dq=smalltalk+double+dispatching&source=bl&ots=p3rKdaDYfs&sig=cmXkq0mQJPpfTitkHnjsdR6Dm6M&hl=de&ei=3dVtStWJL5jcmgPRlYCLDg&sa=X&oi=book_result&ct=result&resnum=3

[volkard]

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.

[u_ser-l]

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

[u_ser-l]

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.

[volkard]

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.

[Sinnlos]

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.

[u_ser-l]

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

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

[volkard]

lol. meine lösung war eine parodie. dachte nicht, daß ich das noch dazuschreiben muß.

[u_ser-l]

@~john:

wenn dich das Thema interessiert, kannst du im web nach +ducasse +smalltalk +books suchen.