Beschreiben von C++

[92]

Nomenloser schrieb:

Bei der Gelegenheit:
Ich kann die *gängigeren* Skriptsprachen Perl, Ruby und Python nicht, würde diese aber gerne einschätzen können. Lässt es sich mit denen auch so elegant programmieren wie C++ (vor allem seit C++11; ein wahrer Genuss)? Und wie sieht es mit der Komplexität aus? Gibt's da viel was man wissen muss?

Wäre das hier nicht ein passender Anhaltspunkt, diese Bildungslücke endlich mal zu schließen?
Letzlich: Es ist doch viel schöner, sich ein Urteil aus eigener Erfahrung zu gönnen, statt auf Urteile aus zweiter Hand zurückzugreifen.

[pypypypy]

92 schrieb:

Letzlich: Es ist doch viel schöner, sich ein Urteil aus eigener Erfahrung zu gönnen, statt auf Urteile aus zweiter Hand zurückzugreifen.

Vor allem kommt man damit nicht weit.

Nomenloser: "C++ ist viel besser als Python weil C++ hat TMP aber Python nicht"
PersonMitMinimalerAhnung: "Python braucht das nicht, alles ist sowieso generisch wegen dem Duck Typing."
Nomenloser: "Äh... aber geht doch nicht schon zur Compilezeit?"
PersonMitMinimalerAhnung: "Nein, wozu auch? Dafür ist der Code viel schöner und schneller gecoded."

Gegen Rückfragen ist man nur sicher, wenn man auch Ahnung von der Materie hat.

[volkard]

Nomenloser schrieb:

Wie kann man einer Person, die keine / nur minimale Ahnung von Programmierung hat, erklären, dass C++ schwieriger

Schwieriger: Ja, absolut. In einem gewissen Sinne, also relativ.
C++ ganz zu können geht praktisch nicht. Das verlangt aber auch keiner, nichtmal Struppi.

Amazon schlägt einem bei "C++" bestimmte Bücher vor, die so ungaublich schlecht sind, es ist das pure Rattengift, man nimmt es auf und es löst mit seiner umfassenden Widersprüchlichkeit im Verlaufe der Zeit zunächst jede logische Schlussfolgerung auf, dann jede Intuition, dann jede Programmierlust.

Ich hatte mal eine Berufsschulklasse Fachinformatiker (Richtung Systemintegration, nicht Anwendungsentwicklung, also schon vorher sagten sie sich "Ich muss ja eh nicht proggern im Job, will ich auch nicht, will ich auch nicht lernen."), 10 Wochen vollzeit Programmieren lernen, alle nach abgebrochener anderer Ausbildung, 20 Schüler im Kurs, davon mindestens 10 aus Prinzip dagegen. Hab ihnen erst ein paar Wochen VB nähergebracht. Allein meinen körperlichen Ausmaßen verdanke ich es, das überlebt zu haben. Danach sollte noch C++ drankommen. Reine Utopie! So dachte ich auch. Da muss man doch mal den Lehrplan anpassen und sich eingestehen, daß das einfach nicht geht. Naja, es kam anders. C++ haben sie gerafft. Das ist so herrlich dicht an der Maschine, das lag ihnen. So strunzroh, wie ein Lichtschalter: Wenn man ihn drückt, geht das Licht an. Zunächst, habs halt auch so aufgezogen, erst C, dann C/C++, dann C++. Am Ende beschwerten sich die Leute nur drüber, daß sie erst das doofe VB lernen mußten und dann erst C++, dabei wäre es umgekehrt viel angenehmer gewesen, ein paar Wochen Kotzen gespart, denn nach C++ hätte man das VB locker abgesessen als willkürlich eingeschränkte Sprache.

Nomenloser schrieb:

als ähnliche Programmiersprachen und extrem viel schwieriger als Scriptsprachen wie Batch ist

Schwieriger? Hängt vom Problem ab. Simple Probleme in Batch, wirds ein wenig schlimmer dann Basic, dann C++. Und vor allem kombinieren, Batch ruft Basic-Programm auf und so. Das war mein Stand anno 1990. Anno 2000 hatte ich mich dann in 20 weiteren Sprachen geübt und meine üblichen Probleme konnte ich am besten mit Batch, PHP, Perl oder C++ lösen, wobei je nach Problem nur eine dieser fantastischen Vier passt und die anderen drei gar nicht in Frage kommen.

