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

[MaBuSE]

Hallo,

einige von und haben ja mittlerweile einige Zeit in Delphi 8 investiert.
Ich stelle gerade eine Liste mit pro und kontra zu Delphi 8 zusammen.
Bitte beteiligt Euch, damit diese Liste noch etwas wächst. ;-)

Ich werde Eure Beiträge in diesen Text einarbeiten

Diese Liste kann dann auch bei Entscheidungen für oder gegen Delphi in Unternehmen genutzt werden.

credits:
teilweise sind Daten/Texte von delphipraxis.net, delphi-source.de und entwickler.de eingeflossen
Danke für die Infos.
Die fertige Liste wird den Seiten dann auch zur Verfügung gestellt.



Borland Delphi 8 for .net

pro

• Es kann VCL.NET oder WinForms programmiert werden
• Eine Portierung von Anwendungen wird ohne großen Aufwand möglich, wenn
  • nur Komponenten von Delphi verwendet werden, die auch in D8 zur Verfügung stehen
  • in den D5 / D7 Projekten auf Pointer verzichtet wurde
  • darauf geachtet wurde, dass keine bzw. wenig Warnungen und Hinweise beim Kompilieren erscheinen
• Quellcode ist für Delphi Programmierer gut lesbar. (da Object Pascal)
• keine Einarbeitungszeit in Syntax der Sprache (da Object Pascal)
• Es ist möglich DLLs zu erzeugen, die von .net und win32 benutzt werden können
• Delphi 8 unterstützt direkt Rational ClearCase (IBM)
• Es wird auch eine neue Version (v2) des Tools SourceConneXion für Delphi for .net geben
• Es können bei Migration VCL.NET und WinForms verwendet werden
• Delphi für .NET-Features, die nicht in C# verfügbar sind
  • Kann Assemblies in eine Exe linken, ohne den Sourcecode für die Assemblies zu haben (unter Verwendung der Delphi-Package-Syntax)
  • Funkionen in einer managed Delphi für .NET-Assembly kann direkt von unmanaged Win32 x86-Code ohne COM-Interop oder .NET-Dingen aufgerufen werden.
  • Gespeicherte Symbol-Informationen für eine schnellere Compilierzeit
  • Virtuelle Konstruktoren
  • Benannte Konstruktoren
  • Virtuelle Aufrufe von Klassenmethoden
  • Ressourcenstrings
• Delphi ist natürlich nicht von Microsoft ;-)
• Delphi für .NET unterstützt versiegelte Klassen (sealed classes). Microsoft hat viele Klassen im .NET-Framework versiegelt, und sie bekommen viel mehr Kummer damit als Borland jemals mit privaten Membern bekommen hat, weshalb sie überlegen, einige davon zu öffnen. Allerdings bieten versiegelte Klassen einige Optimierungsmöglichkeiten für den JITer. Das gleiche gilt für finale Methoden.
• Source der VCL wird mitgeliefert !!!
• Kosten für Update auf D8 geringer als Neukauf VS.NET
  • nur geringe "Ausfallzeiten", da Umgewöhnung auf neue Programmiersprache entfällt.
  • VCL kann direkt wie gewohnt benutzt werden
  • FCL kann "in Ruhe" angeeignet und benutzt werden
• Viele 3th Party Komponenten werden in Delphi 8 verfügbar sein (z.B. DevExpress QuantumGrid, ...)

kontra

• Delphi ist natürlich nicht von Microsoft ;-)
  • neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten
  • VCL.NET muss teilweise mit FULL TRUST laufen. (wegen P/Invoke)
    • von lokaler HDD läuft Anwendung ohne Probleme,
    • von Netzlaufwerk gibt's Fehlermeldung "System.Security.Permissions.SecurityPermissio n"
    • Läst sich aber lösen (mehrere Lösungen: caspol -s off oder Intranet Zone auf FULL TRUST setzen oder Assemblies mit Strong Name Schlüssel signieren und vertrauen oder ...)
• langsame IDE

neutral

• Kompatibilität zu Kylix?
• Kompatibilität zu Win32
  • Was unter .NET nicht funktioniert:
    • Direktive absolute
    • Real48 sechs Byte-Gleitkommazahlen
    • File of <type> (TextFile wird aber unterstützt). File of type funktioniert nicht, weil es unterschiedliche Speicherabbilder auf unterschiedlichen Plattformen erzeugen würde, und Speicher in .NET kann sich verschieben.
    • GetMem, FreeMem, ReallocMem (verwenden Sie stattdessen dynamische Arrays, New() und Dispose())
    • ExitProcs
    • die alte Object-Syntax (type TFoo = object)
    • TVarData und Variant-Interna (aber Varianten selbst sind implementiert)
    • AfterConstructor und BeforeDestructor - kein Platz für sie in der CLR. Aber keine große Sache, da sie virtuelle Aufrufe aus dem Konstruktor ausführen können.
  • Sie können keine Objektreferenz in einen Integer umwandeln (z.B. mit TList), weil Sie ihn nicht zurück umwandeln können - aufgrund von Garbage Collection und verwaltetem Code können Sie diese Tricks mit Pointern und lustigen Typumwandlungen nicht tun. Außerdem gibt es keine Garantie, dass Integer und Pointer die gleichen Typen auf einer gegebenen Plattform sind.
• Assemblies die Delphi 8 spezifische Dinge verwenden, laufen nicht in anderen .net Sprachen
  Es ist aber durchaus möglich Assemblys zu schreiben die in allen .net Sprachen funktionieren.
• in D8 verwendete Assemblys, die zur Laufzeit der IDE geändert werden machen Probleme. (man muss fast immer die IDE neu starten)

C#

pro

kontra

• Für Delphi Entwickler eine gewisse Einarbeitungszeit, da
  • keine VCL mehr
  • andere Sprachsyntax
  • andere IDE
• Source der FCL wird nicht mitgeliefert !!!

vb.net

pro

kontra

• es ist nicht alles machbar

.net Framework

pro

• Es können beliebig viele Versionen nebeneinander (gleichzeitig) installiert sein (1.0, 1.1, 2.0, ...)
• Die Anwendung sucht sich das "richtige" Framework
• Framework ist Betriebssystemunabhängig (gleiche API für alle Win32 Versionen, Linux (Mono))

kontra

• auf dem Zielrechner muss das Framework installiert sein ;-)

edit: Punkte von Delphipraxis Mitgliedern aufgenommen
nieurig: Code-Kompatiplität zu Kylix?, auf dem Zielrechner das Framework installiert?
ak1: Update Delphi 8 ist billiger als Neukauf Visual Studio.NET, gewohnte Komponenten ebenfalls in Delphi 8 (VCL)
Robert_G: Assemblies die Delphi 8 spezifische Dinge verwenden, laufen nicht in anderen .net Sprachen, Es is total friemelig in D8 eine Assembly zu verwenden, die zur Laufzeit der IDE geändert wurde. (man muss fast immer die IDE neu starten

[MathiasSimmack]

Zitat:

Zitat von MaBuSE

neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten

Ist das nicht ein Irrtum? Wenn es neue Eigenschaften oder Erweiterungen im .NET-Framework gibt, dann kannst du die auch unter Delphi benutzen, weil Delphi ja in der Hinsicht komplett auf das Framework zugreift. Es mag IMHO sein, dass die VCL.NET dann nicht auf bestimmte Sachen zugreifen kann. Aber reine WinForms-Anwendungen sollten keine Probleme verursachen.

Zumindest habe ich das aus dem Probekapitel von Andreas Kosch so herausgelesen. Das war IMHO ein Satz wie:

Zitat:

Nie wieder auf Header-Übersetzungen warten

o.ä.


Die einzige Befürchtung, die ich hege, ist das Microsoft wieder dieses Runtime-Chaos wie bei VB einführt. Oder in dem Fall: du hast parallele Versionen vom .NET-Framework 1.1 und 2.0 (irgendwann im nächsten Jahr), und Delphi funktioniert natürlich nur mit der 1.1er-Version. Um v2 verwenden zu können, wird (natürlich!) ein Update auf Delphi 10 notwendig.
Aber (und deswegen mal kein Seitenhieb in Richtung Borland) davon wären dann Visual Studio-Entwickler wohl auch betroffen.

[MaBuSE]

Zitat:

Zitat von MathiasSimmack

Zitat:

Zitat von MaBuSE

neue Änderungen / Erweiterungen im .net Framework werden nicht so schnell in Delphi umgesetzt wie bei MS Produkten

Ist das nicht ein Irrtum?

Ich glaube nicht.
In der .net preview zu D7 war ja auch eine Änderung am Framework (v1.0 auf v1.1)
Meines Wissens musste die komplette VCL neu kompiliert werden.

Visual Studio fragte den Entwickler nur:
"Für welche Frameworkversion wollen Sie entwickeln?"
zur Auswahl stand dann 1.0 und 1.1

Wenn die VCL auf 1.1 aufsetzt und dann 2.0 kommt und man die VCL neu kompiliert:
Wie erzeuge ich dann eine Anwendung für Framework 1.1 ?

Es ist ja wohl nicht praktikabel jedesmal die ganze VCL (und alles was davon abhängt) neu zu kompilieren.

Zitat:

Zitat von MathiasSimmack

Die einzige Befürchtung, die ich hege, ist das Microsoft wieder dieses Runtime-Chaos wie bei VB einführt. Oder in dem Fall: du hast parallele Versionen vom .NET-Framework 1.1 und 2.0 (irgendwann im nächsten Jahr), und Delphi funktioniert natürlich nur mit der 1.1er-Version. Um v2 verwenden zu können, wird (natürlich!) ein Update auf Delphi 10 notwendig.
Aber (und deswegen mal kein Seitenhieb in Richtung Borland) davon wären dann Visual Studio-Entwickler wohl auch betroffen.

Eben nicht. bei Visual Studio kann man die Zielplatform auswählen :|

Einer der Vorteile vom .net Framework ist ja, dass sie beliebig viele Versionen nebeneinander installieren lassen. Die Anwendung weiss ja in welchem Framework sie laufen kann.

http://www.delphi-source.de/grundlagen/dotnet/unterschiede.php

Wenn Delphi für .NET ein Package sieht, importiert es die Symbole aus Metadaten und schreibt sie dann in nativem Delphi-Format auf Platte. Der Compiler kann sie nun etwa tausendmal schneller laden, als wenn er sie aus den Metadaten importiert.

Diese Daten müssten ja dann auch auf das "neue" Framework geändert werden :|

[MathiasSimmack]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von MathiasSimmack

Ist das nicht ein Irrtum?

Ich glaube nicht.
In der .net preview zu D7 war ja auch eine Änderung am Framework (v1.0 auf v1.1)
Meines Wissens musste die komplette VCL neu kompiliert werden.

Ja, und?

Ich schrieb

Wenn es neue Eigenschaften oder Erweiterungen im .NET-Framework gibt, dann kannst du die auch unter Delphi benutzen, weil Delphi ja in der Hinsicht komplett auf das Framework zugreift. Es mag IMHO sein, dass die VCL.NET dann nicht auf bestimmte Sachen zugreifen kann. Aber reine WinForms-Anwendungen sollten keine Probleme verursachen.

Ich habe doch gesagt: Bei der VCL wäre es möglich, dass es Probleme geben kann. Aber ich arbeite nicht mit der VCL.NET. Wenn du mich schon zitierst, dann lass solche Dinge nicht weg. Es verfälscht meine Aussage irgendwie. :roll:

[MaBuSE]

Zitat:

Zitat von MathiasSimmack

Wenn du mich schon zitierst, dann lass solche Dinge nicht weg. Es verfälscht meine Aussage irgendwie. :roll:

Normalerweise zitiere ich nie alles. Das kann man ja ein paar Zeien weiter oben nachlesen. :zwinker:
Und sorry, ich wollte Dich (und Deine Aussagen) nicht verfälschen. :wink:

[MaBuSE]

Zitat:

Zitat von MathiasSimmack

Ja, und?

Wir sind am prüfen, ob Delphi 8 bei uns im Haus eingesetzt wird
oder ob wir nach C# wechseln.

Die VCL.NET ist für uns schon wichtig!
Das ist einer der wichtigen Gründe die für Delphi 8 sprechen.

Wenn wir mit der VCL nicht vernünftig arbeiten können
(also eh alle neu programmieren müssen), spricht nicht mehr viel für Delphi.
Dann würde die Tendenz nach C# gehen.

Ich schrieb

Wenn die VCL auf 1.1 aufsetzt und dann 2.0 kommt und man die VCL neu kompiliert:
Wie erzeuge ich dann eine Anwendung für Framework 1.1 ?

Es ist ja wohl nicht praktikabel jedes Mal die ganze VCL (und alles was davon abhängt) neu zu kompilieren

Na ja, in zweieinhalb Wochen kommen zwei Borland Mitarbeiter zu uns ins Haus, die werd ich dann mal fragen.


Für Änderungen oder Verfälschungen an MathiasSimmack wird keinerlei Haftung übernommen :mrgreen:

[nieurig]

Hallo Mabuse,
ich nehme an, dass die Entscheidung für .NET bereits getroffen ist und es nur noch um die Frage der Sprache geht.

Sonst habe ich noch ein Contra. Die Lauffähigkeit des Programmes hängt davon ab, das auf dem Zielrechner das Framework installiert ist - unde wenn nicht ?

Ach ja, wie steht es eigentlich um die Code-Kompatiplität zu Kylix? Ist das dann überhaupt noch möglich?

Viel Erfolg beim Sammeln. Ich werde Deine Liste aufmerksam beobachten, weil mich diese Uberlegungen auch schon länger umtreiben.

Niels

[MaBuSE]

Zitat:

Zitat von nieurig

ich nehme an, dass die Entscheidung für .NET bereits getroffen ist und es nur noch um die Frage der Sprache geht.

Genau :-)

Danke für Deinen Beitrag, habe Punkte in Liste aufgenommen (s.o.)

[ak1]

Pro Delphi 8:

-ein Update auf Delphi 8 ist wehsentlich billiger als ein Neukeuf von visual Studio.NET
-die Datenbankkomponenten sind in Delphi 8 besser
-gewohnte Komponenten wie Rave können ebenfalls in Delphi 8 verwendet werden

[Robert_G]

D8

• Pro ... :?:
  • Bis auf die buntere Komponentenpalette ( :lol: ), buggy ECO und den für mich sinnloses BDP.Net fällt mir nichts ein. :?
  • Wenn man D8 mit #develop vergleicht, punktet es mit seinem ASP.Net designer (den wird #develop wohl so schnell nicht kriegen)
• Kontra:
  • Die wahrscheinlich instabilste und lahmste IDE seit es IDEs gibt.
  • 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)
  • Es is total friemelig in D8 eine Assembly zu verwenden, die zur Laufzeit der IDE geändert wurde. (man muss fast immer die IDE neu starten :( )

Meiner Meinung nach taugt D8 nur etwas um sich GUIs und ASP.Forms zusammenzuklicken. Der wirklich aufwqendige Code ist IMHO in einer in #develop geschriebenen Assembly viiieeel besser aufgehoben. Damit kann er wenigstens ohne 1-3 cholerische Anfälle in einer anderen Sprache weiter verwendet werden. Außerdem muss man in D8 ständig den kompletten Pfad zu einer Klasse tippen. (Ihr kennt sicher System.Windows.Forms.DialogResult.OK ;) )

[mirage228]

Zitat:

Zitat von Robert_G

System.Windows.Forms.DialogResult.OK

Argh, das nervt echt :evil:

mfG
mirage228

[MaBuSE]

Zitat:

Zitat von ak1

ein Update auf Delphi 8 ist wehsentlich billiger als ein Neukeuf von visual Studio.NET

Das trifft nicht ganz zu. Die VS.NET Vollversion ist nicht (oder nicht viel) teurer als ein Update von z.B. Delphi 5 auf Delphi 8

Aber die Folgekosten können höher sein. (Einarbeitungszeit, Portierungen, ...)

Zitat:

Zitat von ak1

-die Datenbankkomponenten sind in Delphi 8 besser

Bin ich nicht ganz Deiner Meinung:
VCL: BDE wird ohne SQL Links ausgeliefert -> nur Zugriff auf Paradox und DBase Tabellen möglich
(BDE ist die selbe wie bei D7, also kann man SQL Links mit Treibern zu Oracle, ... installieren und auch in D8 nutzen. Es müssen dann aber dieBorland Database Compatibly Components installiert werden.)

FCL: Bis auf BDP (Borland Data Provider) gibt’s hier ja das gleiche wie bei allen anderen .net Sprachen.

Borland (John Kaster) schreibt in http://bdn.borland.com/article/0,1410,31939,00.html

...Once a BdpDataAdapter is configured, a DataGrid can be hooked up and its DataSource and DataMember properties set to see design-time data.

Sprich: Wie in der BDE werden bei der BDP die Daten auch im Designer angezeigt.
(Dazu hält die BDP ständig eine offene Datenverbindung.)

Alle anderen Data Provider z.B. ODP (Oracle Data Provider) zeigen nichts.

Diese Eigenschaft von dem BDP klingt eigentlich gut, aber bei VS.NET wird auch was angezeigt. Das macht dort die IDE. Und zwar bei allen Data Providern.
(Danach wird die Verbindung wieder geschlossen und wandert zurück in den Pool)

[Diese Aussage ist von einem Kollegen, ich selbst kenne mich mit VS.NET nicht aus]

Zitat:

Zitat von ak1

-gewohnte Komponenten wie Rave können ebenfalls in Delphi 8 verwendet werden

Ja, ist aber schon als pro in der Liste (VCL)

Vielen Dank für Deinen Beitrag, ich habe die Liste schon aktualisiert.

[MaBuSE]

Zitat:

Zitat von Robert_G

Kontra:
Die wahrscheinlich instabilste und lahmste IDE seit es IDEs gibt.

Ja, leider.

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)

Das sollte aber funktionieren.
Außer man verwendet Delphi spezifische Dinge, die es im .net nicht gibt. (die können ja dann auch nicht funktionieren ;-))
Siehe auch "delphi.net Sonderheft" Seite 54ff (Was darf's sein? Library, Package oder DLL?)

Zitat:

Zitat von Robert_G

Meiner Meinung nach taugt D8 nur etwas um sich GUIs und ASP.Forms zusammenzuklicken. Der wirklich aufwqendige Code ist IMHO in einer in #develop geschriebenen Assembly viiieeel besser aufgehoben. Damit kann er wenigstens ohne 1-3 cholerische Anfälle in einer anderen Sprache weiter verwendet werden.

Das kann und will ich jetzt noch nicht beurteilen. Ich bin ja noch am Erfahrungen sammeln :mrgreen:

Zitat:

Zitat von Robert_G

Außerdem muss man in D8 ständig den kompletten Pfad zu einer Klasse tippen. (Ihr kennt sicher System.Windows.Forms.DialogResult.OK ;) )

Gibt's da nicht die Möglichkeit "default namespaces" festzulegen.

[mirage228]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von Robert_G

Außerdem muss man in D8 ständig den kompletten Pfad zu einer Klasse tippen. (Ihr kennt sicher System.Windows.Forms.DialogResult.OK ;) )

Gibt's da nicht die Möglichkeit "default namespaces" festzulegen.

Ja, ich glaube das heist "Alias" bzw "Aliasen". Das soll funktionieren - wie ich gehört habe, tut es das aber nicht.

mfG
mirage228

[ak1]

nunja das ist ein Problem vieler "junger Leute" ;-), dass sie schnell etwas als nicht funktional abtun, nur weil sie es nicht verstehen oder nachvollziehen können ;-)

P.S. in C# gibt es die namespaces, es würde mich sehr arg wundern wenn das in Delphi 8 nicht geht

[Robert_G]

Zitat:

Zitat von ak1

nunja das ist ein Problem vieler "junger Leute" , dass sie schnell etwas als nicht funktional abtun, nur weil sie es nicht verstehen oder nachvollziehen können

Ich bin kein verzogerner, kleiner Rotzlöffel. ;)

Das Thema D8 polarisiert aber einfach, die einen wollen die bisher einzige .Net-sprache, die nicht von MS kommt verteidigen. Die anderen haben bereits ein paar monate mit D8 zu tun gehabt und bekommen schon fast einen Aortariss wenn sie nur den Splash screen von D8 sehen. ;)

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

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:

Zitat:

Zitat von ak1

die Datenbankkomponenten sind in Delphi 8 besser

Da muss ich was übersehen haben, ich konnte nur den halbfertigen BDP entdecken. (der kann noch nich tmal benannte Parameter !!!)

Nachtrag

Zitat:

P.S. in C# gibt es die namespaces, es würde mich sehr arg wundern wenn das in Delphi 8 nicht geht

Jein...
Natürlich kannst du deinen Assemblies namespaces verpassen (wäre ja auch irgendwie dumm, wenn es nicht ginge), aber die NameSpace aliases, die es laut D8-OH angeblich gibt, gibt's NICHT.

[ak1]

Hallo Robert,

ich glaube dir natürlich, da ich mich mit Delphi 8 zuwenig auseinander gesetzt habe, kann ich dazu auch nicht viel mehr sagen. Ich beschäftige mich derzeit neben der Delphiprogrammiererei auf Arbeit (Delphi 6 Prof) verstärkt mit Java auf Eclipse und evtl. später JBuilder, von daher verfolge ich das Thema .NET nur noch "nebenher".

[MaBuSE]

Zitat:

Zitat von Robert_G

Ich bin kein verzogerner, kleiner Rotzlöffel. ;)

Aber immerhin ein paar Jährchen jünger als ak1 :mrgreen:

@Robert_G Ich schreib am Freitag noch was zu Deinem Beitrag. (Ich muß ja auch irgendwann Feierabend machen :cheers: )

[ak1]

Zitat:

Zitat von MaBuSE

@Robert_G Ich schreib am Freitag noch was zu Deinem Beitrag. (Ich muß ja auch irgendwann Feierabend machen :cheers: )

hmmm verdammt langer Feierabend :-)

[Alexander]

Zitat:

Die Lauffähigkeit des Programmes hängt davon ab, das auf dem Zielrechner das Framework installiert ist - unde wenn nicht ?

Das ist ein Contra-Punkt aller .NET Programme und daher im Prinzip nicht relevant, da es ja nur um ein Vergleich der .NET Sprachen geht.

[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?

[Hansa]

Nein, das hat Lochkarten-Gründe. Das weiß ich von einem echten Guru. :mrgreen: 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. :lol:

[tommie-lie]

Zitat:

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?!? :shock:

Zitat:

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:

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:

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. :lol: 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 :!:

[tommie-lie]

Zitat:

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:

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:

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. :lol:

Die angeblich schlechtere IDE spielt hierbei auch keinerlei Rolle. Ich kann auch mit nem Editor und der Kommandozeile programmieren und compilieren. :mrgreen: 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 :mrgreen:

[tommie-lie]

Zitat:

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. :lol:

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:

Zitat von Hansa

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

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:

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:

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 :roll:

Zitat:

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

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.

[tommie-lie]

Zitat:

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.

[MathiasSimmack]

Zitat:

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:

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:

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

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 ... :mrgreen:), dann erhält jeder Interessent eine Liste mit besagten Vor- und Nachteilen und kann für sich selbst entscheiden, mit welcher Sprache er arbeitet.

[tommie-lie]

Zitat:

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:

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:

Zitat von MathiasSimmack

Zitat:

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:

Zitat von MathiasSimmack

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

Code:

IrgendeineCFunktion();

Einige namentlich bekannte Delphi-Programmierer (;)) machen das ja auch. Na ja ...

Wer macht denn sowas? :mrgreen:
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.