Welche Programmiersprache soll ich jetzt lernen?
-
Daniel E. schrieb:
DEvent schrieb:
Das Header-Inlcude-Konzept von C++ ist volkommen veraltet und sollte endlich was gegen neues, bequemeres, wartbares ersetzt werden.
*flameweiterführ*
Das dürfte aber unstrittig sein. Turbo-Pascal war da schon weiter. Java lustigerweise nicht wirklich, bei denen blickt ohne Doxygen anscheinend niemand durch.
Wieso blickt man in Java ohne Doxy nicht durch?
Wenn dir die Java-Lib zu umfangreich ist -> Finger weg
-
Eldonir schrieb:
Erstma danke für die zahlreichen Antworten
Ich hab dazu nochmal ein Paar fragen zu C#:
1. Was spricht gegen C# ? imgrunde ist das doch nur eine mischung aus java und C++
Wiso sollte das ein verstümmelung oder so sein ?2. Arbeited C# auch mit Headern?
C# ist der Versuch von Microsoft Java besser zu machen. Du hast im Grunde das was Java hat (Packete, GC, Generics, Interfaces), aber auch Konzepte von C++ wie Operatorüberladung, Strukturen und Unsafed-Code.
Das einzige was mir an C# nicht gefällt ist es, das es nicht portabel ist (oder man verwendet Mono als Lib). Mit Java habe ich bereits eine Sprache mit GC und einer sehr guten Lib, die portabel ist. Wozu dann noch C#.
PS: hies es GarbageContainer oder -Collector, ich vergess es ständig.
-
DEvent schrieb:
Eldonir schrieb:
Erstma danke für die zahlreichen Antworten
Ich hab dazu nochmal ein Paar fragen zu C#:
1. Was spricht gegen C# ? imgrunde ist das doch nur eine mischung aus java und C++
Wiso sollte das ein verstümmelung oder so sein ?2. Arbeited C# auch mit Headern?
C# ist der Versuch von Microsoft Java besser zu machen. Du hast im Grunde das was Java hat (Packete, GC, Generics, Interfaces), aber auch Konzepte von C++ wie Operatorüberladung, Strukturen und Unsafed-Code.
Das einzige was mir an C# nicht gefällt ist es, das es nicht portabel ist (oder man verwendet Mono als Lib). Mit Java habe ich bereits eine Sprache mit GC und einer sehr guten Lib, die portabel ist. Wozu dann noch C#.
PS: hies es GarbageContainer oder -Collector, ich vergess es ständig.
Ehrlich gesagt finde ich einige Sachen in C# viel besser gelöst, aber jeden das seine
-
Danke für die Erklärung , hat mir sehr geholfen!!!
Ich denke ich werde es mit C# einfach mal versuchen , wens mir dann nicht gefällt kann ich ja immernoch ne andere sprache nehmen
-
Setzt jemand ernsthaft D ein? Gibt es eigentlich IDEs die D schön unterstützen? Z.B. auch selbstständig die imports eintragen? (so wie bei den Java-IDEs)
D wäre so die einzige Sprache die ich mir als C++-Alternative vorstellen könnte, nachdem wie es sich auf der DMD-Website liest. Aber habe Null Erfahrung gemacht.
-
DEvent schrieb:
Daniel E. schrieb:
DEvent schrieb:
Das Header-Inlcude-Konzept von C++ ist volkommen veraltet und sollte endlich was gegen neues, bequemeres, wartbares ersetzt werden.
Das dürfte aber unstrittig sein. Turbo-Pascal war da schon weiter. Java lustigerweise nicht wirklich, bei denen blickt ohne Doxygen anscheinend niemand durch.
Wieso blickt man in Java ohne Doxy nicht durch?
Weil die Klasseninterfaces recht unübersichtlich lang werden. Deswegen werden solche Dokumentationstools viel häufiger eingesetzt als in zB C++ oder TP/Delphi, wo Interface und Implementierung getrennt aufgeführt werden (können).
Wenn dir die Java-Lib zu umfangreich ist -> Finger weg
Ich faße Java ohnehin nur mit Kneifzange an.
-
Daniel E. schrieb:
Weil die Klasseninterfaces recht unübersichtlich lang werden. Deswegen werden solche Dokumentationstools viel häufiger eingesetzt als in zB C++ oder TP/Delphi, wo Interface und Implementierung getrennt aufgeführt werden (können).
Hmmm... ich sehe das etwas anders. C++ sollte eigentlich ausgiebiger als Javacode dokumentiert werden. Und zwar, weil man in C++ Ausdrucksformen hat, die sich nicht komplett im Code wiederfinden. Stell Dir ein Template vor, bei dem die Typen, mit denen Du das Template parametrisierst, eine gewisse Schnittstelle bieten müssen. Wie verankert man die Information über diese Schnittstelle im Code? AFAIK normalerweise gar nicht, auch wenn es da sicherlich irgendwelche abgedrehten Möglichkeiten gibt, die keiner nutzt.
Zumindest muss man solche Informationen normalerweise in der Doku unterbringen. ...ok, aber andererseits kann soetwas natürlich auch nicht von automatischen Doku-Tools generiert werden. Man muss also alles per Hand machen. Der Dokumentationsaufwand sollte aber deutlich größer sein. ...und auch die Dokumentationsnutzung bei der Programmierung mit irgendeiner Bibliothek.
-
Gregor schrieb:
Daniel E. schrieb:
Weil die Klasseninterfaces recht unübersichtlich lang werden. Deswegen werden solche Dokumentationstools viel häufiger eingesetzt als in zB C++ oder TP/Delphi, wo Interface und Implementierung getrennt aufgeführt werden (können).
Hmmm... ich sehe das etwas anders. C++ sollte eigentlich ausgiebiger als Javacode dokumentiert werden. Und zwar, weil man in C++ Ausdrucksformen hat, die sich nicht komplett im Code wiederfinden. Stell Dir ein Template vor, bei dem die Typen, mit denen Du das Template parametrisierst, eine gewisse Schnittstelle bieten müssen. Wie verankert man die Information über diese Schnittstelle im Code? AFAIK normalerweise gar nicht, auch wenn es da sicherlich irgendwelche abgedrehten Möglichkeiten gibt, die keiner nutzt.
Zumindest muss man solche Informationen normalerweise in der Doku unterbringen. ...ok, aber andererseits kann soetwas natürlich auch nicht von automatischen Doku-Tools generiert werden. Man muss also alles per Hand machen. Der Dokumentationsaufwand sollte aber deutlich größer sein. ...und auch die Dokumentationsnutzung bei der Programmierung mit irgendeiner Bibliothek.Ne, die Leute, die C++ programmieren sind schlauer und brauchen für sowas keine Doku!
-
Eldonir schrieb:
Danke für die Erklärung , hat mir sehr geholfen!!!
Ich denke ich werde es mit C# einfach mal versuchen , wens mir dann nicht gefällt kann ich ja immernoch ne andere sprache nehmen
Schwerwiegender Fehler!
C# ist ein billiger Java klon und trägt en C im Namen um C/C++ programmierer anzulocken, da es so viele davon gibt. C# ist total unportabel.Wenn schon dann Java.
-
Hört doch mal auf mit dieser engstirnigen Sprach-Missionierung. man sucht sich halt eine der großen aus und fertig. Wenn man ernsthaft programmieren will, dann wird man sich sowieso unzählige Sprachen aneignen.
C# oder Java eignen sich hervorragend um sich OOP beizubringen, weil sie einem erst mal viele der ekligen Details ersparen, die sowieso fürs Verständnis des Paradigmas (!) total unwichtig sind. Mit etwas Intelligenz kann man sich dann die grausigen Sachen wie Header usw anschauen
-
moonfire spam schrieb:
C# oder Java eignen sich hervorragend um sich OOP beizubringen, weil sie einem erst mal viele der ekligen Details ersparen, die sowieso fürs Verständnis des Paradigmas (!) total unwichtig sind.
Also nach einem gewissen anderen Thread möchte ich dir da dezent widersprechen
-
Gregor schrieb:
...
Hmmm... ich sehe das etwas anders. C++ sollte eigentlich ausgiebiger als Javacode dokumentiert werden. Und zwar, weil man in C++ Ausdrucksformen hat, die sich nicht komplett im Code wiederfinden. Stell Dir ein Template vor, bei dem die Typen, mit denen Du das Template parametrisierst, eine gewisse Schnittstelle bieten müssen. Wie verankert man die Information über diese Schnittstelle im Code? AFAIK normalerweise gar nicht, auch wenn es da sicherlich irgendwelche abgedrehten Möglichkeiten gibt, die keiner nutzt. Zumindest muss man solche Informationen normalerweise in der Doku unterbringen. ...ok, aber andererseits kann soetwas natürlich auch nicht von automatischen Doku-Tools generiert werden. Man muss also alles per Hand machen. Der Dokumentationsaufwand sollte aber deutlich größer sein. ...und auch die Dokumentationsnutzung bei der Programmierung mit irgendeiner Bibliothek.Finde das in der SGI STL Doku recht gut gelöst. Der Value Type muss assignable, copyconstructable etc. sein, ein Klick drauf, und du bist bei der Beschreibung des Interfaces.
Dafür ist der Code schön schlank und nicht mit Kommentaren zugedeckt. ( Voraussetzung ist halt, das man neben der IDE noch nen Browser offen hat, was mich nicht extrem stört. )
Hingegen finde ich die Doxy Dokus meist etwas spärlich und nichtssagend. Da nützt auch das Klassendiagramm nicht viel.
Nur meine Meinung.. :p
-
naja bevor ich mich richtig mit c# anfreunde geht ich lieber wieder mit java essen.
C# is zwar net schlecht, aber doch eher weiter in hinten in der qual der wahl. Bin im moment sehr gluecklich mit c++ und wenn ich brauch .NET und ogl dazu. (und imho ASIO fuer audio spielsachen) Damit komm ich recht angenehm dorthin wo ich will.
-
1310-Logik schrieb:
Gregor schrieb:
...
Hmmm... ich sehe das etwas anders. C++ sollte eigentlich ausgiebiger als Javacode dokumentiert werden. Und zwar, weil man in C++ Ausdrucksformen hat, die sich nicht komplett im Code wiederfinden. Stell Dir ein Template vor, bei dem die Typen, mit denen Du das Template parametrisierst, eine gewisse Schnittstelle bieten müssen. Wie verankert man die Information über diese Schnittstelle im Code? AFAIK normalerweise gar nicht, auch wenn es da sicherlich irgendwelche abgedrehten Möglichkeiten gibt, die keiner nutzt. Zumindest muss man solche Informationen normalerweise in der Doku unterbringen. ...ok, aber andererseits kann soetwas natürlich auch nicht von automatischen Doku-Tools generiert werden. Man muss also alles per Hand machen. Der Dokumentationsaufwand sollte aber deutlich größer sein. ...und auch die Dokumentationsnutzung bei der Programmierung mit irgendeiner Bibliothek.Finde das in der SGI STL Doku recht gut gelöst. Der Value Type muss assignable, copyconstructable etc. sein, ein Klick drauf, und du bist bei der Beschreibung des Interfaces.
Dafür ist der Code schön schlank und nicht mit Kommentaren zugedeckt. ( Voraussetzung ist halt, das man neben der IDE noch nen Browser offen hat, was mich nicht extrem stört. )
Hingegen finde ich die Doxy Dokus meist etwas spärlich und nichtssagend. Da nützt auch das Klassendiagramm nicht viel.
Nur meine Meinung.. :pDas hast du bei Java auch. In Eclipse einfach mit dem Mauscursor über die Methode/Klasse.
Über was streiten wir uns überhaupt? Objektiv gesehen hat man viel weniger Freiheiten in Java und der Compiler ist viel strenger. Somit ist Java-Code mehr selbsterklärend als C++-Code.
In der Praxis kommt es eh auf den Programmierer an...
-
DEvent schrieb:
In der Praxis kommt es eh auf den Programmierer an...
Volle Zustimmung
-
Also ich nehme mal an, dass die Auswahl der richtigen Headerdateien in C++ bei dem aktuellen Diskussionsstand nicht mehr das Entscheidende ist, sich von dieser Sprache fernzuhalten. Deutlich schwieriger finde ich das Thema GUI bei C++, da es hier momentan keine breit akzeptierte Lösung gibt. Das führt dann schon eher zu C# oder Java, wobei man bei diesen Sprachen eben nicht mehr so frei ist wie bei C++. Freiheit und große Mengen fertigen Codes sprechen für C++. Ich empfehle daher immer noch C++.