Delphi und .Net was macht eigentlich Sinn?

[Bernhard Geyer]

Zitat von Mavarik:

Habe mir gerade mal das VMWare-Mono-Suse Image runtergeladen.

Ein kleines Win-Forms-"Hello World" Programm mit D2006.Net erstellt und per Drag and Drop "rüber" gezogen...

Läuft... Cool

Das Winforms ab D2007 für Delphi gestorben ist, bist du hier in einer Sackgasse.

[Mavarik]

Zitat von Bernhard Geyer:

Das Winforms ab D2007 für Delphi gestorben ist, bist du hier in einer Sackgasse.

Naja D2006 läuft doch...

Abgesehen davon, wenn ich Daniel richtig verstanden habe... Kommt da noch etwas...

Mavarik

[Khabarakh]

Zitat von grenzgaenger:

aber ansonsten gilt natürlich, dass das natürlich noch weiter hinterherhängt als z.b. delphi für .NET, da M$ ständig neue GB an neuen frameworks auf den markt bringt ohne an was anderes als M$ zu denken.

Hm. Als ich das letzte Mal nachgeschaut habe, war Mono schon zu großen Teilen bei 3.5 (C# 3.0, System.Core) und Delphi.Net bei 2.0 . Windows-Forms und ASP.Net 2.0 sind auch komplett, einer kommerziellen ASP.Net-Seite auf einem Linux-Server steht nichts im Wege. Und wer für Gnome programmiert, benutzt statt SWF natürlich sowieso Gtk#.

Zitat:

also von daher nur für M$ Win zu gebrauchen.

Schon einmal etwas von Banshee, F-Spot oder Tomboy gehört? Man könnte fast meinen, in der OSS-Szene sei Mono schon etablierter als MS.Net.

Zitat:

da ist aktuell nur die prozessorgeschwindigkeit der grosse hemmschuh.

Nicht, wenn man bei der Installation den ganzen Code einfach vorkompilieren lässt (NGen).

Zitat:

IMHO hat aber M$ absolut kein interesse daran, das .NET platformunabhänig zu machen, da sie sonst an den grundfesten ihrer einnahmen rütteln würden ...

Ja, das dürfte der Grund sein, warum sie Moonlight unterstützen . Zur Desktop-CLR kann man sagen, dass sie nicht gerade mithelfen, aber Mono auch nicht verhindern wollen (siehe MS-Novell-Abkommen).

[grenzgaenger]

ich weiss nicht, warum sich die M$ .NET fraktion immer auf die füsse getreten fühlt, wenn man sagt, dass man bei .NET apps zwischen den tastendrücken kaffekochen kann. sorry, jungs, ihr könnt es noch so schönreden, der kaffee ist dennoch beinahe fertig inkl. kochen ...

ansonsten kann man nicht davon ausgehen, dass wenn 1, 2 08/15 befehle einigermassen auf einen anderen system laufen, dass es plattformunabhänig ist. wer dass beraubtet, der disqualifiziert sich selbst! und es ist schlichtweg ungmöglich, dass ein interpreter wie .NET schneller ist, als images für den prozessor, dafür gibts mehr flexibilität. aber das ist wie eine medallie, die hat eben zwei seiten und sie kann nicht gleichzeitig auf beide seiten fallen.

also, kriegt euch wieder ein, jeder soll seinen spass haben, wenn ihr kaffe kochen wollt, könnt ihr auf .NET ausweichen, wenn nicht bleibt ihr nativ. plattformabhänig bleibt ihr dennoch.. so oder so. wenn ihr da rauskommen wollt, gibts auch interpreter welche auf mehren systemen laufen oder auch kompiler, ansonsten ist bei nativ mit preprozessor statements zu arbeiten (vgl. MOZILLA), aber .NET da kommt ihr gar nicht raus. sorry jungs, aber ihr habt hier verloren.

[Dax]

Zitat von grenzgaenger:

sorry jungs, aber ihr habt hier verloren.

Genauer gesagt hast du verloren, oder in anderen Worten: "Wissen über was man redet"-Fail.

Zitat von grenzgaenger:

ich weiss nicht, warum sich die M$ .NET fraktion immer auf die füsse getreten fühlt, wenn man sagt, dass man bei .NET apps zwischen den tastendrücken kaffekochen kann. sorry, jungs, ihr könnt es noch so schönreden, der kaffee ist dennoch beinahe fertig inkl. kochen ...

Wenn es ein schlecht geschriebenes Programm ist, gehe ich gern mit zur Kaffeemaschine und ziehe über das Programm her. Aber würdest du über Delphi herziehen, wenn jemand ein lahmes Delphi-Programm schreibt? Vermutlich nicht, weil Delphi ja nativ ist, und damit einfach immer schnell sein muss.

Zitat von grenzgaenger:

ansonsten kann man nicht davon ausgehen, dass wenn 1, 2 08/15 befehle einigermassen auf einen anderen system laufen, dass es plattformunabhänig ist. wer dass beraubtet, der disqualifiziert sich selbst!

Da hast du Recht. Allerdings sollte dir klar sein, dass mit der Mono-Runtime fast alle .NET2-Programme, die nicht gerade P/Invokes verwenden, sogar auf Plattformen laufen, deren Existenz dir nicht einmal bewusst ist. Und dann noch einige mehr...

Zitat von grenzgaenger:

und es ist schlichtweg ungmöglich, dass ein interpreter wie .NET schneller ist, als images für den prozessor, dafür gibts mehr flexibilität.

.NET und Java sind _nicht_ interpretiert, sondern sie werden beim ersten ausführen _kompiliert_. Das geschieht pro Programmlaufzeit _ein_ Mal für jeden Brocken Code im Programm, nicht - wie bei einem Interpreter - garnicht. Allerdings: Mono hat einen Interpreter, mint. Der wird standardmässig nicht verwendet, weil er im Gegensatz zum JIT, mini, grottig lahm ist. Und auch wenn mini nicht perfekt ist - es ist immer noch verdammt schnell, _wenn man richtig programmiert_.



Disclaimer: das selbe hätte ich auch für Java geschrieben, oder andere geJITete Sprachen. Google Chrome + JS, anybody?

[grenzgaenger]

[quote="Dax"]Aber würdest du über Delphi herziehen, wenn jemand ein lahmes Delphi-Programm schreibt?/quote]

sorry, java ist genauso lahm. aber es ist ein unterschied, ob man ein schnelles programm schreiben kann, da unterstützt, oder ob alleine die architektur gewisse grenzen setzt. und bei einem interpreter, was anderes ist das denn, wenn der zwischencode übersetzt wir, ist einfach eine zwischenschicht dazwischen, wie auch bei JAVA, aber java läuft auf jeder kaffemaschine und praktisch jeden rechner. .NET läuft eigentlich nur auf M$ WIN und das war es schon. auch wenn die marketer was anderes sagen.

ausserdem brachtest du eine grosse einschränkung nur .NET 2.0 und da wohl nur eine hand voll befehle, was ist mit dem ganzen rest????

also, wenn du plattformunabhängig sein willst, kannst das vergessen. und da hilft auch kein schönreden.

PS: ich kenne keine einzige .NET anwendung wo man sich nicht zwischendurch kaffee kochen könnt.

[Dax]

Gut. Ich sehe, dass du mein Posting entweder nicht vollständig gelesen oder dir nicht vollständig zu Gemüte geführt hast In diesem Sinne werde ich mich hier ausschalten, bis du mir das Gegenteil beweist und _gültige_ Argumente vorbringst.

[Elvis]

Man muss allerdings sagen, dass es fast immer native schneller geht. Während man in .Net praktisch immer sicher vor Overflows ist.
Denn was wirklich Performance kostet sind all di Sicherheitsabfragen, die in das native Image gepackt werden.
Delphi hat zwar auch bereichsprüfungen, aber nur ein System-integrierte Runtime mit einem JIT compiler kann sicherstellen, dass an den richtigen Stellen geprüft ird, ob Code von dieser Url, mit diesem Public key, etc. überhaupt auf die HDD zugreifen darf.
Oder ob der Code Datenbankverbindungen öffnen, Dateiben schreiben, oder Fenster vor andere Apps packen darf.

Was Grenzgänger da merkte ist leider etwas, was viele .Net devs nicht wissen: Winforms nutzt GDI+ und das wird schnell sehr lahm, wenn man nicht die üblen Ecken mit DoubleBuffered besetzt.
Zum Beispiel der DataGridView ist fast unbenutzbar ohne DoubleBuffered.

OTOH, Delphis VCL ruckelt und flcikert ebenfalls wie eine japanische Weihnachtsbaumbeleuchtung, wenn man kein DoubleBuffered nutzt. (und manchmal muss man sogar tiefer in die Kiste greifen, siehe XPMan + PageControl)

Ich nutze Mono für OSX, weil ich die Libraries einfach viel besser finde, als den alten, hässlichen Krempel, den man bei C/C++, Java, oder Freepascal vorgesetzt kriegt. (Gilt auch für .Net<->Delphi, btw. Delphi nutze ich nur wenn es absolut keine Möglichkeit gibt, es nicht mit .Net zu lösen)

[Bernhard Geyer]

Zitat von grenzgaenger:

sorry, java ist genauso lahm. aber es ist ein unterschied, ob man ein schnelles programm schreiben kann, da unterstützt, oder ob alleine die architektur gewisse grenzen setzt.

Komisch nur das ich eine Java-Datenbank gefunden habe die um Welten schneller ist als alle bisher für Delphi gefundenen DB's. Sei es nun ADS Local Server, TuboDB oder Absolute Database oder auch Accuracer (Diverse ander wurde wegen hoher Lizenzkosten in unserem Anwendungsfall nicht betrachtet). Und das schneller trotz verwendung von JNI für den Zugriff.

Weitere schnelle Implementierungen bei denen ich keine entsprechende Nicht-Managed-Implementierung gefunden habe ist z.B. Lucene oder Batik.

[grenzgaenger]

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.

aber hast recht, die meisten performancefragen wurden bereits vor 10 jahren, bei java durchgekaut... aber java ist ja noch der schnelle renner gegenüber von .NET .. 8) aber das ist ein anderes thema, und wie gesagt, hat der zwischencode ja nicht nur nachteile .. aber er erfordert eben verwaltungsaufwand, welcher nativ entfällt ..