Nomenloser schrieb:

und dass viele Leute die glauben, sie können C++, eigentlich nichts können, ohne dabei überheblich oder programmier-)sprachchauvinistisch zu klingen?

Geht nicht, ohne überheblich zu klingen.
Fakt ist, daß C++ einen vollkommen anderen Programmierstil braucht als C, aber gute C-Programme auf dem C++-Compiler laufen. Von daher gibt es ein Problem. Wenn man dann noch schlechtes C betreibt, und gerade mal per Versuch-Und-Irrtum lernt, wie man es durch einen C++-Compiler schickt. Das geht in die Hose und ist sowas von üblich!

Es gibt noch eine leider zur Zeit noch unerkannte Mehheit, die Leute die C++ echt gut beherrschen aber überhaut nicht programmieren können. So viele Panne-Programmierer wie in C++ gibt es in keiner anderen Sprache. Die vielen Möglichkeiten der Programmiersprache lenken zu stark ab. Lernen ist geil! Also damit meine ich ganz tumb, wenn man was kapiert hat, werden so glücklichmachende Hormongeschichten ausgestreut. Prima Ding das. Kennnt jeder. Lernen ist geil! Also echtes Lernen, also das Erlernen von Sachen, ich meine damit nicht das Brüten vor Hausaufgaben, zu denen man gar keinen Zugang hat und nur die Zeit absitzt, oder das Zuhören zu Lehrern, die man nicht versteht, das ist kein Lernen.

Nu ist C++ so voller kleiner und größerer Lernfortschritte, daß man sich total darein ergeben kann. Hab ich auch gemacht. 9 Monate nichts außer Essen und Schlafen und C++. Meine Familie hat mich dann rausgeholt.

Vielleicht zeigste Links auf unsere Wolf-Threads. Profis in C++ müssen kein C++ können.

Nomenloser schrieb:

Bei der Gelegenheit:
Ich kann die *gängigeren* Skriptsprachen Perl, Ruby und Python nicht, würde diese aber gerne einschätzen können. Lässt es sich mit denen auch so elegant programmieren wie C++ (vor allem seit C++11; ein wahrer Genuss)? Und wie sieht es mit der Komplexität aus? Gibt's da viel was man wissen muss?

Komplexität ist gleich, wenn Du die Laufzeitkomplexität meinst. Nur Smalltalk ist lahmer oder war es, als ich es zum letzten mal benutzte.

Kompliziertheit liegt im Auge des Betrachters. Man kann wohl von den drei genannten Sprachen in Perl am ehesten C++-Stil programmieren, deswegen würde ich es für Projekte vorziehen, die nicht von vornherein auf nur 5 Jahre Lebenszeit veranschlagt sind.

Das hängt aber voll stark von der Person ab, um die es geht. Es gibt genug Leute, die niemals gut programmieren werden. Denen gibt man vielleicht besser eine Kindersprache wie Java. Es gibt Leute, die können nicht ohne den Hormonflash proggern, denen gibt man vielleicht Haskell. Und auf C++-Seite sollte man 99% der Leute mal 100 Tage lang auf C-Diät setzen zum entgiften. Dann ein Neuanfang und endlich programmieren.

So, das waren nicht wenige Worte. Kack drauf, dann gib ihm halt mehr Worte. Schreibsele aus den Postings halt ein Sammelsurium zusammen, was Deiner Meinung entspricht, drucke es aus und lass ihn lesen. Falls er das nicht kann oder dazu nicht bereit ist, weil er voreilig blockiert, ist es wohl nicht Deine Aufgabe, ihm das einzuhämmern. Geht auch nicht, denn dann würde er auch bei mündlichem Vortrag voreilig blockieren, statt zu überdenken.

Viel Erfolg!

[Nomenloser]

Wow Volkard, deine Posts sind einfach immer zu toll. Bin am Ende derer immer traurig, da es nicht noch weiter geht.

Mechanics schrieb:

Python (und Ruby) erlaubt einiges an Abstraktion, damit kann man auch funktional programmieren, es gibt Metaprogrammierung usw. Und oft braucht man weniger und weniger hässlichen Code als in C++.

Die Frage ist auf welchem Wege die Möglichkeit zur Abstraktion entstanden ist. Indem der Interpreter einfach stumpf einsetzt und das Risiko eingeht, dass da dann zur Laufzeit was in die Luft geht? Aber ich sollte da besser nicht tiefer mitreden, ich habe keine Ahnung von diesen Sprachen. Aus irgendeinem Grund haben sie sich ja etabliert.

Mechanics schrieb:

Vielleicht kann man dir dann besser helfen, wenn du erklärst, was du genau willst? Könnte sein, dass du vor deiner Freundin angeben willst, oder dass du auf der Straße von Schlägern bedroht wirst, die sofort wissen wollen, warum C++ so schwierig ist. Dann wären vielleicht unterschiedliche Antworten angebracht.

Naja, eher wegen Diskussionen mit Freunden. Was soll man denn so sagen? Die Aussage dass C++ schwierig zu erlernen (und noch schwieriger sinnvoll anzuwenden ist) gilt es ja auch entsprechend zu untermauern.
- "Es gibt halt einfach viel zu lernen" (wirkt als wäre die Sprache einfach eine sinnlose Verkomplizierung bestehender sprachen, was gegen sie spricht)
- "Es gibt viele Sonderfälle" (spricht auch gegen sie; ist m.M.n. bei C++ nicht mal nicht der Fall, im Gegenteil)

92 schrieb:

Wäre das hier nicht ein passender Anhaltspunkt, diese Bildungslücke endlich mal zu schließen?

Wäre es durchaus, ja, um aber etwas Umfangreicheres einfach nur zum Spaß zu lernen fehlt mir - zur Zeit zumindest - ein wenig die Zeit.

92 schrieb:

Letzlich: Es ist doch viel schöner, sich ein Urteil aus eigener Erfahrung zu gönnen, statt auf Urteile aus zweiter Hand zurückzugreifen.

Dem kann ich nur beipflichten.

volkard schrieb:

C++ ganz zu können geht praktisch nicht. Das verlangt aber auch keiner, nichtmal Struppi.

Ach, so exzessiv meinte ich das auch gar nicht.

volkard schrieb:

[...]

Oha, das wäre dann das genaue Gegenteil von "schwierig zu erlernen", jedoch auf Basis von Intuition. Daran hab ich nicht gedacht.

volkard schrieb:

Komplexität ist gleich, wenn Du die Laufzeitkomplexität meinst. Nur Smalltalk ist lahmer oder war es, als ich es zum letzten mal benutzte.

Eigentlich meinte ich die Komplexität der Sprache. Aber wenn du das schon erwähnst: Gleich? Aber dann unter den genannten Skriptsprachen und nicht im Vergleich zu C++, oder?

volkard schrieb:

Das hängt aber voll stark von der Person ab, um die es geht. Es gibt genug Leute, die niemals gut programmieren werden. Denen gibt man vielleicht besser eine Kindersprache wie Java. Es gibt Leute, die können nicht ohne den Hormonflash proggern, denen gibt man vielleicht Haskell. Und auf C++-Seite sollte man 99% der Leute mal 100 Tage lang auf C-Diät setzen zum entgiften. Dann ein Neuanfang und endlich programmieren.

Das wäre eine Signatur wert.

Danke für deine Antwort, wie gewohnt überwältigend. Und gute Nacht nun.

[SeppJ]

Nomenloser schrieb:

volkard schrieb:

Komplexität ist gleich, wenn Du die Laufzeitkomplexität meinst. Nur Smalltalk ist lahmer oder war es, als ich es zum letzten mal benutzte.

Eigentlich meinte ich die Komplexität der Sprache. Aber wenn du das schon erwähnst: Gleich? Aber dann unter den genannten Skriptsprachen und nicht im Vergleich zu C++, oder?

Denk dran, dass Konstanten vernachlässigt werden, wenn man über Laufzeitkomplexitäten spricht! Daher sind Laufzeitkomplexitäten in allen Sprachen gleich. Außer vielleicht in irgendwelchen Exotensprachen mit künstlichen Einschränkungen (kastrierte Sprachen ohne Zeiger oder Feinkontrolle über Datenstrukturen) oder wenn du mit komischen Argumenten wie "Sprache A erlaubt nativ Parallelisierung, Sprache B nicht" kommst^*.

^*: Diese beiden Argumente würden darauf hinaus laufen, dass man nicht die Komplexität von Algorithmen vergleicht, sondern die nötige Komplexität zur Lösung einer speziellen Aufgabenstellung. Was eine komische Definition des Begriffs Laufzeitkomplexität wäre.

[volkard]

SeppJ schrieb:

…

Oder die Sprache wird definiert durch eine Referenzimplementierung, die für virtuelle Funktionen Entscheidungsbäume benutzt, pattenmatching durch lineares Suchen über alle Patterns, switch/case durch lineare Suche, oder integers verdoppelt durch [->+<]>[-<++>]<. Uups, letzeres ist nur "irgendwelchen Exotensprachen mit künstlichen Einschränkungen", fällt also weg.

[SeppJ]

Gibt's für die anderen ein Beispiel? Ich rede von "normalen" Sprachen, die in einer Liste der 50 wichtigsten Sprachen auftauchen könnten.

[volkard]

Nomenloser schrieb:

- "Es gibt halt einfach viel zu lernen" (wirkt als wäre die Sprache einfach eine sinnlose Verkomplizierung bestehender sprachen, was gegen sie spricht)

Schau Dir mal kurz das Universum an. Newtons Mechanik ist einfach, eine supi Sprache. Aber damit kann man nur alle Probleme lösen, die man mit Händen fassen kann. Die Relativitätstheorie, Quantenphysik(bisher kein Mensch bekannt, der sie verstanden hat), Stringtheorie oder Schleifenquantengravitation, solche Bringer benutzen die Leute an der Front, ums Universum einigermaßen darzustellen. Ok, die haben auch den Anspruch, daß das Modell nicht zum Beispiel jeden Mittwochvormittag bei Vollmond mal versagt.

Vielleicht ist das Programmieren an sich eine saukomplizierte Sache⁽²⁾.

Und man braucht auch eine dementsprechende Sprqacxhe⁽¹⁾, wenn man nicht jedes an einem Mittwochvormittag bei Vollmond gestartete Softwareprojekt gegen die Wand fahren will, weil die Sprache was Wesentliches nicht darstellen kann. Also wie schlimm die Leute an P=NP rumdoktorn, oder wie seltsam das Halteproblem ist, vielleicht ist es tatsächlich eine saukomplizierte Sache, und zwischen Einfachheit für Nubes (schnell gelernt) und Einfachheit für Profis (nicht so oft gegen eine Wand fahren) besteht ein prinzipieller nicht abzuschaffender Zielkonflikt.

^(1)[h] [t]Das war wirklich nur auf der Tastatur ausgerutscht, habs aber stehenlassen, weil es irgendwie schön in diesen Satz passt.[/t]

[h]2^ ~Das Programmieren als Kunst, wartbare Programme zu schreiben, nicht bloß Turingvollständigkeit.~

[volkard]

SeppJ schrieb:

Gibt's für die anderen ein Beispiel? Ich rede von "normalen" Sprachen, die in einer Liste der 50 wichtigsten Sprachen auftauchen könnten.

Alle gleich. Sie sind vollständig genug, daß man sich einen Uber-Trick, den eine andere Sprache von Hause aus anbietet, daß man sich den auch selber programmieren könnte, um gleich schnelle (in Sachen Komplexität) Programme zu bauen. Und dann werden die Sprachen heutzutage ja auch noch nur auf dem Papier definiert, mit Null Aussage über Laufzeiten! Da muss man dann von einem vernünftigen Compiler/Interpreter ausgehen und sich passende Laufzeiten ausdenken.

[Mechanics]

Nomenloser schrieb:

Die Frage ist auf welchem Wege die Möglichkeit zur Abstraktion entstanden ist. Indem der Interpreter einfach stumpf einsetzt und das Risiko eingeht, dass da dann zur Laufzeit was in die Luft geht?

In solchen Sprachen kann dir grundsätzlich alles zur Laufzeit um die Ohren fliegen. Ich mag das auch nicht, hab ich ja geschrieben. Aber je nach Problemstellung spielts vielleicht gar keine Rolle. Bei Scripten in der Größenordnung 1-2 tausend Zeilen ist es relativ egal, das hat man im Griff, vor allem, wenn mans gewohnt ist. Vor allem, wenn das Problem an sich schon dynamisch ist, ist es ein Vorteil. Solche Sprachen werden ja oft im Web eingesetzt. Wenn du die Darstellung von der Logik trennen willst und eine Template Engine haben willst, wirst du dich mit C++ schwertun und es wird was ziemlich hässliches dabei rauskommen. In jeder dynamischen Scriptsprache geht sowas direkt. Klar, du kannst dich vertippen und dann hast du in deinem Template eine Methode drinstehen, die in Wirklichkeit etwas anders heißt. Aber das Problem hättest du dann auch in C++, wie auch immer du sowas gelöst hättest. Templates sind nun mal Text und da kann man sich schon mal vertippen. Genauso bei Datenbankzugriffen, die in Scriptsprachen dann vielleicht mit "Convention over configuration" mehr oder weniger automatisch gehen und wo man in C++ viel Code schreiben müsste, und dann trotzdem Gefahr läuft, dass man sich bei einem Tabellennamen vertippt hat. Sowas kann man nicht als absolutes Argument verwenden. Wie gesagt, einige Sprachen sind für bestimmte Probleme vielleicht besser geeignet, als andere, und es dürfte keine Sprache geben, die für alle Probleme gleichermaßen geeignet ist.

volkard schrieb:

und zwischen Einfachheit für Nubes (schnell gelernt) und Einfachheit für Profis (nicht so oft gegen eine Wand fahren) besteht ein prinzipieller nicht abzuschaffender Zielkonflikt.

Ja, das ist ein guter Punkt. Mich nervt das auch immer, wenn jemand eine sehr suboptimale Lösung abliefert oder VB programmiert oder so und dann meint, das wäre einfacher. Als Profi interessiert mich "einfacher" nicht. Das ist doch unser Job. Kann natürlich sehr viele Fälle geben, wo "einfacher" wichtig und auch besser ist. Aber es wird viel zu oft als Rechtfertigung für etwas gebraucht, wo man einfach keine Ahnung hatte oder zu faul war, sich einzuarbeiten.

[Marthog]

Mechanics schrieb:

Ja, das ist ein guter Punkt. Mich nervt das auch immer, wenn jemand eine sehr suboptimale Lösung abliefert oder VB programmiert oder so und dann meint, das wäre einfacher. Als Profi interessiert mich "einfacher" nicht. Das ist doch unser Job. Kann natürlich sehr viele Fälle geben, wo "einfacher" wichtig und auch besser ist. Aber es wird viel zu oft als Rechtfertigung für etwas gebraucht, wo man einfach keine Ahnung hatte oder zu faul war, sich einzuarbeiten.

Es kommt fuer mich immer sehr darauf an, was man machen will. Ein kleines Skript, das ein bisschen was steuert, kann gerne in einer dynamisch typisierten Sprache sein, weil man es dann viel schneller aendern kann, weniger boilerplate code hat und es auch so sicher genug ist.
Bei einem grossen Projekt setzt sich dann durch, dass man bei einer komplizierten Sprache wesentlich mehr Vorarbeit geleistet hat und die Arbeit, die man in die saubere Programmstruktur gesteckt hat, vermeidet Fehler bereits im Ansatz.
Ausserdem kommen die einfacheren Sprachen dann an ihre Grenzen, weil die vorgefertigten Funktionen nicht mehr reichen und neue zu schreiben sehr schwierig ist, waehrend die STL so allgemein gehalten ist, dass man den algorithm-Header sogut wie immer benutzen kann, um komplizierte Aufgaben einfacher darzustellen. Dann wird ploetzlich die ach so einfache Sprache zur schwierigeren.