vb.net, C# oder Java?

  • Allgemein

Es gibt 139 Antworten in diesem Thema. Der letzte Beitrag () ist von MrTrebron.

    Der Autor des Artikels hatte wohl leider nicht genug Ahnung von VB.Net und C#. Denn es fehlen features in VB.Net, die in C# vorhanden sind, die ich immer mal wieder gebrauchen kann. Also Nein, es ist nicht völlig egal, denn es gibt einen Unterschied. Oder wirst du mir Basic aufdonnern, nur weil man damit theoretisch genau so viel machen kann wie mit modernen OOP Sprachen? Vermutlich nicht.(Genau deshalb gibt es auch meinerseits Schläge gegen Java, da es einfach mMn grundlegenden Features fehlt). Natürlich werde ich Java Programmieren, wenn es aus irgendeinem Grund erforderlich ist - welcher auch immer das sein sollte.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    jvbsl schrieb:

    Der Autor des Artikels hatte wohl leider nicht genug Ahnung von VB.Net und C#.

    Der gute Herr Schwichtenberg hat auch bei ASP.NET eine - sagen wir es kompatibel zu diesem Forum hier und der deutschen Auffassung von Recht - "merkwürdige Fachkompetenz", die er auch regelmäßig in seinen dicken Wälzern veröffentlicht ^^ .
    es fehlen features in VB.Net, die in C# vorhanden sind

    Und andersrum ;)
    Aber grundsätzlich stimme ich da zu. Es gibt eben solche Unterschiede und deshalb macht es sehr wohl einen Unterschied, welche Sprache man verwendet. Klar, die Prinzipien funktionieren häufig in mehreren Sprachen. In Java gibt's genauso wie in .Net Interfaces, Klassen, Vererbung, Methoden und Felder, aber ich würde nie freiwillig in Java programmieren. Da fehlen einfach Dinge wie Wertetypen, Properties, Events, ein anständiger Support für generische Typen, uvm.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Ich würde nicht sagen, dass er keine Ahnung hat. Der Artikel ist einfach veraltet. Allein der Vergleich zwischen den Properties stimmt einfach nicht mehr, denn VB beherrscht Auto-Properties genauso und die sind mMn noch kürzer&einfacherer als in C#. Außerdem seh ich in dem Beispiel von den Properties, dass die Properties Arrays sind während die privaten Variablen keine sind, kann aber auch sein, dass ich mich da irre.

    Aber jetzt hier wieder in einem alten Thread einen Glaubenskrieg von Zaun zubrechen halte ich einfach für ungeeignet und ich frage mich immer wieder, warum man alte Threads ausgraben muss.

    LG
    Bei normalen Properties funktioniert dies schon, aber nicht zB bei Readonly Properties:

    VB.NET-Quellcode

    1. Private _Test As String
    2. Public ReadOnly Property Test As String
    3. Get
    4. Return _Test
    5. End Get
    6. End Property

    C#-Quellcode

    1. public string Test { get; private set; }


    lg
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten
    @MrTrebron gar keine Ahnung hab ich nicht gesagt, nur eben nicht ausreichend. Und weil man MVP ist und Dozent(sagt sogar noch weniger) heißt das nicht, dass man alles weiß, oder genügend über das weiß, was man gerade so daher redet. Nur weil ich Super gute Noten in Mathe hab weiß ich trotzdem nicht was in der Politik so abgeht...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    @jvbsl
    Von Haus aus Support für Einzelinstanzanwendungen
    Catch When
    Indexierte Properties
    Standard-Namespace
    Projektweite Imports
    WithEvents + Handles
    Events sind generell etwas abstrakter gehalten, als bei C#. In C# addiert man zwei Delegaten, in VB heißt es wortwörtlich "Eventhandler hinzufügen".
    With
    XML-Literale
    #Const + #If
    Properties als ByRef-Parameter übergeben
    Viel mächtigeres Select Case (Vergleiche, nicht-konstante Ausdrücke)
    MyClass
    Handlichere Syntax für For-Schleifen

    Um ein paar nützliche, wenn auch teilweise selten verwendete, zu nennen.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Wobei ich davon ein paar als Nachteil sehe und gerade der handlicheren Syntax ganz und gar nicht zustimme. Vorallem ging es mir nicht um Zucker sondern um das was bereits Möglich ist. unsafe ist in VB.Net auf keinem Umweg(außer IL selbst hinzufügen/C# lib verwenden/Reflection) möglich.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Niko Ortner schrieb:

    Standard-Namespace
    Projektweite Imports
    Sind negativ, nicht positiv.
    Ich will zu jeder Zeit sehen, in welchem Namespace sich ein Typ befindet, bis zur höchsten Ebene. Gleiches gilt für das, was ich importiert habe.

    Der Support für Einzelinstanzanwendungen wird nur über das Anwendungsframework ermöglicht, und das ist schon wieder das nächste Minus. Keine Kontrolle über den Einstiegspunkt meiner Anwendung zu bekommen sehe ich als inakzeptable Einschränkung.

    WithEvents ist ebenfalls diskutabel, denn so ist nicht direkt im Code offensichtlich wo und in welcher Reihenfolge die Delegaten zugewiesen werden.

    Indexierte Properties gibt es zwar in der Tat nicht direkt, aber es gibt einen Indexer, und in 99% aller Fälle ist das der einzige Anwendungszweck für eine solche Property. Alle indexierten Properties außer dem Indexer sind semantisch ohnehin viel besser als Funktion implementiert.

    Select Case ist wieder das nächste. Im Endeffekt gibt es sowas auf Hardwareseite nicht, heißt, Select Case ist nur eine andere Syntax für ein If-ElseIf-Konstrukt und damit eigentlich obsolet weil bereits an anderer Stelle einheitlich vorhanden. Switch hingegen kann vom Compiler tatsächlich besser optimiert werden als ein generisches If-Konstrukt, in dem theoretisch unendlich viele verschiedenartige Abfragen vorkommen können.

    Der Rest ist ausschließlich Syntax, und welche man da lieber mag ist indiskutabel da subjektiv.
    @Artentus
    Ich kann viele Deiner Argumente nicht nachvollziehen bzw. sehe die Dinge aus einer anderen Perspektive. Zum Beispiel will ich nicht jedes Mal 30 Sekunden damit verbringen, meine Imports neu hinzuschreiben, wenn ich eine neue Datei erstelle.
    Und ich finde auch nicht, dass der Rest ausschließich Syntax ist. Die Frage ist halt, wo man den Strich zieht. Ich kann WithEvents oder Select Case bzw. Switch auch als "nur Syntax" sehen, denn es ist ja nur eine Möglichkeit, das selbe anders hin zu schreiben. Aber Präprozessor-Konstanten und das MyClass-Schlüsselwort sind definitiv nicht nur Syntax.
    Und das Performance-Argument bei Select Case zeiht nicht, denn mir ist es relativ Wurst, ob der Code 40 oder 60 OpCodes benötigt, wenn er dafür besser lesbar ist.

    @jvbsl
    Welche genau meinst Du?
    Und die For-Schleife war für mich immer schon eine "zähle mit A von B bis C in D-er Schritten"-Schleife: For A = B To C Step D.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Niko Ortner schrieb:

    meine Imports neu hinzuschreiben, wenn ich eine neue Datei erstelle
    Wer macht denn sowas? ^^
    Ich lass die einfach zusammen mit der Autovervollständigung autogenerieren, wenn sie von dem, was ich gerade gecode hab, gebraucht werden. Und die Standard-Imports sind sowieso schon von Anfang an drin.

    For-Schleife: for (A = B; A <= C; A += D)
    Wo ist das Problem? Die For-Schleife in C# ist genauso mächtig wie die aus C - beliebig viele Zählvariablen, beliebige Inkrementierungs- und Dekrementierungsfunktion sowie beliebige Iterationsbedingung. Kann die Schleife in VB alles überhaupt nicht.

    Artentus schrieb:

    Die For-Schleife in C# ist genauso mächtig wie die aus C

    Echt? Also wie genau das In C geregelt wird, weiß ich nicht, aber ist die nicht noch ein wenig mächtiger? In C++(11) zumindest ist die For-Schleife da noch ein bisschen weiter, da es Templates für Iteratoren gibt und dann verschiedene (Iterator, Reverse_iterator etc.) auch in der Schleife für das Iterieren benutzt werden, indem ein Anfang und ein Ende angegeben wird, der Iterator inkrementiert wird und dann kann man mit Dereferenzierung (*itr) das aktuelle Element rausholen. Da das über Pointer läuft, geht alternativ zum Anfang und Ende auch eben nur ein Anfang und ein Count und dann kann jeweils der Pointer inkrementiert und der Wert an der nächsten Adresse ausgelesen werden. Gibt also nicht nur die klassische For-Schleife.
    Seit C++11 gibt es auch for_each das von Anfang bis Ende durchgeht und für jedes Element eine Funktion aufruft. Aber gut, ist ja inkrementiertes C. :D

    Naja, ist jetzt auch nicht Thema. Was ich da viel mehr noch zu sagen will: Syntaktisch gesehen sind VB.NET und C# sowieso unterschiedlich, daher ist halt die Frage, wem was besser gefällt und eher weniger die einzelnen Sachen, da die dann keine große Rolle mehr aus der subjektiven Sicht spielen.
    Und die anderen Features lassen sich in C# ja genauso gut umsetzen, manche wie gesagt sogar besser. Zum Beispiel das Catch ... When wäre halt eine Abfrage im Catch-Block und wenn die nicht erfüllt ist, wird halt geworfen, sonst behandelt.
    Zu den Namespaces möchte ich kurz anmerken, dass mich die in VB.NET mit deren Verwaltung extrem stören und verwirren. Da steht nur die Klassendefinition und das war's. Ich will aber ebenso immer den aktuellen Namespace sehen und somit ist das imho hier etwas unschön und vor allem durcheinander. Das Anwendungsframework ist eh extrem nervig, da ich selbstständig Kontrolle über den Einstiegspunkt brauche und ich muss immer wieder in die Eigenschaften, es deaktivieren und dann eine eigene Program.vb erstellen usw. Überwiegend also nicht nur positiv.

    Da sich das Meiste von VB auch in C# umsetzen lassen kann, würde ich das eher weniger als wirkliches neues Feature bezeichnen, ist halt meist anders verpackt. Umgedreht sieht es da schon anders aus (z. B. kein unsafe eben). Und wie gesagt, Option Strict Off etc. ist da weniger erwähnenswert. ;)

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    Ich denke zu eurer Argumentation solltet ihr auch noch mal betrachten: Wie oft benutze ich das Feature das ich hier anpreise? Wenn ich in Visual Basic mal Unsafe brauche schreibe ich mir halt mal eine C# Bibliothek und verwende die dann. Da steht der Unsafe Part in keinen Größenverhältnis zu meinen VB Code. Ihr argumentiert so, als müsste man sich für eines Entscheiden, wieso nicht die Stärken von beiden nutzen?

    Ich benutze C# weil ich die Syntax ansprechend finde und mich darin eingewöhnt habe und nicht weil es mehr Features oder sonstiges hat. Dennoch finde ich, das es als Anfänger ein Fehler ist, ohne Vorkenntnisse in VB zu programmieren - Die Folgen sehen wir hier täglich. (Option Strict Off, My, Import ..MS.VisualBasic) Ich wusste damals nichts von diesen Funktionen, heute ist ein Cast selbstverständlich, aber wenn man durch probieren lernt und "Hallo " + "Welt" doch mal verknüft statt addiert und sich das einprägt ist das meiner Meinung nach ein Fehler bei den standard Einstellungen von VB.
    @ThuCommix Stimmt, unsafe wird sicherlich nicht all zu oft verwendet, aber selbst wenn wir diesen Punkt mal weglassen: Das mit den Stärken ist größtenteils wieder subjektiv, da VB.NET (zumindest imho) keine hat, die C# nicht auch hat. Und um genau diese Entscheidung geht es ja hier auch. Klar könnte man das Ganze verbinden, aber im Endeffekt muss man Aufwand und Nutzen sehen. In C# kann ich das, was in VB.NET geht genauso machen und auch noch ein bisschen mehr. Also wieso nicht gleich das? ;)

    Zwar nutze ich persönlich C# auch nicht aus dem Grund, sondern weil es mir syntaktisch besser gefällt und weitaus öfters vertreten ist, aber dennoch ist es wichtig, die weiteren Features von C# zu erwähnen, wenn es hier um die Frage nach der richtigen Sprache geht. Und diese Features sind ja durchaus von Vorteil. Die von VB.NET (wenn man es so nennen will) sind es imho nicht. Dazu kommen natürlich die Sachen, die VB.NET erlaubt und die Du angesprochen hast. Dies bestätigt mir ja auch, dass C# in der Beziehung Visual Basic.NET voraus ist, da es nicht geht und das korrekt bzw. sauberer ist.

    Das soll nicht heißen, dass niemand mehr VB.NET verwenden sollte, aber mal von dem Punkt aus gesehen ist es einfach so, dass C# mächtiger ist. Wenn man es nicht braucht und in VB.NET richtig programmiert, ist das vollkommen in Ordnung, aber erwähnt werden sollte es auf jeden Fall in so einer Diskussion.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    Um noch mal ein bisschen Lesestoff in die Runde zu schmeißen:

    simple-talk.com/dotnet/.net-fr…l-basic-is-better-than-c/
    codeproject.com/Articles/9978/…mparison-for-VB-NET-and-C
    en.wikipedia.org/wiki/Comparis…arp_and_Visual_Basic_.NET
    harding.edu/fmccown/vbnet_csharp_comparison.html

    Grundlegend sollte man als .net Programmierer in der Lage sein sich recht schnell in die andere Programmiersprache hineinzulesen.


    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.