nach dem ganzen hin- und her und einmischen von Lazarus-Fetischisten will ich jetzt auch mal meinen Senf dazu geben...
ich denke persönlich nicht, dass es mit Delphi aus ist... dafür war das Produkt (bis D7) einfach zu gut...
selbst heute findet man noch Leute, die mit D5, D6 oder D7 arbeiten, weil sie damit vollkommen zufrieden sind...
so, wie es zur zeit aussieht, ist .NET heutzutage noch nicht das Maß aller Dinge - kaum irgendeine produktive Software benutzt heutzutage schon .NET - Systemsoftware ist damit tlw. garnicht umsetzbar, da .NET in meinem Verständnis vor allem für Standard-Software konzipiert ist...
bisher sehe ich .NET lediglich als Framework - ein Konstrukt, auf das man zurückgreifen kann, wenn man vereinfacht Software schreiben will - vereinfacht heißt hier: viel Standard-Zeugs frei-haus geliefert bekommen möchte...
Ich sage nicht, dass .NET-Programmierung wirklich einfacher ist - ich denke da z.B. an Compare-Klassen (ich frag' mich, welcher depp bei m$ der meinung war, den sch*** von Java klauen zu müssen - so, wie alles andere)...
Ebenso, wie man ohne
VCL programmieren kann (
nonVCL war mal ein Thema), kann man auch heute noch problemlos ohne .NET programmieren...
kommen wir zu den Delphi-Alternativen:
1.) Java
sorry junx, aber Java ist keine Alternative...
Java ist vielleicht plattform-unabbhängig, aber das erkauft man sich dadurch, dass man sogut wie keinen Systemzugriff hat - alles, was mit dem System interagiert muss nämlich von Sun in die Virtual Machine reinprogrammiert werden...
deswegen sieht es in solchen Bereichen ziemlich mau aus...
Kleines Beispiel: ich habe letztens versucht, eine wirklich kleine hierarchische
DB-Engine von Delphi nach Java zu portieren...
nach ein paar Wochen hatte ich keine Lust mehr, weil ich wirklich jeden Speicherkram per Hand erledigen musste (irgendwie musste der Speicher ja als verschiedene Typen interpretiert werden) - bei Delphi waren das ein paar Zeilen, bei Java eine echte Herausforderung...
2.) Lazarus
ich weiß nicht, wie im letzten Jahr die Entwicklung in dem Gebiet fortgeschritten ist, aber als ich Anfang '07 ein Programm, dass Message Handler benötigt hatte, von Delphi nach Lazarus portieren wollte, bin ich frontal gegen eine Wand gerannt...
es ließ sich wunderbar kompilieren - funktionierte aber nicht... fragt mich nicht warum, die Messages wurden einfach nicht behandelt...
zurück unter Delphi funktionierte alles wieder problemlos...
zudem ist das ganze doch noch seeehr user-unfreundlich... die kompilier-zeiten sind der horror, selbst, wenn nichts (!) geändert wurde und man das programm nochmal startet, wird erneut kompiliert... die damals verfügbare komponenten-palette war lachhaft klein und die Strukturierung des FPC-eigenen Quelltextes einfach nur katastrophal...
Wie kann man heutzutage großteile des Quelltextes bitte in *.INC-dateien auslagern? absolut gruselig...
als ob wir in den 80ern wären und das maximum der
unit-größe erreicht hätten...
3.) (C#/VB.NET/....NET)
irgendwo auf den vorhergehenden seiten meinte jemand, dass der visuelle designer von Delphi um längen besser als MFC wäre und nichts besseres kennen würde (aber sich VS.net noch nicht angeguckt hat)... jemand anderes meinte darauf, dass er das mal tun sollte...
die frage ist: wozu? der visual designer von VS.net reicht bei weitem nicht an den von Delphi heran...
natürlich ist die einfachste möglichkeit, auf M$-sprachen überzugehen - und sich dann darüber zu freuen, dass m$ tatsächlich versucht hat, ihren neuen dialekt an einen an c++ angelehnten dialekt anlehnen zu lassen... zu kompliziert? bei c# wurde mehr von java geklaut als irgendwas anderes...
der große vorteil der m$-sprachen ist natürlich, dass sie state-of-the-art sind... die unterstützen die neuste framework-version und sie sehen anderen sprachen zum verwechseln ähnlich... man kann sofort anfangen...
nunja... das problem wird nur, das ganze wieder nach delphi zu portieren, wenn folgendes passiert... (see below)
(btw.: ich hoffe, jeder weiß, dass man .NET-assemblies problemlos nach c#/vb.net deassemblieren kann)
wie man schon mehrfach in der geschichte gesehen hat, ist Delphi nicht totzukriegen...
Borland hat schon einmal den Fehler gemacht, sich von Delphi zu entfernen und hat sich (damals unter dem namen Inprise) vor allem um Middleware-Lösungen etc. gekümmert... auch damals sind die einnahmen stark zurück gegangen...
zumindest, bis sich Borland dann wieder auf Delphi konzentriert hatte, was dem produkt dann sehr zuträglich war...
anscheinend ist Borland, nachdem sie sich die letzten jahre vor allem auf software-life-cycling konzentriert haben, klar geworden, dass es so mit Delphi nicht mehr weitergehen kann... nachdem keiner Delphi kaufen wollte und das ganze jetzt in CodeGear aufgegangen ist, ist es durchaus möglich, dass wieder vermehrt an der Qualität und am Umfang von Delphi gearbeitet wird...
Delphi 2007 (
Win32) war ein schritt in die richtige richtung... es ist durchaus möglich, dass eine .NET-variante aus einem guten Grund zurückgehalten wurde... vielleicht ist dem Entwicklerteam selber klar geworden, dass der .NET-support in Delphi, so, wie er in
BDS'06 war, weder akzeptabel, noch produktiv einsetzbar war...
ich denke, wir werden noch einiges von Delphi hören... vielleicht ist es irgendwann möglich, dass Delphi.NET im .NET-umfeld das wird, was Delphi im
Win32-umfeld seit jeher war - eine zuverlässige, schnelle
IDE, die den entwickler dabei unterstützt, schnell die gestellten anforderungen zu erfüllen...
cheers...