# Welche Programmisprache für den Desktop?



## V.24 (21. Nov 2010)

Mit welcher Programmisprache würdet ihr Programme für den Desktop entwickeln?

Ich finde die Java Plattform nach wie vor äußert gut, doch außerhalb von Servern kann man Java ja fast vergessen... 
Entweder das ständige Updaten hat die Anwender dazu gebracht das vorinstallierte Java rauszuhaun oder es ist doch wieder so alt, dass man auf Java 5.0 oder älter zurückgreifen muss. Und anwenderfreundlich ist Java nun auch absolut nicht..

Daher überlege ich schon seit längerem auf eine andere Sprache/Plattform zu wechseln. 
Betriebsystem-Unabhängigkeit mögliche ich eigentlich nicht missen, das ist doch der Clue an Java - der aus oben genannten Fällen aber in allzuvielen Fällen nicht greift..

Habt ihr euch darüber schon gedanken gemacht und in welche Richtung könnte man aktuell gehen?


----------



## XHelp (21. Nov 2010)

Kann deine Argumente, die gegen Java sprechen, nicht wirklich nachvollziehen. Wenn du plattformunabhängig das ganze machen willst, dann hast du ja gar nicht so große Auswahl. Du kannst zwar selbst Delphi-Sachen mit Kylix für Linux kompilieren, aber so richtig plattformunabhängig ist es dennoch nicht. C# kannst du dir noch angucken...


----------



## Marcinek (21. Nov 2010)

Ich experimetiere gerade auch mit C#.NET.

Aber ich kann nicht sagen "YES- That's it". Denke, dass sich das in den kommenden Monaten noch genauer zeigen wird.

Ich habe hier den Vorteil dass ich das auf Windows Maschinen schnell deployen kann, weil es da immer spezielle Bereitstellungs Projekte gibt.

In Java wollte ich mich demnächst mit RCP beschäftigen. Kann erstmal sagen, dass für kleine Projekte sich das auf keinen Fall lohnt. 

Ich kann jedenfalls nicht nachvollziehen, wieso man Java außerhalb von Servern "vergessen" kann.. "Vermutlich machst du es nicht richtig"


----------



## V.24 (21. Nov 2010)

C# hatte ich auch schon ins Auge gefasst, jedoch stört mich Mono. Mono, das freie Pendant zu Microsofts .NET Plattform scheint mir einfach zu weit weg von der aktuellen Microsoft Implementierung und daher nur für Windows zu gebrauchen.. 

Hat jemand Erfahrung mit Adobe AIR? 

Kylix... ist das letzte Release nicht von vor zehn Jahren?


----------



## Marcinek (21. Nov 2010)

Schaue mal nach, ob die Anwendung nicht Webbasiert sein kann.

Ich mache atm viel mit Dynamics CRM und die Tatsache, dass der Client voll Webbasiert ist findet vielerseits auf zustimmung, aufgund der geringen Wartung.


----------



## slawaweis (21. Nov 2010)

V.24 hat gesagt.:


> Mit welcher Programmisprache würdet ihr Programme für den Desktop entwickeln?


das kommt ganz auf die Anforderungen an.



V.24 hat gesagt.:


> Ich finde die Java Plattform nach wie vor äußert gut, doch außerhalb von Servern kann man Java ja fast vergessen...
> Entweder das ständige Updaten hat die Anwender dazu gebracht das vorinstallierte Java rauszuhaun oder es ist doch wieder so alt, dass man auf Java 5.0 oder älter zurückgreifen muss. Und anwenderfreundlich ist Java nun auch absolut nicht..
> 
> Daher überlege ich schon seit längerem auf eine andere Sprache/Plattform zu wechseln.
> Betriebsystem-Unabhängigkeit mögliche ich eigentlich nicht missen, das ist doch der Clue an Java - der aus oben genannten Fällen aber in allzuvielen Fällen nicht greift..


vielleicht muss man sich wirklich einfach ein paar Monate mit anderen Sprachen beschäftigen, um die Vorteile von Java besser zu verstehen. Das die Anwender überhaupt merken, dass ein Programm Java benötigt, liegt daran, dass die Programmierer geschlampt haben. Man kann auch Java-Programme mit beigefügten JVM ausliefern, falls der Anwender diese nicht installiert hat. Weiterhin können Swing-Oberflächen richtig gut aussehen:

