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:

Zitat von jaenicke (Beitrag 1396404)

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

Zitat:

Zitat von Medium (Beitrag 1396433)

Kostet der was?

Nein.

Zitat:

Zitat von Medium (Beitrag 1396433)

Ist der kompliziert einzurichten/administrieren?

Nein. Meiner lief nach ein paar Minuten.

Zitat:

Zitat von Medium (Beitrag 1396433)

Wie funktioniert der - auch offline?

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

Zitat:

Zitat von Medium (Beitrag 1396433)

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:

Zitat von Uwe Raabe (Beitrag 1396521)

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:

Zitat von dummzeuch (Beitrag 1396525)

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:

Zitat von Medium (Beitrag 1396385)

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! :dp:

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.

:cheers:

[CCRDude]

Zitat:

Zitat von dummzeuch (Beitrag 1396395)

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:

Zitat von dummzeuch (Beitrag 1396395)

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:

Zitat von Medium (Beitrag 1396431)

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 :-D. 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 :-D. Kann sich heute keiner mehr vorstellen.

Zitat:

Zitat von CCRDude (Beitrag 1396750)

Zitat:

Zitat von dummzeuch (Beitrag 1396395)

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 :-D. Aber sonst nicht.

[jaenicke]

Zitat:

Zitat von MichaelT (Beitrag 1397085)

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

Stabiler als die Delphi IDE ist sie durchaus, allerdings hat Lazarus viele der Features gar nicht erst, die in der Delphi IDE bisweilen Probleme machen. Würde man Delphi bis zur Funktionalität von Lazarus abspecken, wäre die IDE sicher auch viel stabiler.

Ich habe mir Lazarus schon immer wieder mal in letzter Zeit auch angeschaut, aber mir fehlt einfach zu viel im Vergleich zu Delphi. Da hilft es auch nicht, dass die IDE recht stabil läuft.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1397099)

Da hilft es auch nicht, dass die IDE recht stabil läuft.

Dann würdest du ja auch mit Turbo Pascal arbeiten.

Ich kann mich nicht erinnern, dass mir Turbo Pascal oder QBASIC jemals abgestürzt sind oder sonstwie rumzickten. :stupid:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1397105)

Dann würdest du ja auch mit Turbo Pascal arbeiten.

Ich kann mich nicht erinnern, dass mir Turbo Pascal oder QBASIC jemals abgestürzt sind oder sonstwie rumzickten. :stupid:

Vor ein paar Wochen hatte ich nach langer Zeit mal wieder das gute alte UCSD-Pascal auf einem Apple II Emulator gestartet. Lief wirklich flott und stabil. Allerdings hatte ich den Eindruck, daß ich nicht ganz so effizient arbeiten konnte. Kann man sich aber wahrscheinlich schnell wieder dran gewöhnen.

[CCRDude]

Zitat:

Zitat von jaenicke (Beitrag 1397099)

Zitat:

Zitat von MichaelT (Beitrag 1397085)

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

Stabiler als die Delphi IDE ist sie durchaus, allerdings hat Lazarus viele der Features gar nicht erst, die in der Delphi IDE bisweilen Probleme machen. Würde man Delphi bis zur Funktionalität von Lazarus abspecken, wäre die IDE sicher auch viel stabiler.

Wirklich rein aus Interesse (Produktivitätsgewinne sind immer toll), nicht um einen Glaubenskrieg vom Zaun zu brechen: welche Features sprichst Du da an?
Ich bin da wie gesagt nicht auf der Höhe der Zeit, kann nur gut vergleichen mit XE (1), später habe ich mal XE (4 oder 5) angetestet, die aktuelle Starter installierte bisher nichtmal (muss ich mal auf ner sauberen VM neu testen).

[himitsu]

Ich hatte mir von 'ner Weile ein Windows 1.01 und darauf ein Delphi 1 (lag meinem ersten Delphi 4 bei) installiert.
War von QBASIC / Turbo Pascal direkt zu Delphi 4.

DOS+Windows booten und Delphi starten in weit unter einer Sekunde. :lol:

[MEissing]

Zitat:

Zitat von himitsu (Beitrag 1397111)

Ich hatte mir von 'ner Weile ein Windows 1.01 und darauf ein Delphi 1

b2fel...... Delphi 1.0 braucht schon ein Windows 3.

Aus der README.TXT von Delphi 1

Code:

1. MINIMUM SYSTEM REQUIREMENTS
------------------------------
Delphi requires Windows 3.1 or a 100% compatible operating
system, an 80386 or newer processor (486 recommended), and 6Mb of
system memory (Delphi Client/Server requires 8Mb, 12Mb or more is
recommended for Client/Server development). A minimum
installation requires approximately 30Mb of disk space (a full
installation of Delphi Client/Server requires approximately
80Mb).

[himitsu]

Nja, 1.0 und 3.1 waren echt flott, auf einem Athlon 64 (war ja auch nich viel drin) und selbst 95/98 liefen dort krass schnell. (nicht zu vergleichen mit den alten Rechnern :stupid:)


Mist, dachte das wäre im 1 drin.
Ist schon etwas her.

Hatte mir damals paar VMs mit 95, 98, NT4, 2000, XP, Vista und 7 erstellt. (Vista nur 'ne Testversion, die noch rumlag ... hatte ich mir nie persönlich länger angetan)
Dazu jeweils eine Ableitung des Win7 mit je einer meinen Delphi-Versionen.

Und weil es grade rum lag und aus neugier auch Windows noch 1.01, 3.1 (auf Disketten meiner Vorfahren gefunden, die unserem uralten 286er bei lagen) und Delphi 1, 3, 4 und 6.
Also 3, 4 und 6 im XP (wenn ich mich richtig erinnere) und die 1 in was Altem.

War mir grade nicht sicher, wegen dem ganzen 16-Bit zeug, aber mir war so als wäre 3.x schon zu neu und schloss da jetzt einfach auf Windows 1.
Delphi 1, 3 und 6 hatte ich nie benutzt. 1 lag der 4 bei, wegen Kompatibilität mit dem alten Windows, die 3 hatte ich zu Zeiten von XE2 erstanden, mit dem einen Delphi-Buch und die 6 bekam ich geschenkt.

[jaenicke]

Bei mir war es umgekehrt, ich hatte damals Delphi 7, aber einen 486er... Erstaunlicherweise dauerte der Start zwar 15 Minuten ca., aber danach lief die IDE superflott. :lol:

[Neutral General]

Hab mir jetzt nicht alle Beiträge durchgelesen aber nochmal was zu Visual Studio (Winforms + WPF):
Winforms ist zwar von der Programmierung ähnlich wie die VCL in Delphi, aber wie einige Leute schon gesagt haben quasi tot.

Ich war letztens auch in der Situation zu Entscheiden (bzw. zu beraten) ob für ein Projekt lieber Delphi oder C# (WPF) eingesetzt werden soll und ich konnte da keine eindeutige Antwort liefern.
Beide Sprachen sind gut und haben so ihre kleinen Vor- und Nachteile sodass es meistens gar nicht so einfach ist sich zu entscheiden.
Was ich leider sagen muss, ist dass die Delphi IDE (Delphi 10.0) mir in 3 Wochen öfter abgestürzt ist als Visual Studio davor in 2 1/2 Jahren :(
Ich weiß nicht ob es an unserem Projekt liegt oder ob es in den neueren Delphi-Versionen besser ist aber die Abstürze nerven halt leider unglaublich. Z.T. Fehler und Probleme die schon in Delphi 2009 drin waren. Aber wie gesagt: Rein von den Features der Sprachen sind beide definitiv im Rennen.

Und ich würde vorschlagen du gibst WPF nochmal eine Chance. Nicht dass du dich jetzt blind dafür entscheiden sollst, sondern schau es dir mal genauer an und lern es genau kennen bevor du es ausschließt. WPF hat anfangs eine etwas steilere Lernkurve als die VCL und Oberflächen sind auch nicht ganz so schnell gebaut wie mit Delphi (aber es dauert wenn man mal drin ist auch nicht sehr viel länger!). Warum dann WPF? Weil es extrem flexibel und mächtig ist! Ich konnte WPF früher auch nie leiden weil ich es unnötig kompliziert und komisch fand aber nachdem ich bei meinem letzten Arbeitgeber mit WPF zu tun hatte bin ich dann recht schnell reingekommen und und habe es lieben gelernt. Die Bindings in WPF sind den Livebindings in Delphi in Umfang und Performance meiner Erfahrung meilenweit überlegen. Kombiniert mit DataTemplates (und ControlTemplates) kannst du jedes Control komplett nach deinen Vorstellungen modifizieren und anpassen. Für ListViews brauchst du da z.B. keine VirtualListView o.ä. oder ein OnCustomDraw wenn du etwas ausgefalleneres haben willst. Du machst dir ein ItemTemplate und kannst dir da von Grund auf wenn du willst selbst definieren wie so eine Zeile in deiner ListView aussehen soll :thumb:

TLDR: Delphi ist abgesehen von einer etwas instabilen IDE gut. Wenn du etwas anderes ausprobieren möchtest würde ich WPF (C#) empfehlen.

[freimatz]

Zitat:

Zitat von Neutral General (Beitrag 1397120)

Was ich leider sagen muss, ist dass die Delphi IDE (Delphi 10.0) mir in 3 Wochen öfter abgestürzt ist als Visual Studio davor in 2 1/2 Jahren :(
Ich weiß nicht ob es an unserem Projekt liegt oder ob es in den neueren Delphi-Versionen besser ist aber die Abstürze nerven halt leider unglaublich. Z.T. Fehler und Probleme die schon in Delphi 2009 drin waren. Aber wie gesagt: Rein von den Features der Sprachen sind beide definitiv im Rennen.

Dito hier. Es gibt Tage da stürzt Delphi nur einmal ab. Es gibt Zeiten da muss ich Delphi nach jedem [sic!] Programmstart neu starten. Bei TDD also mehrmals pro Stunde.

[himitsu]

Wobei C# auch nur ein halbes Delphi ist. :lol:
Mußt also nicht alles neu lernen, wenn du mit C# anfängst.

Nja, ein paar Aspekte des Pascal flossen dort mit ein, vor allem seit Anders Hejlsberg übergelaufen ist.


Hey, Niklaus E. Wirth wird nächstes Jahr 85. Wo findet die Party statt?

[Medium]

Zitat:

Zitat von Neutral General (Beitrag 1397120)

Hab mir jetzt nicht alle Beiträge durchgelesen aber nochmal was zu Visual Studio (Winforms + WPF):

Ich muss mich hier korrigieren. Ich habe mich mit WPF komplett vertan, und ich wollte eigentlich UWP gesagt haben :oops:

Zitat:

Was ich leider sagen muss, ist dass die Delphi IDE (Delphi 10.0) mir in 3 Wochen öfter abgestürzt ist als Visual Studio davor in 2 1/2 Jahren :(

Ey! Ich habe just heute Vormittag eine Bestellung getätigt! Jetzt ist's zu spät, und du machst mich traurig!

Zitat:

Und ich würde vorschlagen du gibst WPF nochmal eine Chance. [..] WPF hat anfangs eine etwas steilere Lernkurve als die VCL und Oberflächen sind auch nicht ganz so schnell gebaut wie mit Delphi (aber es dauert wenn man mal drin ist auch nicht sehr viel länger!).

Da ein großer Teil bei uns das UI ist (Anlagenvisualisierung), ist das ein immens wichtiger Faktor für uns. Bei Delphi will ich unsere hausinterne Komponentensammlung nun nach und nach zu FMX portieren, aber hier habe ich dann zumindest ein halbwegs gewohntes Umfeld. Der Hüpfer zu WPF könnte sich als so heftig erweisen, dass wir am Ende gar nicht umsteigen. Weil das sind Arbeiten die zusätzlich zum nicht gerade langweiligen Tagesgeschäft laufen müssen. Einer der großen Vorteile für Delphi bei meiner Entscheidungsfindung. (Und nein, mehr Personal ist immer noch keine Option ;) )

Zitat:

Warum dann WPF? Weil es extrem flexibel und mächtig ist!

Was im Umkehrschluss für mich aber auch heißt: Es gibt wenig Standardkrams, wenige fertige (und bezahlbare) Dinge, und mächtig in den Features ist auch immer mächtig Arbeit beim Nutzen. Gegen Arbeit an sich habe ich nichts, aber ich glaube es fehlt einfach die Zeit, um sich mit sowas zu beschäftigen hier. Insbesondere weil ich zu 95% mit den Standardkomponenten von Delphi mehr als auskomme, wir keine "flashy new fancy" UIs brauchen (bzw. unsere Kunden überhaupt nicht wollen), und ich die restlichen 5% praktisch durch die Jedis bedienen kann.
Alles darüber hinaus ist "fluff" der uns nicht besser bezahlt wird, aber einen Haufen Arbeit macht unter der das Kerngeschäft leiden müsste. Wie man es dreht und wendet: Für uns nicht wirtschaftlich.

Zitat:

Die Bindings in WPF sind den Livebindings in Delphi in Umfang und Performance meiner Erfahrung meilenweit überlegen.

Nie genutzt oder vermisst bisher. Vom Grundsatz her muss ich mir das mal begucken langsam.

Zitat:

TLDR: Delphi ist abgesehen von einer etwas instabilen IDE gut. Wenn du etwas anderes ausprobieren möchtest würde ich WPF (C#) empfehlen.

WPF wird dann eher etwas für dann, wenn ich wieder etwas mehr Freizeit habe. Damit muss ich wahrscheinlich erst mal ein paar Monate "spielen" bevor ich es auch nur im Ansatz produktiv einsetzen wöllte.
Hier hat Delphi meinen Recherchen nach immer noch die Nase vorn: Easy-to-use aber dennoch mächtig genug (für uns, in den meisten Fällen). Und vor allem hochintegriert! Fast alle anderen UI Frameworks sind bei weitem nicht so sehr mit ihrer Sprache/IDE verheiratet (was für andere Anforderungen ein riesen Vorteil sein kann!), und müssen erstmal mit dem eigenen Code "verfrickelt" werden.

Ne, es wird vorerst bei Delphi bleiben. Vor allem, dass man jetzt das Mobile Addon dabei hat war ein gutes Argument seitens Emba. Noch brauchen wir es nicht, aber es ist schon prima dem Kunden sagen zu können "klar, könnten wir", ohne dass man dafür gleich wieder eine komplett neue IDE, Sprache und Frameworks erlernen müsste. (Und die paar Schritte die ich mal mit Eclipse (bzw. das, was Google draus gemacht hat) gewagt hatte haben mich ziemlich abgetörnt. Mir ist noch schleierhaft wie manche mit sowas so produktiv arbeiten können und komplexe Apps erstellen. Hexenwerk.)

[Medium]

Zitat:

Zitat von himitsu (Beitrag 1397129)

Wobei C# auch nur ein halbes Delphi ist. :lol:
Mußt also nicht alles neu lernen, wenn du mit C# anfängst.

Nja, ein paar Aspekte des Pascal flossen dort mit ein, vor allem seit Anders Hejlsberg übergelaufen ist.

Ich weiß! Deswegen habe ich meine Abschlussarbeit auch seinerzeit damit entwickelt. C# mag ich sehr! Aber das war noch als WinForms aktuell waren. Die Sprache allein ist es ja leider nicht. Der Hammer wäre ja VCL/FMX mit C#. Uh yeah baby.

[himitsu]

Delphi.NET ... die VCL/FMX in einer "DLL" kapseln und dann drüben verwenden. :lol:

[Neutral General]

Zitat:

Zitat von Medium (Beitrag 1397132)

Da ein großer Teil bei uns das UI ist (Anlagenvisualisierung), ist das ein immens wichtiger Faktor für uns.

Bei meinem letzten Arbeitgeber ging es auch um Anlagenvisualisierung. Und die sind (noch vor mir) von Delphi auf C# umgestiegen ;)

Zitat:

Zitat von Medium (Beitrag 1397132)

Zitat:

Warum dann WPF? Weil es extrem flexibel und mächtig ist!

Was im Umkehrschluss für mich aber auch heißt: Es gibt wenig Standardkrams, wenige fertige (und bezahlbare) Dinge, und mächtig in den Features ist auch immer mächtig Arbeit beim Nutzen.

An Standardkomponenten gibt es im Prinzip alles was es in Delphi auch gibt (abgesehen vllt von irgendwelchen exotischen Sachen.. Keine Ahnung).
Und dann gibt es (wahlweise kostenlos) von Xceed das WPFToolkit in dem nochmal eine ganze Menge weitere Komponenten drin sind. Und über NuGet findet man im Zweifelsfall immer etwas passendes.

Klar unterm Strich ist Delphi eine gute Wahl und wenn es darum geht möglichst einfach/schnell was auf die Beine zu bringen ist Delphi wahrscheinlich (fast) unschlagbar.
Aber mir persönlich hat C# und WPF auch sehr gut gefallen und wenn man die Gelegenheit oder Zeit hat ist C#/WPF sicherlich eine gute Wahl.

[Elrond]

Zitat:

Zitat von Neutral General (Beitrag 1397120)

Hab mir jetzt nicht alle Beiträge durchgelesen aber nochmal was zu Visual Studio (Winforms + WPF):
Winforms ist zwar von der Programmierung ähnlich wie die VCL in Delphi, aber wie einige Leute schon gesagt haben quasi tot.

Mir ist nicht ganz klar inwiefern sich das äußert, wird der Support jetzt in absehbarer Zeit eingestellt? Von offizieller Seite habe ich nichts gefunden. Bugfixes und Features werden/wurden weiterhin implementiert, sprich kein Unterschied zur VCL. Das die Sprünge nicht sonderlich groß sind und in Zukunft nicht viel neues dazu kommt liegt in der Natur der Sache.

Zitat:

Zitat von Neutral General (Beitrag 1397120)

Was ich leider sagen muss, ist dass die Delphi IDE (Delphi 10.0) mir in 3 Wochen öfter abgestürzt ist als Visual Studio davor in 2 1/2 Jahren :(
Ich weiß nicht ob es an unserem Projekt liegt oder ob es in den neueren Delphi-Versionen besser ist aber die Abstürze nerven halt leider unglaublich. Z.T. Fehler und Probleme die schon in Delphi 2009 drin waren.

Das ist normal, die haben was Stabilität angeht geschafft jedes mal schlechter zu werden. Evtl. ist es zu lange her aber ich kann mich nicht daran erinnern das Delphi 5 mehrmals die Woche abstürzte. Das lustige bzw. eher traurige ist, das es einfach jederzeit bei jeder Tätigkeit passieren kann, beim Beenden, beim hinzufügen einer Datei oder sogar einfach beim Speichern (und dabei lässt es sich nie reproduzieren).

[blawen]

Zitat:

Zitat von Elrond (Beitrag 1397136)

Zitat:

Zitat von Neutral General (Beitrag 1397120)

Was ich leider sagen muss, ist dass die Delphi IDE (Delphi 10.0) mir in 3 Wochen öfter abgestürzt ist als Visual Studio davor in 2 1/2 Jahren :(
Ich weiß nicht ob es an unserem Projekt liegt oder ob es in den neueren Delphi-Versionen besser ist aber die Abstürze nerven halt leider unglaublich. Z.T. Fehler und Probleme die schon in Delphi 2009 drin waren.

Das ist normal, die haben was Stabilität angeht geschafft jedes mal schlechter zu werden. Evtl. ist es zu lange her aber ich kann mich nicht daran erinnern das Delphi 5 mehrmals die Woche abstürzte. Das lustige bzw. eher traurige ist, das es einfach jederzeit bei jeder Tätigkeit passieren kann, beim Beenden, beim hinzufügen einer Datei oder sogar einfach beim Speichern (und dabei lässt es sich nie reproduzieren).

Kann ich so nicht bestätigen. Seit der Berlin Version läuft bei mir die IDE stabil und ich hatte bisher nur Abstürze, wenn ich im laufenden Betrieb das Notebook aus der Dockingstation entferne und so vom LAN- ins WLAN-Netz wechsle. Die restliche SW bereitet in diesem Moment aber nicht weniger Probleme - insofern ist alles im gründen Bereich ;-)
Die IDE ist seit der Berlin gefühlt auch deutlich schneller geworden :-)

[bernhard_LA]

was ich mehrfach von Kollegen gehört habe die innerhalb unserer Firma vom "Delphi Team" zu anderen Team und Aufgaben (C++, Python, PEARL, ... ) gewechselt haben:

* DELPHI / RAD IDE ist schon sehr komfortabel
* Software Entwicklung mit Delphi ist sehr effektiv/schnell (wer was mit VBA machen muss kommt sich wie im Straflager vor)


besser als DELPHI ist für mich RAD (Delphi & C++) zwei starke Partner in einer IDE

[jaenicke]

Zitat:

Zitat von Elrond (Beitrag 1397136)

Das ist normal, die haben was Stabilität angeht geschafft jedes mal schlechter zu werden. Evtl. ist es zu lange her aber ich kann mich nicht daran erinnern das Delphi 5 mehrmals die Woche abstürzte. Das lustige bzw. eher traurige ist, das es einfach jederzeit bei jeder Tätigkeit passieren kann, beim Beenden, beim hinzufügen einer Datei oder sogar einfach beim Speichern (und dabei lässt es sich nie reproduzieren).

Bei uns lief die IDE im Gegenteil immer stabiler. Bei XE gab es öfter Abstürze und interne Fehler beim Kompilieren (Rebuild reichte), bei XE6 gab es "nur" noch immer wieder Abstürze, vor allem beim Debuggen und in Projektgruppen, seit 10.0 lief es schon gut und Tokyo stürzt bei mir nur beim Deinstallieren eines bestimmten Packages ab.

Zudem ist Error Insight über die Jahre immer besser geworden. Es zeigt zwar manchmal immer noch Falschmeldungen an, aber bei weitem nicht mehr so häufig wie früher.