Warum programmieren einige noch in C?

hustbaer

@Bashar
Vielleicht solltest du mal deinen Standpunkt überdenken bezüglich was sinnvoll zu diskutieren ist und was nicht.
Vielleicht solltest du dich/uns fragen wieso wir bestimmte Dinge als OO bezeichnen und versuchen unseren Standpunkt zu verstehen - statt einfach jeden für blöd zu halten der nicht deiner Meinung ist (mit der du BTW in der Minderheit bist).

Oder auch gerne erklären wieso du es nicht als OO bezeichnen würdest. Also welche Voraussetzungen etwas erfüllen muss um deiner Meinung nach OO zu sein.

Dann könnte man sich überlegen welche Definition/welches Verständnis des Begriffs mehr Sinn macht. Denn letztlich ändert sich nichts an der FILE* API (oder sonst einer API) dadurch wie wir sie bezeichnen -- sie ist davon ja wohl unabhängig. Allerdings ist die Nützlichkeit des Begriffs OO stark abhängig davon wie man OO definiert.

Und letztlich: IMO macht es wenig Sinn auf einer unüblichen Definition eines Begriffs zu beharren, wenn die meisten Leute eine andere Definition verwenden. Selbst wenn die eigenen Definition vielleicht besser ist. Und ganz speziell sinnlos wird es dann, wenn man so wie du auch noch ablehnt darüber zu diskutieren.

Aber du kannst natürlich auch weiterhin jeden für blöd erklären der eine andere Meinung hat als du. Das bringt bloss keinen weiter. Nicht uns, und ganz bestimmt nicht dich.

Bashar

@hustbaer Es ist absolut irre zu behaupten, eine Bibliothek, die in den 70ern für C designt wurde, sei eindeutig mustergültiges OOP. Wieso muss ich das widerlegen? Wer die irren Behauptungen aufstellt, muss Beweise führen.

Wo kommt denn der ganze OOP-Hype der 80er/90er/2000er her? Wieso hat Bjarne Stroustrup C++ entwickelt? Wieso gibt es Objective-C, wieso gibt es Java? Doch wohl kaum, weil OOP mit C damals schon ein alter Hut war. Ihr könnt doch bestenfalls argumentieren, dass OOP, aus einer gewissen Perspektive gesehen, im Prinzip schon in C existiert. Und müsst euch dann auf die Entgegnung, wo denn die Vererbung und Polymorphie bleiben, etwas einfallen lassen, um das zu relativieren.

Aber nein, es muss unbedingt alles eindeutig und absolut mustergültig sein, und jeder zum Idioten erklärt werden, der nicht zustimmt. Weil Wutz in einem Trollthread noch einen draufsetzen musste.

[deine Meinung] mit der du BTW in der Minderheit bist

In diesem Forum vielleicht. Damit kann ich ganz gut leben.

hustbaer

@Bashar sagte in Warum programmieren einige noch in C?:

@hustbaer Es ist absolut irre zu behaupten, eine Bibliothek, die in den 70ern für C designt wurde, sei eindeutig mustergültiges OOP.

Mehrere Probleme mit dieser Aussage.

Nur dass etwas zu einer bestimmten Zeit entworfen wurde, heisst nicht, dass es nicht einem Konzept entsprechen kann das zu einer anderen Zeit formuliert wurde. Würde man irgendwo ein 1 Mio. altes Rad finden, wäre es immer noch ein Rad. Wobei ich nicht weiss wann der Begriff geprägt wurde, aber der Knackpunkt ist ja gerade: es spielt keine Rolle. Weiters sollte wohl klar sein dass die meisten Konzepte der Softwareentwicklung die einen Namen haben, diesen erst bekommen haben nachdem sie bereits angewendet wurden.
Ich habe nie behaupte dass es mustergültiges OOP ist. Das ist ein Strohmann. Ich behaupte weder dass es mustergültiges OOP ist noch dass es nicht mustergültiges OOP is. Nur dass es meiner Meinung nach ganz klar als OOP einzustufen ist.
Niemand hat (hier) behauptet dass die ganze C Standard Library objektorientiert ist, denn das ist sie ganz klar nicht. Es wurde ein konkretes Beispiel genannt, und zwar die FILE* API die ein Teil der Standard Library ist. Wieder ein Strohmann.

Wieso muss ich das widerlegen? Wer die irren Behauptungen aufstellt, muss Beweise führen.

Der wichtigste Punkt der objektorientierten Programmierung ist dass man Daten und den Code der mit diesen Daten arbeitet zusammenfasst. Ein weiterer wichtiger Punkt dabei ist die Kapselung, also dass man diese Daten davor schützt anderweitig modifiziert zu werden. Die Kombination aus Daten und Code ist das Objekt. Die FILE* API erfüllt das. Die FILE* API ermöglicht dir mit FILE Objekten zu arbeiten. Die FILE* API ist objektorientiert.

Done.

Davon abgesehen ist sowohl die Behauptung dass etwas einem Konzept entspricht als auch die Behauptung dass es ganz klar nicht diesem Konzept entspricht etwas womit du dir einen "burden of proof" einhandelst.

Wenn du das vermeiden möchtest, kannst du sagen "ich akzeptiere die Behauptung dass X dem Konzept Y entspricht nicht". Damit hast du keinen "burden of proof" (weil du keine eigene Behauptung aufgestellt hast). Zu behaupten dass "X ganz sicher nicht dem Konzept Y entspricht" ist aber ganz etwas anderes.

Wobei es wie schon gesagt IMO sinnvoller wäre erstmal abzuklären wie der Begriff überhaupt verstanden wird bevor man sich darüber streitet wer jetzt Recht hat oder doof ist oder wem was zu beweisen hätte.

Wo kommt denn der ganze OOP-Hype der 80er/90er/2000er her? Wieso hat Bjarne Stroustrup C++ entwickelt? Wieso gibt es Objective-C, wieso gibt es Java? Doch wohl kaum, weil OOP mit C damals schon ein alter Hut war.

Niemand hat behauptet dass C objektorientierte Programmierung besonders einfach macht oder überhaupt irgendwie speziell unterstützt. Bloss dass es damit möglich ist objektorientiert zu programmieren. C++ wurde u.A. entworfen weil damals bereits viel objektorientiert programmiert wurde, und Stroustrup es vermutlich einfacher machen wollte sicher und ohne viel unnötige Wiederholung objektorientiert zu programmieren -- und ohne dabei unnötige Laufzeitkosten zu zahlen (wie z.B. die Erzeugung von Objekten auf dem Heap, der man in C schwer entkommen kann wenn man auch Kapselung haben möchte).

Ihr könnt doch bestenfalls argumentieren, dass OOP, aus einer gewissen Perspektive gesehen, im Prinzip schon in C existiert. Und müsst euch dann auf die Entgegnung, wo denn die Vererbung und Polymorphie bleiben, etwas einfallen lassen, um das zu relativieren.

Nicht wirklich. Guck dir COM an. Das ist OOP mit Vererbung und Polymorphie. Und sogar FILE* ist polymorph. Ob jetzt dadurch dass ein Kernel drunter sitzt der Files, serielle Schnittstellen und andere Geräte hinter einer ebenso polymprohen C API versteckt oder nicht ist dabei auch wurscht. Denn wäre dieser Kernel nicht da könnte man die selbe Polymorphie auch direkt in der Standard Library erreichen.

Davon abgesehen halte ich gerade Vererbung (abgesehen von reiner Interface-Vererbung) für eher problematisch und etwas was mit dem modernen Verständnis von OOP nicht viel zu tun hat.

Aber nein, es muss unbedingt alles eindeutig und absolut mustergültig sein, und jeder zum Idioten erklärt werden, der nicht zustimmt.

Mit dem zum Idioten erklären hast denke ich du angefangen. Ebenso bist du es der damit angefangen hat dogmatisch auf einer Meinung zu beharren und sich gleichzeitig zu weigern das Thema überhaupt zu diskutieren. Oder auch nur zu erklären wie seine Meinung überhaupt genau aussieht.

[deine Meinung] mit der du BTW in der Minderheit bist

In diesem Forum vielleicht. Damit kann ich ganz gut leben.

Ich kann mich nicht erinnern in letzter Zeit irgendwo etwas zum Thema OO(P) gelesen zu haben wo APIs wie FILE* als "nicht objektorientiert" bezeichnet wurden.

SeppJ

Ich habe "mustergültig" gesagt und stehe dazu. Wenn man die objektorientierten Teile der C-Standardbibliothek als Vorbild (Muster) für eigenen Code nimmt, dann ist das eine gute Orientierung wie man objektorientiert in C programmiert.

PS: Vererbung in C geht übrigens so:

struct DerivedFile
{
  FILE base;
  // was immer man für andere Member braucht.
};

Denn dann ist ein DerivedFile* auch ein gültiger FILE*. Es ist auch kein Zufall, dass C++ das intern ziemlich genau so handhabt.

Aber es gilt natürlich das, was hustbaer über Vererbung gesagt hat, dass die Überbenutzung von Vererbung sich in den letzten 50 Jahren sowieso als suspekt herausgestellt hat.

*john 0

@hustbaer sagte in Warum programmieren einige noch in C?:

@Bashar Ich kenne sie nicht vollständig, aber ich kann lesen was du hier geschrieben hast.

Die FILE* API in der C Standard Library ist ziemlich eindeutig objektorientiert. Wenn du meinst dass das Quatsch ist, dann meine ich halt dass deine Meinung dazu Quatsch ist.

„Objektorientiert“ halte ich für diese API für eine übertrieben Bezeichnung, es gibt nur einen Datentyp und dazu passende Funktionen. Wenn man an eine alte OOP API nennen will, dann schon einer Xt.

SeppJ

@john-0 sagte in Warum programmieren einige noch in C?:

@hustbaer sagte in Warum programmieren einige noch in C?:

@Bashar Ich kenne sie nicht vollständig, aber ich kann lesen was du hier geschrieben hast.

Die FILE* API in der C Standard Library ist ziemlich eindeutig objektorientiert. Wenn du meinst dass das Quatsch ist, dann meine ich halt dass deine Meinung dazu Quatsch ist.

„Objektorientiert“ halte ich für diese API für eine übertrieben Bezeichnung, es gibt nur einen Datentyp und dazu passende Funktionen. Wenn man an eine alte OOP API nennen will, dann schon einer Xt.

Was würdest du denn als wesentliche Eigenschaft von OOP sehen, das von FILE nicht erfüllt wird? Du sagst als einziges, dass es 'alt' wäre, aber das kann's ja wohl kaum sein.

hustbaer

@SeppJ sagte in Warum programmieren einige noch in C?:

Ich habe "mustergültig" gesagt und stehe dazu.

@Bashar Oops, sorry, mein Fehler in diesem Punkt.

hustbaer

@SeppJ sagte in Warum programmieren einige noch in C?:

Was würdest du denn als wesentliche Eigenschaft von OOP sehen, das von FILE nicht erfüllt wird?

Genau diese Frage möchte ich an dich @Bashar weiterleiten. Nachdem ich jetzt kurz beschrieben habe warum ich die API als objektorientiert bezeichne, würde mich jetzt interessieren warum du meinst dass sie ganz klar nicht objektorientiert ist. Was wie ich schon geschrieben habe ebenso eine Behauptung ist, die man ebenso begründen muss.

It0101

@Bashar sagte in Warum programmieren einige noch in C?:

Schade, ich hatte viel von dir gehalten.

Ich halte von euch allen viel und zwar schon recht lange ( #cpp-wise). ( @hustbaer, @SeppJ , @Bashar ). Für mich ist das gerade als würden Mama und Papa sich streiten.

Und das auch noch in einem C-Unterforum ... ich bin entsetzt.

@SeppJ sagte in Warum programmieren einige noch in C?:

in denen es vor allem um "saubere" Programmierung geht. Code, den auch andere Leute verstehen und wiederbenutzen können. Wenn dir heute jemand eine ausgefallene Vererbungshierarchie schreibt, für die man Graphviz zur Visualisierung braucht, der kommt damit durch kein Review.

Genau so was ist mir in PHP passiert. Ich sollte ein Projekt erweitern und musste mich 3 Monate durch den übelsten Klassensalat wurschteln, man war ich angepisst. Da habe ich OOP so richtig hassen gelernt. Am Ende hätte man das echt einfach in 3 Dateien und ein paar Funktionen so schön abbilden können, aber Nein da war wohl jemand der Meinung wirklich alles muss ein Objekt sein und hat noch gleich drei Entwurfsmuster drumherum gepackt.

Wenn mir dann heute jemand erzählen will mit OOP wird irgendwas einfacher für andere Entwickler, dann wird mir dabei schlecht. Gibt bestimmt auch ganz tolle OOP Ideen, wo nicht jeder Scheiß generalisiert und auf Erweiterbarkeit getrimmt wird, aber die anderen Beispiele sind leider die, die mir in der Praxis begegnet sind.

hustbaer

@It0101 Ach wir streiten uns doch gerade mal so ein bisschen. Ich glaube dass @Bashar irgendwas hier ziemlich aufgeregt hat und er das morgen/in ein paar Tagen viel entspannter sehen wird.

5cript

@hustbaer
Doch habe ich. Und ich stehe zu meiner Aussage.
Vielleicht habe ich noch keine schrecklichen gesehen.
Das ist auch analog zu libraries. C Libraries zu verwenden ist meiner Ansicht 100 mal einfacher als die durchschnittliche C++ Library. (Es gibt in C++ mehr ausreißer in beide richtungen. Welche die es simpel machen und welche für die man erstmal ein Buch zu lesen muss.)

Ich stimme Linus Torvalds mittlerweile zu, dass es besser war für Linux C zu verwenden und über den C++ Vorschlag zu lachen, auch wenn ich ihn nicht leiden kann.

hustbaer

@Computerwelt
Der allgemeine Konsens ist schon seit > 20 Jahren dass Implementierungs-Vererbung böse ist und eher vermieden werden sollte. Dass du sowas grauenhaft findest kann ich gut nachvollziehen.

Nur hat das IMO nicht sehr viel mit OOP zu tun. Man kann jedes Werkzeug misbrauchen, und mit Vererbung ist das nicht anders. Wenn jetzt jemand glaubt OOP würde irgendeine Empfehlung enthalten alles wo es irgendwie geht über Implementierungs-Vererbung zu machen, dann halte ich es nur für vernünftig dass er OOP ableht. Nur gleichzeitig meine ich auch dass sein Verständnis des Begriffs OOP ... seltsam/unüblich und problematisch ist.

It0101

@hustbaer sagte in Warum programmieren einige noch in C?:

@It0101 Ach wir streiten uns doch gerade mal so ein bisschen. Ich glaube dass @Bashar irgendwas hier ziemlich aufgeregt hat und er das morgen/in ein paar Tagen viel entspannter sehen wird.

Aber ausgerechnet im C-Unterforum.... das ist als würden die Eltern zum Streiten in die verwahrloste Messy-Wohnung nebenan gehen....

hustbaer

@5cript
OK. Ich habe genügend schrecklichen C Code und schrecklichen C++ Code gesehen

Was das Verwenden von C Libraries angeht: das ist oft relativ einfach. Zumindest wenn man sich über bestimmte Dinge keine Gedanken macht. Wie z.B. thread-safety oder wie man das Ding in einem Programm mit dynamisch nachgeladenen Modulen sauber verwenden kann.

Das Verwenden von vielen C++ Libraries ist aber auch ausreichend einfach. Zumindest wenn man gut C++ kann. Und wenn man nicht ganz so gut C++ kann, ist der Vergleich IMO nicht ganz sinnvoll. Denn dann ist das eigentliche Thema dass C++ komplexer und schwieriger zu erlernen ist als C -- und nicht was man damit (und den in der Sprache verfügbaren Libraries) anfangen kann wenn man es erstmal beherrscht.

Mir ging es aber auch eher um Programme die in C entwickelt sind, bzw. bei Libraries nicht um die Verwendung der Library sondern darum wenn man sie modifizieren/erweitern möchte. Und da sehe ich einfach verdammt oft grässliche Dinge. (Was bei Programmen bzw. Libraries die in C++ entwickelt sind nicht unbedingt viel besser ist, aber das ist wieder ein anderes Thema.)

SeppJ

@It0101 sagte in Warum programmieren einige noch in C?:

Aber ausgerechnet im C-Unterforum.... das ist als würden die Eltern zum Streiten in die verwahrloste Messy-Wohnung nebenan gehen....

Wobei der Punkt ja gerade ist, dass man in jeder Sprache guten oder schlechten Code schreiben kann. Gutes C anzusehen ist genauso eine Freude an Klarheit und Logik wie bei jeder anderen Sprache. Nur leider wird in vielen Lehrbüchern eine Art halbgares Fortran60 mit C-Syntax gelehrt. Und viele C++ Bücher verleiten dazu, überkomplexe Sprachmittel rücksichtslos einzusetzen. Ein Jürgen Wolf schreibt eben in jeder Sprache unverständlichen Code.

Ich empfehle das Kapitel in K&R, wo sie die string.h herleiten. Da kann man schön sehen, wie man in C sauber und methodisch entwickelt.

Die string.h ist übrigens auch ein relativ objektorientierter Teil der C-Library. Das Konzept der Nullterminierung ist eine interne Invariante der "Klasse", die innerhalb der Funktionen aufrechterhalten wird und nicht nach außen dringt. Ok, kaum nach außen dringt, denn leider fehlt hier als wesentlicher Teil eine Art Konstruktor, wodurch es dem Anwender überlassen ist, passend großen Platz zu besorgen und dieses Implementierungsdetails zu kennen. Das hätte man besser machen können, ging aber vermutlich durch Anforderungen an Stringliterale nicht.

Bashar

@hustbaer sagte in Warum programmieren einige noch in C?:

@Bashar sagte in Warum programmieren einige noch in C?:

@hustbaer Es ist absolut irre zu behaupten, eine Bibliothek, die in den 70ern für C designt wurde, sei eindeutig mustergültiges OOP.

Mehrere Probleme mit dieser Aussage.

Nur dass etwas zu einer bestimmten Zeit entworfen wurde, heisst nicht, dass es nicht einem Konzept entsprechen kann das zu einer anderen Zeit formuliert wurde. Würde man irgendwo ein 1 Mio. altes Rad finden, wäre es immer noch ein Rad. Wobei ich nicht weiss wann der Begriff geprägt wurde, aber der Knackpunkt ist ja gerade: es spielt keine Rolle. Weiters sollte wohl klar sein dass die meisten Konzepte der Softwareentwicklung die einen Namen haben, diesen erst bekommen haben nachdem sie bereits angewendet wurden.

Das ist eine Meinung, die ich akzeptieren kann. Ich stimme mit ihr nicht überein und finde den Vergleich mit dem Rad nicht ganz passend, aber was solls.

Ich habe nie behaupte dass es mustergültiges OOP ist. Das ist ein Strohmann. Ich behaupte weder dass es mustergültiges OOP ist noch dass es nicht mustergültiges OOP is. Nur dass es meiner Meinung nach ganz klar als OOP einzustufen ist.

Niemand hat (hier) behauptet dass die ganze C Standard Library objektorientiert ist, denn das ist sie ganz klar nicht. Es wurde ein konkretes Beispiel genannt, und zwar die FILE* API die ein Teil der Standard Library ist. Wieder ein Strohmann.

Du nicht, aber SeppJ. Siehe weiter oben. Da du dich in den Thread völlig unsachlich und nur Zusammenhalt mit ihm demonstrierend eingemischt hast, musst du damit klarkommen, dass ich seine Aussage erstmal auch dir zurechne.

Wieso muss ich das widerlegen? Wer die irren Behauptungen aufstellt, muss Beweise führen.

Der wichtigste Punkt der objektorientierten Programmierung ist dass man Daten und den Code der mit diesen Daten arbeitet zusammenfasst. Ein weiterer wichtiger Punkt dabei ist die Kapselung, also dass man diese Daten davor schützt anderweitig modifiziert zu werden. Die Kombination aus Daten und Code ist das Objekt. Die FILE* API erfüllt das. Die FILE* API ermöglicht dir mit FILE Objekten zu arbeiten. Die FILE* API ist objektorientiert.

Done.

Wenn sie echt objektorientiert wäre -- also von jemandem entworfen, der von OOP schonmal was gehört hat --, könnte man z.B. eigene Streamtypen definieren und mit der API verwenden. Dann würde es Stringstreams geben, und später hätte jemand Netzwerkstreams dazupacken können. Man hätte die Verantwortlichkeiten getrennt, IO hier, Buffering da.

Alles was hier von OOP übrig ist, ist die Kapselung. Das hat man vorher schon gekannt, und das ist ja auch für sich schon ein sinnvolles Konzept.

Mir ist hier vor allem eure Motivation unklar. In den 90ern gab es wie gesagt diesen Hype, da musste alles objektorientiert sein, was nicht bei Drei auf den Bäumen war. Aber heute? Was soll das denn?

Datei-IO in Haskell funktioniert auch so, dass man ein undurchsichtiges Handle bekommt und da irgendwelche Funktionen drauf anwendet, ist das jetzt auch ein mustergültiges Beispiel für Objektorientierung? Was muss man denn tun, um nicht objektorientiert zu sein?

Davon abgesehen ist sowohl die Behauptung dass etwas einem Konzept entspricht als auch die Behauptung dass es ganz klar nicht diesem Konzept entspricht etwas womit du dir einen "burden of proof" einhandelst.

Ich betreibe hier keine formale Debatte, und ich bin auch nicht daran interessiert, zu gewinnen. Was soll das sein, krieg ich dann ein paar Reputationspunkte oder mehr Follower? Mir egal, dafür nehme ich mir das Recht heraus, Diskussionen zu verweigern, die ich für blödsinnig halte. Ich mach das hier nur, weil ich von dir recht viel halte und herausfinden möchte, ob wir echt fundamental unterschiedliche Meinungen haben oder ob es nur so scheint.

Wo kommt denn der ganze OOP-Hype der 80er/90er/2000er her? Wieso hat Bjarne Stroustrup C++ entwickelt? Wieso gibt es Objective-C, wieso gibt es Java? Doch wohl kaum, weil OOP mit C damals schon ein alter Hut war.

Niemand hat behauptet dass C objektorientierte Programmierung besonders einfach macht

Ähm, doch? Hast du den Thread überhaupt gelesen?

Ihr könnt doch bestenfalls argumentieren, dass OOP, aus einer gewissen Perspektive gesehen, im Prinzip schon in C existiert. Und müsst euch dann auf die Entgegnung, wo denn die Vererbung und Polymorphie bleiben, etwas einfallen lassen, um das zu relativieren.

Nicht wirklich. Guck dir COM an. Das ist OOP mit Vererbung und Polymorphie.

COM ist vor allem eine Krankheit.

Wenn du den Thread gelesen hättest, hättest du auch das gelesen:

ich:

OOP kann man irgendwie hinhacken, siehe GTK und endlose Diskussionen hier, und ob das "sehr gut" ist, ist am Ende ja offenbar Geschmackssache.

Ich hab ja nicht gesagt, dass es nicht geht. Notfalls benutzt man Cfront

jetzt wieder du:

Und sogar FILE* ist polymorph. Ob jetzt dadurch dass ein Kernel drunter sitzt der Files, serielle Schnittstellen und andere Geräte hinter einer ebenso polymprohen C API versteckt oder nicht ist dabei auch wurscht. Denn wäre dieser Kernel nicht da könnte man die selbe Polymorphie auch direkt in der Standard Library erreichen.

Das meine ich mit "relativieren". Man biegt sich alles irgendwie zurecht.

Davon abgesehen halte ich gerade Vererbung (abgesehen von reiner Interface-Vererbung) für eher problematisch und etwas was mit dem modernen Verständnis von OOP nicht viel zu tun hat.

Das ist nicht das Thema. Ich selbst stehe ja OOP an sich kritisch gegenüber. Hier gehts um was OOP ist, nicht darum, was gut ist.

Mit dem zum Idioten erklären hast denke ich du angefangen. Ebenso bist du es der damit angefangen hat dogmatisch auf einer Meinung zu beharren und sich gleichzeitig zu weigern das Thema überhaupt zu diskutieren. Oder auch nur zu erklären wie seine Meinung überhaupt genau aussieht.

Das hat sich wohl so hochgeschaukelt.

hustbaer

@Bashar sagte in Warum programmieren einige noch in C?:

Ich habe nie behaupte dass es mustergültiges OOP ist. Das ist ein Strohmann. Ich behaupte weder dass es mustergültiges OOP ist noch dass es nicht mustergültiges OOP is. Nur dass es meiner Meinung nach ganz klar als OOP einzustufen ist.

Niemand hat (hier) behauptet dass die ganze C Standard Library objektorientiert ist, denn das ist sie ganz klar nicht. Es wurde ein konkretes Beispiel genannt, und zwar die FILE* API die ein Teil der Standard Library ist. Wieder ein Strohmann.

Du nicht, aber SeppJ. Siehe weiter oben. Da du dich in den Thread völlig unsachlich und nur Zusammenhalt mit ihm demonstrierend eingemischt hast, musst du damit klarkommen, dass ich seine Aussage erstmal auch dir zurechne.

Deine Antwort passt auf Punkt 2 aber nicht auf Punkt 3. Egal. z.T. unsachlich: ja, meine Erwiderung auf deinen sehr unsachlichen Beitrag war sehr unsachlich. (Mit voller Absicht übrigens.)

Wenn sie echt objektorientiert wäre -- also von jemandem entworfen, der von OOP schonmal was gehört hat --,

Du vermischt gerade Intention und Ergebnis. Die einer Sache innewohnenden Eigenschaften sind unabhängig davon wie die Sache entstanden ist. Und die ihr bloss zugeordneten/zugesprochenen Eigenschaften (wie z.B. wer eine Sache hergestellt hat oder in welchem Geiste sie hergestellt wurde), sind etwas was mich eher weniger interessiert. Ganz allgemein, und erst recht wenn es um Softwareentwicklung geht.

BTW: Anscheinend gibt es den Begriff "object oriented" schon seit den späten 50er/frühen 60er Jahren. (Weil du vorhin schriebst (sinngemäss) es wäre irre anzunehmen etwas aus den 70ern könne objektorientiert sein...)

könnte man z.B. eigene Streamtypen definieren und mit der API verwenden.

Ähm. Das könnte man dann vielleicht, aber nicht notwendigerweise. Und Gründe etwas nicht polyporph bzw. nicht erweiterbar polymorph zu machen gibt es mMn. viele. KISS, Performance, Implementierungsoverhead und dass es verdammt schwer ist nicht-triviale APIs sauber erweiterbar polymorph zu machen.

Wenn "erweiterbar polyporph" für dich ein absolut notwendiges Kriterium für OOP ist, dann passt das natürlich nicht zu FILE*. Für mein Verständnis von OOP ist es kein notwendiges Kriterium.

Ich betreibe hier keine formale Debatte, und ich bin auch nicht daran interessiert, zu gewinnen. Was soll das sein, krieg ich dann ein paar Reputationspunkte oder mehr Follower?

Das war meine Antwort auf

Wieso muss ich das widerlegen? Wer die irren Behauptungen aufstellt, muss Beweise führen.

Ich wollte darauf hinaus dass die Aussage "wer die (irre) Behauptungen aufstellt, muss Beweise führen" auch genau so für dich gilt, da du ebenso (irre) Behauptungen aufstellt hast.

Niemand hat behauptet dass C objektorientierte Programmierung besonders einfach macht

Ähm, doch? Hast du den Thread überhaupt gelesen?

Ja, doch. Muss mir aber entgangen sein. Wo? Wer?

Das meine ich mit "relativieren". Man biegt sich alles irgendwie zurecht.

Nein, ich biege mir nichts zurecht. Meine Definition des Begriffs OOP erfordert kein zurechtbiegen damit FILE* objektorientiert ist. Die wesentlichen Dinge sind erfüllt, und damit is es für mich objektorientiert.

Ich habe irgendwie den Eindruck dass du siehst OOP als eine Art Religion oder noch schlimmer: Kirche. Für mich ist das einfach nur ein Konzept bzw. eine lose Ansammlung von Konzepten, wovon manche wichtiger sind und manche weniger wichtig.

Wenn du es nicht objektorientiert nennen willst... wie nennst du dann das was heute in sinnvoll und gut entworfenen C, C++ oder C# Programmen gemacht wird wo mit sauber gekapselten Objekten gearbeitet wird, erweiterbare oder geschlossene Polymorphie dort und nur dort eingesetzt wird wo sie Sinn macht etc.?

*john 0

@SeppJ sagte in Warum programmieren einige noch in C?:

Was würdest du denn als wesentliche Eigenschaft von OOP sehen, das von FILE nicht erfüllt wird? Du sagst als einziges, dass es 'alt' wäre, aber das kann's ja wohl kaum sein.

In der Ursprungsversion war das einfach eine Datenstruktur mit opaken Zeiger (f* Funktionen) bzw. Nummer für das entsprechende Handel im Kernel und dazu passenden Funktionen – mehr nicht. Dazu leistet das OOP nicht die C Library sondern der darunter liegende Kernel. Die C Library schreibt bei einem write Daten nur in einen Puffer (der sieht für sie immer gleich aus, d.h. sie hat keinerlei Ahnung um was für ein Device es sich handelt), um den Rest u.a. wie das konkret auf das spezielle Device geschrieben werden muss kümmert sich der Kernel. D.h. alles was OOP ist, spielt sich im Kernel ab nicht in der C Library.

Es gibt keinerlei API Schnittstelle in der C Library wie man das erweitern könnte. Bei Xt existiert das.

Also kann man in C++ auch schön programmieren ohne den Zwang zu unterliegen aus allem gleich ein Objekt machen zu müssen?