https://substance-samples.dev.java.net/docs/cookbook/overview.html



V.24 hat gesagt.:


> Habt ihr euch darüber schon gedanken gemacht und in welche Richtung könnte man aktuell gehen?


JavaScript, Ajax, CSS und HTML5.

Slawa


----------



## Wildcard (21. Nov 2010)

> In Java wollte ich mich demnächst mit RCP beschäftigen. Kann erstmal sagen, dass für kleine Projekte sich das auf keinen Fall lohnt.


Das stimmt so absolut nicht. Gerade kleine, modelorientierte Anwendungen lassen sich dank der Toolchain mit und um EMF nahezu komplett generieren ohne eigenen Code zu schreiben.
Und selbst wenn man Eclipse Modeling ganz ausser Acht lässt, wer sich ein bischen in RCP eingearbeitet hat kommt mit RCP fast immer schneller zum Ziel als Anwendungen from scratch zu schreiben. 
Die modulare Architektur erlaubt dann das sich auch aus kleinen Anwendungen große Projekte entwickeln können ohne alles umwerfen zu müssen.
There are no small Applications - only small Minds.


----------



## Marcinek (22. Nov 2010)

Wildcard hat gesagt.:


> Das stimmt so absolut nicht. Gerade kleine, modelorientierte Anwendungen lassen sich dank der Toolchain mit und um EMF nahezu komplett generieren ohne eigenen Code zu schreiben.
> Und selbst wenn man Eclipse Modeling ganz ausser Acht lässt, wer sich ein bischen in RCP eingearbeitet hat kommt mit RCP fast immer schneller zum Ziel als Anwendungen from scratch zu schreiben.
> Die modulare Architektur erlaubt dann das sich auch aus kleinen Anwendungen große Projekte entwickeln können ohne alles umwerfen zu müssen.
> There are no small Applications - only small Minds.



Kannst du das Iwie belegen??

Hast du Untersuchungen angestellt / gelesen, die Aussagen, dass man mit der EMF Bazooka, und RCP Mammut immer schneller zu seinem gewünschten Ergebnis kommt?

Ich stimme dir zu, dass aus kleinen Projekten schnell mal große werden können, aber das muss man als Entwickler schon vorher wissen / herausfinden / analysieren, sonst ist das ehh fail.

Wir haben ein Tool zur DDL Migration geschrieben fast von Scratch... Das wird in 100 Jahren nicht über diese Spezifikation kommen. Es ist klein < 10k LOC. Und hat bereits Möglichkeiten zur Erweiterung, falls sie den mal kommen. Aber nur im Rahmen seiner Bestimmung. Es wird z.B. keine Datenmigration beinhalten.

Ich kann also damit "There are no small Applications - only small Minds." - bla bla Spruch wiederlegen.


----------



## JohannisderKaeufer (22. Nov 2010)

C# mit WindowsPresentationFoundation und Air/Flex mit mxml wird die GUI per XML definiert.
Das macht schon einen großen Unterschied, im Gegensatz zu Swing, bei dem das meist im Java Code vonstatten geht. 
Es ist ein wenig vergleichbar mit JSF, wenn man einen Renderer hätte, der statt HTML eine Swing Anwendung erstellt. 

Trennung von View und Model per Design. Und eben die Definition in XML machen das ganze recht übersichtlich in der Entwicklung. Der Ansatz hat was.

RCP finde ich recht cool. Man muss es allerdings beherrschen. An welcher Stelle mache ich was? Alles hat dort seinen Platz an den es Hingehört. Und wenn man weiß wo etwas hingehört kann man damit mit Sicherheit sehr schnell sein. Das nächste ist, das wenn man RCP nutzt, dann benutzt man auch die IDE und die darin vorhandenen Möglichkeiten. Code Templates, Projektvorlagen eben die gesamte Toolchain schaffen es die zweite und dritte RCP mit ziemlicher Sicherheit schneller fertigzustellen als die erste.

Darüber hinaus bringt eine RCP von Haus aus schon deutlich mehr mit, als man in Swing selbst unterbekommt. Angefangen vom Hilfe System, Updates, Plugins, GUI Anpassbarkeit, Einstellungsdialoge, etc. Wollte man das alles in seiner Swing Anwendung unterbringen, dann hätte man ganz schön was zu tun.

Und um zu dem Beispiel mit der Bazooka und dem Mamut zu kommen.

Wenn du einen Ferrari in der Garage hast, dann bestellst du keinen Smart um kurz Einkaufen zu fahren.


----------



## Wildcard (22. Nov 2010)

> Kannst du das Iwie belegen??
> 
> Hast du Untersuchungen angestellt / gelesen, die Aussagen, dass man mit der EMF Bazooka, und RCP Mammut immer schneller zu seinem gewünschten Ergebnis kommt?


Belegen? Zum einen durch jahrelange Erfahrung Applikationen mit und ohne RCP, zum anderen ergibt sich das schon aus reiner Logik: 
-Je mehr fertige Bausteine du hast, umso weniger Code musst du selbst schreiben
-Je weniger du selbst erledigen musst, desto effizienter arbeitest du
Diese Gleichung funktioniert natürlich nur wenn du mit deinen Werkzeugen vertraut bist, das versteht sich von selbst. Investiert man allerdings die Einarbeitungszeit (konstanter Aufwand), dann zahlt sich das für alle zukünftigen Projekte aus.

Das ich zB mit EMF deutlich effizienter bin weiß ich einfach, da ich mittlerweile dutzende von EMF Modellen erstellt habe und der Produktivitätsgewinn einfach enorm ist. Oder schau dir Xtext an. Innerhalb von 1 Stunde hast du Lexer, Parser, Linker, Modell, Editor mit Autocompletion, Outline, Folding, Cross-Referenzen, Highlighting, Hyperlinks,...
Mach es von Hand und du brauchst, selbst wenn du gut bist, Wochen dafür.

Zum Thema Mammut und Bazooka, EMF ist AFAIR ca 2 MB groß, und wenn man EMF freien Code generiert braucht man zur Laufzeit gar keine zusätzlichen Bibliotheken. Auf Equinox aufzusetzen bedeutet etwa 3 MB Runtime, RCP ca. 15 MB. Vergleicht man das mit der Größe eines Tomcat, oder JBoss, würde ich nicht gerade von einem Mammut sprechen.


----------



## ARadauer (22. Nov 2010)

slawaweis hat gesagt.:


> https://substance-samples.dev.java.net/docs/cookbook/overview.html


sehr geil!


----------



## bronks (22. Nov 2010)

slawaweis hat gesagt.:


> ... https://substance-samples.dev.java.net/docs/cookbook/overview.html ...


Was ist das für eine widerliche und verwaschene Schriftart? Wie kann man sowas jemanden antun? Da habe ich absolut kein Verständnis dafür. Aber OK, ist ja nur ein Kochbuch, wo man nicht den ganzen Arbeitstag ununterbrochen reinschaun muß.


----------



## SlaterB (22. Nov 2010)

XHelp hat gesagt.:


> Kann deine Argumente, die gegen Java sprechen, nicht wirklich nachvollziehen. Wenn du plattformunabhängig das ganze machen willst, dann hast du ja gar nicht so große Auswahl.



inwiefern sind eigentlich andere Hochsprachen wie C gegenüber Java nicht plattformunabhängig? 
es mag einige spezielle Abhängigkeiten geben, welche dann in Java ganz außen vor gelassen werden,
aber ist dort nicht auch ein Grundstock an Rechnen, Datenstrukturen, einfache Benutzeroberflächen usw. im Quellcode gleich?

wenn ich ein wahlloses Beispiel aus dem Internet wie
C sample code - Program to calculate Area of a Polygon - Source code examples
wähle, dann steht da ja nicht dran 'funktioniert nur unter Windows'..

dass man vielleicht den Quellcode je Betriebssytem neu kompilieren muss finde ich nicht entscheidend gegenüber einer kompletten JVM-Installation,
bei Änderungen muss man in beiden Fällen an den Quellcode ran


----------



## code404 (22. Nov 2010)

Marcinek hat gesagt.:


> Kannst du das Iwie belegen??
> ...
> Hast du Untersuchungen angestellt / gelesen, die Aussagen, dass man mit der EMF Bazooka, und RCP Mammut immer schneller zu seinem gewünschten Ergebnis kommt?



Ich kann aus Erfahrung auch nur zustimmen. 
WENN man RCP (und damit verbundenen Technologien) beherrscht, DANN kommt man vor allen bei kleineren Projekten rasend schnell ans Ziel.

Zurück zur Frage des Threadstarters:
Meine zweite Wahl (nach JAVA) wenns Plattformunabhänig sein muss: Qt
Dann wird man sich immer wieder bewusst wie komfortabel man in JAVA unterwegs ist ;-)


----------



## ThreadPool (22. Nov 2010)

SlaterB hat gesagt.:


> inwiefern sind eigentlich andere Hochsprachen wie C gegenüber Java nicht plattformunabhängig?
> es mag einige spezielle Abhängigkeiten geben, welche dann in Java ganz außen vor gelassen werden,
> aber ist dort nicht auch ein Grundstock an Rechnen, Datenstrukturen, einfache Benutzeroberflächen usw. im Quellcode gleich?



Die "plattformunabhängigkeit" funktioniert da nur, wenn du dich bei z.B. bei C auf ANSI-C beschränkst, keine speziellen Erweiterungen von Compilern nutzt, keine Sonderfunktionen nichts... . Dann kannst du den Code auch problemlos für ein anderes System kompilieren und linken, das musst du in jedem Fall tun. In z.B. C ist Alles so Low-Level das wenn du ein Fensterchen machen möchtest du schon direkt auf das OS zurückgreifen musst, es sei denn du nimmst dir ein Framework her das für verschiedene Systeme portiert ist. In Java ist es soweit "abstrahiert" das dort alles über einen "Emulator" erledigt wird, der natürlich auch für alle Zielsysteme umgesetzt werden muss. Ich würd das nicht so eng sehen mit dem Buzzword "plattformunabhängigkeit" wenn ich für meinen Gameboy, für verschiedene Systeme, einen Emulator schreibe ist der auch plattformunabhängig.


----------



## musiKk (22. Nov 2010)

code404 hat gesagt.:


> WENN man RCP (und damit verbundenen Technologien) beherrscht, DANN kommt man vor allen bei kleineren Projekten rasend schnell ans Ziel.



Und das wird imho gerne übersehen. Ich habe das Gefühl, dass die meisten, die es beherrschen, die Einarbeitungszeit vergessen haben (oder Naturtalente sind).



ThreadPool hat gesagt.:


> Die "plattformunabhängigkeit" funktioniert da nur, wenn du dich bei z.B. bei C auf ANSI-C beschränkst, keine speziellen Erweiterungen von Compilern nutzt, keine Sonderfunktionen nichts... .



Also den GCC gibts z. B. für viele Platformen. Das gilt sicher für die meisten Compiler und Runtimes.



> es sei denn du nimmst dir ein Framework her das für verschiedene Systeme portiert ist.



Wurde schon angesprochen: Qt, GTK+, wxWidgets, tk, Apache Portable Runtime ... Da gibt es viele Möglichkeiten.


----------



## Bierhumpen (22. Nov 2010)

bronks hat gesagt.:


> Was ist das für eine widerliche und verwaschene Schriftart? Wie kann man sowas jemanden antun? Da habe ich absolut kein Verständnis dafür. Aber OK, ist ja nur ein Kochbuch, wo man nicht den ganzen Arbeitstag ununterbrochen reinschaun muß.


Das nennt man Anti-Aliasing, und wenn dein Windowmanager das nicht kann, tust du mir echt leid. Substance bzw. Swing allgemein benutzt in der Regel das Font Rendering des Systems. Aber naja:

[edit SlaterB: Riesenbild entfernt]

edit: sorry, link zum riesenbild


----------



## SlaterB (22. Nov 2010)

bitte nicht solche verrückten Riesenbilder posten, dieser Thread ist doch in ganz normalen Rahmen, keine Spam-Schlacht


----------

