Verleitet C++ zum komplizierteren denken?



  • 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.
    🙂



  • u_ser-l schrieb:

    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 ? 🙂

    Eher glaub ich, dass meine eigene Programmiersprache über den Konzeptphase kommt 😃

    def main : (void->void) {
    	def mainFrame = Frame new;
    	mainFrame {
    		title "My App";
    		size 500,600;
    		visible true;
    
    		onClick (void->void) = system exit 0;		
    	}
    	mainFrame delete;
    };
    


  • hab ich was vom Trend verpasst?
    In letzter Zeit geht die Entwicklung neuer Programmiersprachen doch von OOP weg?

    wo denn? Ich behaupte, daß die Objektorientierung in C++ nicht so konsequent ist wie in einigen anderen Sprachen.

    Volle Zustimmung, die Prinzipien von C++ sind nicht nur auf die objektorientierte Programmierung ausgerichtet, absichtlich, aber du kannst konsequent objektorientiert darin programmieren und das ist hier die Kernaussage.

    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 ?

    Das meine ich. Du setzt ohne wenn und aber voraus, dass diese Systeme besser sind als das aktuelle System.

    Ich würde deinen Argumenten folgen, wenn ich eine Sprache betrachten würde, die OOP selbst verinnerlicht, wie zum Beispiel Java. Aber C++ ist keine rein objektorientierte Sprache, will dies und wird dies nie sein.

    edit:

    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 ?

    paralleles dymamisches Typsystem widerspricht den Prinzipien von C++, das wäre wie wenn du in Smalltalk nicht-objekttypen einbaust.
    object-message-passing-Syntax und Zahlen, Klassen und Funktionen würde ebenfalls für mehr überflüssige Laufzeitkosten sorgen. Dass das nicht immer das wichtigste ist mag sein, aber in C++ ist es das, denn C++ ist nicht Smalltalk und C++ hat den Anspruch resourcenschonend und schnell zu sein, nichts zu verbrauchen, was man nicht braucht.
    Warum sollte C++ den selben Konzepten wie Smalltalk folgen? Das wäre doch unsinnig, wir haben doch schon ein Smalltalk, wir brauchen nicht noch eins.

    edit2:

    ch quatsch, so'n try{...}finally{...} siehste vielleicht alle 20000 zeilen. so häufig und wichtig ist es garnicht, wie ihr c++ fans vielleicht glaubt.

    das hat dich bei volatile int* auch nicht gestört... und da waren es eher nochmal zwei nullen mehr, oder noch mehr.
    Und ich denke bei dir ises eher 1-2 Nullen weniger, in deinem Code vielleicht nicht, ich gehe ja von guten Programmierern aus. Das sind für mich nur Leute, die sich mit Sprachen und Konzepten beschäftigen, du also nicht.

    edit3:
    user-l ist es so schwer nachzuvollziehen, dass man hier irgendwann bissig wird? Thread für Thread wird dieses schöne Forum zugespammt... was machst du überhaupt hier? Bei fricky weiß man zumindest, dass er wegen C hier im Forum unterwegs ist, mal abgesehen davon, dass er abundzu Copy&Paste aus einer Datei auf seinem Computer anwendet und das dann in C++ Flamethreads pastet, aber was machst du eigtl. noch hier? Du magst kein C++? Du willst nichts über C++ lernen? tschüss.

    edit4:
    Und dann gibt es noch Leute wie ich, die diese Threads immer mal verfolgen um zu sehen was sie denn an sinnvoller Kritik an C++ aufschnappen können, denn diese Ernst zu nehmen erweitert den Horizont. Und natürlich habe ich hier schon einige für mich neue Konzepte und ernstzunehmende Kritik gesehen... aber die kommen normalerweise entweder von C++ Programmierern selbst, oder von Leuten die C++ beherschen. Das dumme an Leuten wie mir ist nur, dass sie sich nicht zurückhalten können, dann doch noch was zu schreiben, wenn fricky mal wieder langweilig ist.



  • JustAnotherNoob schrieb:

    Volle Zustimmung, die Prinzipien von C++ sind nicht nur auf die objektorientierte Programmierung ausgerichtet, absichtlich,

    dann sind wir uns doch einig 😕

    JustAnotherNoob schrieb:

    aber du kannst konsequent objektorientiert darin programmieren und das ist hier die Kernaussage.

    mit Einschränkungen.



  • u_ser-l schrieb:

    wo denn? Ich behaupte, daß die Objektorientierung in C++ nicht so konsequent ist wie in einigen anderen Sprachen.

    Das kann in einer selbsthostingfähigen Multiparadimensprache grundsätzlich nicht der Fall sein, aber darauf könnte man auch selbst kommen, wenn man sich mit den Eigenschaften eines realen Prozessores auseinandersetzen würde.

    u_ser-l schrieb:

    Was in der Natur der Sache (C-Kompatibilität, statische Typisierung) liegen kann, aber nicht muß, wie objective-C beweist.

    Da kennt jemand Objective-C nicht. (die wievielte Sprache ist das nun über die du fast nichts weißt und trotzdem drüber schreibst?) Bei Systemnaher Programmierung bist du bei Objective-C auf C beschränkt - ein einziger Krampf. Die C PODs existieren weiter, und das Typsystem ist daher genauso lax wie es immer unter C war. Lediglich der Compiler gibt Warnungen aus, wenn man falsche Zeigertypen beim Programmieren mit Klassen verwendet. Typsicherheit ist bei Objective-C für Klassentypen im Gegensatz zu C++ nicht gewährleistet. In C++ mußt man schon einen ziemlichen Unsinn anstellen, damit man Unsinn mit Exemplaren von Klassen machen kann. In Objective-C reicht es aus, beim Compilen nicht auf die Ausgabe zu achten, die Standardeinstellung sind nur Warnungen.

    u_ser-l schrieb:

    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.

    Die Smalltalk Systanx hat sich definitiv nicht durchgesetzt. Der Weg Methoden via objekt.methodename() aufzurufen ist eindeutig populärer. Und Smalltalk kann so vieles nicht, was zur OOP gehört.



  • u_ser-l schrieb:

    doch, nur nicht auf jedem beliebigen host,

    "Selbsthostingfähig" hat eine feste definierte Bedeutung. Deine Auffassung spielt da überhaupt keine Rolle.



  • u_ser-l schrieb:

    daß es so schwer ist, gute Argumente gegen Smalltalk zu finden,

    Argumente gegen Smalltalk

    • Es ist nicht typsicher. (Der Typ des Objekts und die Typen der Parameter spielen beim Dispatching keinerlei Rolle!)
    • Es gibt keine Module
    • Alle Member einer Klasse sind private
    • Alle Methoden sind public
    • Keine generischen Typen
    • Alle Methoden sind dynamic dispatched
    • Kein multiple dispatch
    • Keine Mehrfachvererbung bzw. Interfaces


  • ~john schrieb:

    "Selbsthostingfähig" hat eine feste definierte Bedeutung. Deine Auffassung spielt da überhaupt keine Rolle.

    Meinst Du die da?
    http://en.wikipedia.org/wiki/Self-hosting



  • ~john schrieb:

    "Selbsthostingfähig" hat eine feste definierte Bedeutung. Deine Auffassung spielt da überhaupt keine Rolle

    Das kannst du gar nicht beurteilen. Du bestreitest ja, daß Smalltalk selbsthostingfähig ist.

    Daß du es wagst, mir Unkenntnis zu attributieren, obwohl dir schon die Bedeutung des grundlegenden Begriffs "Selbsthostingfähigkeit" in Bezug auf Smalltalk nicht bekannt ist, ist schon ein starkes Stück.
    (obwohl mir deine Meinung über meine Kompetenz natürlich 10 m am Arm vorbeigeht)



  • ~john schrieb:

    Argumente gegen Smalltalk

    • Es ist nicht typsicher. (Der Typ des Objekts und die Typen der Parameter spielen beim Dispatching keinerlei Rolle!)
    • Es gibt keine Module
    • Alle Member einer Klasse sind private
    • Alle Methoden sind public
    • Keine generischen Typen
    • Alle Methoden sind dynamic dispatched
    • Kein multiple dispatch
    • Keine Mehrfachvererbung bzw. Interfaces

    Erzähl's deinem Compiler 😃



  • u_ser-l schrieb:

    Ich jedenfalls kann noch sehr lange freundlich bleiben, weil ich genug Argumente vorbringen kann, die meine Punkte stützen.

    Nein, Du warst spätestens jetzt betont unfreundlich.



  • JustAnotherNoob schrieb:

    ch quatsch, so'n try{...}finally{...} siehste vielleicht alle 20000 zeilen. so häufig und wichtig ist es garnicht, wie ihr c++ fans vielleicht glaubt.

    das hat dich bei volatile int* auch nicht gestört... und da waren es eher nochmal zwei nullen mehr, oder noch mehr.

    zugegeben, beides kommt nicht oft vor. aber während das mit dem 'volatile int*' ein astreiner bug ist, ist diese try/finally-geschichte ein entsprechender Java-ersatz für eure 'out of scope'-geschweifte klammer. übrigens ist RAII, dieses kurzzeitige schnappen und freigeben von ressourcen in schneller folge, nur in sonderfällen eine befriedigende lösung (z.b. manuelle speicherverwaltung in ermangelung eines GC oder get/release von locking-objekten, wenn man multithreading machen will). ihr solltet es mal nicht so überbewerten.
    🙂



  • oder get/release von locking-objekten, wenn man multithreading machen will

    Locking-Objekte sind ja wohl manuelles Resourcemanagement in Reinkultur, da kannst du auch gleich alle Resourcen manuell verwalten, wenn du das gut findest.
    Ein besseres Konzept wäre eine funktionale Lösung, ich frag mich ob du davon was weißt(ob du generell nicht über den Tellerrand schaust, oder nur in Hinsicht auf C++ zu ignorant bist). Ich finde zum Beispiel auch das Actorsmodell aus Erlang und Scala recht nett.

    ist diese try/finally-geschichte ein entsprechender Java-ersatz für eure 'out of scope'-geschweifte klammer.

    nicht wirklich. Die Klammer kommt sowieso.



  • volkard schrieb:

    ~john schrieb:

    "Selbsthostingfähig" hat eine feste definierte Bedeutung. Deine Auffassung spielt da überhaupt keine Rolle.

    Meinst Du die da?
    http://en.wikipedia.org/wiki/Self-hosting

    Nein, da wird self-compiling mit self-hosting verwechselt. Es gehört zum self-hosting die komplette Sprache inklusive Laufzeitumgebung, Standardbibliothek und nicht nur der Compiler. Beim self-compiling reicht es aus, wenn der Compiler sich selbst übersetzen kann, das trifft auf Smalltalk und Java zu, aber deren VMs sind nicht mit den jeweiligen Sprachen übersetzbar.



  • gibst nicht auf, was?

    Die Smalltalk-VM ist in Smalltalk formulierbar und kann auf einem Smalltalk-System laufen. Punkt.

    Um die unerfreuliche Diskussion zu beenden und weil du scheinbar meine Quellenangaben ignorierst, ein Zitat aus "Back to the Future: The Story of Squeak, A Practical Smalltalk Written in Itself" von Ingalls, Kaehler, Maloney, Wallace, Kay:

    Based on that experience, we determined to write and debug the virtual machine in Smalltalk.
    


  • JustAnotherNoob schrieb:

    ...ob du generell nicht über den Tellerrand schaust, oder nur in Hinsicht auf C++ zu ignorant bist).

    hätt ich nie übern tellerrant geschaut, wäre mir c++ garnicht aufgefallen. ich hab c++ schon vor jahren für mich persönlich abgehakt. und was ich danach alles bezüglich c++ mitbekommen habe, hat meine entscheidung mehr als bestätigt.

    JustAnotherNoob schrieb:

    Ich finde zum Beispiel auch das Actorsmodell aus Erlang und Scala recht nett.

    scala finde ich sehr beachtenswert. ich hab's mir letztens angeschaut, war sehr beeindruckt und werde mich auch weiter damit beschäftigen (bis zu den actors bin ich aber noch nicht vorgedrungen). prozedurales, oo, funktionales und generisches programmieren in eine einheitliche, durchgängig logische und leicht verständliche syntax zu packen, wurde in keiner, mir bekannten programmiersprache, so perfekt realisiert wie in scala. zudem noch die gute anbindung an Java (in beide richtungen) macht Scala zu 'ner runden sache, in der 'ne menge potential steckt.
    btw, falls du eine gute IDE für scala suchst: ich benutze intelliJ-idea und dessen scala-plugin. das geht ziemlich gut.

    JustAnotherNoob schrieb:

    ist diese try/finally-geschichte ein entsprechender Java-ersatz für eure 'out of scope'-geschweifte klammer.

    nicht wirklich. Die Klammer kommt sowieso.

    das ist aber doofes prinzip, weil man nicht auf anhieb sieht, was bei der '}' so alles passieren kann. gerade bei low-level und maschinennaher programmierung ist sowas absolut nervig.
    🙂



  • .fricky schrieb:

    hätt ich nie übern tellerrant geschaut, wäre mir c++ garnicht aufgefallen. ich hab c++ schon vor jahren für mich persönlich abgehakt. und was ich danach alles bezüglich c++ mitbekommen habe, hat meine entscheidung mehr als bestätigt.

    Java ist die beste Sprache von der Welt!


Anmelden zum Antworten