Entscheidungsfrage: Java, C#, C++, C
- Ersteller Winput
- Erstellt am
PoWerBaR
Semiprofi
Klaro, aber für nen Anfänger fand ich Java doch schöner... oder eher lehrreicher, einfach, weil Java öfters mal gemeckert hat, und man sich fragen musste, was man eigentlich machen will, und ob das der richtige Weg für ist.
Ich enthalte mich bei der Abtsimmung, würde aber, wenn du komplett neu anfängst ein Auge auf D werfen. Ich programmiere in c++ und dass auch nur, weil ichs muss. Vorlieben gibt es glaub ich nicht durch die Sprachen an sich, sondern nur, ob du mit Ihnen klar kommst oder nicht.
mhh toller Thread 
Eigentlich muss man alles können
In modernen Firmen interagieren und Kommunizieren ziemlich oft verschiedene Systeme und verschiedene Sprachen miteinander. Wenn man nur ein System kennt, kann man nicht wirklich gut verstehen wie man den eigenen Code schreiben muss, damit dieser perfomant und stabil ist. Daher würde ich Dir auch sagen: Such Dir die Sprachen
nach dem Projekt aus.
Allgemein geht die Richtung bei Sprachen in Bytecode intepreter wie Java oder C# ( Nur mal so nebenbei C# ist NICHT C+++++, sondern eigentlich JavaC. In C# wird der Code auch in einen Bytecode übersetzt, der dann von einer Runtime Umgebung (bzw. Virtual Machine) ausgeführt... bei C# braucht man dafür das .NET Framework und in Java die installiert man sich das JRE, bei beiden wird dann eine Runtimeumgebung installiert)
Java hat in den letzten Jahren stark zugelegt und ist mitlerweile ziemlich schnell. Im August gibts eine neue JRE (nach meinen Infos) mit jeder Menge Eyecandy...man darf gespannt sein.
Diese Technologie (also C#/Java) ist auf jedenfall die Zukunft..ABER!! Du lernst die Hardware des PCS's damit nicht so gut kennen wie bei C++. Es ist zimlich oft wichtig, das man weiss wie genau die Speicherzugriffe funktionieren oder wie genau ein Parser aufgebaut ist, um einschätzen zu können, ob er auch noch bei 20000 Textzeilen gleichzeitig funktioniert. Bytecode Sprachen nehmen dir sowas nämlich oft ab und das gibt für den unerfahrenen Coder dann "komische" Effekte und man weiss nicht woher die kommen.
Mein Tipp: Mit C++ anfangen und dann mit diesem Wissen auf was moderneres umsteigen.
bye Toc
P.S. Du könntest ja auch mal mit was richtig abgedrehtem anfangen: Ruby bzw. Ruby Raids...klingt wirklich toll. Damit zu entwickeln, ist wie einen Astin Martin aus den 60ern zu fahren...seeeehr exclusiv
Eigentlich muss man alles können
In modernen Firmen interagieren und Kommunizieren ziemlich oft verschiedene Systeme und verschiedene Sprachen miteinander. Wenn man nur ein System kennt, kann man nicht wirklich gut verstehen wie man den eigenen Code schreiben muss, damit dieser perfomant und stabil ist. Daher würde ich Dir auch sagen: Such Dir die Sprachen
nach dem Projekt aus.Allgemein geht die Richtung bei Sprachen in Bytecode intepreter wie Java oder C# ( Nur mal so nebenbei C# ist NICHT C+++++, sondern eigentlich JavaC. In C# wird der Code auch in einen Bytecode übersetzt, der dann von einer Runtime Umgebung (bzw. Virtual Machine) ausgeführt... bei C# braucht man dafür das .NET Framework und in Java die installiert man sich das JRE, bei beiden wird dann eine Runtimeumgebung installiert)
Java hat in den letzten Jahren stark zugelegt und ist mitlerweile ziemlich schnell. Im August gibts eine neue JRE (nach meinen Infos) mit jeder Menge Eyecandy...man darf gespannt sein.
Diese Technologie (also C#/Java) ist auf jedenfall die Zukunft..ABER!! Du lernst die Hardware des PCS's damit nicht so gut kennen wie bei C++. Es ist zimlich oft wichtig, das man weiss wie genau die Speicherzugriffe funktionieren oder wie genau ein Parser aufgebaut ist, um einschätzen zu können, ob er auch noch bei 20000 Textzeilen gleichzeitig funktioniert. Bytecode Sprachen nehmen dir sowas nämlich oft ab und das gibt für den unerfahrenen Coder dann "komische" Effekte und man weiss nicht woher die kommen.
Mein Tipp: Mit C++ anfangen und dann mit diesem Wissen auf was moderneres umsteigen.
bye Toc
P.S. Du könntest ja auch mal mit was richtig abgedrehtem anfangen: Ruby bzw. Ruby Raids...klingt wirklich toll. Damit zu entwickeln, ist wie einen Astin Martin aus den 60ern zu fahren...seeeehr exclusiv
Ein Architekt muss wissen wie gemauert wird, da er sonnst die Statik nicht richtig berechnen kann.
Dein Innenenaustatter ist der Photoshop Anwender...das Haus ist längst fertig. (Bauen ~ Coden, Haus nutzen ~ Programm nutzen)
So klingt das erstmal gut...
Nur wass ist jetzt der "Putz" ?
Du hattest den Vergleich mit dem Innenausstatter gebracht, weil Du die Meinung vertritts, dass ein Entwickler nicht zwingend verstehen muss wie die Software intern (also auf assembler Ebene) arbeitet?!
Ok...der Innenausstatter ist jetzt mal der Softwareentwickler. Wenn dieser z.B. ein Hängeregal anbauen will und die Wand dahinter aus Presspappe ist, dann sollte er das schon wissen. Er sollte auch wissen was in ein Regal rein soll, bzw. wie viel die Tragen sollen.
Wenn ich z.B. einen XML Parser nutze weil ich große (also zig MB) XML Files verarbeiten will, dann sollte ich wissen wie genau der funktioniert, weil ich sonnst mit ewigen Wartezeiten oder Heap überläufen zu kämpfen habe. Und IMO reicht da die Unterscheidung zwischen SAX und DOM nicht aus.
Nur wass ist jetzt der "Putz" ?
Du hattest den Vergleich mit dem Innenausstatter gebracht, weil Du die Meinung vertritts, dass ein Entwickler nicht zwingend verstehen muss wie die Software intern (also auf assembler Ebene) arbeitet?!
Ok...der Innenausstatter ist jetzt mal der Softwareentwickler. Wenn dieser z.B. ein Hängeregal anbauen will und die Wand dahinter aus Presspappe ist, dann sollte er das schon wissen. Er sollte auch wissen was in ein Regal rein soll, bzw. wie viel die Tragen sollen.
Wenn ich z.B. einen XML Parser nutze weil ich große (also zig MB) XML Files verarbeiten will, dann sollte ich wissen wie genau der funktioniert, weil ich sonnst mit ewigen Wartezeiten oder Heap überläufen zu kämpfen habe. Und IMO reicht da die Unterscheidung zwischen SAX und DOM nicht aus.
Klar ist das mein fehler wenn der heap überläuft...deswegen sollte man ja auch wissen wie der parser funktioniert bevor man einen aussucht. Alle Parser durchzutesten und zu schauen welcher funktioniert...dafür fehlt mir dann die Zeit.
setze dich zu erst mit der OO Programmierung im allgemeinen auseinander.
Microsoft:
C++ 2005 trennt sich ja in managed und unmanaged code.
C# ist zwingend managed code jedoch kann hier unmanaged code integriert werden.
Nur C++ bietet dir Plattformunabhängigkeit, aber auch nur dann wenn unmanaged code geschrieben wird. => Prozessorabhängige Kompilierung
Wenn du immer managed code schreibst, dann ist es in .Net egal welche Sprache du verwendest. Die Geschwindigkeit ist zwangsläufig die gleiche, da der Code ja in CLR Assemblies vorliegt.
Letzendlich kommt es auf das Projekt/Arbeitsumfeld und die persönlichen Vorlieben an.
Wer eher aus PHP kommt mag C++, C#, Java eher.
Ich zum Beispiel bin Datenbankprogrammierer und verwende ein dafür spezialisierte Entwicklungsumgebung. FoxPro 9.
Durch die Integration der dort vorhandenen Techniken in dem kommenden VS.Net 2008 (z.B. LINQ) und der immer stärker ins Feld rückenden Systemprogrammierung werden wir teilweise wechseln zu C# und VB.Net.
Besonders in C# und VB-Net wird MS für uns wichtige Implementierungen vorantreiben.
Je schneller du dein Ziel erreichen willst/musst desto mehr Code miuss im Hintergrund für dich erzeugt werden.
Zum lernen würde ich C# nehmen.
Hauptvorteil:
von der ECMA zertifiziert und damit ein offener Standard.
C# ist die Hauptsprache des .Net Frameworks
sowohl stärke Systemprogrammierung wie auch RAD Entwicklung möglich.
Zu Delphi kann ich keine Aussage treffen, da ich hier persönlich keine notwendigkeit sehe.
Ich hoffe ich konnte auch mal eine etwas neue Sichtweise einbringen.
Grundsätzlich: Es gibt keine perfekte Programmiersprache - Wahl sollte durch persönliche Vorlieben und Einsatzbereich entschieden werden.
Diskutieren - Ja , Streitthema - Nein.
Microsoft:
C++ 2005 trennt sich ja in managed und unmanaged code.
C# ist zwingend managed code jedoch kann hier unmanaged code integriert werden.
Nur C++ bietet dir Plattformunabhängigkeit, aber auch nur dann wenn unmanaged code geschrieben wird. => Prozessorabhängige Kompilierung
Wenn du immer managed code schreibst, dann ist es in .Net egal welche Sprache du verwendest. Die Geschwindigkeit ist zwangsläufig die gleiche, da der Code ja in CLR Assemblies vorliegt.
Letzendlich kommt es auf das Projekt/Arbeitsumfeld und die persönlichen Vorlieben an.
Wer eher aus PHP kommt mag C++, C#, Java eher.
Ich zum Beispiel bin Datenbankprogrammierer und verwende ein dafür spezialisierte Entwicklungsumgebung. FoxPro 9.
Durch die Integration der dort vorhandenen Techniken in dem kommenden VS.Net 2008 (z.B. LINQ) und der immer stärker ins Feld rückenden Systemprogrammierung werden wir teilweise wechseln zu C# und VB.Net.
Besonders in C# und VB-Net wird MS für uns wichtige Implementierungen vorantreiben.
Je schneller du dein Ziel erreichen willst/musst desto mehr Code miuss im Hintergrund für dich erzeugt werden.
Zum lernen würde ich C# nehmen.
Hauptvorteil:
von der ECMA zertifiziert und damit ein offener Standard.
C# ist die Hauptsprache des .Net Frameworks
sowohl stärke Systemprogrammierung wie auch RAD Entwicklung möglich.
Zu Delphi kann ich keine Aussage treffen, da ich hier persönlich keine notwendigkeit sehe.
Ich hoffe ich konnte auch mal eine etwas neue Sichtweise einbringen.
Grundsätzlich: Es gibt keine perfekte Programmiersprache - Wahl sollte durch persönliche Vorlieben und Einsatzbereich entschieden werden.
Diskutieren - Ja , Streitthema - Nein.
PoWerBaR
Semiprofi
Für embedded Systems ist reiner Assembler noch immer das einzig wahre. Zumindest für echte ES...
Aber wie schon so oft geschrieben: Ich empfehler erste eine nicht-oo Sprache (warum nicht Turbo-Pascal, C, Delphi, Basic? Hier lernt man noch "wirklich" coden), und dann was oo-tes, ob nun C++/C# oder Java ist relativ egal, da geht eh eher ums oo-Konzept verstehn, als um die Sprache. Kann man das eine, dauerts nen halben Tag und man kann das andre min. genauso gut...
Aber wie schon so oft geschrieben: Ich empfehler erste eine nicht-oo Sprache (warum nicht Turbo-Pascal, C, Delphi, Basic? Hier lernt man noch "wirklich" coden), und dann was oo-tes, ob nun C++/C# oder Java ist relativ egal, da geht eh eher ums oo-Konzept verstehn, als um die Sprache. Kann man das eine, dauerts nen halben Tag und man kann das andre min. genauso gut...
Ähnliche Themen
