Welche Sprache kann C++ Konkurrenz machen?
-
Java ist nicht per se schlecht, nur weil es u. a. interpretiert ist ... Es ist das bessere C++ ... Aber du scheinst nicht studiert zu haben @Mathuas , folglich werde ich bestimmte Unwissenheiten und Nichtkenntnisse auch nicht vorverurteilen.
-
@cyborg_beta sagte in Welche Sprache kann C++ Konkurrenz machen?:
Java ist nicht per se schlecht, nur weil es u. a. interpretiert ist ... Es ist das bessere C++
Aua, das tut aber weh. Die Sprachen haben nicht ohne Grund unterschiedliche Anwendungsgebiete.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
Pascal hatte doch den Durchbruch und war in den 80ern und frühen 90ern auf DOS Mainstream.
Ich habe mich vll. ungenau ausgedrückt: Pascal hatte seine Höhen, aber hat sich letztendlich nicht durchgesetzt.
Ich muss aber sagen: Wäre ich Lehrer an einer Schule, dann würde ich Lazarus/FPC unterrichten: Einfach weil das ein guter Einstieg wäre, man schnell zu Ergebnissen kommt und ich dadurch mehr Schüler mitnehmen würde.
An einer Uni mit Informatik-Schwerpunkt, hat das aber meiner Ansicht nach nichts zu suchen. Einfach deshalb, weil diese Sprache in der Wirtschaft nicht relevant ist.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.
-
@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:
was aber viel schlimmer ist, Python
Python nutze ich für adminstrative Aufgaben. So habe ich z.B. ein Skript geschrieben welches mir einen Setup Ordner auf einem Server aktualisiert. Mit Batch ist dies kein Spaß. Und gewiss könnte man auch Powershell nutzen, aber ich habe immer die Lust daran verloren als ich an Sicherheitsmaßnahmen hängen geblieben bin.
Davon mal abgesehen ist Python die Programmiersprache für Quick & Dirty Aufgaben. Das Ökosystem ist riesig und zentral verwaltet, die Syntax leicht lesbar und viele Routineaufgaben sind intuitiv (z.B.
for Line in OpenedFile
). Ein Aufrufpip install nordic
und schon bekommt man Programmiertools für Nordic Chips installiert.Vor längerem musste ich z.B. mal Sensordaten glätten. Also Matplotlib installiert, Sensordaten eingelesen, geklättet und dargestellt. Ein Kollege wollte damit mal rumspielen, also gab ich ihm eine kurze Einweisung und gut war.
Quick & Dirty und trotzdem gut lesbar. So erlebe ich Python.
Nervige Macken wie z.B. bei VBA
MsgBox "Alles ok"
zuMsgBox("Alles ok)"
habe ich noch keine entdeckt.
BTW: Man darf natürlich nicht vergessen dass Python im Vergleich zu z.B. C++ sehr langsam ist.
-
@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:
@cyborg_beta sagte in Welche Sprache kann C++ Konkurrenz machen?:
Java ist nicht per se schlecht, nur weil es u. a. interpretiert ist ... Es ist das bessere C++
Aua, das tut aber weh. Die Sprachen haben nicht ohne Grund unterschiedliche Anwendungsgebiete.
Die Anwendungsgebiete haben aber eine nicht leere Schnittmenge.
-
Guten Morgen @Mathuas,
in den Schulen wird nicht primär C gelehrt, sondern eher Scratch, Java oder Python (Rechercheergebnis). Außerdem ist ein Vergleich von C und Pascal so was wie ein Vergleich von Brot oder Braten.
Deiner Meinung bin ich, dass eine Priorisierung einer Programmiersprache in der Schule diese fördern würde.
-
@Tyrdal 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.
Das habe ich doch in deinem Zitat beantwortet. Es geht mir gar nicht um Syntax.
-
Ich persönlich würde als "Lernsprache" eine solche bevorzugen, welche Referenzen als eigenständiges Sprachelement hat und wo nicht fast alles irgendwie eine Referenz ist (oder auch alles ein konkreter Wert). Einfach, weil ich die Unterscheidung von direkten und indirekten Variablen als wichtig für das Verständnis grundlegender Datenstrukturen wie verkettete Listen, Bäume, allgemeine Graphen und viele andere halte.
Gleichzeitig sollte die Sprache nicht zu viele Fallstricke haben, wie manuelle Speicherverwaltung, Zeigerarithmetik und andere Sachen, mit denen man sich leicht in den Fuss schiessen kann. Auch das Ausschreiben von Struktur-Schlüsselwörtern (
begin
/end
) ist zumindest für Programmieranfänger erstmal vielleicht nicht so vekehrt.Insofern halte ich Pascal für eine gar nicht mal so schlechte Sprache für die Schule. Die wurde ja immerhin von Wirth auch als "Lehrsprache" entwickelt. Allerdings wurde Pascal bereits schon zu meiner Schulzeit in den 90ern eingesetzt, daher assoziiere ich die Sprache mittlerweile auch eher mit "altbacken" und "unsexy". Aber möglicherweise zu unrecht.
Ich bin jedenfalls nicht überzeugt, ob man z.B. mit Python ein ausreichendes Lowlevel-Verständnis erreichen kann, wie die Maschine letzendlich das abarbeitet, was man da programmiert. Das ist aber nur ein Bauchgefühl, da mein Lernpfad eher grob Pascal->Assembler*->C->C++ war (mit Abzweigungen in die meisten anderen gängigen Sprachen). Ich hab also keine Erfahrung, wie andere "Lern-Karrieren" heutzutage aussehen.
* (Turbo-) Pascal hatte zu DOS-Zeiten nen ziemlich netten Inline-Assembler, der Exkursionen in die Lowlevel-Programmierung sehr einfach gemacht hat. Das finde ich retrospektiv auch ein ziemlich gutes Feature für eine Lernsprache. Nennt mich altmodisch, aber ich finde dass jemand, der seinen Code (in jeder Sprache) auf wirklich allen Ebenen bis runter zum Silizium versteht, gute Voraussetzungen hat, ein guter Programmierer zu werden
-
@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:
Dies ist schon recht lange gelöst, wen ich mich nicht täusche, seit Delphi 32Bit wurde.
Zu diesem Zeitpunkt hatte Borland den Wettstreit mit C/C++ bereits verloren. Delphi war nur noch ein Nachklang der einstigen Bedeutung von TurboPascal.
Definitiv, mit der LCL erzeuge ich innert kürzester Zeit eine Dialog-Maske, welche dann auch sehr einfach genutzt werden kann. Würde ich dies mit nativen GTKx machen, bräuchte ich viel länger.
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.
@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:
FPC und GCC sind fast ebenbürtig,
GCC ist eine Kollektion von Compilern für verschiedene Sprachen – zurzeit sind das: Ada, C, C++, D, Fortran, Go, Modula-II, Objective-C und Objective-C++. fpc ist nur ein Compiler für eine Sprache.
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Das mit den fixen Array-Größen finde ich allerdings krass, scheint aber gelöst zu sein.
Wenn man sich die Funktionsweise alter Computer mit CP/M, MS-DOS, Macintosh System 1 bis 5, AtariTOS und die Armada von BASIC 8Bit Homecomputer vergegenwärtigt, dann verwundert das nicht sonderlich. Es lief immer nur ein Programm, und das konnte nach belieben im Arbeitsspeicher herumfuhrwerken. Es wurden damals auch bestimmte Programmiertechniken (z.B. selbstmodifizierender Code) genutzt, die heute als bäh gelten.
@Tyrdal 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.
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 () then 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.
Was das Thema Variablen sind in einem Block zu definieren betrifft, das war damals bei C und C++ exakt gleich. Nur wurde das nicht so sauber getrennt wie bei den Algol-artigen Sprachen. Erst mit C++1998 und C1999 wurde das dann gelockert. Zuvor durftest Du froh sein, wenn Du einen ANSI C1989/ISO C1990 Compiler hattest, und Dich nicht mit der K&R Syntax herumschlagen musstest.
/* sinnlose Funktion nur um die Syntax von K&R C zu zeigen */ foo (c) char c; { /* man musste zuerst alle Variablen deklarieren, bevor man sie verwenden durfte */ int i; /* danach konnte man die Variablen initialisieren */ i = 0; if ('a' == c) i = c; else i = c + 1; return (i); }
-
@john-0 sagte in Welche Sprache kann C++ Konkurrenz machen?:
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.
Glade ist aber tot.
-
@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.
-
@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.
-
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.
-
@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
-
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).
-
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.
-
@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...
-
Ja, jedem das seine duck, weg
-
@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.
-
@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.