C# oder C++?

[Grimba]

Wem C++ "zu nah am Blech" vorkommt, der kann sich das Leben aber auch mit Frameworks wie Qt vereinfachen, die die C++ Basis noch einmal ordentlich aufbohren. Damit kann man auch effektiv Probleme lösen und Projekte einfach umsetzen

 

[Nur_Momo]

Such dir Aufgaben, programmiere diese und benutze Google dabei. Das ist mein Tipp an dich

greetz
hroessler

Ich kann definitiv diesen Kurs empfehlen:
https://www.youtube.com/playlist?list=PLIMrZfX3DMVF7nLENd7R5HYFKJJBk2jZ7

Hier lernst du neben C# wichtige OO Konzepte und außerdem einigermaßen guten Code zu schreiben. Übungen (z.B. 4 Gewinnt) gibts oben drauf.

Die Tipps nehme ich zum Herzen. Danke.

 

[itdummy]

Ist es nicht erst einmal ausreichend komplex eine Sprache zu lernen?

Nun ja das kommt ganz auf den Anwendungsfall an. Will man z.B. ein klassisches Backend/FrontEnd entwickeln, wie zum Beispiel mit .NET in Verbindung mit Angular, so macht es Sinn sich beides parallel anzuschauen um evtl. Abhängigkeiten schon vor/während der Implementierung zu beachten.
Prinzipiell kommt es auch auf die verfügbare Zeit an.

 

[psYcho-edgE]

Wolltest du TS statt JS schreiben, dann stimmt es wohl.

My bad. Danke.

Wobei TS ja nur ein Superset zu JS mit Typisierung und diversen anderen Möglichkeiten wie Interfaces und Namespacing ist. Die Syntax bleibt größtenteils die gleiche.

 

[new Account()]

@Grimba Lass ihn doch erstmal eine Sprache lernen, dann kann er immer noch Frameworks aufgreifen.

Und dafür empfehle ich erst einmal C#, weil die Sprache einfacher ist und zu 99% genauso ans Ziel führt. Zudem ist es deutlich einfacher sich wichtige Konzepte anzueignen, was viel wichtiger als die Programmiersprache selbst ist.
Mit den Konzepten und dem Wissen vom Lernen von C#, ist imho C++ dann eine geeignete Herausforderung, da man weiß was man machen will und dann es deutlich einfacher hat aus den 1000en Möglichkeiten in C++ auszuwählen und sinnvollen Code zu schreiben.

Will man z.B. ein klassisches Backend/FrontEnd entwickeln, wie zum Beispiel mit .NET in Verbindung mit Angular, so macht es Sinn sich beides parallel anzuschauen um evtl. Abhängigkeiten schon vor/während der Implementierung zu beachten.

Für einen fortgeschrittenen Programmierer mag das ein Weg sein, aber für einen mehr oder weniger Anfänger (v.a. in Objektorientierung) sehe ich hier ganz klar sehr schnell planlose Überforderung.
Mit wenig Ahnung mehrere Programmiersprachen inkl. Frameworks und konzepte zusammenzuführen stelle ich mir als riesiges Chaos vor.

 

[uburoi]

Ich würde mir erstmal ein konkretes Projekt suchen und dann mit einer geeigneten Programmiersprache anfangen. Wichtig ist, grundlegende Konzepte und Algorithmen zu verinnerlichen und erstmal die Möglichkeiten einer Sprache auszureizen. Wenn man das in einer Sprache gemeistert hat, ist es nicht allzu schwierig, sich in weitere Programmiersprachen einzuarbeiten. (Eine Programmiersprache ist ja letztlich nur ein Werkzeug zur Lösung von Problemen und sollte am Ende des Weges nicht mehr das Problem selbst sein.)

Gruß Jens

 

[_Reaper]

@Nur_Momo Aber stimmt schon was manche hier schreiben, lern erstmal nur C# (und zwar richtig^^). Da hast du erstmal genug zu tun. Was du danach lernst ist egal. Auf jeden fall wird die zweite Sprache leichter.

Programmiersprachen unterscheiden sich oft nur oberflächlich und setzen die selben Konzepte auf anderen Wegen um.

 

[dr. lele]

@Nur_Momo Und wenn Du mal mit Spielentwicklung anfängst mach dir vorher klar ob Du ein Spiel oder eine Engine entwickeln willst

Für kleine Spieleprojekte führt meiner Meinung nach wenig an Unity vorbei und da bist du mit C#-Kenntnissen super vorbereitet.

 

[Nur_Momo]

Supi. Vielen dank für die vielen und hilfreichen Kommentaren!

 

[Stuffz]

C# würde ich zuerst "lernen", wenn man das Wissen später für JS recyclen will. Weil sich die Syntax von so manchen Sprachkonstrukten ähnelt (Func-Generics z.B.).
C++ würde ich zuerst lernen, wenn man nebenher etwas Verständnis über die Materie drunter (Sprich: C, Assembler) aufbauen will und man generell eine disziplinierte Arbeitsweise an den Tag legt (da gibt es idR. keinen GC, der hinter einem ständig den Müll aufräumt).

Generell eignet sich C# besser für komplexere Probleme, wo man auf viele/diverse Datenmengen zugreifen muss - da kann man sich mit diversen abkzürzungen (ggf. mit eigenen Extension-Methoden) schnell durchwurschteln, während man in C++ für ähnliche Problemstellungen sich den Wolf schreibt. Auch die Performance kann dabei besser sein (mit Generator/Iterator) in Vergleich zu ähnlich groß geratenen C++-Lösungen (auch diese kann man auf Generator/Iterator ummünzen, aber eben umständlicher/fehlerträchtiger).

Andererseits legt C# (bzw. generell .NET) auch oft Steine in den Weg, z.B. bzgl. Portierbarkeit (oder gibt es inzwischen .Net-Core für Raspi?), bzgl. Speicherverbrauch (string-Daten fressen tlw. extrem viel), bzgl. Laufzeit-Verhalten (ruckelnde UIs dank der Eingriffe vom GC).

 

[Grimba]

@Grimba Lass ihn doch erstmal eine Sprache lernen, dann kann er immer noch Frameworks aufgreifen.

Ein Framework ist auch nur eine Sprache, die auf einer vorhandenen aufbaut und sie erweitert. Muss ja alles durch den gleichen Compiler hinterher. Aber ich weiß, was du meinst. Ich bin hier nicht so ganz deiner Meinung, aber diese Diskussion führt zu sehr ins Offtopic. C# ist sicher nicht verkehrt. Ich schmeiße hier noch Java in den Raum, um grundlegende Objektorientierte Konzepte zu begreifen.

 

[new Account()]

C++ würde ich zuerst lernen, wenn man nebenher etwas Verständnis über die Materie drunter (Sprich: C, Assembler) aufbauen will und man generell eine disziplinierte Arbeitsweise an den Tag legt (da gibt es idR. keinen GC, der hinter einem ständig den Müll aufräumt).

Wenn man was über die Materie darunter lernen möchte (sprich: c, assembler) sollte man auch C und assembler verwenden und nicht C++ missbrauchen. In C++ wird einem auch der Müll weggeräumt, wenn man C++ programmiert wie es gedacht ist (sh. z.B. Herb Sutter oder Bjarne Stroustrup, RAII und smart pointers ftw).
Imho führen solche Ratschläge nur zu schlechtem C++ Code.

Zumal das Disasembling, auf welches in der Videoserie von @The Ripper sogar eingegangen wird, auch einen gewissen Einblick in das Prinzip des Assembler gibt.

Andererseits legt C# (bzw. generell .NET) auch oft Steine in den Weg, z.B. bzgl. Portierbarkeit (oder gibt es inzwischen .Net-Core für Raspi?),

.NET Core ist Cross Platform, und ich glaube die GUI Frameworks wie WPF sind in .NET Core 3 integriert, daher gehört das wohl der Vergangenheit an.

 

[psYcho-edgE]

Eher untypisierter Mist

Mag sein, z.T. ist untypisiertes Programmieren auch sehr praktisch. Man muss halt nur wissen, wie verschiedene Typen dann interpretiert werden und ggf. explizit casten (was man ja auch bei typisierten Sprachen müsste).

Und wer will kann auch einfach TypeScript oder die Flow-Library von Facebook nutzen, dann ist Typisierung ohne Probleme nutzbar.

 

[memmex]

Ich kann @uburoi zustimmen. Überall liest man Fragen, welche Programmiersprache man lernen solle.
Ich würde sagen, dass es irrelevant ist. Viel wichtiger sind die dahinterliegenden Konzepte und die Algorithmik. Ein gutes Programm besteht aus zwei Teilen: der Idee/die Modellierung und das Umsetzen dieses "Plans" in einer Programmiersprache.
Zur Anwendung sind die Standardbeispiele C als imperative Programmiersprache, Java als objektorientierte und Haskell als funktionale Programmiersprache.

Ich bin kein Fan, einfach irgendwelche Tutorials von Youtube zu schauen und Programmtext abzutippen. Meist kommt der grundlegende Aspekt des Modellierens oder das Sprachparadigma viel zu kurz.

Wie häufig habe ich Java-Programme bestehend aus static-Klassen gesehen. Leider wurde dabei die Objektorientierung nicht verstanden.

Eigentlich kann man Programmieren auch nur mit Pseudocode lernen, was aber etwas trocken sein mag.

Wenn man einmal die objektiorientierte Programmierung verstanden hat, ist das Umlernen von Java auf C# keine große Herausforderung.

Ich würde mir wirklich ein Buch kaufen und von Grund auf "das Denken des Programmierens" lernen anstatt nur Codebauchsteine aus Stackoverflow und Youtube zusammenzuschustern.

 

[TopperHarley87]

