Lohnt es sich noch C++ zu lernen?

[GilbertDur]

Aber hast du dir mal überlegt, was für ein Objekt du bei C# übergeben bekommst:

Code: Alles auswählen

private void someFunc(object o){...}

ist o eine kopie, ist o direkt das Element, was ist es denn?
Solange du nur lesend darauf zugreifst, dann ist es dir egal. Aber was passiert, wenn du darauf schreibst? Was wird wo verändert?
Das ist etwas, was in C++ sehr direkt ist:

Code: Alles auswählen

void someFunc(object o) {...}
void someFunc(object * o) {...}
void someFunc(object & o) {...}

Kopie, Pointer, Referenz. Sehr eindeutig.

In nem guten C# Tutorial oder Buch ist das aber schon erklärt...und hat man das Prinzip einmal verstanden, finde ich es an sich einfacher bzw. intuitiver als die 3 verschiedenen Varianten in C++, aber ich denke das ist Geschmackssache.

Also ich fand Pascal nicht grauenhaft und schlecht. Es war aufs nötigste reduzierte, strukturierte Programmierung. Gut geeignet um den Ablauf von Algorithmen zu verstehen.

Das ist C/C++ auch.

C noch eher als C++ wo die ganze Objektorientierung rangebaut wurde.

Dem stimme ich zu, auch wenn ich als Anfänger die Konsole langweilig fand. Man lernt einfach die Abläufe besser, konzentriert sich aufs Wesentliche. Leider neigt man anfangs aber auch dazu gleich etwas sehen zu wollen

GUIs sind unwichtig, lästig und halten auf. Und auch da sind es immer deine Algorithmen und Datenstrukturen, die das Programm bestimmen, nicht die Oberfläche.

Für dich vielleicht, aber ich denke, dass nicht jeder Programmierer der absolute Konsolen-Fan ist und auch nicht jeder Programmierer Konsole für Konsolenfans programmiert. Die meisten Nutzer wären mit Konsolen einfach überfordert, daher sind GUIs wichtig (wenn auch manchmal lästig, das gebe ich zu), egal ob im Web oder im Desktop/Mobile-Bereich. Oder bedienst du das Forum hier gerade per Konsole? Mag ja sein, dass es einige Leute gibt, die mit Console-Only glücklich sind, aber die Mehrheit braucht die GUI.
Und auch zum erstellen von GUIs braucht es Datenstrukturen und Algorithmen. Und es soll auch Leute geben, die gerne GUIs erstellen (ok ich gehöre mangels Design-Talent nicht dazu ).

[Xin]

Allerdings wird Java nicht den gleichen Weg gehen wie Pascal, dafür wird es einfach in viel zu vielen Projekten und Systemen eingesetzt. Solange Firmen wie SAP, Oracle und Google Java pushen, wird es nicht zur reinen Lehrsprache verkommen. Auch die vielen Stellenausschreibungen für Java sprechen da Bände.

SAP pusht Java nicht mehr. Ich hatte vor zwei Jahren die Frage an einen SAP-Entwickler gestellt und der meinte, alles was in Java existiert, wird sukzessive abgelöst. Neue Projekte werden von Schulabgängern in Java gestartet, aber die Projekte interessieren dann in der Regel eh keinen.

Java gehört Oracle. Wenn die Java nicht pushen, dann wüsste ich nicht, wie man tot sonst noch definieren könnte. Und Android kann man inzwischen wohl auch mit C++ füttern.

Ich stimme dem meisten zu. Ich denke aber nicht, dass C/C++ einfach ist. Speicherverwaltung, Templates, Type-Casting, die berüchtigten Zeiger...all das bietet viele Stolperfallen, gerade für Anfänger.

Speicherverwaltung kann man sich von C++ abnehmen lassen, man muss es aber explizit sagen.
Templates muss man nicht kennen, sollte man aber. In Java programmiert man auch mit Generics, also sehe ich hier keinen Nachteil bei C++. Type-Casting gibt es bei allen Sprachen udn die berüchtigten Zeiger...?
Java arbeitet ausschließlich mit Zeigern, in C++ stehen Dir zusätzlich RAII und Referenzen zur Verfügung.

Zu ersten Erfolgserlebnissen kommt man mit anderen Sprachen schneller. C/C++ kann da sehr demotivierend sein. Und auch nach einigen Jahren beherrscht man beides meistens noch nicht völlig (ich jedenfalls nicht, ich lerne hier im Forum immer wieder dazu)

Das ist richtig, wenn es um Erfolgserlebnisse geht, muss man in C++ etwas bescheidenener an die Sache rangehen. Mal eben eine GUI ist in C++ keine gute Idee.

Die Frage ist natürlich, warum man programmieren lernen möchte. Meint man das Ernst oder will man eher spielen?

Dem stimme ich zu, auch wenn ich als Anfänger die Konsole langweilig fand. Man lernt einfach die Abläufe besser, konzentriert sich aufs Wesentliche. Leider neigt man anfangs aber auch dazu gleich etwas sehen zu wollen. Daher befürworte ich beispielsweise Grundlagen der Programmierung mit PHP oder Javascript zu lernen. Im Webbrowser sieht so eine Ausgabe (aufgehübscht mit HTML und CSS) gleich freundlicher aus

Das ist für Anfänger ein wichtiger Punkt, den ich auch bei meiner Sprache umsetzen möchte.

Aber irgendwo muss man auch verständlich machen, dass eine GUI, eine Website oder ein 3D-Modell zu produzieren, nur Zucker ist - insbesondere, wenn ich einfach nur sage "Mach mal GUI". Programmieren lernen findet meistens ganz wo anders statt - die angesprochene Liste z.B.

Als ich den Parser von meinem Compiler geschrieben habe, zeigte ich stolz ein Programm, was fehlerfrei geparst wurde. Der Compiler erkannte, dass darin kein Fehler enthalten war und gab keine Ausgabe. Kommentar des Kommilitonen: "Das hätte ich auch schneller hinbekommen."



cloidnerux stimme ich soweit komplett zu. Das Beispiel mit der DSLR gefällt mir sehr gut.

Dem stimme ich zu, auch wenn ich als Anfänger die Konsole langweilig fand. Man lernt einfach die Abläufe besser, konzentriert sich aufs Wesentliche. Leider neigt man anfangs aber auch dazu gleich etwas sehen zu wollen

GUIs sind unwichtig, lästig und halten auf. Und auch da sind es immer deine Algorithmen und Datenstrukturen, die das Programm bestimmen, nicht die Oberfläche.

Programmieren darf - gerade am Anfang - auch Spaß machen. Bis man verstanden hat, warum komplexe Algorithmen auch Spaß machen und man beim Programmieren so sicher ist, dass man solche komplexen Aufgaben überhaupt debuggen kann, sollte es das auch. Denn bei so komplexen Aufgaben muss man vorher wissen, dass es Spaß und stolz macht, wenn man das am Ende gepackt hat. Diese Frustrationstoleranz muss man erstmal aufbauen können.

In nem guten C# Tutorial oder Buch ist das aber schon erklärt...und hat man das Prinzip einmal verstanden, finde ich es an sich einfacher bzw. intuitiver als die 3 verschiedenen Varianten in C++, aber ich denke das ist Geschmackssache.

Kopie, Referenz oder Zeiger kann in C# nicht erklärt werden, denn C# kennt diese Unterscheidungen nur im 'unsafe'-Modus. Und dann programmiert man eher C++-Syntax als C#.
C# selbst kennt nur - und jetzt kommt's - die berüchtigten Zeiger. Nur sagt man es dem Programmierer nicht.

C noch eher als C++ wo die ganze Objektorientierung rangebaut wurde.

Auch das gehört zur Programmierung. OOP ist ein Design Pattern - das kann man nutzen - muss man aber nicht.
Es ist eine Standardlösung für ein Problem. Ähnlich wie ein while() eine Standardlösung ist - man könnte auch ein if...goto nehmen.

Und auch zum erstellen von GUIs braucht es Datenstrukturen und Algorithmen. Und es soll auch Leute geben, die gerne GUIs erstellen (ok ich gehöre mangels Design-Talent nicht dazu ).

Für GUIs braucht man heutzutage eher ein Programm, mit dem man Buttons hin und her verschiebt. GUIs werden auch gerne per HTML (oder QML) programmiert. Mit Datenstrukturen oder gar Algorithmen hat das heute weniger zu tun.

[cloidnerux]

Für dich vielleicht, aber ich denke, dass nicht jeder Programmierer der absolute Konsolen-Fan ist und auch nicht jeder Programmierer Konsole für Konsolenfans programmiert. Die meisten Nutzer wären mit Konsolen einfach überfordert, daher sind GUIs wichtig (wenn auch manchmal lästig, das gebe ich zu), egal ob im Web oder im Desktop/Mobile-Bereich. Oder bedienst du das Forum hier gerade per Konsole? Mag ja sein, dass es einige Leute gibt, die mit Console-Only glücklich sind, aber die Mehrheit braucht die GUI.

GUIs sind wichtig, keine Frage, aber eben für den Nutzer und nicht den Programmierer. Ich selber entwickel auch einige Anwendungen mit GUI in C# und WinForms. Und es nervt mich stark. Weil "nur" eine GUI zusammenklicken ist kein Problem, das Problem ist die Interaktion mit dem Nutzer und den Daten. Nur was buntes zu sehen reicht ja nicht, es soll ja was können und das intuitiv und schnell. Und so kommt es, dass du 2 - 3h Zeit opferst, eine dämliche ListView so zu optimieren, dass man damit arbeiten kann, ohne den Verstand zu verlieren. Mehrfach das Programm umstrukturieren, damit die Verbindung der GUI sinnvoller funktioniert, grundlegende Funktionalität aus der GUI in die Datenhaltung auslagern(Daten speichern, lesen, auswerten). Das hält alles auf.
Und das ist auch ein Grund, warum GUIs keine großen Erfolgserlebnisse darstellen. Man klickt was zusammen, das sieht dann schön aus. Dann klickt man auf etwas, und es passiert nichts. Dann sitzt man da und muss programmieren und stellt fest, dass man nicht drum herum kommt, Daten zu verwalten, Algorithmen zu implementieren usw. Man merkt sehr schnell, dass GUIs einen weder beim lernen noch Implementieren weiter bringen.
Vor allem die Tatsache, dass eine wirklich gute GUI sehr viel Arbeit ist, ist den meisten verschlossen. Den es ist nicht das aussehen, sondern die Bedienung, die bei sowas entscheidet. Und das ist sehr viel social Engineering.

Und auch zum erstellen von GUIs braucht es Datenstrukturen und Algorithmen. Und es soll auch Leute geben, die gerne GUIs erstellen (ok ich gehöre mangels Design-Talent nicht dazu ).

Eine GUI ist ein Interface zwischen deinem Programm und dem Nutzer. Damit ist es zwangsläufig, dass du ein backend programmieren musst, dass mit deinem Frontend kommuniziert und deine Informationen darstellt und vom Nutzer eingegebene Informationen zurückgibt. Was anderes macht die Konsole auch nicht, wenn auch deutlich direkter.
Aber ich will darauf hinaus, dass eine GUI keinem hilft, schneller, besser oder sinnvoller Programmieren zu lernen. Egal ob das jetzt HTML ist was dann im Browser Angezeigt wird, WinForms, GTK, QT, WPF oder was auch immer, die haupt arbeit liegt im Backend und da musst du wieder Programmieren. Und da ist man zum Debuggen froh, irgendwo ein cout oder printf rein zu setzten um mal schnell zu sehen, was da wie passiert. Das kannst du mit einer GUI nicht.
Daher ist es niemals sinnvoll, einem Programmieranfänger erst eine GUI zu zeigen und dann das Programmieren, weil er wird verzweifeln, weil weder die GUI, noch sein Programm in irgendeiner weise sinnvoll funktionieren.

Für GUIs braucht man heutzutage eher ein Programm, mit dem man Buttons hin und her verschiebt. GUIs werden auch gerne per HTML (oder QML) programmiert. Mit Datenstrukturen oder gar Algorithmen hat das heute weniger zu tun.

Die GUI nicht, das Programm dahinter schon.

In nem guten C# Tutorial oder Buch ist das aber schon erklärt...und hat man das Prinzip einmal verstanden, finde ich es an sich einfacher bzw. intuitiver als die 3 verschiedenen Varianten in C++, aber ich denke das ist Geschmackssache.

Auf Literatur zu verweisen, hilft dem Schüler nicht^^
In C# ist alles ein Pointer und sowieso alles "managed", solange du es nicht anders möchtest(unsafe modus). Du arbeitest mit Objekten und übergibst sie und dann musst du dich dann auch mal fragen, was da egt passiert. Denn es mussten ja die Schlüsselwörter "ref" und "out" eingeführt werden, nur um das was in C/C++ durch die Pointer möglich ist sinnvoll zu implementieren.
Dadurch das in C# alles ein Pointer ist, ist eben dieser Funktionsaufruf uneindeutig. Natürlich ist genau festgelegt, wie sich das zu verhalten hat, aber es ist nicht offensichtlich. Das macht C/C++ halt anders. Der Aufruf ist offensichtlich eindeutig. Jeder Parameter den du übergibst wird kopiert. Übergibst du ein Objekt, wird es kopiert. Übergibst du einen Pointer, wird er kopiert. Der neue Pointer zeigt aber weiterhin auf das Element, das du nun verändern kannst. Für mich ist das sehr logisch und eindeutig.

[Xin]

Und das ist auch ein Grund, warum GUIs keine großen Erfolgserlebnisse darstellen. Man klickt was zusammen, das sieht dann schön aus. Dann klickt man auf etwas, und es passiert nichts.

Kinder spielen mit Spielzeugwaffen Polizei oder Cowboy. Und wenn sie schießen, passiert (meistens) auch nichts.
Trotzdem haben Sie Spaß, denn sie fühlen sich, als wären sie wie die Großen.

Wer als Anfänger eine GUI zusammenstellt, sieht etwas, was so aussieht, wie das, was echte Programmierer machen. Es macht Spaß. Und für viele ist es der Grund, sich mit Algorithmen auseinander zu setzen, um ihrer GUI Leben ein zu hauchen.

Du arbeitest mit Objekten und übergibst sie und dann musst du dich dann auch mal fragen, was da egt passiert. Denn es mussten ja die Schlüsselwörter "ref" und "out" eingeführt werden, nur um das was in C/C++ durch die Pointer möglich ist sinnvoll zu implementieren.

Ähh... kleiner Einspruch: ref und out sind Referenzen auf Zeiger, das ist richtig. Eine Parameterrückgabe (out) bzw. optionale Parameterrückgabe (ref) ist ohne die beiden Schlüsselwörter nicht möglich, was in C++ einfach durch einen Stern repräsentiert wird.
Zusätzlich kennzeichnet ref und out aber auch ob die Rückgabe verpflichtend oder optional ist. Das wiederum ist im Vergleich zu C++ ein semantischer Vorteil, da ein out-Parameter in der Funktion initialisiert werden muss, aber uninitialisiert übergeben werden darf.

Es ist also nicht "nur" das, was in C++ mit einem Pointer möglich ist.

[GilbertDur]

Java gehört Oracle. Wenn die Java nicht pushen, dann wüsste ich nicht, wie man tot sonst noch definieren könnte. Und Android kann man inzwischen wohl auch mit C++ füttern.

Ich finde, dass Java auch im Open Source Bereich noch nen gewichtigen Projektanteil hat oder täuscht das? Android mit C++ sieht mir aber eher noch ziemlich kompliziert aus

Type-Casting gibt es bei allen Sprachen

Mir kam es persönlich so vor, als wären die Type-Casting Regeln in C aber wesentlich lockerer gefasst, als zum Beispiel in C#. Na gut gleichzeitig muss man in C# übers Boxing und Unboxing Bescheid wissen. Ok.

Java arbeitet ausschließlich mit Zeigern, in C++ stehen Dir zusätzlich RAII und Referenzen zur Verfügung.

Schön und gut und genau das macht C++ am Anfang in meinen Augen komplizierter, auch wenn ich es rückblickend besser finde als einfach nur "new" zu schreiben. Mir ist schon klar, dass Java und auch C# intern mit Zeigern arbeiten, aber sie abstrahieren das weg und sehen für Neulinge dadurch einfacher aus und fühlen sich auch einfacher an. Das Thema war ja ursprünglich, ob man noch C++ lernen sollte und ich wollte einfach mal ansprechen, wo die Schwierigkeiten für C++-Neulinge liegen können. Durfte ich ja die letzten 3 Jahre beobachten

Die Frage ist natürlich, warum man programmieren lernen möchte. Meint man das Ernst oder will man eher spielen?

