아래에서 방금 답변을 다른 스레드에 복사했습니다 .
저는 VB와 C #에서 정기적으로 개발하고 있으며, 대부분의 돈 버는 데 C #이 관여했습니다. 개인적으로 저는 대부분의 람다 작업에 VB를 선호합니다. Jon의 개요와는 별개로 어려운 장점은 없습니다. 실제로 Herfried는 자신의 웹 사이트 (독일어)에서 몇 가지를 수집 했지만 다소 기술적입니다.
모든 C 관련 언어에 대해 정말로 나를 괴롭히는 것은 바보 같은 구문입니다. 이것은 순전히 문화적이지만 C ++에서 전문적인 작업을 수행하고 능숙한 사람으로서 여전히 문법을 싫어합니다. 그리고 C ++의 귀여운 작은 단점이 아닙니다. 아니오, 전체 패키지. 왜 중괄호? 왜 세미콜론 (아마도 모든 프로그래밍 역사에서 가장 어리석은 결정)입니까? 왜 바보 같은 C 스타일 캐스트 구문입니까? 변수 선언에 대한 키워드가없는 이유는 무엇입니까 (실제로 이것이 가장 멍청한 결정입니다)?
나를 슬프고 화나게하는 것들이 너무 많습니다. VB는 성자가 아니며 언어에는 큰 단점이 있습니다. 그러나 위에서 말한 것과 비교할만한 것은 없습니다.
나는이 진술들 대부분이 타당성을 필요로한다는 것을 알고 있지만, 이것이 우리가 그들에게 너무 익숙해 졌기 때문이라고 생각합니다. 또한 여기가 옳지 않습니다. C #의 구문은 VB에 비해 주요 이점이기는하지만 주요 단점이기도합니다.
My
네임 스페이스 때문에 VB를 선호 하지 않고 XML 리터럴 때문에 선호하지 않습니다. 약한 입력 때문에 선호하지 않습니다. 선택적 매개 변수 때문에 선호하지 않습니다. switch
성명서. 아니요. 구문 때문에 선호합니다.
즉, 나는 VB가 그 구문에 의해 점점 더 복잡해 짐을 인정해야합니다. 최신 과대 광고는 람다 함수로 매개 변수화 된 Linq 쿼리 인 것으로 보이며 이것이 많은 것을 단순화한다는 것을 쉽게 인정합니다. 불행히도 람다에 대한 VB의 구문은 C #과 경쟁하기에 너무 성가시다. Parallel.For
자연스럽게 보이는 C #과 비교하여 VB에서 호출이 부풀어 오른 것처럼 보이는 방법을 고려하십시오 . VB 디자인 팀 IMHO는 여기에서 잘못된 방향으로 이동하여 가독성에 대한 보수적 인 일관성을 선호합니다.
주관적인 고발에 대답하려면 :
나에게 Visual Basic은 서투르고, 추악하고, 오류가 발생하기 쉽고 읽기 어려워 보입니다.
당신은 확실히 그렇게 생각할 자격이 있지만 Marc가 아래에서 말했듯이, 당신은 이것을 객관적으로 주장하기가 어렵다는 것을 알게 될 것입니다. VB에 존재하는 것보다 객관적으로 오류가 발생하기 쉬운 많은 C 구문 요소를 인용 할 수 있습니다 . 실제로 VB 구문은 이러한 상황을 명시 적으로 방지하기 위해 개발되었습니다.
"서투른, 못생긴 ... 그리고 읽기 어려운"은 익숙하지 않은 거의 모든 언어에 태그를 지정할 수있는 한정자입니다. 간단히 말해서, 추악함은 언어에 익숙하지 않은 것의 직접적인 결과입니다.
언어를 잘 아는 것은 코드에서 패턴을 인식하는 것을 의미합니다. 잘 작성된 코드 는 실제로는 우아하게 보이고 나쁜 (느린 오류가 발생하기 쉬운) 코드는보기 흉하게 나타납니다. 그렇게 간단합니다.
마지막 비고 : 귀하가 인용 한 기사에는 몇 가지 부정확성과 오래된 정보가 포함되어 있습니다. 매우 주관적이고 정서적 인 토론에 대한 유일한 정당화는 그다지 적합하지 않습니다.