Hallo Joachim,

> Als .NET-Programmierer sollt man .NET-Beispielcode nachvollziehen können,
> der entweder in VB.NET oder C# geschrieben worden ist. VB-Programmierer,
> die sich auf My und Basic-Altlasten eingeschossen haben, werden dann 90%
> der Beispiele im Internet usw. nicht verstehen können.

Doch, werden sie - zumindest die engagiert(er)en bzw. professionell(er)en
unter ihnen werden keine Probleme haben, da sie das Framework durchaus
kennen und schätzen dürften.

Eher sehe ich das Problem auf Seiten etwa von C#-Entwicklern, My
enthaltende VB-Code-Beispiele nachvollziehen zu können.

SCNR: Das sei ihnen aber auch gegönnt - schließlich dürfen wir VB'ler uns
ja eh schon mit jeder Menge C#-Beispiel-Code herumschlagen...
;-)


Viele Grüße

Harald M. Genauck

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

Hallo Herfried!

Herfried K. Wagner [MVP] schrieb:
> Wie ich bereits sagte: Das .NET Framework garantiert einen gewissen
> Unterbau (Datentypen, Schnittstellen und Basisklassen, wie etwa bei
> Datenströmen), die natürlich an den Zweck angepasst in verschiedensten
> Frameworks und Bibliotheken zum Einsatz gelangen können. 'My' und
> 'Microsoft.VisualBasic' arbeiten ja genauso mit 'String', 'DateTime',
> 'CultureInfo' und anderen Klassen des .NET Framework und erfinden
> deshalb das Rad nicht auf andere Art und Weise neu. Die Basisframeworks
> für .NET machen verschiedene Dinge auf mehr oder weniger ähnliche Art
> und Weise, nicht umgekehrt. Das ist der grosse Vorteil von .NET.

Ich habe die Diskussion bis hierhin verfolgt und bin nicht recht
glücklich damit.

Ich weiss, dass bei Microsoft ein Bewusstsein besteht, dass man derzeit
den "Hobby-Programmierer-Bereich", den Du weiter oben schon als Schüler,
Studenten, etc. beschrieben hast, vernachlässigt. Ich würde diesen
Bereich um den ganzen wissenschaftlichen Bereich ergänzen, sowohl Natur-
als auch Geisteswissenschaften, wo viele Leute einfach kleine und
größere Automationslösungen brauchen, ohne dass man dazu "Programmierer"
im engeren Sinne braucht, sondern in erster Linie Fachwissenschaftler,
die nur "nebenher" programmieren, um Ihre täglichen Probleme zu lösen.
..NET - egal, ob C# und VB.NET ist für diese Clientel eine Nummer zu
groß, VB6 war es nicht und da klafft eine Lücke.

Nun wird die Öffnung nach unten aber sicher nicht sinnvoll zu erreichen
sein, indem man BCL-Klassen durch "My"-Klassen wrappt. Das ist der
komplett falsche Weg. Der "Unterbau", von dem Du sehr richtig sprichst,
ist auch nicht die BCL, sondern die CLR.

Es gibt derzeit auf hoher Ebene (was die Position der Diskussionsführer
als auch das intellektuelle Niveau angeht) eine Diskussion über die
Tauglichkeit der CLR als Basis für dynamische Sprachen wie Python oder
Ruby. Die Tatsache, dass das CLR-Team Jim Hugunin eingestellt hat, sowie
die permanenten Äußerungen als auch Implementierungen von -
unbestreitbar führenden Architekten - wie Chris Anderson oder Don Box,
aber auch vielen Anderen, sprechen dafür, dass man sich bei Microsoft
offenbar ernsthaft Gedanken über dynamische Sprachen macht, die die
offensichtliche Lücke nach unten schließen sollen.

Aus dieser Perspektive erscheint mir die ganze Diskussion hier etwas
deplaziert - wie so oft wird hier ausschließlich aus der
Froschperspektive argumentiert - "My" ist gut, "My" ist nicht gut - aber
das Problem liegt doch ganz woanders. Du hast völlig richtig
diagnostiziert, dass Microsoft im Hobby-Bereich ein Konzept und ein
Produkt fehlt, aber das Problem geht weit tiefer, als dass man es mit
dem "My"-Namespace lösen könnte, welchen Du leider völlig falsch mit
"RAD"-Features konnotierst. Es geht hier nicht um "My"-Kinkerlitzchen.
Es geht vielmehr um einen notwendigen Wechsel des Programmiermodells.
Ich jedenfalls wäre nicht allzu überrascht, wenn Microsoft demnächst mit
einer Python- oder Ruby-CTP auf uns zukommt und es wäre zweifellos der
richtige Schritt.

