Sollten wir alle uns zurückbesinnen?

Sollten wir uns nicht lieber zurückbesinen? Bringen uns die modernen Programmier-Konzepte wirklich einen Vorteil, oder sind diese im Endeffekt nur elegant formulierte Klugscheisserei? Bringen diese einen produktiven Vorteil oder blähen diese einfach nur den Code auf?

Im Endeffekt reicht C aus, man sollte nur Zeiger möglichst loswerden und dynamische Datentypen ala Listen etc in die Sprache festeinbauen.

Alles was darüber hinaus geht, inklusive OOP-Elementen wie Klassen, ist doch nicht notwendig. So bekommt man jedes Projekt fertig und ich könnte mir vorstellen, dass das eine oder andere aktuelle Großprojekt dadurch einiges an Komplexität verlieren würde, wenn man sich wirklich auf das zurückbesinnt, was man wirklich benötigt.

Und nein, ich ziele nicht auf C++ ab. Und auch nicht auf das jetzige C.
Perfekt wäre eine schlanke und klar formulierte Sprache, die die obigen Voraussetzungen erfüllt.
Ich könnte wetten, dass dadurch besserer Code generiert wird, da "Code der sich selber als Selbstzweck dient" mitsamt seinen unnötigen Abstraktionen entfällt.

Back to the roots, aber nur teilweise.

zB schrieb:

Perfekt wäre eine schlanke und klar formulierte Sprache, die die obigen Voraussetzungen erfüllt.

Gretchenfrage.
Doch es gibt eine Antwort:
Haskell.

Nimm Haskell.

volkard

zB schrieb:

Sollten wir uns nicht lieber zurückbesinen?

Ja.

zB schrieb:

Alles was darüber hinaus geht, inklusive OOP-Elementen wie Klassen, ist doch nicht notwendig.

OOP ist nötig. Wie schon in C mit fpopen/fclose und so weiter gezeigt.
Außerdem muß dieser Ansatz mit RAII und Exceptions komplettiert werden.

Im Übrigen wäre Bescheidenheit eine gute Idee.

volkard schrieb:

zB schrieb:

Alles was darüber hinaus geht, inklusive OOP-Elementen wie Klassen, ist doch nicht notwendig.

OOP ist nötig. Wie schon in C mit fpopen/fclose und so weiter gezeigt.
Außerdem muß dieser Ansatz mit RAII und Exceptions komplettiert werden.

Im Übrigen wäre Bescheidenheit eine gute Idee.

Du hast mich nicht ganz verstanden. Ich will das Prinzip OOP nicht unbedingt verbannen. So wie du es eben erwähnt hast, prorammiert man oop auch ohne explizit Klassen und vererbung zu benötigen. Nein, all das was man sowieso macht, das ist sinnvoll. Aber ich finde man benötigt Klassen & co nicht unbedingt. Denn das verleitet nur dazu, dass man einfach alles in Klassen packt ohne einen Grund, nur um der objektorientierter Vorgabe zu folgen.

Objektorientierung ergibt sich aus dem Kontext und nicht aus der Vorgabe.

Definiere Bescheidenheit bitte ein wenig ausführlicher.

edit: definiere Bescheidenheit ausführlicher, sofern du dich auf etwas anderes beziehst, als das was ich im Eröffnungspost geschrieben habe.

volkard schrieb:

OOP ist nötig. Wie schon in C mit fpopen/fclose und so weiter gezeigt.

Hä?
fpopen gibt es nicht, popen mit fclose ist falsch, fopen und fclose richtig. Meinst du, fclose soll beide schliessen können? Jedenfalls reicht genau eines von den Konzepten Überladung, RAII und OOP aus um das Problem zufriedenstellend zu lösen. RAII ist am besten, danach kommt Überladung. Warum ist OOP nochmals nötig?

cooky451

Zeiger loswerden? Warum haben alle Angst vor Zeigern? Ist das irgendwie ein neuer Trend oder so? oO
Und weiter: Abstraktion hilft. Klassen sind doch auch nur C-Structs mit zusätzen. Dabei hilft RAII aber enorm. Spannender wird es, virtuelle Vererbung und Templatemetaprogrammierung anzugreifen.

volkard

zB schrieb:

edit: definiere Bescheidenheit ausführlicher, sofern du dich auf etwas anderes beziehst, als das was ich im Eröffnungspost geschrieben habe.

Don Knuth greift zu kurz.
OO ist *gut*.
(Siehe MMIX-Ware, das Projekt ruft nicht nur, es brüllt nach OO.)

Abgesehen davon hast Du völlig recht.

DrGreenthumb

Haiku schrieb:

volkard schrieb:

OOP ist nötig. Wie schon in C mit fpopen/fclose und so weiter gezeigt.

Hä?
fpopen gibt es nicht, popen mit fclose ist falsch, fopen und fclose richtig. Meinst du, fclose soll beide schliessen können? Jedenfalls reicht genau eines von den Konzepten Überladung, RAII und OOP aus um das Problem zufriedenstellend zu lösen. RAII ist am besten, danach kommt Überladung. Warum ist OOP nochmals nötig?

popen muss anders close machen als fopen.
RAII löst das Problem nicht, macht den Code in dem Fall nur schöner.

Statische Überladung ok, aber unflexibel. Dynamische Überladung, d.h. die datei bestimmt wie sie geschlossen wird... das nennt man afaik dann OOP.

cooky451 schrieb:

Zeiger loswerden? Warum haben alle Angst vor Zeigern? Ist das irgendwie ein neuer Trend oder so? oO

Ne, aber das sind so Altlasten. C++ hat auch welche. Bei C sind es aber nunmal die Zeiger.

cooky451 schrieb:

Und weiter: Abstraktion hilft. Klassen sind doch auch nur C-Structs mit zusätzen. Dabei hilft RAII aber enorm. Spannender wird es, virtuelle Vererbung und Templatemetaprogrammierung anzugreifen.

Die Sache ist: structs sind dazu da Daten, die zusammengehören zusammenzufassen.
Ob man nun Funktionen auf structs anwendet oder Methoden, die zu einer Klasse gehören ist im Endeffekt das selbe. Nur besteht bei der Klasse die Gefahr, dass man viel zu viel in die Klasse packt, sodass mann nicht mehr Sachen zusammenfasst, die zusammengehören sondern alles was einem dazu einfällt im Sinne einer Mindmap. Klassen verführen dazu zu viel, insbesondere Methoden, reinzustecken. Am Ende hat man eine Klasse, die nichts anderes ist, als eine ein wenig anders formulierte main-Funktion.

Wenn du dich auf einfachere structs beschränkst, dann schreibst du zwangsläufig nur Funktionen für die structs (also Funktionen, die das entsprechende struct als Datentyp annehmen), die auch auf den structs arbeiten. Ich halte es für unwahrscheinlich, dass du eine Funktion definierst, die zwar in struct einfordert, aber nichts damit macht. Ein besseres Beispiel fällt mir momentan nicht ein.

volkard

zB schrieb:

cooky451 schrieb:

Zeiger loswerden? Warum haben alle Angst vor Zeigern? Ist das irgendwie ein neuer Trend oder so? oO

Ne, aber das sind so Altlasten. C++ hat auch welche. Bei C sind es aber nunmal die Zeiger.

cooky451 schrieb:

Und weiter: Abstraktion hilft. Klassen sind doch auch nur C-Structs mit zusätzen. Dabei hilft RAII aber enorm. Spannender wird es, virtuelle Vererbung und Templatemetaprogrammierung anzugreifen.

Die Sache ist: structs sind dazu da Daten, die zusammengehören zusammenzufassen.
Ob man nun Funktionen auf structs anwendet oder Methoden, die zu einer Klasse gehören ist im Endeffekt das selbe. Nur besteht bei der Klasse die Gefahr, dass man viel zu viel in die Klasse packt, sodass mann nicht mehr Sachen zusammenfasst, die zusammengehören sondern alles was einem dazu einfällt im Sinne einer Mindmap. Klassen verführen dazu zu viel, insbesondere Methoden, reinzustecken. Am Ende hat man eine Klasse, die nichts anderes ist, als eine ein wenig anders formulierte main-Funktion.

Wenn du dich auf einfachere structs beschränkst, dann schreibst du zwangsläufig nur Funktionen für die structs (also Funktionen, die das entsprechende struct als Datentyp annehmen), die auch auf den structs arbeiten. Ich halte es für unwahrscheinlich, dass du eine Funktion definierst, die zwar in struct einfordert, aber nichts damit macht. Ein besseres Beispiel fällt mir momentan nicht ein.

Aha, ein ewig-gestriger C-Progger nimmt ein Java-Problem und hat es auf C++ transponiert, ohne eine der beiden Sprachen auch nur ansatzweise verstanden zu haben.

cooky451

zB schrieb:

Ne, aber das sind so Altlasten. C++ hat auch welche. Bei C sind es aber nunmal die Zeiger.

"Das sind so Altlasten" ist kein Argument. Was hast du gegen Zeiger? Ich behaupte einfach mal, dass C ohne Pointer überhaupt nicht funktionieren würde. Als Systemsprache würde es jedenfalls sofort unbrauchbar. Eine Unterscheidung zwischen Zeigern und nicht Zeigern bietet einfach zu viele Vorteile. (Ich schreibe hier bewusst Unterscheidung, man kann eine Sprache natürlich auch frei von nicht-Zeigern machen, die Syntax kürzen und am Ende behaupten man hätte keine Zeiger mehr.)

zB schrieb:

Die Sache ist: structs sind dazu da Daten, die zusammengehören zusammenzufassen.

Aber warum sollte man auf diesen Daten nicht auch gleich operieren können?

zB schrieb:

Ob man nun Funktionen auf structs anwendet oder Methoden, die zu einer Klasse gehören ist im Endeffekt das selbe.

Genau das wollte ich dir ja sagen. Nur dass Klassen Syntaxmäßig einige Vorteile haben. RAII und Operatorüberladungen z.B.

zB schrieb:

Nur besteht bei der Klasse die Gefahr, dass man viel zu viel in die Klasse packt, sodass mann nicht mehr Sachen zusammenfasst, die zusammengehören sondern alles was einem dazu einfällt im Sinne einer Mindmap. Klassen verführen dazu zu viel, insbesondere Methoden, reinzustecken. Am Ende hat man eine Klasse, die nichts anderes ist, als eine ein wenig anders formulierte main-Funktion.

Quatsch. Jemand der das macht hat einfach OOP nicht verstanden, was können denn Klassen dafür.

zB schrieb:

Wenn du dich auf einfachere structs beschränkst, dann schreibst du zwangsläufig nur Funktionen für die structs (also Funktionen, die das entsprechende struct als Datentyp annehmen), die auch auf den structs arbeiten. Ich halte es für unwahrscheinlich, dass du eine Funktion definierst, die zwar in struct einfordert, aber nichts damit macht. Ein besseres Beispiel fällt mir momentan nicht ein.

Du hast zwar Recht mit den Funktionen. Aber wie oben beschrieben bietet die Klassensyntax zu viele Vorteile, als dass man sie für ein paar Idioten aufgeben sollte.

Edit:

volkard schrieb:

Aha, ein ewig-gestriger C-Progger nimmt ein Java-Problem und hat es auf C++ transponiert, ohne eine der beiden Sprachen auch nur ansatzweise verstanden zu haben.

Ich hätte eher auf einen Java-Programmierer getippt, der gerade C gelernt hat und keine namespaces kennt.

dot

Ich schlage vor, wir entwickeln dann einen Precompiler, der uns aus einer etwas einfacheren Syntax dann solche structs und Funktionen generiert, immerhin ist das ja nur Boilerplate Code

Oh, warte mal...

volkard schrieb:

Aha, ein ewig-gestriger C-Progger nimmt ein Java-Problem und hat es auf C++ transponiert, ohne eine der beiden Sprachen auch nur ansatzweise verstanden zu haben.

For the record: Wir schreiben das Jahr 2011, und dieses nähert sich auch allmählich dem Ende zu. Was ich damit sagen will: C++ ist genau so von gestern wie C.

Warum das nur ein Javaproblem sein soll und kein C++ Problem, das musst du mir aber genauer erläutern. Ich würde eher behaupten, dass Java dieses Problem erst von C++ erbt.

dot

zB schrieb:

For the record: Wir schreiben das Jahr 2011, und dieses nähert sich auch allmählich dem Ende zu. Was ich damit sagen will: C++ ist genau so von gestern wie C.

Na dafür hält C++ sich aber doch sehr gut

zB schrieb:

volkard schrieb:

zB schrieb:

Alles was darüber hinaus geht, inklusive OOP-Elementen wie Klassen, ist doch nicht notwendig.

OOP ist nötig. Wie schon in C mit fpopen/fclose und so weiter gezeigt.
Außerdem muß dieser Ansatz mit RAII und Exceptions komplettiert werden.

Im Übrigen wäre Bescheidenheit eine gute Idee.

