Warum programmieren einige noch in C?

Bashar

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

@Bashar
Referenzen müssen immer initialisiert sein, noch nicht mal nullptr geht.
Damit scheiden sie ggü. Zeigern für einen Großteil der Anwendungsfälle schon mal aus.

Wieso meinst du, mir das erklären zu müssen?

SeppJ

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

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

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

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Naheliegendes Beispiel: Weite Teile der C Standardbibliothek sind Musterbeispiele für objektorientierte Programmarchitektur.

Was soll man dazu sagen... eine Diskussion ist da wohl zwecklos.

Wieso? Weil du das pauschal ablehnst? Dann spreche ich dir sowohl Ahnung ab, was OO heißt, als auch Diskussionskultur.

Denn ganz klar ist

class File
{
  void open(...);
  int read(...);
};

voll objektorientiert, aber

File* fopen(...);
int *fread(..., File*);

nicht. Völlig unterschiedliche Codingphilosophie. Absolut offensichtlich [/s]

5cript

@It0101
Je mehr der Entwickler sich mit tollen Sprachmitteln verkünstelt, desto weniger steigen andere noch durch.
C sieht immer gleich aus und ist immer gleich aufgebaut.
Eine C codebase mit gewaltigen mengen Zeilen benötigt 0 Einarbeitung.

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?

It0101

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

@It0101
Je mehr der Entwickler sich mit tollen Sprachmitteln verkünstelt, desto weniger steigen andere noch durch.
C sieht immer gleich aus und ist immer gleich aufgebaut.
Eine C codebase mit gewaltigen mengen Zeilen benötigt 0 Einarbeitung.

Nun ich bevorzuge halt sauber abgetrennte Module. Das stelle ich mir bei C schwer vor.
In C++ hat man sein Objekt und kann dafür N Funktionen aufrufen.

In C hat man im schlimmsten Fall 1000 Funktionen und wühlt sich dann durch die Signaturen, welche wohl zudem passt was man vor hat Alle Funktionen sind zugänglich und aufrufbar. Egal ob sie Sinn machen oder nicht. Ich denke mal das ganze steht und fällt mit der Qualität des Intellisense.

Ich war aber nie besonders stark in C, weil ich frühzeitig mit C++ angefangen habe.

It0101

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

Weil man mit OOP die Möglichkeit hat, ein streng abgeschottetes Modul zu entwerfen, was nur genau das tut was es soll. Mehr nicht. Mehr ist auch gar nicht möglich, weil durch die Zugriffssteuerung ( public, protected, private ) gar keine Dummheiten gemacht werden können. Die Fehlerquote ist also sehr gering. Das ist natürlich die Idealvorstellung.

Verzichtet man auf Klassen, hat man einen offenen Raum von Funktionen. 80% davon soll der Nutzer gar nicht selber aufrufen, weil sie Hilfsfunktionen sind. Er kann es aber trotzdem tun, was wiederum zu einer erhöhten Fehlerquote führen kann.

Aber bei einem Projekt für sich selbst macht das doch überhaupt keinen Sinn und falls wirklich User(komischer Begriff, das sind für mich die Benutzer meines Programms und nicht andere Entwickler) mit meinen Funktionen arbeiten wollen, so können sie in die Doku schauen welche Funktion was macht. Wer frickelt denn freiwillig mit Funktionen rum, die gar nicht dem Hauptzweck der Lib in der Doku dienliche sind? Nur dafür diesen ganzen Kapselung Klassen Overhead, den man sich funktional komplett schenken könnte? Muss denn jede kleinste Variable als private gemacht werden und einen Getter und Setter bekommen, das alles noch in die Klassen gepackt, wo dann irgendwelche Copy- Move- und was weiß ich noch für Construktor geschrieben werden, um dann am Ende sowas wie die Fakultät auszurechnen etc.? Das ist doch reinste Verschwendung von Codezeilen.

Ich denke mir immer, so wenig Code wie möglich und alles so einfach halten wie es geht. Wenn ich OOP nicht hundertprozentig für die Funktion meines Programms brauchen, dann weg damit. Mal so ganz pragmatisch gesprochen.

Ich finde es unheimlich anstrengend mich durch Klassen zu wurschteln, um zu kapieren was und wie das Programm arbeitet. Zeigermüll ist auch schlecht, aber da komme irgendwie schneller darauf, was da vor sich geht, gibt auch Ausnahmen.

It0101

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

Ich finde es unheimlich anstrengend mich durch Klassen zu wurschteln, um zu kapieren was und wie das Programm arbeitet. Zeigermüll ist auch schlecht, aber da komme irgendwie schneller darauf, was da vor sich geht, gibt auch Ausnahmen.

Zeiger? nie gehört. Was soll das sein?

Ich finde, dass Klassen eine unglaubliche Erleichterung darstellen, weil sie Probleme kapseln und sauber abgrenzen.

Nicht umsonst gibt es mehr Leute, die C mit Klassen schreiben, als Leute, die C++ ohne Klassen schreiben

It0101

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

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

In dem Fall bist du "Freizeit"-Entwickler. Wenn du beruflich programmierst, kommt früher oder später der Punkt, an dem Kollegen deinen Quellcode verwenden und darauf angewiesen sind, dass er möglichst intuitiv ist, weil sie eben genau keinen Bock haben, in den Innereien deiner Problemlösung rumzuwühlen, sondern sie einfach benutzen wollen.

PS: guter Quellcode dokumentiert sich selber, ist also selbsterklärend. Wenn ich für jedes einzelne Modul ( oder um mal ohne Kapselung zu sprechen: für jede Problemlösung ) eine Doku geschrieben hätte, wäre ich vermutlich inzwischen rund 30 Projekte im Rückstand und mein Chef würde mich entweder feuern oder mir Verstärkung besorgen.

*john 0

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

OOP ist eine Philosophie der Programmarchitektur, keine Eigenschaft einer Sprache. Man kann wunderbar objektorientiert in allen imperativen Sprachen programmieren, …

Da bin ich aber gespannt wie Du das in Wirthschen Pascal machst. Da gibt es nämlich keine generischen Zeiger, sondern immer nur konkrete Zeiger auf Typen. D.h. die Lösen aus C für OOP funktionieren dort nicht.

Bashar

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

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

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

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

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Naheliegendes Beispiel: Weite Teile der C Standardbibliothek sind Musterbeispiele für objektorientierte Programmarchitektur.

Was soll man dazu sagen... eine Diskussion ist da wohl zwecklos.

Wieso? Weil du das pauschal ablehnst?

Genau.

Dann spreche ich dir sowohl Ahnung ab, was OO heißt

Das ist mir, wie gesagt, egal. Wenn du zu dem stehst, was du gerade gesagt hast, dann haben du und ich radikal unterschiedliche Ansichten. Ich find deine lächerlich, du meine. Auf der Basis ist eine Diskussion unmöglich.

Denn ganz klar ist
class File
{
  void open(...);
  int read(...);
};
voll objektorientiert, aber
File* fopen(...);
int *fread(..., File*);
nicht. Völlig unterschiedliche Codingphilosophie. Absolut offensichtlich [/s]

Du bildest dir wohl viel ein auf deine Diskussionskultur?

Bashar

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

Was ich auch nicht verstehe, warum muss alles immer mit OOP gelöst werden?

Muss es doch gar nicht. Die meisten sollten doch mittlerweile aus dem OOP-Dornröschenschlaf aufgewacht sein. Wo es sinnvoll ist, klar, aber OOP zieht heutzutage nicht mehr als Qualitätsmerkmal.

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.