Ist es mit delphi aus?

[Heffalump]

Zitat von mkinzler:

Zitat:

Wieviel könnt ihr von Delphi32 noch in .NET Delphi verwenden ?

In Vcl.Net schon

Und, macht das Sinn? Die VCL.Net ist doch Aufgrund der Inkompatibilitäten für den geschäftlichen Entwickler nicht geeignet, sondern doch eher was für Hobbyprogrammierer. Ich kann die Programmierung auf VCL.Net Basis nicht empfehlen. .Net und Delphi passt nicht mehr. Das Produkt kann aus der Entwicklung genommen werden. Damit bekommt Codegear mehr Ressourcen für die weitere Entwicklung von Nischenprodukten.

[Insider2004]

Noch was: Mich wundert immer wieder, mit welcher Vehemenz neue Technik verteidigt wird. Nicht alles was Neu ist, ist auch besser. Java und .net sind da schöne Beispiele. Sie sind ca. 10-15 langsamer als native Code. Performance-mässig werfen sie einen Entwickler 10 Jahre zurück (welcome to 1998)!

[Bernhard Geyer]

Zitat von Insider2004:

Ich rede davon, dass sie jedes mal beim Ausführen einer .net-exe geladen werden muss. Dann muss der Jitter loslaufen. Dann erst läuft dein .net Programm (mehr oder weniger schnell).

Ok, falsch verstanden.

Und? Schau mal auf einem "normalen" Rechner an welche DLL's du auch sonst noch unabsichtlich lädst DLL-Injection, .... Da macht ein .NET-Runtime den Kohl auch nicht fett. Und da die Runtime die IL beim ersten ausführen Blockweise übersetzt ist nur der erste durchlauf langsamer. Will man das nicht haben kann man ja "richtig" kompilieren. Und oft ist eine .NET-Exe schneller als ein entsprechendes Delphi/C++-Programm. Stimmt zwar nicht immer aber würde ich für 95-98% der Fälle unterschreiben.

[Insider2004]

.net wird nie schneller sein als eine native exe. Wie denn auch? Sie muss schon systembedingt langsamer sein, weil gejitted werden muss. Diesen Teil hat der dcc32 bereits beim Compilieren miterledigt. Der EXE-Nutzer wird nie wieder damit belästigt werden.

[Elvis]

Zitat von Insider2004:

Wieso lädst Du deine .net-Umgebung jedes Mal aus dem I-Net?

Ich rede davon, dass sie jedes mal beim Ausführen einer .net-exe geladen werden muss. Dann muss der Jitter loslaufen. Dann erst läuft dein .net Programm (mehr oder weniger schnell).

Arrgh...
Warum kriege ich immer so einen Krampf wenn ich deine Beiträge lese?

Die Runtime wird geteilt auf alle .Net Prozesse, die Core assemblies, bzw. alle Assemblies mit native Images (ngen, schon mal gehört?) werden über alle Prozesse verteilt.
Und das Jitting beschränkt sich auf die Code-Pfade die direkt und sofort benötigt werden.
Deine App wird also nicht komplett durch den Jitter gejagt, das Jitting reduziert sich maximal auf etwa 100 - 200ms beim Start einer App.
Es sind die vielen Bibliotheken, die von der Platte in den Speicher geladen werden wollen, beim ersten Start einer .Net Anwendung, die wirklich zu einer signifikanten Verzögerung führen können. (Beim ersten Start einer .Net App innerhalb einer Windows-Session).
Wenn jemand herkommt und sagt, dass VB in jedem Sinne Delphi unterlegen ist, und somit Delphi absolut überlegen ist. Dann ist das OK, denn es stimmt.
.Net ist Delphi aber nicht überall unterlegen, genauso wie Delphi nicht überall schlechter ist.
Keine von beiden ist nämlich ein Superset des anderen, so wie Delphi ein Superset von dem ist, was VB kann. Und deshalb ist es kompletter SCHWACHFUG, dass du hier herkommst, dich aufplusterst, und solchen Blödsinn schreibst:

Zitat von Insider2004:

Microsoft's-.net-Java = Suns-Java = völlig unbrauchbar, wenn man gescheite Applikationen entwickeln will. D.h. wenn ich ein 400 byte Programm laufen lassen will muss ich erst 14 MB Runtime-Environment laden, dann muss ich jitten, und dann geht's erst los. Gutes Konzept, oder?

Ich habe gerade Azureus Vuze offen, sehr schönes Tool, das ich schon auf Linux/OS X und Windows benutzt habe. Ganz klarer Fall von einen Tool, dass von Java, SWT und dem Eclipse RCP profitierte.
UND es ist ganz sicherlich eine "gescheite" Anwendung, was auch immer das aus deiner Feder bedeuten mag.
Ich würde auch den Großteil aller Systeme, die ich in den letzten Jahren verzapft habe, als "gescheit" bezeichnen...

[OregonGhost]

Zitat von Insider2004:

Sie muss schon systembedingt langsamer sein, weil gejitted werden muss. Diesen Teil hat der dcc32 bereits beim Compilieren miterledigt. Der EXE-Nutzer wird nie wieder damit belästigt werden.
[...]
Microsoft's-.net-Java
[...]

Irgendwie habe ich gerade ein Déjà vu
Hatte gerade vor kurzem mit jemandem, der auch in diesem Thread native Anwendungen so vehement verteidigt hat, ausführlich über .NET gesprochen. Er ließ jedenfalls mit sich reden und gab zu, dass er vieles darüber noch nicht wusste. Bei dir halte ich mich kurz: Der JIT-Compiler läuft maximal einmal über den Code. Danach kann eine gecachete Version genommen werden. Wem das zuviel ist, der kann das native Image einfach mit NGEN (bereits weiter oben von Elvis erwähnt) im Vorfeld erzeugen, viele .NET-Anwendungen tun das während der Installation. Also bitte aufhören mit solchen schlicht falschen Aussagen wie "systembedingt langsamer, weil gejitted werden muss". Ich bin, obwohl absolut kein Java-Liebhaber, weder als Entwickler noch als Anwender, auch immer wieder überrascht, wie schnell Java-Anwendungen sein können. Lieber mal richtig informieren. Ich gebe dir noch denselben Tipp wie dem letzten: Lad dir mal das DirectX SDK runter und vergleiche die Performance der Samples, die es in C++ und in C# gibt. Du wirst überrascht sein. Und dass XNA, eine DirectX-Version für Windows und X-Box 360, auf C# setzt, ist auch kein Zufall. Das heißt alles nicht, dass managed code die Lösung für alles und nativer Code die Wurzel allen Übels ist. Aber managed code ist auch nicht das Teufelszeug, von dem einige hier immer sprechen und die Performance ist nicht unbedingt das große Argument gegen managed code
Und wenn die Linux-Fans sich mal ein wenig vom üblichen "das kommt von Microsoft, also ist es schlecht" lösen würden, könnte sich .NET / Mono / dotGNU vielleichts sogar nochmal als das goldene Ei der Plattformunabhängigkeit erweisen. Denn ein und dieselbe Binärdatei auf Linux und Windows direkt starten zu können ist schon cooler, als den Compiler zweimal bemühen zu müssen.
Ansonsten hat Elvis, mit dem ich zwar nicht immer einer Meinung bin, aber der einfach recht hat, noch einen erheblichen Teil dazu geschrieben. Auch über das "Kaltstartverhalten" einer .NET-Anwendung, das insbesondere bei WPF-Anwendungen auffällt, das aber wie erwähnt nicht wirklich etwas mit dem Jitter zu tun hat.

Aber ich habe sogar noch etwas zum Thema. Es gibt eine neue MFC-Version? Oha. Hoffentlich wird das dann ein ähnlicher Sprung wie Direct3D 7 => 8. Ansonsten wüsste ich nicht, was in der Windows-Entwicklung noch großartig für C++ sprechen sollte, außer natürlich Qt, aber das ist dann ja nicht mehr Windows-spezifisch. Die MFC ist zwar schnell, weil ja eigentlich nur ein Thin Wrapper um die Windows API, aber irgendwie ist sie uncool.
Was Delphi hingegen angeht, ich finde, eigentlich hat es nur eine wirkliche Schwäche, und das ist die (mangelnde) Plattformunabhängigkeit. Gäbe es die (und eigentlich ist Borland doch zum Handeln gezwungen durch Lazarus), spräche kaum noch etwas gegen Delphi. Ich meine, hey, man kann sogar die Delphi-IDE zum Entwickeln und dann Lazarus/Freepascal zum Übersetzen verwenden

Davon abgesehen wird Delphi auch nicht wirklich sterben, solange es genug Leute verwenden. Man benutzt eine Sprache ja nicht, weil sie einen schönen Namen hat, sondern weil sie das beste Tool für einen bestimmten Zweck ist. Und Delphi ist als Sprache und Umgebung ja eigentlich immer noch sehr mächtig. Mal sehen, was draus wird

[Hisoka]

Zitat von OregonGhost:

Und wenn die Linux-Fans sich mal ein wenig vom üblichen "das kommt von Microsoft, also ist es schlecht" lösen würden, könnte sich .NET / Mono / dotGNU vielleichts sogar nochmal als das goldene Ei der Plattformunabhängigkeit erweisen. Denn ein und dieselbe Binärdatei auf Linux und Windows direkt starten zu können ist schon cooler, als den Compiler zweimal bemühen zu müssen.
Ansonsten hat Elvis, mit dem ich zwar nicht immer einer Meinung bin, aber der einfach recht hat, noch einen erheblichen Teil dazu geschrieben. Auch über das "Kaltstartverhalten" einer .NET-Anwendung, das insbesondere bei WPF-Anwendungen auffällt, das aber wie erwähnt nicht wirklich etwas mit dem Jitter zu tun hat.

Hallo, deine Aussage zeigt wieder das Windows Nutzer wohl die MS Geschichte nicht kennen. Genau wegen dieser Geschichte sind viele Linux Nutzer auch gegen .NET. Denn man kann davon ausgehen, das wenn sich DOTNET durchsetzten sollte, wird MS einfach ein paar Sachen im Framework ändern und schon wieder kann man die erstellten Anwendungen nicht mehr unter anderen Systemen ausführen. Dies passierte schon damals bei Java und das wird wohl wieder passieren. Dazu kommt das Problem mit den Patenten, wo auch nicht klar ist wie lange das gut geht.
Zu dem sind die derzeitigen Mono Anwendungen noch untragbar langsam und ziehen extrem viel Prozessorleistung und sie sind alle nicht stabil. Dazu kommt das sie der Entwicklung immer etwas hinterher hinken.

Also auf die theoretische Plattformunabhängigkeit des .NET Frameworks würde ich nicht bauen.

Naja ich hab mich von Delphi verabschiedet. Die IDE fand ich nie benutzerfreundlich und die Sprache war auch nicht optimal. Dazu kam dann das Delphi 2005 extrem langsam war und sehr viele Ressourcen gefressen hat. Ist das eigentlich in aktuellen Versionen anders?

[OregonGhost]

Zitat von Hisoka:

Denn man kann davon ausgehen, das wenn sich DOTNET durchsetzten sollte, wird MS einfach ein paar Sachen im Framework ändern und schon wieder kann man die erstellten Anwendungen nicht mehr unter anderen Systemen ausführen.

Ein Grund mehr, dass Mono und dotGNU so weit kommen, dass sie eine ernstzunehmende Alternative zu .NET sind, oder? Solange man immer hinten ansteht, braucht man sich nicht zu wundern. Davon abgesehen ist .NET ein ECMA-Standard - und nicht so ein komischer wie das Office-2007-Format, sondern ein vernünftiger. Es könnte also theoretisch auch passieren, dass das ganze .NET-ist-doof-Gehabe nach hinten los geht. Ich würde es jedenfalls nicht ohne Weiteres abschreiben, und ich würde mich freuen, wenn es sich durchsetzen würde. Es ist für mich einfach sooo viel angenehmer als C++ oder natives Delphi

Edit: Mal davon abgesehen, dass es keine große Rolle spielt, was sich nun genau durchsetzt. Es ist ja nicht so, dass man sich nicht relativ schnell an andere Frameworks/Sprachen gewöhnen kann.

[Elvis]

Zitat von OregonGhost:

Edit: Mal davon abgesehen, dass es keine große Rolle spielt, was sich nun genau durchsetzt. Es ist ja nicht so, dass man sich nicht relativ schnell an andere Frameworks/Sprachen gewöhnen kann.

Jupp, das ist definitiv ein Punkt...

@Mono & Linux
IMO, stellt MonoDevelop momentan die beste RAD für Linux dar, denn es zielt nicht auf Winforms, sondern direkt auf GTK#.
Dadurch dass man gleichzeitig noch die exzellenten Bibliotheken von Mono zur Verfügung hat, würde iches für Linux-only Apps Lazarus/FPC vorziehen. Denn FPC's RTL ähnelt mir zu sehr der altbackenen Delphi RTL, aber das mag man vllt. mit viel Augen-zu-drücken als Geschmacksache abtun...

[Hisoka]

Zitat von Elvis:

Zitat von OregonGhost:

Edit: Mal davon abgesehen, dass es keine große Rolle spielt, was sich nun genau durchsetzt. Es ist ja nicht so, dass man sich nicht relativ schnell an andere Frameworks/Sprachen gewöhnen kann.

Jupp, das ist definitiv ein Punkt...

@Mono & Linux
IMO, stellt MonoDevelop momentan die beste RAD für Linux dar, denn es zielt nicht auf Winforms, sondern direkt auf GTK#.
Dadurch dass man gleichzeitig noch die exzellenten Bibliotheken von Mono zur Verfügung hat, würde iches für Linux-only Apps Lazarus/FPC vorziehen. Denn FPC's RTL ähnelt mir zu sehr der altbackenen Delphi RTL, aber das mag man vllt. mit viel Augen-zu-drücken als Geschmacksache abtun...

Das Aber auch nur im Bereich von Mono. Sonst gibt es genug andere RAD IDEs.
z.B. Netbeans(Matisse),Code::Blocks(C++ & wxGTK),KdevelopDesigner,...
Diese sind auch nicht unbedingt umständlicher zu bedienen und teilweise sogar einfacher.

Ich bin aber auf jeden Fall gespannt wie sich alles entwickelt. Aber Delphi für Win32 geb ich keine große überlebens Chance. Denn Win32 wird spätestens aussterben wenn die meisten Nutzer 64 Bit prozessoren haben(ich habe 3 Rechner und nicht einer hat ne 64 Bit CPU ). Aber das wird noch etwas dauern. Wenn man bedenkt das viele Nutzer Vista nicht wollen und der 64Bit Support für XP nicht gerade der beste ist.