Neues Delphi jetzt kaufen, oder weiter nach Alternativen suchen?

[progopa]

Meine Meinung zu dem eigentlichen Problem.

Von Delphi auf irgend eine andere Sprache umzustellen, ist für größere Projekte absoluter Unsinn und Geldverbrennung.
Aus meiner früheren Praxis als freiberuflicher Software Entwickler,kenne ich einige Firmen,
die von Dos auf Windows umstellen wollten und versucht haben, vorhanden Code anzupassen.
An der Umstellung von Dos auf Windows sind sie gescheitert und letztendlich auch Pleite gegangen.
Mit dem Wechseln z.B. zu C# ist man bemüht die Struktur und den Code aufwandsarm umzustellen, obwohl in C# effektivere Lösungen,möglich wären.
Zum Schluss hat man ein in C# geschriebenes Delphi Programm.
Der Anwender merkt wenig Unterschied.
Eher meckert er - Früher war es schneller.
Ich hatte in einem vorhergehenden Beitrag geschrieben, dass ich mit XE2 zunehmend Probleme beim Debug habe.
Inzwischen habe ich weiter gesucht und meine, daß das Problem alle Delphi Versionen haben könnten.
Microsoft hat wohl die Aufruf/Ladefunktionen für Dll geändert.
Das ist nicht mehr mit Delphi BPLs kompatibel und führt zu fast endlosen Nachladeschleifen.
Ich selbst gehe davon aus, dass Microsoft das Problem früher oder später löst.
Damit kann ich bei XE2 bleiben.(Notfalls in einer VM unter Windows 7)

Zu eurem Problem wäre eine Mittelweg denkbar.
RemObjects bietet ein Framwork an, welches Delphi und Dot.Net Applikationen synchronisiert.

So beschreibt Remobjects die Funktion:

Zitat:

Hydra ist ein Anwendungsframework, mit dem Entwickler modulare Anwendungen erstellen können,
die verwalteten (.NET) und nicht verwalteten ("nativen" Delphi) Code im selben Projekt kombinieren und so eine nahtlose Benutzerschnittstelle schaffen.

Link Hydra

Meine Vorstellung wäre den vorhandenen Delphicode so zu lassen wie er ist und nur noch Bug Support zu vorzunehmen.
Neu hinzu kommende Funktionalität dann in Dot.Net und über Hydra als Plugin einbinden.

[Uwe Raabe]

Zitat von jaenicke:

Genau dafür bietet Embarcadero ja eigene Lizenzserver an, die einfach in der jeweiligen Firma stehen...

Zitat von Medium:

Kostet der was?

Nein.

Zitat von Medium:

Ist der kompliziert einzurichten/administrieren?

Nein. Meiner lief nach ein paar Minuten.

Zitat von Medium:

Wie funktioniert der - auch offline?

Insbesondere Offline von Embarcadero, aber auch Delphi funktioniert für bis zu 30 Tage offline vom Lizenzserver.

Zitat von Medium:

Warum überhaupt den Mist mit Aktivierungen, wenn ich es mit mit einem Lizenzserver eh wieder in die Hand nehmen kann?

Der Lizenzserver hat halt auch seine Beschränkungen. Z.B. muss man auf allen Rechnern mit demselben Usernamen angemeldet sein und man kann die IDE auf maximal 3 Systemen gleichzeitig starten.

[himitsu]

Der Lizenzserver ist im Prinzip so etwas sie ein Cached-Proxy, den du in eurem Intranet, bzw. auf eurem eigenem Webserver installierst.

Du installierst/aktivieriest deine gekauften Lizenzen nicht lokal im Delphi, sondern lädst sie "einmal" in den deinen "eigenen" Lizenzserver und danach bist du lizenztechnisch vom Online-Lizenzserver des Embarcadero getrennt.
Anschließend gehst du mit deinem Delphi nicht gegen den Online-Emba-Lizenzserver, sondern gegen deinen Eigenen.

Je nach Lizenzmodel, z.B. Named-User können dann ein/mehrere Delphis auf Windows mit gleichem User-Namen (den gibst du zu jeder deiner Named-Lizenzen dort an) sich aktivieren, und von dessen Aktivierungszähler (der sich aber schnell und leicht zurücksetzen liese).
Oder bei den Concurrent-Lizenzen wird die Anzahl deiner aktiven Delphi-Installationen gezählt. (kannst diese auch wieder deaktivieren und wo anders neu installieren/aktivieren)

[Uwe Raabe]

Matthias Eissing hatte dazu gerade erst ein Webinar präsentiert: Embarcadero Webinar: Lizenzverwaltung in der eigenen Hand mit dem Lizenzserver ELC

[dummzeuch]

Zitat von Uwe Raabe:

Matthias Eissing hatte dazu gerade erst ein Webinar präsentiert: Embarcadero Webinar: Lizenzverwaltung in der eigenen Hand mit dem Lizenzserver ELC

Das ist ein Video über 50 Minuten, soviel Zeit wollte ich nicht investieren. Gibt's das auch schriftlich zum Nachlesen?

edit: Gefunden:
http://docwiki.embarcadero.com/ELC/53/en/Main_Page

twm

[Uwe Raabe]

Zitat von dummzeuch:

Das ist ein Video über 50 Minuten, soviel Zeit wollte ich nicht investieren.

Du kannst mich bei Fragen auch gerne direkt kontaktieren.

[MichaelT]

Nichts spricht dagegen UNIDAC beizubehalten.

Der FireDAC kennt keine Wire Protocols und als die Entscheidung anstand war über die OCI (um die ging es am Ende zu Beginn) zu arbeiten wesentlich schneller.

Die Delphi/RAD Studio Subscription ist leistbar und der Gegenwert passt.

Umstellen auf eine andere Technologie bspw. unter Windows macht wenig Sinn. Die Zanglerei from Scratch ohne Komponenten machte nur Sinn im Kontext vom Web + Mainstream Technologie. Selbst dort begann schnell die Hinwendung zu existierendem Content aus dem Open Source Bereich der zu Beginn mit Leichen der 90er befüllt war.

Du kannst dir den Zukauf einfach nicht ersparen. Die Popularität vom VS war in der Breite schon eher den zugekauften Active X Komponenten ohne Sourcecode geschuldet, die eher unter klassischem VB in Misskredit gerieten. VS/.net war in Relation zu allem zuvor was von MS kam ein massiver Durchbruch.

Selbst so ein Zipfelkind wie ich kann in Delphi Komponenten sich selbst machen.

Ich habe mit der Qualität von Delphi RADStudio an sich kein Problem zumindest nicht unter Tokyo und eigentlich schon lange nicht mehr.

Wenn du konsequent auf Open Source gehst, dann sind die Alternativen sowieso andere.

Zitat von Medium:

Ahoi DP!

Ich bin für jeden Input dankbar!
Und gehe jetzt auch mal nach Hause...
Cheers!

[Medium]

Vielen Dank an alle für die sehr rege und informative Beteiligung!

Im Moment stehen alle Neuronen auf Kaufen, Kaufen, Kaufen. Noch ein wenig lesen, aber ich glaube wir bleiben tatsächlich bei Delphi. Es gibt einfach zu viele Argumente gegen einen kompletten Sprach- und Toolchainwechsel.

[CCRDude]

Zitat von dummzeuch:

Es gibt auch Überlegungen, Delphi ganz zu verlassen, allerdings ginge das wegen der großen Codebasis und der beschränkten Entwickler-Ressourcen nur in Richtung FreePascal/Lazarus. Und da bin ich zwar der Meinung, dass die Produktivität mit Delphi 2007 immer noch höher ist als die von Lazarus.

Diesen Wechsel habe ich vor einigen Jahren gemacht (von Delphi XE sogar), und bisher keinen einzigen Tag bereut. Wo bei mir die Lazarus-IDE im Alltag produktiver ist als XE:

• Refactoring: auch ein Vanilla XE mit Updates auf einem Vanilla Win7 mit Updates spinnt da ständig rum, streikt jedes zweite Mal. Unter Lazarus dagegen unit-übergreifend zuverlässig.
• Refactoring in der Form: ändert auch die Namen im Code, unter Delphi XE nicht.
• Editor: viele Kleinigkeiten (Booksmarks über alle Editoren statt nur im aktuellen z.B., code folding, ...).
• Git: über IDE-Erweiterung, zugegeben, direkt integriert, ist Gold wert.

Das konnte ich gerade erst wieder bestätigen, weil ich Win7 plus Delphi XE frisch als VM aufgesetzt habe (spielen also keine Fremdsoftware oder -komponenten rein), um einen Patch einer alten Projektversion zu kompilieren. Kommt mir verglichen mit Lazarus wieder wie ein Oldtimer vor (ist XE ja auch, aber 2007 sicher noch mehr ).

Zitat von dummzeuch:

Insbesondere ist der Lazarus-Debugger einfach nicht gut genug um komplexe Fehler zu finden.

Meiner Meinung nach ist er vor allem eines: deutlich langsamer! Das nervt, ja. Hat bei uns letztendlich zu einem positiven Umdenken geführt: wir schreiben Code jetzt besser gekapselt und jeweils direkt mit zugehörigem unit test. Das beschleunigt die Fehlersuche so sehr, dass der langsamere Debugger erträglich ist, wiel er viel seltener gebraucht wird. Im übrigen gibt es nicht „den“ Lazarus-Debugger, sondern mehrere. Die Voreinstellung ist gdb, und gdb an sich ist extrem mächtig. Aber halt nicht so komfortabel in die IDE integriert.

Zitat von Medium:

Lazarus hatte ich über die Jahre auch schon ein paar mal in der Hand. Für zum Spaß ist es ganz nett, aber fürs professionelle Umfeld, gerade in unserem, wo ich mich auf gewisse Dinge einfach verlassen können muss, kommt es einfach nicht in Frage.

Spannender weise ist das genau das Argument, weshalb wir kein Delphi mehr einsetzen. Wir haben etliche neue Delphi-Versionen gekauft in der Hoffnung, das längst berichtete Fehler mal behoben werden, und wurden jedesmal enttäuscht. Wir müssen uns teils streng an die MS-Vorgaben für deren Logo-Programme (und andere Programme) halten, und unter diesem Aspekt war Delphi nicht geeignet (bzw. brauchte manuelle Patches an den RTL-Sourcen) und gab es auch keine für uns sichtbaren Bemühungen, das zu ändern.

Apropos "professionell": über viele Versionen hinweg stürzte mir die deutsche Delphi-IDE immer wieder mit einem „List index out of bounds“ ab - reproduzierbar, und wenn ich mich recht erinnere, weil die deutsche IDE deutsche Key-Names und die englische IDE englische Key-Names geschrieben hat, so dass die Projektdateien nicht ohne ungefilterte IDE-Exception zwischen dt. und engl. IDE getauscht werden konnten.

FreePascal und Lazarus dagegen weisen natürlich auch Fehler auf, aber wann immer ich einen Fehler berichtet und einen Patch beigelegt habe, dauerte es in der Regel nie mehr als zwei Wochen (meist nur Tage), bis der Fehler behoben war.

Und das ist für mich entscheidend: ich muss mich auf spontane Anforderungsänderungen seitens Microsoft schnell anpassen können. Bei Delphi waren meine erwarteten Response-Zeiten bei 3+ Jahren, ich habe aber ggfls. nur einen Monat, da kann ich mir bei FP/Lazarus zur Not selber einen Patch schreiben und bekomme meist sogar Hilfe dabei.

[MichaelT]

FPC/Laz ist weiter. Die Lazarus haben sich die Schwächen von Delphi gesucht und genau dort angegriffen . Somit entspricht der Lazarus einer konsequent(er)en Weiterentwicklung von Delphi 7. Das FPC Team und auch das Lazarus Team müssen sie die als 'Fehler' wahrgenommenen Eigenheiten nicht eingestehen. Die Position ist taktisch die attraktivere.

Wobei Delphi deswegen nicht schlechter wurde und die Stärken des einen sind nicht die Schwächen des anderen.

Der Delphi Debugger ist ein anderes Kaliber, auch wenn der Lazarus Debugger resp. die Integration mehr als gut genug ist.

Die LCL ist nicht so ein Sauhaufen bspw... resp. hat halt weniger bis kaum Altlasten. Man fällt zwar über die 'Delphi Altlasten' nicht dauernd drüber. Im Netzt kugelt eben noch zwangsläufig 'Was mal so gemacht wurde' und nicht wie es heute eigentlich gemacht werden sollte rum.

Die Lazarus IDE ist intuitiver mittlerweile, wobei ein Gewöhnungsprozess miteinkalkuliert werden muss.

Lazarus/FPC unter Linux und Windows ist ähnlich deinen (punktuellen) Anforderungen eher auch der plain C Welt näher. Du hast ja keinen C/C++ Builder als Option, egal wie akkurat der sich ausnimmt.

And oh how they danced
The little children of Stonehenge
Beneath the haunted moon
For fear that daybreak might come too soon

So geil ist ALGOL auch wieder nicht.

Der C/C++ Builder wird in 'unserem' Umfeld so geringgeschätzt. Ist aber bezogen auf einen hausgebackenes C/C++ Umfeld sehr angenehm und und auch kompakt.

Je mehr Code du schreibst desto mehr überwiegen die Traditionen der C Welt und die werden im Lazarus anders adressiert. Schottern kannst bis zum Abwinken ...

Das Delphi und EMB kämpfen ja nicht nur mit sich selbst. Ganz heimlich schlicht sich MODULA, PASCAL und OBERON wieder an (nicht am PC) und die IDEs haben teils 1:1 Features wie die Delphi IDE übernommen. Gut genug, dass andere daraus übernehmen ist das RAD Studio schon noch.

Ich brauche kein Windows Logo und will das beim Booten vom Rechner noch nicht mal sehen. Unter Linux ist FPC/Laz top notch.

Delphi ist eben 'legendär' für Erweiterungen und Komponenten. Das Konzept ist ein wenig anders gelagert.

Mein XE auf Win7 schnurrt (32-bit) ohne Änderung auf dem Altar-PC (full bloated Installation mit den damals aktuellen (gut bis 2012/13) aktuellen Komponenten. Der jetzt ist auf Win 8.1 mit Tokyo (ohne Update) und funzt auch sehr gut.

Für ein Einsteiger wird ein Punkt schwierig zu überwinden, nämlich wenn bspw. Units nicht eingebunden sind und daraus Konstanten werden verwendet. Das hat es das Delphi schon ein wenig. Früher unter Pascal/Modula hat man die Funktion einzeln eingebunden . Kann sich heute keiner mehr vorstellen.

Zitat von CCRDude:

Zitat von dummzeuch:

Es gibt auch Überlegungen, Delphi ganz zu verlassen, allerdings ginge das wegen der großen Codebasis und der beschränkten Entwickler-Ressourcen nur in Richtung FreePascal/Lazarus. Und da bin ich zwar der Meinung, dass die Produktivität mit Delphi 2007 immer noch höher ist als die von Lazarus.

Delphi 2007 vs. Lazarus damals . Aber sonst nicht.