Delphi vs. C#

Twinsetter

Erfahrenes Mitglied
Hallo zusammen !

Möchte mal eine kleine Umfrage starten und mir ein paar Meinungen einholen.

Ich habe in den letzten Jahren für meinen Arbeitgeber ein Programm geschrieben, um Messergebnisse auszuwerten. Das Programm ist über die letzten 8 Jahre stetig gewachsen. Das Programm ist in Delphi, genauer gesagt in Delphi 4, geschrieben und besteht derzeit aus ca. 350 Units mit ca. 154000 Zeilen Code. Das Programm ist in ein Hauptprogramm und einige Plugins (DLL's) gegliedert. Der Funktionsumfang läßt sich jederzeit durch weitere DLL's erweitern, da ich für die DLL's Schnittstellen definiert habe. Somit können die DLL's auch in anderen Sprachen programmiert werden solange die definierten Schnittstellen implementiert werden.
Bisher habe ich allein an dem Programm gearbeitet.

Mein Arbeitgeber möchte nun, daß sich noch ein weiterer jüngerer Programmierer in das Programm einarbeitet, damit der Fortbestand des Programmes auch zukünftig gesichert ist, denn der Zeitpunkt meines Ruhestandes rückt unausweichlich näher (in. ca. 8 Jahren). Ich kann die Meinung meines Arbeitgebers nachvollziehen und unterstütze auch dieses Anliegen.
Allerdings hat er ein Problem damit, das ich in Delphi programmiert habe und meint, daß es schwierig sei Delphiprogrammierer zu finden - was ich mir nicht so ganz vorstellen kann. Er möchte deshalb, daß das Programm auf eine moderne Programmiersprache umgestellt wird. Sein Favorit ist hierbei C#.
Er will mich hierbei auch voll unterstützen, Software, PC-Technik, Weiterbildungsmaßnahmen etc. Als Zeitraum für die vollständige Umstellung haben wir erst mal 5 Jahre eingeplant. Das alte Programm wird in diesem Zeitraum natürlich weiter betreut und erst abgelöst wenn das neue Programm im Funktionsumfang gleichgezogen hat.

Hört sich alles ganz gut an und ich bin im Grunde auch bereit dazu. Dennoch habe ich auch ein paar Bauchschmerzen dabei.
Ich habe so ein bischen den Eindruck, daß heute alles C# gemacht werden muß, weil's gerade In ist. Nun bin ich der Meinung, das es letztendlich auf die Funktionalität ankommt und da ist es eigentlich egal in welcher Sprache das Programm programmiert wurde. Ich möchte nicht, daß wir hier auf irgendetwas umsteigen, bloß weil es gerade hipp ist, denn das kann in 2 Jahren schon wieder ganz anders sein. Ich neige da dann eher zu einem noch radikaleren Schnitt und tendiere zu einer Webanwendung, da damit dann auch die Tablets abgedeckt werden könnten, die ja doch stark im kommen sind.

Was ist die Meinung der Community dazu?
 
Wenn das Argument "Arbeitskraft" kommt, frage ich mich, warum C# und nicht Java oder C++? Die sind IIRC wesentlich weiter verbreitet als C#. Grundsätzlich bin ich der Meinung: Es macht einem gutem Programmierer nicht viel Mühe, eine neue Sprache zu lernen, das geht wesentlich schneller als ein solch großes Programm neu zu implementieren.

Was das Thema Tablets angeht: Auch hier würde ich zu Java raten, denn Google hat für ihr Android-System eine sehr gut gepflegte und häufig verwendete SDK, allerdings alles in Java.

C# halte ich für den falschen Ansatz.
 
Kann saftmeister nur zustimmen.
Wenn man schon eine Sprache wie C# halbwegs gut kann
geht das Einarbeiten in Delphi in einem Bruchteil der 5 geplanten Jahre.
(Die Kunst wird nur, den Chef zu überzeugen :D)

Und zur Sprachwahl...irgendwann geht alles unter.
Delphi, C#, Java, PHP, C++, ...
Bei C# wird es sicher nicht heute oder morgen soweit sein.
Aber: Delphi verstaubt auch nicht, sondern wird weiterhin betreut.
Dann muss es doch noch einige Leute interessieren...

Auf Arbeitssuche würde das Lernen von Delphi mich jedenfalls nicht abhalten,
wenn ich dafür eine Stelle bekomm...
 
@Saftmeister
Wir scheinen da in die gleiche Richtung zu denken.

Delphi 4 ist natürlich nicht mehr das Aktuellste, aber als ich damals bei mir Kämmerlein mit den Grundlagen zu diesem Projekt angefangen habe, war's halt das was ich auf meiner Kiste hatte. Es gab davor schon ein ähnliches Projekt, welches ich mit Turbovision unter TP/BP gemacht hatte.
Mittlerweile habe ich auch viele Komponenten in Delphi auf die ich nicht mehr verzichten möchte, weil sie eine Top-Funktionalität bieten.
Ich bin ja auch schon dran auf eine höhere Delphiversion umzustellen, allerdings gibt es da noch Probleme , weil ich 2 Kompos eingebaut habe von den ich keinen Quelltext, sondern nur die Binarys habe, was allerdings nicht das Hauptproblem ist, da aktuelle Delphiversionen diese Funktionalität anderweitig bereitstellen. Viel aufwändiger ist die ab Delphi 6 eingeführte Trennung zwischen Designtime und Runtime (DESIGNIDE Problem). Dies habe ich mittlerweile aber fast im Griff und eine Projektkopie wird auch vollständig mit Delphi 7 compiliert, allerdings zur Runtime kommt es noch zu diversen Fehlern und Abstürzen. Sobald diese Version aber läuft, könnte man es dann wahrscheinlich auch mit D2006 bzw. XE zum Laufen bekommen. Ich habe es schon mit anderen Projekten getestet und da hat der Umstieg von D7 nach D2006 bzw das relativ aktuelle Delphi XE keine Probs bereitet.
Die Umstellung auf ein höheres Delphi fällt natürlich aus, wenn es denn wirklich umgeschrieben werden soll.

Java hatte ich auch schon als eine Alternative betrachtet, ist aber momentan noch nicht so richtig mein Ding. Aber wenn ich was neues lernen muß ist es eigentlich egal ob es Java oder C# ist. Persönlich finde ich Java aber noch etwas cryptischer C#. Aber darum geht es nicht, denn ich möchte, wenn man den Schritt tut, was Ordentliches machen.
Mit C++ habe ich auch schon gearbeitet und einen Baustein aus benannten Projekt nach C++ portiert und erweitert. Allerdings muß ich sagen C/C++ ist stellenweise schon sehr unhandlich. Speziell die Stringverarbeitung ist unter Delphi für mein Empfinden deutlich besser als unter C/C++, auch wenn's mittlerweile den Ansistring unter C++ gibt. Was mich diesbezüglich unter C# oder Java erwartet kann ich natürlich noch nicht beurteilen.

Gruß Twinsetter
 
Bei Java und C++ gibt's für so gut wie jeden Anwendungsfall eine Library, die man einsetzen kann. Ich habe früher auch in Delphi programmiert, habe aber sehr schnell gemerkt, das dies eine Sprache ist, die in der freien Wirtschaft so gut wie nicht wahr genommen wird. Heutzutage lernt man an der Uni auch nicht mehr Pascal sondern Java und ein bisschen C++. Und das nicht ohne Grund, die Wirtschaft gibt es vor.

Syntaktisch gesehen sind sich Java und C# sich sehr ähnlich. Beide bieten ziemlich die gleichen Features an.

Was bei Java das Problem für einen Ein-/Umsteiger ist, sind die schiere Unmenge an Libraries, die zu so einem Projekt dazu gelegt werden (müssen). Mal von den kleineren Problemen der Wahl der virtuellen Maschine abgesehen. Gleiches gilt im übrigen für C#.
 
Das habe ich auch schon gemerkt, daß Pascal in der freien Wirtschaft eher eine untergeordnete Rolle spielt und habe mich auch schon gefragt warum.
Fakt ist, daß in der freien Wirtschaft sehr viel in C/C++ gemacht wurde, was sicherlich historisch bedingt ist. Die Sprache hat sich dadurch ähnlich wie Windows zu einem Quasistandard entwickelt. Leider ziehen jetzt viele, die nicht die technischen Details kennen, den Schluß das dieser Standard die 1.Wahl ist, weil sie es nicht besser wissen.
Oftmals kommt dann das Argument "mit der Sprache xyz wird objektorientiert programmiert". Dies mag ja richtig sein, aber heutzutage kann ich eigentlich in fast jeder Programmiersprache objektorientiert programmieren und in sofern ist dies kein wirkliches Argument. Man will eigentlich nur im Strom mitschwimmen und übersieht dabei, das es links und rechts auch noch was Vernünftiges gibt mit dem sich die Aufgabe gut vielleicht sogar wesentlich effizienter lösen läßt.

@Saftmeister
Das mit dem zusätzlichen Overhead (sprich Libraries) die ich bei Java und C# mitliefern muß sehe ich genauso. Was ist wenn Libaries ab einem bestimmten Zeitpunkt nicht mehr gepflegt werden oder mit der virtuellen Maschine, dem OS etc. nicht mehr zusammen arbeiten? Dann ist meist guter Rat teuer und man hat einen Haufen Arbeit den Fehler zu fixen.

Was mir an Pascal sehr gut gefällt ist, daß man durch die strenge Typisierung und den unerbittlichen Compiler gezwungen wird, einen relativ sauberen Programmierstil anzuwenden und i.d.R. sehr strukturiert programmiert. Ich muß eben jede Variable, jedes Objekt erst eindeutig definieren bevor ich damit arbeiten kann. Solche Sachen wie in C, wo ich eine Variable erst dann deklariere wenn sie gebaucht wird.
Klassische Beispiel die for-Schleife:
Code:
 for (int i = 0 .... )
gibt es unter Pascal nicht und ich finde, das ist auch gut so. Dieser Programmierstil verleitet zu unstrukturierter Programmierung und birgt viele Fehlerquellen in sich.
 
Zuletzt bearbeitet:
@Saftmeister
Noch'n kleiner Nachtrag :
Du scheinst ja das Ganze richtig gelernt zu haben. Bei mir sieht das etwas anders aus. Ich habe mal vor vielen Jahren einen kleinen Kurs in Assembler bekommen - war noch an einer PDB11 Kiste, habe aber nie viel gemacht in dieser Richtung. Irgendwann hab ich dann mal den Basicinterpreter auf dem Teil entdeckt und mir ein paar kleinere Sachen geschrieben, um mir die Arbeit leichter zu machen. Später so um 1990 rum hatten ich dann noch mal ne Schulung auf HP300 mit HP-Basic. Hab dann auch noch mal auf dem PC mit Basic bissl rumgerfrickelt, fand ich aber auf Dauer nicht so toll weils immer einen Interpreter braucht.
Irgendwann hab ich mir dann mal autodidaktisch Pascal beigebracht und habe mir damit ein paar kleine Hilfsmittel programmiert. So 1996 hab ich dann die Urversion des Programmes in Turbovision geschrieben. Grund war eigentlich, daß ich zu faul war, immer wieder, die Mittelwerte aus ca. 50-100 Messwerten auszurechnen. Das Programm ist dann immer umfänglicher geworden und hat bei der Ergebnisauswertung und Darstellung ca. 1-1,5h eingespart und die ausgedruckten Protokolle sahen ordentlicher als die Handeschriebenen aus. Ja und weil die Software in meiner Firma gut ankam, sollte ich was machen was alle gut benutzen können und möglichst Windowslike ist. Ja und da war Delphi für mich die erste Wahl zumal es damals die Standardversion von Delphi 4 für ca. 140,- DM gab. Die Delphi IDE war damals schon was Tolles und soweit ich mich zurück erinnere gabs auch nichts Vergleichbares.

Noch ne Frage hätte ich:
In meinem Projekt arbeite ich viel mit Tabellen (halt Messwerterfassung und -darstellung). Jetzt habe ich mal ein bischen mit mit C# von Delphi 2006 und Visualstudio 2010 probiert und mal ein kleines Projekt kreiert. Was sich leider nicht gefunden habe ist ist eine vernünftige Tabellenkomponente. Gut das Standardstringgrid von Delphi ist auch nicht der Weisheit letzter Schluß, aber wenn's sowas für C# geben würde dann wär's zumindest eine Basis mit der man was machen kann.

Gruß Twinsetter
 
Nunja, ein C/C++-Compiler (insbesondere GNU) haben auch sehr viele Schalter, mit denen man sich zu gutem Stil zwingen kann. Da seien nur -std und -Werror erwähnt.

Man sucht sich in der Regel nur Libraries aus, die auch gut gepflegt werden. Das kann man heutzutage sehr gut an den Treffern in Google entscheiden. Die Runtime/VM sollte man sich anhand der gleichen Kriterien aussuchen. Letzendlich hat man mit Delphi das gleiche Problem: Wenn die VCL Komponenten anbietet, man auch noch verwendet, die mit Windows XYZ nicht mehr zusammen arbeiten, hat man das gleiche Problem ;-)

Objekt-Orientiertes Programmieren wird häufig überschätzt. Ich habe eine paar Dienste in reinem C geschrieben, die tun ihr Werk, ohne das jemand davon was merkt (im Hintergrund halt). Und dabei werden sogar Enterprise-Komponenten angesprochen, die in Java geschrieben sind.

Ich hab das nicht wirklich gelernt, falls du meinst, das ich studiert habe. Ich habe eine Systemintegrator im dualen System gelernt. Aber schon sehr früh autodidaktisch in Programmiersprachen wie damals noch AmigaBasic, Rexx, C und ASM (bin noch relativ jung - 32 - im Vergleich zu dir, der/die bald in den Ruhestand geht).

Abhängig von der .NET-Version, die du einsetzen willst, gibt's schon mal die MS-eigene GridView (http://msdn.microsoft.com/de-de/library/system.windows.controls.gridview(v=vs.85).aspx). Außer dieser gibts noch http://msdn.microsoft.com/en-us/library/system.windows.controls.grid(v=vs.85).aspx. In gallileo-computing gibt es ja dieses schöne OpenBook über Visual C# 2010 und darin noch ein Kapitel speziell für dieses Thema: http://openbook.galileocomputing.de/visual_csharp_2010/visual_csharp_2010_18_008.htm
 
Hallo Saftmeister

Du bist ja wirklich noch jung aber so richtig alt bin ich auch noch nicht :). Uns trennen 22 Jahre. Nun fragst Du Dich wieso ich sage in 8 Jahren Rente? Ich habe definitiv nicht vor bis 66 zu arbeiten und wenn ich ein gutes Vorruhestands bzw. Altersteilzeitangebot bekomme, dann werde ich es annehmen. Mein Ziel ist es mit 62 in die Rente zu gehen und so scheint auch mein Arbeitgeber zu planen, deshalb kam er jetzt auch auf die Idee das da noch was nachkommen muß. Ist ja auch korrekt, wenn man da frühzeitig plant.

Du hast Dich ja richtig ins Zeug gelegt und mir jede Menge Links geschickt. Ich hab es mir schon mal kurz angeschaut. Aber das Zeugs macht auf mich irgendwie ein crottigen Eindruck - das Handling des Stringgrids unter Delphi scheint mir da einfach besser zu sein. Allerdings nutze ich das Standardgrid selten sondern eine Freewarekomponente Namens TStringAligGrid mit der man fast alles erschlagen kann.

Deiner Meinung zur Objektorientierung stimme ich voll zu. Es braucht nicht immer Objekte. Oftmals reicht simple procedurale Programmierung um eine Aufgabe effizient zu lösen - so wie für manche Dinge auch ein einfaches Kommadozeilentool besser geeignet ist als irgendwelcher Klicki-Bunti Mist. Wir neigen aber mittlerweile dazu allen ein mölgichst schickes GUI zu verpassen, egal ob es Sinn macht oder nicht und nehmen dafür einen großen Overhead in Kauf.
Und genauso ist es mit C#. Da muß ich ein komplettes Framework mitliefern, welches die Größe des eigentlichen Programmes um ein mehrfaches übersteigt und wehe wenn da da mal was fehlt oder ne Datei beschädigt wird, dann funktioniert alles nicht mehr. Mal abgesehen davon, daß wir ja auch nicht wissen was zukünftige Windowsversionen bringen. Läuft dann ein .Net4.0 bzw. Programmme die darauf aufsetzen überhaupt noch ? - man weiß es nicht. Bei klassischer Programmierung, also C, C++, Pascal und was es sonst so da noch gibt, sieht das doch etwas anders aus. Die compilierten Binaries setzen i.R. auf das Windows-API auf und solange ich keine speziellen API-Funktionen, die es nur in bestimmten Windowsversionen gibt, benutze, dann funktioniert mein Programm sowohl unter Win98 als auch unter Win7. Nun macht heutzutage kaum noch jemand was mit Win98, aber mit Win2k z.B. wird auch in unserem Unternehmen und insbesondere bei unseren Kunden noch hier und da gearbeitet. Da wird wohl .Net zumindest die 4.0 nicht laufen.
Einen weiteren Vorteil von Borland Delphi (jetzt Embacadero) sehe ich darin, das zumindest bis D2006 die Quellen mitgeliefert wurden, so daß man im Notfall auch mal einen Fehler selbst fixen kann. Wie ist das eigentlich bei .Net?-ich weiß es nicht.

Gruß Twinsetter

PS: Falls Du auch in C# was machst habe ich heute Nachmittag hier http://www.codeproject.com/Articles/3531/SourceGrid-Open-Source-C-Grid-Control eine wie mir scheint ganz passable Gridvariante gefunden.
 
Ich mach selten was in C#, aber wenn, dann sowohl for .Net als auch für Mono (Platform-Übergreifend und Open-Source). Möglicherweise kann man das sogar mit Windows 2000 laufen lassen (weil Sourcecode verfügbar).

Hier die Kompatibilitätsseite zu .Net: http://www.mono-project.com/Compatibility

Aber es muss ja nicht unbedingt .Net 4.0 sein. Die von dir gelinkte Grid-Komponente setzt nur .Net 1.0 bzw. 1.1 voraus. Das ist auch für Windows 2000 verfügbar: http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5
 

Neue Beiträge

Zurück