Hallo Thomas,

> du bist etwas spät & OT, daher :

Ich wollte nur mal abwarten, was Du hier noch alles zum Besten gibst.

>
> > Ich bin immer wieder verwundert, welche Statements in Bezug auf VB
man hier
> > immer wieder mal lesen kann.
>
> es geht nicht um VB, sondern VB.NET...

Na, wenn ich mir Deine Kreuzzüge hier ansehe, geht es schon um Beides.
Alleine die Erwähnung von VB oder auch VB.net scheint bei Dir doch schon
Wutausbrüche und ein kaum zu bändigendes Missionierungsbedürfnis auszulösen.

> > ob eine bestimmte Syntax in einer Programmiersprache gut oder
schlecht sei,
>
> es geht per Definition nicht um die Syntax/Keywords, sondern um
Zusatz-Funktionen/Libraries,
> die so nicht ins .NET-Zeitalter gehören.

Na grossartig.
Wir haben jetzt also das .net-Zeitalter und wehe dem, der es wagt, sich
nicht widerspruchslos den Prinzipien einiger .net-Dogmatiker zu unterwerfen.
Die Inquisition lässt grüssen. ;-)

Ich werde mich trotzdem auch in Zukunft an den Wünschen meiner Kunden und
nicht an Vorurteilen unerschütterlicher Dogmatiker orientieren und wenn es
dabei mal nicht .net-konform zugeht, wirst Du damit leben müssen. Auch wenn
Dir sowas scheinbar schlaflose Nächte bereitet.

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

Thomas Scheidegger [MVP] wrote:
....
> es geht per Definition nicht um die Syntax/Keywords, sondern um
> Zusatz-Funktionen/Libraries, die so nicht ins .NET-Zeitalter gehören.

Thomas,
und wer ist der "Gott", der bestimmt, was in das .NET-Zeitalter gehört? Wird
das nicht wesentlich davon bestimmt, was der Käufer/Anwender mit seinen
jahrelangen Erfahrungen und Gewohnheiten wünscht, auch wenn dessen
Qualifikation in den theoretischen Grundlagen nicht unbedingt ausreicht, die
heutigen Missionierungsversuche der Verfechter der "reinen" Lehre zu
verstehen? Was solche Versuche auf anderen Gebieten für Probleme bringen
können, hat die Geschichte ja reichlich gezeigt. Ich kann aus der gesamten
Diskussion nicht erkennen, was schlecht sein soll, dem Nutzer vielfältige
Möglichenkeiten zur Effektivierung seiner Arbeit zur Verfügung stellen, auch
wenn dabei ggf. Ziele auf unterschiedlichen Wegen erreicht werden können,
und, auch wenn dabei die unqualifizierte Nutzung zu nicht optimalen
Ergebnissen sein kann. Davon sind auf ihren Irrwegen aber auch die
Verfechter der "reinen" Lehre nicht gefeit, da auch sie gleichfalls einen
Erkenntnisprozeß durchlaufen.

Peter

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
> Blog von Paul Vick, Microsoft VB.NET-Architekt :
>
> [..]
>
> "But it has a NOT SO GOOD side.
> It means VB.Net programmers will be learning and using a ...
> *different* object model for many tasks"

Wo auf der oben genannten Seite sagt Paul Vick das?

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>> Ich bin immer wieder verwundert, welche Statements in Bezug auf VB man
>> hier
>> immer wieder mal lesen kann.
>
> es geht nicht um VB, sondern VB.NET...

Wenngleich VB.NET kein Nachfolger von VB6 ist, ist eine gewisse Nähe
zwischen den beiden Programmiersprachen unbestreitbar.

>> ob eine bestimmte Syntax in einer Programmiersprache gut oder schlecht
>> sei,
>
> es geht per Definition nicht um die Syntax/Keywords, sondern um
> Zusatz-Funktionen/Libraries,
> die so nicht ins .NET-Zeitalter gehören.

Das ist deine verkürzte Sichtweise. Du ignorierst anscheinend vollkommen,
dass 'My' auch ein Compilermerkmal ist.

>> "But it has a NOT SO GOOD side.
> Wo auf der oben genannten Seite sagt Paul Vick das?


Ups, Sorry und verflixt,
da sind Links total durcheinander geraten, war nicht von Paul Vick, sondern
http://weblogs.asp.net/rosherove/arc...23/118544.aspx

Thomas Scheidegger [MVP] schrieb:

> lies bitte nochmals:
> Blog von Paul Vick, Microsoft VB.NET-Architekt :
>
> [..]
>
> "But it has a NOT SO GOOD side.
> It means VB.Net programmers will be learning and using a ...
> *different* object model for many tasks"

Thomas, vielleicht lieferst Du auch besser den zum Zitat passenden
Link. Es stammt nicht von Paul Vick, sondern Roy Osherove:
http://weblogs.asp.net/rosherove/arc...23/118544.aspx

Roy Osherove ist, so wie ich das sehe, von VB6 in das C# Lager
gewechselt und wird dafür seine Gründe gehabt haben. Warum er versucht
Visual Basic.NET Sprachfeatures zu bewerten, ist mir schleierhaft, hat
er mit dieser Sprache doch scheinbar nicht mehr viel am Hut.

Thorsten Dörfler

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

Nur dies zum Abschluss:
warum wohl tun sich so viele VB6 User so schwer mit allem rund um .NET?
Weil sie in einer völlig isolierten, rosaroten Welt lebten!
Diese versucht man nun immer noch verbissen zu retten,
und schlimmer, wiederum neue Mauern aufzubauen.

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.

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>>> "But it has a NOT SO GOOD side.
>>
>> Wo auf der oben genannten Seite sagt Paul Vick das?
>
> Ups, Sorry und verflixt,
> da sind Links total durcheinander geraten, war nicht von Paul Vick,
> sondern
> [..]

Ups, das ist ja ein Artikel eines Befürworters von 'My' in C#, also
jemandem, der damit eine "völlig missratene Kurschluss-Handlung aufgrund
unseriösem Kunden-Feedback" provozieren will?

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
> 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 ...

Genau andersrum:

'My' ist eine der Innovationen aus dem Hause Microsoft. Als C#-Entwickler
ohne 'My'-Kenntnisse wird ein Wechsel auf VB.NET wegen eines Projekts bzw.
einer Stelle nicht ganz so einfach sein...

Hallo Peter,

> Ich kann mir jedenfalls nicht vorstellen, meine wertvolle Arbeitszeit mit
> völlig sinnlosen Diskussionen über bestimmte Funktionalitäten in ...

mein Beitrag zu dieser Diskussion ist verschwindend gering und eigentlich
wollte ich mich auch nicht mehr einmischen. Aber da Du mich direkt
ansprichst:

Meine Ausgangsfrage sollte "My" eigentlich gar nicht infrage stellen (die
Diskussion gab es ja schon mal), sondern ich wollte lediglich wissen, ob es
die (auch von mir gewünschte) Funktionalität (Animation der
Dateioperationen) im System.IO-Namespace gibt. Es wäre wesentlich logischer,
sie dort unterzubringen, statt in proprietären VB-Bibliotheken. Ein C#- oder
Delphi-Programmierer wird eine Überladung von System.IO.File.Copy mit
Parametern für die Visualisierung eher erwarten als eine entsprechende
Methode im VB-Namespace.

> Das hier ist eine Newsgroup für VB.net.
> Ergo ist anzunehmen, dass hier Probleme und Aufgabenstellungen rund um
> VB.net erörtert werden und die Fragesteller für ihre Arbeit oder
> meinetwegen
> auch ihr Hobby verwertbare Antworten erhalten wollen.

Newsgroup <> Hilfeportal!

Ich halte die Diskussionen durchaus für sinnvoll, wenngleich sie manchmal
ein wenig zu lang sind und man sich im Kreis dreht. Aber es ist durchaus
wichtig, auch einmal andere Meinungen zu lesen und sich ein Bild von den
Bedürfnissen anderer Programmierer zu machen. Und ein Blick in die Zukunft,
wie sich Features von heute in einigen Jahren auswirken, ist bestimmt nicht
verkehrt.

>> Als .NET-Programmierer sollt man .NET-Beispielcode nachvollziehen können,
>> der entweder in VB.NET oder C# geschrieben worden ist.
>
> Von einem Programmierer, der Programme mit VB.net schreibt, erwarte ich,
> dass er diese Programmiersprache hinreichend beherrscht um damit die ihm
> anvertrauten Programme zu schreiben und auch zu pflegen. Wozu soll er
> dafür
> das gleiche Wissen über C# haben?

Wie schon so oft: Bei der .NET-Programmierung ist die Sprache relativ
nebensächlich. Man muss die typischen Vorgehensweisen und den Umgang mit dem
Framework beherrschen. Wer das kann, wird auch Beispiele aus anderen
Sprachen verstehen. Dazu muss man als VB.NET-Programmierer nicht mit den
Feinheiten von C# vertraut sein (und umgekehrt genauso). 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.

Und warum ist das nötig? Damit das ewige Gejammere "ich finde immer nur
Beispiele in C#" endlich aufhört. 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. So kompliziert ist das
nicht.

> Wenn ich oder irgendein anderer einen Programmierer einstellt, dann wird
> es
> ihm erst mal relativ egal sein, ob der irgendwelche Beispiele aus dem
> Internet versteht. Ein Programmierer wird eingestellt, um eine oder auch
> mehrere ganz genau festgelegte Aufgaben zu bearbeiten. Wenn dafür gute und
> fundierte VB-Kenntnisse erforderliche sind, dann werde ich den nicht
> fragen
> ob und wie gut er C# beherrscht.

Sehe ich anders. Ein Programmierer sollte dazu in der Lage sein, die
gestellten Aufgaben *selbstständig* zu lösen. Niemand aber kennt jede
Schublade von .NET. 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. Und eine dieser typischen
Vorgehensweisen ist heute, im Internet nach Beispielen zu suchen, um zu
sehen, wie andere Leute ähnliche Probleme gelöst haben. Aber eben diese
Beispiele sind nicht immer in VB.NET, sondern auch in anderen Sprachen
geschrieben worden.

>> Wenn es Code gibt, der allgemein benötigt wird (siehe Ausgangsthema),
>> dann
>> gehört der ins .NET-Framework und nicht in irgendwelche
> Spezialbibliotheken.
>
> Wer bestimmt denn, was "allgemein benötigt" wird?

Der gesunde Menschenverstand? Warum sollten die SHFileOperation-Animationen
VB-Programmierern vorbehalten sein? Weil die C#-Programmierer schon längst
die API-Funktionen nutzen? Das macht keinen Sinn.

Das .NET-Framework ist noch längst nicht vollständig. Die vielen Fragen zu
den Animationsmechanismen von WinXP, zu Taskbars usw. in den Newsgroups
(sowohl VB als auch C#) zeigen, dass hier ein Bedarf besteht. Ich meine, man
kann zu Recht erwarten, dass man mit einem .NET-Programm die typischen
Features von XP direkt ohne Win-API verwenden kann. Und zwar unabhängig von
der eingesetzten Programmiersprache.

Gruß
Joachim

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
>> Wer bestimmt denn, was "allgemein benötigt" wird?
>
> Der gesunde Menschenverstand? Warum sollten die
> SHFileOperation-Animationen VB-Programmierern vorbehalten sein? Weil die
> C#-Programmierer schon längst die API-Funktionen nutzen? Das macht keinen
> Sinn.
>
> Das .NET-Framework ist noch längst nicht vollständig. Die vielen Fragen zu
> den Animationsmechanismen von WinXP, zu Taskbars usw. in den Newsgroups
> (sowohl VB als auch C#) zeigen, dass hier ein Bedarf besteht. Ich meine,
> man kann zu Recht erwarten, dass man mit einem .NET-Programm die typischen
> Features von XP direkt ohne Win-API verwenden kann. Und zwar unabhängig
> von der eingesetzten Programmiersprache.

Es könnte doch auch sein, dass das VB.NET-Team mit dem Wunsch auf
Bereitstellung der Dateioperationsdialoge an das "Framework"-Team
heangetreten ist und der Wunsch abgeschlagen wurde. In WinFX sind nämlich,
soweit ich sehe, keine derartigen Überladungen in 'System.IO' vorgesehen.
Vielleicht hat das VB.NET-Team dann gedacht, dass es besser ist, die
Funktionalität irgendwo bereitzustellen als gar nicht. Wer weiss. Wie
gesagt, alles nur reine Spekulation.

> Genau andersrum:
> ohne 'My'-Kenntnisse wird ein Wechsel auf VB.NET wegen eines Projekts bzw.
> einer Stelle nicht ganz so einfach sein...


Wer soll dies noch ernstnehmen?
Es ist nur Geplapper von jemandem der mit solchen Aussagen immer falsch liegt
und folglich bei den Technologien chronisch aufs falsche Pferd setzt...
(VB6:tot, VB6-Altlasten:obsolet, VB.COM:tot by design, My:Totgeburt, usw.)

Hallo Joachim,

> Das .NET-Framework ist noch längst nicht vollständig. Die vielen Fragen
> zu den Animationsmechanismen von WinXP, zu Taskbars usw. in den
> Newsgroups (sowohl VB als auch C#) zeigen, dass hier ein Bedarf besteht.
> Ich meine, man kann zu Recht erwarten, dass man mit einem .NET-Programm
> die typischen Features von XP direkt ohne Win-API verwenden kann. Und
> zwar unabhängig von der eingesetzten Programmiersprache.

Vielleicht... "hätschelt" Microsoft von sich aus nur die VB-Schiene und
macht ansonsten an/ab dieser Stelle bewusst nicht alles selber, sondern
bietet Fremdanbietern jede Chance?

Viele Grüße

Harald M. Genauck

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

Hallo Joachim,

> Meine Ausgangsfrage sollte "My" eigentlich gar nicht infrage stellen (die
> Diskussion gab es ja schon mal), sondern ich wollte lediglich wissen, ob
es
> die (auch von mir gewünschte) Funktionalität (Animation der
> Dateioperationen) im System.IO-Namespace gibt. Es wäre wesentlich
logischer,
> sie dort unterzubringen, statt in proprietären VB-Bibliotheken. Ein C#-
oder
> Delphi-Programmierer wird eine Überladung von System.IO.File.Copy mit
> Parametern für die Visualisierung eher erwarten als eine entsprechende
> Methode im VB-Namespace.

Darüber hier zu diskutieren, ob und wo man sie erwartet, halte ich für
müssig. Sie ist nun mal im VB-Namespace. Wenn sich das ändern soll, wäre es
sinnvoller einen entsprechenden Änderungswunsch nicht an eine NG, sondern an
Microsoft zu richten.
Einen VB-Programmierer wird es nicht stören, da er sich ohnehin mit dem
VB-Namespace sowie den für ihn wichtigen sonstigen Bibliotheken vertraut
machen wird.


> > Das hier ist eine Newsgroup für VB.net.
> > Ergo ist anzunehmen, dass hier Probleme und Aufgabenstellungen rund um
> > VB.net erörtert werden und die Fragesteller für ihre Arbeit oder
> > meinetwegen
> > auch ihr Hobby verwertbare Antworten erhalten wollen.
>
> Newsgroup <> Hilfeportal!

Na ja, ich sag es mal ein bisschen drastisch

Newsgroup <> Selbstdarstellungsportal

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".
Ich habe eine nun wirklich hinreichend lange Berufspraxis, um mir das Urteil
erlauben zu dürfen, dass solche Aussagen schlichter Unsinn sind.
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.

> Ich halte die Diskussionen durchaus für sinnvoll, wenngleich sie manchmal
> ein wenig zu lang sind und man sich im Kreis dreht.

Genau das meine ich.
Man dreht sich im Kreis, weil eine solche Diskussion hier an dieser Stelle
absolut nichts bewirkt.


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

> Und ein Blick in die Zukunft,
> wie sich Features von heute in einigen Jahren auswirken, ist bestimmt
nicht
> verkehrt.

Ich erkenne in dieser Diskussion wenig Blicke in die Zukunft.
Ein Blick in die Vergangenheit sagt mir aber, dass es solche fruchtlosen
Diskussionen schon immer gegeben hat und es offenbar nicht auszurotten ist,
dass manche Leute glauben, "Ihre" Programmiersprache sei die einzig richtige
und beste. Bei genauerem Hinterfragen habe ich immer festgestellt, dass sich
solche Dogmatiker mit anderen Sprachen und anderen Aufgabenstellungen nicht
wirklich gründlich auseinandergesetzt haben.

> >> Als .NET-Programmierer sollt man .NET-Beispielcode nachvollziehen
können,
> >> der entweder in VB.NET oder C# geschrieben worden ist.

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.

> > Von einem Programmierer, der Programme mit VB.net schreibt, erwarte ich,
> > dass er diese Programmiersprache hinreichend beherrscht um damit die ihm
> > anvertrauten Programme zu schreiben und auch zu pflegen. Wozu soll er
> > dafür
> > das gleiche Wissen über C# haben?
>
> Wie schon so oft: Bei der .NET-Programmierung ist die Sprache relativ
> nebensächlich.

Ich sehe Programmierung nicht als .net- oder Sonstwas-Programmierung,
sondern als Mittel um eine bestimmte Aufgabe zu lösen. Wenn sich dazu eine
der .net-Sprachen hierfür eignet, werde ich sie verwenden, wenn nicht, dann
eben eine andere. 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.


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

> Dazu muss man als VB.NET-Programmierer nicht mit den
> Feinheiten von C# vertraut sein (und umgekehrt genauso).

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.

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

>
> Und warum ist das nötig? Damit das ewige Gejammere "ich finde immer nur
> Beispiele in C#" endlich aufhört.

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


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

> So kompliziert ist das
> nicht.

Nein, das ist es in der Tat nicht.
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.


> > Wenn ich oder irgendein anderer einen Programmierer einstellt, dann wird
> > es
> > ihm erst mal relativ egal sein, ob der irgendwelche Beispiele aus dem
> > Internet versteht. Ein Programmierer wird eingestellt, um eine oder auch
> > mehrere ganz genau festgelegte Aufgaben zu bearbeiten. Wenn dafür gute
und
> > fundierte VB-Kenntnisse erforderliche sind, dann werde ich den nicht
> > fragen
> > ob und wie gut er C# beherrscht.
>
> Sehe ich anders. Ein Programmierer sollte dazu in der Lage sein, die
> gestellten Aufgaben *selbstständig* zu lösen.

Ich rede von Programmierern, also Leuten, die ihr "Handwerk" (ich nutze ganz
bewusst den Ausdruck Handwerk) von der Pike auf gelernt haben. Dass zu deren
Fähigkeiten selbsttändiges Arbeiten und Lösen von gestellten Aufgaben
gehört, ist eigentlich eine Selbstverständlichkeit. Dass solche Leute
wissen, dass Programmieren und Codieren nicht das selbe meint, setze ich
auch voraus.

> Niemand aber kennt jede
> Schublade von .NET.

Genau so ist es.
Wer sowas behauptet hat sich damit schon selbst disqualifiziert.

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


> Und eine dieser typischen
> Vorgehensweisen ist heute, im Internet nach Beispielen zu suchen, um zu
> sehen, wie andere Leute ähnliche Probleme gelöst haben. Aber eben diese
> Beispiele sind nicht immer in VB.NET, sondern auch in anderen Sprachen
> geschrieben worden.

Ich erwähnte ja schon, dass ich zumindest in meinem Umfeld keine kommerziell
mit VB oder VB.net arbeitenden Programmierer kenne, die in C# geschriebenen
Programmcode nicht interpretieren und nach VB.net umsetzen könnten. Ich
würde also dann schon auch an Leute die bevorzugt in C# programmieren, die
Forderung stellen, dass sie umgekehrt auch VB.net Code in Ihre Sprache
umsetzen können. Wer das als unzumutbar empfindet, müsste konsequenterweise
fordern, dass man überhaupt nur noch eine einzige Sprache zulässt. Warum
dies eine unsinnige Forderung wäre, muss ich wohl nicht näher erklären.

> >> Wenn es Code gibt, der allgemein benötigt wird (siehe Ausgangsthema),
> >> dann
> >> gehört der ins .NET-Framework und nicht in irgendwelche
> > Spezialbibliotheken.
> >
> > Wer bestimmt denn, was "allgemein benötigt" wird?


> Der gesunde Menschenverstand?

Na, den würde ich an dieser Stelle lieber nicht bemühen. Da drängt sich bei
mir immer sehr schnell der Verdacht auf, dass es an wirklichen Argumenten
mangelt.

> Warum sollten die SHFileOperation-Animationen
> VB-Programmierern vorbehalten sein?

Soll sie nicht, ist aber momentan so. Na und?

> Weil die C#-Programmierer schon längst
> die API-Funktionen nutzen?

Das mache ich in mit VB und/oder VB.net erstellten Programmen auch, je nach
Anforderung mehr oder weniger intensiv. Ich sehe darin kein wirkliches
Problem.

> Das macht keinen Sinn.

Na eben, dann kann es doch nur recht sein, wenn bestimmte in VB schon
vorhandenen Features in künftigen Versionen auch in C# verfügbar gemacht
werden.

> Das .NET-Framework ist noch längst nicht vollständig.

Das wird es wohl auch nie werden.
Für den einen bzw. die eine Aufgabenstellung wird es alles oder nahezu fast
alles Notwendige schon jetzt bereitstellen, für den anderen mit einer
anderen Aufgabenstellung werden viele zu wünschenden Dinge eben nicht
verfügbar sein und man wird sich deshalb wie schon immer seine eigenen, für
ganz bestimmte Aufgaben spezialisierten Bibliotheken mit intensivem Gebrauch
von Api-Funktionen oder auch gleich in anderen Sprachen schreiben.

> Die vielen Fragen zu
> den Animationsmechanismen von WinXP, zu Taskbars usw. in den Newsgroups
> (sowohl VB als auch C#) zeigen, dass hier ein Bedarf besteht. Ich meine,
man
> kann zu Recht erwarten, dass man mit einem .NET-Programm die typischen
> Features von XP direkt ohne Win-API verwenden kann. Und zwar unabhängig
von
> der eingesetzten Programmiersprache.

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.

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

Hallo Thomas,

> > Wenn Du es für "kindisch" hältst, dass jemand, der seinen Kunden
gegenüber
> > in der Pflicht steht, darauf achtet, dass deren Programme über einen
> > vernünftigen Zeitraum weiterhin einsatzbereit bleiben sowie gepflegt
und
> > gewartet werden können, dann zeugt das nicht gerade von
Professionalität.
> > Ich weiss nicht, ob Du schon mal mit einem Kunden einen Vertrag über
die
> > Erstellung einer Software erstellt hast, aber Deine Statements hier
lassen
> > mich vermuten, dass Du noch nicht mit solchen Aufgaben betraut
warst.
>> Zum 'Produkt' VB6 hat Microsoft auch immer den Life-Cycle
> und die Strategie zum Wechsel auf .NET seit ~2001 klar kommuniziert.

Ein Projekt, das also z.B. Ende 2000 oder Anfang 2001 konzipiert wurde und
mit grossem zeitlichen und finanziellem Aufwand erstellt wurde, wird dann
vielleicht Ende 2002 erstmalig eingesetzt und irgenwann in 2005 weggeworfen?
Dazu kann ich nur sagen: In Industrieunternehmen sitzen üblicherweise keine
Politiker, denen es egal ist, wo das Geld herkommt, das sie verschwenden.

> Wenn du deinen Kunden mehr/längeren Support versprichst als Microsoft zu
VB6,
> dann ist dies schon dein eigenes Problem.

Ich muss denen nichts versprechen, sondern die stellen ganz konkrete
Forderungen. Und recht haben sie. Die Leute, welche Entscheidungen für oder
gegen die Vergabe von Aufträgen für solche Softwareprojekte treffen, müssen
das ihren Unternehmensleitungen gegenüber begründen und vertreten können.

> Microsoft hat dir nie einen Vertrag gegeben, dass VB6 unendlich haltbar
ist.

Dir ist offenbar nicht so recht klar, in welchen Zeiträumen Unternehmen ihre
Investitionen planen. Niemand redet hier von "unendlich" aber ganz sicher
auch nicht von maximal 2 oder 3 Jahren.

> Entscheidende Tatsachen sind da:
> - die Upgrade-Alternative ist VB.NET

Ja, so reden Werbestrategen oder Leute, die noch nie umfangreiche
Softwareprojekte konzipiert, entwickelt und eingesetzt haben. Praktiker
haben da eine etwas andere Sicht der Dinge.

> - VB6 (IDE & Runtime) läuft noch lange auf aktuellen PCs / Windows-OS,
> nur der Support kostet jetzt halt etwas.
>> Abgesehen davon war/ist VB6 kein 'allgemeiner' Industrie/IT/ISO/ECMA -
Standard
> wie etwa C++, java, oder natürlich C#.
> Daher ist u.U. immer mit zB einer etwas kürzeren 'Lebenszeit' zu rechnen.

Was müssen in Unternehmen wie SIEMENS, OSRAM, Siteco, Daimler Benz und
vielen anderen namhaften Unternehmen und einer ganzen Reihe von Behörden nur
für dumme und uneinsichtige Leute sitzen, dass die doch ausgerechnet immer
wieder alle möglichen Softwareprojekte ausgerechnet mit VB oder nun langsam
auch mit VB.net konzipieren. In welcher abgehobenen Welt lebst Du denn?

> >> 4.) die My-Krücke ist mit den VB6-Fn Kompat.-Krücken vergleichbar;
> >> Noch fataler, das Problem hat sich dadurch bereits
verdreifacht!...
> > Welches Problem denn?
> > Wenn ich es recht verstehe, hast nur Du damit ein Problem.
>
> lies bitte nochmals:
> Blog von Paul Vick, Microsoft VB.NET-Architekt :
>
> [..]
>
> "But it has a NOT SO GOOD side.
> It means VB.Net programmers will be learning and using a ...
> *different* object model for many tasks"

Aha, und weil der das so schreibt, ist das so und für die gesamte Welt ein
Problem?
Geübte VB-Programmierer haben nach meiner Erfahrung aber offenbar gar kein
Problem damit, irgendwelche Dinge zu lernen. Ich verstehe eigentlich auch
gar nicht so recht, warum es Dich so sehr bekümmert, dass VB-Programmierer
irgendwas lernen müssen, wo Du doch offenbar ohnehin nur C# als alleinig
seeligmachende Programmiersprache betrachtest. Siehst Du Dich nun als
Programmierer/Softwareentwickler oder als Missionar?

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