Delphi und .Net was macht eigentlich Sinn?

[Bernhard Geyer]

Zitat:

Zitat von grenzgaenger

Zitat:

Zitat von Bernhard Geyer

Komisch nur das ich eine Java-Datenbank gefunden habe die um Welten schneller ist als alle bisher für Delphi gefundenen DB's.

und was willst du damit sagen? dass die DB kein vernünftiges TP kann? oder was? sorry, wegen so einen marketing vergleich, ohne vernünftige grundlage, ist das für mich nur marketing getrommel. nix weiter. ausserdem kommt es ja bei einer DB da normal auf andere punkte an, als nur auf eine standardabfrage welche nach marketing gesichtpunkten gegenüber anderen produkten aufgenommen wurde..

sorry, nix für ungut. aber der vergleich, ist nicht haltbar.

Ich glaub nicht das ein Open-Source Projekt viel Geld für eine Marketingabteilung hat. Und die Performancevergleiche sind auf meinem Mist gewachsen (glaube auch nicht das die H2-DB jemals mit nativen Delphi-DB's verglichen wurde). Also schön Inserts, Updates, Deletes mit diversen Wildcards und das über den vollen Unicode-Zeichenumfang. Und TP ist auch dabei. Ab und zu sind die Schweizer auch ziemlich schnell :-)

[Phoenix]

@Grenzgänger:
Bevor Du weiterhin so über managed Umgebungen im allgemeinen herziehst, und Argumente vorbringst die tatsächlich alle schon mehrfach auch von unabhängigen Stellen widerlegt wurden, halt Dich einfach mal zurück, bis Du Dich persönlich und mit eigener Arbeit davon überzeugt hast, dass es tatsächlich so ist oder eben nicht.

Ich verweise da gerne auf die Geschichte von IronPython (die Python-Implementierung die auf der .NET CLR basiert):
Jim Hugunin wollte einen Artikel schreiben, "Warum die CLR eine furchtbare Umgebung für dynamische Sprachen ist". Unter anderem aus Performance gründen. Er hat also - um das zu belegen - einen .NET Interpreter für Python geschrieben. Blöderweise war das schneller als die native C-Implementierung. Und auch eleganter zu programmieren. Und das ganze läuft freilich dank Mono auch auf jeder Plattform.

Also bitte: Bevor Du Gebetsmühlenartig Deine Meinung hier herunterbetetest und damit allen beweist, dass Du es selber noch nie ausprobiert hast, bleibt diesem Thema bitte fern. Das hat sonst so keinen Taug und stört eine qualifizierte Diskussion über dieses Thema.

[Phoenix]

So, und nun mal wieder was zum Thema:

Zitat:

Zitat von Mavarik

Falls ich nicht völlig daneben liege, gibt es ein .Net Framework zur Zeit nur für Windows, oder? (CF mal außen vor)

Welchen Sinn hat es Jahrelang entwickelte Routinen die sicherlich jeder hat auf .Net umzustellen, wenn sowieso
der Zielsystem Windows ist?

Dann kann ich auch nativen Code programmieren, oder?

1.) Mono wurde schon mehrfach erwähnt. Es gibt etliche Software die auch einwandfrei auf Mono unter OSX läuft. Allerdings (meine Meinung): Es gibt (noch) keine Sprache/Umgebung die das wirklich zufriedenstellend löst. Java hat einfach kein gescheites UI-Framework. Windows Forms ist dank der internen Umsetzung auf Windows beschränkt. GTK halte ich für eine Krücke (und man sieht auch grossartig keine Windows-Anwendung die GTK benutzt).

Also: Wenn Du eine plattformunabhängige Desktop-Anwendung schreiben willst hast Du die Wahl zwischen vielen verschiedenen, aber alle irgendwie gleich schlechten Lösungen. Möglicherweise wird WPF da zukünftig ein wenig was reissen können (um XAML in Direct-X Calls umzusetzen hat man in etwa den gleichen Aufwand wie von X(A)ML zu OpenGL, wenn man da noch Ressourcen Reinsteckt kann Mono hinterher tatsächlich OpenGL-WPF unter Windows UND Linux / OSX mit der gleichen Codebasis), aber das ist noch Zukunftsmusik.

Die Alternative wäre ein Backend mit mehreren separaten GUI's, und zumindest für ein Backend ist .NET sicher sehr gut geeignet.

Kommen wir zu Punkt 2:
Willst Du Anwendungen ausschliesslich für den Windows-Desktop schreiben, ist natives Delphi sicher immernoch und auch in Zukunft die richtige Wahl, insbesondere wenn man schon alten Code hat den man weiterverwenden will.

Es gibt allerdings Dinge in .NET, die ich stand heute nie mehr in anderen Umgebungen anfangen würde: Webanwendungen. ASP.NET ist mit seinem Konzept so dermassen weit vorne, elegant zu entwickeln und unterstützt mich als Entwickler so sehr, dass alles andere was da im Web-Bereich herumschwirrt einfach jederzeit messbar viel weniger Effizient ist. Und das 'läuft doch nur auf IIS'-Argument ist auch schlichtweg falsch: Ich habe es bisher nur ein einziges mal gesehen, wo eine ASP.NET Anwendung nicht 100% auf Linux / Apache mit mod_mono (und freilich mono) lief. Und da war der Entwickler selber schuld, weil er einen Excel-Export mittels COM-Automatisierung von Excel realisiert hat. Und das ist normalerweise auch unter einem Windows Server mit IIS nicht lauffähig weil niemand ein Excel auf einem reinen Webserver installieren würde.

[mschaefer]

Etwas (Bio)-Öl ins Feuer:

Für Mac und Linux brauche ich kein NET. Ordentlich aufgesetztes Wine und schon schnurrt die native Delphi Anwendung durch Mac und Debian. Stellt sich mir eignetlich eher die Frage, ob ein Delphi-Netprogramm auf einem PockePC läuft?

Grüße // Martin

[jfheins]

Es gibt das .NET Compact Framework ;)

Ob Delphi.NET damit zurecht kommt, wage ich zu bezweifeln, aber eine normale (reine) .net Anwendung (C# oder entspr.) sollte laufen. (Mit reduziertem Befehlssatz ;) )

http://de.wikipedia.org/wiki/.NET_Compact_Framework :

Zitat:

Technisch gesehen ist das Compact Framework eine Laufzeitumgebung bzw. eine Klassenbibliothek (vgl. Framework). Diese Version ist gegenüber dem normalen .NET-Framework für den PC um eine größere Zahl von Klassen reduziert, die für intelligente Kleingeräte nicht benötigt werden oder zu viel Speicherplatz belegen.

Das .NET Compact Framework 1.0 wurde in Verbindung mit Microsoft Visual Studio 2003 eingeführt. Unterstützt wird das Compact Framework ab Pocket PC 2000 (Windows CE 3.0) und Windows CE.NET 4.1. Programme können mit den .NET-Sprachen Visual Basic und C# entwickelt werden. Bei der Entwicklung für mobile Geräte helfen die "Smart Device Extensions" (SDE) für Microsofts Entwicklungsumgebung Visual Studio, die zum Beispiel einen Handheld am Computer emulieren können.

[Bernhard Geyer]

Zitat:

Zitat von mschaefer

Für Mac und Linux brauche ich kein NET. Ordentlich aufgesetztes Wine und schon schnurrt die native Delphi Anwendung durch Mac und Debian. Stellt sich mir eignetlich eher die Frage, ob ein Delphi-Netprogramm auf einem PockePC läuft?

Auf dem IntelMac läufts nur wegen dem passenden x86-Prozessor. Auf alten PowerPC-Macs nicht. Und da PocketPC keine x86-Kompatiblen Prozessoren hat wird da auch nicht werden, ganz zu schweigen das eine auf 800*600 Pixel und höher Auflösung ausgelegte Anwendung auf einem solchen Managerspielzeug schon allein wegen der oft mikrigen Auflösung keine Freude machen würde.

[Phoenix]

Soweit ich weiss gab es mal einen Hack um den Delphi.NET Compiler dazu zu bewegen, gegen das CompactFramework zu linken. Aber Oberfläche bekommt man damit auch nicht hin, denn dazu benötigt man die Steuerelemente fürs CF und dort gibt es leider nur Designer für C# und VB.

[Elvis]

Zitat:

Zitat von mschaefer

Etwas (Bio)-Öl ins Feuer:
Für Mac und Linux brauche ich kein NET. Ordentlich aufgesetztes Wine und schon schnurrt die native Delphi Anwendung durch Mac und Debian.

Mit Linux stellt das weit weniger Probleme dar, als es sie mit OSX gibt.
Denn beide großen Linux UIs sehen sehr ähnlich wie Windows aus, und auch die Art wie Dinge funktionieren sind nicht sooo anders.
Bei OSX ist alles anders. Das einzige was gleich bleibt ist, dass es irgendwie Fenster gibt.
Aber Dinge, die in Linux und Windows an der Tagesordnung stehen (Custom controls, Setups, externe Abhängigkeiten), sind in OSX absolut verpönt.
Du wirst wohl niemanden finden, der Geld für sowas für sein schönes MacOS zahlen würde.
Selbst FreePascal-Apps werden es schwer haben, da sie sich anfühlen wie Windows/Linux Apps, die nur wie Mac Apps angestrichen sind.

[mschaefer]

Ja den echten Mac-User werde ich wohl nicht überzeugen können, dass ist wohl so!

[grenzgaenger]

dann geb ich mich mal geschlagen, und oute mich als dinosaurier welcher bereits vom aussterben betroht ist. da man mit optimierten code (nativ) nur so lahm sein kann, dass einen die schuhe unterm laufen ausgezogen werden könne, und die interpretativen sprachen (.NET) schnelleren code erzeugen wie der prozessor abarbeiten kann und ausserdem noch die fehler der programmierer gleichzeitig mit ausbügeln. ausserden sind die sprachen ja 100% portabel und laufen auf jeder kaffeemaschine ohne einschränkung, der pool der komponenten ist absolut überwältigend und die anwender küssen einen gleich die füsse dafür. nur M$ schaffte es nicht, aufgrund erheblicher budget und ressourcenrestriktionen vista als .NET app zu programmieren und muss nun mit erheblichen ressourcenproblemen (memory, platte, prozessoren) kämpfen...

tja, wenn ich mir das so überlege, wird es wohl in einem jahr keine nativen programmierer mehr geben, weshalb auch, bietet ja absolut keine vorteile und die sprachen kommen noch aus dem letzten jahrtausend. werde wohl auch auf die absolut überlegene .NET lösung umsteigen... (btw: .NET muss ja den programmierer vor sich selbst schützen, wie das beispiel zeigte).