Warum programmieren einige noch in C?

[SeppJ]

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

Du bildest dir wohl viel ein auf deine Diskussionskultur?

Das war schon bewusst provokant und unproduktiv. Wie man sieht, kannst du es nicht leiden, wenn andere nicht ernsthaft diskutieren. Dachte ich mir.

[SeppJ]

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

Was ich auch nicht verstehe, warum muss alles immer mit OOP gelöst werden? Muss man denn jeden "scheiß" in eine Klasse packen und mit DesignPattern generalisieren etc.? Bei einer GUI Lib verstehe ich das noch, aber ansonsten. Muss man denn alles gleich kapseln? Ich habe irgendwie kaum C++ Programme gesehen wo einfach mal ohne eine einzigste Klasse was gelöst wird, warum?

Warum muss es also meist OOP sein?

Das was man heute darunter versteht, hat nicht viel mit dem idiomatischen OOP der 1970er zu tun, sondern ist eher eine Ansammlung von best practices, die sich seither darauf aufbauend herausgebildet haben, 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. Sauber getrennte Funktionen mit klarer Aufgabe und Abkapselung, sind hingegen absolut ok. Shitty Code wird nicht gut, indem man class davor schreibt, und ein Design ist nicht nicht-OOP, weil kein class in der Implementierung vorkommt.

[Bashar]

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

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

Du bildest dir wohl viel ein auf deine Diskussionskultur?

Das war schon bewusst provokant und unproduktiv. Wie man sieht, kannst du es nicht leiden, wenn andere nicht ernsthaft diskutieren. Dachte ich mir.

Falsch, ich habe von vornherein eine Diskussion darüber aus inhaltlichen Gründen abgelehnt. Ich mag nicht darüber diskutieren, ob die Erde flach ist.

[hustbaer]

@5cript sagte in Warum programmieren einige noch in C?:

C sieht immer gleich aus und ist immer gleich aufgebaut.
Eine C codebase mit gewaltigen mengen Zeilen benötigt 0 Einarbeitung.

Ich glaub du hast noch nie ein grosses C Projekt gesehen. Oder irgend ein C Projekt. Makros über Makros, haufenweise (projektspezifische) Konventionen die man kennen muss, alles public und daher weiss man nie genau was man angreifen darf und was nicht...
Ja, klar, das ist sicher viel einfacher als ein durchschnittliches C++ Programm.

[hustbaer]

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

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