C, C++, Assembler? Wiedereinstieg in die Programmierung

[motzerator]

Ich habe im Moment leider viel zu viel Freizeit und möchte nach langer Abstinenz wieder mit der Programmierung anfangen. Ich verfolge im Moment noch kein konkretes Projekt, sondern möchte mich erstmal informieren, was es heute für Möglichkeiten gibt, ich plane daher hier in absehbarer Zeit einige"dumme" Fragen zu schreiben um hoffentlich schlaue Antworten zu bekommen...

Im Moment geht es mir darum, zu klären, auf welche Programmiersprache, welche Entwicklungsumgebung und welche Librarys ich mich stürzen sollte wobei heute erstmal die Sprache das Thema ist und da vor allem die Frage: C, C++ oder Assembler


Was hab ich bisher an Programmiererfahrung:

80er Jahre: 8-Bit Basic auf Atari 800 XL, 6502 Assembler
90er Jahre: C auf dem Commodore Amiga und später Windows 3.1
00er Jahre: ein bischen HTML und Javascript

Was habe ich damit angestellt?

8-Bit: Games. Ein Kartenspiel (Full House), ein Würfelspiel, ein Ping Pong (auch für Singleplayer). Bis auf den Pingpong waren das alles basic/Assembler Kombinationen, der Ping Pong war rein in Assembler geschrieben. Sowie allerlei kleine Tools in Assembler.

Amiga, PC: Jeweils ein Fraktalprogramm (Mandelbrot/Juliamengen) mit GUI, sowie einen Bildschirmschoner.

Was denke ich über Programmiersprachen?

Basic:

+ Einfach, Logisch
- Hardwarefern, Lahm
Fazit: heute nicht mehr aktuell

Assembler:
+ Logisch, sehr schnell, Hardwarenah
- sehr aufwendig
Fazit: Find ich genial aber aufwendig

C(ohne ++)
+ Logisch, schnell, recht Hardwarenah
- weniger aufwendig
Fazit: Auch recht genial und einfacher

C++
Kenne ich nur von Windows MFC, fand ich aber immer sehr umständlich, irgendwie muss man da sehr um die Ecke denken wenn man etwas erreichen will. Scheint heute der Standard zu sein, is aber irgendwo eine saure Gurke für mich. Ich habe in den späteren 90er Jahren versucht, mich da einzulesen und immer wenn ich etwas über Programmierung lese, läuft in meinem Hinterkopf ein Film ab, was ich damit anfangen könnte. Bei C++ blieb dieser Film stumm, statt dessen kam immer ein Warnschild: "Vorsicht, das kannst Du alles auch viel bequemer erledigen".



Warum hab ich aufgehört?

Dafür gab es mehrere Gründe:

1. Gibt es heute eigentlich für fast alle Zwecke tolle Programme, alles was ich früher gebastelt habe war unter anderem auch für mich persönlich gedacht, heute googelt man einfach und findet für fast jeden Zweck eine Open Source Lösung. Als ich mal wieder mit Apfelmännchen spielen wurde, fand ich beispielsweise schnell ein Programm, mit dem man sowas heute in Echtzeit zoomen kann und das auch alle möglichen Varianten unterstützt.

2. Hat mich die MFC und das C++ schon abgeschreckt und .NET erst recht, mir reicht es schon wenn Updates dafür kommen und ewig brauchen bis die installiert sind.

3. hab ich es seit 1990 nicht mehr beruflich gebraucht, da ich seitdem im Handel tätig war.



Was möchte ich überhaupt erreichen:

1. Wieder Erfahrungen sammeln
2. Nach dem Lernen ein einfaches Game schreiben (habe schon ideen)
3. Nach dem Lernen eine Anwendung schreiben (kein konkreten Plan)
4. Das ganze neuen Wissen dann eventuell auch mal professionell nutzen.

[DIE FRAGEN] Was will ich nun wissen?

1. Auf welche Programmiersprache sollte ich mich heute konzentrieren?
(hier bitte auch Punkt 4 beachten)

Macht es noch Sinn, sich auf C ohne das ++ zu konzentrieren? Oder muss man sich heute einfach durch C++ durchqälen?

Kann man mit Assembler heute noch Punkten? 68x müsste ich erstmal
lernen, Vorkenntnisse der Konzepte sind vom 6502 sind aber immer noch
vorhanden und ich liebe die logische Struktur dieser Sprache, da weis man wengistens ganz genau, was passiert (volle Kontrolle). Oder sollte man dafür keine Zeit verschwenden, vor allem wegen der verschiedenenen Architekturen, die heute konkurrieren (Intel x86, ARM, PowerPC etc.)?

Ach ja, die Zielplattformen sollte ich noch erwähnen:

1. Windows PC
2. eventuell auch Linux PC
3. XBOX360 ??! (Soll da ja auch Möglichkeiten für Hobbyleute geben)

 

[grünel]

Die Wahl der Programmiersprache ist meiner Meinung nach einzig und allein davon abhängig, was du programmieren willst.

Professionell werden alle drei Sprachen noch eingesetzt.

Ich weiß also nicht so recht, ob man dir hier abgesehen von persönlichen Präferenzen eine Sprache "empfehlen" kann.

 

[kuddlmuddl]

Oder muss man sich heute einfach durch C++ durchqälen?

Was genau war denn so quälend? MFC?
Ich würd sagen auch C enthält schon alles "quälende" was einem in C++ begegnet. Meiner Meinung nach sogar noch viel mehr.
Was du durch ++ halt gewinnst sind so coole Sachen wie http://www.cplusplus.com/reference/stl/vector/ oder http://www.cplusplus.com/reference/algorithm/ oder http://de.wikipedia.org/wiki/Boost_(C++-Bibliothek)
In C++ kann man imho so "nett" programmieren wie in Java wenn man die anfänglichen Probleme übersteht die man als Java-Programmierer garnicht kennt. Ich würd dir allein schon wegen OOP unbedingt zu C++ raten

 

[JustAnotherTux]

Für games wir hauptsächlich C++ eingesetzt. Vielleicht versuchst du es mal mit dem neusten Standard von C++(11). Immerhin hat sich inzwischen auch bei C++ einiges getan.

Ansonsten würde ich "The C++ Programming Language " vom Erfinder von C++ Empfehlen ............eine Übersetzung ist ebenfalls vorhanden.

 

[ghozt]

ich würde unbedingt eine Objekt-orientierte Sprache wählen, also C++, C# oder Java. Zum einsteigen wäre Java oder C# wahrscheinlich einfacher.

 

[maxwell-cs]

Naja, Assembler für x86 lohnt meiner Meinung nach nur noch, wenn man in performancekritischen Anwendungen einzelne Teile beschleunigen möchte. Kaum jemand wird ne komplette Anwendung in ASM schreiben.

Ansonsten erweitert C++ im Wesentlichen C um die Funktionalität der Objektorientierung, die man nutzen kann, aber nicht muss. Der meiste valide C-Code ist auch valider C++-Code.
Die zusätzlichen Features von C++ können aber echt nützlich sein, da sollte man sich nicht prinzipiell vor weigern (z.B. templates).

 

[geisterfahrer]

Das du MFC grauenerregend fandest, kann ich nachvollziehen... Der Eindruck sollte aber nicht auf C++ abfärben. Wenn grafische Oberflächen dazu kommen sollen, empfehle ich Qt, das ist sehr logisch aufgebaut und verwendet C++-Sprachfeatures sehr konsequent.
Assembler hat auf Desktoprechnern nichts verloren! Als Schnippsel in C++ Code eingestreut ja (um bspw. explizit Befehlssatzerweiterungen ala SSE/AVX zu nutzen, wenn man rechenintensive Anwendungen schreibt), oder aber auf ganz kleinen 8bit Microcontrollern, wo das Programm aufgrund des mangelden Platzes klein genug ist, um halbwegs überssichtlich zu bleiben.
C wird insbesondere auf Microcontrollern gern eingesetzt, lohnt sich definitiv es zu beherrschen. Auf Desktoprechnern find ich es persönlich unnötig, da ist C++ erste Wahl - wobei es genügend Leute gibt die auch hier lieber C einsetzten, aber da es bei allen Features von C++ "alles kann, nichts muss" heißt, kann man fast beliebig C-ähnlich programmieren.

 

[Rob83]

C++ oder Java.
Java wenn du Multiplattform Kompatibilität willst, oder irgendwann Apps für Smartphones usw.
Vorteile hast du auch in Sachen Internet, wie Plugins für Browser - das Einsatzgebiet ist deutlich höher als bei C++

C++ eher für Heimanwendungen, Spiele ...

Ich würde sagen Java ist leichter zu lernen als C++. Es ist bischen aufgeräumter und leichter zugänglich.
Wenn ich wählen müsste, dann Java - das lernst auch in den Unis. Der Nachteil von Java ist, dass viele nicht mal wissen wie man eine .jar Datei startet. Musst also noch die exe in einer anderen Sprache programmieren um das Java Programm für den Dau zugänglich zu machen. Bischen langsamer ist es auch

 

[Grimba]

Assembler auf x86 würd ich lassen. Du hast recht, man hat volle Kontrolle und es ist schnell, aber man kommt eben damit nur langsam vorran. Es steht in keinem Verhältnis, was dir aktuelle Programmiersprachen bieten und was ein Assembler an Geschwindigkeit noch herausholt. Die aktuellen Compiler haben schon so schlaue Optimierer, da ist der Geschwindigkeitsgewinn mit Assembler vergleichsweise gering, bzw. wie mein Vorredner sagt, nur in ganz speziellen Situationen zu empfehlen.

So wie ich das lese magst du vorallem die Imperative Programmierung. Da wäre C richtig für dich und C ist auch noch lange nicht tot. Und, wenn du eh schon Assembler magst, dann wird's dich nicht stören, dass du in C auch nahezu alles per Hand machen musst (Speichermanagement etc.).

Aber, sehr richtig bemerkt, bietet die objektorientierte Programmierung sehr große Vorteile, auch wenn man zuerst anders denken muss. Der Berg sieht allerdings höher aus, als er ist. Probiert man es erstmal aus, wird einem schnell klar, dass der Film im Hinterkopf eben eine etwas andere Sichtweise haben muss, aber dann funktioniert Normal läuft das ja so ab "erst mach ich das, dann falls <x> gehe ich da und da hin, übergebe die und die werte, dann spring ich dahin, gebe das und das zurück...." bla bla Programmablauf. Bei der OOP sollte der Hinterkopf eher so aussehen "So, ich will das und das machen, dafür brauch ich folgendes... und das soll das und das können. Und das auch noch. Und dann brauch ich vielleicht noch was anderes, was ähnlich, aber nicht gleich ist usw... und dann hab ich alles, dann nehm ich meine gebauten Teile und setze sie zusammen. Dann brauch ich hier 3 von dem ersten Objekt, dann hier 35 vom anderen und die sprech ich wie folgt an...........etc etc etc." Sprich Wiederverwenden ist das Zauberwort. Und das macht den Ansatz sehr mächtig.

Von daher wären C++ oder Java definitiv einen Blick wert.

 

[vander]

die wahl der programmiersprache ist meiner meinung nach einzig und allein davon abhängig, was du programmieren willst.

Professionell werden alle drei sprachen noch eingesetzt.

Ich weiß also nicht so recht, ob man dir hier abgesehen von persönlichen präferenzen eine sprache "empfehlen" kann.

100% ack

 

[motzerator]

Zuerstmal vielen Dank für die vielen Antworten

Was genau war denn so quälend? MFC?

Schwer zu sagen, das ich mich da eingelesen habe ist über 10 Jahre her aber ich habe mich die ganze Zeit halt gefragt, warum soll ich beispielsweise extra eine Klasse ableiten, um ein Fenster aufzumachen, statt einfach die normale API Funktion zu nutzen?

Das erschien mir immer umständlich und mein Hirn ist nun mal so programmiert, das es immer den bequemsten Weg sucht.

Die einzige Idee, die ich hatte, was mir die Objektorientierung bringen könnte, waren beispielsweise Objekte in Spielen. Da macht das ja Sinn, beispielseise ein Objekt "Automobil" zu definieren und dann immer wenn man einen Wagen braucht, halt einen zu erzeugen.

Ich weiß also nicht so recht, ob man dir hier abgesehen von persönlichen Präferenzen eine Sprache "empfehlen" kann.

Die Empfehlungen bringen mir Denkanstöße und ich kann eventuell von guten/schlechten Erfahrungen profitieren und "Irrewge" vermeiden. Beispielsweise die Antwort auf die Frage, ob ich mich bei C++ einfach nur überwinden muss oder ob ich es links liegen lassen kann und mich auf Standard C beschränke, was ja quais eine Teilmenge von C++ ist.

Für games wir hauptsächlich C++ eingesetzt. Vielleicht versuchst du es mal mit dem neusten Standard von C++(11). Immerhin hat sich inzwischen auch bei C++ einiges getan.

Ja das hatte ich fast schon "befürchtet", denn zur Abbildung von virtuellen Spielobjekten macht der Objektorientierte Ansatz ja auch Sinn

ich würde unbedingt eine Objekt-orientierte Sprache wählen, also C++, C# oder Java. Zum einsteigen wäre Java oder C# wahrscheinlich einfacher.

Java habe ich hier mal aussen vor gelassen, weil ich damit in performance Sachen schlechte Erfahrungen hatte, wobei man es wieder für Android gebrauchen könnte. Aber mangels Vorkenntnissen mach ich da lieber erstmal einen Bogen drum.

Das du MFC grauenerregend fandest, kann ich nachvollziehen... Der Eindruck sollte aber nicht auf C++ abfärben. Wenn grafische Oberflächen dazu kommen sollen, empfehle ich Qt, das ist sehr logisch aufgebaut und
verwendet C++-Sprachfeatures sehr konsequent.

Ja Qt hätte sicher den Vorteil, das es sowohl unter Windows als auch unter Linux laufen würde. Das sehe ich doch richtig so, oder?

Du meinst also, die Kombination aus C++ und MFC war das Problem, nicht C++ alleine? Das könnte eine Erklärung sein, warum mir das alles so unsympathisch war.

Assembler hat auf Desktoprechnern nichts verloren! Als Schnippsel in C++ Code eingestreut ja (um bspw. explizit Befehlssatzerweiterungen ala SSE/AVX zu nutzen, wenn man rechenintensive Anwendungen schreibt), oder aber auf ganz kleinen 8bit Microcontrollern, wo das Programm aufgrund des mangelden Platzes klein genug ist, um halbwegs überssichtlich zu bleiben.

Assembler ist natürlich sehr umständlich, wenn man die meiste zeit nur API Funktionen aufruft (wobei ich mir vorstellen könnte, das hier eine gute MACRO Bibliothek viel Freude bereitet und vieles vereinfacht).

Aber das Ergebniss sind eben auch sehr kompakte Programme, die keine Runtimes brauchen und im Idealfall alles in einer Datei enthalten, also nicht mal installiert werden müssen.

Was ich an Assembler liebe ist einfach die totale Kontrolle. Nenn mir also bitte mal Gründe, warum Assembler auf einem Desktop nicht verloren hat. Vielleicht sehe ich da einige Probleme einfach nicht. Wird nicht C/C++ immer noch erst in Assembler compiliert und dann assembliert oder wird der Zwischenschritt heute übersprungen?

Ansonsten erweitert C++ im Wesentlichen C um die Funktionalität der Objektorientierung, die man nutzen kann, aber nicht muss. Der meiste valide C-Code ist auch valider C++-Code. Die zusätzlichen Features von C++ können aber echt nützlich sein, da sollte man sich nicht prinzipiell vor weigern (z.B. templates).

Das man mit C++ auch C Anwendungen schreiben kann, weis ich noch von Visual C, da musste man die MFC ja auch nicht nutzen. Ja ich muss gestehen, der Tenor hier geht ganz klar in Richtung C++. Vielleicht sollte ich mich da einfach mal reinfummeln, ohne konkretes Projekt im Hinterkopf, bis ich das Konzept richtig gut verinnerlicht habe.

Wobei mich halt auch Assembler immer noch reizt

 

[Backslash]

Wenn du Spiele programmieren willst (auch für Xbox und Windows Phone) dann ist C# + XNA der beste Einstieg.

 

[character]

Assembler kannst du vergessen. In aller Regel wird ein Compiler deutlich besseren Code produzieren als du. Von den sonstigen Nachteilen muss man ja gar nicht reden. Assembler wird nur in Ausnahmefällen zur Optimierung verwendet.

Wenn man heutzutage unter Windows modernes C programmieren will, muss man auf gcc, den Intel compiler oder andere Alternativen setzen. C wird von Microsoft extrem stiefmütterlich behandelt. Visual C++ kann nicht mal C90 gescheit, C99 und C11 werden überhaupt nicht explizit unterstützt. http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

C++ ist ein mächtiges aber irgendwie frickeliges Biest. Man merkt schon, dass es eigentlich mal komplett kompatibel zu C sein sollte. Daher ist es längst nicht so "elegant" (oder wie auch immer man das ausdrücken soll) designed wie neuere, "eigenständige" Sprachen. Es ist aber DER Standard für native Anwendungen unter Windows.

C# und Java bieten viel Komfort und sind beide weit verbreitet. Java ist schon seit Jahren nicht mehr langsam, im Gegenteil. Dass es prinzipiell langsamer als nativer Kram ist, ist zwar richtig, aber die Unterschiede sind in der Regel (anwendungsabhängig!) irrelevant. Die optimierenden JIT-Compiler funktionieren sehr gut. Natürlich kann man aber auch langsamen Mist verzapfen. Das gilt aber auch für native Sprachen.

Es gibt viele Spiele, die in C# mit XNA geschrieben wurden. Java unterstützt mehr Plattformen besser, dafür ist C# neuer und bietet einige Sprachfeatures, die Java fehlen.

Es gibt aber noch weitere Alternativen:

Python, was durch übersichtliche Syntax besticht und sehr schnell zu Ergebnissen führt. Auch hiermit sind Spiele möglich.

Dann gibt es noch andere Sprachen, die auf der JVM oder CLR laufen, z.B. Clojure oder Scala.

Google hat mit Go eine sehr interessante Sprache am Start, die sich in Zukunft bestimmt weiter verbreiten wird.

Objective-C ist bei iOS-Geräten angesagt.

Im Web-Bereich gibt es dann natürlich den Frickelklassiker PHP, aber auch Python und Ruby. JavaScript ist auch nicht mehr wegzudenken. Dank HTML5 und WebGL werden hier auch immer mehr Spiele umgesetzt.

Hier noch die Verbreitung der Sprachen: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 

[geisterfahrer]

Ja Qt hätte sicher den Vorteil, das es sowohl unter Windows als auch unter Linux laufen würde. Das sehe ich doch richtig so, oder?

Korrekt, unter Mac OS X übrigens auch.

Du meinst also, die Kombination aus C++ und MFC war das Problem, nicht C++ alleine? Das könnte eine Erklärung sein, warum mir das alles so unsympathisch war.

Genau. Ich liebe C++11, kann selber aber MFC nicht ausstehen.

Was ich an Assembler liebe ist einfach die totale Kontrolle. Nenn mir also bitte mal Gründe, warum Assembler auf einem Desktop nicht verloren hat. Vielleicht sehe ich da einige Probleme einfach nicht. Wird nicht C/C++ immer noch erst in Assembler compiliert und dann assembliert oder wird der Zwischenschritt heute übersprungen?

Assembler ist ja nun nicht viel mehr als eine Textdarstellung von Maschinencode, das einzige was da tatsächlich noch "compiliert" wird, sind Sprungmarken etc. Da C++ in Maschinencode übersetzt wird, ist der Schritt in Richtung Assembler nicht weit. Man kann zumindestens den gcc/g++ anweisen, Assembler-Code auszugeben, ist aber optional - normalerweise wird direkt der Maschinencode erzeugt.

Die Geschwindigkeitsvorteile von Assembler auf den schnellen Rechnern zu vernachlässigen sind, der C-Code aber bedeutend kürzer und damit wartbarer sind als ihre Assembler-Äquivalente

long long add(long long p1, long long p2, long long p3)
{
	return p1 + p2 + p3;
}

vs. Assembler:

add:
	pushl	%ebp
	movl	%esp, %ebp
	movl	16(%ebp), %eax
	movl	20(%ebp), %edx
	addl	8(%ebp), %eax
	adcl	12(%ebp), %edx
	addl	24(%ebp), %eax
	adcl	28(%ebp), %edx
	popl	%ebp
	ret

Zum Spaß mal mit drei unterschiedlichen Parametertypen, in C sofort ersichtlich das sich nur die Variablengrößen geändert haben, der Assembler-Code wird größer und man muss den erstmal zweimal lesen, um zu sehen, was da passiert ist (ist übrigens mit gcc -O3 -S kompiliert)...

long long add(long p1, long long p2, short p3)
{
	return p1 + p2 + p3;
}

add:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ebx
	movl	8(%ebp), %eax
	movl	%eax, %edx
	sarl	$31, %edx
	addl	12(%ebp), %eax
	adcl	16(%ebp), %edx
	movswl	20(%ebp),%ecx
	movl	%ecx, %ebx
	sarl	$31, %ebx
	addl	%ecx, %eax
	adcl	%ebx, %edx
	popl	%ebx
	popl	%ebp
	ret

Das waren jetzt nur zwei sehr triviale Beispiele, der unterschied zwischen der Codegröße zwischen Assembler und C++ nimmt bei komplexeren Programmen zu. Zudem sei gesagt, das Assembler Programme nicht automatisch schneller sind (im Gegenteil..), denn Compiler sind verdammt gut, eigentlich der bessere Assemblerprogrammierer als ein Mensch, weil er mit unübersichtlichen (aber schnellem) Code leben kann. Neue Befehlserweiterung der CPU? Heißt im Idealfall bei einem Hochsprachenprogramm nur neu compilieren und Geschwindigkeitszuwachs genießen, bei Assembler ist Hand anlegen angesagt und erstmal erweiterten Befehlssatz erlernen. Davon abgesehen ist für anderere Prozessoren dann eben auch nur neu übersetzen angesagt.

Davon abgesehen erhält man mit C/C++ Maschinencode, eine Runtime ist unnötig. Höchstens ein paar Bibliotheken die Funktionen wie printf bereitstellen sind nötig, aber nicht selten bereits beim Benutzer installiert. Bei C kann man unter Verzicht auf die Standardbibliothek auch Programme schreiben, die auch ganz ohne *.dll auskommen (was auf Desktop Systemen nicht sinnvoll ist, weil man ja irgendwie mit dem Nutzer kommunizieren will...).

 

[Falc410]

Kurz mein Senf als aktueller Informatikstudent dazu.

a) Wie viele schon bemerkt haben, wenn du ein Spiel für die Xbox 360 programmieren willst dann kommst du um C# nicht drumherum. Da du noch keine Erfahrung mit OO hast bietet sich die Sprache an. Ist einfacher als C++ (wobei das bei dir nicht der Fall sein muss wenn du noch Fit in C bist)
b) Wenn du vorhast Spiele zu programmieren, entweder Selbststaendig oder in einer kleinen Firma wird sehr wahrscheinlich kein C++ zum Einsatz kommen. Ja, PC Spiele wurden sicher in C++ geschrieben aber eine kleine Firma macht heute entweder Spiele fuer Facebook und Co, oder fuer Mobile Geraete (iOS / Android) oder vielleicht fuer die Xbox. Hier sind also C#, Java und Objective-C vertreten - alles OO.
c) Scriptsprachen sind extrem wichtig, auch als Spieleprogrammierer. Corona z.B. ist ein Framework das nur Lua Skripte benutzt und die Spiele laufen auf iOS und Android.
d) Wenn du einfach so was lernen willst, schau dir doch mal Unity an. Damit wurden auch schon viele tolle Spiele gemacht und Unity benoetigt trotzdem noch eine Programmiersprache, C#, Javascript etc.

Wenn du mit Objekt Orientierter Programmierung vertraut bist dann lernst du die Syntax von einer anderen OO Sprache in weniger als einem Tag.
C kann man immer gebrauchen, aber du wirst kaum eine Firma finden die ein grosses Projekt damit macht. Kleinere Spiele, sicher auch primaer unter Linux / Windows (mit SDL) kann man damit sicher auch machen.

Achja und in der Industrie, mal abgesehen von den Spielen, ist Java schon echt fast ueberall Pflicht. Oder eben zumindest eine OO Sprache. Viele API's koennen mit Java angesprochen werden. Ich bin kein Fan von Java aber hatte mit vmWare zu tun und auf einmal hab ich es gebraucht.

 

[Headcool]

Kurz mein Senf als aktueller Informatikstudent dazu.

a) Wie viele schon bemerkt haben, wenn du ein Spiel für die Xbox 360 programmieren willst dann kommst du um C# nicht drumherum. Da du noch keine Erfahrung mit OO hast bietet sich die Sprache an. Ist einfacher als C++ (wobei das bei dir nicht der Fall sein muss wenn du noch Fit in C bist)
b) Wenn du vorhast Spiele zu programmieren, entweder Selbststaendig oder in einer kleinen Firma wird sehr wahrscheinlich kein C++ zum Einsatz kommen. Ja, PC Spiele wurden sicher in C++ geschrieben aber eine kleine Firma macht heute entweder Spiele fuer Facebook und Co, oder fuer Mobile Geraete (iOS / Android) oder vielleicht fuer die Xbox. Hier sind also C#, Java und Objective-C vertreten - alles OO.
c) Scriptsprachen sind extrem wichtig, auch als Spieleprogrammierer. Corona z.B. ist ein Framework das nur Lua Skripte benutzt und die Spiele laufen auf iOS und Android.
d) Wenn du einfach so was lernen willst, schau dir doch mal Unity an. Damit wurden auch schon viele tolle Spiele gemacht und Unity benoetigt trotzdem noch eine Programmiersprache, C#, Javascript etc.

Wenn du mit Objekt Orientierter Programmierung vertraut bist dann lernst du die Syntax von einer anderen OO Sprache in weniger als einem Tag.
C kann man immer gebrauchen, aber du wirst kaum eine Firma finden die ein grosses Projekt damit macht. Kleinere Spiele, sicher auch primaer unter Linux / Windows (mit SDL) kann man damit sicher auch machen.

Achja und in der Industrie, mal abgesehen von den Spielen, ist Java schon echt fast ueberall Pflicht. Oder eben zumindest eine OO Sprache. Viele API's koennen mit Java angesprochen werden. Ich bin kein Fan von Java aber hatte mit vmWare zu tun und auf einmal hab ich es gebraucht.

Ich habe in diesem Forum ja schon viele dumme Sachen gelesen, aber dieser Post bringt das ganze auf einen ganz neuen Level. Dafür musste ich mich einfach registrieren.

Deine Sichtweise ist ganz typisch für die neue Generation von Informatikern die keine Ahnung von richtiger Programmierung haben aber trotzdem denken sie wären die Besten.

Es stimmt das Java weit verbreitet ist. Es ist allerdings Quatsch dass es schon fast Pflicht außerhalb der Spieleprogrammierung ist.
Die meisten Anwendungen werden weiterhin in nativen Sprachen geschrieben. Wenn ich so überlege wieviele Java-Programme ich auf meinem Computer installiert habe, dann bemerke ich, dass es nur 2 sind(jDownloader & Minecraft). Ausgerechnet zwei Programme denen man anmerkt, dass sie in Java geschrieben wurden, weil sie langsam sind wie Sau.

Außerdem beschränkst du dein Sichtfeld nur auf den Desktop- und Mobile-Bereich.
Was ist mit dem Embedded-Bereich? Ein normaler Mensch hat vielleicht 2 Geräte der Klasse PC/Notebook/Tablet/Smartphone. Aber wieviele Geräte hat er die der Embedded-Klasse angehört? Ein Auto, einen Fernseher, ein Router/Modem, eine Mikrowelle, eine elektrische Zahnbürste, etc, etc, etc. Auf jeden Fall wesentlich mehr. Mit wesentlich mehr Gesamtperformance, mehr Codezeilen, etc.

Ein Großteil der Welt läuft auf sehr, sehr altem Code. Zb. lief 1997 noch 80% der finanziellen Berechnungen auf 200 Milliarden Zeilen COBOL-Code. Und die Zahl der COBOL-Code-Zeilen stieg noch um 5 Milliarden pro Jahr.
Diese Sprache war zu diesem Zeitpunkt 48 Jahre alt. Trotzdem wurde und wird sie noch verwendet.
Ähnlich ist es mit der Sprache Fortran, die heute noch im Großteil der wissenschaftlichen Simulationen verwendet wird.
Das interessante daran ist, dass die Programmierer dieser alten Sprachen immer älter werden und in Pension gehen. Der Code ist noch da und muss gewartet/portiert werden.
Dummerweise lehrt man in den Unis eher Sprachen wie C, Java, Haskell, etc.
D.h. es gibt ein Angebot/Nachfrage-Problem und folgendlich steigt das Gehalt der Informatiker die sich in diesem Bereich ansiedeln.
Im Gegensatz dazu gibts Sprachen wie Java, C#, etc. Diese Sprachen sind ziemlich einfach sodass jeder Depp mit dem geeigneten Tool Anwendungen zusammenklicken kann ohne den Hintegrund der Sprache zu kennen. Ich frage mich wieviel Prozent der C#-Programmierer jede Zeile des Codes erklären kann, die Visual Studio generiert, wenn man ein neues Projekt erstellt. Der Großteil wird keine Ahnung haben. Im Gegensatz zu den meisten nativen Sprachen, wo man sich zuerst mal damit beschäftigen muss, weil man sonst nicht weiß wie es funktioniert.
Desweiteren zuzüglich zur Einfachheit dieser Sprachen sind sie auch ziemlich populär. Aus diesen zwei Gründen gibt es sehr viele Java- und C#- Programmierer. Das bewirkt ein weiteres Angebot/Nachfrage-Problem. Allerdings in die andere Richtung. Das Gehalt ist also niedriger anzusetzen.
Desweiteren ist ein Java-Programmierer(der weit weniger wissen muss als bspw. ein C++ Programmierer)leichter ersetzbar. Beispielweise durch einen Inder der viel weniger kostet, aber fast genauso gut programmiert. Nachzulesen hier:

In essence, he said that today’s Java-savvy college grad is tomorrow’s pizza delivery man. Their skills are so easily outsourced that they’re heading for near-term obsolescence.

@Threadersteller
Meine Empfehlung ist, dass du dir mal C++ anschaust, am besten mit dem Einstiegsbuch von Stroustrup. Danach am besten Qt. Damit bist du schon voll gerüstet für klassische Desktopapplikationen. Wenn du dann Richtung Spieleprogrammierung willst schaust du dir OpenGL an.
Alternativ schlägst du nach C++ das .net-Kapitel mit C++/CLI(welches trotz .net noch Faktor 2 schneller als C# oder VB ist) an. Allerdings musst du dann die Linux-Kompatibilität saußen lassen.
Die Idee mit der XBox würde ich erst mal auf Eis legen. Bis du soweit bist, gibts schon die nächste und wer weiß wie offen die ist. Eventuell wirst da dafür gar nicht programmieren können da sie vollständig geschlossen ist, eventuell wird sie wesentlich offener und du kannst dort Direct3d11 bzw. den Nachfolger benützen.

 

[Backslash]

(...) Ausgerechnet zwei Programme denen man anmerkt, dass sie in Java geschrieben wurden, weil sie langsam sind wie Sau. (...)

Allein mit diesem Satz hast du dich schon disqualifiziert. Wenn du auch nur halb so viel Ahnung hättest wie du behauptest würdest du die Performance dieser Programme nicht auf die Programmiersprache zurückführen.

Auch für die Aussage, dass C++/CLI "Faktor 2 schneller als C#" ist würde ich gerne deine Quelle sehen.

PS: Man wird mit Sicherheit weiterhin mit C# für die XBox programmieren können.
Dass die Entwicklung bei Spielen stark in Richtung Mobile/Browsergames geht kannst du übrigens zum Beispiel daran sehen wo der Fokus der GDC lag.

 

[Falc410]

@Headcool: Ich habe niemals behauptet das in Zukunft alle Programme mit Java geschrieben werden, und das glaube ich auch nicht.
Ich habe hier von Schnittstellen geredet, oder Webapplikationen (sagt dir GWT was?).

Natuerlich laeuft auf einem Embedded System kein Java, und ja davon gibt es einige. Aber der Threadersteller wollte sich weiterbilden und etwas *neues* lernen - oder habe ich das falsch verstanden?

Und um meine Aussage mal zu unterstreichen, siehe dieser Link hier:
http://spectrum.ieee.org/at-work/tech-careers/the-top-10-programming-languages

Was steht da im Bild als erstes? Custom applications for businesses - Java....soso. Genau das deckt sich mit meiner persoenlichen Erfahrung. Mir ist schon klar das der Tiobe Index zur Zeit C an Stelle 1 listet: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Aber was kommt direkt dahinter?

Fakt ist das man mindestens eine Objekt Orientierte Sprache bzw. das Konzept koennen sollte. Du wirst wahrscheinlich nicht das Glueck haben nur Zahnbuersten oder Aufzuege zu programmieren.

Aber wie Backslash sowieso schon bemerkt hast, hast du dich eh selbst disqualifiziert. Obwohl einige deiner Aussagen ansonsten sicher korrekt sind.

 

[Headcool]

Allein mit diesem Satz hast du dich schon disqualifiziert. Wenn du auch nur halb so viel Ahnung hättest wie du behauptest würdest du die Performance dieser Programme nicht auf die Programmiersprache zurückführen.

Auch für die Aussage, dass C++/CLI "Faktor 2 schneller als C#" ist würde ich gerne deine Quelle sehen.

PS: Man wird mit Sicherheit weiterhin mit C# für die XBox programmieren können.
Dass die Entwicklung bei Spielen stark in Richtung Mobile/Browsergames geht kannst du übrigens zum Beispiel daran sehen wo der Fokus der GDC lag.

1. Die Performance dieser Programme ist nicht nur auf Java zurückzuführen, aber zumindest teilweise.
a) Wenn ich beim JDownloader vom "Einstellungen"-Tab auf den "Linksammler"-Tab bzw. den "Download"-Tab wechsle, dann sehe ich diesen Windows 7 "Wartekreis". Das darf einfach nicht passieren. Schon allein deswegen nicht, weil der Jdownloader ein recht kleines Programm ist. Wenn das bei einem Browser so wäre, dann käme das einem Todesurteil gleich.
Verantwortlich für dieses Problem ist ganz klar die GUI. Diese ist nunmal in Java geschrieben.

b) Minecraft ist aus mehreren Gründen langsam.
Der wohl wichtigste ist, dass Notch einfach keinen Plan von Grafikprogrammierung hat.
Ein 60MB Texturpaket hat zur Folge, dass Minecraft 1-2GB mehr an RAM frisst. Ein normale Reaktion wäre ein zusätzlich VRAM-Verbrauch von 60MB(80MB mit MipMapping)
Desweiteren gibt es da noch ein Technik namens Instancing mit der das Zeichnen von gleichen Meshes erheblich weniger Zeit kostet. Da fast ganz Minecraft aus den gleichen Meshes besteht wäre es eine super Idee diese Technik auch zu verwenden. Tut Notch aber nicht, stattdessen verwendet er eine API namens OpenGL 1.2, welche aus dem Jahre 1998 stammmt, die natürlich nichts kann.
Aber auch Java ist ganz klar ein Grund. Vor allem geht es da um den Garbage Collector. Bei Spielen fällt in jedem Frame eine Menge an Speichermüll an, der beseitigt werden müsste. Irgendwann nachdem sich eine Menge von dem Zeug angesammelt hat fährt der Garbage Collector drüber und verbraucht eine Menge an Performance. Dieses Verhalten führt dann zu Spitzen in der Auslastung. Egal wie es mit den FPS sonst so aussieht, diese Spitze wird zum Flaschenhals der Applikation.

2. Ich habe jetzt dafür keine Quelle da, aber primär liegt dieser große Performance-Unterschied an der Optimierung des Compilers. Ich spreche nicht vom JIT-Compiler, sondern vom C++/CLI-->CIL-Compiler. Dieser optimiert wesentlich besser im Bereich von Codegröße, sodass weniger Cache-Misses entstehen und der JIT-Compiler mehr der kürzeren Funktionen inlinen kann.
Wenn du das nachtesten willst, beachte bitte ein Projekt geeigneter Größe dafür zu wählen. Je kleiner ein Projekt ist, desto extremer fallen die Ergebnisse in beiden Richtungen aus, da so ein Projekt ziemlich einseitig ist.

3. Es treiben sich schlimme Gerüchte bezüglich Onlinezwang und ähnlichem für die nächste Xbox herum. Falls sich dieses Gerücht bestätigt, hat dies weitere Einschränkung bezüglich der Offenheit des Gesamtsystems zur Folge, um diesen Schutz vor der Umgehung zu schützen.

4. Es stimmt, dass es einen Trend zu "Mobile"- und Browsergames geht. Allerdings ist dieser Trend extreme Plattform abhängig. So geht der Trend auf den stationären Konsolen momentan eher in die Richtung "Steam-like" & Multiplayer. Soll heißen digitaler Kauf, online-Savegames, etc. Aber trotzdem noch die typischen AAA-Titel ala Skyrim, BF 3, CoD:MW3, etc.

@Headcool: Ich habe niemals behauptet das in Zukunft alle Programme mit Java geschrieben werden, und das glaube ich auch nicht.
Ich habe hier von Schnittstellen geredet, oder Webapplikationen (sagt dir GWT was?).

Natuerlich laeuft auf einem Embedded System kein Java, und ja davon gibt es einige. Aber der Threadersteller wollte sich weiterbilden und etwas *neues* lernen - oder habe ich das falsch verstanden?

Und um meine Aussage mal zu unterstreichen, siehe dieser Link hier:
http://spectrum.ieee.org/at-work/tech-careers/the-top-10-programming-languages

Was steht da im Bild als erstes? Custom applications for businesses - Java....soso. Genau das deckt sich mit meiner persoenlichen Erfahrung. Mir ist schon klar das der Tiobe Index zur Zeit C an Stelle 1 listet: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Aber was kommt direkt dahinter?

Fakt ist das man mindestens eine Objekt Orientierte Sprache bzw. das Konzept koennen sollte. Du wirst wahrscheinlich nicht das Glueck haben nur Zahnbuersten oder Aufzuege zu programmieren.

Aber wie Backslash sowieso schon bemerkt hast, hast du dich eh selbst disqualifiziert. Obwohl einige deiner Aussagen ansonsten sicher korrekt sind.

5. Du hast nur von Schnittstellen und Webapplikationen geredet?

Achja und in der Industrie, mal abgesehen von den Spielen, ist Java schon echt fast ueberall Pflicht.

Hört sich für mich ziemlich allgemein an.

6. Stimmt auch nicht. Es gibt einige Java-JIT-Prozessoren. Jedoch sind diese nicht sehr beliebt.
Desweiteren kann auch der TE im Embedded-Bereich noch viel neues lernen. Hardware-Beschreibungssprachen wie VHDL oder Verilog wären da zu nennen. Dann kann er auf einem kleinen FPGA + Entwicklungsboard die Sau rauslassen.

7. Das Java eine wichtige Rolle spielt habe ich nie bestritten. Bestritten habe ich die Aussage, dass man für fast jede Stelle Java braucht. Und wenn du auf den ganz rechten Balken deiner netten Grafik schaust siehst du dass Java mit 9% nicht weltbewegend abschneidet.

8. Natürlich sollte man eine OO-Sprache lernen. Da bietet sich für den TE C++ gerade so an. Erfahrung in C schon vorhanden. Die Assembler-Kenntnisse können beim Debuggen auch enorm weiterhelfen. Mit C & Assembler scheint sich der TE im nativen Bereich, der zugegeben mehr Stolpersteine besitzt, ziemlich wohlzufühlen.

9. Backslash hat leider keine Begründung dafür eingebracht wieso er denkt, dass Java nicht Schuld für die schlechte Performance von Minecraft bzw. Jdownloader ist. Somit kann ich ihn (noch) nicht ernst nehmen.

 

[Backslash]

(...)

2. Ich habe jetzt dafür keine Quelle da, aber primär liegt dieser große Performance-Unterschied an der Optimierung des Compilers. Ich spreche nicht vom JIT-Compiler, sondern vom C++/CLI-->CIL-Compiler. Dieser optimiert wesentlich besser im Bereich von Codegröße, sodass weniger Cache-Misses entstehen und der JIT-Compiler mehr der kürzeren Funktionen inlinen kann.
Wenn du das nachtesten willst, beachte bitte ein Projekt geeigneter Größe dafür zu wählen. Je kleiner ein Projekt ist, desto extremer fallen die Ergebnisse in beiden Richtungen aus, da so ein Projekt ziemlich einseitig ist.

(...)

Dann wird es aber schwierig ein geeignetes Projekt zu finden, da es sich um ein größeres Projekt handeln müsste, bei dem die gleichen Algorithmen in der Syntax der jew. Sprache formuliert werden, was es so vermutlich nicht gibt. Damit lässt sich die Behauptung wohl leider nicht wirklich belegen. Ich glaube nicht, dass C++/CLI deutlich langsamer als C# ist, wenn es dafür einen vernünftigen Test gibt lasse ich mich gerne vom Gegenteil überzeugen.

Davon völlig unabhängig ist die Performance allerdings für den hier gesuchten Zweck sowieso irrelevant, weshalb der TE einfach mit irgendeiner Sprache seiner Wahl anfangen sollte, eine weitere zu lernen fällt dann auf jeden Fall viel leichter.

Ich persönlich finde für den Einstieg Python gut, eignet sich zusammen mit Blender auch für Spieleprogrammierung. Andere werden eher zu Java und wieder andere zu C#, C++ oder gar C raten.
Abraten würde ich von Assembler als Einstieg, ansonsten ist es eigentlich wirklich egal. Such dir eine Sprache aus, bei der dir die Syntax gefällt und fang' an kleine Projekte damit zu realisieren. Um dir keinen schlechten Stil anzugewöhnen, der später ein Hindernis sein kann, nimm ein gutes Buch dazu. Mehr braucht man meiner Meinung nach nicht, um in die Welt des Programmierens (wieder-) einzusteigen.
Für Microsoft-Plattformen gibt es das schon erwähnte C# + XNA mit der kostenlosen IDE Visual Studio Express.

PS: Falls du C++ wählst, beginne mit reinen Kommandozeilenprogrammen bis du die Grundlagen alle beherrscht und schau' dir dann entweder für "normale" GUIs Qt oder für Spiele SDL (und später OpenGL) an.
Für Konsolenanwendungen mit etwas erweiterten Interfaces ist auch ncurses interessant, damit kann man sehr leicht Fensterartiges oder kleine Spiele umsetzen.