Welche Sprache kann C++ Konkurrenz machen?

[*john 0]

@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:

Glade ist aber tot.

Danke für den Link, denn da wird auch gleich auf den Nachfolger von Glade verwiesen Cambalache. Wesentlich ist, dass es auch weiterhin die Möglichkeit gibt über GtkBuilder UIs aus Dateien zu laden – so sollte das sein. UIs von Hand zusammen zu bauen ist so 1980er, das muss nicht sein.

[Tyrdal]

@john-0 sagte in Welche Sprache kann C++ Konkurrenz machen?:

Die BEGIN END Blöcke sind eine Besonderheit von Pascal. Faktisch alle anderen Algol-artigen Programmiersprachen nutzen nur noch die Form:

if () then
    Anweisungsblock;
else if ()
    Anweisungsblock;
else
    Anweisungsblock;
end;

Lesbarkeit von Programmcode wird von vielen leider unterschätzt. Einige der Neuerungen an C++ seit C++2011 lassen daran zweifeln, dass man das versteht.

Ich mag Klammern lieber, weil die einfacher zu editieren sind. Ich nutze schon seit Ewigkeiten Vim bzw. Vim-Emulation in IDEs. Und da ist es schon praktisch zwischen den Klammer switchen zu können oder einfach mal mit di( den Inhalt löschen zu können. Das ging mit diesen wortbasierten Begrenzern früher nicht. Schlechter lesbar finde ich die eigentlich auch nicht.

[cyborg_beta]

Ich präferiere explizit geklammerte Kontrollstrukturen (auch Einzeiler). Könnt mich gerne als zu engstirnig ansehen, aber außer ein paar Zeichen weniger, sehe ich keinen Vorteil in Sprachen ohne Klammern.

[*john 0]

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Ich mag Klammern lieber, weil die einfacher zu editieren sind. Ich nutze schon seit Ewigkeiten Vim bzw. Vim-Emulation in IDEs. Und da ist es schon praktisch zwischen den Klammer switchen zu können oder einfach mal mit di( den Inhalt löschen zu können. Das ging mit diesen wortbasierten Begrenzern früher nicht. Schlechter lesbar finde ich die eigentlich auch nicht.

Ich halte die öffnende Klammer für überflüssig, analog das THEN in vielen Sprachen. Denn die Bedingung wird ohnehin geklammert und man weiß, dass darauf die Anweisung folgt/die Anweisungen folgen. Was fehlt ist der Abschluss des Anweisungsblocks. In Python macht man das über die Einrückungstiefe. Mir wäre in C/C++ ein einzelnes Symbol lieber gewesen. Z.B.

if (Bedingung1)
    Anweisungsblock;
else if (Bedingung2)
    Anweisungsblock;
else
    Anweisungsblock;
#

Natürlich ist # in C und C++ nicht frei von Bedeutung, so dass es nicht in Frage kommt.

Und das Worst-Case-Szenario mit Pascal sähe dann so aus.

IF (Bedingung1) THEN
  BEGIN
    Anweisungsblock;
  END
ELSE IF (Bedingung2) THEN
  BEGIN
    Anweisungsblock;
  END
ELSE
  BEGIN
    Anweisungsblock;
  END

[wob]

Hm. Ich habe früher viel mit Pascal/Delphi gemacht - und ich habe immer die Schreibweise mit weniger Zeilen bevorzugt:

if a = b then begin
    block;
end else begin
    block_2;
end;

Ich musste mich beim Umstieg auf C++ vor allem auch an die Klammern um die if-Bedingung gewöhnen und an das ==.

Inzwischen mache ich fast nur noch Python und bin inzwischen (anfangs nicht!) richtig glücklich damit, dass alles über die Einrücktiefe geregelt wird. Der Code sieht so aus wie das, was man ausdrücken will (und black formatiert alles mit bis auf line-length keinen Einstellmöglichkeiten).

Und ja, Python ist langsam. Aber meist macht das nichts. Die Dinge, wo das relevant ist, passieren meist in irgendwelchen Modulen (wie numpy oder pandas), die wichtige Teile in C implementiert haben oder irgendwelche C-Bibliotheken nutzen. Und zur Not gibt es ja z.B. cython.

Lesbarkeit von Programmcode wird von vielen leider unterschätzt. Einige der Neuerungen an C++ seit C++2011 lassen daran zweifeln, dass man das versteht.

Hm... Ich fand Loops im Stil von

for (std::vector<namesp::typ::subtyp>::const_iterator it = vec.begin(); 
    it != vec.end(); ++it)

ziemlich furchtbar und finde range-for eine DEUTLICHE Lesbarkeitsverbesserung. Und auch auto macht sowas so viel einfacher, wenn man bei der expliziten iterator-Loop bleiben will.

Range-Loops, auto und Lambdas waren für mich die Killerfeatures der Lesbarkeit! Und ja, so was kleines wie "wie schreibe ich die Loop" ist mir sehr viel wichtiger als "wie ist die Template-Syntax, darf ich jetzt >> schreiben, wenn ich 2 verschachtelte Template-Typen schließe oder muss da ein Space zwischen (prä-C++11 war das auch noch der Fall).

[Mathuas]

Und was ist so toll an Pascal? Ich fands immer zu verbose, Begin/end stattKlammern ist sehr unpraktisch und dann dass man Variablen in nem eigenem Block deklarieren musst war jetzt auch nicht so toll.

Ich habe schneller "begin" geschrieben, als wen ich die {} mit einem Tastengewurstel suchen muss. Das "end" wird dann meisten selbst geschrieben.
Dafür entfallen bei Pascal die bei C immer notwendigen () bei if und while.
Nicht um sonst sagen Pascal Fans, C sein nur Kommentar weil man dort so viele {} findet.

• (Turbo-) Pascal hatte zu DOS-Zeiten nen ziemlich netten Inline-Assembler, der Exkursionen in die Lowlevel-Programmierung sehr einfach gemacht hat.

Dies geht heute noch.

Wenn es nur um einfache Masken geht, nimmt man Glade und lädt das GUI über GtkBuilder vollkommen unabhängig von der jeweiligen Sprache. Das geht sehr viel schneller als das GUI über Programmcode zu generieren.

Dann hast du vermutlich nie Delphi oder Lazarus in den Fingern. Dort ist alles im gleichen Entwicklungstool.

Lesbarkeit von Programmcode wird von vielen leider unterschätzt. Einige der Neuerungen an C++ seit C++2011 lassen daran zweifeln, dass man das versteht.

Genau da trumpft Pascal wieder. Viele C Sachen sind sehr schwer leserlich, besonders mit den viele #define Makros.
Ausser man programmiert mit C auch leserlich und strukturiert.

Danke für den Link, denn da wird auch gleich auf den Nachfolger von Glade verwiesen Cambalache. Wesentlich ist, dass es auch weiterhin die Möglichkeit gibt über GtkBuilder UIs aus Dateien zu laden – so sollte das sein. UIs von Hand zusammen zu bauen ist so 1980er, das muss nicht sein.

Die XML sieht der lfm von Lazarus sehr ähnlich.

Hm. Ich habe früher viel mit Pascal/Delphi gemacht - und ich habe immer die Schreibweise mit weniger Zeilen bevorzugt:

Dies mache ich auch so, so hat man viel mehr Platz auf dem Bildschirm, die Breite wird eh viel zu wenig ausgenutzt. Viele Coder murksen sich noch mit 80 Zeichen/Zeile ab. Die Zeiten der kleinen Bildschirme ist vorbei.

Hm... Ich fand Loops im Stil von

>for (std::vector<namesp::typ::subtyp>::const_iterator it = vec.begin(); 
>    it != vec.end(); ++it)

Genau sowas ist sehr unleserlich. Auch Typecasting ist in C viele unleserlicher als in Pascal.

[Ein ehemaliger Benutzer]

@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:

Ich habe schneller "begin" geschrieben, als wen ich die {} mit einem Tastengewurstel suchen muss.

Ist ja wohl kaum schuld der sprache, dass du dich zwingst ein kernbehindertes keyboard layout wie deutsch zu benutzen...

[cyborg_beta]

Ja, jedem das seine duck, weg

[Tyrdal]

@john-0 sagte in Welche Sprache kann C++ Konkurrenz machen?:

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Ich mag Klammern lieber, weil die einfacher zu editieren sind. Ich nutze schon seit Ewigkeiten Vim bzw. Vim-Emulation in IDEs. Und da ist es schon praktisch zwischen den Klammer switchen zu können oder einfach mal mit di( den Inhalt löschen zu können. Das ging mit diesen wortbasierten Begrenzern früher nicht. Schlechter lesbar finde ich die eigentlich auch nicht.

Ich halte die öffnende Klammer für überflüssig, analog das THEN in vielen Sprachen. Denn die Bedingung wird ohnehin geklammert und man weiß, dass darauf die Anweisung folgt/die Anweisungen folgen. Was fehlt ist der Abschluss des Anweisungsblocks. In Python macht man das über die Einrückungstiefe. Mir wäre in C/C++ ein einzelnes Symbol lieber gewesen. Z.B.

Das wäre noch schlechter zu editieren. Nein danke.

Und Python mit seiner Einrückungstoefe ist völlig Banane. Da muss ich ja beim Schreiben schon auf die Formatierung achten anstatt das einfach den Formatter machen zu lassen.

[Schlangenmensch]

@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:

for (std::vectornamesp::typ::subtyp::const_iterator it = vec.begin();
it != vec.end(); ++it)

Naja, heute schreibt man halt

for(auto element : vec)
{
}

Oder nutzt ein for_each Konstrukt.

Ich habe Pascal als erste Sprache an der Uni gemacht und bin damit nie sonderlich warm geworden. Insbersondere die Pointer Syntax mit ^integer fand ich immer ziemlich hässlich.

Mir persönlich gefällt es auch besser, erst den Typen zu schreiben und dann den Variablennamen, aber das kann auch gut Gewohnheit sein.

Ausser man programmiert mit C auch leserlich und strukturiert.

Das ist Vorraussetzung für guten Programmcode, egal mit welcher Sprache. Und auch mit Pascal / Delphi kann man sehr unleserlich programmieren. Ich habe da mal versucht meinem Bruder zu helfen, der das im Maschinenbaustudium machen musste. Was der für Stilblüten hatte, kann man sich gar nicht vorstellen.

@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:

Auch Typecasting ist in C viele unleserlicher als in Pascal.

i := Integer (Ch)
vs
i = (int)Ch;
vs
i = static_cast<int>(c);

Zwischen Pascal und C ist das nicht wirklich ein Unterschied und in C++ steht explizit da, was passiert, das ist doch das, was man von lesbarem Code erwartet, oder?

Wenn es um Konkurrenz zu C++ im gleichen Anwendungsgebiet geht, kann ich mir vorstellen, das Rust ein ernstzunehmender Konkurrent ist, mit ich mich schon ewig mehr auseinandersetzen wollte, aber dazu bin ich leider noch nicht groß gekommen.

C++ ist, gerade im Bereich der Metaprogrammierung nicht immer einfach zu verstehen, aber auch da hat sich in den letzten Standards viel getan. Und für die "normale" Anwendungsentwicklung sowieso. Das Problem ist, dass die Leute über die Jahre sich ein Bild von C++ gemacht haben (oder falsch eingetrichtert bekommen haben), welches so nicht mehr stimmt. Aber aus einer Schublade wieder raus zu kommen ist halt nicht so einfach.

Ich habe schon auf C++ Konferenzen Vorträge über die Vorteile von Rust gehört, bei denen der Vortragende eben den Vergleich nicht mit den neueren C++ Features gemacht hat, sondern mit Prä C++11. Dann sieht C++ halt schlecht aus.

[Tyrdal]

@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:

Und was ist so toll an Pascal? Ich fands immer zu verbose, Begin/end stattKlammern ist sehr unpraktisch und dann dass man Variablen in nem eigenem Block deklarieren musst war jetzt auch nicht so toll.

Ich habe schneller "begin" geschrieben, als wen ich die {} mit einem Tastengewurstel suchen muss. Das "end" wird dann meisten selbst geschrieben.

Ernsthaft? 5 Zeichen sind schneller geschrieben als eins? Dann hast du IMHO die falschen Tastatureinstellungen.

Dafür entfallen bei Pascal die bei C immer notwendigen () bei if und while.

Eindeutiger Nachteil.

[wob]

@Schlangenmensch sagte in Welche Sprache kann C++ Konkurrenz machen?:

Zwischen Pascal und C ist das nicht wirklich ein Unterschied und in C++ steht explizit da, was passiert, das ist doch das, was man von lesbarem Code erwartet, oder?

Naja, ich fand es sehr sehr unlogisch, dass man einen Typ einklammert, um zu casten, der Pascal-Style Cast ist doch viel logischer. Es gibt ja auch in C diesen functional-style Cast, sofern es ein einfacher Typ ist (also int(float_var) geht, aber int*(float_ptr) nicht). Außerdem war ich überrascht, dass Type Casts was anderes als reinterpret_cast tun. Ich meine mich zu erinnern, dass man in Pascal nicht integer(real_var) schreiben konnte, um float nach int zu wandeln. Daher war ich sehr verwirrt, was casts in C wirklich tun. Mal scheinen sie zu reinterpreten, mal scheinen sie den Wert irgendwie sinnvoll in einen anderen Typ zu konvertieren. Das ist in C++ schön explizit mit static_cast vs reinterpret_cast.

Überhaupt: versuch mal jemandem zu erklären, wie du den Typ für eine Variable schreiben musst, die eine Funktion mit Parametern zeigt... Es kann doch niemand wirklich behaupten, dass das in C (oder C++) irgendwie gut lesbar wäre?! Nicht umsonst gibt es cdecl.org, den "C gibberish English" Übersetzer.

[wob]

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Dafür entfallen bei Pascal die bei C immer notwendigen () bei if und while.

Eindeutiger Nachteil.

Nö. Das ist Gewohnheitssache von dir. Ich mache viel mit Python und da brauchts diese Klammern auch nicht. Ist schön, wenn die da nicht sind und von der eigentlichen Bedingung ablenken.

[Mathuas]

@Schlangenmensch sagte in Welche Sprache kann C++ Konkurrenz machen?:

Ich habe Pascal als erste Sprache an der Uni gemacht und bin damit nie sonderlich warm geworden. Insbersondere die Pointer Syntax mit ^integer fand ich immer ziemlich hässlich.

Ich finde dies angenehm, in C ist doch mit & Und * das Gleiche. Und wen man sich an die Regel mit T und P hält, ist sofort übersichtlich ob es ein normaler Typ oder ein Zeiger ist.

Ausnahme sind die alten Urtypen wie Integer, String, Real, etc., da fehlt das T.

Aber unter dem Strich würde ich sagen, ist Pascal und C ebenbürtig, und schlussendlich ist es eine Gewohnheitssache, mit was man codet.

C ist einfach bekannter, weil für die mehr Werbung gemacht wird, ob in Schulen, UNIs und PC-Hefte.
Das verbreitete ist nicht immer das Beste, das sieht man auch zwischen Linux und Windoof.

[*john 0]

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Das wäre noch schlechter zu editieren. Nein danke.

Was ist an n dd schwieriger als an di in vim? Die Zahl der Zeilen sollte man ohnehin im überschaubaren Rahmen haben.

Und Python mit seiner Einrückungstoefe ist völlig Banane. Da muss ich ja beim Schreiben schon auf die Formatierung achten anstatt das einfach den Formatter machen zu lassen.

Ich nutze nie einen Formatter bei eigenem Code, da es entscheidend für die Codequalität ist den Code gleich ordentlich zu formatieren.

[Tyrdal]

@wob sagte in Welche Sprache kann C++ Konkurrenz machen?:

@Schlangenmensch sagte in Welche Sprache kann C++ Konkurrenz machen?:

Zwischen Pascal und C ist das nicht wirklich ein Unterschied und in C++ steht explizit da, was passiert, das ist doch das, was man von lesbarem Code erwartet, oder?

Naja, ich fand es sehr sehr unlogisch, dass man einen Typ einklammert, um zu casten, der Pascal-Style Cast ist doch viel logischer. Es gibt ja auch in C diesen functional-style Cast, sofern es ein einfacher Typ ist (also int(float_var) geht, aber int*(float_ptr) nicht). Außerdem war ich überrascht, dass Type Casts was anderes als reinterpret_cast tun. Ich meine mich zu erinnern, dass man in Pascal nicht integer(real_var) schreiben konnte, um float nach int zu wandeln. Daher war ich sehr verwirrt, was casts in C wirklich tun. Mal scheinen sie zu reinterpreten, mal scheinen sie den Wert irgendwie sinnvoll in einen anderen Typ zu konvertieren. Das ist in C++ schön explizit mit static_cast vs reinterpret_cast.

Functional style casts sind doof, weil schwerer zu greppen.

[Tyrdal]

@wob sagte in Welche Sprache kann C++ Konkurrenz machen?:

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Dafür entfallen bei Pascal die bei C immer notwendigen () bei if und while.

Eindeutiger Nachteil.

Nö. Das ist Gewohnheitssache von dir. Ich mache viel mit Python und da brauchts diese Klammern auch nicht. Ist schön, wenn die da nicht sind und von der eigentlichen Bedingung ablenken.

Falsch, ist schlechter editierbar. Das hat nur am Randemit Gewohnheit zu tun.

[Tyrdal]

@john-0 sagte in Welche Sprache kann C++ Konkurrenz machen?:

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Und Python mit seiner Einrückungstoefe ist völlig Banane. Da muss ich ja beim Schreiben schon auf die Formatierung achten anstatt das einfach den Formatter machen zu lassen.

Ich nutze nie einen Formatter bei eigenem Code, da es entscheidend für die Codequalität ist den Code gleich ordentlich zu formatieren.

Ich muss sowieso nach Firmenrichtlinien formatieren. Warum soll ich mir diese Arbeit nicht vom Computer abnehmen lassen? Schlechter wird der Code dadurch nicht. Der Inhalt ändert sich ja nicht.

[wob]

@Tyrdal sagte

Functional style casts sind doof, weil schwerer zu greppen.

Hm. Ich finde, dass Lesbarkeit vor "Grepbarkeit" geht. In welchem Fall hat man denn in Pascal nicht \bInteger\(, wenn es um einen cast nach Integer geht? (gut, im Beispiel oben hatte jemand noch ein Space drin, aber das macht der Formatierer für die Codebasis gleich und somit wäre es kein Problem, dann noch ein Space (oder ein \s*) einzufügen) - insbesondere im Vergleich zu (typ) sehe ich keinen so großen Unterschied. Klar, wenn man C++ static_cast etc. nutzt, ist das deutlich besser (das habe ich aber oben auch schon so geschrieben).

@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:

Falsch, ist schlechter editierbar. Das hat nur am Randemit Gewohnheit zu tun.

Huch, wieso schlechter editierbar? Das finde ich überhaupt nicht. Woran hast du hier gedacht? Keine nervigen Klammern -> schneller geschrieben, einfacher zu lesen.

[Tyrdal]

@wob sagte in Welche Sprache kann C++ Konkurrenz machen?:

Hm. Ich finde, dass Lesbarkeit vor "Grepbarkeit" geht.

Ich finde Grepbarkeit gehört zur Lesbarkeit, denn ich muss oft irgendwo was suchen.

Huch, wieso schlechter editierbar? Das finde ich überhaupt nicht. Woran hast du hier gedacht? Keine nervigen Klammern -> schneller geschrieben, einfacher zu lesen.

Klammern machen Codeteile gut editierbar, weil man halt die Klammern al Begrenzer hat. Da muss man nicht alles von Hand ansteuern sondern kann einfach auf die Klammer springen, ein ci( und dann den Inhalt ändern. Wenn es nur ein Klammernpaar gibt muss ich nichtmal mit dem Cursor da rein. Ohne Klammern ist das doch mehr Aufwand. Genauso kann ich einfach von öffnender zu schließender Klammer springen um an den Anfang oder das Ende zu kommen. Geht ohne schwieriger. Genauso mit markieren, löschen etc. Klar, heutzutage geht vieles auch über einen LSP-Server, aber ist doch besser wenn man den nicht zwingend braucht.