Jetzt liegt das Update-Angebot auf dem Tisch!

[Markus Rautenberg]

> ("warum denn zum Schmidtchen gehn, wenn man zum Schmidt gehenkann").

Wenn ich Wein kaufe, gehe ich lieber zu Schmidtchen's Weinhandlung als zu Schmidt's Supermarkt.
Ersterer ist sachkompetent, liefert hohe Qualität und kann mich gut beraten - wäre es nicht so, würde er sich nicht lange halten.
Für letzteren läuft der Weinverkauf unter Sonstiges, die Beratung beschränkt sich auf eine ungefähre Richtungsangabe, wo das Weinregal oder -Palette steht und die Qualität.. naja, ich würd's keinem anbieten, mit dem ich befreundet bleiben möchte.
Es soll aber tatsächlich welche geben, die den 1l Pappkarton für 2.50 für'n Schnäppchen halten.

> In ein paar Jahren dürfte Delphi mehr oder minder vergessen sein.

Diese frohe Kunde wird auch schon seit Jahren verbreitet - wahrer wurde sie dadurch auch nicht. Wahrscheinlich wird sie auch dann noch zu hören sein, wenn Microsoft .NET zugunsten des "next big thing" aufgegeben hat.

Der Appell, C#-Bücher zu schreiben scheint mir unnötig, da wahrscheinlich bereits .NET-Bücher in Arbeit sind. Einen Mangel an C#- oder .NET-Büchern wirds es eh nicht geben, da wahrscheinlich zur Zeit jeder Fachautor an entsprechenden Büchern sitzt - ein Teich mit vielen Fischen.
Die treue Delphi-Entwicklergemeinde wird den Autoren, die noch Delphi-Bücher schreiben umso dankbarer sein

[Jürgen Hofmann]

"Ersterer ist sachkompetent, liefert hohe Qualität...": dazu kann ich nur sagen: siehe Delphi 6 und die diversen Reparaturversuche dazu!!
"Die treue Delphi-Entwicklergemeinde wird den Autoren, die noch Delphi-Bücher schreiben umso dankbarer sein."
Eigentlich dürfte die vorstehende Message von Andreas Kosch doch angekommen sein: die Sprache ist wurscht. Ob Pascal oder Chinesisch spielt keine Rolle. Also wozu noch etwas pflegen, was gegenüber anderen Sprachen keine Vorteile hat. Wir wollen doch wohl alle nicht vorzugsweise Programmierkunststückchen fabrizieren, sondern (hoffentlich) Probleme (unserer Kunden; am besten bezahlterweise)lösen.
Und die Sache mit dem "next big thing" ist doch schlichtweg Polemik. Visual Studio ist seit Jahren auf dem Markt (ob nun mit VB oder C++), ist definitiv Marktführer mit Entwicklerzahlen, von denen Borland nur träumen kann. Egal was man darüber denkt: "rein in die Kartoffel, raus aus den Kartoffeln" kann man Microsoft nun wirklich nicht vorwerfen (bei aller Häme, die eingefleischte Borlander gerne über die verhassten Monopolisten ausgiesen). Ich würde vorschlagen, dass wir das Beste daraus machen und uns die Polemik sparen. Also weiter so, lieber Andreas Kosch

[Jürgen Hofmann]

Herr Kosch, könnten Sie noch die "gravierenden Vorteile", die VB gegenüber C# hat, noch etwas näher erläutern

[Andreas Kosch]

Hallo,

zuerst eine Vorbemerkung: Das einzige wirkliche Problem an VB.NET ist das "miese soziale Image" von Visual Basic, da dieses damals durchaus wohlbegründete Image auch 1:1 auf VB.NET übertragen wird und daher nur wenige offiziell etwas mit dieser Sprache zu tun haben wollen :-)

Zur Zeit ist es doch so, dass in der Regel eine .NET-Anwendung auf "alte" COM-Sachen zurückgreifen muss, da Microsoft noch nicht alle Bestandteile in die .NET-Welt migriert hat. Nehmen wir zum Beispiel den Bereich <i>ADO MD</i> - dafür gibt es im Gegensatz zu ADO noch keine .NET-Klassen. Dies bedeutet, dass die eigene .NET-Anwendung über COM Interop auf die COM-Objekte von ADO MD zurückgreifen muss. Diese COM-Objekte verwenden jedoch intensiv optionale Parameter bei den Interface-Methoden, so dass man mit C# in Schwierigkeiten kommt. Da C# im Gegensatz zu VB.NET die <i>späte Bindung</i> nicht direkt über die Sprache unterstützt, muss ein C#-Programm an dieser Stelle zwangsläufig sehr viel aufwendiger sein:

a) C#: Späte Bindung durch explizite Invoke-Aufrufe, nachdem alle Zutaten einzeln definiert werden <br>
b) VB.NET: Methode ohne Parameter "einfach so" aufrufen (wie bei VB oder Delphi mit dem OleVariant-Umwandlungstrick)

Diese Unterschiede führen dazu, dass in diesem konkreten Fall die Anzahl der einzutippenden Programmzeilen bei der C#-Anwendung ca. das 5..10-fache höher liegen als bei VB.NET - und das ist in meinen Augen ein gravierender Unterschied (zumal man beim Invoke-Aufruf über C# die Zutaten einzeln heraussuchen bzw. experimentiell ermitteln muss). Bei VB.NET legt nur ein Mausklick in den Projektoptionen fest, ob dieser "schmutzige" Weg der späten Bindung toleriert wird oder nicht

[Michael Witzsche]

Da muss ich auch noch was dazu sagen. Aber ohne viel Worte ........
Es reicht !!!!!!!! Ich werfe noch einmal einen Blick auf Delphi.NET, und wenn das auch so eine schreckliche Geschichte wird, dann sieht Borland von uns keinen müden Cent mehr !!!!

[ake]

hallo,

@jürgen hoffman: erst mal abwarten bis zwei wirklich fertige dotnet ide's da sind die man dann vergleichen kann. wenn das so ausfällt wie damals der vergleich: visual basic versus delphi bzw. "visual" C++ versus delphi, dann hat eine borland dotnet-version durchaus ihre berechtigung! wie gesagt, auch wenn es nur um die reinen ide's geht. und ms verschenkt seine updates mit sicherheit auch nicht und die bugs finden sich nun mal überwall, wenn man nur intensiv damit arbeitet. ich lass dass ganze mal auf mich zu kommen und entscheide dann...

mfg
ak