Kann mich nicht entscheiden: Java oder C++ ?
-
tfa schrieb:
Dabei ist längst bekannt, dass es unter Windows sowieso keine Programme gibt, die 100%g laufen - egal welche Sprache.
Ui, dies gilt ebenso wie für alle anderen Betriebssysteme (Gerade wenn man sich nicht an die dort üblichen Programmierkonventionen, und spezielle Gegebenheiten erfordert etc.).
Zum OP: Wenn Java in Frage kommt kann das .Net Framework auch kein KO-Kriterium sein (Zumindestens auf meinen Rechner nimmt sich dies bezüglich Frameworkgröße und Installationsaufwand nichts, aber auch gar nichts).
Wenn du möglichst wenig "Overhead" haben willst ist C++ tatsächlich recht gut geeignet - aber auch hier ist (ob nun statisch oder dynamisch gelinkt) eine Runtime Umgebung nötig. Leichter zu lernen und auch mit mehr Anfangserfolg ist Java und C#/.Net (Wie gesagt akzeptiere ich kein Argument gegen .Net wenn man ebenso mit Java spekuliert) - und hier kommt es eher auf persönliche Vorlieben an (Wobei ich unter Windows .Net, Plattformübergreifend Java vorziehen würde).
cu André
-
asc schrieb:
(Wie gesagt akzeptiere ich kein Argument gegen .Net wenn man ebenso mit Java spekuliert)
ausserhalb der windows-welt ist .NET so gut wie bedeutungslos und ausserdem zu 'mickrosoftig'-proprietär, um ein wirklich plattformunabhängiges system zu sein.
-
asc schrieb:
Wie gesagt akzeptiere ich kein Argument gegen .Net wenn man ebenso mit Java spekuliert
Und was ist mit dem Argument, dass es die JVM für wesentlich mehr Plattformen gibt als die CLR ?
-
~fricky schrieb:
ausserhalb der windows-welt ist .NET so gut wie bedeutungslos und ausserdem zu 'mickrosoftig'-proprietär,...
byto schrieb:
Und was ist mit dem Argument, dass es die JVM für wesentlich mehr Plattformen gibt als die CLR ?
Das Eingangsposting hattet ihr beide nicht gelesen, oder?
Also ich möchte Programme, die unter Windows 100%ig laufen... Plattformunabhängigkeit ist mir nicht so wichtig.
Zudem habe ich auch erwähnt das ich .Net auf den Windowsplattformen, und Java Plattformunabhängig vorziehen würde (wenn man C++ mal außen vor läßt).
-
asc schrieb:
Das Eingangsposting hattet ihr beide nicht gelesen, oder?
Doch habe ich, aber Deine Aussage hörte sich recht pauschal an.
-
asc schrieb:
Wenn du möglichst wenig "Overhead" haben willst ist C++ tatsächlich recht gut geeignet - aber auch hier ist (ob nun statisch oder dynamisch gelinkt) eine Runtime Umgebung nötig.
Wie kommt ihr immer dazu, die Runtime für C++ mit der Runtime von .Net oder Java in einem Atemzug zu nennen? Die Runtime für C++ ist ein paar mikrige Kilobyte groß und wird in der Praxis wahrscheinlich immer statisch gelinkt. (Erst bei Visual C++ 2005 war da die unsinnige Voreinstellung, bei der das nicht statisch gelinkt wurde, um weniger 100 KB zu sparen.) Konsolen- und WinAPI-Programme sollten ohne Probleme selbst auf einem frisch installierten Windows 95 laufen. Es sei denn, das Programm greift auf externe Bibliotheken zu. Aber dann ist es sowieso nicht mehr passend, diese Dinge mit .Net zu vergleichen, denn .Net ist das standardmäßige Basisprodukt, das man auf jeden Fall für C# braucht. Während so Zeugs wie die MFC ja externe Frameworks/Bibliotheken sind. Würde man analog mit C# auf externe Bibliotheken zugreifen, bräuchte man ja wiederum externe DLLs.
Der Vergleich C++-Runtime - .Net-Runtime hinkt total. Das .Net-Framework ist 80 MB groß, während man bei C++ sämtliche Standardheader und die windows.h benutzen kann, ohne dass das Programm 100 oder 200 KB dafür überschreitet. Und diese Runtime ist in der Regel statisch gelinkt, so dass man C++-Programme ohne weiteres weitergeben kann, während der Benutzer bei .Net erstmal das .Net Framework installieren muss.
Also hört auf, C++-Runtime und .Net-Runtime miteinander zu vergleichen, so als wäre das einander ähnlich. "Gut, bei C# muss man erst die Runtime installieren, aber bei C++ ist das ja auch so." FALSCH!!!
Und MFC und Konsorten sind externe Bibliotheken. Die gehören in diesen Vergleich sowieso nicht rein, denn wenn ich analog von externen Bibliotheken für .Net sprechen würde, bräuchte man dafür ja auch nochmal weitere DLLs.
-
mad schrieb:
Während so Zeugs wie die MFC ja externe Frameworks/Bibliotheken sind. Würde man analog mit C# auf externe Bibliotheken zugreifen, bräuchte man ja wiederum externe DLLs.
Du brauchst defakto solche externen Bibliotheken für C++. Deshalb ist es auch vernünftig die Runtime von C++ miteinzubeziehen.
natürlich ist die c++ runtime idR kleiner, aber komplett ignorieren kann man sie auch nicht.
-
mad schrieb:
asc schrieb:
Wenn du möglichst wenig "Overhead" haben willst ist C++ tatsächlich recht gut geeignet - aber auch hier ist (ob nun statisch oder dynamisch gelinkt) eine Runtime Umgebung nötig.
Wie kommt ihr immer dazu, die Runtime für C++ mit der Runtime von .Net oder Java in einem Atemzug zu nennen? Die Runtime für C++ ist ein paar mikrige Kilobyte groß und wird in der Praxis wahrscheinlich immer statisch gelinkt.
Dem "in der Praxis wahrscheinlich immer statisch gelinkt" widerspreche ich vehement. Gerade wenn Programme eine gewisse Größe erreichen, und in Einheiten (DLL...) getrennt werden, halte ich statisches Linken für die schlechtere Einstellung - und kenne es aus mittelgroßen Projekten (ab ca. 1 Mio Codezeilen) auch nicht.
Und wenn ich bedenke wie viele der Meinung mit dem statischen Linken sind, dann ist es durchaus legitim die C++ Runtime mit Java/.Net zusammen zu erwähnen. Denn insgesamt dürfte die Größe der Runtime, durch die vielen installierten Anwendungen, zusammen auch locker erreicht werden (Da sie ja nach deiner Meinung in der Regel statisch gelinkt werden).
mad schrieb:
Und MFC und Konsorten sind externe Bibliotheken. Die gehören in diesen Vergleich sowieso nicht rein, denn wenn ich analog von externen Bibliotheken für .Net sprechen würde, bräuchte man dafür ja auch nochmal weitere DLLs.
Nur das du bein .Net Framework (ebenso wie bei Java) im seltesten Fall auf externe Bibliotheken zurück greifen musst (das .Net Framework enthält alles wesentliche), und du in C++ in der Regel immer weitere Bibliotheken benötigst.
cu André
-
Und vorallem ist es keine virtuelle Maschine sondern meist nur eine enzelne kleine Bibliothek. Fuer C-Programme hat man ja auch 'ne "Runtime", dort wo malloc etc. zu finden ist. Spricht darueber irgendwer? Und mal ehrlich, wuerde jemand Java oder C# benutzen, wenn nicht so eine grosse Klassenbibliothek mitgeliefert wuerde?
-
knivil schrieb:
Und vorallem ist es keine virtuelle Maschine sondern meist nur eine enzelne kleine Bibliothek.
Die sich statisch gelinkt aber effektiv zu einem wahren Moloch entwickeln können (Kleinvieh macht auch Mist).
Davon abgesehen: Wieviele Anwendungen, die größer als Hilftools sind, kennst du, die keine externen Bibliotheken benötigen. Letztere rechne auch zum Teil ein, da in .Net/Java diese meist durch das Framework abgedeckt werden.
-
mad schrieb:
und wird in der Praxis wahrscheinlich immer statisch gelinkt.
Nee, das ist Quatsch. Wir linken hier nicht statisch (unser Software-Chef würde mir eins auf den Deckel geben
), und es gibt auch viele bekannte Mainstream-Software, die die Installation der Runtime in ihr Setup integriert hat. Bei vielen Spielen ist das z.B. auch so...
-
knivil schrieb:
Und mal ehrlich, wuerde jemand Java oder C# benutzen, wenn nicht so eine grosse Klassenbibliothek mitgeliefert wuerde?
Es gibt noch weitaus mehr Gründe für Java/C#, auch wenn wir das eigentliche Framework Beispielsweise auf den Umfang von der C++ Standardbibliothek reduzieren. Zumindestens möchte ich mich nicht mit COM & Co quälen, um Objekte über DLL Grenzen übergeben zu können. Ebenso werden viele C++ Macken erst im kommenden Standard teilweise ausgemerzt (I18N sei nur mal ein Thema).
Nein, weder C# noch Java sind der heilige Gral, aber ebenso auch nicht C++. Berufich entwickel ich unter C++, privat unter C# (da mit einer Ausnahme alle Bekannten Windowssysteme verwenden, und der Entwicklungsaufwand unter C# einfach geringer ist; Wäre die OS-Verbreitung anders, wäre wohl Java privat im Einsatz).
cu André
-
asc schrieb:
Davon abgesehen: Wieviele Anwendungen, die größer als Hilftools sind, kennst du, die keine externen Bibliotheken benötigen. Letztere rechne auch zum Teil ein, da in .Net/Java diese meist durch das Framework abgedeckt werden.
Gab.s da nicht mal was: steuererklaerung.exe? Oder wie heisst die?
-
asc schrieb:
Davon abgesehen: Wieviele Anwendungen, die größer als Hilftools sind, kennst du, die keine externen Bibliotheken benötigen.
Wobei es für den Windows-Anwender weitaus komfortabler ist, wenn bei der Installation eines C- oder C++-Programms ein paar kleine, unauffällige DLLs ins Programmverzeichnis mitinstalliert werden, als wenn von ihm verlangt wird, erst irgendwelche dutzende Megabyte großen Frameworks irgendwoher runterzuladen, von denen er gar nicht weiß wozu sie gut sind.
-
Eine JRE zu installieren, verlangt dem User ungefähr genauso viel ab, wie den Acrobat Reader zu installieren, wenn man PDFs angucken will.
Alles weitere wird ja mit der Anwendung deployed, insofern kA wovon Du sprichst.
-
namespace invader schrieb:
Wobei es für den Windows-Anwender weitaus komfortabler ist, wenn bei der Installation eines C- oder C++-Programms ein paar kleine, unauffällige DLLs ins Programmverzeichnis mitinstalliert werden, als wenn von ihm verlangt wird, erst irgendwelche dutzende Megabyte großen Frameworks irgendwoher runterzuladen, von denen er gar nicht weiß wozu sie gut sind.
Dem wiederspreche ich nicht, es gibt durchaus auch Gründe für den Einsatz von C++. Anderseits muss man natürlich auch den Entwicklungsaufwand abwägen (In der Regel ist die Entwicklungsproduktivität mit Java/C# gegenüber C++ unbestritten höher - wobei es natürlich Ausnahmen geben kann).
Nur ärgere ich mich immer wieder wenn man bei allem hin und her folgendes übersehen wird:
a) Gerade bei statischen Linken die Größenargumentation nicht greift.
b) Das man einerseits nichts gegen Java hat, aber sich aufregt das man das .Net Framework installieren müsse.Auch sehr interessant finde ich Argumente das Java ja fast überall beigelegt wird (mag stimmen, aktualisieren sollte man es aber auch), ich erinnere mich an einige Programme wo beim Installieren immer noch der Hinweis kommt das zusätzlich das (ebenso mitgelieferte) Java-Framework installiert werden muss. Dies ist also zumindestens in Bezug auf C#/Java kein Unterschied.
Hier würde ich eher nach den Plattformanforderungen entscheiden.
Bei großen Projekten fällt für mich aber die Entscheidung immer mehr gegen C++ aus, da man häufig durch die Frameworks einfach mehr in kürzerer Zeit schafft (Auch wenn ich in C# beispielsweise auch ein paar C++ Sprachbestandteile vermisse - ich sehe gerne an der Übergabe wo die Gefahr besteht das etwas geändert wird, wo Elemente per Kopie und wo per Referenz übergeben werden).
cu André
-
byto schrieb:
Eine JRE zu installieren, verlangt dem User ungefähr genauso viel ab, wie den Acrobat Reader zu installieren, wenn man PDFs angucken will.
Das mag sein, aber dennoch gebe ich "namespace invader" recht: Der Anwender fragt sich immer wieder warum zur Hölle man noch dies und jenes installieren muss. Meist geht es gar nicht soviel um das Installieren als solches, sondern die Frage nach dem warum.
Ich hatte da jemanden der ein Programm wegen der zusätzlichen Javainstallation (son Mist kommt mir nicht auf den Rechner) ein Programm abgeleht hat, aber unbedacht alle Browserplugins installiert hat.
cu André
-
byto schrieb:
Eine JRE zu installieren, verlangt dem User ungefähr genauso viel ab, wie den Acrobat Reader zu installieren, wenn man PDFs angucken will.
Beim JRE kann das ja sein, aber zunächst ist das bei .NET etwas anders, und außerdem neigen Abhängigkeiten dazu, sich in ungünstigen Momenten zur Last zu entwickeln.
Das letzte JRE, das ich installiert hatte, war beispielsweise inkompatibel mit einer Anwendung, die ich benutzte, so daß ich es wieder deinstalliert habe. Wahrscheinlich hätte ich mit ein wenig zusätzlichem Aufwand die beiden auch irgendwie parallel betreiben können, aber da fängt der Spaß ja schon an.
Bei .NET ist es infolge des inkrementellen Aufbaus und des MSI-Systems noch schlimmer. Der Uninstaller der VS2008-Shell war aus irgendeinem Grunde der Meinung, er müsse mir ein Chaos aus Framework-Addons und -SDKs zu Version 2.0 und höher hinterlassen, und davon ließ sich alles >= 2.0 dann nicht mehr deinstallieren - was aber für manche Anwendungen, die noch 1.1 benötigen, notwendig ist, da deren Installer sonst mit dem 2.0er in Konflikt gerät und desgleichen. Mit einem massiven Aufgebot an Zeit und entsprechenden Utilities war das Problem dann so weit zu bereinigen, daß heute 1.1 und 2.0 friedlich koexistieren - trivial ist das längst nicht mehr.Sicher, .NET bietet zweifellos gravierende Vorteile - aber unkompliziertes Deployment gehört nicht dazu.
-
nein, er will kein flameware, aber ihr macht trotzdem einen
schön, dass die dependency hell auch windows erreicht. eigtl. schade das abwärtkompatibilität nicht gewährleistet wird. egal jetzt ob .net oder java.
das gute an diesen frameworks ist ja eigentlich, dass man es nur einmal installieren braucht, und verschiedene anwendungen die gleiche runtime nutzen. theoretisch..
ich hab auf meiner kiste glaub 4 verschiede jre's installiert (sun jdk 5 und 6, open-jre und noch irgendeine 1.4 fürn uralt programm). ich hab ja platz aber toll ist das nicht.
in die gleichen probleme rennst du mit C++ aber auch, wenn du .dlls ausserhalb des standards benutzt (seis mfc, direct x oder was auch immer), die von mehreren programmen genutzt werden. iwie bleibt sich das gleich in allen sprachen.schlimmer wirds noch dadurch, dass einige programme C# wollen, andere Java und wieder eins libxyz.dll, so hat man schlussendlich x bibliotheken und y virtuelle maschinen, die eigentlich alle das selbe machen: fenster, buttons, filehandles, socks und dergleichen zur verfügung stellen.
schön wäre doch, eine einheitliche schnittstelle zwischen verschiedenen sprachen und verschiedenen plattformen. quasi eine superruntime
-
audacia schrieb:
Das letzte JRE, das ich installiert hatte, war beispielsweise inkompatibel mit einer Anwendung, die ich benutzte, so daß ich es wieder deinstalliert habe.
Vereinzelt kommt sowas vor und ist natürlich unschön. Aber es ist grundsätzlich problemlos möglich, mehrere JRE Versionen auf einem Rechner installiert zu haben. Natürlich muss man dann ggf. etwas anpassen, um Anwendungen gezielt mit einer speziellen JRE zu starten und nicht immer die aktuell im Classpath registrierte Version zu nehmen.