Warum programmieren einige noch in C?

[Bashar]

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

@Bashar Eine Diskussion ist auch nicht nötig. Die Erde ist nicht flach und deine Vorstellung davon was OOP ist, ist Quatsch. Bitte, gern geschehen.

Woher kennst du meine Vorstellung von OOP?

[hustbaer]

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

Aber bei einem Projekt für sich selbst macht das doch überhaupt keinen Sinn

Jain.

Kommt z.B. drauf an wie gross das Ding mal wird. Irgendwann erreichen auch private Projekte manchmal eine Grösse, wo man sich selbst nicht mehr auskennt nach einiger Zeit. Dann ist es gut wenn Dinge halbwegs sauber implementiert und gekapselt sind.

Und davon abgesehen ist es für die meisten Entwickler auch gut wenn sie private Projekte sauber entwickeln, selbst wenn sie klein bleiben. Ganz einfach weil die meisten Entwickler auch an anderen Projekten arbeiten, und es leichter ist dort dann sauber zu arbeiten wenn man sich angewöhnt einfach überall sauber zu arbeiten.

[hustbaer]

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

[Bashar]

Schade, ich hatte viel von dir gehalten.

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

1. 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.
2. 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.
3. 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.

[Ein ehemaliger Benutzer]

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