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 :mrgreen:)

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.

Delphi-Quellcode:

Result:=1=0;

ist doch viel kürzer als

Delphi-Quellcode:

Result := False;

und der Compiler macht das selbe draus. (Er erkennt, das das ein konstantes False ist :mrgreen:)

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.

[MathiasSimmack]

Zitat:

Zitat von MaBuSE

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

Das hast du doch auch gar nicht gemacht. :roll: 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:

Zitat von MaBuSE

ps: Warum schreibt man nicht einfach.

Delphi-Quellcode:

Result:=1=0;

ist doch viel kürzer als

Delphi-Quellcode:

Result := False;

und der Compiler macht das selbe draus.

Genau das habe ich gemeint. :mrgreen: 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:

Zitat von MathiasSimmack

...auf den Kranz.

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

[MaBuSE]

Zitat:

Zitat von Hansa

Zitat:

Zitat von MaBuSE

ps: Warum schreibt man nicht einfach.

Delphi-Quellcode:

Result:=1=0;

ist doch viel kürzer als

Delphi-Quellcode:

Result := False;

und der Compiler macht das selbe draus.

Genau das habe ich gemeint. :mrgreen: 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.

[tommie-lie]

Zitat:

Zitat von MaBuSe

(obwohl das schon recht amüsant zu lesen ist :mrgreen:)

Stimmt ;-)

Zitat:

Zitat von MaBuSe

Ich wollte keinen Glaubenskrieg zuwischen den verschiedenen Sprachen anfesseln.

Aber du hast ihn nicht angezettelt...

Zitat:

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:

Zitat von Hansa

Zitat:

Zitat von MaBuSE

ps: Warum schreibt man nicht einfach.

Delphi-Quellcode:

Result:=1=0;

ist doch viel kürzer als

Delphi-Quellcode:

Result := False;

und der Compiler macht das selbe draus.

Genau das habe ich gemeint. :mrgreen: 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 :wall:
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 :roll:
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 :roll:

[MaBuSE]

Zitat:

Zitat von tommie-lie

Zitat:

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:

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:

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:

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:

Zitat von tommie-lie

Zitat:

Zitat von Hansa

Zitat:

Zitat von MaBuSE

ps: Warum schreibt man nicht einfach.

Delphi-Quellcode:

Result:=1=0;

ist doch viel kürzer als

Delphi-Quellcode:

Result := False;

und der Compiler macht das selbe draus.

Genau das habe ich gemeint. :mrgreen: 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 :wall:
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 :roll:
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 :roll:

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". :warn:

Vielen Dank für Euer Verständnis.

[Robert_G]

Da ich jetzt genug über unsere überteuerte Alpha-Testversion gemeckert habe ( :lol: ), 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 :-D ), muss sich AllroundAutomations tierisch ins Zeug legen um uns mal wieder ein paar hundert Euronen abzuknöpfen. :zwinker:
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:

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:

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.

[Robert_G]

Nochmal OT: :roll:
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. :lol:

[MaBuSE]

Morgen kommen 2 Borland Mitarbeiter zu uns, um mit uns über .net zu diskutieren.
Ich bin mal gespannt, was die zu sagen haben. :chat:

Ich werde diesen Threat zusammenfassen und mit in die Diskussion bringen :mrgreen:

[tommie-lie]

Zitat:

Zitat von MaBuSE

diesen Threat

War das Absicht? :mrgreen:

Wenn es loyale Mitarbeiter sind, werden sie wohl bei allen Möglichkeiten die Vorteile vom CSB und D8 anpreisen. Ideal wäre vermutlich ein hohes Tier von MS und ein hohes Tier von Borland, aber die wird man wohl nie zu schnappen kriegen...

[MaBuSE]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von MaBuSE

diesen Threat

War das Absicht? :mrgreen:

Ups :oops:

Mein Wörterbuch meint dazu

threat die Bedrohung
threat die Drohung

Ich meine natürlich Thread
Ich glaube nicht, das diese Liste eine Bedrohung für Borland darstellt. :mrgreen:

Zitat:

Zitat von tommie-lie

Wenn es loyale Mitarbeiter sind, werden sie wohl bei allen Möglichkeiten die Vorteile vom CSB und D8 anpreisen.

Ich gehe mal davon aus, das es loyale Mitarbeiter sind. :mrgreen:

Zitat:

Zitat von tommie-lie

Ideal wäre vermutlich ein hohes Tier von MS und ein hohes Tier von Borland, aber die wird man wohl nie zu schnappen kriegen...

Das wäre nicht ideal.
In der Regel kennen sich die "hohen Tiere" nicht so gut mit den technischen Einzelheiten aus, aber das ist ja auch nicht deren Job.
(Gut - es gibt glücklicherweise auch Ausnahmen. Mein Chef z.B. weiß sehr genau was abgeht, und das ist auch gut so :-))

Ich habe also lieber mit den Normalos zu tun, die aber wissen wovon Sie sprechen.

[tommie-lie]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von tommie-lie

Ideal wäre vermutlich ein hohes Tier von MS und ein hohes Tier von Borland, aber die wird man wohl nie zu schnappen kriegen...

In der Regel kennen sich die "hohen Tiere" nicht so gut mit den technischen Einzelheiten aus, aber das ist ja auch nicht deren Job.

Ich meinte auch nicht diese hohen Tiere, ich meinte die hohen Tiere unter den Entwicklern, also nicht die, die mal eine kleine Klasse zusammengebastelt haben, sondern die die Übersicht über die Entwicklung der IDEs und Sprachen haben.
Wenn ihr irgendwelche Marketingfritzen geschickt kriegt, haben die vermutlich auch keine Ahnung von den technischen Aspekte, Programmierer haben die dann vielleicht mal durch 'ne Glasscheibe gesehen.

[Robert_G]

Zitat:

Ich werde diesen Threat zusammenfassen und mit in die Diskussion bringen

Ich hoffe du "zensierst" dabei meine Beiträge nicht zu sehr. :roll:

[MaBuSE]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von tommie-lie

Ideal wäre vermutlich ein hohes Tier von MS und ein hohes Tier von Borland, aber die wird man wohl nie zu schnappen kriegen...

In der Regel kennen sich die "hohen Tiere" nicht so gut mit den technischen Einzelheiten aus, aber das ist ja auch nicht deren Job.

Ich meinte auch nicht diese hohen Tiere, ich meinte die hohen Tiere unter den Entwicklern, also nicht die, die mal eine kleine Klasse zusammengebastelt haben, sondern die die Übersicht über die Entwicklung der IDEs und Sprachen haben.
Wenn ihr irgendwelche Marketingfritzen geschickt kriegt, haben die vermutlich auch keine Ahnung von den technischen Aspekte, Programmierer haben die dann vielleicht mal durch 'ne Glasscheibe gesehen.

Ich kann Dich beruhigen, es ist jemand dabei der sich auskennt :-) Der Andere ist Sales :-)

Wenn Du jemanden treffen willst, der sich auskennt, kann ich dir diverse Entwicklerkonferenzen empfehlen :mrgreen:


Ich muß mich mal wieder selbst rügen, wir werden Offtopic ;-)

[ak1]

Wie ist denn das Treffen mit den Borland-Mitarbeitern gelaufen?

[MaBuSE]

Zitat:

Zitat von ak1

Wie ist denn das Treffen mit den Borland-Mitarbeitern gelaufen?

Das war sehr informativ, es wurden hauptsächlich firmenspezifische Dinge besprochen, die ich hier nicht ausbreiten werde. Aber es ist im Endeffekt nichts wirklich Neues rausgekommen.

Es wird noch ein weiteres Treffen geben, bei dem wir dann die "Neuigkeiten" erfahren werden.
(Mich interessieren vor allem Infos zu Delphi 9 -> Wo geht das ganze hin?)

Ich werde diesen Thread noch mal ordentlich in ein Pro und Kontra Stickpunkte Word Dokument verpacken und mich mit einem Borländer darüber unterhalten ;-)
Nach dem Gespräch werde ich das Dokument und weitere Infos noch mal hier posten.

Danke nochmals für die Infos. :dp:

[merlin17]

<<

Zitat:

Mich interessieren vor allem Infos zu Delphi 9 -> Wo geht das ganze hin?)

>>
Moment mal, wir haben jetzt ein stabiles Delphi7 m(mit oder ohne SP...),
Delphi 8 ist mit SP2 so langsam interessant und nun reden manche schon vom nächsten Delphi.....

Was für Features fehlen denn in D7 für VCL bzw. in D8 für .net......
(ich meine nicht die Versionsnummer, darüber sollten wir wirklich stehen :lol: )


:-) thomas

[MaBuSE]

Zitat:

Zitat von merlin17

<<

Zitat:

Mich interessieren vor allem Infos zu Delphi 9 -> Wo geht das ganze hin?)

>>
Moment mal, wir haben jetzt ein stabiles Delphi7 m(mit oder ohne SP...),
Delphi 8 ist mit SP2 so langsam interessant und nun reden manche schon vom nächsten Delphi.....

Was für Features fehlen denn in D7 für VCL bzw. in D8 für .net......
(ich meine nicht die Versionsnummer, darüber sollten wir wirklich stehen :lol: )

• Delphi 8 macht einen ehr unausgereiften Eindruck.
• Mein Chef will z.B. wissen wie es um die Weiterentwicklung steht
  • wird win32 noch weiterentwickelt, bzw. supportet.
  • wird die neue IDE in der Lage sein über eine Option "Target" die Zielplattform zu bestimmen. (Win 32 oder .net)
  • wird Delphi 9 es einfacher machen Projekte von z.B. D7 nach .net zu portieren
  • ...

Wenn man als Firma eine Entscheidung für die zukünftigen Entwicklerwerkzeuge macht, dann plant man langfristig. Also werden solche Informationen natürlich auch in die Entscheidung einfließen.

Man kann ja nicht ständig die Werkzeuge wechseln. Ziel sollte es sein, alle Projekte (oder zumindest einen großen Teil) in einer Umgebung warten zu können.

Stell Dir vor Du musst 8 verschiedene Entwicklungsumgebungen auf Deinem Rechner installiert haben, weil ein Teil der Projekte in Delphi 5 ein Anderer in Delphi 7, dann noch ein paar C# Projekte, Java wollen wir auch nicht vergessen, ...
Außerdem musst Du natürlich auch alle Sprachen soweit beherrschen, dass man Änderungen an den Projekten vornehmen kann.
Nun stell Dir vor, Du hast nicht nur einen Programmierer sondern 50 oder 100.
Man kann aber die Programmierer nicht nach Programmier-Sprachen einteilen, sondern jeder Programmierer arbeitet in seiner fachlichen Umgebung (Spezialwissen).

Es macht also durchaus Sinn sich auch vor der Entscheidung für Delphi 8 auch die Zukunft anzusehen (Zumal Delphi 9 Ende diesen Jahres noch kommen soll).

[Robert_G]

Zitat:

Man kann aber die Programmierer nicht nach Programmier-Sprachen einteilen, sondern jeder Programmierer arbeitet in seiner fachlichen Umgebung (Spezialwissen).

Genau das ist aber einer der Grundgedanken von .Net. ;)

• Newbies -> VB.Net
• Delphianer -> D8
• Für die Entwickler gibt's dann C#

Alle können trotzdem problemllois an einem Projekt arbeiten (bis auf die D8'ler, die könnten für ein paar Problemchen sorgen)

p.s.: Der größte Vorteil von C# wurde noch gar nicht genannt. -> Der Code schreibt sich irgendwie viel schneller als in Delphi.Net.
In D8 hakt es noch tierisch mit den NameSpaces ( Das wohl meistgehasste Ergebnis davon dürfte wohl System.Windows.Forms.DialogResult sein).
Außerdem kennt D8 keine Escape sequences, obwohl die IMHO eigentlich in den Basisklassen System.String / System.Char definiert sind (oder ist das NOCH ein Vorteil für C# :gruebel: ).

[MaBuSE]

Zitat:

Zitat von Robert_G

Zitat:

Man kann aber die Programmierer nicht nach Programmier-Sprachen einteilen, sondern jeder Programmierer arbeitet in seiner fachlichen Umgebung (Spezialwissen).

Genau das ist aber einer der Grundgedanken von .Net. ;)

• Newbies -> VB.Net
• Delphianer -> D8
• Für die Entwickler gibt's dann C#

Alle können trotzdem problemllois an einem Projekt arbeiten (bis auf die D8'ler, die könnten für ein paar Problemchen sorgen)

Bei und würde das aber so aussehen:

• Newbies -> D8 (alte Projekte D7)
• Delphianer -> D8 (alte Projekte D7)
• Für die Entwickler gibt's dann D8 (alte Projekte D7)
• Eine Abteilung, die sich um 3th Party Komponenten kümmert -> D8 + C# + ?

oder:

• Newbies -> C# (alte Projekte D7)
• Delphianer -> C# (alte Projekte D7)
• Für die Entwickler gibt's dann C# (alte Projekte D7)
• Eine Abteilung, die sich um 3th Party Komponenten kümmert -> D8 + C# + ?

:mrgreen:

[trifid]

nach langer Zeit ...

@ak1
was heisst die "Datenbankkomponenten sind in Delphi 8 besser"?
Wie ist das Datenbank-Konzept bei c# realisiert ?

@MaBuSE
"Die fertige Liste wird den Seiten dann auch zur Verfügung gestellt."
Gibt es eine/diese Liste mittlerweile ?

[Skatspieler]

@MaBuSe
@u. a. Forumteilnehmer

Hallo zusammen, :)

der Thread ist recht interessant geworden.

Ich möchte auch noch ein paar Fragen zum Thema C# oder Delphi 8 + X (+ Kylix) :mrgreen: los werden, welche auch teilweise an die Borland-Mitarbeiter weitergestellt werden sollten).


1.) Welche Vorteile (in bezug auf Leistungsfähigkeit / Mehr-Nutzen) hat die Sprache C# gegenüber Delphi 8/9 oder umgekehrt ?

2.) Welche Konsequenzen hat der Wechsel vom .NET Framework 1.0/1.1 auf 2.0 für Delphi 8 / C# 1 Programme ?

3.) Wie verläuft der Distributionsprozess von .NET - Programmen
- Welches Compilat erhält der Endkunde ?
- Muss der Kunde auf seinem PC-System ein Framework installiert (wenn ja von wem erhält er
dieses Framework) haben oder kann der Kunde das
fertige Compilat wie früher bei der Win32-Entwicklung direkt auf seinem Rechner
(z. B. unter Windows XP-Home einsetzen oder ist XP-Professional mit Framework zwingend
unerlässlich ?)

4.) Wird unter Delphi10 auch C# mit dabei sein, so wie es unter Delphi9 sein soll (wäre eine interessante Fragestellung für die 2 Borland-Mitarbeiter :mrgreen: ) ?

5.) Warum sollte man Delphi9 sich überhaupt anschaffen ?

6.) Wird das neue Framework 2.0 abwärtskompatibel zu Delphi 8/9 sein oder muss man für jede
Programmversion das entsprechende Framework installieren ?

7.) Welches C# ist leistungsfähiger (das von MS oder das von Borland) ?

8.) Noch eine Frage an die Borländer: Wird es ein Kylix 4 geben, wenn ja wann ?

9.) Was wird mit den nicht-.NET-Sprachen (C++, Assembler usw.) passieren ?

10.) Mit welcher (.NET-)Programmiersprache hat man eher Chancen (z. B. als Seiteneinsteiger) in die kommerzielle Programmierszene reinzukommen - C# oder Delphi ?

11.) Ist es möglich mit C# oder Delphi8/9 100%ig web-basierte Anwendungen (z. B. Erstellung eigener WEB-Seiten) zu schreiben ohne dass es hierzu weitere Progerammierwerkzeuge bedarf ?
- Wenn ja, welche Version von Delphi bzw. C# müsste hierzu eingesetzt werden ?

Danke vorab für evtl. Antworten.

Grüsse vom Skatspieler :coder:

[Robert_G]

Mal ein paar schnelle Antworten bevor ich mich verkrümel:

1. Probier's einfach aus. ;)
2. Gar keinen, D8/D2005 sind fest mit dem FrameWork 1.1 verwachsen. Sie nunmal nur 1.1. Selbst Änderungen an einer Version dürften auch in D2005 zum SuperGAU führen.
   D8 ist mit installiertem SP1 für das Framework 1.1 für viele seit vielen Wochen unbenutzbar. (Ich persönlich würde nie auf den Gedanken kommen für D8 ein, ansonsten problemloses, ServicePack zu deinstallieren )
3. Das Framework muss natürlich vorhanden sein. ;) Für ASP.Net Services braucht man ein W2K/WinXPPro (oder die Server versionen)
4. Frag's Pferd :gruebel:
5. Es gibt dir die Möglichkeit Delphi32-Projekte und C#-Projekte in eine Projektgruppe zu packen. Ich erhoffe mir damit eine einfachere Protierung weg von Delphi. Da auch Delphi32 in D2005 eine nette Iterations syntax erweiterung bekommen hat, kann man sicher viele Code stellen besser "vorbeireiten". :)
6. Jede Version des Frameworks wird friedlich mit seinen Vorgängern und Nachfolgern koexistieren.
7. Borland hat kein C#, sie verwenden den C#-Compiler des .Net SDK 1.1
8. --
9. Die werden sicher noch ein paar Jährchen ihre Wichtigkeit behalten.
10. C#!
11. Theoretisch war es sogar in D8 möglich. Wenn du die Geduld hast offt genug Fehlermeldungen wegzuklicken, auf den unglaublich lahmen ASP.Net Designer zu warten oder mal wieder die IDE neustarten musst. Wie schnell/träge D2005 dabei ist muss sich noch zeigen.
    Das Visual Studio 2003 verhält sich da ganz anders, es ist nicht nur massiv schneller, es zickt auch überhaupt nicht rum. (Ich benutze es seit ein paar Monaten und es hat noch nie rumgezickt.)
    Im VS bekommst durch die Setup-Projekt-Templates auch einen sehr einfachen Weg um den/die WebService zu installieren.
    ASP.Net ist bei D8 ab der Prof. dabei, beim VS sollte es die Developer oder Prof. sein

[MaBuSE]

Zitat:

Zitat von Robert_G

Mal ein paar schnelle Antworten bevor ich mich verkrümel:

Ich gebe auch mal meinen Senf dazu ;-)

Zitat:

Zitat von Robert_G

1. Probier's einfach aus. ;)
2. Gar keinen, D8/D2005 sind fest mit dem FrameWork 1.1 verwachsen. Sie nunmal nur 1.1. Selbst Änderungen an einer Version dürften auch in D2005 zum SuperGAU führen.
D8 ist mit installiertem SP1 für das Framework 1.1 für viele seit vielen Wochen unbenutzbar. (Ich persönlich würde nie auf den Gedanken kommen für D8 ein, ansonsten problemloses, ServicePack zu deinstallieren )

[edit]
Das Servicepack war ein Problem für die Delphi 8 Programmier. Es ist aber meines Wissens gelöst. Es sollten nun keine Probleme mehr auftreten.
(s.u.) :oops:
[/edit]

Zitat:

Zitat von Robert_G

3. Das Framework muss natürlich vorhanden sein. ;) Für ASP.Net Services braucht man ein W2K/WinXPPro (oder die Server versionen)

• Der Kunde erhällt das Kompilat, was er vom Programmier bekommt!
• Das Framework muss installiert sein. Mit dem XP ServicePack ist das Framework aber bereits installiert. Ansonsten gibt es bei Microsoft eine Redist Version zum Downloaden und dem Programm beilegen.
• Der Kunde kann selbstverständlich auch XP Home, Win2k oder WinME mit installiertem .Net Framework einsetzen.

Zitat:

Zitat von Robert_G

4. Frag's Pferd :gruebel:

Wer wird sich den jetzt schon Gedanken über Delphi 10 machen? :gruebel:
In Delphi 2005 ist es möglich Delphi für Win32, Delphi für .Net, C# und wer's braucht auch Visual Basic zu nutzen.

Zitat:

Zitat von Robert_G

5. Es gibt dir die Möglichkeit Delphi32-Projekte und C#-Projekte in eine Projektgruppe zu packen. Ich erhoffe mir damit eine einfachere Protierung weg von Delphi. Da auch Delphi32 in D2005 eine nette Iterations syntax erweiterung bekommen hat, kann man sicher viele Code stellen besser "vorbeireiten". :)

Es gibt viele Gründe. Delphi 2005 ist ein deutlicher Schritt nach vorne.
Die VCL.net unterstützt nun viel mehr VCL als bei Delphi 8. (Eine schmerzlich vermisste Komponenten sind nun verfügbar)
Einfaches Beispiel: Schnapp Dir die Beispielprogramme der Delphi 7 und versuch die alle mal in Delphi 8 zu kompilieren (portieren). -> Viel Arbeit, einiges geht gar nicht.
In Delphi 2005 lassen sich die meisten Delphi 7 Beispiele direkt kompilieren (vcl.net)
Unter Delphi 2005 Win 32 alle.

Zitat:

Zitat von Robert_G

6. Jede Version des Frameworks wird friedlich mit seinen Vorgängern und Nachfolgern koexistieren.

Es können beliebige .net Frameworks nebeneinander installiert werden. Die Applikation weiß ja welches Framework sie benötigt und benutzt es dann einfach.

Zitat:

Zitat von Robert_G

7. Borland hat kein C#, sie verwenden den C#-Compiler des .Net SDK 1.1

Das trifft auch für das vb.net zu. Es wird der Compiler des Frameworks benutzt.
-> Also der Gleiche wie bei den Microsoft Produkten.

Zitat:

Zitat von Robert_G

8. --

Meines Wissens nicht.
Aber es gibt ein freeCLX Projekt, in diesem arbeiten auch einige Borländer mit.
http://freeclx.sourceforge.net/index.php
Mittlerweile gibt es auch Crosskylix in der Version 1.0
http://crosskylix.untergrund.net/

Zitat:

Zitat von Robert_G

9. Die werden sicher noch ein paar Jährchen ihre Wichtigkeit behalten.

Ja, aber dir Richtung geht eindeutig nach .net
Es gibt ja auch ein .net Framework für WinME und Win2k-> also die "alten" Betriebssysteme sind ja nicht außen vor.

Zitat:

Zitat von Robert_G

10.C#!

Leider C# :-( (Ich persönlich bin ein Delphi Fan)

Zitat:

Zitat von Robert_G

11.Theoretisch war es sogar in D8 möglich...

@Robert_G: So so, was erwartest Du von einer Beta :mrgreen: In Delphi 2005 ist es möglich.

[r_kerber]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von Robert_G

11.Theoretisch war es sogar in D8 möglich...

@Robert_G: So so, was erwartest Du von einer Beta :mrgreen: In Delphi 2005 ist es möglich.

Guckst Du hier: http://www.kerber-netz.de/exc/Mannsc...sais=2004/2005. Ist mit Delphi 8 erstellt. Vorraussetzung ist aber eine Inetrnet-Provider, der ASP.Net-Unterstützung anbietet!

[Sharky]

Zitat:

Zitat von MaBuSE

...Das Servicepack war ein Problem für die Delphi 8 Programmier. Es ist aber meines Wissens gelöst. Es sollten nun keine Probleme mehr auftreten...

Hai MaBuSE,
hast Du da genauere Infos? Mir ist noch kein Patch bekannt geworden mit dem D8 jetzt bei installiertem SP1 von .NET laufen soll?

[MaBuSE]

Zitat:

Zitat von Sharky

Zitat:

Zitat von MaBuSE

...Das Servicepack war ein Problem für die Delphi 8 Programmier. Es ist aber meines Wissens gelöst. Es sollten nun keine Probleme mehr auftreten...

Hai MaBuSE,
hast Du da genauere Infos? Mir ist noch kein Patch bekannt geworden mit dem D8 jetzt bei installiertem SP1 von .NET laufen soll?

