Dlaczego VB jest tak popularny? [Zamknięte]

28

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?
aaaidan
źródło
4
Skąd wiesz, z jakich komercyjnych stron internetowych Microsoft zbudowano?
samjudson
30
„Dlaczego VB / VB.net jest dziś tak często używany”, To trochę jak pytanie „Dlaczego muły / ciężarówki są dziś tak często używane w transporcie?”
Daniel Daranas
2
Tylko dla potomności, poprawiam się (nieśmiało). VB ma społeczność bardzo lojalnych użytkowników, co mówi bardzo dużo.
5
to pytanie należy usunąć.
25
Nie usuwaj tego pytania. Jest zły, uprzedzony i subiektywny, ale dość często występuje i może służyć jako odniesienie.
Konrad Rudolph,

Odpowiedzi:

47

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 .

Rick J
źródło
4
Łał. Właśnie. Łał. To właśnie sprawiło, że mój dzień był niesamowity.
1
omg wow ... omg wow.
2
Nigdy więcej nie spojrzę na CSI w ten sam sposób.
Robert Harvey
3
Powiększ ... ok, popraw.
42

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

Fredrik Mörk
źródło
5
Dokładnie opisujesz moją sytuację.
6
To samo tutaj - kod VB.NET jest pełen „szumu”, gdy patrzy się na niego z perspektywy składni w stylu C. Bez obrazy dla programistów VB. Dokładnie tak, jak się czuje przejście z C # na VB.
2
zgodziłem się, że nie mogę znieść VB.NET - składnia jest jak historia ... i tak, musiałam go używać nieprzerwanie od miesięcy, doprowadzało mnie to do szału, uwielbiam składnię C #.
Dal
2
Programiści C # nie są zwykłymi ludźmi?
prawej strony
@rightfold Nope. Programiści VB.net również nie są normalni. Programiści VB.net są bardziej niesamowici niż zwykli ludzie i dla C # ... bez komentarza. = D ZASADY VB.net !!!!!!!
Anonimowy pingwin
27

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.

Konrad Rudolph
źródło
4
Blake: tak, pełne punkty dla Ruby. Wreszcie język robi to dobrze. Python również osiąga u mnie wysokie noty. Mimo to jestem częściowo niezadowolony ze wszystkich istniejących składni.
Konrad Rudolph
2
Ruby jest do kitu: P ... teraz, gdy mam to na uboczu ... prawdziwy powód różnic składni majoy między słowami kluczowymi opartymi na nawiasach klamrowych sprowadza się do łatwości napisania parsera. Byłem wielkim fanem VB (ogólnie BASIC), ale odkąd przeprowadziłem się do C #, znacznie łatwiej i szybciej pracuję.
Matthew Whited
4
Dlaczego aparaty ortodontyczne? Ponieważ wizualnie wyznaczają blok kodu, jeśli są właściwie używane. Tak, zdaję sobie sprawę, że wcięcie w VB też to robi, ale nawiasy klamrowe robią to z większą jasnością IMO. Średniki ułatwiają kompilatorowi (po prostu zapytaj o to zespół kompilatorów VB). Uważam, że castowanie w C # jest bardzo intuicyjne i kompaktowe. I nie jest to zmienna deklaracja kluczowe:var
Robert Harvey
1
@Robert Harvey: 1) VB używa słów kluczowych do oznaczania bloków, a nie wcięć. Tyle o jasność. 2) Jeśli chodzi o casting, C ++ już dawno słusznie zrezygnował z rzutowania w stylu C, ponieważ jest on zbyt wizualnie niepozorny ( nie jest to dobra rzecz; casting powinien się wyróżniać, ponieważ wprowadza zmienioną semantykę i potencjalne słabości użycia typu). 3) Nie. Miałem na myśli wskazówkę składniową poprzedzającą każdą deklarację. var int xprzychodzi na myśl. Wszystkie pozostałe instrukcje i bloki są wprowadzane przez dedykowane słowa kluczowe, dlaczego nie deklaracje zmiennych i metod? Fie. Niespójne i brzydkie.
Konrad Rudolph,
4
@Konrad: Przyznam, że na początku trochę się przyzwyczaiłem. Częścią filozoficznej różnicy może być to, że nie myślę już o moim języku programowania jako o wariancie języka angielskiego, tak jak wtedy, gdy programowałem w VB. Przejście do C # sprawiło, że język programowania, którego używam, jest nieco bardziej symboliczny (i zwięzły), ale nie jest zbyt nieprzejrzysty. Ta symbolika pozwoliła mi umysłowo swobodnie myśleć bardziej koncepcyjnie o takich rzeczach, jak orientacja obiektowa, przekazywanie wiadomości i lambda.
Robert Harvey
15

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

coobird
źródło
13

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++;
}
Dario
źródło
1
C # dałby błąd kompilacji w przypadku braku inicjowania countZeros (w zakresie lokalnym) i przypisania wartości do danych [i] w instrukcji if. Wiem, że w swoim komentarzu wspomniałeś o c / c ++, ale wierzę, że OP porównał VB do C # :)
1
Moim zdaniem VB10 jest lepszy od C # 10!
Shimmy,
Lubię wszystkie języki: LISP, C, VB, PHP, nazywacie to.
systemovich,
+1 i dodam, że instrukcja Switch VB nie jest bezużyteczna jak C #.
Joel Brown
12

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.

dommer
źródło
2
+1 afaics VB6, a zwłaszcza VS IDE, zapewniły (bardzo) niską barierę wejścia, co stworzyło generację nowych koderów ze wszystkimi problemami i możliwościami w tym zakresie
7

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.

JBRWilkinson
źródło
6

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.

Brian Rasmussen
źródło
6

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.

iburlakov
źródło
6

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.

Vincent
źródło
4

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.

Władca
źródło
Ta kompilacja w tle sprawiła, że ​​edycja dużych projektów VB w VS2005 była bardzo powolna. W każdym razie po to jest ReSharper;)
Lucas
To nie tylko kompilacja w tle, narzędzia do automatycznego formatowania i czyszczenia kodu naprawiają wiele rzeczy, zanim jeszcze opuścisz blok, aby uruchomić kompilację. Jest to OGROMNA oszczędność czasu w vb w porównaniu do c #
Bill
4

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.

gbc
źródło
3

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

Marc Gravell
źródło
3

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.

Blake Pettersson
źródło
I w tym przypadku „dynamiczny” - dając C # coś porównywalnego z VB istniejącym wiązaniem późnym / wysyłającym.
Marc Gravell
1
Ta tak zwana zaleta zawsze była dla mnie problematyczna - czytam o tym, że C # ma przeciążenia, które są bezpieczniejszym sposobem na osiągnięcie tego samego praktycznego rezultatu.
2
Minusem przeciążeń jest to, że są one trudniejsze i mylące w utrzymaniu, gdy chcesz ustawić kilka wartości domyślnych. Możesz skończyć ze złożonymi łańcuchami przeciążeń, które kompilują się w zagnieżdżone wywołania metod, zamiast być przez kompilatora bezpośrednio rozwiązywane do metody.
Matthew Whited
3

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.

NinethSense
źródło
Możesz powiedzieć to samo o kombinacji ASP.net + C #, nie?
Tak, większość wersji językowych opartych na Visual Studio.
Cóż, w wieku VB (nie .net) nie było C # itp. Więc VB było jedyną WIELKĄ rzeczą tego czasu. Później użytkownicy VB migrowali do VB.NET. W każdym razie VB <> VB.NET.
3

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.

PhpFlashGuy
źródło
Zgadzam się, że VB.net nie jest tak popularny jak klasyczny VB. Niektórzy deweloperzy, którzy nie mogli migrować swojej bazy kodu do VB.net, mogli zamiast tego przejść na C #.
JBRWilkinson,
3

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.

chugh97
źródło
3

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
Toon Krijthe
źródło
3

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

Eric
źródło
2

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.

miccet
źródło
2

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ść)

Petar Kabashki
źródło
Wolę subskrybować wydarzenia osobiście, a nie wszystkie magiczne rzeczy za kulisami, które toczą się w „Rękojeściach” i projektantce VS.
Lucas
2

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.

mattmc3
źródło
Jeśli chodzi o mnie, VB.NET jest zbyt gadatliwy. Musisz ręcznie wydrukować wiele kodów typu „kocioł”, a ReSharper w rzeczywistości nie pomaga. Koduję w C # / VB.NET w równoległej już od 3 lat.
Hedin,
VB jest rzeczywiście poziomo szczegółowy ze względu na dłuższe słowa kluczowe. Chociaż często ich nie wpisujesz, ponieważ IDE umieszcza je dla Ciebie. Ale IMHO C # jest często pionowy z powodu kręconych nawiasów klamrowych. Kilka innych zalet VB: unikaj debatowania nad stylem klamrowym, ponieważ w VB jest tylko jeden styl; (język wpada w policzek) unikaj nadmiernie umięśnionego prawego palca ze względu na niekończące się pisanie średnikiem i klamrą.
MarkJ
1
@ MarkJ: Uważam za interesujące sposób, w jaki zwolennicy C # krytykują AndAlso[nie zapominając, że gdy jest wypowiadany, jest krótszy niż „podwójny ampersand”], ale ignoruję fakt, że If-Then/Else/EndIfzajmuje on trzy linie plus kontrolowane stwierdzenia, podczas gdy odpowiednik C # zabrałby co najmniej cztery i ewentualnie sześć, w zależności od konwencji nawiasów klamrowych, chyba że ktoś pisze } else {jako pojedynczą linię.
supercat