C# vs Delphi.net - Vor- und Nachteile

[Pr0g]

Hallo,

ich habe mich noch nicht so viel mit .Net beschäftigt und es erstmal auch nicht vor, doch trotzem kam mir die Frage welche Vorteile C# gegenüber Delphi.Net bietet. Denn ich würde nun denken, dass ein Delphiprogrammierer eher die Delphi.Net Variante wählt anstelle von C#, was er neu lernen müsste. Da dies ja aber wohl nicht immer der Fall zu sein scheint und Borland C# auch in die Delphi IDE eingebunden hat muss C# doch gewisse Vorteile bieten...

Hatte es mal mit der Suche probiert, aber nichts passendes gefunden (obwohl ich mir kaum vorstellen kann, dass ich der einzige mit einer solchen Frage bin).

MfG Pr0g

[Interceptor]

Naja, C# ist sozusagen die Muttersprache des .NET Framework und bietet, soweit ich richtig informiert bin, gewisse Sprachfeatures, die entsprechende Derivate like VB.NET oder Delphi.NET nicht haben.

[faux]

C# wird zu 99% immer im Aktuellen .NET Framework zur Verfügung stehen, Delphi.NET jedoch nicht (gibts ja nichtmal .NET 2.0 im BDS 2006).
btw: Ich glaube du wirst ohnehin einiges neu lernen müssen, wenn du von Delphi Win32 auf Delphi.NET umsteigen willst. Da gibt es einige Unterschiede denke ich (zumindest sieht man oft im Forum, dass manche ihre Probleme damit haben). Aber ich kenne Delphi.NET nicht.

Grüße
Faux

[hanspeter]

Wenn Du dich in Net einarbeitest, wirst Du sehr viele Parallelen zu Delphi VCL finden. Teilweise bis zur Namensgleichheit.
Ist auch kein Wunder. Der geistige Vater von Delphi, ist gleichzeitig der geistige Vater von .Net.
Net ist sozusagen die Weiterentwicklung von Delphi mit mehr Manpower.

Gruß Peter

[Bernhard Geyer]

Wenn Du für .NET-Entwickeln willst solltest Du auf jedenfall etwas mehr als Grundkenntnisse in .NET haben egal ob du letztendlich mit VB.NET oder Delphi.NET entwickelst, da C# die "Hauptsprache" von .NET ist und somit praktische fast alle Beispiele/Komponenten/OpenSource-Projekte mit C#-Entwickelt sind.

[Pr0g]

Das man .Net selber noch lernen muss ist mir klar. Delphi.Net und C# unterscheiden sich nur von der Syntax oder nicht?

Also wäre ein Nachteil von Delphi.Net, dass es nicht immer ganz aktuell ist. Dann sollte der C# Teil der IDE dies aber doch auch nicht sein, denn was den Compiler (oder wie das Teil in dem Fall nochmal hieß) angeht benutzen doch beide den selben des Frameworks (was ich mal gelesen habe).

[faux]

Zitat:

Zitat von Pr0g

Also wäre ein Nachteil von Delphi.Net, dass es nicht immer ganz aktuell ist. Dann sollte der C# Teil der IDE dies aber doch auch nicht sein, denn was den Compiler (oder wie das Teil in dem Fall nochmal hieß) angeht benutzen doch beide den selben des Frameworks (was ich mal gelesen habe).

Wenn du C# aus dem BDS benutzt, musst du dich auch mit .NET 1.1 zufriedenstellen. Du kannst dir aber die VS C# Express Edition laden und dann .NET 2.0 benutzen, bis es von Borland unterstützt wird.
Delphi.NET hat jedoch nicht nur das .NET Framework als Libary zur Verfügung, sondern auch die Borland VCL, was C# natürlich nicht hat.

Grüße
Faux

[Pr0g]

Mit VCL.Net will ich garnet erst anfangen. Wenn dann schon komplett .Net. Muss man bei der VCL.Net nicht alles in zich Extradlls mitliefern...

[mquadrat]

Wenn du keine der Borland-Klassen nutzen willst, sondern dich auf das .NET SDK beschränkst würd ich C# unter Visual Studio nehmen. Wennn du bei Borland bleiben willst, dann würd ich auch bei Delphi als Sprache bleiben.

Wie setzen Delphi.NET ein, weil wir keine Zeit haben unsere Entwickler auf C# umzuschulen ;)

[Khabarakh]

Zuerst einmal gibt es einen großen Unterschied zwischen allen Pascal-Dialekten (Chrome, Delphi.Net) und C# (, C(++(/CLI)), Java, ...): die Lesbarkeit. Bei C# kannst du so kompakt wie nur möglich schreiben, der Schreibaufwand reduziert sich auf ein Minimum. Bei Pascal hast du Einiges mehr zu schreiben, aber natürlich einen perfekten Überblick. Wobei dieser Punkt noch von der IDE ausgeglichen werden kann: Mit einem Classbrowser wird jeder C#-Code ein Stück übersichtlicher, mit Refactoring-Tools reduziert sich der Schreibaufwand bei Pascal.
Dass Delphi.Net etwas hinterher ist, wurde ja schon angesprochen. Es ist leider so, dass .Net erst mit 2.0 wirklich Win32 überlegen ist (bevor jemand aufschreit: wenigstens im Programmierkomfort (OOP, ...). Das müsst ihr zugeben.
Dann muss dir noch klar sein, dass Delphi.Net (im Gegensatz zu Chrome) noch ziemlich am "alten System" hängt. Win32-Projekte lassen sich fast direkt übernehmen, aber bei neuen Projekten wird man doch sehr an die alten Zeiten erinnert (dynamsiche Arrays in .Net :gruebel: ?). Dazu gehören auch solche kleine Unfeinheiten wie der Namespace-Support. Chrome dagegen legt nicht sehr viel Wert auf Kompatibilität, sondern erweitert die Sprache noch um viele Features (klick).
Ich möchte mich nicht darauf festlegen, aber so wie ich es hier erlebt habe, kann Delphi.Net mit Assemblies nichts anfangen :gruebel: :stupid: . Stattdessen wird immer noch ein Package benötigt.

So, Robert kann dir sicher noch Einiges mehr erzählen ;) .

[edit]

Zitat:

Zitat von Interceptor

Naja, C# ist sozusagen die Muttersprache des .NET Framework und bietet, soweit ich richtig informiert bin, gewisse Sprachfeatures, die entsprechende Derivate like VB.NET oder Delphi.NET nicht haben.

Wenn du damit andeuten willst, dass C# so etwas wie einen Heimvorteil hätte, stimmt das nicht wirklich. Die CLR steht jedem Compiler offen, wie viel er davon nutzt, ist seine Entscheidung (nur die CLI muss vollkommen implementiert sein). Wenn du alle Features nutzen willst, musst du direkt MSIL schreiben ;) .

[Heffalump]

Zitat:

Zitat von Pr0g

Hallo,

ich habe mich noch nicht so viel mit .Net beschäftigt und es erstmal auch nicht vor...

.Net ist die Zukunft, was mindestens die Programmierung für Windows bedeutet. Du kannst den Zug verpassen oder aufspringen. Ich habe für mich beschlossen aufzuspringen und programmiert wird C#. Mir gefällt zwar die Übersichtlichkeit nicht so gut wie die von Pascal, aber wie hier bereits erwähnt, gibt es sehr viele Beispiele zu .Net und diese sind in C# geschrieben.

Hat sich zudem mal jemand das kompilierte Ergebnis in der Delphi IDE angesehen (siehe Beispiel)? Ich frage mich, was die Pascal Delphi Version aus den Namensräumen macht und was da noch so auftaucht ohne das man es wollte (Da steht was von VCL, obwohl es ein WinForm Projekt ist). Zudem habe ich den ein oder anderen Fehler gefunden, der sich so in anderen IDEs nicht nachvollziehen läßt. Zum Beispiel funktionieren diese Schaltflächen nicht, im Gegensatz zu SharpDevelop 1.1, 2.0 und Visual Sharp Express.

[Pr0g]

Zitat:

Zitat von Heffalump

.Net ist die Zukunft, was mindestens die Programmierung für Windows bedeutet. Du kannst den Zug verpassen oder aufspringen.

Ich halte es noch für zu früh und werde weiterhin Win32 nutzen. Nach dem Release von Vista und einiger dann vergangener Zeit evtl. .Net, so zumindest die aktuelle Planung. Aber das soll nicht Thema dieser Diskussion werden ;)

[Phoenix]

Also das mit dem .NET 2.0 hat sich dank Daniel's experimentierfreudigkeit ja schon gelegt: Auch der Delphi-Compiler aus dem BDS 2006 kann gegen .NET 2.0 kompilieren.

Und .NET ist .NET - egal welche Sprache Du verwendest. Wenn ich mal kurz einen Prototypen ausprobieren will tippe ich den in C# runter, meine Projekte sind aber immer imho besser lesbarer Delphi.NET - Code. Hat bei mir Gründe der Wartbarkeit und der Übersichtlichkeit. Wenn C# auch Forward-Deklarationen hätte *träum*....

Vor- und Nachteile? Nunja, Delphi hinkt etwas hinterher. Auch wenn man mit Tricks schon mit .NET 2.0 arbeiten kann so ist das doch ein gefrickel.

Bei der Umstellung von Delphi/VCL -> .NET hast Du schon einen batzen vor Dir. Wenn Du Dir gleichzeitig noch die Umgewöhnung von Delphi Language -> C# antun willst ist das schon ein ganz grosser Brocken. Dann solltest Du aber noch die Umstellung von Delphi/BDS -> Visual Studio mitnehmen, und die ist zum einen für einen Delphianer arg Gewöhnungsbedürftig. Weil mit C# auf dem BDS zu bleiben... dann kannst Du genausogut Delphi.NET nehmen, weil C# im BDS bietet Dir keine Vorteile sondern eher nur das Hinterherhinken als Nachteil gegenüber dem VS.

[hanspeter]

Zitat:

Zitat von Pr0g

Ich halte es noch für zu früh und werde weiterhin Win32 nutzen. Nach dem Release von Vista und einiger dann vergangener Zeit evtl. .Net, so zumindest die aktuelle Planung. Aber das soll nicht Thema dieser Diskussion werden ;)

BDS und C#, sollte man sich nicht unbedingt antun. Da gibt es zu wenig Vorteile.
Ich wünsche mir heute noch ein System, welches plattformübergreifend compilieren könnte.
Und was Win32 angeht.
Solange MS seine eigenen großen Systeme, sprich Word,Excel,Access,SQL Server nicht auf Net umstellt, mach ich mir
um ein Sterben der Win32 API keine Gedanken. Die wird bestenfalls von einer Win64 API (teilweise) ersetzt.

Laufzeitverhalten ist da schon eher ein Kriterium und da dürfte ein Win32 Programm noch lange die Nase vorn haben.

Viel wichtiger ist eigentlich die Frage, wie es mit Delphi überhaupt weitergeht.
Borland hat mit seiner Verkaufsankündigung viele so verunsichert, das ich nur noch angelächelt werde, wenn ich bei einem angehenden Auftrag Delphi sage.
Gibt es da eigentlich schon was Neues, damit die diesbezügliche Lähmung aufhört?

Gruß
Peter

[Elvis]

Zitat:

Zitat von Phoenix

Also das mit dem .NET 2.0 hat sich dank Daniel's experimentierfreudigkeit ja schon gelegt: Auch der Delphi-Compiler aus dem BDS 2006 kann gegen .NET 2.0 kompilieren.

Wenn man jetzt noch dagegenrechnet, dass man in fast jeder Klasse in 2.0 gegen generische Interfaces/Klassen programmiert kann man dn "Trick" als Spielerei abtun...

Zitat:

Hat bei mir Gründe der Wartbarkeit und der Übersichtlichkeit. Wenn C# auch Forward-Deklarationen hätte *träum*....

Um es in tommies art zu schreiben:
[ ] Du weißt was Forward declarations sind

Was du meinst ist eine Trennung von Interface & Implementierungs section.
FDs würd ich meinem schlimmsten Feind nicht zumuten wollen.
Das Hineinquetschen von mehreren voneinander abhängigen Typen in ein Code file halte ich für alles andere als wartbar oder lesbar.
Wenn du interface sections und/oder Pascal magst, kann ich nur Chrome empfehlen. D32 mag absolut KickAss für natives Entwickeln sein :) , D.Net ist aber nur ein zusammengeriemeltes "Ding", das so hässlichen Code generiert, dass man den keinem non-Delphi .Net-Entwickler vorhalten könnte.

In D.Net gibt es immer noch Units, du kannst selbst keine Namespaces benutzen. Jeder D.Net-Konsument deiner Assemblies muss wieder deine Units verwenden.

Du hast keine Sichtbarkeitsmodifizierer für Typen, außer es sind nested types.

Da der Compiler sich nur wie ein frisierter D32 compler verhält wird er sowas hier ohne zu murren kompilieren:

Delphi-Quellcode:

unit NS.A;

interface
type Class1 = class
end;

unit NS.B;

interface
type Class1 = class
end;

Natürlich hast du jetzt Class1 zweimal im namespace NS[1], wodurch die generierte Assembly nicht benutzbar ist...

Wer Pascal mag und Neuentwicklungen in .Net anfängt sollte sich IMHO erstmal Chrome ansehen, bevor er seine Zeit mit D.Net verschwendet um danach zu C# zu flüchten.
Es kann eigentlich alles was C# kann bis auf anonyme Methoden[2], aber halt pascalisch. ;)


[1]Wer hier nicht hinterkam braucht sich nicht schämen, die Art wie D.Net Namespaces anlegt/benutzt ist kompliziert genug um ein ganzes Kapitel zu füllen.

[2]Bis jetzt gab es nicht einen Vorschlag wie die in Chrome aussehen könnten, der nicht absolut hässlich war. ;)

[jbg]

Zitat:

Zitat von Pr0g

Mit VCL.Net will ich garnet erst anfangen. Wenn dann schon komplett .Net. Muss man bei der VCL.Net nicht alles in zich Extradlls mitliefern...

Und was ist für dich dann "komplett .NET" ? Wenn du damit meinst, dass man keine Assemblies (aka DLL) braucht, dann gibt es kein "komplett .NET", denn auch ohne VCL.NET braucht man Assemblies. Und mit Delphi.NET kann man die Borland.*.dll Assemblies auch statisch in das Executable linken, womit diese auch nicht mehr ausgeliefert werden müssen.
Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, wobei man die nicht direkt sieht, weil Microsoft den Quellcode dazu nicht (wie Borland) mit ausliefert.

[Bernhard Geyer]

Zitat:

Zitat von jbg

Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, ...

Das stimmt. Aber MS kann seinen Assemblies aus dem .NET-Framework einen "Full-Trust"-Stempel geben um die Performanceverluste von P/Invoke aufgrund von Sicherheitsüberprüfungen zu minimieren. Das kann Borland natürlich nicht.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von jbg

Und wenn du nun mit dem P/Invoke "Problem der VCL.NET" ankommst, dann muss ich dir leider sagen, dass WinForms ebenfalls nur aus P/Invokes besteht, ...

Das stimmt. Aber MS kann seinen Assemblies aus dem .NET-Framework einen "Full-Trust"-Stempel geben um die Performanceverluste von P/Invoke aufgrund von Sicherheitsüberprüfungen zu minimieren. Das kann Borland natürlich nicht.

Richtig. Ich kann einen smart client mit SWF schreiben. Der wird direkt über's Internet gestartet und da er keine lokalen Berechtigungen braucht, wird er direkt starten ohne den User irgendwas zu fragen und ihn somit verunsichern. Eine VCL.Net App wird schlichtweg mit einer SecurityEx wegsterben bevor auch nur ein einiziger Pixel erscheint (RuntimeSecurityException kann man nicht abfangen ;) ).

Außerdem hat MS die .Net BCL/FCL nicht obfuscated, dadurch kann man mit dem Reflector wunderbar darin umhersurfen. :)
SWF ist im worst case archlahm, das ist richtig. Aber wenn CAS, DataBinding oder Kompatibilität zu den StiNo interfaces in .Net notwendig/erwünscht ist, ist VCL.Net schlichtweg keine Option.

[Pr0g]

Ich meinte es so, dass ich unter C# ja bspw. auch keine VCL habe, bzw. sie nicht dazugehört. Warum also die VCL Controls nutzen, wenn ich auch die aus .NET nutzen kann, welche nicht extra dazugeliefert werden müssen. Ob nun als DLL, oder reinkompiliert, die Datenmenge wird unnötig größer...

Habe mir nun mal Visual C# 2005 Express installiert und versuche nun ein Programm unter Linux/Mono zum laufen zu bekommen :mrgreen:

[Phoenix]

Zitat:

Zitat von Pr0g

Habe mir nun mal Visual C# 2005 Express installiert und versuche nun ein Programm unter Linux/Mono zum laufen zu bekommen :mrgreen:

Holla. Mono ist im Bereich .NET 1.1 zwar schon recht gut, aber .NET 2.0 ist da bei weitem noch nicht vollständig. Und VS C# Express ist halt .NET 2.0. Da wirst Du einiges zu knabbern haben.

[Elvis]

Zitat:

Zitat von Pr0g

Habe mir nun mal Visual C# 2005 Express installiert und versuche nun ein Programm unter Linux/Mono zum laufen zu bekommen :mrgreen:

Dafür wäre als kostenlose IDE die Kombi C#1.1 und #develop1 aka Fidalgo besser. Mono hat recht guten Support für .Net 1.1. #D wird dich auch direkt gegen Mono kompilieren lassen, wodurch du nicht erst das ganze aufwendig testen musst.
Bei 2.0 wirst du in Probleme rennen. Benutzt du den Formdesigner von 2.0 wirst du sofort in Probleme rennen. ;)
Aber um mal ganz ehrlich zu sein: Wieviel Sinn macht es sich gleich noch mit Mono zu befassen wenn man gerade erst dabei ist sich mit der Sprache bekannt zu machen?

[Pr0g]

Das Mono noch nicht vollständig .NET 2.0 unterstützt weiß ich, aber dachte das zumindest ne leere Form geht.

Es war nur nen kleiner Test, momentan befasse ich mich weder mit .NET, noch mit Mono richtig, da derzeit andere Projekte im Vordergrund stehen.