Wieso gibt es keine gute Programmiersprache?
-
5cript schrieb:
Und wenn ich Leute mit Java-philosophie "entfernen oder ändern wir das, weil man dann weniger falsch machen kann" an C++ rangehen, dann reagiere ich außerordentlich allergisch.
Granted: explicit hätte meinetwegen auch andersrum sein können, aber dann würde es gar keiner benutzen.
Falsch.
Wenn esimplicitstattexplicitgäbe, dann würden es mehr Leute kennen.
Wenn man dasimplicitKeyword braucht ohne es zu kennen fällt das auf, und man fragt nach.
Umgekehrt nicht, da man im Prinzipexplicitüberhaupt nicht braucht - trotzdem man es eigentlich bei jedem 2. Konstruktor braucht.5cript schrieb:
Zudem sind 7 Jahre nicht unbedingt viel EmpfehlungIn meinem Alter schon.
Ich will sowas auch gar nicht erwähnen, aber ich fühlte mich ziemlich angegriffen nach dem Motto: "Was weißt du denn schon?"Das liegt z.T. schon auch daran was du schreibst.
-
hustbaer schrieb:
5cript schrieb:
Und wenn ich Leute mit Java-philosophie "entfernen oder ändern wir das, weil man dann weniger falsch machen kann" an C++ rangehen, dann reagiere ich außerordentlich allergisch.
Granted: explicit hätte meinetwegen auch andersrum sein können, aber dann würde es gar keiner benutzen.
Falsch.
Wenn esimplicitstattexplicitgäbe, dann würden es mehr Leute kennen.
Wenn man dasimplicitKeyword braucht ohne es zu kennen fällt das auf, und man fragt nach.
Umgekehrt nicht, da man im Prinzipexplicitüberhaupt nicht braucht - trotzdem man es eigentlich bei jedem 2. Konstruktor braucht.Und Implicit würde man nie "wirklich" brauchen. Man könnte immer drauf verzichten. Genauso wie man immer explicit hinschreiben könnte.
Die meisten Anfänger würden dann explizite Konstruktoraufrüfe hinschreiben. Dann hätte Meyers geschrieben "benutzen sie nie implicit". Siehe dazu Effective C++, wo er sagt, verwenden sie fast immer explicit. Das Buch sollte sowieso jeder gelesen haben.
Da auch mit dem Einzug von auto, typen aus code weiter verschwunden sind, schreibe ich auch bei der aggregate initialization den Typ nur hin wenn ich muss (offensichtlich, wenn ich sie als Parameter übergebe), und die verwende ich viel.
Es ist ja nicht so, dass durch implizite Typkonvertierungen plötzlich überall schwachsinns Umwandlungen durchgeführt werden.
Ich bleibe dabei, es ist besser so wie es jetzt ist.EDIT: Ich rege mich manchmal darüber auf, dass Bibliotheken mit explicit um sich schmeißen und ich mich dann "selbst kümmern muss".
hustbaer schrieb:
5cript schrieb:
Zudem sind 7 Jahre nicht unbedingt viel EmpfehlungIn meinem Alter schon.
Ich will sowas auch gar nicht erwähnen, aber ich fühlte mich ziemlich angegriffen nach dem Motto: "Was weißt du denn schon?"Das liegt z.T. schon auch daran was du schreibst.
Hätte mehr ausholen sollen
-
5cript schrieb:
Und Implicit würde man nie "wirklich" brauchen. Man könnte immer drauf verzichten. Genauso wie man immer explicit hinschreiben könnte.
Was ist wohl einfacher und birgt ein geringeres Risiko, in Vergessenheit zu geraten? Fast immer explicit schreiben zu müssen, oder fast nie implicit?
5cript schrieb:
Die meisten Anfänger würden dann explizite Konstruktoraufrüfe hinschreiben.
Dann würden sie es schon mal fast immer korrekt machen, im Gegensatz zu fast nie wie im Moment.
5cript schrieb:
Dann hätte Meyers geschrieben "benutzen sie nie implicit". Siehe dazu Effective C++, wo er sagt, verwenden sie fast immer explicit. Das Buch sollte sowieso jeder gelesen haben.
Wenn du einsiehst, dass man fast immer explicit nutzen soll, wieso findest du es dann verkehrt, wenn der Default fast immer korrekt wäre?
5cript schrieb:
Es ist ja nicht so, dass durch implizite Typkonvertierungen plötzlich überall schwachsinns Umwandlungen durchgeführt werden.
Es ist aber die implizite Typkonvertierung, die diese Art von Fehler überhaupt erst zulässt. Würde C++ nur explizite Konvertierung zulassen, dann bestünde diese Art von Problem gar nicht erst. Die implizite Konvertierung ist es also, die (mit ihrem Komfort) diesen Problemherd nach sich zieht.
-
Weil ich es als komfortabler und hübscher empfinde. Wenn es von Anfang an anders gewesen wäre hätte ich das nie ausgenutzt. Ich hatte noch nie ein Fehler durch fehlendes explicit, bzw wo es verhindert werden hätte können. Naja wie auch immer. Ich gegen die Welt...
-
5cript schrieb:
Es ist ja nicht so, dass durch implizite Typkonvertierungen plötzlich überall schwachsinns Umwandlungen durchgeführt werden.
Doch, wenn man unsinnige implizite Konvertierungen erlaubt, dann ist das schon so. Zumindest wenn man Code schreibt der dann von anderen verwendet wird.
Wenn man dagegen eine kleine, glückliche Insel ist, dann kann man mit viel fragwürdigen Dingen arbeiten ohne dabei besonders viele Fehler zu bauen.
-
hustbaer schrieb:
5cript schrieb:
Es ist ja nicht so, dass durch implizite Typkonvertierungen plötzlich überall schwachsinns Umwandlungen durchgeführt werden.
Doch, wenn man unsinnige implizite Konvertierungen erlaubt, dann ist das schon so. Zumindest wenn man Code schreibt der dann von anderen verwendet wird.
Wenn man dagegen eine kleine, glückliche Insel ist, dann kann man mit viel fragwürdigen Dingen arbeiten ohne dabei besonders viele Fehler zu bauen.
¯\(ツ)/¯
Wenn die Bibliotheks API nicht die "Schwachstelle" ist, "sau" (nach euren Maßstäben) ich darunter rum, wie ich will. Und hinter dieser Wand halte ich mich meistens auf.
'explicit' ist es für mich nicht wert über mehrere Beiträge zu streiten. Dafür gibt es viel wichtigere diskutable Dinge im Bereich der Programmiersprachen.
Außerdem kann ich nicht "gewinnen", wenn man sich gegen allgemein akzeptiertes stellt.
-
Der Knackpunkt ist dass man eben nirgends rumsauen sollte. Können ja, aber es ist kein guter Stil und langfristig auch keine gute Idee. Irgendwann übernimmt deinen Code vielleicht auch mal jmd. anderer oder du bekommst Verstärkung. Und dann wäre gut wenn der sich damit zurechtfindet. Was mit schönem Code meist schon schwer genug ist.
Und das ist ein Punkt der es mMn. wert ist sehr sehr lange diskutiert zu werden.
ps: Das Argument "das ist hier nicht wichtig, hier kann ich ruhig rumsauen" ist mMn. grob falsch und gefährlich. Weil der Mensch ein Gewohnheitstier ist. Wenn man hier rumsaut tut man es meist auch anderswo wo es dann nicht egal ist.
-
hustbaer schrieb:
Der Knackpunkt ist dass man eben nirgends rumsauen sollte. Können ja, aber es ist kein guter Stil und langfristig auch keine gute Idee. Irgendwann übernimmt deinen Code vielleicht auch mal jmd. anderer oder du bekommst Verstärkung. Und dann wäre gut wenn der sich damit zurechtfindet. Was mit schönem Code meist schon schwer genug ist.
Und das ist ein Punkt der es mMn. wert ist sehr sehr lange diskutiert zu werden.
ps: Das Argument "das ist hier nicht wichtig, hier kann ich ruhig rumsauen" ist mMn. grob falsch und gefährlich. Weil der Mensch ein Gewohnheitstier ist. Wenn man hier rumsaut tut man es meist auch anderswo wo es dann nicht egal ist.
Gooooottt, Ich sehe das überhaupt nicht als rumsauen. Mein code ist alles andere als rumgesaut. Sobald mein code compiliert ist er Fehlerfrei. Das ist mein Anspruch. Und ich bin Typ-Agnostiker. keine casts, dazu auto und Aggregat Initialisierung, die selbst rausfindet, was erzeugt werden muss.
Dinge um die ich mich nicht kümmern muss, sind gute Dinge.
Explicit, wenn ich sonst mit meinem Stil Fehler einführen würde.
Das passiert nur dann, wenn ich Besitztum oder Verwaltung für die übergebene Ressource einführe. Jede spezielle Memberfunktions ist gut durchdacht und durchgeplant.explicit?
noexcept?
const?
virtual?
delete?
final?
override?
...Daran muss man denken und das ist gut so.
EDIT: Außerdem durchdokumentiert. Wer dokumentiert denkt NOCHMAL nach.EDIT 2: CASTS HABEN KEINE SEITENEFFEKTE! Falls doch dürfen sie nicht implizit sein.
-
5cript schrieb:
Mein code ist alles andere als rumgesaut. Sobald mein code compiliert ist er Fehlerfrei.
Harharhar.
Viel zu lernen du noch hast.
-
dachschaden schrieb:
5cript schrieb:
Mein code ist alles andere als rumgesaut. Sobald mein code compiliert ist er Fehlerfrei.
Harharhar.
Viel zu lernen du noch hast.
Schonmal Haskell programmiert?
Stateless programming, invarianzfreie Programmierung usw.
Oder Boost Spirit. Sobald die Grammatik kompiliert ist sie nur selten falsch.
Für parallele Programmierung gibt es auch Mittel, sodass einem die Hölle ersparrt bleibt.Viel zu lernen DU noch hast!
-
5cript schrieb:
Schonmal Haskell programmiert?
Nein, ich verwende keine funktionalen Programmiersprachen. Von dem, was ich mitbekommen habe, besitzen diese den namensgebenden Anspruch, alles funktional lösen zu wollen. Ohne Seiteneffekte oder State. Und dann verrenken sie sich, da doch sowas wie State reinzubringen, oben draufgepappt, weil's auf echten Maschinen nun mal nicht anders geht. Über Monads, wo ich bereits einige Leute zu befragt habe und niemals eine einleuchtende Erklärung bekommen habe, warum. Eingabe, Verarbeitung, Ausgabe, es ist so einfach mit dem State, und sie wollen es aber so kompliziert machen.
Mit solchen Spielereien befasse ich mich nicht. Und ohnehin ging es hier auch nicht um Haskell, sondern im Kontext von C++.
-
5cript schrieb:
invarianzfreie Programmierung
Nie gehört. Link!
-
dachschaden schrieb:
5cript schrieb:
Schonmal Haskell programmiert?
Nein, ich verwende keine funktionalen Programmiersprachen. Von dem, was ich mitbekommen habe, besitzen diese den namensgebenden Anspruch, alles funktional lösen zu wollen. Ohne Seiteneffekte oder State. Und dann verrenken sie sich, da doch sowas wie State reinzubringen, oben draufgepappt, weil's auf echten Maschinen nun mal nicht anders geht. Eingabe, Verarbeitung, Ausgabe.
Mit solchen Spielereien befasse ich mich nicht. Und ohnehin ging es hier auch nicht um Haskell, sondern im Kontext von C++.
Diese "Spielereien" haben so wunderbare Konsequenzen, die einem bewusst sein sollten. Und in C++ kann man sehr wohl auch diese Prinzipien anwenden und davon profitieren. C++ kann alles sein. Wer C++ auf objektorientierung, generisches und prozedurales beschränkt, kann auch nicht von den Einflüssen profitieren aus anderen Gebieten.
-
hustbaer schrieb:
5cript schrieb:
invarianzfreie Programmierung
Nie gehört. Link!
Ich meinte "keine Invarianten". Invarianten oder "stille Gegebenheiten" salopp ausgedrückt sind Fehlerquellen, die Kapselung benötigen. Zum Beispiel, wenn man ein Counter mitführt für die Anzahl Elemente eine Liste.
Wenn man sowas vermeiden kann, kann man auch keine Kapselungsfehler machen oder Sachen vergessen.EDIT: OOP ist Modellierung mit State. Der Versuch state zu bändigen. Aber das kann man auch anders lösen.
-
5cript schrieb:
Diese "Spielereien" haben so wunderbare Konsequenzen, die einem bewusst sein sollten.
Tolle Konsequenzen, die die Maschine darunter so weit weg abstrahieren wollen. Und dann geben sie doch klein bei beim State.
5cript schrieb:
Und in C++ kann man sehr wohl auch diese Prinzipien anwenden und davon profitieren. C++ kann alles sein.
Stimmt. Sollte aber nicht.
Das ist ja auch mein Hauptkritikpunkt an C++. Dass mir Leute sagen, dass ich Sachen dann doch lieber in C++ machen soll. Und dann mach ich Sachen in C++, und die Leute sagen mir, dass man das so nicht macht. Sie verkaufen es mir als Erweiterung, aber inzwischen ist es eine eigene Sprache mit Mitteln, die mir so überhaupt nicht gefallen will mit ihren Paradigmen, die von jedem erwartet werden.
Ich fange nicht an, C-Code in C++ runterzuschlunzen. Da spare ich mir und meinen Mitmenschen die Nerven. Und ich fange auch nicht an, stateless-Paradigmen in objektorientierte Programmiersprachen reinzubringen. Das ist wie wenn ich eine Fliege mit einem Topf erschlage - kann man machen, aber dann schaut jeder einen an wie einen Geistesgestörten.
-
Das ist warum ich C++ liebe.
Jedes Problem benötigt sein eigenes Werkzeug.
Und das Werkzeug, dass ich nicht verbiegen muss um etwas zu realisieren bietet meistens die einfachste, lesbarste Lösung, die am wenigsten Fehlerpotential hat, weil man es vollständig überblicken kann, oder die Mittel einem die Arbeit vollständig abnehmen.
**
Deswegen C++. Weil man nicht versucht wie ein "geistesgestörter" (zitat) versucht quadrate in dreieckige Formen zu quetschen, weil man zb nur OOP hat, oder nur Funktionale Programmierung. usw usw.**
-
5cript schrieb:
Deswegen C++. Weil man nicht versucht wie ein "geistesgestörter" (zitat) versucht quadrate in dreieckige Formen zu quetschen, weil man zb nur OOP hat, oder nur Funktionale Programmierung. usw usw.
Finde ich nicht. Ich finde, C++ gibt dir die Möglichkeit, die dreckigen Details dahinter nicht mehr betrachten zu müssen. Wie bei RAII. Oder bei Exceptions. Ja, ja, wir wissen alle, wie viel Code die beiden sparen - im eigentlichen Anwendungscode. Also das, was du siehst, nicht, was daraus wird.
Wobei, im Fall von RAII stimmt das nicht so ganz. Da siehst du die Nachteile auch im Code. Dass ich, wenn ich nicht will, dass ein Konstrukoraufruf für ein eventuell benutztes Objekt teuer werden, den eigentlichen Initialisierungscode in eine eigene Funktion packen müsste. Aber damit könnte ich noch leben.
Aber Exceptions - nicht falsch verstehen, ich habe auch kein besseres Rezept hier außer alles auf Basis von Fehlercodes zurückgeben. Da muss ich den Heap nicht bemühen. Fehlercodes sind einfach, Exceptions sind komfortabel. Ich hätte gerne was, was beides ist. Gibt es nicht, also verkneife ich mir den Komfort und lasse mir lieber überall da, wo ein Fehlercode zurückgegeben wird, eine Warnung ausgeben, wenn ich nicht darauf prüfe.
Das sind Werkzeuge, mit denen arbeiten Programmierer halt. Aber ich habe lieber Werkzeuge, die mir nicht verheimlichen, was unten drunter passiert. Die versuchen, ihre Sachen so gut wie möglich zu machen, ohne mir unnötigen Komfort zu geben, nur weil ich 'ne faule Socke bin. Sonst landet man irgendwann hier. Da war ich oft. Möchte ich nach Möglichkeit auch vermeiden.
Ich habe lieber eine manuelle, haltbare Plastikfliegenklatsche, die sich leicht reinigen lässt und deren einziger Zweck das Klatschen von Fliegen und anderem Getier ist, als ein Edelstahlungetüm, das ich auch zum Kochen verwenden kann.
-
dachschaden schrieb:
5cript schrieb:
Deswegen C++. Weil man nicht versucht wie ein "geistesgestörter" (zitat) versucht quadrate in dreieckige Formen zu quetschen, weil man zb nur OOP hat, oder nur Funktionale Programmierung. usw usw.
Finde ich nicht. Ich finde, C++ gibt dir die Möglichkeit, die dreckigen Details dahinter nicht mehr betrachten zu müssen.
Ich denke nicht dass sich das beides wiederspricht/ausschließt.
-
5cript schrieb:
Ich denke nicht dass sich das beides wiederspricht/ausschließt.
1. "widersprechen"
2. Ich kann also RAII deaktivieren? Wusst' ich gar nicht.
-
dachschaden schrieb:
5cript schrieb:
Ich denke nicht dass sich das beides wiederspricht/ausschließt.
2. Ich kann also RAII deaktivieren? Wusst' ich gar nicht.
Was hat das damit zu tun?
Please note that object-oriented programming is not a panacea. "OOP" does not simply mean "good" - if there are no inherent hierarchical relationships among the fundamental concepts in your problem then no amount of hierarchy and virtual functions will improve your code
http://www.stroustrup.com/bs_faq.html#oop
Das ist das wovon ich rede.
Das hat doch überhaupt keine Schnittmenge damit, ob ich jetzt RAII benutze oder nicht. Das ist eine völlig andere Ebene. Ein Pattern, keine Paradigma.
