![]() |
AW: Delphi oder C#
Zitat:
Apache wird dir da mehr helfen :freak: Wobei du dann auch gleich PHP, Perl, Python, Ruby oder gleich 'ne Linux Native Binary nehmen kannst, ASP.NET auf Linux wäre wie XFCE auf Windows :mrgreen: |
AW: Delphi oder C#
Für Linux gibt es ja Mono (Apache Module mod_mono)
|
AW: Delphi oder C#
Hallo,
irgendwie diskutiert ihr etwas am Thema vorbei. RalfE hat nicht geschrieben das die Anwendung auf Linux laufen soll, sonder der Interbase-Server soll auf Linux laufen. Bis bald Chemiker |
AW: Delphi oder C#
Zitat:
ist bestimmt nicht unwahrscheinlich |
AW: Delphi oder C#
Ich habe in den vergangenen 2 Jahren als externer Mitarbeiter genau diese Aufgabenstellung gehabt.
Umstellung eines großen am Markt eingeführten Programmsystem von BDE/Paradox auf Interbase/Firebird. Interbase würde ich schon deshalb nicht verwenden, weil es bei CG 5. Rad am Wagen und kostenpflichtig ist. Da sind uns mal vor Jahren bei einem IB Projekt Freitag abend die Client-Lizenzen ausgegangen. Es war ein Drama bis wir weitere Lizenzen hatten. FB ist Opensource. Wenn die Wahl der Datenbank noch frei ist, würde ich heute zu MS-SQL Server tendieren. Hier gibt es eine kostenfreie Personalversion und jenseits von 2GByte wird es dann kostenpflichtig. Bei dem MS-SQL Server ist die Datenbankverwaltung besser gelöst. Die Umstellung von BDE auf C/S hat reichlich doppelt so lange gedauert wie geplant und hat einen deutlich 7 stelligen Betrag (innerbetriebliche Kostenrechnung) verschlungen. Von D7 auf D2010 kommt zusätzlicher Kostenaufwand hinzu, da alle externen Komponenten, sofern diese noch beschaffbar sind, neu gekauft werden müssen. (Unicode) Bei der Umstellung von D7 auf Unicode sind viele Toolhersteller weggebrochen, so dass man u.U. auch noch auf andere Komponenten ausweichen muss. Für Delphi sprechen drei Argumente. 1. Der bereits vorhandene Quellcode. Hier muss allerdings die Datenzugriffsschicht komplett ausgewechselt werden, da vieles was in einem auf TTable gestützten Filesystem problemlos funktioniert, in einem C/S System nicht ohneweiteres geht. 2. Delphi erzeugt etwas robustere Programme, da man alle Bibliotheken in die Exe linken kann. 3. GEfühlt läuft ein Delphiprogramm etwas schneller und hat eine deutlich schnellere Ladezeit beim Erststart. Beispiel D2007 benötigt Netframework 1.1. Auf einigen Rechnern ist D2007 nicht mehr ohne weiteres lauffähig und das alte Framwork muss explizit nachinstalliert werden. Wenn Unicode nicht zwingend erforderlich ist, dann ist es billiger bei D7 zu bleiben. Für Delphi-Programmierer muss man wenigstens ein halbes Jahr Einarbeitungszeit in C# mit einplanen. Wenn man anfängt zu modularisieren, dann ist net durch sein Assembly-Konzept haushoch überlegen und erspart einen die BPL-Hölle, die man sich mit Delphi an Land zieht. Delphi ist als Entwicklungssystem ein solides aber etwas altbackenes System, man wird aber immer der Entwicklung hinterherlaufen. Von D2006 bis heute schleppt die IDE immer noch eine Reihe ärgerlicher Bugs mit, welche einen das Leben schwer machen. Und was XE2/XE3 bringen, das glaube ich erst, wenn ich es sehe. Und wenn dann alles einigermaßen bugfrei ist, dann sind wir bestimmt bei XE5 oder 6. Gruß Peter |
AW: Delphi oder C#
Zitat:
![]() |
AW: Delphi oder C#
Ich empfehle ganz klar oder.
|
AW: Delphi oder C#
Das fertige Programm liegt in Delphi vor. Warum willst Du jetzt die Sprache wechseln?
Wenn Du alles neu programmieren willst und deinen Arbeitsplatz sichern, dann nimm C# (da sollte aber das Kunden-Geld dann nicht ausgehen). C# ist 15 Mal langsamer als Delphi EXE Programme. |
AW: Delphi oder C#
Zitat:
Ich finde .NET 4 recht zügig. Mit VS 2010 (noch als Express im Test) sind viele Kompos integriert, die vorher mühsam nachgebastelt werden mussten (bei uns ist eine Chartkompo immer wichtig). Zu den Kompos möchte ich noch etwas loswerden: ich mache ja viele Installationsroutinen für Kundensysteme (weltweit, verschiedene Rechner, alle Sprachen und Zugriffslevel, kein qualifizierter Support vor Ort greifbar). Bei Delphi kann ich meine Kompos alle in die exe linken, da muss ich auch kundenseitig nichts nachinstallieren. Bei .NET muss man viele Kompos ins Framework installieren sowie das Framework selbst, das birgt ein erhebliches Risiko. Denn beim Client muss ja alles nahtlos und silent integriert werden - oder es sind jeweils Fachleute vor Ort. Das Hinterherrennen hinter einer unsicheren Installation kann die Hölle sein. Grüße, Messie |
AW: Delphi oder C#
Hi DP'ler,
Zitat:
Wir sind, in unserem Konzern sicherlich mehr als 200 Programmentwickler. Wir haben keinen einzigen gefunden der mit C# programmiert geschweige denn es versteht. Visual basic an erster Stelle Delphi an zweiter Stelle C++ an dritter Stelle (vor allem in der Firmwareentwicklung) und ein paar Freaks die Java programmieren. Nochmal zur Diskussion: Die Entscheidung hängt doch im Wesentlichen davon ab was vom alten Code übrig bleiben kann. Ich möchte den Chef sehen, der einer Neuentwicklung zustimmt wenn 70 oder 80% des alten Codes noch verwertbar sind. Umstiegsideen bei einer vorhandenen Lösung, die im wesentlichen funktioniert, sind Träume und kaum umsetzbar. Hier geht es nicht darum was technisch sinnvoll ist, sondern was möglichst schnell möglichst viel Kohle bringt (wir leben in Zeiten des Raubkapitalismus). Du wirst also gefragt: 1.) Wenn du den alten Code behältst wann bist du fertig und was kostet das? 2.) Wenn du neuen Code schreibst wann bist du fertig und was kostet das? 3.) Was kosten beiden Alternativen in Bezug auf Lizensen, Einarbeitung usw. Ich gehe jede Wette ein, dass die alte Lösung bevorzugt wird, aber nicht weil sie besser ist sondern weils schneller geht und damit weniger kostet. Was dich weiterbringt oder mit welcher Sprache du gerne programmieren möchtest interessiert kein Schwein. Grüsse Rainer PS: das sind meine Erfahrungen aus 20 Jahren Softwareentwicklung. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz