Wieso gibt es keine gute Programmiersprache?

[Ethon]

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt halt einfach nicht die universale Sprache.

[stinkstiefel]

Ethon schrieb:

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt einen sehr deutlichen Unterschied zwischen "nicht möglichst kompliziert" und "künstlich beschnitten". Dass die Java-String-Klasse den +-Operator überlädt, dies den Nutzern für ihre eigenen Klassen aber explizit vorenthalten wird, ist ein typisches Beispiel dieser Philosophie. Selbes gilt auch bei Mehrfachvererbung, die bei Interfaces dann kurioserweise doch wieder erlaubt ist, oder bei integrierten Datentypen, von denen es nur vorzeichenbehaftete gibt.

[Ethon]

String ist halt bei Java eine Mischung aus Builtin und Library.
Ansonsten kann ich sagen, dass ich Operatorenüberladung in Java noch nie vermisst habe, ich überlade auch in C++ keine Operatoren, finde ich richtig unnötig und kann andere Entwickler unnötig verwirren.
Es gibt wenig Fälle, in denen Operatorenüberladung wirklich logisch ist, zb wenn man eine Klasse für komplexe Zahlen oder etwas wie BigInteger entwickelt. Und da fällt mir kein Zacken aus der Krone, a.add(b) statt a + b zu schreiben.
Abgesehen davon sind die Usecases für diese Klassen auch ziemlich selten und eher lokal.
Grundsätzlich finde ich es positiv, wenn keine Operatorenüberladung mit der Mächtigkeit von C++ möglich ist. Dinge wie Boost.Spirit sind für mich nichts außer Spielereien.
Da gefällt mir der Ansatz von D schon besser, dass alle relationalen Vergleichsoperatoren der selben Ordnungsrelation zugrunde liegen, weniger Unfug möglich.

Das mit der Mehrfachvererbung und den Interfaces ist für mich absolut logisch: Mehrere Interfaces produzieren keine Probleme wie zb. das diamond problem.

[Columbo]

Ethon schrieb:

Dinge wie Boost.Spirit sind für mich nichts außer Spielereien.

Einige Arbeiten mit Spirit (und erfolgreich, wie du dir vorstellen kannst). Nur weil du keine application domain kennst, ist es nicht nutzlos oder suboptimal.

Ansonsten kann ich sagen, dass ich Operatorenüberladung in Java noch nie vermisst habe, ich überlade auch in C++ keine Operatoren, finde ich richtig unnötig und kann andere Entwickler unnötig verwirren.

Oh, wow. Dass wir strings mittels == vergleichen können ist ja so verdammt verwirrend. Und diese ganzen + Operatoren für string und chrono::duration , auch so ein Blödsinn! Wer braucht schon Syntax?

Mehrere Interfaces produzieren keine Probleme wie zb. das diamond problem.

Das Diamond Problem ist kein Problem, weil es eine Lösung hat. Und wir können leere Basisklassen als Interfaces einsetzen, kein Problem.

[SideWinder]

Operatorenüberladung geht mir nur dann ab, wenn ich mathematisch anspruchsvollere Dinge baue - etwas was mir im Java-Bereich wahrscheinlich einfach nicht häufig passiert -> wiederum, richtige Sprache für den richtigen Einsatzzweck.

Das Diamond-Problem hat zwar eine Lösung, die ist aber auf Sprachlevel schwieriger umzusetzen weil das Speicherlayout eines Objektes dadurch verkompliziert wird. Das macht es schwieriger eine VM für die Sprache zu schreiben, etc. pp.

MfG SideWinder

[5cript]

Ethon schrieb:

Ich habe genug sehr kompetente Menschen erlebt, die Java sehr zu schätzen wissen, ich sehe nicht im geringsten, warum die Sprache möglichst "kompliziert" sein muss, nur weil der Entwickler kompetent genug ist, die Sprache zu verwenden.

Es gibt halt einfach nicht die universale Sprache.

Was ich ausdrücken wollte: Java ist ein Sprache, bei der man mit wenig regeln und sprachmitteln saubere, leicht testbare Programme schreiben kannst mit schwer zu vermodelnder Struktur.
C++ ist einfach ein großer Haufen Mittel etc und mit C++17 wirds noch umfangreicher und schwerer für Anfänger alles gleichzeitig im Kopf zu haben oder zu kennen.

Ich hoffe in zumindest 2 Unternehmen

ja 2 In dem einen jetzt seit 1.5 Jahren.

Zudem sind 7 Jahre nicht unbedingt viel Empfehlung

In 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?"

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.

[Gast3]

Granted: explicit hätte meinetwegen auch andersrum sein können, aber dann würde es gar keiner benutzen.

soll man auch nicht wenn es default wäre:

so machst du es bisher

class A
{
  // implicit - weil du das unbedingt so brauchst
  A(int a);
}

so sollte man es machen

class A
{
  // explicit weil es so besser ist
  explicit A(int a);
}

so würde es aussehen wenn explicit default wäre

class A
{
  // explicit per default
  A(int a);
}

wenn du doch unbedingt einen konvertierenden ctor brauchst

class A
{
  // implicit - weil du das unbedingt so brauchst
  implicit A(int a);
}

und schon ist das ungewollte konvertieren in den meisten Fällen einfach nicht mehr vorhanden

[hustbaer]

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 es implicit statt explicit gäbe, dann würden es mehr Leute kennen.
Wenn man das implicit Keyword braucht ohne es zu kennen fällt das auf, und man fragt nach.
Umgekehrt nicht, da man im Prinzip explicit überhaupt nicht braucht - trotzdem man es eigentlich bei jedem 2. Konstruktor braucht.

5cript schrieb:

Zudem sind 7 Jahre nicht unbedingt viel Empfehlung

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

[5cript]

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 es implicit statt explicit gäbe, dann würden es mehr Leute kennen.
Wenn man das implicit Keyword braucht ohne es zu kennen fällt das auf, und man fragt nach.
Umgekehrt nicht, da man im Prinzip explicit ü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 Empfehlung

In 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

[turbo autist]

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.

[5cript]

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

[hustbaer]

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.

[5cript]

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.

[hustbaer]

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.

[5cript]

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.

[dachschaden]

5cript schrieb:

Mein code ist alles andere als rumgesaut. Sobald mein code compiliert ist er Fehlerfrei.

Harharhar.

Viel zu lernen du noch hast.

[5cript]

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!

[dachschaden]

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.

https://xkcd.com/1312/

Mit solchen Spielereien befasse ich mich nicht. Und ohnehin ging es hier auch nicht um Haskell, sondern im Kontext von C++.

[hustbaer]

5cript schrieb:

invarianzfreie Programmierung

Nie gehört. Link!

[5cript]

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.

https://xkcd.com/1312/

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.