C Sharp stärker als Java ?

Thread Starter
Mitglied seit
03.12.2010
Beiträge
225
Die Entwicklung unter C# geht wesentlich schneller vorwärts.

Was meint Ihr ?


Die schnellste Sprache ist Assembler nach Machine Code und Kernighan und Ritchie C, C++ wegen Microcontroller. Ist C-Sharp schneller als Java ?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was ist denn das für ein Schwachsinnsthread?
 
Besser: was ist das für eine Schwachsinnsantwort?

Die Frage nach der richtigen Programmiersprache ist nicht unberechtigt. Auch Benchmarks und Entwicklungszeit unter Sprachen selbst sind nicht gerade unwichtig. Neulich hat ein Kollege von mir ein Programm zur Berechnung von doppelten Fakultäten in C programmiert - das Programm war vielleicht schnell, aber leider hatte es keine Unterstützung von BigInt-Typen, wodurch es zum Absturz kam sobald Int ausgereizt war. Ich hab ihm dann so ein Programm in C# geschrieben, dass - wenn mein Rechner nicht ewig brauchen würde - (20!)! berechnen könnte. Eben weil C# nativ über einen entsprechenden Typen verfügt. Was hat das mit dem Thread zu tun? Wer weiß, welche Sprache zu was in der Lage ist, kann wesentlich schneller und einfacher zum Ziel kommen. Ich hätte es auch in C++ schreiben können und eine BigInt-Klasse implementieren können; aber warum der Aufwand? Hunderte von Zeilen mehr schreiben für ein Programm was im Endeffekt nicht mehr können muss? Sinnlos.

Zur eigentlichen Frage:
Ich habe mich immer nur sporadisch mit Java beschäftigt. Irgendwie gefällt mir die Sprache nicht (keine Destruktoren, Klassennamenvergewaltigung für Namespaces, so weit vom System entfernt wie die Erde vom Mars, usw.). Aber spaßhalber habe ich vor nem Jahr oder so mal kleinere Benchmarks mit ein paar Sprachen gemacht (C++, Java, C#, PHP) um zu sehen, wie groß die Unterschiede tatsächlich sind. Das Ergebnis war wie zu erwarten: C++ ist am Schnellsten, danach war C# (soweit ich mich erinnern kann etwa 15% schneller als Java), dann Java und letztendlich PHP.

Das Ergebnis lässt sich auch einfach erklären:
C++ ist die einzig richtig kompilierte Sprache und wird als nativer Maschinencode ausgeführt. Da man keine virtuellen Runtime Environments braucht, sondern die CPU sich direkt mit der Ausführung beschäftigt, ist die Sprache am Schnellsten. Nachteil: C++ ist relativ schwierig zu lernen und erfordert ein hohes Maß an Frustrationstoleranz.
C# wird unter dem .NET Framework ausgeführt. Dieses wird regelmäßig von Microsoft geupdatet und somit kann man - selbst wenn die Sprache nicht kompiliert wird, sondern im Bytecode ausgeführt wird - entsprechende Geschwindigkeiten erwarten. Nachteil: ist halt eine "Windows-Sprache". Für andere Systeme bräuchte man Mono, und das ist leider nicht so verbreitet wie z.B. der Java-Interpreter. Aber wer hauptsächlich für Windows entwickeln möchte, macht mit C# sicher keinen Fehler. Man kommt sehr einfach ans System, ans Betriebssystem, hat immer noch eine recht brauchbare Menge von Bibliotheken und die Entwicklung von GUIs geht sehr schnell.
Bei Java fällt mir nur ein Zitat von "Java ist mehr als eine Insel" ein: der Autor hatte dort gesagt, dass Java sich mehr in einem "Wartungszustand" befindet und man eigentlich nicht mehr groß darauf hoffen würde, dass hier noch maßgebliche Änderungen kommen. Gefühlt kommen ohnehin nur Bugfixes für die zahlreichen Sicherheitslücken. Vermutlicherweise wäre Java unter Entwicklern nicht halb so beliebt, wenn Minecraft nicht wäre ;)
Und PHP war wie zu erwarten so langsam wie ein Stein: komplett interpretierte Sprache, die Optimierung nur sehr bedingt zulässt (hatte testweise mal umfangreichere Benchmarks mit PHP gemacht; beispielsweise ist dort "Speichermanagement" (wenn man das überhaupt so nennen darf) zwar für den Speicher "gut", aber verringert die Ausführungszeit. Folge: sich um den Speicher gezielt zu kümmern ist vollkommen sinnlos, da der Interpreter nach seiner Arbeit ohnehin alles im RAM freigibt).

Meine persönliche Meinung zu C# vs. Java:
C# ist neben Objective C sicher einer der modernsten Programmiersprachen. Man kommt schnell zu seinen Ergebnissen und kann auch ohne Anwendung von dunkler Magie gute Ergebnisse erzielen. Man ist zwar zu OOP gezwungen, aber meiner Meinung nach, ist alles andere heutzutage ohnehin obsolet. Und: es ist, meinen Benchmarks zu Folge, schneller als Java. Vielleicht lag das an den Tests, vielleicht lag das an meiner Hardware - oder vielleicht lags daran, dass das .NET Framework einfach schneller ist als die JRE.
 
Lange galt JAVA als langsam - das ist allerdings überholt.
Problem nur: man kann bei JAVA so herrlich viel falsch machen..

Gegenfrage: Warum ist der Geschwindigkeitsfaktor so von Interesse? Ich würde auch dazu tendieren und sagen: im Normalfall ist C# schneller.
 
Es stellt sich nicht die Frage, was besser ist. Jede Sprache hat ihre Daseinsberechtigung, abhängig von Einsatz und Systemumgebung. Da gibts kein besser oder schlechter.
 
Besser: was ist das für eine Schwachsinnsantwort?

Die Frage nach der richtigen Programmiersprache ist nicht unberechtigt. Auch Benchmarks und Entwicklungszeit unter Sprachen selbst sind nicht gerade unwichtig. Neulich hat ein Kollege von mir ein Programm zur Berechnung von doppelten Fakultäten in C programmiert - das Programm war vielleicht schnell, aber leider hatte es keine Unterstützung von BigInt-Typen, wodurch es zum Absturz kam sobald Int ausgereizt war. Ich hab ihm dann so ein Programm in C# geschrieben, dass - wenn mein Rechner nicht ewig brauchen würde - (20!)! berechnen könnte. Eben weil C# nativ über einen entsprechenden Typen verfügt. Was hat das mit dem Thread zu tun? Wer weiß, welche Sprache zu was in der Lage ist, kann wesentlich schneller und einfacher zum Ziel kommen. Ich hätte es auch in C++ schreiben können und eine BigInt-Klasse implementieren können; aber warum der Aufwand? Hunderte von Zeilen mehr schreiben für ein Programm was im Endeffekt nicht mehr können muss? Sinnlos.

Okay, dann mal los.

Ja, die richtige Programmiersprache ist wichtig. Wenn ich Mikrocontroller programmiere, dann nehme ich entweder Assebmler (kann ich persönlich nicht) oder pures C mit Erweiterungen vom Mikrocontroller-Hersteller. Fertig, Thema erledigt. OOP in dem Bereich ist schwachsinnig und nur hinderlich.

Zu Deinem Kollegen: Ich würde einfach sagen, dass er etwas nicht aufgepasst hat . Int in C++ ist als 16 bzw. 32 bit definiert. Warum nimmt er nicht long? Ist entweder 32bit oder 64 bit (bei 64 bittigen Hardware), also kein Problem. Dann gäbe es noch einen double, ist dann acht Byte groß.

Zur eigentlichen Frage:
Ich habe mich immer nur sporadisch mit Java beschäftigt. Irgendwie gefällt mir die Sprache nicht (keine Destruktoren, Klassennamenvergewaltigung für Namespaces, so weit vom System entfernt wie die Erde vom Mars, usw.). Aber spaßhalber habe ich vor nem Jahr oder so mal kleinere Benchmarks mit ein paar Sprachen gemacht (C++, Java, C#, PHP) um zu sehen, wie groß die Unterschiede tatsächlich sind. Das Ergebnis war wie zu erwarten: C++ ist am Schnellsten, danach war C# (soweit ich mich erinnern kann etwa 15% schneller als Java), dann Java und letztendlich PHP.

Einen Destruktor kannst Du selber schreiben, wenn Du ihn unbedingt brauchst. Aber wofür?

Und in Java gibt es sowas wie Packages und das nicht umsonst. Solltest Es Dir vielleicht anschauen.

Du hast Dich nur sporadisch mit Java beschäftigt, maßt Dir aber an in der Lage zu sein einen Benchmark dafür zu schreiben? Respekt, Du bist mein Gott.


Das Ergebnis lässt sich auch einfach erklären:
C++ ist die einzig richtig kompilierte Sprache und wird als nativer Maschinencode ausgeführt. Da man keine virtuellen Runtime Environments braucht, sondern die CPU sich direkt mit der Ausführung beschäftigt, ist die Sprache am Schnellsten. Nachteil: C++ ist relativ schwierig zu lernen und erfordert ein hohes Maß an Frustrationstoleranz.

Ich programmiere C wesentlich lieber als Java. Java programmiere ich beruflich und C privat, für Mikrocontroller.

Und das Java langsam sein sollte, ist Blödsinn. Wenn es so wäre, wäre es keine Sprache für AppServer und MiddleTier. Solange keine GUI da ist, ist Java verflucht schnell. Vorausgesetzt der Entwickler weiß, was er da tut.
 
Ich schließe mich an. Schwachsinnsthread.

Die Unterschiede kann man nachlesen. Es gibt sogar diverse seriöse Benchmarks, die nicht einfach pauschalisieren so wie das hier im Moment der Fall ist. Von einer mathematischen Berechnung auf die Performance einer kompletten Programmiersprache zu schließen, ist etwas sehr kurzsichtig. OOP ist zu mehr gut als nur für einen Taschenrechner...
 
Es stellt sich nicht die Frage, was besser ist. Jede Sprache hat ihre Daseinsberechtigung, abhängig von Einsatz und Systemumgebung. Da gibts kein besser oder schlechter.
Falsch. Für jede Art von Entwicklung bieten sich bestimmte Sprachen besser an an als andere. Natürlich kann man einen 0815 Taschenrechner mit GUI via C++ (und Qt oder vergleichbarem) realisieren. Du kannst auch mit deinem Auto im zweiten Gang bei 5.000rpm durch die Stadt düsen - ob das sinnvoll ist, sei dahingestellt.

OOP in dem Bereich ist schwachsinnig und nur hinderlich.
Applikationen die via OOP realisiert worden sind, bieten schonmal einfachere Wartbarkeit und Wiederverwendbarkeit. Hält man sich dann sogar noch an bestimmte Design-Patterns, kann man richtig guten Quellcode fabrizieren. Und ob du es glaubst oder nicht: es gibt Mikrokontroller die in C++ oder sogar Java laufen. Meine Erfahrung aber sagt mir, dass es sinnlos ist, einem C-Fanatiker die Vorteile von objektorientierten Sprachen zu erzählen.
Ich bestreite nicht, dass C mächtig ist. Aber man sollte, wo man kann, auf andere Sprachen zurückgreifen - bestimmte Gebiete (bestimmte Kontroller, Betriebssysteme, etc.) erlauben ohnehin ausschließlich C. Andere Dinge (Applikationsentwicklung, Spieleentwicklung, etc.) heutzutage noch in C zu realisieren wäre so sinnvoll wie wenn man seine Daten auf Disketten sichert...

Zu Deinem Kollegen: Ich würde einfach sagen, dass er etwas nicht aufgepasst hat . Int in C++ ist als 16 bzw. 32 bit definiert. Warum nimmt er nicht long? Ist entweder 32bit oder 64 bit (bei 64 bittigen Hardware), also kein Problem. Dann gäbe es noch einen double, ist dann acht Byte groß.
Anhand meines Beispiels von (20!)!: Ich weiß es nicht im Kopf, aber ich schätze einfach mal, dass jeder native Datentyp für (2432902008176640000!) zu klein ist.

Einen Destruktor kannst Du selber schreiben, wenn Du ihn unbedingt brauchst. Aber wofür?
Ein Wort: RAII.
Java-Programmierer, dessen Speichermanagement vom GC übernommen wird, kennen das Prinzip nicht wirklich. Ist weder tragisch noch verheerend - wenn man aber speicherkritische Applikationen schreibt, sollte man es aber vielleicht doch kennen und auch anwenden.

Und in Java gibt es sowas wie Packages und das nicht umsonst. Solltest Es Dir vielleicht anschauen.
Wusste ich nicht; jetzt weiß ichs. Aber - für mich - immer noch kein Grund jetzt in Java verliebt zu sein ;)

Respekt, Du bist mein Gott.
Danke.

Ich programmiere C wesentlich lieber als Java. Java programmiere ich beruflich und C privat, für Mikrocontroller.
Mal die Frage da du hier ganze Zeit von Mikrocontrollern redest: was machst du privat mit den Teilen wenn ich neugierig sein darf?

Und das Java langsam sein sollte, ist Blödsinn. Wenn es so wäre, wäre es keine Sprache für AppServer und MiddleTier. Solange keine GUI da ist, ist Java verflucht schnell. Vorausgesetzt der Entwickler weiß, was er da tut.
Java ist - verhältnismäßig - nicht schnell. Es kann auch nicht schnell sein, da es gewisse Zeit braucht bis der Bytecode von der JRE übersetzt wurde. Folgedessen kann Java nie schneller als nativer Maschinencode sein. Wäre Java so verdammt fix, wie die Java-Programmierer alle behaupten, wären große Applikationen die mit massig Speicher zu kämpfen haben wohl nicht in C, C++ oder Ähnlichem geschrieben.

Vorausgesetzt der Entwickler weiß, was er da tut.
Reine Vermutung: da Java einfach zu erlernen ist, wird es ähnliche Probleme wie Pyhton oder auch PHP haben. Es gibt Entwickler wie Sand am Meer - aber nur ein winziger Teil davon wird Ahnung davon haben was er tut. Auch logisch, da Java keine systemnahe Sprache ist und man sich mit bestimmten Elementen nicht auseinandersetzen muss.


E/ An den Herren über mir:
Von einer mathematischen Berechnung auf die Performance einer kompletten Programmiersprache zu schließen
Keine Ahnung wer das behauptet hat, aber die mathematische Berechnung die ich nannte war ein Beispiel zur Demonstration von Nützlichkeit, nicht Geschwindigkeit.
 
Zuletzt bearbeitet:
Applikationen die via OOP realisiert worden sind, bieten schonmal einfachere Wartbarkeit und Wiederverwendbarkeit. Hält man sich dann sogar noch an bestimmte Design-Patterns, kann man richtig guten Quellcode fabrizieren. Und ob du es glaubst oder nicht: es gibt Mikrokontroller die in C++ oder sogar Java laufen. Meine Erfahrung aber sagt mir, dass es sinnlos ist, einem C-Fanatiker die Vorteile von objektorientierten Sprachen zu erzählen.
Ich bestreite nicht, dass C mächtig ist. Aber man sollte, wo man kann, auf andere Sprachen zurückgreifen - bestimmte Gebiete (bestimmte Kontroller, Betriebssysteme, etc.) erlauben ohnehin ausschließlich C. Andere Dinge (Applikationsentwicklung, Spieleentwicklung, etc.) heutzutage noch in C zu realisieren wäre so sinnvoll wie wenn man seine Daten auf Disketten sichert...

Es geht nicht um "C-Fanatiker", es geht darum für den gegebenen Einsatzgebiet die passende Programmiersprache zu finden. Wenn ich in einem Umfeld arbeite, wo ich weiche oder gar harte Echtzeit habe, sch**sse ich auf OOP und Java und C++ mit dazu, da ist sowas fehl am Platz. Da nimmt man C und die Passagen, die Tausende Male in der Sekunde durchlaufen werden, schreibt man in Assembler, fertig. Oder nimmst Du einen Hammer zum Sägen? Was meinst Du, in welcher Sprache werden die Spiele-Engines entwickelt?

Beispiel: Du kennst doch bestimmt den Hersteller Oracle oder? Und kennst doch bestimmt die Oracle Datenbank? Rate mal in welcher Sprache ist sie geschrieben.

Du wirst Wartbarkeit und Performance durcheinander.

Mikrocontroller läuft nicht unter C++, ein Mikrocontroller läuft mit dem Maschinencode, in welcher Sprache der ursprünglich geschrieben wurde, juckt den Mikrocontroller herzlich wenig. Es gibt sowohl C als auch C++ Compiler dafür, das ist richtig.

Anhand meines Beispiels von (20!)!: Ich weiß es nicht im Kopf, aber ich schätze einfach mal, dass jeder native Datentyp für (2432902008176640000!) zu klein ist.

Aha.

Ein Wort: RAII.
Java-Programmierer, dessen Speichermanagement vom GC übernommen wird, kennen das Prinzip nicht wirklich. Ist weder tragisch noch verheerend - wenn man aber speicherkritische Applikationen schreibt, sollte man es aber vielleicht doch kennen und auch anwenden.

Kennst Du es?

Wenn es um speicherkritische Anwendungen geht, sollte man von "interpretierten" Sprachen die Finger lassen, das ist meine Meinung dazu. Es weiß keiner, wann der GC vorbeikommt. Man kann es zwar manuell auslösen, ist aber kein sauberer Stil.

Wusste ich nicht; jetzt weiß ichs. Aber - für mich - immer noch kein Grund jetzt in Java verliebt zu sein ;)

Das natürlich nicht, aber erhöht die Kompetenz...


Mal die Frage da du hier ganze Zeit von Mikrocontrollern redest: was machst du privat mit den Teilen wenn ich neugierig sein darf?

Serielle Bussysteme (quasi Echtzeit, sprich CAN) und Player, der alles Audioformate frisst. Der Player ist mein aktuelles Projekt.
 
Es geht nicht um "C-Fanatiker", es geht darum für den gegebenen Einsatzgebiet die passende Programmiersprache zu finden. Wenn ich in einem Umfeld arbeite, wo ich weiche oder gar harte Echtzeit habe, sch**sse ich auf OOP und Java und C++ mit dazu, da ist sowas fehl am Platz. Da nimmt man C und die Passagen, die Tausende Male in der Sekunde durchlaufen werden, schreibt man in Assembler, fertig. Oder nimmst Du einen Hammer zum Sägen?
Ich habe nicht bestritten, dass C durchaus Einsatz findet. Und Echtzeit-Anwendungen sind in C oder gar Assembler sicher klüger als in Java, ohne Frage. Aber wie gesagt: wenns an andere Dinge geht, z.B. Applikationsentwicklung (beispielsweise ein Thunderbird, oder ein Firefox), ist OOP eindeutig im Vorteil.

Was meinst Du, in welcher Sprache werden die Spiele-Engines entwickelt?
Bevor ich diese Frage beantworte: was meinst du denn, in welcher Sprache Engines entwickelt werden? Und von welchen Engines sprechen wir hier? Sprechen wir von der Engine von Super Mario, oder etwas à la CryEngine?

Nunja, es zu kennen ist nicht wirklich schwierig. Es anzuwenden genauso wenig. Die Frage nach Sinnhaftigkeit wäre berechtiger. Und wenn es darum geht; meine Applikationen sind weder speicher- noch performancekritisch. Daher habe ich relativ freie Hand welche Sprache ich wähle, und welche Prinzipe ich dort anwede.

Wenn es um speicherkritische Anwendungen geht, sollte man von "interpretierten" Sprachen die Finger lassen, das ist meine Meinung dazu. Es weiß keiner, wann der GC vorbeikommt. Man kann es zwar manuell auslösen, ist aber kein sauberer Stil.
Richtig.

Serielle Bussysteme (quasi Echtzeit, sprich CAN) und Player, der alles Audioformate frisst. Der Player ist mein aktuelles Projekt.
Klingt sehr interessant! Schöne private Beschäftigung, ohne Frage :)
 
Die Entwicklung unter C# geht wesentlich schneller vorwärts.
Nein. Jein. Ja.
Es hängt davon ab was man machen will, unter welcher Umgebung, worauf man zugreifen will, ob es schon passende Bibliotheken gibt usw.
Die schnellste Sprache ist Assembler
Schneller als auf die Befehlssätze direkt zuzugreifen gehts halt nicht ;)
Ist C-Sharp schneller als Java ?
Das kann man garnicht sagen. Es kommt immer darauf an was man macht und unter welcher Umgebung.
Unter Linux mit Mono wird vermutl. Java schneller sein. Unter Windows vermutl. C#. Aber solche Aussagen sind keines falls allgemein gültig.
Es kommt immer auf das konkrete Programm an und außerdem auch wie "gut" der Quelltext geschrieben ist, ob mögliche Optimierungen die die Sprache zur Verfügung stellt (z.B. Speicherverwaltung, Destruktoren) überhaupt genutzt werden oder nicht.

Man kann ja z.B. auch nicht einmal von "C++" allgemein reden. Es kommt ja auch noch immer auf den Compiler an. So kann ein mit dem VC-Compiler erstelltes C++-Programm unter Linux langsamer als Java sein, während der gleiche Quelltext mit dem GNU-Compiler erstellt schneller ist. Es kann auch sein dass Java beides mal langsamer oder beidesmal schneller ist.

Es gibt also viel zu viele Faktoren. Letzlich hat jede Sprache ihren Einsatzzweck und daseinsberechtigung.
Was die beste Sprache ist hängt immer noch davon ab für was man sie konkret einsetzen will.
Es gibt keine eierlegende Wollmilchsau unter den Programmiersprachen.
 
Zuletzt bearbeitet:
Java ist - verhältnismäßig - nicht schnell. Es kann auch nicht schnell sein, da es gewisse Zeit braucht bis der Bytecode von der JRE übersetzt wurde. Folgedessen kann Java nie schneller als nativer Maschinencode sein. Wäre Java so verdammt fix, wie die Java-Programmierer alle behaupten, wären große Applikationen die mit massig Speicher zu kämpfen haben wohl nicht in C, C++ oder Ähnlichem geschrieben.
Nur gut das es Benchmarks gibt die deine Behauptung wiederlegen. Durch JIT und HotSpot Compiler gibt es durch aus einige Fälle in denen Java schneller ist als C++ Code.
 
hier gibt es das beliebte "computer language benchmark game":

Computer Language Benchmarks Game

da schneidet java eigentlich ziemlich gut ab.

java vs. .Net/mono würde ich eher "politisch" sehen: Will man echte Plattformunabhängigkeit? Wie sieht es mit möglichen SW-Patenten aus, wer hat in der Entwicklung die Macht? (z.B. java community process ), usw...

technisch wird sich das nicht viel nehmen.... außer das man halt relativ stark an MS gebunden wird....
mit Java 7 gab es übrigens recht viele Neuerungen.
 
Reine Vermutung: da Java einfach zu erlernen ist, wird es ähnliche Probleme wie Pyhton oder auch PHP haben. Es gibt Entwickler wie Sand am Meer - aber nur ein winziger Teil davon wird Ahnung davon haben was er tut. Auch logisch, da Java keine systemnahe Sprache ist und man sich mit bestimmten Elementen nicht auseinandersetzen muss.

Wer braucht denn heutzutage noch Systemnahe Entwicklung? In solchen Benchmarkthreads wird immer über harte Echtzeit geredet um eine Sprache über eine andere zu heben, wobei der Anwendungsfall extrem klein ist. Ohne Frage hat so etwas seine Daseinsberechtigung, aber es kommt immer ganz darauf an, was man tun möchte.

In wie fern Java nun viel leichter zu erlenen sein soll, wie C++ ist ohnehin rätselhaft. Die Syntax ist bis auf ein paar extreme Beispiele in fast allen Sprachen ähnlich und wenn man grundlegende Konzepte verstanden hat, kann man nach belieben die Sprache wechseln und muss sich nur noch auf die Eigenheiten einstellen.
 
Wer braucht denn heutzutage noch Systemnahe Entwicklung? In solchen Benchmarkthreads wird immer über harte Echtzeit geredet um eine Sprache über eine andere zu heben, wobei der Anwendungsfall extrem klein ist. Ohne Frage hat so etwas seine Daseinsberechtigung, aber es kommt immer ganz darauf an, was man tun möchte.

Spieleentwickler, OS-Entwickler, bestimmte Applikationsentwickler (Dinge wie z.B. ein Photoshop, ein 3dsm, ...), ... - such dir was aus.

In wie fern Java nun viel leichter zu erlenen sein soll, wie C++ ist ohnehin rätselhaft.
Dann hast du C++ nicht verstanden, sorry. Ein paar Keywords einer Sprache zu kennen, heißt noch lange nicht, die Sprache zu beherrschen. Ergebnis solcher "lustigen Sprachensprünge" sind in den meisten Fällen einfach nur minderwertige Quellcodes...
 
Spieleentwickler, OS-Entwickler, bestimmte Applikationsentwickler (Dinge wie z.B. ein Photoshop, ein 3dsm, ...), ... - such dir was aus.

Und weiter? Nehmen wir die Spieleentwickler mal raus, weil die in den meisten Fällen gegen eine Engine entwickeln. Das sind nen paar Prozent. Bei harter Echtzeit kommen vllt. noch die SPS Jungs dazu, aber sonst? Abseits dessen gibt es wenige Fälle, in denen eine Sprache nötig ist, die solche Features bietet. In den meisten Fällen ist es dann eher so, dass einem Entscheidungsträger erzählt wird, dass Sprache x viel schneller ist als y also entscheidet er sich für diese. Während der Entwicklung fällt dann auf, dass der zusätzliche Overhead zu groß ist. Das Ergebnis sind dann entweder erhöhte Kosten, oder ein Bugverseuchtes Produkt.

Ein paar Keywords einer Sprache zu kennen, heißt noch lange nicht, die Sprache zu beherrschen.
Vollkommen klar. Mir geht es auch nicht primär darum die Sprachen zu switchen, sondern eine neu zu erlernen. Wo sind da die riesen Unterschiede im Vergleich? Was in C++ hält dich so lange auf, dass du sagen kannst, dass Java so viel leichter zu erlernen ist?
 
Echtzeit kann übrigens auch ein Jahr sein :-D , solange der Kontrakt eingehalten wird...

Klar dauert es eine Sprache zu beherrschen, wer jedoch z.B. Compilerbau / Formale Sprachen verinnerlicht hat, für den ist der Rest nur Syntax... alles andere ist gleich, da turingvollständig.
Es gibt ja auch noch transcompiler z.B. LLVM usw. dann wird die Frontendsprache noch unwichtiger. Facebook hat ja mit HipHop (php to c ) wohl auch sehr viel Erfolg gehabt.

Insofern ist die Diskussion über die "richtige" Sprache schon etwas albern.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh