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

**MaBuSE**

Hallo zusammen,

zuerst sorry, das ich am Freitag nichts schreiben konnte.

Ich möchte kurz zu diesem Thema etwas sagen:

Ich wollte eigentlich nur relativ "objektiv" einige Pro und Kontra zu / gegen Delphi (bzw. anderen .NET Sprachen) sammeln.

Diese Liste wird Teil des Entscheidungsprozesses hier in der Firma sein.

Ich wollte keinen Glaubenskrieg zuwischen den verschiedenen Sprachen anfesseln. (obwohl das schon recht amüsant zu lesen ist

)

Ich bin der Meinung dass man in fast jeder Sprache sauber, übersichtlich und einigermaßen strukturiert schreiben kann.

Das ist wie in den gesprochenen Sprachen.

Es gibt Leute, die sprechen ein klares, einfaches, gutes Englisch!!!
Es gibt aber auch Leute die nuscheln so, das man nichts mehr versteht.

Das gilt natürlich für jede Andere Sprache auch!!! (Deutsch, Französisch, C#, Pascal, ...)

Es gibt auch Autoren die können ein schwieriges Thema in einen Fachbuch so einfach und bildlich darstellen, das man es sofort versteht. Andere Autoren erklärten in ihren Büchern das selbe nur "kompliziert".

Beide Bücher werden gekauft!

Der eine Leser kommt mit der einfachen, klaren gut strukturieren Sprache besser zurecht, der
andere Leser kauft das komplizierte Buch, weil er es dort besser versteht.

Und was ist die Moral von der Geschichte?

"Das ist Geschmacksache." sagte der Affe und biss in die Seife.

Wer kommerziell Software im Team schreibt, sollte aber darauf achten, dass auch Andere seinen Code verstehen.

Aber das ist nur meine Bescheidene Meinung.

ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus. (Er erkennt, das das ein konstantes False ist

)

pps: Die Beiträge werden OT.

**MaBuSE**

Verschiedene schrieben in diesem Threat sinngemäß

...sich bestenfalls die Trial- oder evtl. eine Personalversion von D8/D9 anzuschauen.

Das mag auf einen einzelnen Programmierer zutreffen.

Aber es gibt ja auch Firmen in denen im Team an den Produktion gearbeitet wird.
Wir haben über 50 Programmierer. Wenn man jetzt eine Portierung / Weiterentwicklung von Anwendungen ins Auge fasst, muss man alle Kosten mal 50 (oder mehr) nehmen.

Ein Programmierer muss sich nun von Delphi lösen und in C# einarbeiten. Ein technikbegeisterter Mensch, wie die meisten von uns, ist das wahrscheinlich kein Problem.
Aber wenn man von z.B. 50 Programmierern redet, dann sind mit Sicherheit auch einige dabei, denen das nicht so leicht fällt. (Weil sie z.B. aus der fachlichen Seite kommen und Delphi die einzige Sprache ist, die sie überhaupt können) [Ich meine das jetzt nicht negativ!]

Bei einem Umstieg muss man natürlich auch solche Dinge berücksichtigen.
Projekte in denen ein paar Hundert Mann-Jahre stecken, schreibt man nicht eben mal auf C# um. Da macht VCL.NET direkt Sinn.

Trotzdem wird darüber nachgedacht.

In solchen Projekten benötigt man natürlich auch viele der Funktionen die nur in der Architekt Version vorhanden sind. Also einfach mal mit der personal Version programmieren geht also auch nicht.

Ich habe mir Delphi 8 angeschaut. Aber es haben ja auch viele Andere Delphi 8 angeschaut.
Deshalb diese Pro/Kontra Liste.

Diese Liste kann und soll ja auch vielen Anderen bei solchen Entscheidungen helfen.

Zitat von MaBuSE:

Ich wollte keinen Glaubenskrieg zuwischen den verschiedenen Sprachen anfesseln. (obwohl das schon recht amüsant zu lesen ist

)

Das hast du doch auch gar nicht gemacht.

Mir persönlich ging das Hin und Her zwischen tommie-lie und Hansa auf den Kranz. Deswegen habe ich meinen obigen Einwand gepostet.

**Hansa**

Zitat von MaBuSE:

ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus.

Genau das habe ich gemeint.

Denn in C wird so was auf die Spitze getrieben. Und die Spitze ist noch nicht genug, da muß notfalls auch noch Assembler ran. Da es sich sogar um ein größeres Team handelt, wäre C&Co. für mich allenfalls 3. Wahl.

Zitat von MathiasSimmack:

...auf den Kranz.

Heißt es nicht "auf den Keks gehen" ?

**MaBuSE**

Zitat von Hansa:

Zitat von MaBuSE:

ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus.

Genau das habe ich gemeint.

Denn in C wird so was auf die Spitze getrieben. Und die Spitze ist noch nicht genug, da muß notfalls auch noch Assembler ran. Da es sich sogar um ein größeres Team handelt, wäre C&Co. für mich allenfalls 3. Wahl.

Lieber Hansa,
ich sagte oben, das kann man in jeder Sprache machen (nuscheln).
Ich kann Dir gerne auch in Delphi Quellcode geben, den Du nicht verstehen wirst.
Das hat nichts mit der verwendeten Sprache zu tun.

Was ich z.B. besonders gut leiden kann

:
Der Programmierer baut absichtlich einen Fehler ein, der später in einem anderen Modul durch einen 2 Fehler wieder aufgehoben wird. (statt in den 2 Modulen eine Bedingung einzubauen)

mfg
MaBuSE

ps: Ich habe auch schon ASM in Delphi eingebaut. Und das war auch an dieser Stelle angebracht.

Zitat von MaBuSe:

(obwohl das schon recht amüsant zu lesen ist

)

Stimmt

Zitat von MaBuSe:

Ich wollte keinen Glaubenskrieg zuwischen den verschiedenen Sprachen anfesseln.

Aber du hast ihn nicht angezettelt...

Zitat von MaBuSe:

Diese Liste wird Teil des Entscheidungsprozesses hier in der Firma sein.

Wie groß ist denn euer Softwareetat? Bei genügend Kleingeld wäre es meines Erachtens sinnvoll, sowohl Delphi.NET, als auch das VS.NET zu kaufen, selbst wenn letzteres nur für einige Arbeitsplätze verfügbar sein wird. Besonders wenn ihr vorher schon Entwickler hattet, die's nicht so mit Delphi hatten und lieber mal ihren C-Compiler angeworfen haben, würde das die Gesamtproduktivität erhöhen, weil sie die C-Leute nicht erst in eine komplett neue Syntax einarbeiten müssen (ich persönlich habe mich in C# sofort wohl gefühlt).
Wenn der Etat sowieso schon zu eng bemessen ist, würde ich auch in Betracht ziehen, die Architects nicht für alle 50 Mitarbeiter zu kaufen sondern den Rest mit Professionals auszustatten. Das mag zwar jetzt ein wenig nach Klassentrennung klingen, halte ich aber in einem solchen Fall, wo der Komplettumstieg nicht finanzierbar aber erwünscht ist, aber für einige die Architect unumgänglich ist, für sinnvoll. Mit dem gesparten Geld bleibt dann auch für das VS.NET übrig.
Wenn vorher ausschließlich Delphi eingesetzt wurde und keiner der 50 Leute auch nur eine if-Bedingung in C oder Basic hinkriegt, wäre es bei knappem Etat sinnlos, sich das VS.NET zu beschaffen, die Kosten für die Weiterbildung wären dann wohl doch eher in einer guten Delphi-Version angelegt als in einem Compiler, mit dessen Sprache keiner umgehen kann.

Du siehst schon, ich würde das nicht von der Sprache an sich abhängig machen, wenn ihr eh alle Delphi und C oder Basic könnt, sondern vielmehr von den aktuellen Firmenverhältnissen. Wenn ihr ohnehin einen großen Ausbau plant und demnächst nochmal 50 Programmierer ins Boot holen wollt, wäre es vielleicht nicht unklug, wenn die neuen Mannen C(#) können, dann würde sich auch das VS.NET lohnen, selbst wenn aus dem alten Team keiner C kann. Da wäre eine Unterteilung in Arbeitsgruppen nach Programmiersprachen eh angebrachter. Die Aufgaben werden dann so auf die Arbeitsgruppen verteilt, daß am Ende Assemblies rauskommen, die sowohl in C#, als auch in Delphi.NET entwickelt wurden, und eingebunden wird es dann in ein Hauptprojekt, bei dem man die Sprache ja auslosen kann

Wenn ihr viel Wert auf Abwärtskompatibilität legt und mit Sicherheit alte Delphi-Projekte nach .NET portieren wollt, ohne sie neuzuschreiben, seit ihr auf jeden Fall auf Delphi.NET angewiesen, aber selbst die VCL.NET hat viele Einschränkungen, was Portabilität angeht, ein wenig dran rumfummeln wird man immer müssen. Da würde ich mir dann auch überlegen, ob der Aufwand der Portierung lohnt, oder ob ich das dann doch neu entwickle, dann auch gerne mit dem VS.NET oder dem CSB.

Alles eine Frage der Umgebung, bei .NET fällt nunmal die Sprache an sich einfach hinten runter, das ist ja Sinn der ganzen Sache.

------------------------------------

Zitat von Hansa:

Zitat von MaBuSE:

ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus.

Genau das habe ich gemeint.

Denn in C wird so was auf die Spitze getrieben. Und die Spitze ist noch nicht genug, da muß notfalls auch noch Assembler ran. Da es sich sogar um ein größeres Team handelt, wäre C&Co. für mich allenfalls 3. Wahl.

Ich glaub' ich spinne

In C gibt es die konstanten false und true genauso wie in Delphi auch (und das sogar bequemer/sauberer als in Delphi). Wenn du deinen C-Code so schreibst, weiß ich, warum du meinst, daß das unübersichtlich sei, aber das ist deine Sache, es gibt auch Leute die können vernünftigen C-Code schreiben

Und in C muss man genauso selten auf Assembler zurückgreifen wie in Delphi auch, dafür gibt's nämlich die ganzen C-Bibliotheken, die du bei Delphi auch dabei hast, nur merkst du es da nicht und fragst dich hinterher, warum die Anwendung 300kb groß ist.

Nachtrag: Guck dir mal an, wieviel Assemblercode in den ganzen RTL-Units von Delphi drin ist (Win32), dann können wir uns nochmal drüber unterhalten, daß man in C oft auch noch Assembler ran muss

**MaBuSE**

Zitat von tommie-lie:

Zitat von MaBuSe:

Diese Liste wird Teil des Entscheidungsprozesses hier in der Firma sein.

Wie groß ist denn euer Softwareetat? Bei genügend Kleingeld wäre es meines Erachtens sinnvoll, sowohl Delphi.NET, als auch das VS.NET zu kaufen, selbst wenn letzteres nur für einige Arbeitsplätze verfügbar sein wird.

Das entscheide ich nicht. Ich sammele nur die Fakten, damit die Entscheider eine Grundlage zur Diskussion haben.

Zitat von tommie-lie:

Da wäre eine Unterteilung in Arbeitsgruppen nach Programmiersprachen eh angebrachter. Die Aufgaben werden dann so auf die Arbeitsgruppen verteilt, daß am Ende Assemblies rauskommen, die sowohl in C#, als auch in Delphi.NET entwickelt wurden, und eingebunden wird es dann in ein Hauptprojekt, bei dem man die Sprache ja auslosen kann

Das wird in diesem Unternehmen garantiert nicht gemacht werden. Die Struktur der Abteilungen wird nicht geändert.

Zitat von tommie-lie:

Wenn ihr viel Wert auf Abwärtskompatibilität legt und mit Sicherheit alte Delphi-Projekte nach .NET portieren wollt, ohne sie neuzuschreiben, seit ihr auf jeden Fall auf Delphi.NET angewiesen, aber selbst die VCL.NET hat viele Einschränkungen, was Portabilität angeht, ein wenig dran rumfummeln wird man immer müssen. Da würde ich mir dann auch überlegen, ob der Aufwand der Portierung lohnt, oder ob ich das dann doch neu entwickle, dann auch gerne mit dem VS.NET oder dem CSB.

Das bin ich immer noch am prüfen. Leider gibt es einige der benutzten Komponenten (noch) nicht in Delphi 8 (z.B. DOA).

Zitat von tommie-lie:

Alles eine Frage der Umgebung, bei .NET fällt nunmal die Sprache an sich einfach hinten runter, das ist ja Sinn der ganzen Sache.

Trotzdem muss man sich ja für eine (oder mehrere) Entwicklungsumgebung(en) entscheiden.

Zitat von tommie-lie:

Zitat von Hansa:

Zitat von MaBuSE:

ps: Warum schreibt man nicht einfach. Result:=1=0; ist doch viel kürzer alsResult := False; und der Compiler macht das selbe draus.

Genau das habe ich gemeint.

Denn in C wird so was auf die Spitze getrieben. Und die Spitze ist noch nicht genug, da muß notfalls auch noch Assembler ran. Da es sich sogar um ein größeres Team handelt, wäre C&Co. für mich allenfalls 3. Wahl.

Ich glaub' ich spinne

In C gibt es die konstanten false und true genauso wie in Delphi auch (und das sogar bequemer/sauberer als in Delphi). Wenn du deinen C-Code so schreibst, weiß ich, warum du meinst, daß das unübersichtlich sei, aber das ist deine Sache, es gibt auch Leute die können vernünftigen C-Code schreiben

Und in C muss man genauso selten auf Assembler zurückgreifen wie in Delphi auch, dafür gibt's nämlich die ganzen C-Bibliotheken, die du bei Delphi auch dabei hast, nur merkst du es da nicht und fragst dich hinterher, warum die Anwendung 300kb groß ist.

Nachtrag: Guck dir mal an, wieviel Assemblercode in den ganzen RTL-Units von Delphi drin ist (Win32), dann können wir uns nochmal drüber unterhalten, daß man in C oft auch noch Assembler ran muss

Hallo ???
ich will ja niemanden den Mund verbieten, aber ich wollte mir dem Beispiel nur zeigen, das es egal ist in welcher Sprache man schreibt. Überall kann man "schlechten Code" schreiben. Aber man kann auch in allen Sprachen sauber programmieren. Das liegt nicht an der Sprache, sondern am Programmierer!

Wenn Ihr nur diskutieren wollt was den nun besser ist eine "{" oder ein "begin", dann seid doch bitte so lieb und macht einen eigenen Threat auf. Vielen Dank.

Das ist "off topic".

Vielen Dank für Euer Verständnis.

Da ich jetzt genug über unsere überteuerte Alpha-Testversion gemeckert habe (

), kann ich auch etwas abschweifen...

Zitat:

Das bin ich immer noch am prüfen. Leider gibt es einige der benutzten Komponenten (noch) nicht in Delphi 8 (z.B. DOA).

Wie ich bereits in einem anderem Thread erwähnt habe: DOA wird entweder mal wieder einfach genial oder es wird kein DOA mehr geben.

Da du bereits entweder mit dem ODP.Net oder System.Data.OracleClient ziemlich komfortabel und flink auf eine Ora DB zugreifen kannst (es gibt ENDLICH, auch ohne DOA, Unterstützung für REF Cursor und REF Objects

), muss sich AllroundAutomations tierisch ins Zeug legen um uns mal wieder ein paar hundert Euronen abzuknöpfen.

Der

Ora Provider von CoreLabs taugt IMHO weniger als die MS-Komponenten oder der ODP.Net.

Da es von DOA wahrscheinlich KEINE VCL.Net Kompos geben wird (warum auch

), wird das nächste DOA kein Argument für D8 sein (eine StiNo-Assembly kann jede .Net Sprache verwenden).

p.s.: Dieses Syntax-gezicke geht mir auch auf den Keks.

**MaBuSE**

Zitat von Robert_G:

Da es von DOA wahrscheinlich KEINE VCL.Net Kompos geben wird (warum auch

), wird das nächste DOA kein Argument für D8 sein (eine StiNo-Assembly kann jede .Net Sprache verwenden).

Und wie verbinded man eine Nicht-VCL.NET Datenbankkomponente mit z.B. einem TDBEdit?

Zitat von Marco Kalter:

There is no concrete information yet. Unfortunately this port requires considerably more effort than Delphi 3 -> 4 -> 5 -> 6 -> 7.

Daraus schliesse ich mal das es ein Port nach D8 (vcl.net) wird.

TOracleDataSet ist ja z.B. von dem TDataset abgeleitet.
Dadurch kann man ja erst all die Komponenten verbinden.

Nochmal OT:

Jeder Nachfahre von System.Windows.Forms.Control besitzt einen BindingContext.
Wozu also DBEdits?
Ein DataAdapter gibt dir die Möglichkeit für DML/SELECT _eigene_ Statements zu schreiben.
Im System.Data.DataSet kannst du sämtliche Verknüpfungen und Constaints nachbilden. Der User bekommt also WÄHREND der Eingabe die Meldung, dass er Käse fabriziert, nicht erst beim Speichern. Das konnte zwar das TOracleDatset auch, aber es war dabei doch etwas hakelig.

Wozu also ein TDataset-Nachfahre?

Ich komme jetzt nicht schon wieder damit, was ich von der VCL.Net halte, aber warum lässt du deine Win32 Projekte nicht einfach auf Win32? Es wird schließlich auch in Zukunft Win32 IDEs von Borland geben. (Bei der nächsten größeren Änderung kann man es immer noch zu Winforms/Webforms portieren...)
Da die Klassen der VCL.Net fast nichts mit den den Klassen aus System.Windows.Forms zu tun haben ist das ganze in meinen Augen sowieso keine Portierung, vielmehr ist es eine unötige Zeitverschwendung.
Nur weil du deinen Code mit viel Schweiß, ein paar grauen Strähnen mehr und 2-3 Nervenzusammenbrüchen unter VCL.Net zum Laufen gebracht hast, ist es noch lange kein "wirkliches" .Net-Programm (mit allen Vorteilen des FrameWorks in Funktionität und vereinfachter Entwicklung) geworden.

Zum Thema:
Ich kann die VCL.Net nicht wirklich als Vorteil für D8 sehen.

Ich brauchte 10-20 Klicks um das ganze VCL-zeugs aus dem File\New -menu zu bekommen -> VCL.Net war für mich also mit Mehraufwand verbunden.