Delphi bzw. FreePascal neu erlernen?

[D-User]

Zitat von milos:

... Diese könnte ich auch in C# umsetzen jedoch würde ich dieses Projekt gerne ohne die .NET abhängikeit und mit multi platform lösung anbieten wollen und da stelle ich mir die frage ob ich nun nicht (wieder) anfangen sollte mich in Delphi bzw FreePascal ein zu arbeiten.

...


Momentan sehe ich nur Delphi bzw FreePascal und C++ als potenzielle sprachen, da beide eine Native Anweundung erstellen, multi-platform sind und auch gute IDEs zur verfügung haben.

Java wäre auch eine variante aber da fehlt mir der aspekt der nativen anwendung.

Ich bin gespannt auf eure antworten. ^^

MfG

€dit: Kleine Info: Würde für Delphi die Lazarus IDE und für C++ den C++ Builder benutzen.

Ps: sry für rechtschreibfehler, bin mom am handy^^

meine Meinung:

eigentlich nennst du alle wesentlichen Aspekte.

-Delphi bzw FreePascal sind m.E. nicht so schwer zu erlernen, und da du dich
ja schon mit beschäftigt hast wirst du schnell drin sein

-wie richtig geschrieben, nativ bekommst du nur mit Delphi / FreePascal bzw. C++.
So was ist durchaus wesentliches Kriterium.

-sehr praktisch find ich in Delphi / FreePascal /Lazarus auch
dieses praktische Komponentenkonzept.
Die Komponenten kann man ja dann sogar im C++-Builder verwenden,
seh ich als echten Vorteil an.
Und wenn man Spass dran hat kann man die Komps dann auch ncoh
(weiter)verkaufen

-was dieses ganze Geunke angeht denk ich da sind so einige bezahlte Leute
unterwegs, die ungeliebte Konkurrenz aus dem Weg schaffen sollen.
Das geht ja jetzt schon ne ziemliche Weile so, weit über 10 Jahre.
Würd mich echt mal interessieren wieviel man dafür so bekommt.


Mein Tipp:
Wenn du mit wenigen Leuten entwickelst, mußt du über Aufwand nachdenken.
Da ist dann Delphi / FreePascal durchaus ne gute Option.

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

[mkinzler]

Zitat:

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Delphi ist eigentlich nicht langsamer als C++. Man kann nur keine Treiber o.ä. darin entwickeln

[D-User]

Zitat von mkinzler:

Zitat:

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Delphi ist eigentlich nicht langsamer als C++. Man kann nur keine Treiber o.ä. darin entwickeln

vllt noch zu ergänzen:
man kann auch in Delphi selber optimieren, z.B. statt
Stringkonkatenation mit Format diese schlicht mit +.
Ist bei mir deutlich schneller.

zudem natürlich immer die Möglichkeit, Assembler direkt
einzubinden, wenn man brutal optimieren möchte.
Da wirds dann in .NET-Sprachen auch knifflig...

[TReader]

Was den Stellenmarkt angeht: Bin auch gerade beruflich in die Programmierung eingestiegen. Bei dem Unternehmen bei dem ich jetzt arbeite sah es folgendermaßen aus (auf das wesentliche zusammengekürzt): "Haben Sie neben C# und Objective-C auch Erfahrung mit Delphi?" - "Ja" --> Höheres Bruttogehalt, da Delphientwickler Mangelware sind.

Bei den Vergleichen, was ein Objective-C Entwickler verdient und was ein Delphi-Entwickler verdient hat Delphi die Nase vorn, weil es für die populären Sprachen einfach Programmierer wie Sand am Meer gibt. Klar ist dort die Qualität auch sehr weit gestreut, aber ich trau mich zu behaupten, dass wenn du mit Delphi und der Sprache umgehen kannst immer einen Job finden wirst, der - wie in meinem Fall - sogar besser bezahlt ist als eine der Mainstream-Sprachen.

Just my 2c

[D-User]

noch ein paar kleine Argumente:

Wenn du deine Entwicklungs-Bemühungen in der Gegend verteilen willst,
das .Net -Decompilieren wird anscheinend teilweise als Sport
angesehen:

.Net Decompilierung:
http://www.heise.de/developer/artike...T-1773804.html

und es wäre nebenbei mal sehr interessant zu erforschen ob im
Bytecode tatsächlich nur Programm-Info enthalten ist oder auch
Zusatzinfo.
Ich würde ne Wette eingehen, dass auch Zusatzinfo.
Für VB-"Compilat" gabs diverse Decompiler und auch entsprechende
Storys dazu, sollte sich mit einiger Suche noch finden lassen.


Pascal Vorteilhaft für Cross-Platform-Development
http://www.zdnet.com/pascal-still-an...rs-7000014743/


Meine eigene Experience:
Ich hatte vor ner ziemlichen Weile in VB ein größeres Projekt
quasi komplett fertig.
Dann trat ein Fehler auf, VB kam mit der Komplexität irgendwo
nicht zurecht.
Das war auch nicht sinnvoll zu umgehen, was dann den Umstieg
auf Delphi ausgelöst hat. Da gings dann.

Später noch mal was mit VB 6 probiert, das war aber so buggy
direkt die Finger von weggelassen, für so was hatte ich keine Zeit.

Was mich in letzter Zeit ziemlich geschockt hat waren die
Sicherheitswarnungen vor Java, wohl ein Grundsatz-Problem von
gelayerter (ge-"managter", hahaha, was ein dämlicher Euphemismus ) App-Entwicklung wie in Java oder .Net:

http://www.heise.de/newsticker/meldu...a-1784782.html

[WM_CLOSE]

Zitat:

Was mich in letzter Zeit ziemlich geschockt hat waren die
Sicherheitswarnungen vor Java, wohl ein Grundsatz-Problem von
gelayerter (ge-"managter", hahaha, was ein dämlicher Euphemismus ) App-Entwicklung wie in Java oder .Net:

Nein, meiner Meinung nach sind die Sicherheitsprobleme eher das Ergebnis inkonsequenter Sicherheismechanismen, sowie auch der Versuch das Sicherheitskonzept vom Betriebssystem zu abstrahieren anstatt mit den vorhandenen, auf Kernelebene vom Betriebssystem bereitgestellten Mechanismen zu interagieren.
.Net ist da wieder im Vorteil, da es konsequent das Sicherheitskonzept von Windows benutzt (eben nur schön verpackt). (wie Mono ds macht weiß ich nicht).
Java ist mehr eine Art VM als ein "Layer". Was in der VM geschieht bestimmt nur Oracle (und eben Java Bugs).

Ich muss zugeben, ich bin ein großer Fan von .Net, aber ich glaube es ist zum großen Teil auch berechtigt.
Schließlich ist C# eine Art Weiterentwicklung von beidem: Delphi und Java.

PS: Umfangreiche (kostenpflichtige) Software für den Massenmarkt (z.B. Photoshop) würde ich mit .Net aber nicht herstellen, wegen der Dekompillierbarkeit. Da würde ich eher zu C tendieren, oder eben Delphi (je nach Anwendungsgebiet). Auf exotische Sprachen würde ich aber nicht setzen, weil es einen einfach beruflich nicht weiterbringt und wenn das Projekt umfangreicher wird, hat man Probleme Verstärkung zu finden. (Natürlich muss man sich auf dem laufenden halten, was es neues gibt, aber einen Webserver mit BF will ich jetzt auch nicht umsetzten).

[milos]

Wow, erst mal danke für die vielen, ausführlichen Antworten!

Zitat von Perlsau:

Zitat von milos:

Es wäre toll, wenn mir einige von euch sagen könnten warum ihr gerade bei Delphi geblieben seid und was euch davon überzeugt euer Projekt in Delphi umzusetzen.

Also ich bin und bleibe bei Delphi, weil ich mir so ca. 1994, also vor fast 20 Jahren, (Turbo-) Pascal selber beigebracht habe und inzwischen zu alt bin, um nochmal schnell was ganz Neues zu lernen. Meine alten Hirnwindungen sind zu träge, um nochmal so schnell zu begreifen, wie das vor 20 Jahren noch der Fall gewesen sein mag. Außerdem hab ich erstens schon viel Geld, Zeit und Energie in Delphi investiert, zweitens etliche Projekte mit Delphi am Laufen und drittens keine Zeit, mich in eine völlig andere Sprache einzuarbeiten. Auch wenn Delphi angeblich aussterben soll, sehe ich nicht den geringsten Anlaß, nun eine andere Sprache zu erlernen.

Fast 20 Jahre und nie zu einer anderen gewechselt? Respekt, nach so einer Zeit wäre mir glaube ich die Lust an der Sprache vergangen xD Aber schön zu sehen das du es geschafft hast. ^^

Zitat von WM_CLOSE:

Was Delphi fehlt ist eigentlich nur die marktbeherrschende Stellung. Das aber auch nur aufgrund der meiner Meinung nach schlechten Preispolitik. Ich meine jetzt mal im Ernst: welcher Programmierer will um eine Sprache mal auszuprobieren überhaupt Geld ausgeben? FreePascal wird keiner anfassen, der Visual Studio gewohnt ist. (ich möchte keine Diskussion vom Zaum brechen)

Dies könnte ein Grund sein, jedoch gibt es dafür doch Lazarus. Das einer Lazarus nicht anfasst, als Visual Studio User kann ich mir auch denken, aber da ich anfangs mit Delphi 3 gearbeitet habe, mag ich es. Das bringt bei mir so ein „Ahhh, die alten Zeiten“-Feeling.

Zitat von WM_CLOSE:

Dazu kommt noch, dass Delphi im RAD Bereich einfach zu wenig out-of-the-box zu bieten hat.
Inkonsestens der Komponenten in verschiedenen Versionen ist auch nicht gerade hübsch.

Naja, das wirft bei mir die Frage auf, ob RAD-Tools überhaupt zwingend von nöten sind? Sind zwar Nice-To-Have, aber Delphi bietet m.M.n. andere, wichtigere Vorteile als RAD-Tools die man sich eigentlich auch selbst basteln könnte, bei bedarf.

Zitat von WM_CLOSE:

Da ist das .Net Framework deutlich im Vorteil, vor allem weil es ja auch nur auf die schon vorhandenen Windows APIs zurückgeift. Das .Net Framework ist einfach enorm umfangreich, weshalb man eigentlich kaum noch etwas selber basteln muss. Und viel langsamer als nativ ist es auch nicht (~90% je nach Anwendung).

Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

Zitat von WM_CLOSE:

Weitgehende Plattformunabhängigkeit hat man übrigens mit Mono und .Net auch. Man nuss nur darauf achten, dass man nicht in einen Bug oder ein nicht implementiertes Feature in Mono stolpert.

Über Mono bin ich auch schon seit einiger Zeit gestossen, jedoch würde ich wie gesagt gerne Nativ-Anwendungen schreiben, was mir durch Mono auch nicht möglich ist. Habe ausserdem Mono mal auf meinem Linux-Rechner ausprobiert und war gar nicht zufrieden damit. :-/

Zitat von WM_CLOSE:

Java würde ich jetzt nicht unbedingt für die Zukunft empfehlen, da es meiner Ansicht nach auf dem absteigenden Ast ist, seit dem Oracle damit zu tun hat. Es hat aber den Vorteil, dass das Programm einaml kompilliert, wirklich auf jedem Toaster läuft.

Ja, der grösste (und wohl auch der einzige) Vorteil von Java bleibt wohl, dass jeder, ohne grosse Probleme, Anwendungen für die meisten Betriebssysteme erstellen kann.

Zitat von WM_CLOSE:

Für kleinere Anwendungen, vor allem im Netzwerkbereich setze ich mittlerweile auf Node.JS, wobei es da mit kommerziell etwas schlechter aussieht (Quellcode ist einsehbar (bei .Net über Umwege übrigens auch)).

Genau, habe ich vergessen zu nennen. Mir ist auch wichtig das mein Code nicht einsehbar ist, wobei C# kläglich versagt.

Zitat von WM_CLOSE:

PS: Für die Zukunft empfehle ich dir, währen deiner Ausbildungszeit ein oder zwei Zertifikate zu machen (das CCNA macht man glaube ich sowieso zur Halfte in der Schule), vor allem, weil du in deinem Alter vermutlich kein Studium und auch kein Abi hast. Dabei geht es nur darum deinem potenziellen Arbeitgeber zu zeigen, dass du dein Fachgebiet beherrschst und das auch unter Beweis stellen willst. Wenn man etwas Konkurrenz hat, sind diese Papiere Gold wert.

Danke für den Vorschlag, habe ich gar nicht bedacht und werde ich Mal mit meinen Arbeitgeber ansehen. ^^

Zitat von WM_CLOSE:

PPS: Wenn du glaubst, du bist jetzt ein guter Programmierer, sieh dir deinen Code in 1 oder 2 Jahren nochmal an.

Ich verzweifle schon nur wenn ich sehe welche Fragen ich vor 4 Jahren gestellt habe und nicht einmal Grundlagen der Programmierung kannte und wirklich nichts kapiert habe, obwohl alles gut erklärt war, wenn ich es mir jetzt so ansehe. xD

Zitat von WM_CLOSE:

PPPS: Wenn du es ernst meinst mit Plattfromunabhängigkeit brauchst du von jeder Plattform, die du unterstützen willst ein Gerät. Kannst du dir das leisten beim Ausbildungsgehalt? Ich denke da an Windows PC, Virtuelles Linux System, einen Mac, ein iPhone, noch ein Android Gerät. Ich meine ein Leben hat man doch auch noch, oder? Bei mir hätte das den Geldbeutel gesprengt, da Auto (Versicherung 2k€ im Jahr), Wohnung (4k€ warm im Jahr), neuer PC (1k), diverse Software Lizenzen (1k im Jahr) und Lebensmittel. Und da war ich noch nicht unterweg mit Kumpels oder so...

Ja, ich meine es ernst und ja die meisten Geräte besitze ich. ^^
Windows und Linux PC, Mac OS X für x86 Prozessoren als VMImage (somit kann ich auch einen iOS Emulator benutzen), Android-Smartphone mit 2.2 (HTC Desire) und 4.x (SGS3) und ein älteres Windows Phone von meinem Vater besitze ich alles. Sollte somit den grössten Teil des Marktes abdecken ^^

Zitat von Der schöne Günther:

Sehe ich ehrlich gesagt, ähnlich. Leute, die dir irgendein x-beliebiges Webzeug in PHP und JavaScript findest du wie Sand am Meer. Ich sehe es eher umgekehrt: Nicht auf Teufel komm raus das zu nehmen, was jetzt gerade hipp ist gefällt mir besser (vielleicht auch einfach nur, weil ich eben das getan habe).

Genau, wieso sollte ich in einen vollen Zug steigen, der auch noch dreckig ist, wenn ich in einen halbvollen gehen könnte, der wenigstens alles richtig macht und dabei auch noch besser aussieht?

Zitat von Der schöne Günther:

Und natürlich verlernt man eine Sprache nach ein paar Jahren nicht, aber richtig drin bist du dann auch nicht mehr. Als reiner Anwendungsentwickler wird einem das sicherlich negativ ausgelegt, wenn jemand einen Entwickler für ein bestimmtes Projekt in XYZ sucht und du kannst nur sagen "Ja, damit habe ich vor zehn Jahren mal für zwei Jahre etwas gemacht, aber so richtig drin bin ich da auch nicht mehr..."

Wie gesagt bin werde ich beruflich immer noch mit der Sprache C# konfrontiert, somit wird auch mein Wissen in der Sprache immer weiter ausgebaut. Ausserdem habe ich noch noch ein Projekt das weiterhin gepflegt werden muss und in C# geschrieben wurde. Ich denke, dass ich so schnell C# nicht ganz aufgeben werde ^^

Zitat von Der schöne Günther:

Von daher, wie gesagt: Ich habe die letzten Jahren mit anderen Sprachen verbracht - Hauptsächlich Java und C++. Jetzt bin ich bei Delphi. Und bereue es ehrlich gesagt keine Minute. Wenn man sich heute umschaut, scheint es so viele verschiedene Nischensprachen (mit entsprechend komischen Namen) zu geben wie nie zuvor. Und alle Sprachen haben ihre Anwender.

Warum also nicht auch Delphi?

Naja, man hört überall das es aussterben wird, das wäre ein Grund um nicht Delphi zu lernen.

Zitat von D-User:

-Delphi bzw FreePascal sind m.E. nicht so schwer zu erlernen, und da du dich
ja schon mit beschäftigt hast wirst du schnell drin sein

Hoffe ich doch! ^^ Was mir momentan mühe bereitet sind immer die verschiedenen Wörter die die Sprachen benutzen, aber das gleiche anstellen. Aber daran hat man sich ja relativ schnell gewöhnt.

Zitat von D-User:

-sehr praktisch find ich in Delphi / FreePascal /Lazarus auch
dieses praktische Komponentenkonzept.
Die Komponenten kann man ja dann sogar im C++-Builder verwenden,
seh ich als echten Vorteil an.

Heisst das ich könnte auch in C++ *.DLLs erstellen die auf Hardwarebasis arbeiten und die dann in einem FreePascal Projekt verwenden?

Zitat von D-User:

Mein Tipp:
Wenn du mit wenigen Leuten entwickelst, mußt du über Aufwand nachdenken.
Da ist dann Delphi / FreePascal durchaus ne gute Option.

Momentan arbeite ich alleine an meine Privaten Projekte, aber bin schon einen Freund am „Rekrutieren“ in vb.NET. Werde ihm wohl dann C# oder FreePascal beibringen sobald ich es kann und er das Grundprinzip des programmieren einigermassen verstanden hat ^^

Zitat von D-User:

Wenn es irgendwann mal *komplett* Superhighspeed sein muss, wirst du C++ in
Erwägung ziehen müssen, vorausgesetzt du bekommst die Highspeed-Teile nicht
als fertig einbindbare Bausteine.

Kompletten Source Code in meine Projekte einzubauen, die nicht von mir bzw. von dem Team sind, kommt bei mir nicht in frage. Soweit ich mich erinner kann, habe ich bisher noch nie eine Libary von anderen genutzt, ausser jQuery und die Excel API von M$, worauf ich auch recht stolz bin .

Zitat von D-User:

zudem natürlich immer die Möglichkeit, Assembler direkt
einzubinden, wenn man brutal optimieren möchte.
Da wirds dann in .NET-Sprachen auch knifflig...

Wow, das ist eine sehr coole Nachricht!
Wäre es dann möglich mit Assembler einen JIT-Compiler zu erstellen der die Controls von Pascal benutzt, oder wäre dies dann wieder Pascal und kein Assembler?

Zitat von TReader:

Was den Stellenmarkt angeht: Bin auch gerade beruflich in die Programmierung eingestiegen. Bei dem Unternehmen bei dem ich jetzt arbeite sah es folgendermaßen aus (auf das wesentliche zusammengekürzt): "Haben Sie neben C# und Objective-C auch Erfahrung mit Delphi?" - "Ja" --> Höheres Bruttogehalt, da Delphientwickler Mangelware sind.

Bei den Vergleichen, was ein Objective-C Entwickler verdient und was ein Delphi-Entwickler verdient hat Delphi die Nase vorn, weil es für die populären Sprachen einfach Programmierer wie Sand am Meer gibt. Klar ist dort die Qualität auch sehr weit gestreut, aber ich trau mich zu behaupten, dass wenn du mit Delphi und der Sprache umgehen kannst immer einen Job finden wirst, der - wie in meinem Fall - sogar besser bezahlt ist als eine der Mainstream-Sprachen.

Das ist auch eine tolle Nachricht, leider werden hier keine Delphi entwickler gesucht >.< Aber vielleicht wird es Mal so weit kommen ^^

Ich bedanke mich noch mal für alle Antworten, ich glaube diese haben mich dazu bewegt, mich endgültig zu entschliessen FreePascal zu lernen ^_^
Vielen dank für die Informationen liebe Leute

[WM_CLOSE]

Zitat:

Heisst das ich könnte auch in C++ *.DLLs erstellen die auf Hardwarebasis arbeiten und die dann in einem FreePascal Projekt verwenden?

Ja. Genau das haben früher alle Peripheriehersteller gamacht. Es resultierte in einem totalen Desaster, weil natürlich jeder meinte er müsste einen eigenen Treiber haben und diesen nach 2 Jahren nirgends mehr anbieten*. Setze daher nach möglichkeit auf USB und HID wenn du Hardware ansteuern willst.
Außerdem bist du mit Treibern grundsätzlich Bertriebssystemgebunden. (Linux und Apple Systeme könnten noch funktionieren, aber Windows und *nix eher nicht). Mit HID bist du Plattformunabhängig.

*Versuch mal für eine ältere Webcam oder einen Scanner aus der Zeit Treiber zu finden.
spoiler es wird dir nicht gelingen /spoiler

[messie]

Zitat von milos:

Naja, man hört überall das es aussterben wird, das wäre ein Grund um nicht Delphi zu lernen.

Oder man trifft heute auf viele Leute, die von Delphi schon mal etwas gehört haben, aber es nicht kennen. Grund ist unter Anderem, dass es in den Hochschulen und Berufsschulen nicht mehr gängig ist. Da hat MS das Visual Studio optimal zu einem Zeitpunkt platziert als nicht klar war ob Delphi "weiter lebt". Embarcadero versucht mit seiner Preispolitik im Kielwasser von MS zu schwimmen hat aber die Vorleistung nicht erbracht. Daher bleibt das Visual Studio im Vorteil - zumal die kostenlosen Express-Versionen sehr umfangreich sind.
Klar auch, dass sich viele beim VS für C# entscheiden - ist es als Abkömmling von Delphi doch das einzig wirklich produktive Tool im MS-Portfolio .
Ich habe die Projekte, in denen ich Delphi nicht durchsetzen und wir mit C# arbeiten mussten, bitter bereut. Das ging es um große Datenmengen, Performance bei Berechnungen und bei der Visualisierung. Besonders gestört hat mich aber .NET mit seinen Inkompatibilitäten. Eigentlich sollte es ja besonders portabel sein, ist es aber nicht.

[Phoenix]

Zitat von milos:

Der Grund warum ich auf .NET verzichten möchte ist wie genannt, dass ich Multi-Platform Lösungen bringen will und ohne das .NET Framework auskommen will. Aber .NET ist schon eine tolle Sache, aber ich mag „vorgebasteltes“ Zeug nicht so ^^ Wenn möglich, alles selber schreiben. ^^

So war ich auch mal drauf. Das Nennt sich "Not invented here"-Syndrom und hat einige Nachteile:

1.) Du investierst viel Zeit damit, Infrastruktur-Code zu schreiben, den jemand anderes schonmal geschrieben hat.
2.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
3.) Du verbringst viel Zeit damit, Dich in problemfremde Domänen (Logging, Datenbankzugriff um nur zwei zu nennen) einzuarbeiten um Deinen Infrastruktur-Code überhaupt schreiben zu können.
4.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
5.) Ausnahmslos jeder Entwickler macht Fehler und produziert Bugs. Am Anfang mehr und trivialere, später weniger, aber dafür schwerer zu findende. Je mehr Code Du schreibst, desto mehr Bugs sind da drin. Du verbringst also einen Großteil Deiner Zeit damit, Bugs im Code für Logging und im Datenbankzugriff (nur um mal zwei zu nennen) zu suchen und zu fixe.
6.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.
7.) Der Infrastruktur-Code, der Dein Projekt seinem Ziel nicht näher bringt, ist da. Also muss er gewartet werden.
8.) Du verlierst dabei Zeit, die Du eigentlich damit verbringen könntest, das Problem zu lösen wegen dem Du Dein Programm schreibst.

Letzendlich wirst Du, wenn das wirklich so versuchst, Dein Projekt nie zuende bringen weil Du immer erst nötigen Kleinkram schreiben musst bevor Du Dich um die eigentliche Aufgabe kümmern kannst.

Das kannst Du mir jetzt einfach glauben, oder Du wirst diese Erfahrung selber machen. Letzteres wird teuer (Zeit ist Geld, verlorene Zeit rausgeworfenes Geld).


Andere Leute haben viel Zeit in diese Probleme investiert. Die meisten Lösungen gibt es als Open-Source Komponenten die Du einfach reinziehen kannst. Insbesondere im Java- und im .NET Bereich gibt es hier eigentlich *alles* schon fertig. Sogar mit Unit-Tests. Du kannst Dich also auch davon überzeugen das das Zeug zuverlässig funktioniert.

Schau Dir mal (selbst kommerzielle) Delphi-Komponenten an. Wie viele von denen kommen zusammen mit Unit-Tests?


Zudem: Technologisch ist C# lediglich eine Weiterentwicklung von Delphi. Das, was in Delphi run-time Packages sind, ist das .NET Framework. Die Assembler-Optimierungen, die vorhin mal angesprochen wurden und die Du so cool fandest, finden bei .NET durch das Framework statt. Du kannst niemals bei einer statischen Kompilierung auf das konkrete Zielsystem optimieren, sondern Du kannst nur allgemein pro CPU-Typ optimieren. Mit zig ifdefs. Bei .NET / Mono übernimmt das der Compiler der aus Deinem IL-Code Plattformspezifischen Code bastelt. Und der wird regelmäßig von Leuten optimiert, die davon Ahnung haben und die das Hauptberuflich machen. Glaubst Du, Du kannst neben dem eigentlichen Programmieren in Deiner Problemdomäne auch noch CPU-spezifische Optimierungen auf Assembler-Ebene so gut lernen, dass Du es wirklich beherrschst? Und falls ja: Warum machst Du das dann nicht zu Deinem Hauptjob? Solche Leute werden *sehr* gut bezahlt. Okay, das mag jetzt etwas kätzerisch klingen, aber Grundsätzlich läuft es darauf hinaus:

Nutze das, was Dir geschenkt wird, und kümmere Dich nicht um Probleme am Strassenrand für die es schon Lösungen gibt. Sie führen Dich nur von Deinem Weg ab.

Das was ich da geschrieben habe trifft Grundsätzlich zu. Es gibt Ausnahmen. Und die sind vermutlich für Dich sogar im Moment relevant: Solchen Infrastruktur-Code zu schreiben, dabei Fehler zu machen, diese Fehler zu verstehen und zu korrigieren, ist ein wichtiger Teil des Lernprozesses eines Entwicklers. Diese Fehler darfst Du aber in Deiner Ausbildung machen - bezahlt von Deinem Arbeitgeber. Du solltest das Risiko und die Kosten solcher Fehler nicht in Bereichen eingehen, in die Du persönlich kommerziell investierst.

Cross-Platform als Argument gegen .NET aufzuführen wirkt im übrigen eher uninformiert. Wenn Du Cross-Platform bauen magst, ist Mono definitiv das richtige Werkzeug. Wenn Du Mobile Anwendungen schreiben willst, schau Dir Xamarin an. Sehr viele sehr erfolgreicher Anwendungen für iOS, Android und Windows Phone sind damit geschrieben. Viele Mac-Anwendungen sind mit Xamarin geschrieben (und das funktionier hervorragend). Und - nativ ist das auch noch. Xamarin bzw. auch die OS-X Toolchain für Mono kann IL mit den verwendeten Framework-Klassen in ein natives Kompilat herunterkompilieren. Du brauchst keine Runtime auf dem System. Das ist genauso wie bei Delphi, wo die Runtime-Umgebung und die Komponenten (RTL, VCL) auch direkt einkompiliert werden.

Und um nochmal auf die Verwandschaft von Delphi und C# zurück zu kommen:
Delphi ist inzwischen leider technologisch ein massiver Rückschritt von Delphi. Wenn man die Konzepte hinter LINQ (z.B. Expression Trees) einmal richtig kapiert hat, wird die Sprache als Werkzeug sehr elegant einsetzen können und selbst komplexe Aufgaben sehr einfach und verständlich lösen können. Delphi mangelt es da massiv an modernen Sprachkonstrukten. Du würdest also dort auch noch viel Zeit damit verbringen, um dich um unzulänglichen in der Sprache herumzuprogrammieren, während Du das in C# direkt nutzen könntest. Noch so ein Zeitfresser.

Die Qualitätsprobleme der Delphi-IDE wurde ja hier schon erwähnt (Error Insight, falsche Unterstrichelungen in der IDE, sehr beschränkte Refaktoring-Optionen). Im VS wirst Du solche Probleme nicht finden (dazu investiert Microsoft zu viel in die QS-Abteilung als das Embarcadero es jemals wirtschaftlich sinnvoll könnte - das merkt man aber leider am anderen Ende). Und für's VS findest Du zusätzlich noch geniale Helferlein (ich sage nur ReSharper), die einem das Leben nochmal massiv einfacher machen und die Produktivität stark steigern.

Letzlich ist es also auch eine Frage der Effizienz - und die ist mit C# im VS einfach deutlich höher als mit Delphi. Insbesondere dann, wenn Du C# schon kannst. Sonst kommen natürlich immer noch die Umlern-Aufwände dazu, die einen Anfangs ausbremsen, (was immer auch gerne als Argument "gegen X" genannt wird) aber auch die sind nur einmalig da und hinterher schneller wieder aufgeholt als man nachrechnen könnte.