Dlaczego VB jest tak popularny? [Zamknięte]

Dla mnie Visual Basic wydaje się niezdarny, brzydki, podatny na błędy i trudny do odczytania. Pozwolę innym wyjaśnić dlaczego . Podczas gdy VB.net wyraźnie zrobił ogromny skok naprzód dla języka pod względem funkcji, nadal nie rozumiem, dlaczego ktoś zdecydowałby się napisać kod w VB, powiedzmy C #.

Jednak nadal widzę (jak się wydaje) ogromną większość komercyjnych aplikacji internetowych ze „sklepów MS”, które są wbudowane w VB. Mógłbym z tym poradzić, ale VB nadal wydaje się bardziej popularny niż na to zasługuje.

Czy ktoś może pomóc odpowiedzieć na dowolne (lub wszystkie) z następujących pytań:

• Czy brakuje mi czegoś z VB? Czy łatwiej jest się uczyć, czy „przyjaźniej” niż C #? Czy są funkcje, o których nie wiem?
• Dlaczego VB / VB.net jest dziś tak często wykorzystywany, szczególnie w projektach internetowych?

VB może być używany do tworzenia GUI (wyraźny lepki) do śledzenia adresów IP. Jest to często wykorzystywane w rozwiązywaniu przestępstw .

Myślę, że to zależy od tego, skąd pochodzisz. Zaczynając jako programista, myślę, że VB może być łatwiejszy do odczytania niż na przykład C #, ponieważ opiera się bardziej na słowach niż symbolach, co ułatwia przyjmowanie zwykłych ludzi.

Byłem programistą VB przez wiele lat i kiedy .NET przyszedł, nadal pracowałem w VB.NET przez pierwsze kilka lat (tak naprawdę nie widziałem sensu w C #). Teraz mam kilka lat C # za sobą i czasami stwierdzam, że kod VB.NET zajmuje mi trochę więcej czasu na „dekodowanie” niż kod C #. Być może dlatego, że w niektórych konstrukcjach opiera się bardziej na słowach niż symbolach ...

Poniżej właśnie skopiowałem moją odpowiedź do innego wątku :

Rozwijam się zarówno w VB, jak i C #, większość moich zarobków dotyczyło C #. Osobiście wolę VB do większości (ale nie wszystkich… lambdów!) Prac. Naprawdę nie potrafię wymienić żadnych twardych zalet poza tymi opisanymi przez Jona. W rzeczywistości Herfried zebrał kilka na jego temat stronie internetowej (w języku niemieckim!), Ale są one raczej techniczne.

Rzeczą, która naprawdę wkurza mnie w całym języku związanym z C, jest głupia składnia. Jest to czysto kulturowe, ale jako ktoś, kto wykonuje większość swojej pracy zawodowej w C ++ i będąc w tym dość biegły, nadal absolutnie nie znoszę składni. I nie tylko urocze dziwactwa C ++. Nie, cały pakiet. Dlaczego aparaty ortodontyczne? Dlaczego średniki (być może najgłupsza decyzja w całej historii programowania)? Dlaczego głupia składnia obsady w stylu C? Dlaczego nie ma słowa kluczowego dla deklaracji zmiennej (w rzeczywistości to jest najgłupsza decyzja)?

Jest tak wiele rzeczy, które naprawdę sprawiają, że jestem smutny i zły. VB nie jest świętym, jego język ma ogromne wady. Ale nic w porównaniu do tego, co powiedziałem powyżej.

Zdaję sobie sprawę, że większość tych stwierdzeń wymaga uzasadnienia, ale twierdzę, że dzieje się tak tylko dlatego, że się do nich przyzwyczailiśmy. Ponadto tutaj nie jest właściwe miejsce. Wystarczy powiedzieć, że składnia języka C #, choć jest jego główną przewagą nad VB, jest także jego główną wadą.

Nie preferuję VB ze względu na Myprzestrzeń nazw, nie preferuję go z powodu literałów XML, nie preferuję go z powodu słabego pisania, nie preferuję go z powodu opcjonalnych parametrów lub z powodu znacznie lepszych switchkomunikat. Nie, wolę to ze względu na składnię.

To powiedziawszy, muszę przyznać, że VB staje się coraz bardziej obciążony jego składnią. Najnowszym szumem wydają się być zapytania Linq sparametryzowane funkcjami lambda i chętnie przyznam, że to czyni wiele rzeczy prostszymi. Niestety składnia VB dla lambdas jest po prostu zbyt skomplikowana, aby konkurować z C #. Zastanów się, Parallel.Forjak wygląda rozmyte połączenie w VB - w porównaniu do C #, gdzie wygląda naturalnie. IMHO, zespół projektowy VB poszedł tutaj w złym kierunku, faworyzując konserwatywną spójność nad czytelnością.

Aby odpowiedzieć na twoje subiektywne oskarżenie:

Dla mnie Visual Basic wydaje się niezdarny, brzydki, podatny na błędy i trudny do odczytania.

Na pewno masz prawo tak myśleć, ale jak powiedział poniżej Marc, trudno będzie ci to argumentować obiektywnie. Zdecydowanie mogę przytoczyć wiele elementów składni C, które są obiektywnie bardziej podatne na błędy niż cokolwiek istniejącego w VB. W rzeczywistości opracowano składnię VB, aby wyraźnie zapobiec takim sytuacjom.

„Niezdarny, brzydki ... i trudny do odczytania” to wszystkie kwalifikatory, które można przypisać do prawie wszystkich języków, których nie znasz. Mówiąc wprost: brzydota jest bezpośrednią konsekwencją nieznajomości języka.

Dobra znajomość języka oznacza rozpoznawanie wzorców w kodzie. Kod dobrze napisany zostanie przez virtuel praktyki wydają elegancki, natomiast zły (powolny, podatne na błędy) kod pojawi się brzydka. To takie proste.

Ostatnia uwaga: cytowane przez ciebie artykuły zawierają kilka nieścisłości i nieaktualne informacje. Jako jedyne uzasadnienie wysoce subiektywnej i emocjonalnej dyskusji nie są one zbyt dobrze dostosowane.

Dla mnie Visual Basic wydaje się niezdarny, brzydki, podatny na błędy i trudny do odczytania.

Dla mnie angielski wydaje się niezdarny, brzydki, podatny na błędy i trudny do odczytania, szczególnie napisany przez ludzi, którzy mają słabą gramatykę, słabą pisownię, lekkomyślne lekceważenie wielkich liter i interpunkcji oraz brak poczucia, jak przestrzennie i mentalnie uporządkować swoje myśli.

Nie chodzi tylko o to, że Visual Basic jest trudny do odczytania lub nieporadny z powodu składni języka, ale zwykle dzieje się tak, ponieważ programista nie jest naprawdę dobry w wyrażaniu własnych myśli:

If blah = 10 Then If stuff = "foo" Then t = 1 + k: s = 42: dostuff21

Racja, to okropne. Ale pisanie okropnego kodu w innych językach nie jest szczególnie trudne. Przy prawidłowym pisaniu ma sens, nawet jeśli kod jest napisany w VB:

If SelectedType = 10 And UserName = "Foo" Then
    CurrentUsers = CurrentUsers + 1
    UserConnectionID = 42
    PerformUserOperation
End If

Przynajmniej jest to bardziej czytelne i zrozumiałe. Nadal jest PODSTAWOWY. Naprawdę sprowadza się to do zdolności programisty do wyraźnego wyrażenia swoich intencji poprzez formatowanie kodu w łatwy do odczytania sposób, przy użyciu dobrze nazwanych identyfikatorów i zwracania uwagi na pisanie zrozumiałego kodu.

To powiedziawszy, nie dotknąłem Visual Basic wiele od czasów VB3 (stąd przykład ze „starą” składnią), ale to, że język może być nadużywany, nie oznacza, że ​​nie można go poprawnie użyć do napisania dość solidnego kodu . Jasne, mogą występować pewne braki, ale podejścia mające na celu obejście tych problemów pokazują także umiejętności jednego programisty nad drugim.

(Bezkrytycznie natryskiwanie On Error Resume Nextprzychodzi na myśl jako niezbyt dobry sposób na obejście braków wyjątków w VB w czasach sprzed .NET.)

Większość argumentów przeciwko VB dotyczy tylko VB-Classic (drugi link) lub opiera się na słabych lub przestarzałych argumentach

• Nawet w VBC nie będziesz używać GoSub ... Return itp.
• co jest źle z static ? C ++ też to obsługuje.
• VB10 wprowadza niejawną kontynuację linii (nie potrzebujesz nawet redundantnej średnika jak C #)
• Różne funkcje rzutowania istnieją również w C ++ i C #. (object)(expr)Składnia -Cast- C # iobject as type jest jeszcze bardziej zagmatwana i niespójna.
• Co jest złego w tym with ? Możesz tworzyć zagnieżdżone struktury drzew w bardzo intuicyjny sposób, co nie jest możliwe w języku C #.
• Obsługa zdarzeń w VB jest znacznie bardziej elegancka niż w C #. Możesz wprowadzać i obsługiwać zdarzenia jednym słowem kluczowym ( WithEvents) bez konieczności inicjowania delegatów, procedur obsługi zdarzeń itp. Dzięki temu programowanie GUI w VB jest znacznie wygodniejsze i nie musisz generować kodu zdarzenia przez projektanta .
• Parametry opcjonalne są wprowadzane do nowego C # - stąd wydają się być dobre.
• VB.NET ma zarówno ścisłe, jak i skrótowe operatory logiczne.
• Państwo nie sprawdzić błędy składniowe w czasie kompilacji, chyba uruchomieniu skryptu VB-jak język.
• End Ifjest bardziej pomocny niż tylko }. Mając złożone struktury syntaktyczne, wszystkie nawiasy klamrowe są po prostu mylące, podczas gdy beton End ...pomaga w określeniu, który blok nie został zamknięty.
• Literały XML - skrypt XML jest teraz częścią kodu, w pełni wspierany przez intellisense.

Podsumowując, istnieje tylko kilka obiektywnych różnic między VB.NET i C # oprócz składni. EG: Projektowanie GUI jest znacznie bardziej wydajne w VB ze względu na lepszy system zdarzeń i lepsze IDE, podczas gdy np. Algorytmy mogą być lepiej wyrażane w C #, ponieważ składnia jest conciser.

Reszta to tylko kwestia twojego osobistego stylu. Programiści w stylu C czują się komfortowo z C #, VB (a może Pascal?) - programiści stylu używają VB.

Ale oparta na słowach, bardziej wyraźna składnia VB może być łatwiejsza do odczytania dla początkujących niż wszystkie symbole w C. Porównaj:

If (a < 15) Xor (b = 2) And Not Condition Then

do

if ((a < 15) ^ (b == 2) && !Condition())

To nie znaczy, że jeden język jest lepszy od drugiego.

Edytować : -----------------------------------------

Argument VB byłby podatny na błędy. Gdy używasz Option Strict On, jest tak rygorystyczny jak C #, ale nie pozwala nam popełniać takich błędów:

// VB would initialize with zero (C/C++ doesn't)
int countZeros;
// No confusion with loop bounds with For x = 1 To Length
for (int i = 1; i <= length; i++) {
    // Never confusing == with = 
    if (data[i] = 0) 
        countZeros++;
}

Historycznie środowisko programistyczne VB było szybkim i skutecznym sposobem budowania niektórych rodzajów aplikacji (np. Aplikacji GUI). To sprawiło, że był to bardzo popularny wybór. Myślę, że VB był najczęściej używanym językiem w czasach swojej świetności (np. VB6).

Z tego rodzaju zainstalowaną bazą nie jest zaskakujące, że wciąż jest w niej dużo pracy.

Wszystko zaczęło się, zanim istniał C #

W ~ ~ 1999 mieliśmy Visual Studio 5/6. Jeśli byłeś niezależnym dostawcą oprogramowania lub firmą korzystającą z systemu Windows i potrzebowałeś napisanej aplikacji, która mogłaby np. Śledzić czas pracownika spędzany na projektach, masz kilka opcji:

1. Formularze w języku Visual Basic.
2. MFC, ATL lub Win32 w Visual C ++.
3. Formularze w programie Access 97/2000.
4. Strona ASP.
5. Aplet Java.

W tym czasie byliśmy tuż przed pęknięciem bańki Dot-Com, więc każdy, kto był dobry z (4) lub (5), poszedł negocjować opcje na akcje przy każdym niesamowitym dot-com, który ich pociągał.

(3) miał problemy z blokowaniem i ogólną skalowalnością, ale widziałem wiele rozwiązań opartych na dostępie, które byłyby uruchamiane w celu uruchomienia funkcji wsparcia w razie potrzeby.

Pozostaje nam więc VB i VC ++:

Edytor formularzy w VB był wówczas doskonały pod względem produktywności. Możesz przeciągnąć elementy - nie tylko przyciski, etykiety i pola tekstowe, ale pełny zestaw narzędzi „Kontrolki OLE” komponentów wielokrotnego użytku, takich jak sprytne siatki, arkusze Excela lub instancje IE. Podłączenie zostało wykonane za kulisami - wszystko było podobne do obiektu, a ty po prostu dwukrotnie kliknąłeś, aby dodać procedury obsługi zdarzeń. Było to o wiele trudniejsze w Visual C ++. Jako członek zespołu programistów Visual Studio w tym czasie pamiętam, w jaki sposób wywołania pomocy technicznej w języku Visual Basic dotyczyły głównie tego, który składnik najlepiej użyć lub jak zoptymalizować aplikację na określone sposoby. Prawie nigdy nie było „jak zrobić aplikację z funkcjami interfejsu użytkownika X, Y i Z”.

Zbudowanie bogatego interfejsu użytkownika w Visual C ++ było innym wyzwaniem. Mimo że edytory wizualne obsługiwały okna dialogowe i formularze SDI / MDI, były dość ograniczone. Obsługa osadzania formantów OLE (ActiveX) w MFC lub Win32 była czarną sztuką, choć nieco łatwiejsza w ATL. Podłączanie prostych rzeczy, takich jak zmiana rozmiaru zdarzeń lub losowanie przez właściciela, było dość bolesne, nie mówiąc już o punktach połączenia wymaganych dla niestandardowych zdarzeń w komponentach.

Tak, VC ++ miał szybkość wykonywania, możliwość debugowania i elastyczne frameworki / biblioteki / interfejs użytkownika, ale obsługa IDE nie mogła objąć wszystkich tych obszarów, więc zajęła się najczęstszymi operacjami takimi jak Wizards, kompleksowe hierarchie klas MFC i 90 dni / 2 linie wsparcia dla wolnych od incydentów.

IIRC, program do pakowania aplikacji dostarczany z VB, może spakować twoją aplikację, środowisko uruchomieniowe VB i najnowsze wspólne biblioteki DLL sterowania oraz dostarczyć niezależny instalator EXE, który możesz umieścić na płycie CD i dotrzeć do klientów. Żadne z tych „które msvcrtXX.dll i mfcxx.dll masz zainstalowane?”, Które nękały programistów MFC.

Tak więc, ze względu na czas wprowadzania na rynek i bogaty interfejs użytkownika, VB zyskał bardzo dużą popularność.

Kiedy Visual J ++ i Visual Interdev uderzyły w VS6, było jasne, że Visual Basic IDE wygrał bitwę nad Visual C ++, co było uczciwym IMHO. Nic dziwnego, że Visual Studio .NET miał edytor formularzy podobny do VB dla nowego języka COOL C #.

Nowy język podobny do Java / C / C ++ w połączeniu z projektantem interfejsu użytkownika, z którego korzystają ludzie VB, przez cały ten czas stworzył nową ścieżkę migracji dla osób z C ++, które były już gotowe z MFC / ATL / Win32. Dla osób VB 3/4/5/6, które nie lubiły braku 100% wstecznej kompatybilności w VB.net, oferowało to możliwość nauki nowego języka w znanym środowisku.

Powody, dla których VB był tak kompleksowym produktem, prawdopodobnie mają coś wspólnego z początkami Microsoftu, przy czym Basic jest ich flagowym produktem dla programistów, ale obecnie nie mam żadnych cytatów.

Bez względu na to, jak brzydki jest dany język, sprowadzanie się do niego zwykle sprowadza się do: złomowanie ogromnej bazy kodu jest bardzo drogie, a fakt, że programiści już go znają, sprawia, że ​​korzystanie z niego jest tańsze niż w przypadku innych języków.

VB.NET jest łatwiejszy do nauczenia się, masz rację i ogólnie jest łatwiejszy niż C #, moim zdaniem. To pierwszy punkt, dlaczego VB jest tak popularny. Kolejny i najważniejszy punkt, jak sądzę, jest taki, że istnieje ogromna zbieżność programistów, którzy pracowali z VB 6 i starszymi wersjami tego języka, i łatwiej jest im tworzyć aplikacje z VB.net niż uczyć się nowego języka.

Jak inni powiedzieli, twoja estetyczna ocena składni języka w dużej mierze zależy od tego, co wiesz wcześniej. Od ponad dekady wygląda na to, że był to konkurs podobny do C, z kręconymi nawiasami klamrowymi dla „bloków”, „->” dla pośrednictwa (perl, php), nawiasami dla argumentów wywołania funkcji, // dla komentarze i średnik na każdym końcu wiersza. Niektórzy nawet uważali, że dzięki temu „unikatowemu pomysłowi”, jeśli znasz język, znasz je wszystkie, co jest rzeczywiście śmieszne. Ale to zaszczepiło pomysł wśród ludzi C ++ / Java, że ​​jest to jedyna poprawna estetyka składniowa i wszystko inne próbuje sklonować COBOL.

Kilka lat temu przeszedłem na rubin, a teraz python, i nie mogę znieść więcej brzydkich średników, nawiasów klamrowych i innych bezsensownych znaków. Kod źródłowy jest przeznaczony do odczytu przez ludzi. Kiedy spróbowałem studio wizualnego, wybrałem VB zamiast C #. Podejrzewam, że niektórzy programiści wybrali język C # tylko po to, by „wyglądać poważnie” ze swoją składnią podobną do java, ale daj spokój, te same funkcje są dostępne… daj spokój.

Cóż, jeśli mówisz o .NET, jest jeden naprawdę łatwy, o którym mogę pomyśleć:

Edytor VB.NET w Visual Studio jest znacznie lepszy w wychwytywaniu błędów składniowych niż C #.

Podczas gdy edytor C # znacznie poprawił VS2008 SP1, nadal istnieją pewne błędy składniowe, których edytor nie wykrywa, dopóki nie spróbujesz skompilować programu.

Duża popularność VB powstała w czasach, gdy narzędzia VB były znacznie bardziej przyjazne niż w innych dostępnych językach. „Klasyczny” VB oferował łatwy sposób na budowanie aplikacji Windows bez konieczności uczenia się wnętrzności Win32 API lub kłopotania się ręcznym zarządzaniem pamięcią. Bariera wejścia dla początkujących programistów była znacznie niższa w przypadku VB niż C ++, więc wielu ludzi obciąło zęby za pomocą VB.

Obecnie myślę, że jedną zaletą VB w stosunku do C # jest znajomość dla tych, którzy pracowali z VB przez lata. Kolejną zaletą jest to, że kod VB jest łatwy do odczytania ze względu na tendencję do używania słów kluczowych zamiast symboli interpunkcyjnych. Jako ktoś, kto pracuje w VB, Java, C, C # i Python, uważam, że VB jest najłatwiejszym językiem, do którego można wrócić, przeglądając kod napisany przed laty. Składnia jest bardziej szczegółowa, co często ułatwia czytanie kodu, a Visual Studio zawsze wykonał świetną robotę formatowania kodu VB, aby wyczyścić formatowanie podczas pisania, aby kod był konsekwentnie formatowany (niezależnie od niechlujstwa autora).

Na marginesie uważam, że Python jest niezwykle łatwy do czytania i recenzji z podobnych powodów. W Pythonie formatowanie kodu jest wymuszane przez interpreter, a nie IDE, ale wynik końcowy jest taki sam. Python również preferuje słowa kluczowe do interpunkcji, choć prawdopodobnie mniej niż VB.

Trudno byłoby argumentować, że jest bardziej lub mniej „podatny na błędy” niż jakikolwiek inny język. Wątpię także w to, czy chodzi o „zdecydowaną większość komercyjnej sieci MS”; z tego co widziałem, C # jest zdecydowanie liderem w rozwoju .NET (z .NET jest flagowym narzędziem w stosie MS do rzeczy, które nie są sterownikami urządzeń itp.).

Jedną z zalet VB.NET w stosunku do C # (który zniknie wraz z C # 4), są domyślne i nazwane parametry, co jest bardzo miłe podczas korzystania z VSTO.

VB / VB.NET należy do kategorii RAD (Rapid Application Development). Możesz tworzyć aplikacje za pomocą przeciągania i upuszczania z przybornika i mniejszej ilości kodu.

Cóż, myślę, że musisz odróżnić klasyczne VB i VB.NET.

Wydaje mi się, że VB.NET nie jestWydaje zbyt popularny, ale Visual Basic „Classic” nadal ma 1 Powodem jest to, że bardzo łatwo jest stworzyć aplikację Windows. Porównaj to z aplikacją Windows w C ++ / Mfc, która była prawie jedyną alternatywą w tym czasie.

Z tego samego powodu Delphi był kiedyś bardzo popularny.

VB jest bardzo gadatliwy i łatwo przyzwyczaić się do C #, w którym rozróżniana jest wielkość liter. Dla początkującego programisty jest to najlepszy punkt wyjścia.

By wymienić tylko kilka:

• łatwość użycia
• znana nazwa (podstawowy był jednym z pierwszych popularnych języków programowania komputerowego)
• nie lekceważ marketingu w Microsoft

Myślę, że po części powodem jest to, że starzy programiści ASP wchodzący do .NET, tak jak to zrobiłem, już bardzo dobrze znają VB, ponieważ skrypt VB jest klasycznym językiem ASP używanym w większości. Czułem, że mniej czasu zajmuje pisanie w VB w .NET, ponieważ już wiedziałem, jak mówić w VB. VB jest również mniej krybaby niż C #. Mogę czytać / pisać w obu, ale wolę VB, ponieważ łatwo jest się zaprzyjaźnić, jeśli jesteś nowym programistą.

Pracuję w środowisku, w którym korzystamy z obu. Przeszliśmy na C # na rzecz klasycznych ASP i VB. Moim zdaniem nie ma żadnych rozłamów między językami. W przypadku większości projektów możesz wykonać tę samą pracę z oboma językami. Teraz podzielam twoją opinię na temat podatności na błędy i uważam, że VB jest zagracone (bez powodu).

Jak wspomnieli inni, VB jest bardzo prosty i historycznie można bardzo szybko budować projekty. Trwało to przy tworzeniu stron internetowych (które jest szybko rozwijane), ale myślę, że kiedy ludzie zdadzą sobie sprawę, że C # jest równie szybko rozwijany, VB zniknie. Innym powodem, dla którego myślę, że zniknie, jest to, że wszystko, co piszesz (CSS, JavaScript) podczas tworzenia aplikacji internetowych wygląda bardziej jak C # niż VB, więc warto używać C #, nawet dla początkujących.

Osobiście podoba mi się sposób, w jaki zdarzenia są dołączane w vb.net za pomocą słowa kluczowego „uchwyty” ... IDE / Visual Studio / jest również bardziej responsywny, gdy ma do czynienia z VB i obsługuje automatycznie większość końcówek if i tym podobne ... C # jest oczywiście o wiele bardziej przejrzysty i czysty (IMHO, pracowałem z oboma dość)

Od wersji 4.0 jest tylko kilka rzeczy, których brakuje VB w porównaniu do C #, i odwrotna sytuacja jest również prawdą. Mianowicie:

1. Najbardziej godne uwagi jest to, że VB.NET nie ma Yieldsłowa kluczowego, ale wkrótce pojawi się w VB.NET z nową strukturą asynchroniczną.
2. Nie ma unsafesłowa kluczowego. Nigdy nie uważałem tego za konieczne, ale na pewno są ludzie, którzy mają.
3. Nie ma ciągów wieloliniowych. Ciągi wielowierszowe uzyskuje się za pomocą + (lub starszych i) operatorów w poprzek linii. Lub mogą być realizowane za pomocą składni XML dosłowne: Dim s = <s>My string... multiple lines...</s>.Value. To nie jest ładne, ale jeśli nie jesteś wybredny i naprawdę chcesz ciągów wieloliniowych, to działa. I możesz wykonywać interpolację łańcuchów za pomocą <%= myVar %>składni, co jest miłe.
4. Nie ma odpowiednika zmiennej o zasięgu dynamic. Zmienne dynamiczne są w VB już od dłuższego czasu Option Compare Off, ale jest to zakres pliku, więc nie jest tak dobry, dynamicponieważ dynamicogranicza zakres tylko do zmiennej zadeklarowanej w ten sposób.
5. VB nie ma zwięzłej składni lambda. Lambda są tam, ale musisz użyć Function(x)lub Sub(x).

Niektóre funkcje VB.NET mają to, że C # nie:

1. Literały XML, które są przydatne do wszelkiego rodzaju rzeczy, nie tylko XML.
2. Niewrażliwość na wielkość liter w języku to miauczenie kota. Niewiele innych języków na to pozwala, ale jaka to różnica w szybkości kodowania, aby nigdy nie musieć naciskać klawisza Shift podczas pisania, a Twój kod automatycznie formatuje tak, jak chcesz.
3. Często niepotrzebną Selectklauzulę można pominąć w zapytaniach Linq.
4. Słowo Nothingkluczowe jest znacznie bardziej przydatne niż to, nullże wszystko (nawet typy wartości) można ustawić na Nothingwartość domyślną. Słowo kluczowe nie jest potrzebne default.
5. VB.NET jest stale kompilowany w Visual Studio, więc od razu widać błędy. Nie uderzanie CTRL-SHIFT-B przez cały dzień jak w C #.

Mój sklep robi MVC3 z Razor za pomocą VB.NET, a kiedy przejdziesz przez (w większości nieuzasadnione) uprzedzenia, jest to naprawdę bardzo przyjemny język. To nie jest tak naprawdę bardziej szczegółowe niż C #, jak wielu twierdzi (z wyjątkiem lambdów), i jest prawie równoległe do C #. Przekonałem się, że większość ludzi nienawidzących tak naprawdę nie kodowała w nowoczesnym VB.NET przez dłuższy czas.