Man sollte doch nicht alle Tasten gleichzeitig drücken ...

Hallo Harald,

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

sicher bekommt man heraus, was die Funktion macht. Hätte ich dasselbe
Beispiel geschrieben, hätte ich aber auch in VB.NET die DateTime-Struktur
verwendet, ohne damit mehr Aufwand zu haben oder mehr Code zu produzieren.
Ein Nicht-VB-Programmierer könnte diesen Code dann sofort begreifen, ohne
nach den Funktionen suchen zu müssen.

Sieh es doch auch einmal aus meiner Sicht. Als Dozent muss ich wechselweise
Seminare zu C# und VB.NET halten. Abgesehen von der Syntax brauche ich
Codebeispiele, die sich in den Sprachen nicht unterscheiden. Warum sollte
ich in C# DateTime/TimeSpan benutzen und in VB.NET etwas ganz anderes? Da
würde ich mich nur selbst verwirren.

Gruß
Joachim

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
> 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.

Diese Gelegenheitsprogrammierer und Office-Entwickler brauchen und wollen
m.E. keine Programmiersprache, die vollständig objektorientiert ist, da
ihnen bei ihrer Tätigkeit durch erzwungene Objektorientierung keine
spürbaren Vorteile entstehen. Ich zitiere hier nur exemplarisch:

<URL:http://www.dicks-blog.com/archives/2005/03/09/support-classic-vb/#comment-9262>:

Hallo Joachim,

> Sieh es doch auch einmal aus meiner Sicht. Als Dozent muss ich
> wechselweise Seminare zu C# und VB.NET halten. Abgesehen von der Syntax
> brauche ich Codebeispiele, die sich in den Sprachen nicht unterscheiden.
> Warum sollte ich in C# DateTime/TimeSpan benutzen und in VB.NET etwas
> ganz anderes? Da würde ich mich nur selbst verwirren.

Na, wenn *das* Dein Hintergrund ist... dann würde ich an Deiner Stelle
womöglich bei Äußerungen zu diesem Thema immer vorsorglich dazu schreiben:
"Für (mich als) Dozenten..."
;-)

Aber, im Ernst: Niemand behauptet doch, man *müsse* diese VB-spezifischen
Funktionen benutzen? Wenn es beispielsweise für (Dich als) Dozenten
einfacher ist, sich in beiden Welten nur auf das Framework zu beschränken -
warum auch nicht?

Was mich nur an dieser und ähnlichen Diskussion(en) immer wieder stört, ist
der von einigen (ob Du dazuzurechnen bist oder nicht, ist jetzt egal)
verkündete Tenor der Abqualifizierung derjenigen, die sich nicht sklavisch
aufs Framework beschränken oder/und darüber hinaus gehende Erweiterungen
wünschen bzw. sich darüber freuen.

Viele Grüße

Harald M. Genauck

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

Hallo Herfried,

> Der Einarbeitungsaufwand in .NET ist relativ hoch und wird auch durch 'My'
> nicht merklich reduziert, sondern erhöht, da man mit 'My' alleine nicht
> auskommen kann. Excel-Entwickler bspw. benötigen ungefähr jene Funktionen,
> die "Microsoft.VisualBasic.dll" bereitstellt und kaum mehr.


ja, deswegen sage ich ja, dass für eine VBA.NET-Version viele
Spracherweiterungen eingebaut werden könnten, die es zu 99,9% kompatibel zur
VBA-Programmierung machen, aber die Komplexität des Frameworks weitestgehend
verbergen. Und wenn es denen hilft, dann sollen sie auch Form1.Show aufrufen
können. Professionelle Programmierer werden statt dessen lieber zur
Profi-Variante greifen, die näher am .NET-Konzept ist und eben keine
derartigen Sonderfälle vorsieht.

Gruß
Joachim

Hallo Joachim,

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

Weil eben die "klassische" Forms-Bibliothek dem Stand-Alone-VB vorbehalten
ist, während in VBA-basierten Umgebungen eine andere Forms-Bibliothek
verwendet wird.

So wie ich es zurückverfolgen kann, ist der Unterschied historisch bedingt.
Die (heutige VBA-)Forms-Bibliothek ist im Scripting-Umfeld entstanden, weil
eine von dem bis dahin monolithischen VB (VB3) unabhängige Forms-Bibliothek
nicht verfügbar war. Das war etwa die Zeit (ca. 1994), als in den
MS-Office-Anwendungen die ersten VBA-Ansätze stattfanden (Excel 5) und wohl
auch, als noch das (für Windows 95 ursprünglich geplante) MSN-Projekt als
proprietärer "Inter"net-Vorläufer in der Mache war. Das Scripting hierfür
ging dann später in der unseligen ActiveX-Initiative für den IE auf. VBA
war seit dieser Zeit der Vorreiter, während das Stand-Alone-VB ab VB4 auf
dessen Entwicklungen aufsetzte (so gab es etwa ein VBA6 schon geraume Zeit
vor VB5/6). Glücklicherweise hat man sich hier aber dafür entschieden, aus
voll und ganz berechtigten Kompatibilitätsgründen das bisherige
Forms-Modell - in eine eigene Bibliothek ausgelagert - aufrecht zu
erhalten, und nicht das (m.E. etwas verunglückte, holprige
VBA-Forms-Modell) zu übernehmen.

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

Es gibt aber auch sehr viele, die ihre ersten Schritte im VBA-Umfeld getan
haben und dann zum "vollwertigen" Stand-Alone-VB gewechselt sind, weil sie
einfach mehr wollten, als die eher in sich geschlossen wirkenden
VBA-Umgebungen zu bieten hatten/haben.

> Diese Gelegenheitsprogrammierer gehen, wie Arne gestern geschrieben hat,
> in .NET unter und werden ohne Hilfe wie My & Co nicht klar kommen.

Sie würden aber wohl noch weniger mit C# klar kommen...
;-)


Viele Grüße

Harald M. Genauck

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

Hallo Joachim,

>> Der Einarbeitungsaufwand in .NET ist relativ hoch und wird auch durch
>> 'My' nicht merklich reduziert, sondern erhöht, da man mit 'My' alleine
>> nicht auskommen kann. Excel-Entwickler bspw. benötigen ungefähr jene
>> Funktionen, die "Microsoft.VisualBasic.dll" bereitstellt und kaum mehr.

> ja, deswegen sage ich ja, dass für eine VBA.NET-Version viele
> Spracherweiterungen eingebaut werden könnten, die es zu 99,9% kompatibel
> zur VBA-Programmierung machen, aber die Komplexität des Frameworks
> weitestgehend verbergen.

Wie schon selber zu Lernkurven anmerktest: Wenn sie dann von schlichter
VBA-.NET-Programierung zu "richtiger" VB.NET-Programmierung wechseln
wollen, haben sie halt dann erst die Lernkurve vor sich. Das wäre m.E. kein
Unglück, aber damit widersprichst Du Dir wohl ein wenig selber.

> Professionelle Programmierer werden statt dessen lieber zur
> Profi-Variante greifen, die näher am .NET-Konzept ist und eben keine
> derartigen Sonderfälle vorsieht.

Sollen sie doch, wenn sie *wollen*... Aber warum bloß in aller Welt sollten
sie denn *müssen und nicht anders dürfen*?


Viele Grüße

Harald M. Genauck

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

> Gibt es wirklich Entwickler, die darauf achten, nur die in der CLI
> enthaltenen Klassen zu benutzen?


leider ist heute die Jäger-und-Sammler-Mentalität
unter vielen Programmierern weit verbreitet:
Man krallt sich blind jeden nur erdenklichen Code/Library/Wrapper,
egal was für Nebenwirkungen & Spätfolgen es kostet.

Dabei kommt man mit den echten .NET Framework Klassen
schon sehr weit, auch wenn es halt mal 'ne Zeile mehr braucht.
Dafür ist das Gesamtresultat 'Lean & Clean'.


> Durch Verwendung von 'My' entsteht doch ".NET-Code".

".NET-Code" sagt noch rein gar nichts aus.
Schon eher, in welcher Assembly der Code enthalten ist.
(massgebend ist da zuerst die mscorlib.dll)

Hallo Harald,

hätte man zwei Produkte, wüsste jeder von Anfang an, worauf er sich
einlässt. Mit VBA.NET käme man schnell mit seinen alten VBA-Kenntnissen
weiter, aber eben nie zu .NET. Mit VB.NET Prof. gäbe es nicht so viele
Umstiegshilfen, dafür aber auch keine Scheinwelt, die nicht jeder erkennt.

Gruß
Joachim

Hallo Harald,

> Sie würden aber wohl noch weniger mit C# klar kommen...

habe ich irgendwo erwähnt, dass Gelegenheitsprogrammierer von VB auf C#
umsteigen sollten?
Es gibt auch immer noch Leute an den Hochschulen, die mit Fortran
programmieren. Oft auch Gelegenheitsprogrammierer, die über
Assistentengenerationen hinweg alte Programme geerbt haben und immer weiter
entwickeln.

Gruß
Joachim