Delphi-PRAXiS
Seite 3 von 7     123 45     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi oder C# (https://www.delphipraxis.net/156356-delphi-oder-c.html)

implementation 29. Nov 2010 16:47

AW: Delphi oder C#
 
Zitat:

Zitat von mschaefer (Beitrag 1064843)
Braucht man das wenn man IIS und ASP.NET hat?

Man sollte nicht vergessen, dass die meisten Webserver auf Linux laufen, und versuch mal IIS auf Linux zu installieren.
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:

mkinzler 29. Nov 2010 17:53

AW: Delphi oder C#
 
Für Linux gibt es ja Mono (Apache Module mod_mono)

Chemiker 29. Nov 2010 18:19

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

himitsu 29. Nov 2010 18:19

AW: Delphi oder C#
 
Zitat:

Zitat von Hansa (Beitrag 1064816)
Da muss ich doch mal dumm fragen : was soll das ? Programm nur für Windows und damit wird dann irgendwie auf Linux zugegriffen ? :shock: Wo liegt der Nutzen ?

Der Clientrechner läuft mit Windows und die DB läuft auf einem Linux-Server :?:
ist bestimmt nicht unwahrscheinlich

hanspeter 29. Nov 2010 18:24

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

taveuni 30. Nov 2010 07:31

AW: Delphi oder C#
 
Zitat:

Zitat von hanspeter (Beitrag 1064873)
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.
Gruß Peter

Die 2 GByte sind Geschichte wir sind nun bei zehn.

Assarbad 30. Nov 2010 18:33

AW: Delphi oder C#
 
Ich empfehle ganz klar oder.

Insider2004 30. Nov 2010 19:11

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.

messie 30. Nov 2010 19:41

AW: Delphi oder C#
 
Zitat:

Zitat von Insider2004 (Beitrag 1065194)
C# ist 15 Mal langsamer als Delphi EXE Programme.

Hmmm, ich bin auch gerade in genau derselben Lage, mich ins C# einzuarbeiten.
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

R2009 1. Dez 2010 06:36

AW: Delphi oder C#
 
Hi DP'ler,

Zitat:

Zudem muss man sich heutzutage als Delphi-Entwickler auch meist fragen lassen, warum man noch in der Sprache entwickelt. All zu viele Projekte gibt es darin scheinbar nicht mehr, bzw. es gibt mehr neue Projekte auf Basis anderer Sprachen. Somit gibt es wohl auch mehr Entwickler die z.B. C# Code schreiben. Aus dieser Sicht könnte man auch sagen, dass es besser für die Zukunft wäre.
Dem wiederspreche ich energisch. Ich habe versucht Unterstützung für einen Umstieg nach C# zu kriegen und habe Leute gesucht die eine Ahnung von C# haben.
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 07:02 Uhr.
Seite 3 von 7     123 45     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz