Delphi vs. Java

[MrSpock]

Kommt bitte zum Thema zurück.

Wenn MacNuke klar sagt, dass er den Ton für unangebracht hält, ist es umso unhöflicher, dieselbe Aussage noch einmal zu wiederholen. Die Aussage durch eine ähnlich persönlich verletzende ist dann auch nicht besser. Diskutiert bitte sachlich und zum Thema, sonst mache ich hier zu.

[FBrust]

Hallo,

danke für Eure Antworten.

Der Hintergrund ist, dass wir eine Anwendung haben (Datenbank, soll später C/S werden), die mit Delphi erstellt wurde (von uns selbst, nicht eingekauft). Diese Software wird auch bei Kunden installiert.

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Ich möchte das mal auf Windows beschränken, da man (wie weiter oben gesagt) ein Delphi-Programm nicht mit einem Java-Linux-Programm vergleichen kann (finde ich jedenfalls auch).

Die Anwendung ist eine Einzelplatzanwendung, die als Datenbank den ADS hat, später soll sie (auch via ADS) als Client/Server-Anwendung laufen. Es gibt Tabellen, in die im Laufe eines Jahres ca. 50.000 Datensätze eingetragen werden, die auch verarbeitet werden (Abfragen, Berechnungen etc.).

So, dies nur als ungefähre Angaben. Was meint ihr?


Gruß

Frank

Ach so: "Plattformunabhängig" hat für mich auch den Beigeschmack vom "kleinsten gemeinsamen Nenner".

[MacNuke]

Zitat:

Zitat von tommie-lie

Wenn du write once, run everywhere mit sämtlichen Features jeder Zielplattform haben willst, gibt es keine Möglichkeit,

Nein. Sämtliche Features des Frameworks und nicht der Zielplattform.

Das geht zur Zeit am besten mit Qt und GTK+. Java halt nur da wo es die RunTime gibt.

[Phoenix]

Zitat:

Zitat von FBrust

Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Erstes: Ja. Korrekt.
Zweites: Kommt drauf an. ;-)

In der Regel sind native Win32/Executables deutlich (will heissen um Faktoren) schneller als entsprechende Java-Applikationen. Ist aber auch kein Wunder.

Leider wird dieser Geschwindigkeitsvorteil wie ich auch schon schrieb in Delphi durch die exzessive Nutzung der VCL meistens wieder zunichte gemacht, da diese nicht nur die Programme aufbläht sondern auch Performance kostet.

Dennoch: Meistens sind native Kompilate immer noch schneller als entsprechendes Java-Gewurschtel.


Ps: (Ich weiss nur nicht mehr wer das eingeworfen hatte): Nein, ich meinte nicht Rotor, sondern tatsächlich dotGNU. Im übrigen meinte jemand, dotGNU würde Mono hinterherhinken. Derjenige hat überhaupt gar keine Ahnung vom Stand der beiden Projekte. Fakt ist, das das Mono-Team sich gerade überlegt aufgrund des inzwischen viel zu gross gewordenen Abstandes zum dotGNU Projekt seine Arbeit einfach einzustellen, weil sie diese Differenz (durch das fehlende Knowhow) einfach nie mehr einholen könnten.

[MacNuke]

Zitat:

Zitat von FBrust

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Je nachdem. Liegt an der Programmierweise und Anwendung, was schneller ist.

Rein in der Datenverarbeitung (Berechnungen, String-Operationen, Arrays, etc.) ist Java eigentlich sehr schnell, da die RunTime mittlerweile sehr auf die Prozessoren optimiert ist und bei Mathe spezielle Algos benutzt.

Wenn ich mir z.B. Dev-Cpp (ist ja mit Delphi geschrieben) angucke finde ich diese auch nicht unbedingt schneller als Eclipse oder NetBeans.

[tommie-lie]

@MacNuke: Aber es ist lediglich eine frage der Zeit, bis alle Namespaces unterstützt sind. Das Framework selbst ja noch nicht produktiv einsetzbar, weil zu große Teile der API noch nicht verfügbar sind, und die freien Frameworks sind auf dem besten Weg zur vollständigen Implementierung. Wenn du allerdings als Framework auch das bezeichnest, was Microsoft willkürlich ohne Firmen-Präfix einbindet, nämlich zum Beispiel Avalon (statt Microsoft.Avalon), so wird .NET nie ohne Verzögerung plattformunabhängig sein. Aber solche Namespaces muss ich ja nicht nutzen, ich habe ja mit GTK# eine Alternative zu Avalon.


@FBrust: Ihr habt eine bestehende Datenbankanwendung, die ihr in Delphi geschrieben habt, und überlegt, diese nach Java zu portieren, nur weil irgendwann mal ein Linux-Kunde kommen könnte? :shock:
Habt ihr zuviel Gewinn und wisst nicht, wohin mit eurem Geld?
Eine komplette Neuentwicklung einer kompletten Anwendung dauert gerne mal ein Jahr. Wenn ihr dann noch eure Programmierer auf Java umschulen wollt, entsprechend länger. Wenn ihr bisher noch keine Kunden mit Linux-Wünschen hattet und ihr so viele Windows-Kunden habt, daß selbst 100 Linux-Kunden nur einen Bruchteil des Umsatzes ausmachen würden, lohnt sich IMHO eine Portierung nicht. Die würde dann mehr kosten als ihr durch den neu erschlossenen Markt wieder reinholen würdet. Außerdem solltet ihr erstmal schauen, wie groß der Linux-Markt für euch überhaupt ist. Was bringt eine komplette Neuentwicklung eines vorhandenen und funktionierenden Produktes, wenn es nachher eh nur 10 Leute gibt, die dieses neue Produkt überhaupt einsetzen würden, von denen 5 drauf angewiesen sind und von denen wiederum 4 beim Konkurrenzprodukt bleiben würden, das sie benutzen, weil ihr bisher keins angeboten habt.
Zur Geschwindigkeit würde ich sagen, daß es vermutlich kaum einen Unterschied machen wird. Ihr habt keine geschwindigkeitskritische Software und vermutlich ist bei großen Datenbanken die Datenbank selbst, bzw die Festplatte eher der Flaschenhals als der verwendete Datenbankclient. Es ist ja nicht so, daß ihr innerhalb von Millisekunden hunderte von Datensätzen auseinandernehmen und zusammensetzen müsstet.

[magicm247]

Zitat:

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. Question

Als C/S ist hier Java für früher oder später eine interessante Lösung, könnten auch ApplicationServer zum einsatz kommen. Da kann Java sich richtig austun. Auch die Nutzung von JSPs sind bestimmt denkbar für die die realisierung einer WebLösung. Genügend Arbeitsspeicher vorrausgesetzt.

Die Clienten sind hier sicher egal, diese Würden als Delphi-Client bestimmt unter Wine einsetzbar sein , eine Linux-Version per Kylix würde auch schnell genug und den Migrationsaufwand in grenzen halten. Die Clients rein in Java zu lösen würde ich eher von absehen. Man könnte auch unter .net/mono die clients umsetzten und diese über webservices mit den java basierten servern werkeln lassen.

[fastplasma]

hey Leute,
arbeitet nur mit eclipse für java programmieren, der ist einfach der beste, soo viele möglichkeiten :dancer2:

[phXql]

Zitat:

Zitat von r_kerber

Zitat:

Zitat von Nicodius

lol mich schon sehr ... ich mag kurze programmteile schnell teste :roll:

Dann ist (das alte) VB am Besten für Dich geeignet! BTW: Auch Delphi braucht seine Zeit zum Erstellen eines Programmes.
Und nun ein Wort zur Lauzeitgeschwindigkeit. Im vergangenen Jahr gab's dazu eine Artikelserie in der c't von Arne Schäpers und Rudolf Huttary. Das überraschende Ergebnis: Am schnellsten arbeiteten Java- und C#-Programme. Mit Abstand folgten C++ (VS) und Delphi!

öhm, dieser C't-Test: Da gabs keinen eindeutigen gewinner, manchmal war Java vorne, manchmal c++, manchmal delphi...

[phXql]

Zitat:

Zitat von fastplasma

hey Leute,
arbeitet nur mit eclipse für java programmieren, der ist einfach der beste, soo viele möglichkeiten :dancer2:

und so schön schnell ^^