Tại sao VB rất phổ biến? [đóng cửa]

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc. Tôi sẽ để người khác giải thích tại sao . Mặc dù VB.net rõ ràng là một bước nhảy vọt lớn về ngôn ngữ về các tính năng, tôi vẫn không hiểu tại sao mọi người lại chọn viết mã trong VB hơn, giả sử, C #.

Tuy nhiên, tôi vẫn thấy (dường như là vậy) phần lớn các ứng dụng web thương mại từ "cửa hàng MS" được xây dựng trong VB. Tôi có thể sửa chữa điều này, nhưng VB vẫn có vẻ phổ biến hơn nó xứng đáng.

Bất cứ ai có thể giúp trả lời bất kỳ (hoặc tất cả) các câu hỏi sau:

• Tôi có thiếu điều gì với VB không? Có dễ học hơn, hay "thân thiện" hơn C # không? Có những tính năng nào tôi không biết?
• Tại sao VB / VB.net được sử dụng thường xuyên ngày nay, đặc biệt là trong các dự án web?

VB có thể được sử dụng để tạo GUI (phát âm là gooey) để theo dõi địa chỉ IP. Điều này thường được sử dụng trong giải quyết tội phạm .

Tôi nghĩ rằng nó phụ thuộc vào nơi bạn đến từ. Khi bắt đầu làm lập trình viên, tôi nghĩ rằng VB có thể dễ đọc hơn C #, vì nó phụ thuộc nhiều vào các từ hơn các ký hiệu, điều này giúp dễ dàng tiếp nhận người thường.

Tôi là một lập trình viên VB trong nhiều năm và khi .NET xuất hiện, tôi vẫn làm việc trong VB.NET trong vài năm đầu (không thực sự thấy được điểm với C #). Bây giờ tôi có một vài năm C # phía sau tôi và đôi khi tôi thấy rằng mã VB.NET mất nhiều thời gian hơn để tôi "giải mã" hơn mã C #. Có thể bởi vì nó phụ thuộc nhiều vào từ ngữ hơn là biểu tượng cho một số điều ...

Dưới đây tôi vừa sao chép câu trả lời của mình sang một chủ đề khác :

Tôi phát triển trong cả VB và C # một cách thường xuyên, hầu hết việc kiếm tiền của tôi có liên quan đến C #. Cá nhân, tôi thích VB cho hầu hết (nhưng không phải tất cả các lamb lambas!) Hoạt động. Tôi thực sự không thể kể tên bất kỳ lợi thế khó khăn nào ngoài những lợi thế được vạch ra bởi Jon. Trên thực tế, Herfried đã thu thập một số ít trên trang web của mình (bằng tiếng Đức!) Nhưng chúng khá kỹ thuật.

Điều thực sự làm tôi bực mình về tất cả các ngôn ngữ liên quan đến C là cú pháp ngu ngốc. Đây hoàn toàn là văn hóa nhưng là một người làm hầu hết các công việc chuyên môn của mình trong C ++ và khá thành thạo về nó, tôi vẫn hoàn toàn ghét cú pháp. Và không chỉ là những quirks nhỏ dễ thương của C ++. Không, toàn bộ gói. Tại sao phải niềng răng? Tại sao dấu chấm phẩy (có lẽ là quyết định ngu ngốc nhất trong tất cả lịch sử lập trình)? Tại sao cú pháp cast kiểu C ngu ngốc? Tại sao không có từ khóa để khai báo biến (thực ra, đây là quyết định ngu ngốc nhất)?

Có quá nhiều thứ thực sự khiến tôi buồn và tức giận. VB không phải là thánh, ngôn ngữ của nó có nhược điểm rất lớn. Nhưng không có gì so với những gì tôi đã nói ở trên.

Tôi nhận ra rằng hầu hết các tuyên bố này cần sự biện minh nhưng tôi đưa ra rằng điều này chỉ là do chúng ta đã quá quen với chúng. Ngoài ra, đây không phải là nơi thích hợp. Đủ để nói rằng cú pháp của C #, trong khi là lợi thế chính của nó so với VB, cũng là nhược điểm chính của nó.

Tôi không thích VB vì Mykhông gian tên, tôi không thích nó vì chữ XML, tôi không thích nó vì gõ yếu, tôi không thích nó vì các tham số tùy chọn hoặc vì tốt hơn nhiều switchtuyên bố. Không, tôi thích nó vì cú pháp.

Điều đó nói rằng, tôi đã phải thừa nhận rằng VB ngày càng bị vướng bận bởi cú pháp của nó. Sự cường điệu mới nhất dường như là các truy vấn Linq được tham số hóa với các hàm lambda và tôi dễ dàng thừa nhận rằng điều này làm cho nhiều thứ đơn giản hơn. Thật không may, cú pháp của VB cho lambdas đơn giản là quá cồng kềnh để cạnh tranh với C #. Chỉ cần xem xét mức độ phình to của một cuộc gọi Parallel.Fortrông như thế nào trong VB - so với C #, nơi nó trông tự nhiên. IMHO, nhóm thiết kế VB đã đi sai hướng ở đây, ủng hộ tính nhất quán bảo thủ hơn khả năng đọc.

Để trả lời lời buộc tội chủ quan của bạn:

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc.

Bạn chắc chắn có quyền nghĩ như vậy nhưng như Marc đã nói dưới đây, bạn sẽ khó tranh luận điều này một cách khách quan. Tôi chắc chắn có thể trích dẫn một số các yếu tố C cú pháp mà là một cách khách quan hơn dễ bị lỗi hơn bất cứ điều gì hiện có trong VB. Trong thực tế, cú pháp VB đã được phát triển để ngăn chặn các tình huống như vậy một cách rõ ràng.

Những người vụng về, xấu xí và khó đọc là tất cả các vòng loại có thể được gắn thẻ vào gần như tất cả các ngôn ngữ mà bạn không quen thuộc. Nói một cách đơn giản: sự xấu xí là hậu quả trực tiếp của việc bạn không quen với ngôn ngữ này.

Biết một ngôn ngữ tốt có nghĩa là nhận ra các mẫu trong mã. Mã được viết tốt sẽ bằng cách thực hành có vẻ thanh lịch, trong khi mã xấu (chậm, dễ bị lỗi) sẽ xuất hiện xấu. Nó đơn giản như vậy.

Một nhận xét cuối cùng: Các bài viết được trích dẫn bởi bạn có chứa một số thông tin không chính xác và lỗi thời. Như một lời biện minh duy nhất cho một cuộc thảo luận mang tính chủ quan và cảm xúc, họ không phù hợp lắm.

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc.

Đối với tôi, tiếng Anh có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc, đặc biệt là được viết bởi những người có ngữ pháp kém, chính tả kém, coi thường viết hoa và chấm câu, và không có ý thức về cách tổ chức không gian và tinh thần của họ.

Không chỉ là Visual Basic khó đọc hay vụng về vì cú pháp của ngôn ngữ, mà nó thường như vậy bởi vì lập trình viên không thực sự giỏi trong việc thể hiện suy nghĩ của chính mình:

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

Phải, thật kinh khủng. Nhưng nó cũng không khó để viết mã khủng khiếp bằng các ngôn ngữ khác. Khi được viết chính xác, nó sẽ rất có ý nghĩa ngay cả khi mã được viết bằng VB:

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

Ít nhất đó là dễ đọc và dễ hiểu hơn. Nó vẫn CƠ BẢN. Nó thực sự phụ thuộc vào khả năng của lập trình viên thể hiện rõ ràng ý định của mình bằng cách định dạng mã theo cách dễ đọc, sử dụng các định danh được đặt tên tốt và chú ý viết mã dễ hiểu.

Điều đó nói rằng, tôi đã không chạm vào Visual Basic nhiều kể từ ngày VB3, (do đó là ví dụ với cú pháp "cũ") nhưng chỉ vì một ngôn ngữ có thể bị lạm dụng không có nghĩa là nó không thể được sử dụng chính xác để viết mã khá mạnh mẽ . Chắc chắn, có thể có một số thiếu sót, nhưng cách tiếp cận được đưa ra để giải quyết những vấn đề đó cũng cho thấy kỹ năng của một lập trình viên so với người khác.

(Phun thuốc bừa bãi On Error Resume Nextxuất hiện trong tâm trí như một cách không hay để khắc phục những thiếu sót của việc thiếu các ngoại lệ trong VB trở lại trong những ngày trước .NET.)

Hầu hết các cuộc tranh luận của bạn chống lại VB chỉ có thể áp dụng cho VB-Classic (liên kết thứ hai) hoặc dựa trên các đối số mờ nhạt hoặc lỗi thời

• Ngay cả trong VBC, bạn sẽ không sử dụng GoSub ... Return, v.v.
• Có chuyện gì với bạn staticvậy? C ++ cũng hỗ trợ điều này.
• VB10 giới thiệu tiếp tục dòng ngầm định (bạn thậm chí không cần dấu chấm phẩy dư thừa như C #)
• Các hàm cast khác nhau tồn tại trong C ++ và C #. C # (object)(expr)-Cast-Syntax và object as typethậm chí còn khó hiểu và không nhất quán hơn.
• Có gì xấu về with? Bạn có thể tạo các cấu trúc cây lồng nhau theo cách rất trực quan, điều không thể có trong C #.
• Xử lý sự kiện trong VB thanh lịch hơn nhiều so với trong C #. Bạn có thể giới thiệu và xử lý các sự kiện bằng một từ khóa ( WithEvents) mà không cần phải khởi tạo đại biểu, eventhandler-procs, v.v. Điều này làm cho lập trình GUI trong VB trở nên dễ hiểu hơn nhiều và bạn không cần phải tạo mã sự kiện bởi nhà thiết kế .
• Các tham số tùy chọn được đưa vào C # mới - Do đó chúng có vẻ tốt.
• VB.NET có cả toán tử boolean nghiêm ngặt và phím tắt.
• Bạn làm kiểm tra lỗi cú pháp tại thời gian biên dịch trừ khi bạn chạy VB như một kịch bản ngôn ngữ.
• End Iflà hữu ích hơn chỉ }. Khi có cấu trúc cú pháp phức tạp, tất cả các dấu ngoặc nhọn chỉ gây nhầm lẫn trong khi cụ thể End ...giúp bạn xác định khối nào chưa bị đóng.
• Văn học XML - Tập lệnh XML hiện là một phần của mã, được hỗ trợ đầy đủ bởi intellisense.

Nói chung, chỉ có một vài khác biệt khách quan giữa VB.NET và C # ngoài cú pháp. EG: Thiết kế GUI hiệu quả hơn trong VB do hệ thống sự kiện tốt hơn và IDE tốt hơn trong khi các thuật toán có thể được thể hiện tốt hơn trong C # vì cú pháp là trình duyệt.

Phần còn lại chỉ là một câu hỏi về phong cách cá nhân của bạn. Lập trình viên C-Style cảm thấy thoải mái với C #, VB (hoặc có thể là Pascal?) - Lập trình viên phong cách sử dụng VB.

Nhưng VB-Syntax dựa trên từ, rõ ràng hơn có thể dễ đọc hơn cho người mới bắt đầu so với tất cả các ký hiệu trong C. So sánh:

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

đến

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

Điều này không có nghĩa là một ngôn ngữ tốt hơn ngôn ngữ khác.

Chỉnh sửa : -----------------------------------------

Đối số VB sẽ dễ bị lỗi. Khi bạn sử dụng Option Strict Onnó nghiêm ngặt như C # nhưng không cho phép chúng tôi mắc lỗi như vậy:

// 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++;
}

Trong lịch sử, môi trường phát triển VB là một cách nhanh chóng và hiệu quả để xây dựng một số loại ứng dụng nhất định (ví dụ: ứng dụng GUI). Điều đó dẫn đến nó là một lựa chọn rất phổ biến. Tôi nghĩ VB là ngôn ngữ được sử dụng nhiều nhất trong thời hoàng kim (ví dụ VB6).

Với loại cơ sở được cài đặt đó, hầu như không ngạc nhiên khi vẫn còn rất nhiều công việc đang diễn ra trong đó.

Tất cả bắt đầu trước khi C # tồn tại

Trở lại năm 1999, chúng tôi đã có Visual Studio 5/6. Nếu bạn là Nhà cung cấp phần mềm độc lập hoặc công ty sử dụng Windows và cần một ứng dụng được viết, ví dụ như theo dõi thời gian của nhân viên dành cho các dự án, bạn có một vài lựa chọn:

1. Các hình thức trong Visual Basic.
2. MFC, ATL hoặc Win32 trong Visual C ++.
3. Các hình thức trong Truy cập 97/2000.
4. Trang web ASP.
5. Táo Java.

Vào thời điểm đó, chúng tôi đã ở ngay trước khi bong bóng Dot-Com nổ tung, vì vậy bất kỳ ai tốt với (4) hoặc (5) đã đi ra để đàm phán các lựa chọn cổ phiếu tại bất kỳ điểm dot-com tuyệt vời nào mà họ bị thu hút.

(3) có vấn đề với khóa và khả năng mở rộng tổng thể, nhưng tôi đã thấy rất nhiều giải pháp dựa trên Truy cập sẽ bỏ ra để chạy các chức năng hỗ trợ khi cần.

Vì vậy, điều đó cho chúng ta với VB và VC ++:

Trình soạn thảo Forms trong VB, vào thời điểm đó, tuyệt vời cho năng suất. Bạn có thể kéo thả các thành phần của mình - không chỉ các nút, nhãn và hộp văn bản mà cả hộp công cụ 'điều khiển OLE' đầy đủ của các thành phần có thể sử dụng lại như lưới thông minh, trang tính Excel hoặc phiên bản IE. Việc kết nối được thực hiện ở hậu trường - mọi thứ đều giống như đối tượng và bạn chỉ cần nhấp đúp vào những thứ để thêm trình xử lý sự kiện. Điều này đã khó hơn rất nhiều trong Visual C ++. Là thành viên của nhóm hỗ trợ nhà phát triển Visual Studio tại thời điểm đó, tôi có thể nhớ cách các cuộc gọi hỗ trợ Visual Basic chủ yếu là về thành phần nào là tốt nhất để sử dụng hoặc cách tối ưu hóa ứng dụng của họ theo những cách nhất định. Gần như không bao giờ 'làm thế nào để tôi tạo một ứng dụng với các tính năng giao diện người dùng X, Y và Z'.

Xây dựng một giao diện người dùng phong phú trong Visual C ++ là một thách thức khác. Mặc dù đã có hỗ trợ trình soạn thảo trực quan cho các hộp thoại và biểu mẫu SDI / MDI, nhưng nó khá hạn chế. Hỗ trợ để nhúng Điều khiển OLE (ActiveX) vào MFC hoặc Win32 là một nghệ thuật đen, mặc dù dễ dàng hơn một chút trong ATL. Việc xử lý những thứ đơn giản như thay đổi kích thước các sự kiện hoặc vẽ chủ sở hữu là khá khó khăn, chứ đừng nói đến Điểm kết nối cần thiết cho các sự kiện tùy chỉnh trong các thành phần.

Có, VC ++ có tốc độ thực thi, khả năng gỡ lỗi và các tùy chọn khung / thư viện / giao diện người dùng linh hoạt, nhưng hỗ trợ IDE không thể bao quát tất cả các vấn đề cơ bản nhất để giải quyết các hoạt động phổ biến nhất với các thứ như Wizard, phân cấp lớp MFC toàn diện và 90 ngày / 2 dòng hỗ trợ sự cố miễn phí.

IIRC, trình đóng gói ứng dụng đi kèm với VB có thể đóng gói ứng dụng của bạn, thời gian chạy VB và các điều khiển phổ biến mới nhất DLL và cung cấp cho bạn trình cài đặt EXE độc lập mà bạn có thể đưa vào CD và đến với khách hàng. Không ai trong số này 'mà bạn đã cài đặt msvcrtXX.dll và mfcxx.dll?', Điều này đã gây khó khăn cho các nhà phát triển MFC.

Vì vậy, vì lý do giao diện người dùng theo thời gian và thị trường phong phú, VB đã có một lượng người theo dõi rất lớn.

Khi Visual J ++ và Visual Interdev tấn công vào VS6, rõ ràng Visual Basic IDE đã giành chiến thắng trong cuộc chiến với Visual C ++, một IMHO công bằng. Không có gì ngạc nhiên khi Visual Studio .NET có trình chỉnh sửa biểu mẫu giống VB cho ngôn ngữ COOL C # mới.

Ngôn ngữ giống Java / C / C ++ mới được kết hợp với trình thiết kế UI được người VB yêu thích trong suốt thời gian này đã đưa ra một đường di chuyển mới cho những người C ++ hiện đang thực hiện với MFC / ATL / Win32. Đối với VB 3/4/5/6, những người không thích thiếu khả năng tương thích ngược 100% trong VB.net, điều này mang đến cơ hội học một ngôn ngữ mới trong một môi trường quen thuộc.

Những lý do khiến VB là một sản phẩm toàn diện như vậy có thể có liên quan đến nguồn gốc của Microsoft, với Basic là sản phẩm dành cho nhà phát triển hàng đầu của họ, nhưng tôi không có bất kỳ trích dẫn nào vào lúc này.

Tuy nhiên, bất kỳ ngôn ngữ nhất định nào cũng có thể là lý do để gắn bó với ngôn ngữ này: nó rất tốn kém để loại bỏ một cơ sở mã khổng lồ và thực tế là các nhà phát triển đã biết ngôn ngữ này, làm cho nó rẻ hơn so với các ngôn ngữ khác.

VB.NET dễ học hơn, bạn nói đúng và về tổng thể thì dễ hơn C #. Đó là điểm đầu tiên tại sao VB rất phổ biến. Một điểm khác, và điểm lớn nhất, tôi nghĩ, là có một sự kết hợp rất lớn của các nhà phát triển đã làm việc với VB 6 và các phiên bản cũ hơn của ngôn ngữ này và họ dễ dàng phát triển các ứng dụng với VB.net hơn là học một ngôn ngữ mới.

Như những người khác đã nói, phán đoán thẩm mỹ của bạn đối với cú pháp ngôn ngữ phụ thuộc rất nhiều vào những gì bạn biết trước đây. Trong hơn một thập kỷ, có vẻ như đây là một cuộc thi giống như C, với các dấu ngoặc nhọn cho "khối", "->" cho sự gián tiếp (perl, php), dấu ngoặc đơn cho các đối số gọi hàm, // cho bình luận, và một dấu chấm phẩy ở mỗi đầu dòng. Một số người thậm chí đã nghĩ rằng nhờ vào 'penée unique' này, nếu bạn biết một ngôn ngữ, bạn biết tất cả, điều này thực sự vô lý. Nhưng điều này thấm nhuần ý tưởng giữa những người C ++ / Java đó là thẩm mỹ cú pháp đúng duy nhất và bất cứ điều gì khác đang cố gắng sao chép COBOL.

Vài năm trước tôi đã chuyển sang ruby, và bây giờ là trăn, và tôi không thể chịu đựng thêm bất kỳ dấu chấm phẩy xấu xí nào, dấu ngoặc nhọn và các ký tự vô nghĩa rác rưởi khác. Mã nguồn có nghĩa là được đọc bởi con người. Khi tôi đã thử một phòng thu trực quan, tôi đã chọn VB trên C #. Tôi nghi ngờ một số lập trình viên đã chọn C # chỉ để "trông nghiêm túc" với cú pháp giống như java của nó, nhưng thôi, các tính năng rất giống nhau ở đó ... hãy cho mắt bạn nghỉ ngơi.

Chà, nếu bạn đang nói về .NET, tôi có thể nghĩ ra một điều thực sự dễ dàng:

Trình soạn thảo của VB.NET trong Visual Studio tốt hơn nhiều trong việc bắt lỗi cú pháp so với C #.

Mặc dù trình chỉnh sửa của C # đã có một cải tiến lớn trong VS2008 SP1, nhưng vẫn có một số lỗi cú pháp mà trình soạn thảo không phát hiện ra cho đến khi bạn cố gắng biên dịch chương trình.

Phần lớn sự phổ biến của VB bắt nguồn từ thời mà công cụ của VB thân thiện hơn nhiều so với các ngôn ngữ có sẵn khác. VB "cổ điển" cung cấp một cách dễ dàng để xây dựng các ứng dụng Windows mà không cần phải tìm hiểu sự can đảm của API Win32 hoặc bận tâm với việc quản lý bộ nhớ thủ công. Rào cản gia nhập cho các lập trình viên mới bắt đầu với VB thấp hơn nhiều so với C ++, vì vậy rất nhiều người đã cắt răng bằng VB.

Ngày nay, tôi nghĩ VB một lợi thế so với C # là sự quen thuộc đối với những người đã làm việc với VB trong những năm qua. Một ưu điểm khác là mã VB rất dễ đọc vì xu hướng sử dụng từ khóa thay vì ký hiệu dấu chấm câu. Là một người làm việc trong VB, Java, C, C # và Python, tôi thấy rằng VB là ngôn ngữ dễ dàng nhất để quay trở lại khi xem lại mã mà tôi đã viết cách đây nhiều năm. Cú pháp dài dòng hơn, thường giúp đọc mã dễ dàng hơn và Visual Studio luôn làm rất tốt việc định dạng mã VB để dọn sạch định dạng khi bạn nhập để mã được định dạng nhất quán (bất kể sự chậm chạp của tác giả).

Là một lưu ý phụ, tôi thấy Python cực kỳ dễ đọc và xem xét vì những lý do tương tự. Trong Python, định dạng mã được thực thi bởi trình thông dịch chứ không phải IDE, nhưng kết quả cuối cùng là như nhau. Python cũng ưu tiên các từ khóa để chấm câu, mặc dù ít hơn so với VB.

Thật khó để tranh luận rằng đó là bất kỳ "dễ bị lỗi" hơn hoặc ít hơn bất kỳ ngôn ngữ nào khác. Tôi cũng nghi ngờ điểm "đại đa số web MS thương mại"; từ những gì tôi đã thấy, C # là người đi đầu trong việc phát triển .NET (với .NET là công cụ hàng đầu trong ngăn xếp MS cho những thứ không phải trình điều khiển thiết bị, v.v.).

Một lợi thế VB.NET có trên C # (sẽ biến mất với C # 4), là các tham số mặc định và được đặt tên, một điều rất hay khi sử dụng VSTO.

VB / VB.NET thuộc danh mục RAD (Phát triển ứng dụng nhanh). Bạn có thể phát triển các ứng dụng chỉ bằng các điều khiển kéo thả từ hộp công cụ và ít mã hơn.

Chà, tôi nghĩ bạn phải phân biệt giữa VB cổ điển và VB.NET.

Tôi cảm thấy VB.NET không phổ biến lắm, nhưng Visual Basic "Classic" vẫn là1 Lý do là nó rất dễ tạo ứng dụng Windows. So sánh điều này với một ứng dụng Windows trong C ++ / Mfc, gần như là sự thay thế duy nhất tại thời điểm này.

Vì lý do tương tự, Delphi đã rất nổi tiếng một thời.

VB rất dài dòng và dễ dàng làm quen so với C # là trường hợp nhạy cảm. Đối với một lập trình viên mới làm quen, điểm khởi đầu tốt nhất của nó.

Đến tên một vài:

• dễ sử dụng
• tên quen thuộc (cơ bản là một trong những ngôn ngữ lập trình máy tính phổ biến đầu tiên)
• đừng đánh giá thấp tiếp thị microsoft

Tôi nghĩ một phần lý do là bởi vì các lập trình viên asp cũ đi vào .NET như tôi đã làm rất quen thuộc với VB vì tập lệnh VB là ngôn ngữ cổ điển được sử dụng cho phần lớn. Tôi cảm thấy ít tốn thời gian hơn khi viết bằng VB bằng .NET vì tôi đã biết cách nói VB. VB cũng ít khóc hơn C #. Tôi có thể đọc / ghi cả hai nhưng tôi thích VB hơn vì dễ kết bạn nếu bạn là lập trình viên mới.

Tôi làm việc trong một môi trường nơi chúng tôi sử dụng cả hai. Chúng tôi đã chuyển sang C # để ủng hộ ASP và VB cổ điển. Theo tôi không có sự phá vỡ thỏa thuận giữa các ngôn ngữ. Đối với hầu hết các dự án, bạn có thể làm cùng một công việc với cả hai ngôn ngữ. Bây giờ tôi chia sẻ quan điểm của bạn về xu hướng lỗi và tôi cũng thấy VB bị lộn xộn (không có lý do).

Như những người khác đã đề cập, VB rất đơn giản và trong lịch sử bạn có thể xây dựng các dự án rất nhanh. Điều này sống trong phát triển web (được phát triển nhanh), nhưng tôi nghĩ khi mọi người nhận ra rằng C # cũng phát triển nhanh như vậy, VB sẽ biến mất. Một lý do khác tôi nghĩ nó sẽ mờ dần là mọi thứ khác mà bạn viết mã (CSS, JavaScript) khi tạo các ứng dụng web trông giống C # hơn VB, vì vậy sẽ rất hợp lý khi sử dụng C #, ngay cả đối với người mới bắt đầu.

Cá nhân tôi thích cách các sự kiện được đính kèm trong vb.net với từ khóa 'xử lý' ... IDE / Visual Studio / cũng phản ứng nhanh hơn khi xử lý VB và tự động xử lý hầu hết các kết thúc và tương tự ... C # dĩ nhiên là gọn gàng và sạch sẽ hơn nhiều (IMHO, tôi đã làm việc với cả hai khá nhiều)

Đối với khung 4.0, chỉ có một số ít điều VB thiếu so với C #, và điều ngược lại cũng đúng. Cụ thể là:

1. Đáng chú ý nhất là VB.NET không có Yield từ khóa, nhưng nó sẽ sớm xuất hiện trên VB.NET với khung async mới.
2. Không có unsafe từ khóa. Tôi chưa bao giờ thấy cần thiết, nhưng chắc chắn có một số người có.
3. Không có chuỗi nhiều dòng. Chuỗi nhiều dòng được thực hiện bằng cách sử dụng các toán tử + (hoặc di sản &) trên các dòng. Hoặc, chúng có thể được thực hiện bằng cách sử dụng cú pháp bằng chữ XML:Dim s = <s>My string... multiple lines...</s>.Value . Nó không đẹp, nhưng nếu bạn không kén chọn và thực sự muốn các chuỗi nhiều dòng thì nó hoạt động. Và, bạn có thể thực hiện phép nội suy chuỗi với nó bằng <%= myVar %>cú pháp rất hay.
4. Không có biến phạm vi tương đương với dynamic. Các biến động đã xuất hiện trong VB trong một thời gian dài Option Compare Off, nhưng đó là phạm vi tệp, vì vậy nó không tốt như dynamicbởi vìdynamic giới hạn phạm vi chỉ có biến được khai báo theo cách đó.
5. VB thiếu một cú pháp lambda ngắn gọn. Lambdas ở đó, nhưng bạn phải sử dụng Function(x)hoặc Sub(x).

Một số tính năng VB.NET có C # không:

1. Chữ XML, tiện dụng cho tất cả các loại, không chỉ XML.
2. Không phân biệt chữ hoa chữ thường trong ngôn ngữ là tiếng kêu của mèo. Không có nhiều ngôn ngữ khác cho phép, nhưng tốc độ mã hóa sẽ không bao giờ phải nhấn phím shift khi bạn nhập và mã của bạn chỉ tự động định dạng theo cách bạn muốn.
3. SelectMệnh đề thường không cần thiết có thể được bỏ qua từ các truy vấn Linq.
4. Các Nothingtừ khóa là nhiều hơn nữa hữu ích hơn nullở chỗ tất cả mọi thứ (kiểu giá trị chẵn) có thể được thiết lập để Nothingvà bạn sẽ có được mặc định. Không cần defaulttừ khóa.
5. VB.NET được biên dịch liên tục trong Visual Studio để bạn thấy lỗi ngay lập tức. Không nhấn CTRL-SHIFT-B cả ngày như trong C #.

Cửa hàng của tôi thực hiện MVC3 với Dao cạo bằng VB.NET và một khi bạn vượt qua định kiến ​​(chủ yếu là không có cơ sở), đó thực sự là một ngôn ngữ rất hay để sử dụng. Nó không thực sự dài dòng hơn C # như nhiều yêu cầu (ngoại trừ trường hợp lambdas) và đó là tính năng tương tự nhiều tính năng song song với C #. Tôi đã thấy rằng hầu hết những người ghét đều không thực sự được mã hóa trong VB.NET hiện đại trong bất kỳ khoảng thời gian nào.