Ein wichtiger Punkt könnte sein das die Compatibilität zu VB6 irgendwann eingestellt wird.

VB6 ist nicht Objektorientiert, und passt deswegen nicht in Net.

Split kommt anscheinend aus dem "Nichts" währen Split aus Net der Klasse String zugeordnet ist.

String.Split. Das hat was mit konformer Programierung zutun.

RushDen schrieb:

Das erste ist ja VB 6

Nein, das ist pures VB.Net.

Die einzigen Sachen, die "veraltetes" VB6 sind, findet man im VisualBasic.Compatibility.Vb6 Namespace. Die dienen eigentlich nur dazu alto Projekte zu importieren und sollen deshalb nie verwendet werden - sagt auch schon Microsoft.
Die anderen sogenannten "bösen" Funktionen sind ganz normale VB.Net Methoden, die häufig nur "Abkürzungen" darstellen. Das ganze Gemeckere dagegen kommt meist von Leuten, die C# sowieso für die "bessere" Sprache halten.



In .Net führen immer (!) viele Wege zum Ziel. Man möge den wählen, der Sinn macht und dem eigenen Gusto nahekommt.

RushDen schrieb:

iwo

Irgendwo steht immer viel und immer auch viel Blödsinn ...

Glaube nie jemandem, der sagt "das ist so", wenn er es nicht begründen kann! (gilt nicht nur im Bezug auf VB.Net, sondern ist eine Lebensweisheit).

RushDen schrieb:

wo EDR sagt das die Funktion veraltet

Wie kann sie veraltet sein, wenn sie im aktuellen FW 4.5 enthalten ist und nicht als "obsolete" markiert ist?
msdn.microsoft.com/de-de/libra…ings.split(v=vs.110).aspx

Alle ECHT veralteten Sachen findet man hier:
msdn.microsoft.com/en-us/library/ee461502(v=vs.110).aspx

Der Micosoft.VisualBasic-Namespace ist tatsächlich nicht veraltet, der Grund, warum man ihn nicht verwenden sollte, ist aber auch ein ganz anderer. Er existiert aus dem selben Grund, warum Strict Off existiert, nämlich um alten VB6-Code zu unterstützen. Alle Funktionen dort wurden in .Net "hineingezwungen", obwohl sie eigentlich nicht da reinpassen. Deshalb hat auch nur VB überhaupt diesen Namespace, andere Sprachen brauchen ihn nicht.
Und das ist auch der Grund, warum C# in der Tat die bessere Sprache ist, weil C# nicht durch irgend welchen veralteten Kram versaut wurde, sondern sich völlig auf den neuen Weg begibt.

Ich persönlich würde nie soweit gehen zu behaupten, eine Sprache (hier: C#) sei besser als eine andere (hier: VB.NET).

Von daher würde ich das nie als Grund akzeptieren, warum etwas nicht benutzt werden sollte. Aber wenn wir schon dabei sind: Ich persönlich meide den Microsoft.VisualBasic Namespace ebenfalls (soweit es geht), weil ich mir damit einfach die Möglichkeit offen halte, den Code nach Belieben auch nach C# übernehmen zu können, ohne in C# extra einen Verweis auf den VisualBasic-Namespace hinzufügen zu müssen.

Ich sag das ja nicht einfach nur so. Man nehme von VB.Net den Microsoft.VisualBasic-Namespace, den My-Namespace und Strict Off weg und füge Pointer (unsicheren Kontext) hinzu und man erhält C#.

Visual Basic ist für mich eine Sprache die sich vorallem an Anfänger richtet... Darum auch diverse "Vereinfachungen" (e.g. standard Option strict Off)...
Das Problem an dieser Anfängerfreundlichkeit ist, dass es später schwerer wird vernünftigen Code zu lernen.

Dennoch ist VisualBasic (mit Option Strict ON) meiner Meinung nach eine gute Sprache und nicht "schlechter" als C#

Ob eine Sprache schlechter oder besser ist, steht garnicht zur Debatte. Es liegt immer am Programmierer wie die Architektur aussieht, auch in C# kann dreißigtausend Methoden aus dem Nebel auftauchen lassen und eine OO-Struktur zunichte machen. VB.Net und C# sind fast identisch, bis auf die Pointer unterstützung die in VB.Net wohl vergessen wurde.

Der Grund für diie Abwärtskompatibilität ist mir trotzdem nicht ganz bewusst, imho hätte man dem Compiler auf keinen Fall die Strict-Flag geben dürfen.

Aber es fällt doch auf, dass im Namespace Microsoft.Visualbasic lauter unnützer Schrott drin ist.
Etwa die Strings.Split - Funktion.
Und ich sage das auch nicht unbegründet, denn da binnich zu 100% Picoflops Meinung (inklusive des in der Klammer):

picoflop schrieb:

Glaube nie jemandem, der sagt "das ist so", wenn er es nicht begründen kann! (gilt nicht nur im Bezug auf VB.Net, sondern ist eine Lebensweisheit).

Meine Begründung im Falle von Split ist: Das OOP-Paradigma ist der nur prozeduralen Programmierung vorzuziehen, wann immer es möglich ist. Im Falle String ist es möglich - bietet sich sogar an: Ein String ist ein Objekt, und weiß selbst, wie er sich splittet.
Ausserdem programmiert sich das doch viel leichter - man setzt einen Punkt hinter den String, und dann bietet Intellisense alle Optionen an, die die String-Klasse halt anbietet.
Noch ein Vorteil ist, wenn man sich mit String.Split auseinandersetzt, etwa im ObjectBrowser die verschiedenen Überladungen anguckt, dann lernt man dabei die String-Klasse besser kennen - man sieht ja auch die anneren Optionen.
Also das hat eine Systematik und innere Logik, dass inne String-Klasse die String-Operationen zu finden sind. Hingegen das Microsoft.Visualbasic.Strings - Modul ist etwas unsystematisches, das könnte ja auch BillisKleinerStringFummelLaden heißen.

Ähnlich sind meine Ablehnungs-Begründungen zu fast allem, was sich in diesem IMO misratenen Namespace findet - obs sich nun um DateTime-Operationen handelt oder Dateizugriffe - im richtigen Framework gibts besseres und systematischer organisiert.
Ich mache dabei sogar 2 Ausnahmen: den Textfieldparser und die ControlChars-Enumeration.
Aber mehr Nützliches habich bisher in Microsoft.Visualbasic nicht gefunden.

In einem anneren Punkt bin ich wieder ganz anderer Meinung als picoflop:

In .Net führen immer (!) viele Wege zum Ziel. Man möge den wählen, der Sinn macht und dem eigenen Gusto nahekommt.

Na gut, wörtlich genommen ist das richtig.
Tatsächlich kann man aber bei mehreren Lösungen fast immer untersuchen und identifizieren, welches bessere und welches schlechtere Wege sind. Und da binnich numa quasi-dogmatisch:

tautologisches Dogma schrieb:

"Hat man die Wahl zwischen einem guten Weg und einem besseren, dann hat man keine Wahl."

(weil logisch nimmt man den besseren).

Hin und her, bla und blub, der Fakt bleibt bestehen, dass die Befehle in ms.vb KEINE VB6 Befehle sind, sondern reinstes .Net. Ob da jetzt unheimlich viele Sachen drin sind, die hilfreich sind, mag bezweifelt sein, aber die immer wieder anzutreffende Verteufelung lehne ich ab.

Ja, natürlich ist es .Net, sonst würde es ja nicht unter .Net laufen.
Aber es ist verkrüppeltes .Net, man hat .Net-Paradigmen genommen und sie verstümmelt und in andere Paradigmen hineingequetscht. Sonst rät man doch auch jedem, schön objektorientiert zu programmieren, warum dann nicht auch hier?