Du hast mich nicht ganz verstanden. Ich will das Prinzip OOP nicht unbedingt verbannen. So wie du es eben erwähnt hast, prorammiert man oop auch ohne explizit Klassen und vererbung zu benötigen. Nein, all das was man sowieso macht, das ist sinnvoll. Aber ich finde man benötigt Klassen & co nicht unbedingt. Denn das verleitet nur dazu, dass man einfach alles in Klassen packt ohne einen Grund, nur um der objektorientierter Vorgabe zu folgen.

Objektorientierung ergibt sich aus dem Kontext und nicht aus der Vorgabe.

Ähm, die Definition einer Klasse ergibt sich aus den Merkmalen, daß sie Klassenvariablen und Klassenmethoden hat, bzw. bei Objekten Objektvariablen und Methoden.

Die Klasse ist also ein sinnvolles Konstrukt um diese Dinge zusammenzufassen.
Wie willst du in C ein Objekt erzeugen, wenn das Struct, welches z.B. die Variablen bzw. Daten enthält, von den Funktionen völlig losgelöst ist?

Daher sag ich es mal so, auch wenn man in C objekt orientiert programmieren kann, so sind die ganzen Klassenkonstrukte die man in C++ oder Java hat, sehr sinnvoll.

Und auch Zeigerarithemtik finde ich sinnvoll, wenn es auf das letzte Pünktchen Performance ankommt, auch das sollte eine Sprache weiterhin bieten.
Bei Java fehlt das schon, allerdings sehe ich es dort persönlich nicht als so schlimm an, weil ich Java eh nicht für performancekritische Anwendungen einsetzen würde.

zB schrieb:

cooky451 schrieb:

Zeiger loswerden? Warum haben alle Angst vor Zeigern? Ist das irgendwie ein neuer Trend oder so? oO

Ne, aber das sind so Altlasten. C++ hat auch welche. Bei C sind es aber nunmal die Zeiger.

Tolles Argument.
Zeiger sind sicher keine Altlast wenn man sie anzuwenden weiß.

cooky451 schrieb:

Und weiter: Abstraktion hilft. Klassen sind doch auch nur C-Structs mit zusätzen. Dabei hilft RAII aber enorm. Spannender wird es, virtuelle Vererbung und Templatemetaprogrammierung anzugreifen.

Die Sache ist: structs sind dazu da Daten, die zusammengehören zusammenzufassen.
Ob man nun Funktionen auf structs anwendet oder Methoden, die zu einer Klasse gehören ist im Endeffekt das selbe. Nur besteht bei der Klasse die Gefahr, dass man viel zu viel in die Klasse packt, sodass mann nicht mehr Sachen zusammenfasst, die zusammengehören sondern alles was einem dazu einfällt im Sinne einer Mindmap. Klassen verführen dazu zu viel, insbesondere Methoden, reinzustecken. Am Ende hat man eine Klasse, die nichts anderes ist, als eine ein wenig anders formulierte main-Funktion.

Eine Programmiersprache kann dem Programmierer nicht das Denken abnehmen, wenn der Progammierer so einen Mist baut, dann liegt es sicherlich nicht an der Programmiersprache.

314159265358979

C Coder schrieb:

Und auch Zeigerarithemtik finde ich sinnvoll, wenn es auf das letzte Pünktchen Performance ankommt, auch das sollte eine Sprache weiterhin bieten.

Auch wenn ich dir zustimme, dass eine Sprache Zeiger bieten sollte, haben sie dennoch relativ wenig bis gar nicht mit Performance zu tun.

314159265358979 schrieb:

C Coder schrieb:

Und auch Zeigerarithemtik finde ich sinnvoll, wenn es auf das letzte Pünktchen Performance ankommt, auch das sollte eine Sprache weiterhin bieten.

Auch wenn ich dir zustimme, dass eine Sprache Zeiger bieten sollte, haben sie dennoch relativ wenig bis gar nicht mit Performance zu tun.

Dann schau dir mal Java an, welches keine Zeiger bietet.
Änderungen in einem String führen bei Java dazu, daß ein neues Stringobjekt angeleegt wird und die Referenz darauf geändert wird.
Das kopieren des alten Strings mit dem neuen Inhalten zu einem neuen Stringobjekt kostet Zeit.

In C/C++ kannst du auf deinen String mithilfe von Zeigern zugreifen und darin einzelne Zeichen ändern, ohne das du den String kopieren mußt.
Du arbeitest somit auf dem unveränderten Original.
Und das ist performant!