|
Plattformunabhängig programmieren
Hi,
ich muss jetzt mal eine wahrscheinlich etwas naive Frage stellen, seht es mir nach. Im Netz habe ich nicht so recht die Infos gefunden, die ich gesucht habe. Uni-bedingt verbringe ich meinen Programmieralltag überwiegend mit Java (bzw. auch Python, aber das ist ein anderes Thema). Das hat auch für das, was ich bisher so machen musste, einen enormen Vorteil: Es lief überall ohne nennenswerte Probleme. Soll heißen, bei dem was ich bisher so gemacht habe, musste ich mich wenig bis gar nicht darum kümmern, was der Empfänger meiner Arbeit so für ein Betriebssystem hat. Auch Teamarbeit mit Mac, Windows, Linux war nie ein Problem. Was das verteilen der Programme angeht, wage ich einfach mal die Prognose, das nahezu jeder irgendwo eine JRE oder gar ein JDK installiert hat, da es ja auch im Web immer mal wieder vorkommt etc... (Diese Aussage ist zumindest für das akademische Umfeld in Saarbrücken wahr ;) ) Klarer Nachteil von Java in meinen Augen: GUI-Entwicklung ist einfach grausam. Jetzt habe ich in einem anderen Thread gelesen, dass jemand Java insgesamt als Nachteil empfindet. Da drängt sich mir doch die Frage auf: was gibt es denn da sonst so? Was ich dabei meine, ist eine Programmiersprache, mit der ich auf allen drei System und für alle drei Systeme programmieren kann. Dabei sollen keine Anpassungen für die einzelnen Systeme erforderlich sein (klar, jetzt nicht bei superspeziellen Features, aber die letzten Jahre hat das mit Java immer geklappt). Damit ich jetzt einen Vorteil sehe, sollte man einfach ne nette GUI basteln können (oder man müsste mich überzeugen, dass trotz, dass das nicht geht, die Sprache andere Vorteile hätte). Sinnvoll wäre natürlich auch eine fähige IDE und ganz wichtig: Die erstellten Programme sollten auch auf einer breiten Zahl von Systemen laufen (ich meine, auch Windows-Exen kann man per Wine unter Linux laufen lassen, aber das gehört ja nicht gerade zum Standardweg - ich denke, ihr versteht was ich meine). Ich wage nicht davon auszugehen, dass es das Ganze auch unbedingt noch in kostenlos gibt, aber ein Nachteil wäre es sicherlich nicht. Also schreibt mal drauf los ;) Dankeschön! Liebe Grüße, Frederic |
AW: Plattformunabhängig programmieren
Qt, inkl. IDE, lauffähig unter Windows, Linux und Mac, ist eine C-Sprache und kostenlos. Unter Windows muss man seine EXE allerdings mit ein paar DLLs ausliefern, dass die Qt-Unterstützung geht.
Bernhard |
AW: Plattformunabhängig programmieren
-.Net/Mono
-gcc QT/Gtk/wxLib, ... -Delphi/c-Builder XEx .O.B.d.A. x > 1 ... |
AW: Plattformunabhängig programmieren
Ich glaube, dass Java das Maß aller Dinge ist, wenn es um das plattformunabhängige Programmieren geht. Sicher gibt es beispielsweise den Nachteil mit der komplizierten GUI-Entwicklung, aber auch dafür gibt es ja Tools, die einem einen Haufen Arbeit abnehmen können (habs zugegeben selber noch nie wirklich ausprobiert, aber man liest so einiges ;-) ). Immerhin gibt es unzählige Programme (und ich meine damit nicht nur die "kleinen Tools"), welche eine aufwändige Oberfläche haben und komplett in Java geschrieben wurden. Ich kann mich über Java nicht wirklich beschweren (gut, wenn man von Delphi kommt, sind manche Dinge wie beispielsweise die Syntax vielleicht etwas gewöhnungsbefürftig, aber das ist eine andere Sache...). Den großen Vorteil sehe ich neben der Plattformunabhängigkeit (nicht nur für Dekstop-Rechner, sondern auch für Android & co) auch darin, dass es völlig kostenlos ist...
Nur mal so meine Meinung... |
AW: Plattformunabhängig programmieren
Es wurde schon erwähnt: Mono - also analog zu .NET.
Schau Dir allein mal MonoDevelop an: Es ist eine IDE und damit nicht gerade ein Leichtgewicht an GUI-Software. Die Oberfläche ist mit Gtk# entworfen und läuft stabil und gut zu bedienen auf Windows, dem Mac und Linux. Oberflächen-Design mit Gtk ist zwar doch etwas unterschiedlich von Delphi, aber bei weitem nicht so ein pain wie bei Java. Bei RemObjects haben wir auch einen internen Bugtracker, der für Mac und Windows mit Gtk# geschrieben ist, und die gleichen Libraries laufen auch im iPad/iPhone Client. Wo wir beim nächsten Bereich sind: Das .NET auf dem Windows Phone läuft ist ja selbstverständlich. Mit MonoDroid bzw. MonoTouch kann man für Android und iOS entwickeln. Allerdings betreten wir hier dann tatsächlich einen kostenpflichtigen Bereich. Das schöne an .NET/Mono ist auch, dass man hier in der Wahl der Sprache recht frei ist. Klar, C# ist der Favorit, aber wenn Du Delphi magst ist Prism da (auf Mac und PC - Entwicklung auf Linux ist in der Mache, wird aber nicht so wirklich nachgefragt. Hauptsache das Kompilat läuft da.). Und dann gibt es natürlich noch zig andere Sprachen in einer .NET Fassung wie z.B. auch IronPython, was Deinen Python-Code den Du erwähntest auch auf der gleichen Plattform laufen lässt - bei Bedarf sogar innerhalb der restlichen Anwendungen. Ein weiterer massiver Vorteil: Der C# Compiler in Mono und die Runtime unterliegen der MIT/X11 Lizenz. Das heisst im Prinzip: Jeder darf alles damit machen, sogar in closed-Source Software einsetzen und unter eine andere Lizenz stellen und verkaufen. Es gibt eine Einschränkung für embedded Systeme, die dem Nutzer nicht die Möglichkeit lassen die Mono runtime upzudaten wenn er will, sowie wenn man die Mono runtime statisch linkt (also für den User nicht austauschbar/updatebar macht). Für diese Fälle gibt es aber auch auf Anfrage Lizenzen. MonoDevelop steht unter GPL, aber das sollte kein Beinbruch sein. Java untersteht hingegen einer nicht freien Lizenz. Auch wenn der Source einsehbar ist: derivative Werke darf man davon nicht verbreiten. Sollte sich Oracle heute entscheiden Java künftig zur Nutzung kostenpflichtig zu machen gibt es keine Alternative als zu zahlen oder auf der aktuellen Version zu bleiben. In dem Zustand wie sie sich befindet - auch das veröffentlichen von Bugfixes wäre nicht erlaubt. .NET / Mono ist halt das bessere Java - und hier wurde es richtig gemacht. Vor allem der Architektur der Basis-Namespaces sieht man an das Anders Heijlsberg seine Finger da drin hatte und als Delphianer findet man sich schnell zurecht. |
AW: Plattformunabhängig programmieren
Hi,
also verstehe ich das richtig? Mono ist quasi das .Net für Nicht-Windows-Systeme? Und "glücklicherweise" sind diese beiden Systeme (zumindest bis .NET 2, wenn Wiki recht hat) kompatibel. D.h. wenn ich unter Mac was mit z.B. MonoDevelop programmiere, dann wird es auch unter Windows laufen, wenn dort ein passendes .NET-Framework installiert ist? Bzgl. dem Programmieren an sich: Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#? Wie ist das mit Delphi-Prism? Ich hab auf der Download-Seite gesehen, es gibt die IDE für Mac und Windows. Gilt dann hier quasi das selbe wie oben? Ich entwickele unter Mac und das Ganze wäre dann unter Windows mit .NET-Framework lauffähig? Und die Sprache ist dann quasi Delphi im .NET-Style? Eine zentrale Frage wäre für mich jetzt noch: Die Verbreitung irgendeiner .NET-Framework-Version unter Windows dürfte wohl recht weit sein - aber wie sieht es auf der anderen Seite für Mac und Linux aus? Wenn ich das richtig verstanden habe, muss dort ja dann das Mono-Framework installiert sein - das wäre jetzt bei mir beispielsweise nicht der Fall. Daher meine Frage, ob es da vllt. irgendwo Statistiken/Zahlen (auch wenn ich sie nicht selbst gefälscht habe ;) ) gibt, die dazu was sagen. Dann noch eine letzte Frage: Auf der Mono-Download-Seite habe ich jetzt auch eine Windows-Version gesehen. Da frage ich mich nun, warum? Unterstützt die dann Mono-Anwendungen besser, als das .NET-Framework es tut? Liebe Grüße, Frederic |
AW: Plattformunabhängig programmieren
Zitat:
Bernhard PS: Irgendwo habe ich mal gelesen, dass Mono in der Linux-Welt nicht gern gesehen ist, weil es eben kompatibel zu .net ist. |
AW: Plattformunabhängig programmieren
Hi,
Achso, also Mono ist sowohl Framework wie auch eigene Sprache? Ich ging nach diesem Wiki-Zitat Zitat:
Auch  http://www.mono-project.com/Languages erweckt nicht den Eindruck.Wo kann man denn Infos über die Sprache finden? LG, Frederic |
AW: Plattformunabhängig programmieren
Lazarus freepascal lässt sich für so ziemlich jedes system kompilieren...
man muss nur "richtig" Programmieren (den Dateisystem seperator nicht hard codieren und so). Geht soweit ich das überblicken kann auf Windows (in 64 bit und 32 Bit), Linux, Mac (wenn man es dort installiert bekommt, was anscheinend nicht so einfach ist), Iphone OS, Windows CE ARM(crosscompiler). Du kannst entweder mit den Standard GTK oberflächen oder mit QT (kylix ähnlich) arbeiten. Mir gefällt es mehr und mehr... musst eben nur ein Build für jedes System ausführen ...der code kann weitestgehen gleich beleiben...wenn man "richtig" programmiert. Ansonnsten gibt es noch Morfik damit kannst du Webanwendungen schreiben (in Basic, Objectpascal und c# ) die werden dann nach Javascript Html5 Css "compiliert" halt wie das GWT für Java. |
AW: Plattformunabhängig programmieren
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. |
AW: Plattformunabhängig programmieren
Zitat:
Mono ist eine betriebssystemübergreifende Implementierung der .Net-Plattform Diese ist aber nicht zu 100% komplett und kompatibel |
AW: Plattformunabhängig programmieren
Zitat:
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. |
AW: Plattformunabhängig programmieren
Zitat:
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2. |
AW: Plattformunabhängig programmieren
Zitat:
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. |
AW: Plattformunabhängig programmieren
Zitat:
1.) Teilweise korrekt. Windows Forms ist natürlich für Windows gedacht und man braucht tatsächlich eine Gui-Bibliothek. Wie ich aber schon ausgfeührt habe ich Gtk# fertig und brauchbar. Und die Anwendungen sehen besser aus als mit irgendeinem Java-Gedöns. 2.) Swing ist eine Krankheit. Jede Applikation die damit geschrieben ist sieht auf jedem System anders bescheiden aus und fühlt sich nicht nativ an. 3.) Deswegen gibt es für jede Plattform auch native Bindings - die gibts bei Java nicht. 4.) Bei Linux-Freaks mag das zutreffen, normalen Linux-Usern ist es egal ob da eine Runtime druntersteckt oder nicht und mit der Performance hat das gerade mal gar nichts zu tun. .NET im allgemeinen und auch Mono sind sauschnell. Man merkt allerhöchstens beim ersten Anwendungsstart eine kurze Verzögerung - wenn überhaupt. Zitat:
Mono ist eine zu der ECMA-Spezifikation von .NET 4.0 kompatible Runtime. Dazu kommen dann teile(!) von Microsoft-Kompatiblen-Implementierungen zugehöriger Bibliotheken wie ASP.NET, Windows Forms, ADO.NET. Darüber hinaus bringt Mono aber z.B. auch mehr ADO.NET Datenbanktreiber mit als Microsoft.NET - ist in diesem Bereich also sogar weiter. Dazu kommen dann auch noch weitere Bibliotheken wie z.B. Gtk# oder auch die MonoMac-Bindings, die z.B. viele Zugriffe auf die Mac-API Cocoa kapseln und dem Entwickler sonst notwendige P/Invokes abnehmen. Mono hat sich inzwischen übrigens im Gnome-Desktop fest eingenistet und etliche Default-Anwendungen von Gnome sind für Mono geschrieben. So ablehnend kann die Einstellung der Linux-Anhänger die Gnome entwickeln also gar nicht sein. So, und nun zum eigentlichen Teil: Zitat:
Es gibt von diesen Bibliotheken einige, die nicht oder nur Teilweise unter Mono bzw. auf anderen Plattformen laufen. Das ist z.B. Windows Presentation Foundation (WPF) oder auch Teile von WCF (Windows Communication Foundation). Letztere ist aber grad im kommen. Auf der anderen Seite gibt es aber auch Teile in Mono, die sind viel umfangreicher als die in Microsofts .NET. Ein gutes Beispiel hier ist ADO.NET. Microsoft kann SQL Server und Oracle. Mono bringt hier Provider für viel mehr Datenbanken von Haus aus mit. Zitat:
Zitat:
Zitat:
Wie oben schon erwähnt: Auf einem neueren Linux-System mit GNOME ist Mono schon drin. Mono auf dem Mac ist üblicher als man meinen mag, aber selbst wenn nicht ist das kein Beinbruch: Mono bietet zum einen die Möglichkeit, die komplette Runtime in die Anwendung gleich reinzupacken. Von der Idee her ist es das gleiche, wie wenn man bei Delphi eben keine Packages ausliefert sondern einkompiliert. http://www.mono-project.com/Embedding_MonoNatürlich bläht das die Anwendung dann ein wenig auf - aber die komplette Mono Runtime inkl. mscorlib.dll brauchen zusammen nur 3.7 MB. Das kann man sogar noch weiter runterkriegen. Dazu gibt es bei Mono dann auch noch die Möglichkeit, die Anwendung komplett in nativen Code zu übersetzten. Das wird z.B. auch für iOS-Anwendungen gemacht, so dass man am Ende eine native executable hat: http://www.mono-project.com/AOT Damit ist man dann noch unabhängiger. Zitat:
Nein, die Idee ist eher die, dass man seine Anwendung dann auch auf Windows direkt gegen die Mono testen kann. Wie gesagt: Es gibt Teile in Mono, die sind in .NET nicht drin (eben die angesprochenen ADO.NET Provider), und umgekehrt. Die oben genannten Tools (z.B. auch das Ahead-of-time compiling-Tool) sind natürlich auch kein Bestandteil von Microsofts .NET, so das man hierfür auch unter Windows Mono braucht. Es gibt auch ein Tool namens Mono Migration Analyer (MoMA), das eine für Microsoft .NET geschriebene Anwendung analysiert und aufzeigt, bei welchen Stellen es auf anderen Systemen Probleme geben kann (z.B. ein P/Invoke auf eine Windows-DLL, das verwenden von #13#10 anstelle von Environment.NewLine oder - noch schlimmer - das Benutzen von WPF). Auch dafür braucht man unter Windows eine Mono-Installation. Als Anmerkung: Ich mache ja ungeheuer viel im Web-Bereich, und ich habe bisher noch keine ASP.NET Anwendung hinbekommen die nicht auch unter Apache/mod_mono lief. Übrigens: Die meisten kommerziellen ASP.NET Komponenten laufen inzwischen auch offiziell unter Mono: http://www.telerik.com/company/press...-for-mono.aspxhttp://www.infragistics.com/about-us...ouncement.aspxIch schreibe auch etliche Tools und Bibliotheken, die auch alle unter Mono laufen (viele schreibe ich sogar auf dem Mac). Man muss sich fast schon anstrengen Sachen zu schreiben, die nicht auf Mono laufen - sofern man sich auf ein paar Grundregeln einlässt. Diese wären: Keine hart codierten Pfade, keine hart codierten Zeilenumbrüche. Die Spezialpfade wie z.B. das Userverzeichnis gibts mit .NET-Hausmitteln genauso einfach und das läuft auch unter Mono. Bevor man etwas mit Fremdcode oder Komponenten löst erstmal nachgucken ob .NET / Mono nicht schon was passendes mitliefert. Die Bibliothek ist riesig und ein großes Problem was ich bei vielen sehe ist dass sie einfach loslaufen und zeug selber schreiben was es schon gibt. Ein bisschen einlesen hat noch niemandem geschadet :) Bei der GUI immer aufpassen. Windows Forms mag auch auf dem Mac laufen (unter X11) und unter Linux, aber das sieht echt häßlich aus und viele eingekaufte Komponenten gehen da nicht. Also da lieber einheitlich auf Gtk# setzten, ODER (mein Favorit), sich tatsächlich die Arbeit machen, ein MVC-Pattern hernehmen und die GUI für jede Plattform nativ machen (Windows Forms oder WPF für Windows, Cocoa (mittels InterfaceBuilder) auf dem Mac und Gtk oder Qt für Linux. Das sieht auf jedem System viel natürlicher aus, fühlt sichbesser an, ist hintenraus einfacher zu handeln und wenn man hinten mit Model und Controller aufpasst und das sauber löst muss man tatsächlich nur die Form auf jedem System machen, ein bisschen Glue-Code schreiben, und das war's auch schon. |
AW: Plattformunabhängig programmieren
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 :wink:). 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:
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 :wink:). Also nochmal zusammenfassend:
|
AW: Plattformunabhängig programmieren
Zitat:
Spring.NET, NHibernate, nDepend.Nicht nur ähnliche. Zum Teil sogar die gleichen. ;-) Zitat:
|
AW: Plattformunabhängig programmieren
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. |
AW: Plattformunabhängig programmieren
Zitat:
(Der Notizzettel und der Musikplayer?) |
AW: Plattformunabhängig programmieren
Zitat:
|
AW: Plattformunabhängig programmieren
@Feuervogel:
Der einzige Nachteil wäre vielleicht, dass WPF-Anwendungen nicht von Mono unterstützt werden... :) |
AW: Plattformunabhängig programmieren
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. |
AW: Plattformunabhängig programmieren
|
AW: Plattformunabhängig programmieren
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 |
AW: Plattformunabhängig programmieren
QuickAndDirty hat zwar schon Free Pascal und Lazarus angesprochen, ich möchte da jedoch noch etwas ausholen.
Erstmal Free Pascal ist ein Open Source Object Pascal Compiler und für unterschiedliche Plattformen (x86, x86_64, ARM, Sparc, Power PC) und Betriebssysteme (u.a. Windows, Windows CE, Linux, Mac OS X, BSD, Solaris, DOS, OS/2) verfügbar. Der Compiler kompiliert die Anwendungen nativ für die jeweilige Zielplatform, ist also dann an den CPU Typ und das Betriebssystem gebunden (im Gegensatz zu Java, manchen .NET Programmen und den Scriptsprachen).Aber auch wenn die Anwendung binär an ein bestimmtes Betriebssystem gebunden ist, so bietet Free Pascal eine plattformunabhängige RTL (so Sachen wie Writeln, TList, etc) und die Möglichkeit Code nur für bestimmte Plattformen zu kompilieren (wie es in Delphi ja auch möglich ist). Auch das Einbinden von anderen Bibliotheken (DLL, SO, Dynlib), welche eine flache C API bereitstellen, ist relativ einfach möglich (das berühmte "external 'Foo' name 'Bar'"). In der Entwicklungsversion des Compilers kannst du sogar Objective-C Klassen anbinden (hierzu wurde von der Mac Community eine eigene Spracherweiterung namens Objective Pascal entwickelt). Das Kompilieren von verschiedenen Betriebssystemen nach Windows und Windows CE ist im großen und ganzen ohne weitere Verrenkungen möglich (dank internem Linker und zumindest für x86 und x86_64 auch internem Assembler). Um von Windows nach Linux zu kompilieren benötigt man schon passende Binutils (vor allem Linker) und die Bibliotheken des Zielsystems (z. B. libc, libpthreads, libgtk, etc.). Letzteres kann auch mal ein Problem sein, wenn du ein auf z. B. einem ArchLinux kompiliertes Programm (mit solchen Abhängigkeiten) auf einem Ubuntu laufen lassen möchtest, da ersters andere (meist neuere) Bibliotheken verwendet (Linux ist da etwas unverzeilicher als Windows). Hier hilft dann nur auf dem Zielsystem neu kompilieren. Das Cross Kompilieren nach Mac OS X ist dann (sowohl von Windows, als auch von Linux) ein noch größerer Terz (ähnliche Problematik wie unter Linux, nur noch etwas kopfzerbrechender). Kompilierst du allerdings auf der jeweiligen Zielplatform (Windows CE und iPhone mal ausgenommen), hast du mit den Bibliotheken kaum Probleme. Free Pascal alleine bietet allerdings keine GUI (von FreeVision, einem Klon von TurboVision für die Textmode IDE mal abgesehen). Du kannst natürlich auf die verschiedenen GUI Toolkits zugreifen (WinAPI, GTK(2), Qt, Carbon, Cocoa), musst allerdings für jedes Toolkit ne Extrawurscht machen (bei GTK und Qt etwas weniger, da diese auch auf anderen Plattformen als Linux laufen). Möchtest du jedoch plattformunabhängig mit GUI arbeiten, so sind drei bekanntere Varianten möglich: Ersteres wird von der Delphi ähnlichen IDE Lazarus zur Verfügung gestellt und lässt sich ähnlich zur VCL verwenden. Die Entwickler streben danach LCL-Anwendungen auf dem jeweiligen System so nativ wie möglich aussehen zu lassen. Für die Plattformunabhängigkeit wurde eine Abstraktionsschicht, das sogenannte Widgetset eingeführt und erlaubt es dir zu bestimmen, ob eine kompilierte Anwendung nun die WinAPI oder Qt (als Beispiele) verwendet. Du kannst so zum Beispiel auch Qt Anwendungen für Windows entwickeln (nicht alle Kombinationen machen allerdings Sinn, wie Cocoa auf Windows CE). Diese Abstraktionsschicht bringt allerdings auch Performanceeinbußen mit sich. Ich persönlich empfinde diese jedoch nicht als so gravierend wie von Hisoka beschrieben. Hier empfehle ich dir (falls näheres Interesse besteht) einfach mal die IDE herunterzuladen und zu schauen, ob dir die Performance ausreicht (wobei du hier eventuell warten solltest, da sich zur Zeit ein neues Release in Vorbereitung befindet - das "aktuelle" ist bereits über ein Jahr alt und dementsprechend viel hat sich seitdem geändert).Im Gegensatz zur LCL sind fpGUI und MSEgui komplette Neuentwicklungen. Beide haben den selben Look der Anwendung unter allen unterstützten Plattformen zum Ziel. Zu MSEgui kann ich jedoch nicht viel sagen, da ich mich noch nicht damit auseinandergesetzt habe. fpGUI ist jedoch näherungsweise ähnlich zur LCL/VCL und unterstützt zur Zeit Windows und Linux (bzw. allgemeiner: X-Server basierte Systeme). Mac OS X Unterstützung sowie Unterstützung für Open GL und Linux Framebuffer als Backend sind in Entwicklung bzw. Planung. Während mseGUI eine komplette eigene IDE (MSEide) mitbringt, bietet dir fpGUI nur einen Formulardesigner an. Der eigentliche Code wird in der IDE deiner Wahl (MSEide, Lazarus, Free Pascal IDE) entwickelt. Ich persönlich bin sehr zufrieden mit Free Pascal und Lazarus (fpGUI teste ich hin und wieder aus). Die "Cross Compile" Funktionalität setze ich vorwiegend ein, um Anwendungen für Windows CE zu entwickeln (Hauptentwicklung/-test unter Win32, Details korrigieren dann unter WinCE). Die Variante Linux => Windows verwende ich seltener. Ich habe jedoch einiges an Code, den ich unter Linux und Windows verwende und weiterentwickle, wobei kaum IFDEFs vorhanden sind. Ich hoffe dies hat dir einen kleinen Einblick gegeben. Edit: Link zu fpGUI korrigiert. Gruß, Sven |
AW: Plattformunabhängig programmieren
Zitat:
Liste gefunden. Ob die alle jetzt GUI haben weiß ich nicht. Aber lang ist die Liste.Bernhard |
AW: Plattformunabhängig programmieren
Ich arbeite jetzt schon 10 Jahre plattformunabhängig. Der Witz ist, man braucht es einfach nicht. 90-95% aller Kunden verwenden die Windows Plattform. Die paar Prozent, die mit Linux oder Mac arbeiten sind wirklich teuer für eine Entwicklung. Es lohnt sich einfach nicht Cross-Software anzubieten. Ich bestreite alles mit Delphi auf Windows. Ist schnell, native und (fast) fehlerfrei. Die Karten werden neu gemischt, wenn Delphi für Mac dieses Jahr rauskommt. Viel verdienen wird man an einem Mac-Port aber nicht, so meine Einschätzung.
|
AW: Plattformunabhängig programmieren
Zitat:
|
AW: Plattformunabhängig programmieren
Je kleiner der Aufwand für eine Portierung, desto niedriger die Hürde und desto mehr lohnt es sich. Es gibt ja Softwarehersteller, die nur für MacOSX entwickeln und die davon leben können.
|
AW: Plattformunabhängig programmieren
Zitat:
|
AW: Plattformunabhängig programmieren
Auch nicht wirklich.
Wie gesagt: Ich mach das häufiger und das funktioniert einwandfrei. Man muss sich halt ein bisschen am Riemen reissen und den Ansatz der Trennung von Code und UI wirklich konsequent durchziehen. |
AW: Plattformunabhängig programmieren
Ein Stichwort will ich noch schnell in die Runde schmeißen (ich hoffe ich komme nicht zu spät :-) ): Rich Internet Applictions.
Wenn man das richtig macht, ist man auch plattformunabhängig. |
AW: Plattformunabhängig programmieren
Deshalb ist ja auch kein Openoffice, Adobe und sogar Microsoft Office für verschiedene Plattformen :green:
|
AW: Plattformunabhängig programmieren
Zitat:
|
AW: Plattformunabhängig programmieren
Naja ... das Problem liegt aber nicht an der bestehenden Web-Technologie, sondern an der fehlenden. Zum Glück geht die Entwicklung ja in die richtige Richtung ... siehe z.B. Websockets.
Ganz grob, pauschal und unbeweisbar behaupte ich mal, das die Web-Desktops in Zukunft mal eine ganz große Rolle spielen werden ... schon alleine deswegen, weil die meisten User völlig naiv in jede vorbeischwebende Cloud rein tappen. :evil: |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 08:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz