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

**Hansa**

Nein, das hat Lochkarten-Gründe. Das weiß ich von einem echten Guru.

Wegen der langen Compilier-zeiten, die reduziert werden sollten, waren selbst die 3 Zeichen für END schon zuviel. ,./ usw. konnten logischerweise auch nicht benutzt werden. Tja und das verfolgt die C-Programmierer überall heute immer noch und verursacht ziemlich unlesbare Programme. Wirth hat da keine Rücksicht drauf genommen, da er eine Lernsprache machen wollte, die leicht zu verstehen ist.

Borland hat dann das ganze so optimiert/erweitert, daß es kommerziell verwertbar war. Die Syntax von C hat diese "Erblasten" nun an C++, Java usw. vererbt. Ist halt alles OOP.

Zitat von Hansa:

Schwachsinn ist höchstens ein Betriebssystem mit einer Programmiersprache zu verwechseln. Um ein Betriebssystem zu programmieren, dafür ist C erste Wahl.

Also stellst du an das darunterliegende Betriebssystem weniger kritische Ansprüche, was die Sprache angeht, als an die Programme, die auf einem Betriebssystem laufen, das in einer Sprache geschrieben wurde, die du als "unsicher", da zu verwirrend einschätzt?
Ich hoffe, du wirst nie Architekt...

BTW: Wie kann man denn ein Betriebssystem mit einer Programmiersprache verwechseln?!?

Zitat von Hansa:

Aber ich würde niemals ein Anwendungsprogramm, wo NICHT-Programmierer jeden Tag damit zurecht kommen müssen in C schreiben.

Was ist bei Anwendungsprogrammen denn der Unterschied zwischen Programmierern und Nicht-Programmierern? Wenn ich ein Programm bediene, und es funktioniert nicht richtig, weiß ich zwar, warum es nicht geht, aber damit kann ich nur dem Autor eine bessere Fehlerbeschreibung liefern. Ich würde nie versuchen, als Programmierer in Word oder Writer einen Fehler zu finden, bis ich mich nämlich in die paar tausend Zeilen Quellcode eingearbeitet habe, gibt's schon längst drei neue Versionen und ich hätte mir die Arbeit sparen können.
Auf der Anwenderseite gibt es in der Praxis keinen Unterschied zwischen Programmierer und Nicht-Programmierer, auch wenn Programmierer, die was auf sich halten, das gerne von sich behaupten, wenn sie gerade ihre oberflächliche OpenSource-Mentalität verteigigen...

Ich weiß echt nicht, wer dir den floh ins Ohr gesetzt hat, daß C unübersichtlich, schlecht lesbar und zu fehlerverleitend ist. Ich kann das auf jeden Fall nicht bestätigen, und jeder, der C kann (und zwar kann, und nicht nur mal drei Zeilen aus dem PSDK gelesen und nach Delphi portiert hat), kann das ebenfalls nicht.

Zitat von Hansa:

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

Umgekehrt wird ein Schuh draus. { und } sind in Pascal begin und end, weil Wirth damals dachte, daß seine Studenten eine Sprache schneller lernen, wenn die Sprache zum Menschen kommt, deswegen ist er von abstrakten, durch die Syntax implizierte Strukturierung weggegangen und ist in Richtung beschreibende Schlüsselwörter gegangen, deswegen haben wir heute begin, end, function, procedure und dergleichen.
Bei C stand es damals im Mittelpunkt, ähnlich flexibel zu sein wie in Assembler (jaa, damals hatte man noch Ahnung *g*), aber sich so viel unnötigen Schreibkram wie Möglich vom Hals zu schaffen. Entstanden ist ein Strukturmodell, daß sich hauptsächlich aus der C-Syntax impliziert. Ein "{ /*blah */ }" ist ein Block. Eingeleitet mit einem Zeichen, beendet mit einem Zeichen. Kein Schreibaufwand und für den Parser trotzdem eindeutig erkennbar.
Die "Ursache" für die aus Abkürzungen bestehende und dadurch überaus flexible Syntax besteht also tatsächlich in der Schreibfaulheit damaliger Informatik-Professoren, während die Ursache für die langatmige Pascal- und Basic-Syntax darin liegt, den Studenten möglichst einfach irgendwas beizubringen, was sie vorher noch nicht gesehen haben.

Ich wüsste nicht, wann C ernsthaft auf Lochkarten programmiert wurde...

**Hansa**

Zitat von tommie-lie:

Also stellst du an das darunterliegende Betriebssystem weniger kritische Ansprüche, was die Sprache angeht, als an die Programme, die auf einem Betriebssystem laufen, das in einer Sprache geschrieben wurde, die du als "unsicher", da zu verwirrend einschätzt?
Ich hoffe, du wirst nie Architekt...

Tommie, das Beispiel mit dem Architekt ist echt gut. Aber falls Du einer werden willst, so beschäftige Dich noch etwas mit den Grundlagen.

Denn ein Architekt würde niemals auf die Idee kommen, weil er für das Fundament eines Hauses Beton benutzt hat, auch die Fensterrahmen aus Beton zu machen, oder das Dach. Einige haben das trotzdem gemacht für Flachdächer. Das sind dann die Bauten aus den 70er/80er Jahren, die jetzt massenweise abgerissen werden.

Und die komplette Computersoftware ist in gewisser Weise ein Fertigbauhaus. Und dieses wird aus verschiedenen Elementen zusammengebaut. Es gibt Bodenelemente aus Beton, die macht man besser mit C (Windows etc.). Früher waren das Backsteine (Assembler).

Dann gibt es Wandelemente. An die sind die Anforderungen nicht so groß aber nur in einem gewissen Grenzbereich lassen sie einen Spielraum zu. Wird dieser fahrlässig überschritten, so wird das Haus einstürzen. Pascal bzw. Delphi ist da wesentlich robuster aber auch restriktiver, was die Stabilität und den Bauplan eines Programmes angeht.

Deshalb behaupte ich, daß die Hürde bei C erheblich höher liegt, ein sauberes Programm hinzukriegen. Sich in Word-Quellcode reinzudenken, das ist auch Blödsinn. Erhalte ich eine konkrete Fehlermeldung von meinem Programm, so muß ich als Programmierer diesen Fehler finden. Bei einem guten Quelltext und einer guten Sprachen-Syntax geht das einfach viel schneller und auch billiger. C & Co. liegt da weit dahinter, wohlgemerkt bei Anwendungsprogrammen

Zitat von Hansa:

Denn ein Architekt würde niemals auf die Idee kommen, weil er für das Fundament eines Hauses Beton benutzt hat, auch die Fensterrahmen aus Beton zu machen, oder das Dach. Einige haben das trotzdem gemacht für Flachdächer. Das sind dann die Bauten aus den 70er/80er Jahren, die jetzt massenweise abgerissen werden.

Beton, geil!
Du warst doch gegen C, weil du Programme, die damit geschrieben werden, für zu instabil hältst, weil die Programmierer in der angeblich unübersichtlichen Snytax sich selbst nicht mehr zurechtfinden.
Beton ist was ganz anderes. Beton ist eine graue Masse, ich schütt' sie in mein Fundament, wart' nen Tag und fertig. Beton ist keine Programmiersprache, denn keine Programmiersprache ist so eifnach zu bedienen und gleichzeitig so stabil wie Beton, die richtigen Mischverhältnisse kann man zur Not mit Messlöffel abmessen, das kann selbst mein Sohn, hätte ich einen.

Wenn ich mir deine Argumente so anschaue, wäre C Bimsstein, der schon zerbröselt, wenn ich ihn nur schief angucke. Und ich würde kein Fundament mit Bimsstein bauen, erst recht nicht wenn ich nachher 'nen Wolkenkratzer drauf bauen will.

Zitat von Hansa:

Deshalb behaupte ich, daß die Hürde bei C erheblich höher liegt, ein sauberes Programm hinzukriegen.

Da haben wir's wieder. Bei einem Fundament ist die Sauberkeit nicht so wichtig?

Zitat von Hansa:

Bei einem guten Quelltext und einer guten Sprachen-Syntax geht das einfach viel schneller und auch billiger. C & Co. liegt da weit dahinter, wohlgemerkt bei Anwendungsprogrammen

Und bei einem Fundament ist die Fehlersuche nicht viel komplizierter? Ich verstehe nicht, wieso C für dich schlecht ist, weil die Syntax unübersichtlich ist, du das aber für ein Betriebssystem vollkommen in Ordnung findest. Das lässt für mich die einzige Schlussfolgerung übrig, daß ein Betriebssystem ruhig unübersichtlich, schwierig u debuggen und auch buggy sein kann. Es gibt, was Anforderungen an Stbilität und Übersichtlichkeit angeht, keinerlei Unterschiede zwischen Quellcode für Anwendungen und Quellcode für ein Betriebssystem. Im Gegeneteil, ein Betriebssystem sollte sogar noch übersichtlicher und stabiler sein, als die Anwendungen, die drauf laufen sollen. Zum einen, damit das Fundament für alles andere stabil ist, und zum anderen, weil das Betriebssystem die Schnittstelle zum System ist, und wächst die Hardware drumrum, muss das Betriebssystem erweitert werden, und das geht nur dann schnell, wenn der Quellcode übersichtlich ist.
Und ganz nebenbei ist es auch nicht objektiv zu behaupten, C-Code wäre unübersichtlich und fehlerbeschwörend, dem ist nicht so, wenn man C kann. Das gleiche kann ich meiner Französisch-Lehrerin als Argument gegen die nächste Klausur sagen, sie wird entgegnen, daß wenn man die Sprache kann, alles genauso einfach ist wie im Deutschen.

In meinen Augen bruht deine ganze Argumentation allein auf dem Irrglauben, C sei unübersichtlich, vermutlich weil du C nicht kannst (das ist eine Unterstellung, ist lasse mich gerne vom Gegenteil überzeugen!).

Scheint ja doch noch ein schöner Popcorn-Thread zu werde, nur dumm daß ich mitten drin sitze und die Popcorntüte gelegentlich wieder weglegen muss...

**Hansa**

Schon witzig, in einem Delphi-Forum vom Moderator eines anderen Delphi-Forums die Vorzüge der C-Sprache erklärt zu bekommen, die entweder nicht vorhanden oder unwichtig sind.

Die angeblich schlechtere IDE spielt hierbei auch keinerlei Rolle. Ich kann auch mit nem Editor und der Kommandozeile programmieren und compilieren.

Es geht mir um die letztendliche Qualität des Programmes. Und die sehe ich bei C Programmen gegenüber Delphi eindeutig als niedriger an. Eben weil mehr Know How, bzw. ein komplizierterer Einstieg, sowie längere Zeit notwendig ist, ein Programm fertigzustellen zu testen usw.

Ein Fundament kann ruhig nicht sauber sein, da es sowieso in den Dreck kommt. Das kann man deshalb auch mit C machen

Zitat von Hansa:

Schon witzig, in einem Delphi-Forum vom Moderator eines anderen Delphi-Forums die Vorzüge der C-Sprache erklärt zu bekommen, die entweder nicht vorhanden oder unwichtig sind.

Deine unangebrachte Ironie kannst du dir sparen.
Als Programmierer sollte man sich nie nur auf eine Sprache beschränken, das hat weder etwas damit zu tun, daß ich Moderator im DF bin, noch damit daß ich hier nicht in meinem "Stammforum" bin, wenn man das überhaupt so bezeichnen kann.

Und ich sehe es genau andersrum, dein Argument, C-Code sei unübersichtlich und somit fehleranfällig ist nicht vorhanden (auch wenn du es ständig anführst). Wenn man eine Sprache kann, ist sie weder unübersichtlich noch kompliziert, man kann sie einfach.

Zitat von Hansa:

Die angeblich schlechtere IDE spielt hierbei auch keinerlei Rolle. Ich kann auch mit nem Editor und der Kommandozeile programmieren und compilieren.

Ja, das mache ich auch gelegentlich (naja, Editor nicht, ich steh' auf Syntaxhighlighting, aber Kommandozeilencompiler). Und will man in einer Firma programmieren, kommt es genau auf die IDE an, die ist mit das wichtigste, denn sie allein bestimmt die Produktivität. Wenn ich für die einfachste Aufgabe durch 25 verschiedene Menüs muss, dauert mein Entwicklungsprozess entsprechend länger. Und Zeit ist Geld, das gilt auch hier, und die Kosten werden weitergereicht, richtig, an den Kunden.

Zitat von Hansa:

Es geht mir um die letztendliche Qualität des Programmes. Und die sehe ich bei C Programmen gegenüber Delphi eindeutig als niedriger an.

Für dieses Vorurteil kannst du aber keine stichhaltigen Argumente liefern. Und da ich sowohl C als auch Delphi kann und weiß, daß es sowohl unordentlichen Delphi-Code als auch ordnelichen und äußerst übersichtlichen C-Code gibt, gehe ich von der simplen Tatsache aus, daß die Qualität eines Programmes nicht durch die Programmiersprache, sondern durch Compiler und Programmierer geregelt wird.

Zitat von Hansa:

Eben weil mehr Know How, bzw. ein komplizierterer Einstieg, sowie längere Zeit notwendig ist, ein Programm fertigzustellen zu testen usw.

Siehe oben

Zitat von Hansa:

Ein Fundament kann ruhig nicht sauber sein, da es sowieso in den Dreck kommt. Das kann man deshalb auch mit C machen

Ich hoffe du wirst nie Architekt...

Edit zum ersten Absatz: Daß ich Moderator in einem Delphi-Forum bin und nicht in einem C-Forum und daß ich auch nicht aktiv in C-Foren bin liegt daran, daß die Leute in einschlägigen C-Foren meist zu arrogant sind und ihre Sprache um alles in der Welt verteidigen wollen. Mein persönlicher Eindruck ist, daß das im DF und in der DP nicht so ist, auch wenn ich hier gerade dabei bin, von dieser Vorstellung ein wenig abzuweichen

**trifid**

bitte eine Wende ...
es geht hier doch um die "Vor und Nachteile von Delphi 8 for .net vs c#, vb.net" herauszufinden.
Mir fehlt ein wenig die Struktur und die etwas eigenartige vorgehensweise darin eine Lösung zu finden.
Sicherlich mag der Eine mehr Delphi und der Andere weniger. Der eine kommt von C, der andere hat mit Basic
angefangen. Weiterhin besitzen welche Delphi8 und gleichzeitig sogar das VS.net.
Welche Erfahrungen wurden gemacht; gegenüber Delphi5,6,7 und Delphi8 und worin liegt der Unterschied
in der Entwicklung von Software zwischen Delphi8 und VSc#.net VSvb.net.
Also muss doch unterschieden werden zwischen der

IDE (Aufbau, Struktur, Geschwindigkeit, Stabilität)
den Compiler (Compilierzeiten, Syntax, Sprachumfang),
Erstellung von Komponenten, DLL, Applikationen
Anwendungsbereiche (Komponentenbau, allg. Anwendungen, Datenbanken, Grafik, Spiele)
Verwendung vorhandenere Komponenten oder Kauf von Komponenten (Kosten - Nutzen)
Einarbeitung - Vorgehensweise - Lernaufwand

Sicherlich, habe ich den ein oder anderen Punkt vergessen oder muss sogar vertieft werden.
Wenn ich mir etwas von diesen Artikel wünschen könnte, wäre es eine Auflistung mit einer
ordentlichen Struktur (wie z.B. die Testberichte von der ct') und einer Bewertung.
Wobei Unterschieden werden müsste, ob man ein Komponentenbauer ist oder ob jemand Spiele oder Datenbanken
programmiert.
Für Wenige oder auch für Viele kann dieser Artikel - oder das Resultat davon - eine Kaufentscheidung sein.

Und, "Delphi ist natürlich nicht von Microsoft" das ist für mich kein Kaufargument.
Denn "Delphi ist von Borland" und "Visual C# ist von Microsoft" - ich denke das wissen wir doch alle.

Zitat von trifid:

Mir fehlt ein wenig die Struktur und die etwas eigenartige vorgehensweise darin eine Lösung zu finden.

Worauf ich eigentlich ursprünglich hinaus wollte ist, daß es keine allgemeingültige Lösung auf die frage gibt "Welche Sprache ist besser?".
Inhaltlich sind C#, VB.NET und Delphi.NET vollkommen identisch, da Microsoft an die Compiler sehr enge Richtlinien vergibt, was sie zu tun und zu lassen haben. Das Hauptziel von .NET ist die Sprachkompatibilität auf der Programmierseite, daher muss jede .NET-Sprache, die sich so nennen darf, den Standards von Microsoft unterliegen.
Ausschlaggebend ist am Ende die persönliche Priorität für gewisse Merkmale. Die Compiler sind dabei nahezu uninteressant. IDE, Vorkenntnisse in Sprachen und dergleichen sind die Messpunkte, die es bei dieser Frage gibt.
Zu Delphi8 würde ich bisher keinem Raten, genauso wenig wie zum CSB, zumindest nicht zu den Kaufversionen. Zum reinschnuppern ist der CSB Personal Edition meines Erachtens die beste Wahl, er hat VS.NET-Feeling, eine mächtige Sprache und obendrein kostenlos. Ausgereift ist er aber genauso wenig wie Delphi8. Für richtige IDEs von Fremdherstellern ist es jetzt noch zu früh, wirklich ausgereifte Produkte werden uns frühestens mit dem CSB2 und Delphi9 ins Haus stehen, wenn nicht sogar erst eine weitere Generation später.
Was die IDEs angeht so sind D8 und der CSB weitgehend identisch, sie beutzen beide die gleichen Frontends, wobei insgesamt die Borland-IDE an das VS.NET angelehnt ist. Das VS.NET hat den Vorteil, daß es bereits in der zweiten Generation vorliegt, man hat also schon einige Fehler ausgebügelt und den Komfort erweitert, was bei den beiden Borland-IDEs noch nicht der Fall sein kann.
Will man .NET sinnvoll einsetzen, besorgt man sich Delphi8 und das VS.NET (komplett), denn nur dann kann man die Vorteile von .NET komplett ausspielen, nämlich die Sprachkompatibilität. Man sucht sich die Programmiersprache passend zum aktuellen Problem und erzeugt sich eine Assembly, die man dann im Hauptprojekt einbindet. So ist es vorgesehen und das ist auch der beste Mittelweg, um immer effizient zu arbeiten.

Zitat von tommie-lie:

Das VS.NET hat den Vorteil, daß es bereits in der zweiten Generation vorliegt, man hat also schon einige Fehler ausgebügelt und den Komfort erweitert, was bei den beiden Borland-IDEs noch nicht der Fall sein kann.

Generell ist das Visual Studio.NET ein sehr gutes Beispiel. Auch schon in der ersten Generation. Integrierte Hilfe (man muss also nicht mehr zwischen Programm und Hilfe hin und her wechseln, sondern wie beim Tabbed-Browsing schaltet man bequem zwischen Registerseiten hin und her) und Erweiterbarkeit (ein Plug-in für´s Highlighting, Zugriff auf den Compiler, und schon könnte das Visual Studio IMHO Delphi-Projekte kompilieren) sind nur zwei Glanzpunkte.
Man merkt, dass sich bei Microsoft Fachleute damit beschäftigen, eine möglichst simple IDE zu entwickeln, die dem Anwender viele Freiheiten lässt, ihm dabei aber soviel Arbeit wie möglich abnimmt.

Borland ging mit der D8-IDE den richtigen Weg. Ich hoffe, dass sie mit D9 den Weg fortsetzen werden, so dass auch Delphi-Entwickler in den Genuss der o.g. integrierten Hilfe bspw. kommen.

Zitat:

[...] wirklich ausgereifte Produkte werden uns frühestens mit dem CSB2 und Delphi9 ins Haus stehen, wenn nicht sogar erst eine weitere Generation später.

Als Anmerkung: Ich habe irgendwo mal gelesen, dass Microsoft im nächsten Jahr (vermutlich!) das neue Visual Studio zum .NET-Framework 2.0 veröffentlichen wird. Delphi 9 wird daher noch mit dem aktuellen .NET-Framework arbeiten, und Delphi 10 dürfte dann die Version werden, die auch auf 2.0er-Framework zugreift.
Insofern wäre mein Vorschlag sogar der, auf D10 zu warten und sich bestenfalls die Trial- oder evtl. eine Personalversion von D9 anzuschauen.

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?

Er meinte wahrscheinlich die leeren Klammern, wenn eine Funktion/Prozedur keine Parameter benötigt

markieren

Code:

IrgendeineCFunktion();

Einige namentlich bekannte Delphi-Programmierer (

) machen das ja auch. Na ja ...

Zitat:

Worauf ich eigentlich ursprünglich hinaus wollte ist, daß es keine allgemeingültige Lösung auf die frage gibt "Welche Sprache ist besser?".

Deswegen wurde die Frage ja auch nicht gestellt. Der Beitrag von MaBuSe beschäftigt sich mit den Vor- und Nachteilen aller .NET-Sprachen. Wenn man die objektiv zusammenfasst, ohne sich in einen ähnlichen Konflikt wie den berühmten Browser-Krieg verwickeln zu lassen (da klingelt doch was ...

), dann erhält jeder Interessent eine Liste mit besagten Vor- und Nachteilen und kann für sich selbst entscheiden, mit welcher Sprache er arbeitet.

Zitat von MathiasSimmack:

Man merkt, dass sich bei Microsoft Fachleute damit beschäftigen, eine möglichst simple IDE zu entwickeln, die dem Anwender viele Freiheiten lässt, ihm dabei aber soviel Arbeit wie möglich abnimmt.

So sehr ich Microsoft hasse (

), ich habe immer behauptet, daß sie für Entwickler sehr gute Qualität liefern. Das fängt beim IMHO sehr guten PSDK an und hört beim hochintegrierten MSVS auf.

Zitat von MathiasSimmack:

Borland ging mit der D8-IDE den richtigen Weg. Ich hoffe, dass sie mit D9 den Weg fortsetzen werden, so dass auch Delphi-Entwickler in den Genuss der o.g. integrierten Hilfe bspw. kommen.

Hoffen wir das nicht alle? Aber ich denke mal, daß sie sich immer mehr ans VS anlehnen werden, immerhin haben sie Gallileo nicht umsonst entwickelt

Zitat von MathiasSimmack:

Zitat von tommie-lie:

[...] wirklich ausgereifte Produkte werden uns frühestens mit dem CSB2 und Delphi9 ins Haus stehen, wenn nicht sogar erst eine weitere Generation später.

Als Anmerkung: Ich habe irgendwo mal gelesen, dass Microsoft im nächsten Jahr (vermutlich!) das neue Visual Studio zum .NET-Framework 2.0 veröffentlichen wird. Delphi 9 wird daher noch mit dem aktuellen .NET-Framework arbeiten, und Delphi 10 dürfte dann die Version werden, die auch auf 2.0er-Framework zugreift.
Insofern wäre mein Vorschlag sogar der, auf D10 zu warten und sich bestenfalls die Trial- oder evtl. eine Personalversion von D9 anzuschauen.

Ich sagte ja auch "frühestens"

Aber Borland wird Microsoft immer einen Schritt hinterher sein, das wird allen Konkurrenten so gehen. Wer weiß, wann D10 rauskommt, vielleicht ist MS dann schon beim Framework 2.1 oder gar 3, die Entwicklungszyklen sind bei Borland ja immer länger,
als alle hoffen (selbst Borland *g*).

Zitat von MathiasSimmack:

Er meinte wahrscheinlich die leeren Klammern, wenn eine Funktion/Prozedur keine Parameter benötigt

markieren

Code:

IrgendeineCFunktion();

Einige namentlich bekannte Delphi-Programmierer (

) machen das ja auch. Na ja ...

Wer macht denn sowas?

Ich find's bei Funktionen für Delphi nur in Texten praktisch, wenn ich Funktionen kennzeichnen will. In normalen Quellcodes mache ich sowas eigentlich nicht...
Außerdem sind die wie gesagt nicht sinnvoll sondern zeugen von einem gut strukturierten und strengen Syntaxregelwerk, das konsequent durchgezogen wird.