Plattformunabhängig programmieren

[Hisoka]

Zitat von mquadrat:

Wenn plattformunabhängig entwickelt werden soll, nehmen wir aktuell auch Java. Sind von Eclipse zu Netbeans gewechselt, weil da der GUI Builder brauchbar ist.

Mono hab ich mir noch nicht angeschaut, wird sicher eine Alternative sobald .NET 4 vollumfänglich unterstützt wird.

Das wird nur nie passieren. Das ist auch nicht das Ziel der Mono Entwickler.

Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

[creed steiger]

Zitat von Hisoka:

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

[Hisoka]

Zitat von creed steiger:

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

fpGUI und MSEgui integrieren sich mal gar nicht ins Betriebssystem. Mag vielleicht einigen egal sein, aber nicht jedem. Der Punkt ist aber, eine Neuentwicklung der Anwendung mit Python und PyGTK hatte mehr Funktionen und lief deutlich besser als die Pascal/LCL variante. Also da wurde das ganze einfach schlecht umgesetzt, denn die LCL zeichnet zu viele Sachen selbst, was dazu führt das eine große Menge an Ressourcen verschwendet werden. Wobei das GTK1 Interface nicht so schlimm ist, dafür ist es aber hässlich wie die Nacht.


Die Qt Variante könnte ganz brauchbar sein, hab mich mit der aber nicht so sehr beschäftigt, denn wenn ich mit Qt arbeite kann ich auch gleich was ordentliches nehmen und QtCreator wählen und damit die Anwendung erstellen. Die IDE ist wenigstens ausgereift, stabil und bei der direkten Qt Nutzung bekommt man eben noch mehr als nur eine Interface Bibliothek. Damit ist gemeint das die LCL die Möglichkeiten welche Qt bietet nicht nutzt.

[Unwissender]

Hallo fkerber,

was ist eigentlich der Ausgangspunkt der Debatte gewesen? Ich glaube Du sagtest, dass Du jetzt gelesen hast, das irgendwer sagt: "Java ist doof!" (ok, etwas vereinfacht ausgedrückt ).

Aber mal ganz ehrlich, hast Du das nicht schon mal gelesen? Seit ich mit Java arbeite habe ich das schon häufiger gelesen, trotzdem verdienen meine Kollegen und ich (und viele andere auch) ganz gut mit Java Programmierung ihr Geld und hey, unsere Kunden sind (meistens) ganz zufrieden. Wie in jedem Unternehmen gilt das nicht immer, aber noch kein Kunde hat sich wegen der Programmiersprache beschwert.

Ich meine das übrigens ernst und finde es wichtig für die Debatte. Den Kunden oder Deinem Geldgeber ist es in der Regel egal welche Programmiersprache Du verwendest. Für die bleibt letztlich eine Anforderung die sie erfüllt sehen wollen und die Frage was es kostet. Natürlich gibt es auch Leute die Dir vorschlagen nimm doch Technik X oder die nach einer Java-Anwendung fragen, die Folgendes kann, es ist jedoch nicht deren Aufgabe sich über die technische Umsetzung sorgen zu machen. Ist eine Java-Anwendung nötig, weil die eine eigen QS-Abteilung haben, die nur Java kann, den Quellcode mitkaufen und der eben dort geprüft wird, dann ist das Anforderung und wird mit Kosten berechnet. Wollen die nur Plattformunabhängigkeit (für eine definierte Auswahl von Systemen) bleibt es dem Auftragnehmer überlassen ob der für Linux in C, MacOS in Objective-C und Windows in Java programmiert/ programmieren lässt oder nicht.

Was jetzt also die (ewige?) Debatte um Java angeht, ob es gut oder schlecht ist, so gilt hier das gleiche wie für andere Sprachen auch, die Antwortet lautet: depends. Z.B. kann C++ super sein, wenn Du eine IDE für Windows schreibst (was nicht heißt das andere Sprachen nicht auch super dafür sein können!). Schreibst Du aber einen Linux-Kernel, ist es ungeignet (siehe Post).
Auch Java ist nicht die eierlegende Wollmichsau. Möchtest Du einen Treiber programmieren, ist eine abstrakte Ausführungsschicht so ziemlich das Ungeeignetste, was einem einfallen könnte, das gilt somit auch für .NET Sprachen/ die CLI oder Interpreter. Das versteht sich von selbst. Auch gibt es die ewig gleichen Gerüchte, dass Java besonders langsam ist (gilt schon sehr lange nicht mehr) oder dass die Entwicklung mit der Sprache X (gerne wird hier C# benannt) 30% schneller ist oder so.

Das ist alles so pauschal wie falsch. Es kommt immer darauf an, was Du machen möchtest. Einen ganz wichtigen Punkt hast Du ja schon benannt, Java ist schon fast überall installiert. Das darf (und sollte) man nicht unterschätzen. Natürlich kann man jetzt auf MyBlaster, Conficker oder I-Love-You verweisen, die waren auch weit verbreitet, aber irgendwie doch nur unter Windows (was für die weite Verbreitung von Windows spricht und nicht gegen das OS!). Bei den Dingen, die wie Java oder FireFox, eher freiwillig verbreitet werden, spricht aber eine gewisse Alleinstellung und/oder Qualität für das Produkt. Java gibt es jetzt auch schon ein paar Jahre und bis heute finden sich viele Firmen, die freiwillig auf die Sprache setzen oder die Laufzeitumgebung auf ihren Systemen installieren, trotz der "vielen Nachteile" über die man so gerne liest. Man kann also davon ausgehen, dass es auch Vorteile geben muss oder vielleicht nicht alles stimmt was Leute gerne so behaupten.

Wie schon erwähnt, auch Java hat bestimmte Einsatzzwecke, für die es sich besser eignet und solche, für die es ungeeignet ist. Am Stärksten wiegt immer die Abstraktionsstufe, die Java mitbringt. Java gut für solche Anwendungen, die eine hohe Abstraktionsebene benutzen (und das sind viele Fachanwendungen). Hier möchte man nicht eine bestimmte CPU direkt ansprechen, einen Scheduler selbst steuern oder Treiber bereitstellen, sondern schnell und effizient eine komplexe Problematik (in der fachlichen Domäne) umsetzen.
Hier wird man eher schauen welche Frameworks bereits zur Verfügung stehen und da ist Java einfach sehr gut aufgestellt. SourceForge z.B. hat immer noch deutlich mehr Java-Projekte als irgendwas anderes, JasperReports und Birt sind sehr gute Report-Generatoren, mit JSF gibt es eine gute Mölgichkeit komponentenbasiert Webanwendung (HTML nicht Applets!) zur Verfügung zu stellen, mit der JPA gibt es freie O/R Mapper. Ist so nicht ganz korrekt, denn Java oder die JSRs definieren mit JSF oder JPA erstmal nur Schnittstellen, die eigentliche Bereitstellung erfolgt über Implementierungen (von denen es dann wieder gute Referenzimplementierungen und Alternativen gibt, z.B. EclipseLink und Hibernate als JPA Implementierung).

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien, aber vergleicht man das z.B. mit C, so fehlt dort dieser "quasi Standard". Ihn selbst zu schreiben und eine gute Qualität sicherzustellen ist mit einem Aufwand von mehreren Personen-Jahren zu beziffern (die Zeit und Erfahrung ist sicher auch bei Java nötig gewesen, aber schon investiert wurden).

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht. Warum also hat MS so eine CLI geschaffen, wo doch plattformunabhängigkeit hier (offensichtlich) nicht im Fokus stand oder steht (nicht durch MS selbst)? Wenn man sich hier die Unterschiede zwischen .net und Win32 anschaut, dann liegen sie darin, dass C# stärker abstrahiert. Man hat viele mächtige Frameworks wie LINQ und eine relativ hohe Abstraktionsebene. Der Code ist managed und somit gelten ähnliche Vor- und Nachteile wie für Java. Das zeigt aber einfach, dass diese Form von Programmierung/Entwicklung an Bedeutung gewonnen hat. C wird es wie C++ auch weiterhin geben und die Domänen die sie bedienen werden auch weiterhin vorhanden sein, aber es gibt auch viele Anwendungen höherer Abstraktion.

Ich würde Dir deswegen raten Dich nicht von Kommentaren irritieren zu lassen, die sagen, dass Java doof ist oder keine Treiberprogrammierung beherrscht. Klar, stimmt, wenn Du in die HW-nahe Programmierung eintauchen willst solltest Du nicht unbedingt mit C# oder Java anfangen, für die Anwendungsentwicklung ist es aber keine schlechte Sprache.
Auch solltest Du Dich nicht vom Feature-Wahn verfolgen lassen. Natürlich kannst Du in .NET verschiedene Sprachen kombinieren, sowie auch Java das kann (da gibt es eine Schnittstelle für und ich glaube z.B: Ruby oder Scala kann man darüber mit anderen Java-Klassen zusammen verwenden).

Bleibt noch die Sache mit dem GUI. Das ist (und das liegt in der Natur der Sache) ein Problem der Plattformunabhängigkeit. Hier muss man in Java 3 Möglichkeiten unterscheiden, alle mit ihren Vor- und Nachteilen:

1. AWT - Die "älteste" Fenstertechnik in Java. Hier wurde einfach der kleinste gemeinsame Nenner aller Plattformen genommen und in eine Java API gesteckt. Alle Elemente (Fenster, Button, ...) die es überall gibt werden nativ erzeugt. Ein AWT Fenster sieht unter Mac so aus, wie jedes andere auch, unter Windows sind es Windows-Fenster usw. Allerdings ist die Gemeinsamkeit eher klein, schon bei der Anzeige von Bäumen muss AWT passen.
2. Swing - Die Beschwerden über die viel zu vielen Dinge die AWT fehlten führten zu Swing. Um alle Komponenten darstellen zu können, wird bei Swing einfach ein viel kleinerer, gemeinsamer Nenner verwendet, die Zeichenfunktionen. Das führt dazu, dass Java-Anwendungen, die mit Swing erstellt werden, überall gleich aussehen (leider nicht immer schön). Ein Button wird hier einfach mit Grundoperationen gezeichnet, genauso ein Baum oder andere Komponenten. Das können alle Plattformen, aber schnell ist dann auch anders (daran hat man viel gearbeitet und mittlerweile ist die Leistung der Systeme und die Optimierung der Java Umgebung schon ganz ok!).
3. SWT - Bei SWT wurde eine Sammlung von unterstützten Komponenten festgelegt. Diese finden sich alle nativ unter Windows. Vereinfacht kann man hier eine Mischung aus AWT und Swing unterstellen, alle Komponenten, die nativ angeboten werden, werden vom OS aus erzeugt. Alles was eine bestimmte Plattform nicht direkt bietet, wird emuliert. Hier wird gerne darauf verwiesen, dass Windows SWT Anwendungen etwas schneller laufen als die unter Linux oder MacOS, aber ich glaube nicht, dass man hier im relevanten Bereich landet.

Dass die GUI Entwicklung mit Java besonders aufwendig ausfällt liegt hauptsächlich daran, dass es keine gute IDE mit kostenlosem GUI-Designer gibt. NetBeans fühlt sich immer etwas träge an, Ecipse bietet keinen integrierten GUI Editor. Eclipse selbst ist nutzt SWT (und zeigt eindrucksvoll wie wenig eine Java Anwendung schleicht oder sich von anderen Anwendungen unterscheidet). Man kann das Eclipse-Framework auch direkt verwenden um eigene SWT Anwendungen zu erzeugen. Auch finden sich kommerzielle Designer, die man sicher auch testen kann.
Ich selbst kann hier keine Empfehlung aussprechen, da ich aktuell nur Webentwicklung betreibe und dort bestimmt der Webdesigner schon das Layout mit seinen Tools, ich muss da nur die Logik einfügen. In Unternehmen wirst Du hier sicherlich keine Probleme haben ein paar hundert Euro für eine IDE oder eben so eine Erweiterung zu bekommen, ein Visual Studio (ohne Express) oder eine Delphi IDE werden ja auch bezahlt. Hier kommen wieder nur einfache Kosten-Nutzen-Rechnungen zu tragen (eine IDE kostet ein paar hunder Euro, Du kannst aber viiiel schneller arbeiten und nach wenigen PT amortisiert sich die Investion, der Rest interessiert keinen ).


Also nochmal zusammenfassend:

• Java ist mehr als plattformunabhängkeit
• Java ist gut für Fachanwendungen, schlecht für systemnahe Programmierung
• Java ist verbreitet und es gibt viele Frameworks (was die Entwicklung komplexer Fachanwendungen erleichtert)
• Java Anwendungen sind (wie z.B. Eclipse) nicht "langsame, graue Dinosaurier, denen man das Java schon ansieht"
• Java Applets sind nicht Java und sollten verboten werden! (da gibt es wirklich immer Ärger, aber das ist ein anderes Thema)
• Gutes GUI Design kostet bei Java

[Phoenix]

Zitat von Unwissender:

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien

Ein paar Schlagworte: Spring.NET, NHibernate, nDepend.

Nicht nur ähnliche. Zum Teil sogar die gleichen.

Zitat von Unwissender:

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht.

Glauben heisst nicht wissen. Ich sage Dir: Ja. Geht. Mache ich tagtäglich und funktioniert einwandfrei.

[rollstuhlfahrer]

Dann würde ich noch Python in den Raum werfen. Mein Informatiklehrer hat demletzt gesagt, dass Python die nächsten Jahre flächendeckend in der Rheinland-Pfälzer Sekundarstufe II als Konsolen/GUI-Anwendungsentwicklung eingeführt wird (anstelle von Delphi). Leider braucht man für Python sowas wie eine Runtime-Bibliothek. Unter Linux wird man schon fast dazu genötigt, diese zu installieren, wenn man bestimmte Anwendungen haben will, unter Windows dürfte es ein leichtes sein, diese mitzuliefern und im Anwendungsverzeichnis gleich mitzuinstallieren.

Ein weiterer Versuch wäre Erlang. Falls es jemand kennt: ejabberd (Jabber-Server) ist mit Erlang geschrieben, zur Verbreitung lässt sich allerdings nichts sagen.


Zu .net und Mono: Meine Musik-Lade-Software lief unter Linux mit Mono zusammen prima. Der Grund, warum sie nicht mehr läuft, ist im Betriebsystem zu suchen und die Software gehört einfach neu kompiliert. Dann würde sie auch wieder laufen. Leider ist mir das unter Linux viel zu kompliziert.

Bernhard

ADD: Und wenns nur Konsole sein soll, ist PHP auch einen Blick wert.

[Mithrandir]

@Feuervogel:
Der einzige Nachteil wäre vielleicht, dass WPF-Anwendungen nicht von Mono unterstützt werden...

[Phoenix]

Nicht unbedingt.
Silverlight ist am kommen, und SL-Anwendungen kann man auch auf dem Desktop laufen lassen (out-of-browser applications). Und mit Moonlight gibt es die Mono-Version von Silverlight auch auf allen Plattformen - auch mit out-of-browser support.

[BUG]

Wenn Java als Sprache nicht gefällt, gibt es auch einige andere interessante Sprachen (z.B. Scala, Gosu) die auf der JVM laufen und Java-kompatibel sind.

[fkerber]

Hi,

erstmal wow für die Vielzahl und die Länge der Antworten, danke.


@Phoenix:
Danke für die Ausführungen, jetzt bin ich schlauer.


@Unwissender:
Ich habe diese Aussage zum Anlass genommen, um mal "über den Tellerrand" zu schauen.
Natürlich renne ich jetzt nicht los und suche was anderes, nur weil jemand gesagt hat "Java ist doof" - und mir sind die Vorteile von Java ja ebenfalls geläufig und ich weiß sie zu schätzen. Allerdings hat mich gerade die GUI-Entwicklung beim letzten Projekt nahezu in den Wahnsinn getrieben und mich viel Zeit gekostet, damit es wenigstens ansatzweise manierlich aussah - und trotzdem war es hässlich. Dazu kommen dann auch so Sachen, dass bspw. unter Mac die Tastenkombis zum Kopieren, Einfügen etc nicht wie gewohnt mit Apfel+C/V funktionieren sondern nur mit Strg+C/V - das ist für Otto-Normal-Nutzer ungewohnt und vllt. sogar unhandlebar, weil er nicht auf die Idee kommt etc. Auch die Integration ins Fenster-Schließen-Konzept von Mac geht von Haus aus nicht wie sie soll, sondern erfordert ein extra Eingreifen etc. - halt so viele Kleinigkeiten.

Daher will ich einfach mal schauen, was es da sonst so gibt. Da ich privat gänzlich unter Mac unterwegs bin (von VMs abgesehen) sind schon alleine wegen der Verbreitung von Windows Lösungen für mich interessant, die ich sowohl für mich programmieren kann, aber vllt. auch irgendwo "unters Volk" bringen kann (und dann sollte Volk nicht auf Mac-User beschränkt sein).
Dank Android werde ich Java so oder so nicht so schnell den Rücken kehren, aber ich denke, es schadet nichts, auch mal was anderes anzutesten.


@Rollstuhlfahrer
Das mit Python ist auch durchaus interessant.
Wie im Eingangspost erwähnt habe ich auch schon einiges mit Python gemacht und die Sprache und Ihre Funktionalitäten finde ich auch recht sympathisch. Allerdings waren das bislang reine Entwicklung für Multi-Touch-fähige Eingabegeräte mit einer speziellen Bibliothek, die sowohl das Tracking übernimmt, wie auch sämtliche grafische Elemente zur Verfügung stellt (--> www.libavg.de ). Ist ne nette Sache, aber eben nicht für normale Alltagsprogramme sondern quasi nur solche Programme, deren GUI komplett durch Grafiken bzw. zumindest grafische Elemente dargestellt wird (und nein, ein normaler Button ist kein grafisches Element in dem Sinne, den ich meine ).

Also mal schauen, was es da gibt, um normale GUIs zu produzieren.
Gibt es "prominente" Programme, die mit normaler GUI in Python geschrieben sind?


@BUG:
Doch doch, Java als Sprache gefällt (zumindest mir) - meine Aufgaben konnte ich damit bisher gut umsetzen, solange sie keine GUI hatten


Liebe Grüße,
Frederic