Delphi bzw. FreePascal neu erlernen?

[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.

[Olli73]

Zitat von Phoenix:

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.

Dazu hätte ich auch mal eine Frage, denn ich habe mich bisher nur oberflächlich damit beschäftigt.

Genau das, was du schreibst, habe ich mir auch immer gedacht; nämlich, dass die .net-Programme nach dem ersten Starten (= "Kompilieren für Zielplattform" ?) ja wegen der Optimierungen für die konkrete Zielplattform schneller sein müssten. Man liest aber immer, dass .net i.d.R. langsamer ist. Woran liegt das nun? Ist es nur die garbage collection? Ist das OS/Framework einfach (noch) nicht gut genug dafür optimiert? Oder stimmen die Aussagen nicht, die man überall so liest?

Also zweites frage ich mich, wie die Zukunft von .net aussieht. Als MS damit gestartet ist, hatte ich es so aufgefasst, dass es zwar zunächst ein Framework/Laufzeitumgebung ist, aber zukünftige Betriebssysteme "darum herum" gebaut werden sollen, also .net das "native Kernsystem" werden soll und "alte" Technologien (Win32, COM, ...) dann nur noch emuliert werden. Also in etwa so, wie Windows am Anfang nur ein Aufsatz für DOS war und später dann DOS in Windows "emuliert" wurde.

.net/C# wird zwar nicht verschwinden, aber oben skizzierten Stellenwert wird es wohl auch nicht mehr erreichen? Hier beziehe ich mich auf die Entwicklung von z.B. Windows Phone. Bei WP7 hat MS noch voll auf C#/.net/silverlight gesetzt. Bei WP8 und Win RT ist die neue "Schlüsseltechnologie" auf einmal ein (modernisiertes) COM. Sieht für mich so aus, als ob MS zwar weiterhin .net/C# supportet, aber nur als Option, mit einem geringeren Stellenwert.

Wäre schön, wenn jemand meine Darstellungen bestätigen oder widerlegen könnte (wie gesagt, habe mich nur oberlächlich damit beschäftigt).

[Robotiker]

Ich denke das ist etwas offtoppic, vielleicht sollte man die Frage abtrennen.

Aber zu zwei Details der Frage gab es erst kürzlich Antworten von MS.

Zitat von Olli73:

Als MS damit gestartet ist, hatte ich es so aufgefasst, dass es zwar zunächst ein Framework/Laufzeitumgebung ist, aber zukünftige Betriebssysteme "darum herum" gebaut werden sollen, also .net das "native Kernsystem" werden soll und "alte" Technologien (Win32, COM, ...) dann nur noch emuliert werden.

Zitat:

This is a 199x/200x meme that’s hard to kill – “just wait for the next generation of (JIT or static) compilers and then managed languages will be as efficient.” Yes, I fully expect C# and Java compilers to keep improving – both JIT and NGEN-like static compilers. But no, they won’t erase the efficiency difference with native code, for two reasons.

Ganzer Text
http://herbsutter.com/2012/04/02/rea...-managed-code/

Zitat von Olli73:

Also zweites frage ich mich, wie die Zukunft von .net aussieht.

Nun, zumindest kommt kein nativer Ersatz:

Zitat:

The main reason for this is that there are many open questions about what is the future of traditional desktop app development in C++. Certainly, we intend to continue supporting existing code, but there are questions about the future.

Ist aus den Kommentaren hierzu
http://channel9.msdn.com/Shows/C9-Go...ingNative-2013

[Olli73]

Zitat von Robotiker:

Ich denke das ist etwas offtoppic, vielleicht sollte man die Frage abtrennen.

Da hast du natürlich Recht.

Trotzdem Danke für die Links.

[Phoenix]

Zitat von Olli73:

Dazu hätte ich auch mal eine Frage, denn ich habe mich bisher nur oberflächlich damit beschäftigt.

Genau das, was du schreibst, habe ich mir auch immer gedacht; nämlich, dass die .net-Programme nach dem ersten Starten (= "Kompilieren für Zielplattform" ?) ja wegen der Optimierungen für die konkrete Zielplattform schneller sein müssten. Man liest aber immer, dass .net i.d.R. langsamer ist. Woran liegt das nun? Ist es nur die garbage collection? Ist das OS/Framework einfach (noch) nicht gut genug dafür optimiert? Oder stimmen die Aussagen nicht, die man überall so liest?

Das wird jetzt tatsächlich etwas Offtopic, daher hier nur soviel dazu:

Die meisten Aussagen die man überall so liest sind in aller Regel stark in die eine oder die andere Richtung gefärbt.
Sagen wir es mal so: Wenn .NET wirklich in der Regel langsamer wäre, würden wir bei Smarthouse nicht um die 200.000 Wertstellungen pro Sekunde von einer Börse auf einem einzelnen CPU-Kern damit verarbeiten können. Das funktioniert aber. Zugegeben, wir mussten auch dort optimieren und ein gutes Know-How über das haben, was das Framework macht. Aber: Assembler-Optimierung in Delphi braucht ein ebenso tiefes Know-How über das was genau auf der CPU abläuft.

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate (der Begriff nativ wurde hier in letzter Zeit deutlich überstreckt) müssen nicht zwangsläufig schneller sein. Es gibt Anwendungsfälle, bei denen managed Code massive Vorteile ausspielen kann, und genauso gibt es Anwendungsfälle wo sich diese ins Gegenteil verkehren und die Software tatsächlich ausbremsen könnten.

Wichtig ist aber vor allem auch ein weiterer Aspekt: Wann kommt es bei einer normalen Line of Business Anwendung denn tatsächlich auf das letzte Quäntchen Performance an, das man aus einem System theoretisch rausquetschen könnte? Unser Marktdatensystem ist da eher eine Ausnahme.

Eine normale Desktop-Anwendung - und das ist das, was mit Delphi üblicherweise erstellt wird - verbringt über 90% seiner Zeit damit, auf User-Eingaben oder auf Antworten von Drittsystemen, meist der Datenbank, zu warten. Wenn eine Eingabe erfolgt, oder Daten zurück kommen, dann muss die Anwendung mal kurz etwas hektik betreiben und versuchen möglichst schnell darauf zu reagieren, aber das beschränkt sich in der Regel auf die Anzeige von Daten oder kurzen Berechnungen. Hier wird man als Anwender keinen Unterschied zwischen managed oder unmanaged Code bemerken können.

Der eigentliche Unterschied zwischen den Systemen liegt hier darin, wie effizient eine solche Anwendung mit den jeweiligen Tools erstellt werden kann und um wieviel Code sich der Entwickler tatsächlich kümmern muss. Die Performance der Entwicklung ist hier aussagekräftig. Und die ist für normale Desktop-Anwendungen nunmal auch in aller Regel dort, wo der Entwickler sein tiefstes Know-How hat.

Selbst wenn der Entwickler jetzt aber ein kompletter Delphi-Crack ist, wird er eine Webanwendung für eine Server-Farm damit nur mäßig schnell umsetzen können. Hier sind andere Technologien gefragt. Und hier spielen dann auch managed Umgebungen einen großen Vorteil aus: Sie skalieren in aller Regel deutlich besser. Wenn man in .NET mit der TPL (Task Parallel Library) arbeitet bzw. mit dem Äquivalent für Java, dann weiss ein managed Framework einfach deutlich mehr über die Plattform auf der es läuft und kann die Nutzung der Systemressourcen (CPU-Kerne und Speicher) deutlichst effizienter steuern als man es mit unmanaged Code jemals könnte (ohne krasse Massen an Infrastruktur-Code, der eigentlich ein eigener Task- und Memory-Manager wäre, womit man seinen Code auch managed machen würde).

Es ist grundsätzlich also immer eine Frage von zwei Dingen:
1.) Ist es überhaupt das richtige Werkzeug für die Aufgabe?
2.) Kenne ich mich mit dem Werkzeug auch gut genug aus um es korrekt zu bedienen oder gibt es Alternativen, bei denen ich mit einem gewissen Einarbeitungsaufwand am Ende effizienter bin und/oder ein besseres Produkt erzeugen kann?

[Robotiker]

Zitat von Phoenix:

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate

Ich denke bei Herb Sutters Aussagen ging es nicht um Geschwindigkeit, sondern um Effizienz.Ein Grund dafür, dass die Windows 8 Runtime in C++ und COM hochgezogen wurde, dürfte Energieeffizienz gewesen sein.

Auf jeden Fall, um die Kurve zum Thema zurückzukriegen, liest man seine Artikel auch bei Emba. So schrieb David I letzten Monat

Zitat:

While I was in Seattle in April presenting our Delphi for iOS release, I also was able to visit with Herb at the Microsoft campus - that was a real honor!

Vielleicht hilfts ja dem FireMonkey.

Mit seinem Native-GUI Ansatz steht Delphi jedenfalls heute eher in Konkurrenz zu Qt, als zu anderen C++ Entwicklungsumgebungen an sich. MS entwickelt VC++, abseits der Spieleprogrammierung, eher zu einer Systemsprache für die Entwicklung leistungsfähiger Komponenten für andere Sprachen. (In gewisser Weise löst das auch das angesprochene Dotfuscator Problem.) Gleicher Trend bei IBM, wo es neuerdings wieder C++ unterhalb von Java gibt.

Pascal muss da keine schlechter Ansatz sein, es gibt ja auch noch andere native Ansätze, wie D, Go und Rust. C++ ist nicht per se schneller als diese, sondern weil viele Leute an schnellen C++ Compilern und Bibliotheken arbeiten. Der C++ Builder z.B. ist leider nicht schneller als Delphi, andere Compiler schon.

[D-User]

Zitat von 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. ^^

...
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.

DB-Zugriff ist doch weitestgehend mit Komponenten regelbar, soweit man das nicht selber mit Hand machen will;

Zitat von Phoenix:

5. ..Entwickler verbringt..Großteil Seiner Zeit damit, Bugs im Code für Logging und im Datenbankzugriff (nur um mal zwei zu nennen) zu suchen und zu fixe.

s.o.

Zitat von Phoenix:

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.

hmmmmmm, hört sich interessant an:
Dann kann man jetzt die dummen Uni-Abteilungen, die sich mit Algorithmen, theoretischer Informatik etc befassen alle schliessen?
Und das "alles fertige" nur noch in Komponenten packen, so dass dann jeder Laie diese nur noch zusammenstöpseln braucht?

Zitat von Phoenix:

Das, was in Delphi run-time Packages sind, ist das .NET Framework.

interessant, sind Delphi run-time Packages gemanaged?
Wäre mir jetzt neu



seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben?

[Daniel]

Zitat von D-User:

Seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben?

Sebastian ist nicht mehr bei RO. Das hat er nun schon mehrfach geschrieben.

[Furtbichler]

Zitat von Daniel:

Zitat von D-User:

Seid ihr bei Remobjects jetzt so sauer auf Emba, weil die euch nen Entwickler geklaut haben?

Sebastian ist nicht mehr bei RO. Das hat er nun schon mehrfach geschrieben.

Wenn ich Dir dein Auto klaue und dann weiterverkaufe, ist es nicht mehr geklaut?

[mkinzler]

Aber da Sebastian schon länger nicht mehr bei RO ist, kann man ihm dass nicht unterstellen.