Ich dachte ich hätte sowas in einem Blog gelesen.
Ich muß nochmal nachschauen.
(hoffentlich hab ich da nix verwechselt)

[sakura]

Zitat:

Zitat von MaBuSE

(hoffentlich hab ich da nix verwechselt)

Hast Du :mrgreen: Für Delphi 2005 haben sie eine Lösung, in Delphi 8 wird diese zZ eingearbeitet. Dabei ist "zZ" schon recht lang :-(

...:cat:...

[Robert_G]

Zitat:

Zitat von MaBuSE

Ich dachte ich hätte sowas in einem Blog gelesen.
Ich muß nochmal nachschauen.
(hoffentlich hab ich da nix verwechselt)

Hast du leider. ;)
Es wurde vor einigen Wochen angekündigt, dass es in der nächsten Woche einen Patch für den Compiler geben wird.
Nix ist passiert. Der einzige existierende Workaround ist alles andere als sauber.
Und deine VCL.Net wird damit immer noch nicht laufen. (Aber wen interessiert die schon. :mrgreen: )

[MaBuSE]

Zitat:

Zitat von sakura

Zitat:

Zitat von MaBuSE

(hoffentlich hab ich da nix verwechselt)

Hast Du :mrgreen: Für Delphi 2005 haben sie eine Lösung, in Delphi 8 wird diese zZ eingearbeitet. Dabei ist "zZ" schon recht lang :-(

Zitat:

Zitat von Robert_G

Zitat:

Zitat von MaBuSE

(hoffentlich hab ich da nix verwechselt)

Hast du leider. ;)

:oops: Ist ja schon gut. Ich habs ja schon oben im Beitrag geändert. Man wird halt alt. :wall:
Wir setzten Delphi 8 halt nicht produktiv ein. Und warten auf Delphi 2005 ;-)

[sakura]

Zitat:

Zitat von MaBuSE

:oops: Ist ja schon gut. Ich habs ja schon oben im Beitrag geändert. Man wird halt alt. :wall:
Wir setzten Delphi 8 halt nicht produktiv ein. Und warten auf Delphi 2005 ;-)

Nicht nur ihr :-)

...:cat:...

[tommie-lie]

Zitat:

Zitat von Skatspieler

Wird das neue Framework 2.0 abwärtskompatibel zu Delphi 8/9 sein oder muss man für jede
Programmversion das entsprechende Framework installieren ?

Zitat:

Zitat von Robert_G

Jede Version des Frameworks wird friedlich mit seinen Vorgängern und Nachfolgern koexistieren.

Zitat:

Zitat von MaBuSE

Es können beliebige .net Frameworks nebeneinander installiert werden. Die Applikation weiß ja welches Framework sie benötigt und benutzt es dann einfach.

Irgendwie scheint mir diese Frage nicht komplett beantwortet zu sein...
Wenn man nun .NET1.0-Programme, .NET1.1-Programme und .NET2.0-Programme benutzen will, muss man alle drei Frameworks installieren (soweit ich weiß: ja)?

Zitat:

Zitat von MaBuSE

Wir setzten Delphi 8 halt nicht produktiv ein.

Nicht? :mrgreen:

[MaBuSE]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von Skatspieler

Wird das neue Framework 2.0 abwärtskompatibel zu Delphi 8/9 sein oder muss man für jede Programmversion das entsprechende Framework installieren ?

Zitat:

Zitat von Robert_G

Jede Version des Frameworks wird friedlich mit seinen Vorgängern und Nachfolgern koexistieren.

Zitat:

Zitat von MaBuSE

Es können beliebige .net Frameworks nebeneinander installiert werden. Die Applikation weiß ja welches Framework sie benötigt und benutzt es dann einfach.

Irgendwie scheint mir diese Frage nicht komplett beantwortet zu sein...
Wenn man nun .NET1.0-Programme, .NET1.1-Programme und .NET2.0-Programme benutzen will, muss man alle drei Frameworks installieren (soweit ich weiß: ja)?

JA !!!
Es muß jedes Framework installiert sein.

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von MaBuSE

Wir setzten Delphi 8 halt nicht produktiv ein.

Nicht? :mrgreen:

NEIN :!:
:duck: