Was jetzt nach C und C++?
-
Kingruedi hat prinzipiell Recht, die Realität sieht aber noch anders aus. Vielleicht ist C# und .NET die richtige Zukunftsorientierung, so eine Art Mix aus Java und MicroSoft Overkill.
-
Ich würde mir die WinAPI nicht mehr anschauen, die liegt im Sterben. Vielleicht macht sie noch für C++ eine Zeit lang ein bisschen Sinn, aber das war's dann.
@Shade: Ich halte mehr davon, sich erstmal mehrere Sprachen anzuschauen, speziell auch auf verschiedenen Abstraktionsebenen. Assembler und Java, um mal wirklich alles gesehen zu haben. Danach kann man sich ja eine oder zwei Sprachen raussuchen und sich dort reinsteigern.
-
Assembler (nur zum Spaß), C++ (richtig), WinAPI (Prinzip) und Java (richtig), das wäre mein Tipp. Hängt aber stark von der zukünftigen Ausrichtung ab. Wer z.B. Game-Programming machen will, sollte C++, WinAPI und DirectX bzw. OpenGL beherrschen. Wer Mikroprozessoren programmieren will, sollte Assembler, C und C++ kennen. etc.
-
@Erhard
deine Empfehlungen sind zu allgemein. Es ist wichtiger, dass man sich ein Verständniss fürs Programmieren aufbaut.Was da zB. die WinAPI soll versteh ich nicht. Die API ist (selbst nach Aussagen von MS) veraltet und einen schönen Programmierstil lernt man durch die WinAPI erst recht nicht. Also lieber gleich von der Liste streichen und nur lernen, wenn man es wirklich muss (also jemand mit Scheinen winkt ;)). Sich auf APIs festzulegen ist eine schlechte Idee. APIs kommen APIs gehen...
Und direkt nach dem man C++ gelernt hat, Java zu lernen finde ich auch nicht so sinnvoll. Man lernt dadurch kein besseres Verständniss vom Programmieren. Java kann man auch dann später mal lernen, wenn man nichts zu tun hat oder jemand mit dicken Scheinen winkt.
Assembler halte ich da für Sinnvoller, da man ein grundlegendes Gefühl für Computer-Architekturen gewinnt. Und so Sprachen wie Lisp, Prolog etc. haben vielleicht keinen direkten Nutzen, wenn man sich um einen Job bewirbt, aber bringen einem eine Menge Know-How und neue Blickwinkel, was einem enorm hilft, wenn man zB. Software designt.
-
kingruedi schrieb:
Was da zB. die WinAPI soll versteh ich nicht. Die API ist (selbst nach Aussagen von MS) veraltet und einen schönen Programmierstil lernt man durch die WinAPI erst recht nicht. Also lieber gleich von der Liste streichen und nur lernen, wenn man es wirklich muss (also jemand mit Scheinen winkt ;)). Sich auf APIs festzulegen ist eine schlechte Idee. APIs kommen APIs gehen...
Verstehe ich nicht. *So* schnell ist die WinAPI auch nicht veraltet (jedenfalls hat man noch Zeit, ein paar Grundzüge zu lernen) und man lernt dadurch, auch mit krepligen C-APIs umzugehen. Da ist die WinAPI ja bei weitem nicht die einzige auf der Welt.
-
Ohne WinAPI kommt man aber im Moment noch nicht aus. In C# und Visual Basic etc. brauch man sie auch immer wieder.
-
... schrieb:
Ohne WinAPI kommt man aber im Moment noch nicht aus. In C# und Visual Basic etc. brauch man sie auch immer wieder.
Es gibt auch noch interessante Bereiche jenseits von M$
Zum Thema. Ich bin ebenfalls wie einige Andere hier auch der Meinung dass man mal in verschiedene Sprachen reinschnuppern sollte. Er hat sich nun ne prozedurale Sprache und ne Objektorientierte angeschaut. Da wirds doch evtl. Zeit für was Funktionales oder Imperatives. Eben neue Konzepte und neue Wege.
Assembler ist ne feine Sache um eine tieferes Verständnis für die Funktionsweise des Rechenknechts zu gewinnen. Einfach mal alles anschauen.
Und wenn er sich mal mit allem so ein bisschen beschäftigt hat, bleibt ja noch Brainfuck
-
prolog schrieb:
Und wenn er sich mal mit allem so ein bisschen beschäftigt hat, bleibt ja noch Brainfuck
wobei ich auch nur betonen kann, dass ich BrainFuck jedem Programmierer nur empfehlen kann. Das bringt einem irgend wie ein gewisses Verständniss
-
kingruedi schrieb:
Assembler halte ich da für Sinnvoller, da man ein grundlegendes Gefühl für Computer-Architekturen gewinnt.
Das Argument habe ich ehrlich gesagt noch nie verstanden. Warum sollte man etwas über "Computer-Architekturen" erfahren, wenn man einen Assembler lernt. Wo wird man denn da zum Beispiel mit Dingen wie Pipelining oder der Funktionsweise eines Caches konfrontiert? Naja, vielleicht habe ich mich bisher auch einfach nur zu wenig mit Assembler auseinandergesetzt, um das zu sehen. Ich bin mal auf die Erklärung gespannt.
-
Konzepte und grundlegendes Verständnis ist wichtig. Daher halte ich es immer noch für wichtig, den inneren Ablauf einer klassischen Windows-Anwendung (Nachrichtenerzeugung, Nachrichtenpumpe und -Schlange, Reaktionen auf Nachrichten) zu verstehen, denn das ist bei MFC oder auch bei Java bzw. C# das gleiche System, sobald man es mit Mausklicks zu schaffen hat. Vielleicht kann man Assembler und Windows kombinieren.
http://www.deinmeister.de/wasmtut.htmEine neuere Entwicklung sind "DNS-Rechner":
http://www.wisdom.weizmann.ac.il/~kobi/
-
Vielleicht kann man Assembler und Windows kombinieren.
Sehr sinnvoll.
-
@User20034: In welche Richtung gehen deine Interessen nun?
-
Gregor schrieb:
Das Argument habe ich ehrlich gesagt noch nie verstanden.
Es ist auch ein komisches Argument.
Der Grundgedanke ist wohl der, dass wenn du dich mit ASM abgibst du recht oft mehr ueber die Funktionsweise von alle dem erfahren willst. Zwingen tut dich allerdings keiner. Insofern kann man sich auch ein gutes Buch genehmigen - das tut es auch
-
Ich würde sagen, dass auch hier gilt: reinschnuppern schadet nicht.
-
Ja, wie gesagt in jedes Paradigma mal reinschnuppern:
Prozedural: Pascal, Basic, ...
OO: SmallTalk, Objective-C, Eiffel, ...
Funktional: ML, Haslkell, ...
Logisch: Mercury, Prolog, ...Gibts noch mehr?
Das, was dich itneressiert dann weiter ausbauen.
-
Hi,
danke erstmal für die ganzen Tipps. Ich bin eigentlich ganz heiß drauf ein Prog mit GUI zu programmieren und so meine kentnisse zu sammeln.
Mein Problem hierbei, überall wo ich nur hinschaue kosten die IDEs ar... viel Geld. Ich bin Student und bekomme von unserer uni die IDE gestellt da wir an dem MSDN Academic teilnehmen. Ich möchte ein Programm Online stellen können wenn ich damit fertig bin damit es die anderen User nutzen können. So eine Art KDE Projekt will ich machen. Mit was ist das möglich? Darf ich dann auch spenden annehmen, Ohne von den Softwareherstellern gleich verklagt zu werden?
-
Mein Problem hierbei, überall wo ich nur hinschaue kosten die IDEs ar... viel Geld.
1. gibt es auch gute kostenlose IDEs (zB. Eclipse, MinGWStudio, Anjuta oder KDevelop)
2. Hat eine IDE nichts mit GUI programmieren zu tun
So eine Art KDE Projekt will ich machen. Mit was ist das möglich?
Du musst ja nur die Möglichkeit haben auf dem Bildschirm zu malen. Womit du das genau machst, ist ziemlich egal. Wenn du einen UNIX WindowManager schreiben willst, dann musst du dich aber mit X11 ausseinandersetzen.
Darf ich dann auch spenden annehmen, Ohne von den Softwareherstellern gleich verklagt zu werden?
äh, wer sollte dir das warum verbieten?Erhard Henkes schrieb:
Konzepte und grundlegendes Verständnis ist wichtig. Daher halte ich es immer noch für wichtig, den inneren Ablauf einer klassischen Windows-Anwendung (Nachrichtenerzeugung, Nachrichtenpumpe und -Schlange, Reaktionen auf Nachrichten) zu verstehen, denn das ist bei MFC oder auch bei Java bzw. C# das gleiche System, sobald man es mit Mausklicks zu schaffen hat.
das ist doch totaler Blödsinn. Genausogut lernt man Nachrichtenbehandlung auch wenn man mit einem anderen GUI System arbeitet. Was sollte die WinAPI da für ein Mehrwert mitbringen (denk dran, es gibt mehr Systeme als Windows)? Die WinAPI bringt eher den Nachteil, dass sich die Leute
a) hässliche Dinge angewöhnen (lange Parameterlisten, ungarische Notation, hässliche typedefs etc.), vorallem wenn der eigene Stil noch nicht so gefestigt ist
b) die Leute an einer riesigen und unübersichtlichen API sich die Zähne ausbeißen, obwohl sie relativ leicht mit einer höheren Library die Dinge schneller und sauberer lernen könnten.
-
das ist doch totaler Blödsinn
@kingruedi:
Also zunächst einmal muss ich dir sagen, dass du dich häufig im Ton vergreifst und dich nicht wie ein neutraler Moderator verhälst, sondern offen deine Zuneigung zu Linux und deine Abneigung zu MS Windows, insbesondere zu WinAPI, zur Schau stellst. Also, entweder solltest du deinen Moderator-Job an den Nagel hängen oder dein Verhalten neutraler oder zumindest ausgewogener (z.B. These, Antithese, Synthese) gestalten.@all:
Persönlich halte ich viel vom Nachempfinden und praktischen Begreifen historischer Entwicklungen. Daher empfehle ich einem Einstieger in GUI die Programmierung auf MS Windows mit WinAPI (Das Buch von Charles Petzold ist z.B. heute noch lesenswert, nicht nur wegen WinAPI). Man lernt dort wichtige Zusammenhänge kennen, aber auch die Schwächen und Probleme vergangener Zeiten.Erst dann sollte man sich neuen Ufern zuwenden.
Ich halte es z.B. auch für gut, den Weg von C über C++ zu Java oder C# zu gehen, weil man m.E. ansonsten nicht wirklich versteht, welche Vor- aber auch Nachteile neue Systeme besitzen.
Dass man diesbezüglich völlig anderer Meinung sein kann, ist mir ebenfalls klar. Deshalb hat weder der eine noch der andere Recht, darum geht es auch überhaupt nicht.
Ich möchte aber auch betonen - und da unterstütze ich kingruedi -, dass API's nicht wirklich elementar sind. Sie sind nur temporäres Mittel zum Zweck.
Entscheidend sind praxisnahe, grundlegende Prinzipien, die sich längerfristig nicht verändern. Hierzu zählen z.B.:
algorithmische Problemlösung und Zuverlässigkeit, Leistungsfähigkeit und Grenzen algorithmischer Methoden.
-
Erhard Henkes schrieb:
das ist doch totaler Blödsinn
@kingruedi:
Also zunächst einmal muss ich dir sagen, dass du dich häufig im Ton vergreifst und dich nicht wie ein neutraler Moderator verhälst, sondern offen deine Zuneigung zu Linux und deine Abneigung zu MS Windows, insbesondere zu WinAPI, zur Schau stellst. Also, entweder solltest du deinen Moderator-Job an den Nagel hängen oder dein Verhalten neutraler oder zumindest ausgewogener (z.B. These, Antithese, Synthese) gestalten.Öhm, es geht hier nicht um Linux und ich habe niemandem gesagt er soll lieber Linux benutzen. Was willst du mir sagen? Das du wenn du argumentativ nicht mehr weiter kommst einfach den "Du bist doch Moderator, lass mich in Ruh"-Hammer rausholst?
Die WinAPI ist wirklich keine schöne API, aber das wär sie auch nicht wenn Linus Torvald sie geschrieben hätte oder sie vom POSIX Komitee ratifiziert worden wär.
Und nach meiner Meinung ist es totaler Blödsinn zu glauben, dass man Nachrichten Systeme besser versteht, nur weil man mit der WinAPI arbeitet.
@all:
Persönlich halte ich viel vom Nachempfinden und praktischen Begreifen historischer Entwicklungen. Daher empfehle ich einem Einstieger in GUI die Programmierung auf MS Windows mit WinAPI (Das Buch von Charles Petzold ist z.B. heute noch lesenswert, nicht nur wegen WinAPI). Man lernt dort wichtige Zusammenhänge kennen, aber auch die Schwächen und Probleme vergangener Zeiten.ich befürchte eher, dass viele Leute, die noch keinen Überblick im Programmieren besitzen (also Anfänger) sich leicht in der historischen Entwicklung verfangen.
Die WinAPI bringt IMHO kein Mehrwert als jede andere GUI API und im Gegensatz zu vielen GUI APIs fördert die WinAPI auch einen schlechten Stil. (ähnliches lässt sich auch auf andere APIs übertragen. Zum Beispiel was ich vom FOX-Toolkit gesehen habe lässt einen erschaudern, da man mit sehr vielen Macros arbeitet)
Erst dann sollte man sich neuen Ufern zuwenden.
Nein, erst wenn man ein gefästigtes Basis Wissen hat, sollte man sich an einen Brocken wie die WinAPI wagen.
Ich halte es z.B. auch für gut, den Weg von C über C++ zu Java oder C# zu gehen, weil man m.E. ansonsten nicht wirklich versteht, welche Vor- aber auch Nachteile neue Systeme besitzen.
Den begreift man wenn man sich mit den anderen Systemen ausseinander setzt, gerade als C++ Programmierer wird man schneller mit C konfrontiert als einem lieb ist.
So gewöhnt man sich eher einen Stil an, der nicht optimal ist und den wieder wegzubekommen ist noch schwerer als der Programmier Einstieg oder das man sich zu sehr auf die WinAPI einfährt
-
C über C++ zu Java oder C#
Wieso dass? Wieso vorher nicht noch BCPL? Ich meine, wieso ausgerechnet diesen kleinen Ausschnitt aus der Geschichte? Das macht doch nun wirklich gar keinen Sinn.