Ich würde am Anfang C# empfehlen. Hat mMn den großen Vorteil, dass du Visual Studio installierst und alles komplett eingerichtet ist. Du kannst also direkt dein erstes kleines HalloWelt-Programm schreiben, F5 drücken und es läuft. Du sparst dir so erstmal das ganze Drumherum und kannst dich auf das Programmieren bzw. die Sprache konzentrieren. In C# kann man zudem sehr leicht Anwendungen mit GUIs erstellen. Ich habe die Erfahrung gemacht, dass gerade Anfänger sehr schnell das Interesse verlieren, wenn sie nur weißen Text auf schwarzem Grund erzeugen...^^

 

[Stuffz]

Wenn man was über die Materie darunter lernen möchte (sprich: c, assembler) sollte man auch C und assembler verwenden und nicht C++ missbrauchen. In C++ wird einem auch der Müll weggeräumt, wenn man C++ programmiert wie es gedacht ist (sh. z.B. Herb Sutter oder Bjarne Stroustrup, RAII und smart pointers ftw).
Imho führen solche Ratschläge nur zu schlechtem C++ Code.

Zumal das Disasembling, auf welches in der Videoserie von @The Ripper sogar eingegangen wird, auch einen gewissen Einblick in das Prinzip des Assembler gibt.

Jein. RAII und smart_pointer sind Segen und Fluch zugleich. Zum einen sind sie ein Vorteil von C++ und eigentlich sind zuverlässige Destruktoren generell ein Vorteil von C++, in C# hat man's nur mittels einer Krücke nachgebaut (IDisposable). Zum anderen wird die Ausführungszeit und gewisse Randaspekte damit schon prinzipbedingt festgezurrt - und im Nachhinein muss man sich Krücken bauen, um die Nebenwirkungen im Design abzumildern (weak_ptr "ftw").

.NET Core ist Cross Platform, und ich glaube die GUI Frameworks wie WPF sind in .NET Core 3 integriert, daher gehört das wohl der Vergangenheit an.

Ja, ja. Und was hilft mir das, wenn eine brauchbare Runtime für eine CPU (z.B. Mono für aarch64) erst Jahre später erscheint, wenn überhaupt?

PS: eins noch, Laufzeitkosten nicht vergessen. Für eine mikrige Anwendung (z.B. 4kb eff. Code) erst mal 40MB runtime laden, ist bei embedded-Dingen einfach Mist.

 

[LukS]

Ich hab damals in der Schule(HTL) im ersten Jahr die Programmiergrundlagen (funktionale Programmierung) mit C und Assembler gelernt. Dann kam C++ und im darauf folgenden Jahr Java. Erst Anschließend hab ich die letzten beiden Jahre C# mit Objektorientierter Programmierung gelernt. Das ganze ist aber schon über 15 Jahre her...

Viel wichtiger als die Sprache, ist es den Algorithmus schon vorher zu verstehen. Sprich du musst zuerst wissen was du machen willst und erst dann Programmieren. Also wäre es erstmals gut die Grundlagen (funktionale bzw. Objektorientiere Programmierung) zu verstehen und dann deine Programmabfolgen in einem Pseudocode zu schreiben.
Von der Syntax sind alle Sprachen recht ähnlich und der Umstieg von einer zur andern sollte relativ leicht und schnell gehen.

 

[new Account()]

PS: eins noch, Laufzeitkosten nicht vergessen. Für eine mikrige Anwendung (z.B. 4kb eff. Code) erst mal 40MB runtime laden, ist bei embedded-Dingen einfach Mist.

Wusste garnicht, dass der TE an embedded systems interessiert ist.

Inwiefern sind RAII und smart pointer Fluch? Was ist festgezurrt? Der Zeitpunkt der Deallokierung?

@itdummy Als nicht Rust-Programmierer glaube ich, dass Rust genau auf die Prinzipien setzt?

 

[itdummy]

Wusste garnicht, dass der TE an embedded systems interessiert ist.

Inwiefern sind RAII und smart pointer Fluch? Was ist festgezurrt? Der Zeitpunkt der Deallokierung?

Da schmeiß ich doch gleich mal Rust als neue zu lernende Programmiersprache in den Raum *Ironie off*

 

[Stuffz]

Wusste garnicht, dass der TE an embedded systems interessiert ist.

Inwiefern sind RAII und smart pointer Fluch? Was ist festgezurrt? Der Zeitpunkt der Deallokierung?

Die Tatsache, dass man unter Umständen einen smarten Zeiger in "falsche" Hände gibt. Und dass der dtor dann unter zeitlich ungünstigen Bedingungen ausgeführt wird. Und dass Destructoren, die damit mit ausgelöst werden, eben weiteren Code enthalten und evtl. noch weitere Sonderverhalten auslösen. Bei einer komplexeren Architektur, mit viel Nebenläufigkeit, hat man damit unter Umständen einigen "Spaß". Ist alles nicht unlösbar, aber dann diktiert teilweise die Programmiersprache das Design, was nicht so schön ist.

Edith: s/ctor/dtor/ (oops...)