In der Erwartung, dass nun alle über mich herfallen...

Gruß

Arne Janning

Hallo Arne,

[..]
> Froschperspektive argumentiert - "My" ist gut, "My" ist nicht gut - aber
> das Problem liegt doch ganz woanders. Du hast völlig richtig
> diagnostiziert, dass Microsoft im Hobby-Bereich ein Konzept und ein
> Produkt fehlt, aber das Problem geht weit tiefer, als dass man es mit dem
> "My"-Namespace lösen könnte, welchen Du leider völlig falsch mit
> "RAD"-Features konnotierst. Es geht hier nicht um "My"-Kinkerlitzchen. Es
> geht vielmehr um einen notwendigen Wechsel des Programmiermodells. Ich
> jedenfalls wäre nicht allzu überrascht, wenn Microsoft demnächst mit
> einer Python- oder Ruby-CTP auf uns zukommt und es wäre zweifellos der
> richtige Schritt.

Ich sehe keinen großen Unterschied zwischen der Philosophie von und Basic
und Python. Eher im Gegenteil: Python scheint mir lediglich das Resultat
einer Vereinfachung aus der Sicht von C/C++ zu sein, die Basic zufällig bis
auf leichte Syntax-Unterschiede gleich gekommen ist. Dynamische Datentypen
mit impliziter Typumwandlung kennt VB auch - in VB Classic waren es die
Variants, in .NET ist es schlicht Object. Bezüglich von anscheinend
"jüngeren" Sprachelementen wie Listen, Dictionaries usw. ist VB.NET sogar
besser dran als Basic an sich und VB Classic - und als Python.

Wenn man in VB.NET in alter VB-Tradition schreibt und die VB-Bibliothek wie
gewohnt nutzt, vermisst man eigentlich recht wenig RAD"iges", im Vergleich
zu VB Classic. My ist da eher nur noch ein Sahnehäubchen obenauf.

Was VB'ler bisher in VB Classic wohl am meisten vermisst haben, ist der
Zugriff auf System-Features ohne "außerhalb" der Sprache und des Compilers
liegende API-Tricksereien. Und diese Zugriffe sind mit dem .NET-Framework
nun allemal gegeben. Der Großteil von My bietet hier nur semantische
Abkürzungen - nicht lebenswichtig, aber eben nett.

Die "Leichtigkeit" der Sprache ist eine Sache, eine andere ist das
Entwicklen von Anwendungen mit GUI und Nutzung von System-Features. Und da
werden auch dynamische Sprachen wie Python und eben auch VB aus sich heraus
kaum RADiger werden können. Das geht nur über zusätzliche Bibliotheken, die
entweder auf dem .NET-Framework aufsetzen oder formal in selbiges
integriert werden. Ob nun der Namespace einer solchen Bibliothek mit
"System" beginnt (und damit scheinbar die Integration ins Framework
"beweist"), oder ob er "Kuwiopaz Dollbunt" lautet, oder ob er "Microsoft
Visual Basic" heißt, spielt wohl kaum ernsthaft eine Rolle.

Solche RAD-Ideen bietet übrigens ASP.NET längst jede Menge: Die
Standard-Objekte Application, Context, Request, Response, Cache, Server
stellen im Prinzip genau das dar, was wohl My für eine Desktop-Anwendung
sein soll. Und sie sind zum einen auf vielerlei redundantem Wege greifbar
und kapseln zum anderen auch eine ganze Menge von dem, was auch en Detail
auf anderem Framework-Weg auf "Low-level"-Ebene greifbar wäre. In ASP.NET
2.0 sind sogar noch mehr RAD-Elemente hinzugekommen: LogIn, Profile, Menu
und WebParts. Alles Dinge, die man längst auch schon in ASP.NET 1.x in
"reinstem" Framework mit viel Aufwand hatte zu Fuß erledigen können (und
müssen, wenn man ernsthafte Web-Anwendungen entwickeln wollte). Zu ASP.NET
habe ich allerdings und wundersamerweise noch keine Klagen der
Framework-Puristen gehört...

Die "große Sünde" hat Microsoft wohl damit begangen, My in den VB-Namespace
zu legen, statt in den System-Namespace...


Viele Grüße

Harald M. Genauck

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

> Die "große Sünde" hat Microsoft wohl damit begangen, My in den VB-Namespace
> zu legen, statt in den System-Namespace...


nein, Microsoft hat so bewusst die grosse ('lernfähige') Mehrheit
der Kunden vor der My-Krücke bewahrt...

Hallo Harald!

"Harald M. Genauck" <hmg.ng.entfernen> schrieb:
> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
> VB-Namespace zu legen, statt in den System-Namespace...

Nun, das wird nicht zuletzt damit zusammenhängen, dass 'My' zum Teil auch
ein Funktionsmerkmal des Compilers ist. Zumindest diese Teile ('My.Forms')
lassen sich schwer in das .NET Framework integrieren.

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>> Die "große Sünde" hat Microsoft wohl damit begangen, My in den
>> VB-Namespace
>> zu legen, statt in den System-Namespace...
>
> nein, Microsoft hat so bewusst die grosse ('lernfähige') Mehrheit
> der Kunden vor der My-Krücke bewahrt...

.... diese Mehrheit versucht, wie man an 'That' erkennen kann, krampfhaft,
die Funktionalität von 'My' zu nutzen. 'My' ist, und das kannst du drehen
oder wenden wie du willst, ein Punkt, der klar für den Einsatz von VB.NET
spricht.

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>>>> 'My' ist nur eine primitive, sinnlose Namespace-Duplizierung.
>>
>> Deutlich kürzer mit My.
>> My ist kürzer und, zugegeben, einfacher zu finden.
>
> ob kürzerer oder einfacherer Namen ist egal,
> es geht um die 'inhaltliche' Namespace-Duplizierung.
>
> Jeder mit realer SW-Entwicklungs - Erfahrung weiss,
> dass dies garantiert ins Chaos führt.

Ins Chaos würde es führen, wenn die beiden "Zugriffssichten" zueinander
inkompatibel wären, aber gerade das sind sie nicht.

Hallo Arne!

"Arne Janning" <spam-me.here.iasyncresult> schrieb:
>
> Ich habe die Diskussion bis hierhin verfolgt und bin nicht recht glücklich
> damit.
>
> Ich weiss, dass bei Microsoft ein Bewusstsein besteht, dass man derzeit
> den "Hobby-Programmierer-Bereich", den Du weiter oben schon als Schüler,
> Studenten, etc. beschrieben hast, vernachlässigt. Ich würde diesen Bereich
> um den ganzen wissenschaftlichen Bereich ergänzen, sowohl Natur- als auch
> Geisteswissenschaften, wo viele Leute einfach kleine und größere
> Automationslösungen brauchen, ohne dass man dazu "Programmierer" im
> engeren Sinne braucht, sondern in erster Linie Fachwissenschaftler, die
> nur "nebenher" programmieren, um Ihre täglichen Probleme zu lösen. .NET -
> egal, ob C# und VB.NET ist für diese Clientel eine Nummer zu groß, VB6 war
> es nicht und da klafft eine Lücke.
>
> Nun wird die Öffnung nach unten aber sicher nicht sinnvoll zu erreichen
> sein, indem man BCL-Klassen durch "My"-Klassen wrappt. Das ist der
> komplett falsche Weg.

Genau das konstatiere ich auch. 'My' wird bisherige VB6/VBA-Benutzer kaum
anlocken können, da die Programmier/sprachen/ VB.NET und C#
überdimensioniert sind. Oder anders: Vielleicht sogar Objektorientierung als
Werkzeug überdimensioniert ist und Objektbasiertheit, wie aus VB6 bekannt,
vollkommen ausreicht.

> Der "Unterbau", von dem Du sehr richtig sprichst, ist auch nicht die
> BCL, sondern die CLR.

Ich bezog mich mit "Unterbau" darauf, dass z.B. 'My.User.CurrentPrincipal'
den Typ 'System.Security.Principal.IPrincipal' besitzt und nicht etwa einen
dazu inkompatiblen Typ. Daher ist es m.E. vollkommen egal, ob man nun direkt
die Funktionalität aus der "Sicht" des .NET Frameworks oder jener von 'My'
nutzt.

>[Dyamische Sprachen]
> Aus dieser Perspektive erscheint mir die ganze Diskussion hier etwas
> deplaziert - wie so oft wird hier ausschließlich aus der Froschperspektive
> argumentiert - "My" ist gut, "My" ist nicht gut - aber das Problem liegt
> doch ganz woanders.

Nun, 'My' gibt es in einigen Monaten, alles andere ist Zukunftsmusik. Ich
beschränke mich mit meiner Einschätzung von 'My' erst einmal auf den status
quo.

>> nein, Microsoft hat so bewusst die grosse ('lernfähige') Mehrheit
>> der Kunden vor der My-Krücke bewahrt...
> ... diese Mehrheit versucht, wie man an 'That' erkennen kann, krampfhaft,
> die Funktionalität von 'My' zu nutzen.


'That' ist eine rein private Spielerei (lies: Spinnerei)
einer Dritt-Firma.
Also sozusagen eine Krücke für die 'My'-Krücke.

Die Mehrheit der .NET Programmierer ist intelligent
und fällt nicht auf solche (My/That) Krücken rein.
Das überlassen wir schon ganz dir alleine.

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>>> nein, Microsoft hat so bewusst die grosse ('lernfähige') Mehrheit
>>> der Kunden vor der My-Krücke bewahrt...
>>
>> ... diese Mehrheit versucht, wie man an 'That' erkennen kann, krampfhaft,
>> die Funktionalität von 'My' zu nutzen.
>
> 'That' ist eine rein private Spielerei (lies: Spinnerei)
> einer Dritt-Firma.
> Also sozusagen eine Krücke für die 'My'-Krücke.
>
> Die Mehrheit der .NET Programmierer ist intelligent
> und fällt nicht auf solche (My/That) Krücken rein.
> Das überlassen wir schon ganz dir alleine.

Mich würde es nicht wundern, 'That' (oder wie auch immer es heisst) in
Orcas-VC# zu sehen -- aufgrund von positiven Kundenrückmeldungen
und -wünschen.

> Mich würde es nicht wundern, 'That'...in Orcas-VC#

und mich wundert es nicht,
dass du davon träumst...
(wie auch schon von VB.COM, u.v.a. Unsinnn)

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>> Mich würde es nicht wundern, 'That'...in Orcas-VC#
>
> und mich wundert es nicht,
> dass du davon träumst...

<URL:http://www.panopticoncentral.net/archive/2004/04/23/991.aspx>

| Inevitably, the best ideas of one language will be cribbed by
| the other language. If 'My' turns out to be a smashing success,
| I'd expect C# to come sniffing 'round it the next time around.

Da jetzt, auch im C#-Lager, bereits viele von 'My' schwärmen, stehen die
Chancen gar nicht so schlecht, schon alleine aus dem Grund, dass C#ies auch
in Zukunft in der Lage sind, VB.NET-Code zu lesen.

Addendum:

Übrigens:

C# Programmer's Reference -- How to: Use the 'My' Namespace
<URL:http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/e7152414-0ea5-4c8e-bf02-c8d5bbe45ff4.asp>

> <URL:http://www.panopticoncentral.net/archive/2004/04/23/991.aspx>
> Da jetzt, auch im C#-Lager, bereits viele von 'My' schwärmen


ROFL,
krasser kannst du nicht daneben liegen (und das von einem MVP!) ...
www.panopticoncentral.net
ist der _private_ Blog von Paul Vick, VB.NET-Archtitekt!

Schon erstaunlich, wie _du_ da plötzlich doch völlig kritiklos
dessen Werbung & Rechtfertigung für die 'My'-Kurzschlusshandlung
akzeptierst...
(wie gesagt, mich wundert all dies bei dir nicht mehr)


Paradoxerweise steht in jenem Blog auch das _zentrale_ Übel:

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

ROFL, ROFL, ROFL ...


In keinster Weise hat die 'My'-Krücke etwas mit C# zu tun.

Hallo Herfried,

> C# Programmer's Reference -- How to: Use the 'My' Namespace
> <URL:http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/e7152414-0ea5-4c8e-bf02-c8d5bbe45ff4.asp>


das geht einher mit Bauchschmerzen und Brechreiz :-(

Zitat daraus:

"Not all the classes in the My namespace may be called from a C#
application: for example, the FileSystemProxy class is not compatible. In
this particular case, the static methods that are part of
System.IO.FileSystem (also contained in the VisualBasic.dll) can be used
instead.

For example, here is how to use one such method to duplicate a directory:"

Wie war das noch mit der Kompatibilität von My.Dingsbums?

Wie Thomas schon sagte: Alles mehrfach definiert - vieles passt nicht
zusammen - mehrfacher Lernaufwand ...

Gruß

Joachim