Hallo Thomas,

> ok, ich kapituliere,
> da sind wieder dieselben Uneinsichtigen ...

Ich finds köstlich.
Da beharrt einer stur auf seiner Meinung, die ihm andere schon zig-mal
widerlegt haben und nennt andere dann uneinsichtig.

> Nur dies zum Abschluss:
> warum wohl tun sich so viele VB6 User so schwer mit allem rund um .NET?

Woher hast Du denn die Kenntnis, dass sich "so viele VB6 User so schwer" mit
allem rund um .net tun?
Wenn ich mal von kommerziell arbeitenden Programmierern in meinem Umfeld
ausgehe, dann haben die mit dieser Technik durchwegs keine Probleme. Mit
..net wurde nichts erfunden, was ein ordentlich ausgebildeter Programmierer
nicht verstehen würde. In den vergangenen 40 Jahren habe ich wirklich schon
bedeutendere Änderungen miterlebt und deshalb hat sich die Erde auch nicht
rückwärts gedreht.

Wenn Hobbyisten ein solches Problem haben, ist das sicherlich nicht
verwunderlich, weil es da vermutlich vielfach mehr davon gibt, die mit
VB/VB.net spielen, als solche die das mit C# tun. Deswegen aber zu glauben,
VB oder VB.net seien nur deshalb keine für kommerzielle Softwareentwicklung
geeigneten Programmsprachen ist schlicht und einfach unlogisch.

> Weil sie in einer völlig isolierten, rosaroten Welt lebten!

Woher weisst Du das denn, wenn Du doch ausser C# gar nichts anderes gelten
lässt und wie es den Anschein hat auch gar nichts anderes wirklich fundiert
kennst?

> Diese versucht man nun immer noch verbissen zu retten,
> und schlimmer, wiederum neue Mauern aufzubauen.

Das scheinen aber offenbar Mauern zu sein, die man von VB-Seite aus gar
nicht bemerkt oder zumindest mit nur einem kleinen Hopser leicht überwinden
kann, die aber Deinen Äusserungen nach für C#-Programmierer vollkommen
unüberwindlich sind.
Wer hat denn dann also ein Problem?

>
> Beim nächsten Technologie-Wechsel
> (oder schon nur: neues Projekt/Stelle mit Vorgabe: C#)
> werden es wiederum diese sein,
> die am lautesten über inkompatiblen Code heulen und jammern,
> während alle anderen elegant in kürzester Zeit auf neue Innovationen
wechseln ...
>
> Ich werde kein Bedauern haben.

Den Kommentar dazu verkneife ich mir mal.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

Hallo Peter,

> Bei einer Reihe von Deinen und von Thomas Statements habe ich schon den
> Eindruck, dass es nur einen Hintergrund gibt: "VB ist schlecht, C# ist
> gut".

wenn ich VB.NET für schlecht hielte, hätte ich nicht das VB.NET Codebook
geschrieben ;-)

Ich beobachte nur mit großer Sorge, in welche Richtung sich VB.NET
weiterentwickelt. Die "rosa Welt", von der Thomas gesprochen hat, gibt es
wirklich. Das habe ich schon oft in Seminaren feststellen müssen. Und viele
finden ohne fremde Hilfe da nicht heraus.

> Ich habe eine nun wirklich hinreichend lange Berufspraxis, um mir das
> Urteil
> erlauben zu dürfen, dass solche Aussagen schlichter Unsinn sind.

Welche Aussagen? "VB ist schlecht, C# ist gut"? Das habe ich nicht
behauptet. In dieser NG wird traditionell von vielen anderen eher das
Gegenteil behauptet.

> Für mindestens ebenso unsinnig halte ich es z.B. auf OO-Dogmen
> herumzureiten
> und sich dabei nicht darum zu kümmern, ob es in bestimmten (gar nicht so
> seltenen Fällen) eben auch andere, weniger OO-konforme, aber eben
> sachgerechtere Lösungen gibt.

Beispiel?
OO kann man doch so oder so sehen. Auch mit C# kann man in einem Projekt mit
einer einzigen Klasse auskommen und mittels statischer Felder und Methoden
prozedural programmieren. Das Framework ist aber nun mal objektorientiert,
daran ändert auch My u.ä. nicht.

>> Aber es ist durchaus
>> wichtig, auch einmal andere Meinungen zu lesen und sich ein Bild von den
>> Bedürfnissen anderer Programmierer zu machen.
>
> Das kann ich nur voll und ganz unterstreichen.
> Aber ich möchte auch darauf hinweisen, dass das keine Einbahnstraße sein
> sollte.

Ist es auch nicht. Aus vielen Diskussionen vor 2-3 Jahren hat sich meine
Sichtweise insbesondere von VB.NET auch geändert. Das heißt aber nicht, dass
ich alles aus VB.NET akzeptiere.

> Bei einigen Beiträgen drängt sich eben der Eindruck auf, dass hier jemand
> alles nur aus seiner begrenzten C#-Sicht beleuchtet und alles andere schon
> deshalb für unzulänglich hält, weil es nicht C# ist.

Der Eindruck ergibt sich vermutlich zwangsläufig daraus, dass Thomas und ich
die nahezu einzigen sind, die es wagen, in dieser Newsgroup auch etwas gegen
VB.NET zu schreiben. So negativ, wie es vielleicht manchmal klingt, ist
meine Einstellung zu VB.NET aber nicht. Oft ist es auch einfach nur eine
Reaktion auf die Gegenbehauptung, mit VB.NET sei alles viel einfacher als
mit C#.

>Ob C#, VB.net oder
> welche sonstige Sprache ist keine Glaubensfrage, sondern, zumindest im
> Bereich kommerzieller Softwareentwicklung, eine Frage der
> Zweckmässigkeiten.
> Für jede Aufgabe das richtige Werkzeug, ist eine Maxime, die nicht nur in
> unserer Branche gilt. Und es ist nun eben mal nicht möglich, ein Werkzeug
> als gut oder schlecht einzustufen, wenn man nicht genau weiss, was damit
> eigentlich gemacht werden soll.
Letzteres ist richtig, für die Entscheidung zwischen VB.NET oder C# aber
meist irrelevant. Es gibt eigentlich nur zwei Anwendungsbereiche, in denen
wirkliche Vor- und Nachteile erkennbar sind:
- Zugriff auf COM-Komponenten wie Word, Excel, Outlook und so weiter. Hier
hat VB die Nase vorn, da es syntaktisch besser zu den VBA-Aufrufen passt.
- Unsafe Code mit Zeigern, z.B. für schnelle Bildalgorithmen. Das ist mit
VB.NET nicht zu machen.

Bestimmt mehr als 99% der Programmieraufgaben lassen sich aber sowohl mit C#
als auch mit VB.NET erledigen. Die Wahl der Programmiersprache ist dann doch
Unternehmensphilosophie, Geschmacks- oder Glaubensfrage oder eine Frage der
Vorkenntnisse. Produktive Unterschiede gibt es nicht. Ich kenne beide Welten
gut genug, um sagen zu können, dass man mit beiden etwa gleich schnell zum
Ziel kommt.

> ... Bei genauerem Hinterfragen habe ich immer festgestellt, dass sich
> solche Dogmatiker mit anderen Sprachen und anderen Aufgabenstellungen
> nicht
> wirklich gründlich auseinandergesetzt haben.

Schau auf meine Website. Ich kann zwar nicht mit 40 Jahren Berufspraxis
aufwarten, sondern beschäftige mich erst seit 1978 mit der Programmierung.
Aber Programmiersprachen habe ich schon etliche erlernt und verwendet. Basic
war übrigens damals eine der ersten. VB benutze ich seit Version 3 1995,
also inzwischen über 10 Jahre. Projekterfahrung habe ich damit reichlich
gesammelt. Unterschätze meine Detailkenntnisse von VB/VB.NET besser nicht.
Ich kenne die Sprachen durchaus sehr genau.

> Jemand der kommerziell Software in VB.net entwickelt und sein "Handwerk"
> dazu entsprechend gelernt hat, wird keine Probleme haben, ein in C# oder
> auch einer anderen Sprache geschriebenes Programm nachzuvollziehen. Er
> wird
> es möglicherweise nicht so flüssig lesen, wie ein in "seiner" Sprache
> geschriebenes, aber es wäre auch reichlich unlogisch, so etwas zu
> erwarten.

Na, da sind wir uns ja einig. Leider zeigen die Beiträge in den Newsgroups
tagtäglich, dass das offenbar nicht so ist.

> ... Wenn aber erst mal die Entscheidung gefallen ist, die
> Sprache XY wird zur Lösung der Aufgabe verwendet, dann werden auch die von
> dieser Sprache gebotenen Möglichkeiten genutzt, denn diese waren ja der
> Grund, sich für eben diese Sprache für diese Aufgabe zu entscheiden.
> Irgendwelche Sprachfeatures zu meiden, nur weil es die in einer anderen
> Sprache so nicht gibt oder irgendeiner Lehre oder einem unsinnigen Dogma
> widersprechen, hat nichts mit produktivem Arbeiten zu tun.

Du hast unsere Bedenken nicht wirklich verstanden. Wenn Herfried begeistert
My.XYZ benutzt, ist nichts dagegen einzuwenden. Bei Herfried bin ich davon
überzeugt, dass er sich mit .NET auskennt und so etwas wie My als nette
Ergänzung empfindet. Er wird aber keine Probleme haben, bei Bedarf eine
benötigte Klasse im Framework zu finden und zu verwenden.

Für jemanden, der aus VB6 herüberwechselt, und sich bislang nicht mit OOP
und Klassenbibliotheken beschäftigt hat, beginnt die Lernkurve in .NET sehr
steil. Mit den verschiedenen Features von VB.NET wird er dann aber in die
von Thomas genannte "rosarote VB-Welt" eingeführt. Dadurch ist die Lernkurve
sehr sehr flach, denn vieles der VB6-Kenntnisse kann übernommen werden. Ein
Verständnis von (VB).NET wird dabei aber überhaupt nicht vermittelt. Und
wenn dann My & Co nicht mehr ausreichen, dann ist die Lernkurve auf einmal
sehr steil.

Mich erinnert das an den Chemieunterricht in der Schule. Nachdem wir ein
Jahr lang ein einfaches Modell gelernt hatten, kam der Lehrer dann
irgendwann mit dem Bohrschen Atommodell rüber und alles bis dahin gelernte
wurde über den Haufen geworfen. So wird es jemandem ergehen, wenn er die
rosa Welt verlassen will.

>> Man muss die typischen Vorgehensweisen und den Umgang mit dem
>> Framework beherrschen. Wer das kann, wird auch Beispiele aus anderen
>> Sprachen verstehen.
>
> Ob einer das kann oder nicht, entscheidet aber nicht, ob er in C# oder in
> VB.net oder sonstwas programmiert. Leute die ihr Handwerk nicht gelernt
> haben, findet man überall. Das beschränkt sich nun wirklich nicht auf eine
> bestimmte Programmiersprache.

Habe ich das behauptet?

> Wenn man aber mit solchen Feinheiten nicht vertraut ist, sollte man eine
> andere Sprache aber nicht pauschal ablehnen. Auch wenn ich mich
> wiederhole:
> Für jede Arbeit das richtige Werkzeug. Erst mal muss ich wissen, welche
> Arbeit eigentlich erledigt werden soll und erst danach kann ich
> entscheiden,
> welches Werkzeug sich dazu am besten eignet.

s.o.

>> Der Code der
>> meisten Beispiele besteht aus trivialster Syntax von Klassen, Methoden,
>> Variablendefinitionen, Verzweigungen und Schleifen. Es kann mir keiner
>> weismachen, dass ein engagierter VB.NET-Programmierer solchen Code nicht
>> nachvollziehen kann.
>
> Will Dir das denn irgendjemand weismachen?

Ja! Lies NG-Beiträge. "iii- C#-Code" oder "iii-VB-Code" liest man ständig.

> Ich habe sowas jedenfalls hier von Leuten die bevorzugt mit VB bzw. VB.net
> arbeiten noch nicht gelesen. Ich lese aber sehr häufig von Leuten, die C#
> offenbar für die einzig mögliche Programmiersprache halten, dass jemand
> der
> VB oder VB.net nutzt in keinem Fall wüsste, was professionelle
> Programmierung bedeutet. Solche Statements lassen bei mir schon immer ein
> gewisses Schmunzeln aufkommen.

Habe ich das geschrieben? Quelle? Ich reagiere zwar manchmal auf etwas zu
gereizt, aber zu solchen Aussagen lasse ich mich eigentlich nicht hinreißen.
Als alter VB-Programmierer würde ich mich dann doch selbst treffen.

> Na ich lese mindestens ebenso oft, dass sich jemand beklagt, dass er
> diesen
> oder jenen Code nur in VB.net gefunden hätte.

Ja, sagte ich bereits. Das ist genauso "beschränkt". Ein C#-Programmierer
kann auch ohne Mühe typische VB-Syntax verstehen, wenn er denn will.
Allerdings wird das mit Altlasten wie Filecopy, Kill und neuen Spezialitäten
wie My immer schwieriger.

>> Ein VB.NET-Programmierer muss nicht seine
>> VB.NET-Programme in C# umsetzen können, da gebe ich Dir Recht, aber er
>> sollte C#-Beispiele weitestgehend lesen können.
>
> Die Leute in meinem Umfeld, die täglich mit VB, VB.net und auch einer
> ganzen
> Reihe anderer Sprachen arbeiten können das ausnahmslos.

Dann hast Du ein gutes Umfeld und die richtigen Leute eingestellt. Glaube
mir, das ist nicht selbstverständlich.

> Bei einigen Leuten, die sich mit VB oder VB.net offenbar auf keinen Fall
> anfreunden wollen, habe ich aber den Eindruck dass es für die offenbar ein
> sehr grosses Problem und scheinbar doch kompliziert ist, ein
> VB/VB.net-Programm zu lesen. Anders kann ich mir solche Diskussionen sonst
> nicht erklären.

Ja, nur weiß ich jetzt nicht genau, wen Du meinst. Ich hoffe nicht mich.

>> Somit wird jeder Programmierer früher oder später an
>> einen Punkt kommen, wo er mit seinem Wissen nicht mehr weiterkommt. Dann
>> muss er recherchieren, um eine Lösung zu finden.
>
> Die wird er aber erst mal bei anderen erfahrenen Programmierern suchen,
> die
> vor allem die Sprache beherrschen, mit welcher er auch arbeitet.

Nun, schön, wenn in Deiner Firma ein Erfahrungsaustausch zwischen den
Entwicklern möglich ist. Viele arbeiten aber allein und sind auf Medien wie
das Internet angewiesen. Oder es gibt noch keine Qualifikationen der
Mitarbeiter, weil sich gerade erst alle in die neue Welt einarbeiten.

>> Das .NET-Framework ist noch längst nicht vollständig.
>
> Das wird es wohl auch nie werden.

Ich wusste, dass das kommt, widerspreche dem aber auch nicht :-)

> Ich habe nicht die geringsten Probleme damit, mit APi-Funktionen zu
> arbeiten, wenn das Framework nichts Passendes bietet. Wo sollte man da
> eine
> Grenze setzen?
> Ich denke, wer nicht bereit ist, sich mit den Betriebssystemen, für die er
> programmiert, vertraut zu machen, der sollte besser was anderes tun als
> eben
> gerade programmieren zu wollen.

Das Problem ist nur, dass hier das Rad wieder mehrfach erfunden wird.
Wieviel tausend Umsetzungen alleine der SHFileoperation-Kiste gibt es wohl
inzwischen? Und wieviele Fehler werden dabei gemacht? Bedenke, dass für eine
Reihe von API-Funktionen fundierte C- (nicht C#) notwendig sind. Wenn ich
allein in dieser NG schon sehe, wie oft bei API-Funktionen die falschen
Datentypen verwendet werden (z.B. Long statt Integer), dann müssen doch bei
MS die Alarmglocken läuten. SHFileOperation bietet auch so einige
Fallstricke. Es muss somit bei MS mit hoher Priorität auch daran gearbeitet
werden, durch Erweiterung des Frameworks den Bedarf an API-Funktionen
drastisch zu reduzieren. Schon allein aus Gründen der Code-Sicherheit halte
ich das für unumgänglich.

So, jetzt habe ich wieder wesentlich mehr Zeit für diesen Beitrag
aufgebracht, als ich wollte. Für heute ist daher erstmal Schluss.

Gruß
Joachim

Hallo Joachim,

> OO kann man doch so oder so sehen. Auch mit C# kann man in einem Projekt
> mit einer einzigen Klasse auskommen und mittels statischer Felder und
> Methoden prozedural programmieren. Das Framework ist aber nun mal
> objektorientiert, daran ändert auch My u.ä. nicht.

Wobei My ja durchaus eine objektorientierungsgemäße Form hat...

> Der Eindruck ergibt sich vermutlich zwangsläufig daraus, dass Thomas und
> ich die nahezu einzigen sind, die es wagen, in dieser Newsgroup auch
> etwas gegen VB.NET zu schreiben.

Vielleicht hat das weniger etwas mit "wagen" zu tun, als eher damit, dass
wir "Uralt"-VB'ler aufgrund der schon früheren VB-Unzulänglichkeiten wohl
einfach wesentlich ...hm... toleranter gegenüber dem jetzigen VB.NET sind.

> So negativ, wie es vielleicht manchmal klingt, ist meine Einstellung zu
> VB.NET aber nicht.

Auch wenn Du Dich im vorhergehenden Satz in eine Reihe mit Thomas stellst:
Wirklich auf einer Linie liegt Ihr m.E. nicht wirklich...
;-)

> Bestimmt mehr als 99% der Programmieraufgaben lassen sich aber sowohl mit
> C# als auch mit VB.NET erledigen. Die Wahl der Programmiersprache ist
> dann doch Unternehmensphilosophie, Geschmacks- oder Glaubensfrage oder
> eine Frage der Vorkenntnisse. Produktive Unterschiede gibt es nicht. Ich
> kenne beide Welten gut genug, um sagen zu können, dass man mit beiden
> etwa gleich schnell zum Ziel kommt.

Wenn man beide Welten gleich gut kennt, mag das derzeit durchaus noch so
sein. Microsoft hat allerdings mehrfach verlauten lassen, VB stärker in
Richtung RAD zu forcieren. My ist da sicherlich nur ein erster (und
tatsächlich etwas kümmerlicher) Ansatz.

Ausgehend von der .NET-Architektur und den gleichen formalen Grundprinzipen
der Syntax (lediglich die Notation unterscheidet sich ja letzten Endes)
kann man auch beide Welten gleich gut kennen und können. Grundlegende
Präferenzen sind da allenfalls eher der Gewohnheit (C, Java -> C#, VB
Classic -> VB.NET) zuzuschreiben, vermutlich auch hinsichtlich der
Notation, aber, in VB.NET, auch hinsichtlich der MVB-Bibliothek, die die
Gewohn(t)heit zulässt (und ehrlich gesagt, ohne *wirklich ersthafte*
Nachteile bezüglich der Arbeitsresultate!).

>> ... Wenn aber erst mal die Entscheidung gefallen ist, die
>> Sprache XY wird zur Lösung der Aufgabe verwendet, dann werden auch die
>> von
>> dieser Sprache gebotenen Möglichkeiten genutzt, denn diese waren ja der
>> Grund, sich für eben diese Sprache für diese Aufgabe zu entscheiden.
>> Irgendwelche Sprachfeatures zu meiden, nur weil es die in einer anderen
>> Sprache so nicht gibt oder irgendeiner Lehre oder einem unsinnigen Dogma
>> widersprechen, hat nichts mit produktivem Arbeiten zu tun.

> Du hast unsere Bedenken nicht wirklich verstanden. Wenn Herfried
> begeistert My.XYZ benutzt, ist nichts dagegen einzuwenden. Bei Herfried
> bin ich davon überzeugt, dass er sich mit .NET auskennt und so etwas wie
> My als nette Ergänzung empfindet. Er wird aber keine Probleme haben, bei
> Bedarf eine benötigte Klasse im Framework zu finden und zu verwenden.
>
> Für jemanden, der aus VB6 herüberwechselt, und sich bislang nicht mit OOP
> und Klassenbibliotheken beschäftigt hat, beginnt die Lernkurve in .NET
> sehr steil. Mit den verschiedenen Features von VB.NET wird er dann aber
> in die von Thomas genannte "rosarote VB-Welt" eingeführt. Dadurch ist die
> Lernkurve sehr sehr flach, denn vieles der VB6-Kenntnisse kann übernommen
> werden. Ein Verständnis von (VB).NET wird dabei aber überhaupt nicht
> vermittelt. Und wenn dann My & Co nicht mehr ausreichen, dann ist die
> Lernkurve auf einmal sehr steil.

Und? Macht das was aus? Es ist eben die ursprüngliche Basic-Philosophie,
schnell zu Erfolgen und zu Erfolgserlebnissen zu kommen - ohne steile
Lernkurve zu Anfang. Und auch wenn so nicht in der ursprünglichen
Basic-Philosophie verankert, haben nahezu alle jüngeren
Basic-Implementierungen spätere beliebig steile Lernkurven nach Bedarf
ermöglicht. Auch in VB Classic konnte man schon nahezu alles machen, wenn
man wollte. Der Unterschied in VB.NET ist nur der, dass man sich nicht mehr
in "fremden" Welten wie API- und COM-"Tricksereien" zu bewegen braucht,
sondern sich der spätere nach Bedarf wachsende Lerneifer zum größten Teil
inhärent auf die .NET-Welt beschränken kann.

> Mich erinnert das an den Chemieunterricht in der Schule. Nachdem wir ein
> Jahr lang ein einfaches Modell gelernt hatten, kam der Lehrer dann
> irgendwann mit dem Bohrschen Atommodell rüber und alles bis dahin
> gelernte wurde über den Haufen geworfen. So wird es jemandem ergehen,
> wenn er die rosa Welt verlassen will.

Ich würde da eher ein anderes "Schul"-Beispiel anführen: Der
Standard-Physik-Unterricht beschränkt sich etwa in der Mechanik im
wesentlichen auf die Newton'sche Physik. Und diese reicht völlig dazu aus,
spätere Ingenieure Maschinen und Bauwerke für den praktischen Bedarf
entwickeln zu lassen. Doch das, was hinter der "rosa Welt" der
Newton'schen Mechanik steckt, nämlich Relativitätstheorie und
Quantenmechanik, braucht's da nur in seltenen Grenzfällen.

Ich verstehe die eigentliche Problematik, die Du meinst, sehr wohl. Sie
liegt aber weniger in der Reduzierung des VB-Werkzeugkastens auf eine "rosa
Welt", als in dem unzureichenden Wissen vieler Programmier-Einsteiger (das
gilt für alle Sprachen) zu den Grundlagen dessen, was sie da eigentlich
programmieren. Grob vereinfacht und überzeichnet gesagt: Ein Programmierer,
der etwa ins Datei-System eingreift, müsste eigentlich zuvor das Wissen
erworben haben, das auch einer Admin-Qualifizierung zugrunde liegt.

An diesem Problem ändert aber auch tiefgehende Kenntnis des Framework
nichts. Eher im Gegenteil - je mehr Details der Unbedarfte anpackt, um so
mehr Mist baut er in der Regel. Dies hat sich auch schon in VB Classic
gezeigt, wenn sich so jemand ans API-Eingemachte herangemacht hat.

Noch als Beispiel bezüglich Dateisystem: Viele Entwickler wissen (immer
noch) nicht, wozu die Ordnerhierarchie von "Dokumente und Einstellungen"
gedacht ist und wie sie fach- und sachgerecht zu nutzen ist. Daran beißen
weder die Mäuse "VB-Simplifizierung" noch "Hardcore-Framework" einen Faden
ab.

Was ich in diesem Zusammenhang sehe, und an anderer Stelle in diesem Thread
auch schon als Mangel in VB.NET anzumerken "gewagt" (s.o. ...)habe: In
dieser Hinsicht müssten VB.NET, um dem RAD-Anspruch gerechter zu werden,
oder gar das Framework fix eingebaute Lösungen präsentieren.

>>> Der Code der
>>> meisten Beispiele besteht aus trivialster Syntax von Klassen, Methoden,
>>> Variablendefinitionen, Verzweigungen und Schleifen. Es kann mir keiner
>>> weismachen, dass ein engagierter VB.NET-Programmierer solchen Code
>>> nicht
>>> nachvollziehen kann.

>> Will Dir das denn irgendjemand weismachen?

> Ja! Lies NG-Beiträge. "iii- C#-Code" oder "iii-VB-Code" liest man
> ständig.

Eben - das (be)trifft halt beide Seiten. In dieser Hinsicht bequemliche
Programmierer gibt's eben hier wie dort. Und in beiden Welten gibt's eben
Konstrukte, die es in der anderen Welt überhaupt nicht gibt.

>> Na ich lese mindestens ebenso oft, dass sich jemand beklagt, dass er
>> diesen
>> oder jenen Code nur in VB.net gefunden hätte.
>
> Ja, sagte ich bereits. Das ist genauso "beschränkt". Ein C#-Programmierer
> kann auch ohne Mühe typische VB-Syntax verstehen, wenn er denn will.
> Allerdings wird das mit Altlasten wie Filecopy, Kill und neuen
> Spezialitäten wie My immer schwieriger.

Aber immer noch bedeutend leichter, als etwa in Eiffel.NET oder COBOL.NET
geschriebenen Code zu lesen...
;-)


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

Hallo Joachim

> Der Eindruck ergibt sich vermutlich zwangsläufig daraus, dass Thomas und ich
> die nahezu einzigen sind, die es wagen, in dieser Newsgroup auch etwas gegen
> VB.NET zu schreiben.


ich möchte nur klarstellen:
Ich habe _nie_ etwas gegen VB.NET insgesamt geschrieben.

Nur gegen die absolut unnötigen, lächerlichen Zusätze dazu,
die auf falschen Kundendruck hin übernommen/aufgenommen wurden:
VB6-Fn-Altlasten und die My-Krücke.


Zur Untermauerung hier nochmals
(Peter Götz, jetzt gut mitlesen!)



'My' - Chat:

http://msdn.microsoft.com/chats/tran...405_dn_my.aspx

Q: don't you think developers (VB6 users) will be confused if they have to understand why there are
e.g. redundant VB6:MkDir VB2005:My.Computer.FileSystem.CreateDirectory
if .NET has the official Directory.CreateDirectory ?


Antwort von Tyler Whitney [MS], development lead 'My' feature:

A: The problem is that many VB6 customers never would find Directory.CreateDirectory ;-)
And our message is that Directory.CreateDirectory is what we end up calling anyway.
We just make is easy to find. As for the VB6:MkDir, that is just for backwards compat.
There is a problem having the new world and the old,
but we found an even worse problem during user studies that many people couldn't find
the new functionality at all.
So we took the bet to make it easy to find some of the common things.

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
>> Bei einer Reihe von Deinen und von Thomas Statements habe ich schon den
>> Eindruck, dass es nur einen Hintergrund gibt: "VB ist schlecht, C# ist
>> gut".
>
> wenn ich VB.NET für schlecht hielte, hätte ich nicht das VB.NET Codebook
> geschrieben ;-)
>
> Ich beobachte nur mit großer Sorge, in welche Richtung sich VB.NET
> weiterentwickelt. Die "rosa Welt", von der Thomas gesprochen hat, gibt es
> wirklich. Das habe ich schon oft in Seminaren feststellen müssen. Und
> viele finden ohne fremde Hilfe da nicht heraus.

Das Rosa-Welt-Phänomen gibt es wohl bei jeder
Programmiersprache/Technologie, wie einige Beiträge in diesem Thread zeigen.
Auch ich habe gewisse Sorgen, was die Entwicklung von VB.NET, aber auch .NET
als Ganzes betrifft. In Bezug auf .NET habe ich diese ja mehrfach geäussert,
jene mit VB.NET-Bezug äussere ich bevorzugt direkt im Kontakt mit Microsoft.

>> Für mindestens ebenso unsinnig halte ich es z.B. auf OO-Dogmen
>> herumzureiten
>> und sich dabei nicht darum zu kümmern, ob es in bestimmten (gar nicht so
>> seltenen Fällen) eben auch andere, weniger OO-konforme, aber eben
>> sachgerechtere Lösungen gibt.
>
> Beispiel?
> OO kann man doch so oder so sehen. Auch mit C# kann man in einem Projekt
> mit einer einzigen Klasse auskommen und mittels statischer Felder und
> Methoden prozedural programmieren.

Trotzdem hat VB.NET mit Modulen ein ausdrucksstäkeres Sprachmittel, nicht
zuletzt aufgrund der prozeduralen Tradition von BASIC aus dem Hause
Microsoft.

> Das Framework ist aber nun mal objektorientiert, daran ändert auch My u.ä.
> nicht.

Das ist doch vollkommen egal. Wie einige Programmiersprachen auf Basis von
..NET (und dessen Klassenbibliothek) zeigen, lassen sich auch wunderschön
rein prozedurale Programmiersprachen auf Basis von .NET realisieren. Ideal
wären natürlich massstabsgetreue Nachbildungen häufig benutzter älterer
Programmiersprachen und Bibliotheken auf Basis von .NET, um
Codekompatibilität zu gewährleisten, aber trotzdem das Tor der
Interoperabilität zu öffnen. Aber ich sehe, ich schweife ab.

'My' bildet recht sauber als Objektmodell die Entitäten eines Computers bzw.
einer Anwendung nach, eben in einer intuitiveren Form als das .NET
Framework, da die Anordnung der Funktionalität jener folgt, wie sie in der
Praxis vorzufinden ist.

>> Bei einigen Beiträgen drängt sich eben der Eindruck auf, dass hier jemand
>> alles nur aus seiner begrenzten C#-Sicht beleuchtet und alles andere
>> schon
>> deshalb für unzulänglich hält, weil es nicht C# ist.
>
> Der Eindruck ergibt sich vermutlich zwangsläufig daraus, dass Thomas und
> ich die nahezu einzigen sind, die es wagen, in dieser Newsgroup auch etwas
> gegen VB.NET zu schreiben. So negativ, wie es vielleicht manchmal klingt,
> ist meine Einstellung zu VB.NET aber nicht. Oft ist es auch einfach nur
> eine Reaktion auf die Gegenbehauptung, mit VB.NET sei alles viel einfacher
> als mit C#.

Im Falle von 'My' zu unterstellen, dass alles komplizierter wird, wie das in
dieser Gruppe getan wird, ist doch sicher nicht dienlich. Alles hat Vor- und
Nachteile, aber eine Bewertung kann man nur abgeben, wenn man die einzelnen
Merkmale für sich bewertet, und keinesfalls, indem man Benutzer, die diese
Merkmale nützlich finden, diffamiert. Diese Kritik will ich nicht an dich
gerichtet wissen.

> [...]
> Bestimmt mehr als 99% der Programmieraufgaben lassen sich aber sowohl mit
> C# als auch mit VB.NET erledigen. Die Wahl der Programmiersprache ist dann
> doch Unternehmensphilosophie, Geschmacks- oder Glaubensfrage oder eine
> Frage der Vorkenntnisse. Produktive Unterschiede gibt es nicht. Ich kenne
> beide Welten gut genug, um sagen zu können, dass man mit beiden etwa
> gleich schnell zum Ziel kommt.

Nun, gerade eben mit 'My' könnte sich ein produktiver Unterschied
hinzugesellen. Künftige Erweiterungen von 'My' um bspw. "simple Printing",
wie sie bereits geplant waren, könnten diese Vorteile noch verstärken. Ich
denke, dass man derartige Unterschiede durchaus aufzeigen und diskutieren
sollte.

>> Jemand der kommerziell Software in VB.net entwickelt und sein "Handwerk"
>> dazu entsprechend gelernt hat, wird keine Probleme haben, ein in C# oder
>> auch einer anderen Sprache geschriebenes Programm nachzuvollziehen. Er
>> wird
>> es möglicherweise nicht so flüssig lesen, wie ein in "seiner" Sprache
>> geschriebenes, aber es wäre auch reichlich unlogisch, so etwas zu
>> erwarten.
>
> Na, da sind wir uns ja einig. Leider zeigen die Beiträge in den Newsgroups
> tagtäglich, dass das offenbar nicht so ist.

Wenn ein VB.NET- oder C#-Anfänger sich jeweils nicht mit der anderen
Programmiersprache auskennt, ist das zu tolerieren. Ich habe auch zuerst
VB.NET gelernt und anschliessend mein VB.NET-Wissen direkt auf C#
übertragen. Aber um das zu tun, muss ein Grundstock an Wissen über
Programmierparadigmen und -konzepte vorhanden sein. Andererseits geht mir
nicht ein, warum C#-Entwickler, die den Eindruck der Professionalität
erwecken, sich über VB.NET-Code und VB.NET mokieren.

>> ... Wenn aber erst mal die Entscheidung gefallen ist, die
>> Sprache XY wird zur Lösung der Aufgabe verwendet, dann werden auch die
>> von
>> dieser Sprache gebotenen Möglichkeiten genutzt, denn diese waren ja der
>> Grund, sich für eben diese Sprache für diese Aufgabe zu entscheiden.
>> Irgendwelche Sprachfeatures zu meiden, nur weil es die in einer anderen
>> Sprache so nicht gibt oder irgendeiner Lehre oder einem unsinnigen Dogma
>> widersprechen, hat nichts mit produktivem Arbeiten zu tun.
>
> Du hast unsere Bedenken nicht wirklich verstanden. Wenn Herfried
> begeistert My.XYZ benutzt, ist nichts dagegen einzuwenden.

Nur um das klarzustellen: Ich stehe und stand 'My' kritisch gegenüber, weil
ich anderen Dingen höhere Prioritäten beigemessen hätte als 'My'. Niemand,
den ich kenne, hat nach 'My' gerufen, sondern Microsoft hat die meisten
damit überrascht. Trotzdem: 'My' ist da und dementsprechend gilt es zu
diskutieren, wie die Kluft zwischen VB.NET und C# vielleicht in Zukunft
geschlossen werden kann.

Für mich steht 'My' nicht im Widerspruch zum .NET Framework. Mit der
Existenz von 'My' konfrontiert würde ich es begrüssen, wenn 'My' nicht nur
auf VB.NET beschränkt wäre. Wie die Bibliothek heisst, in der 'My'
implementiert ist, hat geringe Relevanz, denn in einer Programmiersprache,
deren Compiler 'My' unterstützt, ist dies vollkommen transparent. Daher kann
der Name der DLL auch leicht geändert werden, sollte ein allgemeines
'My'-Merkmal für mehrere .NET-Programmiersprachen geöffnet werden. Nur: C#
unterstützt derzeit 'My' nicht, deshalb sieht man das unschöne
'Microsoft.VisualBasic' im Code (gut, projektweite Importe könnten hier
dienlich sein ;-)).

Deine Bedenken in Hinblick auf VB6-Umsteiger kann ich zum Teil beipflichten.
Ich selbst sehe 'My' gerade trotz seiner Einfachheit als Funktionsmerkmal,
das nicht leichtfertig verwendet werden soll. Das Studium des .NET
Frameworks wird es sicher nicht ersetzen.

> Ja, sagte ich bereits. Das ist genauso "beschränkt". Ein C#-Programmierer
> kann auch ohne Mühe typische VB-Syntax verstehen, wenn er denn will.
> Allerdings wird das mit Altlasten wie Filecopy, Kill und neuen
> Spezialitäten wie My immer schwieriger.

Glaubst du, dass unsaubere Sprachmerkmale wie 'default(T)' das Lesen von
C#-Code für VB.NET-Benutzer leichter machen? War das Lesen von C#-Code mit
'using' ohne Blick in die Dokumentation möglich? VB.NET ist nun einmal nicht
C# und umgekehrt ist C# nicht VB.NET. Jede der beiden Programmiersprachen
besitzt ihre Eigenheiten, und die muss man verinnerlichen, wenn man darin
entwickelten Code verstehen will.

>
> Das Problem ist nur, dass hier das Rad wieder mehrfach erfunden wird.
> Wieviel tausend Umsetzungen alleine der SHFileoperation-Kiste gibt es wohl
> inzwischen? Und wieviele Fehler werden dabei gemacht? Bedenke, dass für
> eine Reihe von API-Funktionen fundierte C- (nicht C#) notwendig sind. Wenn
> ich allein in dieser NG schon sehe, wie oft bei API-Funktionen die
> falschen Datentypen verwendet werden (z.B. Long statt Integer), dann
> müssen doch bei MS die Alarmglocken läuten. SHFileOperation bietet auch so
> einige Fallstricke. Es muss somit bei MS mit hoher Priorität auch daran
> gearbeitet werden, durch Erweiterung des Frameworks den Bedarf an
> API-Funktionen drastisch zu reduzieren. Schon allein aus Gründen der
> Code-Sicherheit halte ich das für unumgänglich.

Dem kann ich nur voll zustimmen. Dennoch mache ich dem VB.NET-Team keinen
Vorwurf dafür, dass es in 'My' eine verwaltete Möglichkeit bietet, diese
Funktionalität zu nutzen.

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
> Antwort von Tyler Whitney [MS], development lead 'My' feature:
>
> A: The problem is that many VB6 customers never would find
> Directory.CreateDirectory ;-)
> And our message is that Directory.CreateDirectory is what we end up
> calling anyway.
> We just make is easy to find. As for the VB6:MkDir, that is just for
> backwards compat.
> There is a problem having the new world and the old,
> but we found an even worse problem during user studies that many people
> couldn't find
> the new functionality at all.
> So we took the bet to make it easy to find some of the common things.

Thomas, mal ehrlich, wir lesen beide die deutschsprachigen VB.NET- und
C#-Gruppen: Unterscheiden sich die Anfängerfragen der beiden Gruppen
wirklich so stark? Ich sehe in beiden Gruppen ähnliche Fragen, eben u.a.
"wie erstelle ich ein Verzeichnis". Das "VB6" in Tyler Whitneys Aussage kann
m.E. getrost durch "VB6, VB.NET, C++, C#" etc. ersetzt werden.

Grosse Klassenbibliotheken sind sicher eine tolle Sache, haben aber den
Nachteil, dass sie zu schnell unübersichtlich werden, da sie Funktionalität
für alle Anwendungsfälle bereitstellen. Dies betrifft vor Allem
gelegentliche Nutzer, die durchaus auch im professionellen Bereich zu finden
sind. Da hilft auch eine Strukturierung durch Namensräume wenig,
Subnamensräume wie 'Common' unter jedem Namensraum, in denen die häufigst
verwendeten Merkmale zu finden sind oder das Auszeichnen grundlegender
Funktionalität mit speziellen Attributen, um sie in IntelliSense u.ä.
optisch hervorzuheben, sind unzureichend, da selbst Methodenüberladungen für
viele Anwendungsfälle unpassend dimensioniert sind. Das gilt auch für das
allgemeine Überladungsdilemma, also einem Wust an Überladungen, in denen man
diejenige, die für die meisten Fälle vollkommen ausreichend ist, kaum
findet.

Das .NET Framework wird in den nächsten Jahren noch weiter Wachsen, sodass
es noch an Übersichtlichkeit verlieren wird. Ich sehe 'My' als Antwort auf
dieses allgemeine "Problem", nämlich als Versuch, die /wichtigste/
Funktionalität in sauber und intuitiv angeordneter Form bereitzustellen,
ohne sie dabei neu zu erfinden. Während dem .NET Framework im Wachstum keine
Grenzen gesetzt sind, muss die Auswahl der Funktionalität, die in 'My'
bereitgestellt wird, sorgfältig erfolgen, da sonst früher oder später
ähnliche Probleme wie bei .NET Framework zu erwarten sind.

Hallo Herfried,

umpf - noch mehr Text ;-)

Ich habe alles gelesen, will aber aus Zeitgründen nicht zu allen Punkten
Stellung nehmen. Nur ganz kurz:

> Glaubst du, dass unsaubere Sprachmerkmale wie 'default(T)' das Lesen von
> C#-Code für VB.NET-Benutzer leichter machen? War das Lesen von C#-Code mit
> 'using' ohne Blick in die Dokumentation möglich? ...

Using gibt's ja in VB.NET jetzt auch ;-)
Grundsätzlich hast Du aber Recht. In C# gibt es auch einige merkwürdige
Syntaxkonstruktionen. Z.B.:

int?
für
Nullable<int>

Wenn das ein VB-Programmierer nicht versteht, kann ich das nachvollziehen.

Das sind allerdings syntaktische Feinheiten. Die gibt es in beiden Sprachen.
Schwieriger wird es mit eingebauten VB-Funktionen, die nicht jeder kennt.
Ich habe mir eben auf der Seite von Peter Götz ein paar Beispiele zur
Datumsberechnung angesehen. Die sind durchsetzt mit Funktionen wie
DateSerial, DateAdd usw. Welcher Nicht-VB-Programmierer kann damit etwas
anfangen?

Aber es gibt noch eine andere Neuerung in VB.NET, die mir ein Dorn im Auge
ist:
Die Möglichkeit, bei Fensterklassen über Klassenname.Show ein Fenster
anzeigen zu können, ohne dass vorab eine Instanz angelegt werden muss. Eine
statische Methode 'Show' ist für die Klasse 'Form' nicht dokumentiert. Wie
soll man jemandem OOP beibringen, wenn MS hier wieder alles anders macht?

Gruß
Joachim

Hallo Harald,

>> Der Eindruck ergibt sich vermutlich zwangsläufig daraus, dass Thomas und
>> ich die nahezu einzigen sind, die es wagen, in dieser Newsgroup auch
>> etwas gegen VB.NET zu schreiben.
>
> Vielleicht hat das weniger etwas mit "wagen" zu tun, als eher damit, dass
> wir "Uralt"-VB'ler aufgrund der schon früheren VB-Unzulänglichkeiten wohl
> einfach wesentlich ...hm... toleranter gegenüber dem jetzigen VB.NET sind.
>
>> So negativ, wie es vielleicht manchmal klingt, ist meine Einstellung zu
>> VB.NET aber nicht.
>
> Auch wenn Du Dich im vorhergehenden Satz in eine Reihe mit Thomas stellst:
> Wirklich auf einer Linie liegt Ihr m.E. nicht wirklich...
> ;-)

Wenn ich das jetzt nochmals lese, würde ich die Formulierung eher ändern.
Ich schreibe ja nichts "gegen" VB, sondern übe Kritik an verschiedenen
Dingen, die mir in VB.NET nicht gefallen.

Also bitte "etwas gegen VB.NET zu schreiben" ersetzen durch "Kritik an
VB.NET zu üben.".
Ob ich mit Thomas auf einer Linie liege, kann ich selbst schlecht
beurteilen, da ich Thomas' Erfahrung in der VB-Programmierung nicht
einschätzen kann. Grundsätzlich kann ich aber vielen seiner Argumente
zustimmen, die hier sehr vehement bekämpft werden.

MS versucht mit VB.NET einen großen Spagat. Einerseits soll es eine
High-End-Sprache sein, die C# in nichts nachsteht, andererseits sollen
Gelegenheitsprogrammierer, die bislang mit VBA gebastelt haben, auch ihren
Gefallen daran finden. Beides in einer Sprache zu vereinigen, halte ich für
sehr fragwürdig. Vielleicht wäre es wirklich besser, wie früher bei VBx und
VBA zwei Sprachen für die jeweiligen Ansprüche anzubieten. VB.NET
Professional ohne historischen Ballast und VBA.NET mit 99,9% Kompatibilität
zu VB6/VBA.

Gruß
Joachim

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
>> Glaubst du, dass unsaubere Sprachmerkmale wie 'default(T)' das Lesen von
>> C#-Code für VB.NET-Benutzer leichter machen? War das Lesen von C#-Code
>> mit 'using' ohne Blick in die Dokumentation möglich? ...
>
> Using gibt's ja in VB.NET jetzt auch ;-)

Genau, und vielleicht gibt's auch mal 'My' (oder 'That') in C# ;-).

> Grundsätzlich hast Du aber Recht. In C# gibt es auch einige merkwürdige
> Syntaxkonstruktionen. Z.B.:
>
> int?
> für
> Nullable<int>
>
> Wenn das ein VB-Programmierer nicht versteht, kann ich das nachvollziehen.
>
> Das sind allerdings syntaktische Feinheiten.

Man muss aber trotzdem in der Dokumentation nachsehen, um in der Lage zu
sein, den Code zu verstehen -- in beiden Sprachen.

> Schwieriger wird es mit eingebauten VB-Funktionen, die nicht jeder kennt.
> Ich habe mir eben auf der Seite von Peter Götz ein paar Beispiele zur
> Datumsberechnung angesehen. Die sind durchsetzt mit Funktionen wie
> DateSerial, DateAdd usw. Welcher Nicht-VB-Programmierer kann damit etwas
> anfangen?

Naja, was die Funktionen machen, ist ja mehr oder weniger offensichtlich,
bei so sprechenden Namen.

> Aber es gibt noch eine andere Neuerung in VB.NET, die mir ein Dorn im Auge
> ist:
> Die Möglichkeit, bei Fensterklassen über Klassenname.Show ein Fenster
> anzeigen zu können, ohne dass vorab eine Instanz angelegt werden muss.
> Eine statische Methode 'Show' ist für die Klasse 'Form' nicht
> dokumentiert. Wie soll man jemandem OOP beibringen, wenn MS hier wieder
> alles anders macht?

Diese Neuerung gefällt mir auch nicht, und auch viele andere MVPs und
VB.NET-Entwickler haben sich dagegen stark gemacht, auch im direkten Kontakt
mit Microsoft. Aber Microsoft denkt wohl, damit VB6-Entwickler anziehen zu
können -- eine Einschätzung, die ich nicht teile. Aber Microsoft sieht
anscheinend das Problem nicht, das VB6-Entwickler mit dem Umstieg auf .NET
haben. 'My.Forms.<Klassenname>' ist m.E. eine nette Sache, besonders für
Dialoge, von denen nur eine Instanz existieren kann. Noch dazu, wo Instanzen
nur bei Bedarf angelegt werden. Der direkte Zugriff über den Klassennamen
ist jedoch sehr ärgerlich!

> Thomas, mal ehrlich, wir lesen beide die deutschsprachigen VB.NET- und
> C#-Gruppen: Unterscheiden sich die Anfängerfragen der beiden Gruppen
> wirklich so stark?


'Anfängerfragen' unterscheiden sich nicht so stark,
sind aber hier öfter noch einen Hauch 'unbeholfener'.

Weiteres Indiz:
Es wird hier viel häufiger ein fixfertiges Code-Snippet erwartet/geliefert.
VB-Programmierer arbeiten offenbar noch eher 'blind' mit Copy&Paste,
anstatt erst eine Lösung (mittels Doku) zu _erarbeiten_.
Dies ist IMHO ein wichtiger Hintergrund
zum fehlenden Willen/Fähigkeit, ein umfangreiches Framework zu lernen.

Vor lauter RAD nimmt man sich offenbar kaum mehr die Zeit
für etwas _äusserst_ wichtiges,
nämlich um das 'Feeling' für eine Technologie zu bekommen.
Man muss ja nicht das ganze Fx auswendig kennen,
sondern etwa wissen, wo zu suchen.

Das ganze auch unter dem Grundsatz: "Der Weg ist das Ziel".



> Grosse Klassenbibliotheken sind sicher eine tolle Sache, haben aber den
> Nachteil, dass sie zu schnell unübersichtlich werden
> Ich sehe 'My' als Antwort auf dieses allgemeine "Problem"


wenn dies ein echtes, allgemeines 'Problem' wäre,
dann müsste/hätte man/MS :
- dies universeller direkt im Fx für alle Sprachen lösen sollen,
und zwar nur mit möglichst 'virtuellen Shortcuts'.
Aber keinesfalls mit Klassen/Methoden/Code-Duplizierung
in einem sprachspezifischen, isolierten VB-Assembly, wie bei 'My'.

Ich persönlich würde aber Design-Time Alternativen vorziehen, zB:

- visuell stark verbesserte Fx Doku
(auch interaktive HTML-Posters o.ä., usw.)

- IntelliSense fast Wizard-artig erweitert (aber bitte abschaltbar).
Der User navigiert dabei also visuell in sowas wie dem My-Namespace,
aber es wird danach reiner .NET-Fx SourceCode eingefügt.

Hauptsache muss dabei _immer_ bleiben:
es entsteht 100% reiner .NET (möglichst CLI) - SourceCode!



> muss die Auswahl der Funktionalität, die in 'My' bereitgestellt wird,
> sorgfältig erfolgen, da sonst früher oder später ähnliche Probleme

richtig, wie schon mehrmals gesagt,
es besteht die Gefahr dass ein Parallel-Universum entsteht:
Wächst es zu schnell, -> Explosion (wg totaler Duplizierung),
wächst es nicht mehr, -> Implosion (wg mangelnder Attraktivität).

Hallo Joachim,

> Das sind allerdings syntaktische Feinheiten. Die gibt es in beiden
> Sprachen. Schwieriger wird es mit eingebauten VB-Funktionen, die nicht
> jeder kennt. Ich habe mir eben auf der Seite von Peter Götz ein paar
> Beispiele zur Datumsberechnung angesehen. Die sind durchsetzt mit
> Funktionen wie DateSerial, DateAdd usw. Welcher Nicht-VB-Programmierer
> kann damit etwas anfangen?

In jedem Programm gibt es aber auch Methoden-Aufrufe wie Foo und Bla usw.
Welcher Programmierer kann damit etwas anfangen, egal in welcher Sprache?
Er wird also bei einer unbekannten Funktion nach deren Implementierung
suchen. Findet er sie nicht im Programm selbst, schließt er daraus, dass
sie sich in einer Bibliothek befindet. Er schaut nun etwa im im
Objekt-Katalog nach oder probiert die F1-Taste. Ob sich nun die Methode in
der Bibliothek "FuerDiesUndJenes" oder in der Bibliothek
"MicrosoftVisualBasic" findet, spielt doch nun keine Rolle mehr, oder?

> Aber es gibt noch eine andere Neuerung in VB.NET, die mir ein Dorn im
> Auge ist:
> Die Möglichkeit, bei Fensterklassen über Klassenname.Show ein Fenster
> anzeigen zu können, ohne dass vorab eine Instanz angelegt werden muss.
> Eine statische Methode 'Show' ist für die Klasse 'Form' nicht
> dokumentiert. Wie soll man jemandem OOP beibringen, wenn MS hier wieder
> alles anders macht?

Zugegeben, das ist ein Rückschritt - und dieses Feature war auch schon in
VB Classic ein Hindernis für viele, Forms als Klassen zu begreifen und zu
nutzen...


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

Hallo Joachim,

> MS versucht mit VB.NET einen großen Spagat. Einerseits soll es eine
> High-End-Sprache sein, die C# in nichts nachsteht, andererseits sollen
> Gelegenheitsprogrammierer, die bislang mit VBA gebastelt haben, auch
> ihren Gefallen daran finden. Beides in einer Sprache zu vereinigen, halte
> ich für sehr fragwürdig.

Grundsätzlich ist eigentlich nichts dagegen einzuwenden. Es ist "nur" eine
Herkules-Aufgabe, die richtig und konsequent angepackt werden müsste - und
da hapert es schon ein wenig, zugegeben.

> Vielleicht wäre es wirklich besser, wie früher bei VBx und VBA zwei
> Sprachen für die jeweiligen Ansprüche anzubieten. VB.NET Professional
> ohne historischen Ballast und VBA.NET mit 99,9% Kompatibilität zu
> VB6/VBA.

Na, da verkennst Du aber ganz gehörig den Unterschied zwischen VBx und VBA.

Zumindest seit VB5 sind VB und VBA identisch - sie haben nämlich über die
identische Syntax hinaus exakt den gleichen Sprachkern. In VB5/6 liegt
dieser nämlich sogar in einer explizit so bezeichneten "VBA"-Bibliothek.
(Im Wesentlichen ist dieser Sprachkern nun eben in .VB.NET zur "Microsoft
Visual Basic"-Bibliothek geworden.)

VBA ist nichts weiter als dieser Sprachkern, der in verschiedene
Objekt-Umgebungen über die VBA-Entwicklungsumgebung (auch weitestgehend mit
der von VB5/6 identisch) verwendet werden kann. Die Objekt-Umgebungen (MS
Word, Excel, ... AutoCAD, Corel Draw und, und und...) stellen ein mit eben
VBA programmierbares Objekt-Modell zur Verfügung - und dazu noch die
Forms-Bibliothek für Dialoge usw.

Und so gesehen, ist das Stand-Alone-VB nichts anderes, als der Sprachkern
VBA mit der VBA-IDE, wobei hier schließlich als programmierbares
Objekt-Modell das VB-Objekt-Modell mit den Forms und Standard-Controls in
der Bibliothek "VB" und dazu noch die Hilfs-Bibliothek "VBRun" zur
Verfügung gestellt werden. Dass mit Stand-Alone-VB eigenständig ausführbare
Anwendungen kompiliert werden können, dass es mehr Projekt-Typen gibt usw.,
hat nicht wirklich mit einem Unterschied zu VBA zu tun.


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>> Thomas, mal ehrlich, wir lesen beide die deutschsprachigen VB.NET- und
>> C#-Gruppen: Unterscheiden sich die Anfängerfragen der beiden Gruppen
>> wirklich so stark?
>
> 'Anfängerfragen' unterscheiden sich nicht so stark,
> sind aber hier öfter noch einen Hauch 'unbeholfener'.
>
> Weiteres Indiz:
> Es wird hier viel häufiger ein fixfertiges Code-Snippet
> erwartet/geliefert.

Das ist wohl eine Implikation deiner Feststellung zu den Anfängerfragen.
Anfänger neigen nun einmal dazu, Code abzutippen und sich erst später
Gedanken über dessen Funktionsweise zu machen, wenn sie den Code anpassen
und erweitern. Das wird sich bei VB.NET- und C#-Anfängern kaum
unterscheiden.

> VB-Programmierer arbeiten offenbar noch eher 'blind' mit Copy&Paste,
> anstatt erst eine Lösung (mittels Doku) zu _erarbeiten_.

Das trifft auf Anfänger sicher zu. Mir scheint, dass sich in dieser Gruppe
etwas mehr wirkliche Programmieranfänger finden, als in der C#-Gruppe.
Deshalb würde ich daraus nicht darauf schliessen, wie professionelle
VB.NET-Entwickler arbeiten.

> Dies ist IMHO ein wichtiger Hintergrund
> zum fehlenden Willen/Fähigkeit, ein umfangreiches Framework zu lernen.

Die ganze Sache hat mit dem Willen oder der Fähigkeit wenig zu tun. Selbst
professionelle Entwickler, die bereits länger mit dem .NET Framework
arbeiten, kennen oft nicht die gesamte Funktionalität des .NET Framework.
Wer würde z.B. Objekte zur Repräsentation von Windows-Benutzern
('WindowsPrincipal') in 'System.Security.Principal' vermuten? Über
'My.User.CurrentPrincipal' findet man blitzschnell ans Ziel.

> Vor lauter RAD nimmt man sich offenbar kaum mehr die Zeit
> für etwas _äusserst_ wichtiges,
> nämlich um das 'Feeling' für eine Technologie zu bekommen.
> Man muss ja nicht das ganze Fx auswendig kennen,
> sondern etwa wissen, wo zu suchen.

Das Suchen kann man sich aber mit 'My' z.T. ersparen.

>
> wenn dies ein echtes, allgemeines 'Problem' wäre,
> dann müsste/hätte man/MS :
> - dies universeller direkt im Fx für alle Sprachen lösen sollen,
> und zwar nur mit möglichst 'virtuellen Shortcuts'.
> Aber keinesfalls mit Klassen/Methoden/Code-Duplizierung
> in einem sprachspezifischen, isolierten VB-Assembly, wie bei 'My'.
>
> Ich persönlich würde aber Design-Time Alternativen vorziehen, zB:
>
> - visuell stark verbesserte Fx Doku
> (auch interaktive HTML-Posters o.ä., usw.)
>
> - IntelliSense fast Wizard-artig erweitert (aber bitte abschaltbar).
> Der User navigiert dabei also visuell in sowas wie dem My-Namespace,
> aber es wird danach reiner .NET-Fx SourceCode eingefügt.

Das sind alles gute Ideen :-). In VB 2005 ist letzerer Vorschlag ja
/ansatzweise/ mit den Registern "Common" und "All" in IntelliSense
realisiert.

> Hauptsache muss dabei _immer_ bleiben:
> es entsteht 100% reiner .NET (möglichst CLI) - SourceCode!

Gibt es wirklich Entwickler, die darauf achten, nur die in der CLI
enthaltenen Klassen zu benutzen? Durch Verwendung von 'My' entsteht doch
".NET-Code".

>> muss die Auswahl der Funktionalität, die in 'My' bereitgestellt wird,
>> sorgfältig erfolgen, da sonst früher oder später ähnliche Probleme
>
> richtig, wie schon mehrmals gesagt,
> es besteht die Gefahr dass ein Parallel-Universum entsteht:
> Wächst es zu schnell, -> Explosion (wg totaler Duplizierung),
> wächst es nicht mehr, -> Implosion (wg mangelnder Attraktivität).

Ob es das wird, hängt einzig und allein davon ab, wie sorgfältig die Auswahl
erfolgt.

Hallo Harald,

Hallo Harald,

> VBA ist nichts weiter als dieser Sprachkern, der in verschiedene
> Objekt-Umgebungen über die VBA-Entwicklungsumgebung (auch weitestgehend
> mit der von VB5/6 identisch) verwendet werden kann. Die Objekt-Umgebungen
> (MS Word, Excel, ... AutoCAD, Corel Draw und, und und...) stellen ein mit
> eben VBA programmierbares Objekt-Modell zur Verfügung - und dazu noch die
> Forms-Bibliothek für Dialoge usw.

der Sprachkern ist derselbe, aber die Entwicklungsumgebung nicht. Auch habe
ich nie nachvollziehen können, dass bei VBA Dialoge anders aufgebaut werden
als bei VB6.

Und hier gibt es wirklich klassische Unterschiede zwischen
VBA-Programmierern und VB6-Programmierern. Erstere wollen oft lediglich Word
oder Excel ein bisschen erweitern und ein paar Kleinigkeiten automatisieren,
aber nicht tiefer in die Programmierung einsteigen. Diese
Gelegenheitsprogrammierer gehen, wie Arne gestern geschrieben hat, in .NET
unter und werden ohne Hilfe wie My & Co nicht klar kommen.

Gruß
Joachim