Wie viel Aufwand, um für mehrere OS zu entwicklen?
-
C++ hat seine Anwendungsgebiete, managed Sprachen wie Java und C# auch. Es gibt Bereiche wo man nicht klar sagen kann, welche der Sprachen im Vorteil ist, in anderen Bereichen haben native oder managed Sprachen deutliche Vorteile.
Welche Vorteile welcher Sprache bei dir überweigen kann dir wegen fehlender Infos keiner sagen. "Ich möchte so ungefähr nichts genaues will nichts verraten, kann mir jemand genau sagen was ich brauche?"
So oder so befürchte ich allerdings, dass du dir das zu einfach vorstellst. Mit zwei Jahren C++ wirds hart was größeres auf die Beine zu stellen. Dann sowas beeindruckendes hinzubekommen, dass du von Spenden aus der Open-Source Gemeinde leben kannst, wird nochmal ein paar Größenordnungen härter. Im Vergleich dazu ist es ein Klacks, Portabilität sicherzustellen.
Portablen Code zu schreiben ist nicht schwer. Du musst nur irgendwann im Laufe deines Projektes den Build-Prozess für die anderen Plattformen aufsetzen. Der Code ist kein großer Anteil. In dem Projekt, in dem ich arbeite, wird für mehrere Plattformen entwickelt. Hauptentwicklung unter Windows, andere Plattformen sind z/OS, AIX, Linux, HPUX, also auch durchaus unterschiedliche Compiler. Dazu unterschiedliche Datenbanksysteme, d.h. auf den einzelnen Plattformen haben wir zwei verschiedene Builds für die beiden DB-Systeme. Entwickelt wird in Java und C++. Der Aufwand für die Portierung auf die anderen Systeme ist jetzt, wo die Buildprozesse stehen, bei geschätzt einem Prozent.
Wie oben schon gesagt wurde ist das wichtigste, Plattformabhängigkeiten wegzukapseln. Das bedeutet, plattformunabhängige Bibliotheken zu benutzen, keine windows.h etc. einzubinden, kein C++/CLI benutzen (manche verwechseln das mit C++). Bei C++ muss dir vorher auch noch klar sein, für welche Compiler du entwickeln willst. Je nachdem wird dir TR1 und/oder C++11 zur Verfügung stehen, andere Compiler sind noch nicht so weit. Du legst damit ja auch Restriktionen für die User fest, die entsprechende Compiler haben müssen, die den Code übersetzen können. Für open source würde ich mich vielleicht sogar auf C++03 und eine Handvoll BOOST Bibliotheken beschränken.
Java ist auch nicht unproblematisch: Die wechseln ihre Subversionsnummern häufgier als andere die Unterhosen. Je nach JVM ändert sich dabei das Verhalten von einzelnen Bibliotheken ein ganz kleines Bisschen. Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen, ob dein Code auf anderen Subversionen das gleiche Verhalten hat. Bei uns in der Firma hats dafür gesorgt, dass Firefox nicht mehr zu den Referenzplattformen zählt.
Vieles zu beachten also. Der Aufwand für die Anpassung des Codes auf andere Plattform ist dazu vergleichsweise klein.
-
pumuckl schrieb:
Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen (...)
Huch?
Die Applikation kann doch ihre eigene JVM/JRE mit ausliefern, also ganz genau kontrollieren mit welcher Version sie läuft.
Zumindest unter Windows gibt es diese Option, und auf anderen Systemen sollte das doch genau so gehen, nicht?
-
Ich nehme mal an pumuckl spricht von Applets.
-
Hi,
soweit ich weis sind die neuen Embarcadero-Programmierumgebungen mit FireMonkey auch portabel. Kann Dir aber nicht sagen was der heiße Affe wirklich bringt.
Aber Du hast zumindest mit Delphi und C++ zwei sehr vernünftige Programmierumgebungen.Gruß Mümmel
-
Namenloser Held schrieb:
Eine Art Browser oder Dateimanager.
Dann kannste Java oder auch zusätzliche nicht nativ laufende GUI APIs gleich vergessen, denn ich habe keine Lust, > 10 Sekunden auf den Dateimanager zu warten, bis der endlich gestartet ist.
Java Programme haben es nämlich so ansich, daß sie erstmal > 30 Sekunden zum Start brauchen, weil ja erstmal die JVM geladen werden muss.
Für nicht nativen GUI APIs, wie z.B: Qt unter Windows gilt das selbe.
Dein Qt basierter Dateimanager wäre also lediglich unter KDE schnell gestartet und unter Gnome würde es schon wieder schlecht aussehen.Genaueres will ich noch nicht sagen. Es dauert noch lange, bis ich das Projekt starte und will nicht, dass mir wer die Idee wegnimmt, da sie mein Einkommen sichern soll.
Das was du vorhast, haben nur wenige geschafft.
Insbesondere bei reinen Endanwender Anwendungssoftware.Schau dir als Beispiel mal den Typen von Ardour 2.0 an, der werkelt an seinem Open Source Musikprogramm und lebt von spenden.
Reicht wirst du dadurch allerdings wohl eher nicht.Und der Typ von Cinelerra ist wohl eher an diesem Finanzierungsmodell gescheitert.
Er arbeitet zwar weiterhin an seinem Videoschnitteditor, aber die Entwicklung läuft so schleppend und bei den Features wird nur das notwendigste gemacht, während die Usability darunter leidet, daß ih fest glaube, daß er seinen Lebenunterhalt noch mit Nebenprojekten finanzieren muss.Denn wäre dies anders, dann würde die Entwicklung bei Cinelerra anders verlaufen.
Dazu kommt dann noch, das einige dieser Entwickler einen anderen Lebensunterhalt haben und z.B. nicht in München Deutschland wohnen, sondern irgendwo anders, wo der Lebensunterhalt auch deutlich günstiger ist.
Auch dies gilt es zu beachten.Die Spenden müßtest du dann übrigens vermutlich noch versteuern.
Fazit:
Das mit dem Open Source & Geld verdienen rechent sich meistenst nur als Dienstleistung und nicht für die Entwicklung von Endanwendersoftware, daher würde ich mir das gut überlegen.Gegen ein Freizeitprojekt spriht allerdings nichts, wenn du Lust hast, deine Freizeit dafür zu opfern.
Ansonsten würde ich eher den klassischen Closed Source Weg wählen, der Nachteil wäre dann nur, daß dein Programm dann sicherlich nur geringe Verbreitungschancen hätte.
Denn für einen Dateimanager würde zumindest ich kein extra Geld zahlen wenn Wincows & Co bereits einen mitliefern, der meinen Anforderungen durch Gewöhnung eigentlich genügt.
-
Ach ja und nicht zu vergessen.
Mit Open Source sind Forks möglich.
Cinelerra-CV ist z.B. ne Abspaltung von Cinelerra und wird von der Community in der Freizeit entwickelt.
Die Usabilty von Cinelerra-CV ist daher auch besser und der Originalautor von Cinelerra hat's noch schlechter, für seine Programmierung bezahlt zu werden.
-
hustbaer schrieb:
pumuckl schrieb:
Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen (...)
Huch?
Die Applikation kann doch ihre eigene JVM/JRE mit ausliefern, also ganz genau kontrollieren mit welcher Version sie läuft.
Zumindest unter Windows gibt es diese Option, und auf anderen Systemen sollte das doch genau so gehen, nicht?ja, dachte ich auch als ich fuer jemanden ein spielchen implementierte, lief auch ueberall.... bis auf bei ihm.
er hat macosx (weswegen ich erst das 'platformunabhaengige' java genommen hatte). hab dann festgestellt er hat nur 1.5, ich hatte es fuer 1.6 gebaut und auf macosx wird die version vom OS updater verwaltet. was apple drauf installiert ist sacheplatformunabhaengig programmieren ist an sich nicht so der warnsinn, wenn man es von anfang an macht und weiss wie es geht (ich spreche von c++). allerdings steigt mit jeder platform natuerlich der aufwand alles zu testen, ich persoenlich versuche zwar immer linux/win/osx compatibel zu programmieren, sodass ich nur wenige dinge fixen mueste falls ich die platform wechsel, meistens erstelle und verteile ich die versionen nur fuer ein OS.
-
Meine Meinung schrieb:
Ach ja und nicht zu vergessen.
Mit Open Source sind Forks möglich.
Cinelerra-CV ist z.B. ne Abspaltung von Cinelerra und wird von der Community in der Freizeit entwickelt.
Die Usabilty von Cinelerra-CV ist daher auch besser und der Originalautor von Cinelerra hat's noch schlechter, für seine Programmierung bezahlt zu werden.Mir der richtigen Lizenz lässt sich das vermeiden.
-
Wo sind die Mods eigentlich? Da fragt jemand explizit nach platformunabhängiger Programmierung und sofort wird C# empfohlen obwohl alle wissen dass Mono einfach nur rückständig ist.
Es gibt ungefähr 6455555555555555599 platformunabhängige Programmiersprachen udn heir wird C# empfohlen?
Liebe Mods, löscht bitte solche Trolle. Diese wollen nichts dem Thema beitragen, sondern nur ihre Ideologie aufzwingen.
-
oooooooooooooooo schrieb:
Liebe Mods, löscht bitte solche Trolle. Diese wollen nichts dem Thema beitragen, sondern nur ihre Ideologie aufzwingen.
Look who's talking
-
Wieso sollte C# mit Mono keine Option sein? Wenn die Features ausreichen (im wesentlichen fehlt ja nur WPF, ansonsten ist das Basisframework fast aufm gleichen Stand wie die MS Implementierung), dann hat man mit Mono ne leichte Möglichkeit für viele Plattformen zu entwickeln. Grad was den Buildprozess angeht, ist der sogar wesentlich einfacher als bei nativen Sprachen, da nicht für jede Plattform extra Kompilate erstellt werden müssen, sondern das ja der JIT Compiler bei der Ausführung erledigt.
-
Ethon schrieb:
Meine Meinung schrieb:
Mit Open Source sind Forks möglich.
Mir der richtigen Lizenz lässt sich das vermeiden.
Gemäß Absatz 3 hiervon nicht:
http://opensource.org/docs/osd
-
dot schrieb:
oooooooooooooooo schrieb:
Liebe Mods, löscht bitte solche Trolle. Diese wollen nichts dem Thema beitragen, sondern nur ihre Ideologie aufzwingen.
Look who's talking
Inwiefern ist das empfehlen einer platformabhängigen programmiersprache, wenn nach platformunabhängigkeit gefragt ist, kein trollen?
Werd erwachsen fanboy
-
Schau dir die von Mono unterstützten Plattformen an, und dann erklär bitte nochmal warum du denkst, dass C# mit Mono keine plattformunabhängigkeit bietet.
oooooooooooooooo schrieb:
...obwohl alle wissen dass Mono einfach nur rückständig ist.
Das liegt nur daran, dass du keine Ahnung hast auf welchem Entwicklungsstand Mono ist. Außerdem, rückständig in Bezug auf was? Man könnte z.B. ganz provokant formulieren, dass C++ im Vergleich zu Java oder .Net rückständig ist, da es kein Standard GUI Framework gibt. Oder Java im Vergleich zu C# rückständig ist, da es kein Linq gibt. Oder C# rückständig im Vergleich zu C++ ist weil es nur Generics kennt, und keine Templates. usw. Wie du siehst sind einfache Aussagen wie "ist rückständig" völlig nichtsaussagend.
-
Meine Meinung schrieb:
Dann kannste Java oder auch zusätzliche nicht nativ laufende GUI APIs gleich vergessen, denn ich habe keine Lust, > 10 Sekunden auf den Dateimanager zu warten, bis der endlich gestartet ist.
Java Programme haben es nämlich so ansich, daß sie erstmal > 30 Sekunden zum Start brauchen, weil ja erstmal die JVM geladen werden muss.
warum lügst du hier so dreist rum?
-
Zwergli schrieb:
Schau dir die von Mono unterstützten Plattformen an, und dann erklär bitte nochmal warum du denkst, dass C# mit Mono keine plattformunabhängigkeit bietet.
oooooooooooooooo schrieb:
...obwohl alle wissen dass Mono einfach nur rückständig ist.
Das liegt nur daran, dass du keine Ahnung hast auf welchem Entwicklungsstand Mono ist. Außerdem, rückständig in Bezug auf was? Man könnte z.B. ganz provokant formulieren, dass C++ im Vergleich zu Java oder .Net rückständig ist, da es kein Standard GUI Framework gibt. Oder Java im Vergleich zu C# rückständig ist, da es kein Linq gibt. Oder C# rückständig im Vergleich zu C++ ist weil es nur Generics kennt, und keine Templates. usw. Wie du siehst sind einfache Aussagen wie "ist rückständig" völlig nichtsaussagend.
Rückständig in Bezug zum C# unter windows. Und das ist unsinn. wozu diesen unsinn auf sich nehmen wenn man gleich eine platformunabhängige sprache nehmen kann.
Wenn du einen Familienwagen willst, dann kaufst du dir doch beim Autohändler einen Familienwagen und nicht einen kleinwagen den du mühsam umfrickeln musst.
leute wenn ihr keine ahnung habt haltet einfach die klappe. c# mag unter windows toll sein aber außer halb ist es nicht zu gebrauchen. Wer platformunabhängig programmieren will sollte eine entsprechende sprache nehmen
-
ooooooooo schrieb:
leute wenn ihr keine ahnung habt haltet einfach die klappe. c# mag unter windows toll sein aber außer halb ist es nicht zu gebrauchen. Wer platformunabhängig programmieren will sollte eine entsprechende sprache nehmen
Anstatt einfach zu behaupten dass "es nicht zu gebrauchen ist", wie wärs zur Abwechslung mit ein paar Argumenten?
Da du ja offenbar einiges an Erfahrung mit Mono hast, wird dir da doch sicherlich einiges einfallen?Das mit der plattformunabhängigen Sprache ist eben ein Problem. C++ und Qt wär z.B. eine portable Lösung, auch wenn ich persönlich kein Fan von Qt bin...
-
Blöd nur, dass plattformunabhängige Programmierung immer der Kleinwagen ist, da man, egal welche Technologie, immer nur auf den kleinsten gemeinsamen Nenner der Zielsysteme setzen muss. Und da ist Mono auch nicht schlechter als z.B. C++ - mit beiden Plattformen musst du z.B. erstmal nen GUI Framework finden was die Zielplattformen unterstützt. Auf welche Technologie sollte man denn deiner Meinung nach setzen?
-
@ooooooooo: Mich würden auch deine Erfahrungen interessieren, die du mit Mono gemacht hast, ich habe nämlich in Foren meist positive Erfahrungsberichte gelesen.
-
lolhehe schrieb:
Meine Meinung schrieb:
Dann kannste Java oder auch zusätzliche nicht nativ laufende GUI APIs gleich vergessen, denn ich habe keine Lust, > 10 Sekunden auf den Dateimanager zu warten, bis der endlich gestartet ist.
Java Programme haben es nämlich so ansich, daß sie erstmal > 30 Sekunden zum Start brauchen, weil ja erstmal die JVM geladen werden muss.
warum lügst du hier so dreist rum?
Ich lüge nicht, das ist Fakt.
Kauf dir ne entsprechende Festplatte und messe es aus.Die JVM muss extra gestartet werden, sie ist kein Teil von Windows.