Vor und Nachteile von Delphi 8 for .net vs c#, vb.net

[tommie-lie]

Zitat:

Zitat von Robert_G

Ich habe es anfangs auch verteidigt, aber mitlerweile musste auch ich einsehen, dass uns Borland einfach die Alpha zu D9 teuer verkauft hat. (Für eine Beta version ist es zu instabil & lahm :evil: )

Ähhh, darf ich anmerken, daß das beim CSB und damals bei der 2002 vom VS auch so war, und IMHO auch beim CBX...?!?
Das ist heute gängige Praxis, weil man so wenigstens noch ein wenig Geld für kriegt. Deswegen bin ich auch froh, daß ich die kostenlose Personal vom CSB zum Einarbeiten habe, wenn D9 stabil und zuverlässig ist, werde ich mir frühestens das kaufen, wenn ich für .NET nicht vollständig zum VS.NET wechsele (mal abwarten, was der CSB 2.0 so mit sich bringt...).

Zitat:

Zitat von Robert_G

Da ich jetzt noch kein VS.Net kaufen möchte, muss ich wohl weiterhin mit der mischung aus #develop (Programmieren) und D8 (GUI/ASP -zusammenklicken) auskommen. :cry:

Dafür sind die Assemblies ja da ;-)
Aber warum benutzt du für die Oberfläche ausgerechnet Delphi? Auf der einen Seite willst du keine Krüppellösungen, auf der anderen Seite benutzt du Delphi8 für .NET-GUIs :roll:

Zitat:

Zitat von Robert_G

Assemblies in D8 zu schreiben ist kompletter Schwachfug!
Eine Version der dll, die mit D8 funktioniert, wird mit KEINER anderen .Net Sprache laufen, und andersherum (läuft sie mit z.B. C# wird sie NICHT mit D8 laufen). :-( (RTTI)

Hmm, bei Andreas Kosch geht's irgendwie...
Bist du sicher, daß du statische Assemblies nicht mehrfach eingebunden hast (Assembly A lädt Borland.Delphi, Assembly B lädt auch Borland.Delphi und jetzt will Assembly C die beiden Assemblies A und B benutzen, das haut aus irgendwelchen Gründen nicht hin...)
Jedenfalls ist es Möglich, mit D8 Assemblies zu schreiben, die man mit C#, J#, VB.NET oder MC++ benutzen kann und vice versa.


Ich muss sagen, daß mich seit gestern die .NET-Idee doch etwas in ihren Bann gezogen hat, auch wenn ich gegen die entstehende Inkompatibilität bin. Praktikabel wird's erst, wenn wirklich alle irgendwo benutzten (x86-Win-)Rechner ein .NET-Framework haben, denn nur dann bin ich so flexibel wie bei gewöhnlichen Win32-Anwendungen. Aber prinzipiell ist die Idee gelungen, und besonders C# hat's mir angetan (doch nur wegen der schicken IDE? :mrgreen:)
In Delphi8 konnte ich noch keinen großen Blick werfen, Peter Lustig ist ganz fasziniert davon, die IDE soll jedoch imt den C#-IDEs von Microsoft und Borland vollkommen identisch sein. Da ich eh nicht die VCL.NET benutzen würde (außer uzr Portierung alter Projekte, wenn's sich nicht vermeiden lässt), sehe ich daher zwischen Delphi.NET und C# keinen großen Unterschied, ich würde meine Entscheidung also letzten Endes allein an der IDE festmachen (Preis, Funktionalität, Entwicklungskomfort), und das kann nur jeder für sich selber ausprobieren, wenn wirklich endgültige und stabile IDEs vorhanden sind (und das wird wohl noch ein Jahr dauern, wenn MS nicht die volle Energie ins Studio steckt und Longhorn ein wenig vernachlässigt, D9 wird jedenfalls nicht vor 2005 rauskommen, denke ich (ja, ich kenne die Ankündigung für Ende 2004, deswegen bin ich mir ja so sicher, daß es im Frühjahr 2005 erst so weit sein wird...)).

[Hansa]

Das ist ja alles schön und gut. Nur, das wichtigste Pro für Delphi fehlt. Bzw. einige wichtige:

• Lesbarkeit des Source-Codes beste von allen.
  
  Delphi-Quellcode:

  for i := 1 to 10 do begin

  Das versteht jeder Anfänger.

• Lokalisierung von Programmierfehlern. Wegen der logischen Syntax entstehen IMHO von Anfang an weniger. Falls doch : der Debugger ist auch nicht ohne.

Daß Delphi nicht von Microsoft kommt, ist eher ein Pro statt ein Kontra. Wie heißt es so schön ? "Schuster bleib bei deinen Leisten" Insofern soll M$ besser bei seinem Windows oder Office bleiben. Für Programmiersprachen waren die noch nie sonderlich gut. Der Markt ist für die eh uninteressant. Programmiersprachen ist da nur eine Unter-Unter-Unter Abteilung. :mrgreen:

Und zu guter letzt : müßte ich ein Programm kaufen und hätte die Auswahl zwischen Delphi-codiertem oder C&co, so würde die verwendete Programmiersprache bei in etwa vergleichbarem Leistungsumfang den Ausschlag geben. Mit einem C-Programm hätte ich immer ein ungutes Gefühl. 8)

[sharkx]

Ich bin von Delphi auf c# umgestiegen. am Anfang habe ich einen stink normalen Editor genutzt und den im .Net Framework befindlichen Compiler. Mittlerweile habe ich mir das VS Studio geleistet und ich möchte diesen Editor nicht mehr missen. Es gibt tausende von Funktionen innerhalb des Editors die bei Delphi einfach komplett fehlen.

Der Editor ist zudem in koorparation mit dem Delphi Entwickler endstanden ;p

Zitat:

Daß Delphi nicht von Microsoft kommt, ist eher ein Pro statt ein Kontra. Wie heißt es so schön ? "Schuster bleib bei deinen Leisten" Insofern soll M$ besser bei seinem Windows oder Office bleiben. Für Programmiersprachen waren die noch nie sonderlich gut.

MS hat noch nie was anständiges geschrieben, is klar .. meckern aber selbst MS Produkte kaufen und nutzen.


IMHO denke ich wird das .NET Framework auf jedenfall Zukunft haben, somit auch seine neuen und verbesserten programmiersprachen.

[tommie-lie]

Zitat:

Zitat von Hansa

Lesbarkeit des Source-Codes beste von allen.
Source:

Delphi-Quellcode:

for i := 1 to 10 do begin

Das versteht jeder Anfänger.

Das ist kein Argument :roll:
Parles-tu Francais?
Or d'you prefer English?
Für mich persönlich ist

Code:

for (i = 1; i<=10; i++)

genauso logisch wie die entsprechende Delphi-Syntax, mit dem Plus, daß eine C-For-Schleife flexibler ist als eine Delphi-For-Schleife (in C kann man mit einer For-Schleife alles machen, andere Schleifenarten braucht man im Prinzip nicht).
Das ist alles eine subjektive Sache und zählt nicht als Argument, in Firmen zählt meist die Leistungsfähigkeit udn Produktivität mehr. Sicherlich spielt da auch die Sprachsyntax eine gewisse Rolle, aber daß es auch C-Programmierer gibt, die die Sprache beherrschen, zeigen so gut wie alle aktuellen Betriebssysteme und Office-Suiten, um nur zwei große Bleistifte zu nennen.

Zitat:

Zitat von Hansa

Lokalisierung von Programmierfehlern. Wegen der logischen Syntax entstehen IMHO von Anfang an weniger. Falls doch : der Debugger ist auch nicht ohne.

Unter .NET kannst du für jede Sprache den Standard-.NET-Debugger benutzen. Wenn du dich in den einmal richtig eingearbeitet hast, kannst du damit von Delphi bis J# alles debuggen, was dir in die Finger kommt, und musst dich nichtmal umstellen.

Zitat:

Zitat von Hansa

Insofern soll M$ besser bei seinem Windows oder Office bleiben. Für Programmiersprachen waren die noch nie sonderlich gut. Der Markt ist für die eh uninteressant. Programmiersprachen ist da nur eine Unter-Unter-Unter Abteilung. :mrgreen:

Deswegen ist das MSVS auch so weit verbreitet und die MS-Compiler auch nicht die schlechtesten, oder hat das andere Gründe?

Zitat:

Zitat von Hansa

Und zu guter letzt : müßte ich ein Programm kaufen und hätte die Auswahl zwischen Delphi-codiertem oder C&co, so würde die verwendete Programmiersprache bei in etwa vergleichbarem Leistungsumfang den Ausschlag geben. Mit einem C-Programm hätte ich immer ein ungutes Gefühl.B-)

Gut, dann such dir mal ein in Pascal geschriebenes Betriebssystem und eine in Delphi geschriebene Office-Suite. Ach ja, die DP darfst du ja dann auch nciht mehr nutzen, der Chat benutzt JavaScript und ASP, und der Server ist Linux und somit auch in C geschrieben...
Eine solche Argumentation halte ich gelinde gesagt für totalen Schwachsinn. Es gibt genauso gute C-Programme wie schlechte Pascal-Programme, die Programmiersprache wäre für mich der letzte Anhaltspunkt für den Kauf eines Programmes...

Zitat:

Zitat von sharkx

IMHO denke ich wird das .NET Framework auf jedenfall Zukunft haben, somit auch seine neuen und verbesserten programmiersprachen.

Ich hoffe, daß es Zukunft haben wird, und das möglichst schnell. Denn sinnvoll ist das Programmieren für .NET nur, wenn wirklich jeder das Framework hat. Ist das erstmal der Fall, finde ich Programmierung in .NET wesentlichen komfortabler als zu Win32-Zeiten, vorrausgesetzt natürlich das Gewünschte ist im Framework überhaupt machbar (solange das Framework nicht die kompletten Möglichkeiten der Win32-API unterstützt, wird man immer mal wieder was für Win32 schreiben (müssen)).

Zitat:

Zitat von sharkx

am Anfang habe ich einen stink normalen Editor genutzt und den im .Net Framework befindlichen Compiler.

:mrgreen:

[Insider2004]

Ich habe D8 ausführlich getestet. Ich gewinne damit nichts.
Ganz im Gegenteil:

-IDE extrem langsam (Start dauert halbe Minute),
-compiling !extrem! langsam (D6: 3 Sek, D8: 120 Sek.)
-Programm kann sehr viel leichter disassembliert werden (die Mitbewerber freuen sich)

Der Knackpunkt schlechthin:
Viele Tools, die Standard sind (zlib, png, etc.)
können nicht mehr includiert werden.

Von daher bleibe ich bei D6 und werde auf D9/10 wechseln.

Mfg,
Insider

[Robert_G]

Zitat:

Zitat von Tommie Lie

Aber warum benutzt du für die Oberfläche ausgerechnet Delphi? Auf der einen Seite willst du keine Krüppellösungen, auf der anderen Seite benutzt du Delphi8 für .NET-GUIs

#develop hat zum Bleistift noch keinen Webforms designer. :zwinker:

Zitat:

Zitat von Tommie Lie

Jedenfalls ist es Möglich, mit D8 Assemblies zu schreiben, die man mit C#, J#, VB.NET oder MC++ benutzen kann und vice versa

Das habe ich nie in Frage gestellt. Es gibt aber nur 2 Möglichkeiten dafür:

• Ich verlinke die Borland.Delphi.System.dll in allen verwendeten Assemblies und kompiliere sie in die "Hauptassembly"
• Ich installiere das Ding mit in den GAC auf dem Zielsystem. Jetzt muss ich alle Assemblies nur verlinken.
  Aber dieses olle Ding muss dabei halt in den GAC. :wall:

Assemblies der ersten Lösung werden niemals mit D8 fuktionieren und mit der zweiten kann ich mich irgendwie nicht anfreunden.
C# ist einfach die Muttersprache des Frameworks, ich kann auch in #develop meine Assemblies & eine Testanwendung in ein Combine packen. (im after Build der Assemblies wandern diese in den GAC, danach wird die Testapp mit diesen GAC-Assemblies kompiliert)
Versuche das mal mit D8. :lol:
Zuerst sagt er dir es gibt keine [Assemblyname].dcuil. Während des ersten Build hat er sie dann erzeugt. Bei nächsten Kompilierversuch ist er plötzlich der Meinung, dass die Methode Dispose nicht zur Klasse system.Windows.Forms.Form gehört.
Erst ein Schließen des Projektes und erneutes Öffnen ermöglicht eine Kompilierung. (manchmal muss man die ganze IDE neustarten :evil: )
Der zweite Grund, warum die Arbeit mit D8 nie langweilig wird:

• Setze ein Control aus Assembly XYZ in die Toolpalette
• Enferne mal die Assembly per "C:\Program Files\Microsoft.NET\SDK\v1.1\Bin\gacutil.exe" /u XYZ aus dem GAC.
• Jetzt löschst du die eigentliche Datei XYZ.dll

:arrow: Du kannst ab jetzt den Dialog zum De-/Installieren von Komponenten nicht mehr öffnen (Er heult wegen der fehlenden Assembly :mrgreen: )
Die einzige Chance, die du jetzt noch hast um den Dialog wieder verwenden zu können ist, den Eintrag in "HKEY_CURRENT_USER\Software\Borland\BDS\2.0\ToolFo rm\Mapping" zu entfernen und beten, dass es keine weiteren Verweise in den 5 mio. XML-Dateien von D8 zu der verschollenen Assembly gibt.

BTW: Es kam genau 13-mal das Wort Assembly ( jetzt 14 ) vor, wer bietet mehr? :lol:

[Robert_G]

Zitat:

-IDE extrem langsam (Start dauert halbe Minute),
-compiling !extrem! langsam (D6: 3 Sek, D8: 120 Sek.)
-Programm kann sehr viel leichter disassembliert werden (die Mitbewerber freuen sich)

Der Knackpunkt schlechthin:

Eine halbe Minute? Dann hast du wohl keine zusätzlichen Packages installiert. :lol:
Der Compiler von C# ist um ein Vielfaches langsamer als der von D8!!! Für eine .Net IDE kompiliert D8 verdammt schnell ;) (wird wohl an den DCUILs liegen)
Das ILDisasm-Problem trifft ALLE .Net-Sprachen (vor allem wenn man so freundlich ist und die Debug infos mitgibt :lol: )

Zitat:

Viele Tools, die Standard sind (zlib, png, etc.)
können nicht mehr includiert werden.

Es ist ja auch totaler Käse Win32 libraries in einer .Net Assembly zu verwenden :lol:
Die .Net Gemeinde wächst rasent schnell. Was an solchen Funktionen nicht schon im .Net Redist enthalten ist, findest du bestimmt irgendwo (ich finde hier oft sehr nützliche Dinge ;) )

@Tommie lie
Deinem letzten Beitrag kann ich nur voll und ganz zustimmen.
Auch wenn C# oft wie eine Kindersprache aussieht, sie kann bei vernünftiger Formatierung mindestens genauso lesbar sein wie Delphi code.
Mittlerweile stören mich die sinnlosen Klammern auch nicht mehr soooo sehr (man kann damit nämlich sofort eine Funktion/Prozedur erkennen :arrow: Lesbarkeit )

Zitat:

der Debugger ist auch nicht ohne.

Genau! Er ist ohne jeglich Unterstützung für ASP.Net. :lol:
Ich verwende fast ausschließlich den CLR Debuger, da ich damit in einem Guss meinen C# UND D8 Code debuggen kann. ;)

[tommie-lie]

Zitat:

Zitat von Insider2004

Programm kann sehr viel leichter disassembliert werden (die Mitbewerber freuen sich)

Das lässt sich angeblich mit entsprechenden Tools verhindern, beim VS.NET gibt's den Dotfuscator dazu, der das kann (selbst ausprobiert habe ich's noch nicht).
Außerdem ist es gerade ein wichtiges Merkmal der ganzen .NET-Geschichte, daß die CLR den Code kennt und somit Malware rechtzeitig in ihren Rechten beschneidet.

Zitat:

Zitat von Insider2004

compiling !extrem! langsam (D6: 3 Sek, D8: 120 Sek.)

Ohh, das erstaunt mich bei den an sich für Geschwindigkeit berühmten DL-Compilern...
Da bin ich ja mit meinem "langsamen" C#-Compiler noch ganz gut bedient, den finde ich gar nicht sooo langsam... (GCC ist subjektiv irgendwie langsamer...) :mrgreen:
Aber ich denke, daß sich dieses Problem in der nächsten Compilergeneration wieder legen wird, die aktuelle DCCIL-Version ist ja nur der erste Versuch ;-)
Aber komisch ist's schon, wo doch der eigentliche Hochsprachencompiler weder optimieren muss (sollte (darf)), noch sonst großartig was von wegen Linking und sonstigem Kleinkram zu tun hat...

Zitat:

Zitat von Robert_G

#develop hat zum Bleistift noch keinen Webforms designer.

Der CSB hat einen ;-)

Zitat:

Zitat von Robert_G

Ich installiere das Ding mit in den GAC auf dem Zielsystem. Jetzt muss ich alle Assemblies nur verlinken.
Aber dieses olle Ding muss dabei halt in den GAC.

Das ist oft sogar sinnvoll, wenn die Assembly wirklich sinnvolle Dinge enthält und man gedenkt, in seinem Leben auch mal mehr als ein Programm zu schreiben :zwinker:
Enthält die Assembly weniger sinnvolle Dinge, die eigentlich noch nichtmal groß sind, kann man sie ja auch mit 'ner weniger auf Abwärtskompatibilität getrimmten Sprache schreiben *g*

Zitat:

Zitat von Robert_G

Auch wenn C# oft wie eine Kindersprache aussieht

:gruebel:
Du kennst aber VB und Delphi, oder?
C# sieht absolut nicht wie eine Kindersprache aus (IMO), dafür ist sie viel zu sehr an C angelehnt. Aber im Vergleich zu C++ ist C# schon stark vereinfacht, man merkt, das Hejlsberg da seine Finger drin hatte :mrgreen:

Zitat:

Zitat von Robert_G

Ich verwende fast ausschließlich den CLR Debuger, da ich damit in einem Guss meinen C# UND D8 Code debuggen kann. ;-)

Na, da haben wir doch mal einen lebenden Bleistift für meinen Hinweis auf den Framework-Debugger *g*

Deinem Beitrag zufolge kann ich nur froh sein, mit C# angefangen zu haben und werde mir dann wohl auch die Schmach ersparen, mich mit der D8 Trial rumzuschlagen, immerhin muss ich da dann schon in 30 Tagen fertig werden. Oder ist das vielleicht absicht, damit man nicht endgültig durchdreht? :mrgreen:

Zitat:

Zitat von Robert_G

Mittlerweile stören mich die sinnlosen Klammern auch nicht mehr soooo sehr

Wo gibt's denn in C sinnlose Klammern? :shock:
Ich finde die alle äußerst sinnvoll, sie zeugen von einer fest definierten Syntax, einfach zu parsen, einfach zu merken, keine Ausnahmeregeln, wenig Tipparbeit; eine Sprache wie für faule Programmierer geschaffen :mrgreen:

[Hansa]

Zitat:

...eine Sprache wie für faule Programmierer geschaffen :mrgreen:

Das ist schon ein Problem. Wie gesagt, ich würde eher ein Programm einem sorgfältigen und fleißigen Programmierer abkaufen, bevor ich mich auf die Flexibilität und den Einfallsreichtum eines Nanosekunden-Teilzeit-Programmierers einlassen würde. :mrgreen:

@Tommie-lie : Schwachsinn ist höchstens ein Betriebssystem mit einer Programmiersprache zu verwechseln. 8) Um ein Betriebssystem zu programmieren, dafür ist C erste Wahl. Früher war das Assembler. C liegt da nicht weit zurück. Aber ich würde niemals ein Anwendungsprogramm, wo NICHT-Programmierer jeden Tag damit zurecht kommen müssen in C schreiben. Alleine schon wegen der überzüchteten gerühmten Flexibilität, die einen eher zu Fehlern verleitet. :wall:

P.S.: Da fältt mir noch was ein: Weiß einer, wieso begin und end in C# {} sind ? Bzw. was dafür die Ursache ist ??

[r_kerber]

Zitat:

Zitat von Hansa

P.S.: Da fältt mir noch was ein: Weiß einer, wieso begin und end in C# {} sind ? Bzw. was dafür die Ursache ist ??

Vielleicht weil's in C, C++ und Java auch so ist?