Ist jetzt meine persönliche Meinung: Mir kommt es so vor, dass die meisten erst mal spielen (oder Spiele programmieren) wollen oder sich vorstellen in den Kreis der coolsten Hacker aufzusteigen, wie sie es letztens in nem Hollywood-Film gesehen haben.
Schaut man sich dann Tutorials oder Bücher zu C++ an, wird einem die Illusion vom schnellen eigenen Spiel aber auch sehr schnell wieder genommen. Da zeigt sich dann, ob die Leute mit ernst bei der Sache sind.

Kopie, Referenz oder Zeiger kann in C# nicht erklärt werden, denn C# kennt diese Unterscheidungen nur im 'unsafe'-Modus. Und dann programmiert man eher C++-Syntax als C#.
C# selbst kennt nur - und jetzt kommt's - die berüchtigten Zeiger. Nur sagt man es dem Programmierer nicht.

Hier muss man dann eben wieder diskutieren, ob es besser wäre, dem Programmierer zu sagen, dass es Zeiger sind. Als Anfänger hätte es mich verwirrt. Heutzutage würde ich sagen: Ja klar, sollte man wissen. Das meinte ich auch mit intuitiver. Wenn man erst mal nur ein "new" liest, ist man weniger abgeschreckt, als wenn man sofort mit Zeigern hantieren muss, wobei es wiederum besser ist gleich die Zeiger zu verstehen, da man dann mit "new" auch nie so große Probleme haben wird. Ist ne widersprüchliche Geschichte. Würde ich ein C# Tutorial schreiben, würde ich die Interna hinter new jedoch eher im Fortgeschrittenen-Teil abhandeln.

OOP ist ein Design Pattern - das kann man nutzen - muss man aber nicht.

Trotzdem verkompliziert es die Sprache, im Vergleich zu C, da man auch kaum ne C++-Anleitung findet, wo OOP ignoriert wird. Die meisten propagieren das ja sogar eher. Und als Einsteiger prozedurale Programmierung und OOP gleichzeitig zu verstehen... Ist schon nicht so leicht. Da braucht man gleich nen etwas längeren Atem. Aber na gut, den braucht man wohl sowieso, wenn man ernsthaft programmieren lernen will

Für GUIs braucht man heutzutage eher ein Programm, mit dem man Buttons hin und her verschiebt. GUIs werden auch gerne per HTML (oder QML) programmiert. Mit Datenstrukturen oder gar Algorithmen hat das heute weniger zu tun.

Ich dachte auch eher daran, was man so wissen muss, wenn man selbst eine GUI-Bibliothek erstellen wollte. Aber ok, wer macht sowas heutzutage noch selbst. Ich mag übrigens das Button hin - und herverschieben per Designer nicht. Da kommt fast immer Murks bei raus. Sachen wie QML oder XAML finde hingegen ganz gut, wenn man sie selbst schreibt und nicht "hinklickt".

GUIs sind wichtig, keine Frage, aber eben für den Nutzer und nicht den Programmierer.

Das war ja mein Punkt. Die meisten Entwickler programmieren ja für den Nutzer und nicht nur für sich selbst oder für andere Programmierer.

Nur was buntes zu sehen reicht ja nicht, es soll ja was können und das intuitiv und schnell. Und so kommt es, dass du 2 - 3h Zeit opferst, eine dämliche ListView so zu optimieren, dass man damit arbeiten kann, ohne den Verstand zu verlieren. Mehrfach das Programm umstrukturieren, damit die Verbindung der GUI sinnvoller funktioniert, grundlegende Funktionalität aus der GUI in die Datenhaltung auslagern(Daten speichern, lesen, auswerten). Das hält alles auf.

Es macht aber auch das Programm insgesamt wartbarer. Und wenn man eh keine Chance hat, die GUI zu vermeiden? Natürlich könnte man argumentieren, dass man schneller fertig ist, wenn niemand eine GUI verlangen würde. Das stimmt.

Und das ist auch ein Grund, warum GUIs keine großen Erfolgserlebnisse darstellen. Man klickt was zusammen, das sieht dann schön aus. Dann klickt man auf etwas, und es passiert nichts. Dann sitzt man da und muss programmieren und stellt fest, dass man nicht drum herum kommt, Daten zu verwalten, Algorithmen zu implementieren usw. Man merkt sehr schnell, dass GUIs einen weder beim lernen noch Implementieren weiter bringen.
Vor allem die Tatsache, dass eine wirklich gute GUI sehr viel Arbeit ist, ist den meisten verschlossen. Den es ist nicht das aussehen, sondern die Bedienung, die bei sowas entscheidet.

Absolute Zustimmung

Daher ist es niemals sinnvoll, einem Programmieranfänger erst eine GUI zu zeigen und dann das Programmieren, weil er wird verzweifeln, weil weder die GUI, noch sein Programm in irgendeiner weise sinnvoll funktionieren.

Das habe ich auch nie gesagt. Ich sage das Gegenteil: Niemand sollte mit komplexer GUI-Programmierung anfangen, schon gar nicht in C++. Ich störte mich einfach nur an dem "GUIs sind unwichtig" Satz .

[Xin]

Java gehört Oracle. Wenn die Java nicht pushen, dann wüsste ich nicht, wie man tot sonst noch definieren könnte. Und Android kann man inzwischen wohl auch mit C++ füttern.

Ich finde, dass Java auch im Open Source Bereich noch nen gewichtigen Projektanteil hat oder täuscht das? Android mit C++ sieht mir aber eher noch ziemlich kompliziert aus

Ich habe mir das noch nicht angesehen, würde das aber bevorzugen.
Ich bevorzuge ja auch C++. ^^

Was ist denn im OpenSource-Bereich mit Java unterwegs? LibreOffice! Hmm... sonst noch was wichtiges? Eclipse - ich bin Softwareentwickler, wollte es benutzen, tue es aber nach einer Testphase trotzdem nicht.

Viele Kids machen OpenSource-Projekte, in dem sie etwas nachmachen, was sie im Unterricht gelernt haben (Java) und damit ein wenig rumspielen.

Vielleicht fehlt mir auch nur der Einblick, denn als (auch) Mac-User muss ich Java explizit installieren. Und das gegenwärtige MacBook ist jetzt ein Jahr alt und hat immernoch kein Java.

Type-Casting gibt es bei allen Sprachen

Mir kam es persönlich so vor, als wären die Type-Casting Regeln in C aber wesentlich lockerer gefasst, als zum Beispiel in C#. Na gut gleichzeitig muss man in C# übers Boxing und Unboxing Bescheid wissen. Ok.

Wieso lockerer gefasst?

Java arbeitet ausschließlich mit Zeigern, in C++ stehen Dir zusätzlich RAII und Referenzen zur Verfügung.

Schön und gut und genau das macht C++ am Anfang in meinen Augen komplizierter, auch wenn ich es rückblickend besser finde als einfach nur "new" zu schreiben. Mir ist schon klar, dass Java und auch C# intern mit Zeigern arbeiten, aber sie abstrahieren das weg

Nein, tun sie nicht.
Du bekommst Deine Null-Pointer-Exception in Java/C# genauso wie in C++. Pointer-Arithmetik zu verbieten ist auch kein "wegabstrahieren". Wenn man statt void * nun object schreibt und Casten Boxing nennt, dann ist das auch kein wegabstrahieren.
Es sind neue Worte, die andere Worte überlagern sollen, die negativ belegt sind. Programmierung funktioniert aber weiterhin genauso, wie in C++, nur dass es Leute gibt, die tatsächlich glauben, dass C# einfacher ist, weil man keine gefährlichen Pointer und kein gefährliches Casting hat. Die meisten Java-Entwickler, die ich gesprochen habe, haben nie mit Pointern gearbeitet und wissen nicht, was ein Casting ist.

Die Frage ist natürlich, warum man programmieren lernen möchte. Meint man das Ernst oder will man eher spielen?

Ist jetzt meine persönliche Meinung: Mir kommt es so vor, dass die meisten erst mal spielen (oder Spiele programmieren) wollen oder sich vorstellen in den Kreis der coolsten Hacker aufzusteigen, wie sie es letztens in nem Hollywood-Film gesehen haben.
Schaut man sich dann Tutorials oder Bücher zu C++ an, wird einem die Illusion vom schnellen eigenen Spiel aber auch sehr schnell wieder genommen. Da zeigt sich dann, ob die Leute mit ernst bei der Sache sind.

So habe ich auch angefangen. Eins meiner ersten Programme war eine Simulation eines Hackerangriffs. Damals war ich so 10 oder 11 Jahre alt. Und das ist ja auch vollkommen in Ordnung, nur ist Programmieren lernen heute viel komplizierter, bevor man etwas sieht, weil die Computer und damit auch die Möglichkeiten der Programme viel aufwendiger geworden sind.
Mit hat ein TicTacToe gereicht, das mit ASCII-Grafik gezeichnet wurde. Das war damals Standard und in Ordnung. Das konnte ich auch selbst erreichen.

Hier muss man dann eben wieder diskutieren, ob es besser wäre, dem Programmierer zu sagen, dass es Zeiger sind. Als Anfänger hätte es mich verwirrt. Heutzutage würde ich sagen: Ja klar, sollte man wissen. Das meinte ich auch mit intuitiver. Wenn man erst mal nur ein "new" liest, ist man weniger abgeschreckt, als wenn man sofort mit Zeigern hantieren muss, wobei es wiederum besser ist gleich die Zeiger zu verstehen, da man dann mit "new" auch nie so große Probleme haben wird. Ist ne widersprüchliche Geschichte. Würde ich ein C# Tutorial schreiben, würde ich die Interna hinter new jedoch eher im Fortgeschrittenen-Teil abhandeln.

Hast Du mein C-Tutorial mal gelesen?

OOP ist ein Design Pattern - das kann man nutzen - muss man aber nicht.

Trotzdem verkompliziert es die Sprache, im Vergleich zu C, da man auch kaum ne C++-Anleitung findet, wo OOP ignoriert wird.

OOP verkompliziert nicht "die Sache", sondern vereinfacht ein Standard-Problem.
C++ ist eine Sprache, die OOP direkt unterstützt, die geschaffen wurde, um das Standardproblem in C leichter lösen zu können. Natürlich ignoriert man da in keinem Tutorial die Vorteile, weswegen es C++ überhaupt gibt.

Die meisten propagieren das ja sogar eher. Und als Einsteiger prozedurale Programmierung und OOP gleichzeitig zu verstehen... Ist schon nicht so leicht. Da braucht man gleich nen etwas längeren Atem. Aber na gut, den braucht man wohl sowieso, wenn man ernsthaft programmieren lernen will

Prozedurale und OOP stehen nicht gegeneinander. Es ist kein Entweder-Oder, es ist grundsätzlich ein prozedural UND optional OOP. Eine Methode ist auch nur eine Funktion. Jedes Programm startet in einer static main-Funktion.

[jeanluc]

So, ich hol mal den Thread nach oben. Ich denke schon, dass es sich lohnt, würde es aber stark von der Zielsetzung abhängig machen. Einen Server z.B. würde ich eher in C schreiben. Eine Backend für eine Geschäftsapplikation in Java oder C#. Viel wichtiger für mich ist jedoch, dass ein Programmierer wartbaren Code produziert. Schließlich gibt es auch noch sowas wie Konnektoren, IPC, RPC, RFC usw. usf.

Was SAP und Java angeht: könnte sein, dass SAP davon abrückt, schließlich ist Oracle ein verhasster Konkurrent. Außerdem habe ich gelesen, dass sich IBM aus Eclipse zurückgezogen hat. Auch eine interessante Tatsache, da viele SAP Client-Applikationen auf Eclipse basieren.

Auf der anderen Seite gibt es nichts vergleichbares, denn C# auf Mono ist ... naja nicht praktikabel. Ich könnte mir aber vorstellen, dass SAP diese Mono Firma im Hintergrund aufkauft, da sie eh schon mit Microsoft kooperieren, und dann gehts ab...

[Fohlen]

Weiss nicht ob das schon genannt wurde, aber mit QT lässt sich echt ne Menge realisieren. Damit kannst du auf Windows Phone und Android rumspielen, genauso wie Distrubuted Applications (für Browser und Desktop) programmieren.

[darksider3]

Weiss nicht ob das schon genannt wurde, aber mit QT lässt sich echt ne Menge realisieren. Damit kannst du auf Windows Phone und Android rumspielen, genauso wie Distrubuted Applications (für Browser und Desktop) programmieren.

*hüstlechen* Es heißt nicht mehr Rumspielen mit Qt auf Android, es heißt nun Programmieren, denn seit Monntag/Dienstag ist das in Qt5.2 Stable geworden