¿Por qué es tan popular VB? [cerrado]

Para mí, Visual Basic parece torpe, feo, propenso a errores y difícil de leer. Dejaré que otros expliquen por qué . Si bien VB.net claramente ha sido un gran avance para el lenguaje en términos de características, todavía no entiendo por qué alguien elegiría codificar en VB en lugar de, por ejemplo, C #.

Sin embargo, todavía veo (lo que parece ser) la gran mayoría de las aplicaciones web comerciales de "tiendas MS" están construidas en VB. Podría corregir esto, pero VB todavía parece más popular de lo que merece.

¿Alguien puede ayudar a responder alguna (o todas) de estas preguntas:

• ¿Me estoy perdiendo algo con VB? ¿Es más fácil de aprender o "más amigable" que C #? ¿Hay características que no conozco?
• ¿Por qué VB / VB.net se usa con tanta frecuencia hoy, especialmente en proyectos web?

VB se puede utilizar para hacer GUI (pronunciado pegajoso) para rastrear direcciones IP. Esto a menudo se usa para resolver crímenes .

Creo que depende de dónde vienes. Al comenzar como programador, creo que VB podría ser más fácil de leer que C #, por ejemplo, ya que se basa más en palabras que en símbolos, lo que hace que sea más fácil de asimilar para las personas normales.

Fui programador de VB durante muchos años y, cuando llegó .NET, todavía trabajé en VB.NET durante los primeros años (realmente no veía el punto con C #). Ahora tengo algunos años de C # detrás de mí y, a veces, encuentro que el código VB.NET tarda un poco más en "decodificar" que el código C #. Posiblemente porque se basa más en palabras que en símbolos para algunas construcciones ...

A continuación, acabo de copiar mi respuesta a otro hilo :

Me desarrollo tanto en VB como en C # de forma regular, la mayor parte de mi dinero ha involucrado a C #. Personalmente, prefiero VB para la mayoría (pero no para todos ... ¡lambdas!) De trabajo. Realmente no puedo nombrar ninguna ventaja difícil aparte de las descritas por Jon. En realidad, Herfried ha recopilado algunos en su sitio web (¡en alemán!), Pero son bastante técnicos.

Lo que realmente me molesta de todo el lenguaje relacionado con C es la sintaxis estúpida. Esto es puramente cultural, pero como alguien que hace la mayor parte de su trabajo profesional en C ++ y que es bastante hábil en eso, todavía odio la sintaxis. Y no solo las pequeñas peculiaridades de C ++. No, todo el paquete. ¿Por qué frenillos? ¿Por qué punto y coma (quizás la decisión más estúpida en toda la historia de la programación)? ¿Por qué la estúpida sintaxis de reparto estilo C? ¿Por qué no hay una palabra clave para la declaración de variables (en realidad, esta es la decisión más estúpida)?

Hay tantas cosas que realmente me ponen triste y enojado. VB no es un santo, su lenguaje tiene grandes inconvenientes. Pero nada comparado con lo que he dicho anteriormente.

Me doy cuenta de que la mayoría de estas declaraciones necesitan justificación, pero afirmo que esto es solo porque nos hemos acostumbrado tanto a ellas. Además, aquí no es el lugar correcto. Baste decir que la sintaxis de C #, aunque es su principal ventaja sobre VB, también es su principal desventaja.

No prefiero VB debido al Myespacio de nombres, no lo prefiero debido a los literales XML, no lo prefiero debido a una escritura débil, no lo prefiero debido a parámetros opcionales, o por el mejor switchdeclaración. No, lo prefiero por la sintaxis.

Dicho esto, debo admitir que VB se ve cada vez más gravado por su sintaxis. El último bombo parece ser consultas de Linq parametrizadas con funciones lambda y admito que esto simplifica muchas cosas. Desafortunadamente, la sintaxis de VB para lambdas es simplemente demasiado engorrosa para competir con C #. Solo considere qué tan hinchada se Parallel.Forve una llamada a VB, en comparación con C #, donde se ve natural. En mi humilde opinión, el equipo de diseño de VB ha ido en la dirección equivocada aquí, favoreciendo la consistencia conservadora sobre la legibilidad.

Para responder a su acusación subjetiva:

Para mí, Visual Basic parece torpe, feo, propenso a errores y difícil de leer.

Ciertamente tiene derecho a pensarlo, pero como Marc ha dicho a continuación, le resultará difícil argumentar esto objetivamente. Definitivamente puedo citar varios elementos de sintaxis de C que son objetivamente más propensos a errores que cualquier cosa existente en VB. De hecho, la sintaxis de VB ha sido desarrollada para prevenir tales situaciones explícitamente.

"Torpe, feo ... y difícil de leer" son calificadores que se pueden etiquetar en casi todos los idiomas con los que no está familiarizado. En pocas palabras: la fealdad es una consecuencia directa de su desconocimiento del idioma.

Conocer bien un idioma significa reconocer patrones en el código. El código bien escrito , en virtud de la práctica, parecerá elegante, mientras que el código malo (lento, propenso a errores) aparecerá feo. Es tan simple como eso.

Una última observación: los artículos citados por usted contienen varias inexactitudes e información desactualizada. Como única justificación para una discusión altamente subjetiva y emocional, no son muy adecuados.

Para mí, Visual Basic parece torpe, feo, propenso a errores y difícil de leer.

Para mí, el inglés parece torpe, feo, propenso a errores y difícil de leer, especialmente escrito por personas que tienen mala gramática, mala ortografía, despreocupación temeraria por las mayúsculas y la puntuación, y no tienen idea de cómo organizar sus pensamientos espacial y mentalmente.

No es solo que Visual Basic sea difícil de leer o torpe debido a la sintaxis del lenguaje, sino que generalmente es así porque el programador no es realmente bueno para expresar sus propios pensamientos:

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

Bien, eso es horrible. Pero tampoco es particularmente difícil escribir código horrible en otros idiomas. Cuando se escribe correctamente, tendría mucho sentido incluso si el código está escrito en VB:

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

Al menos eso es más legible y comprensible. Sigue siendo BÁSICO. Realmente se reduce a la capacidad del programador para expresar claramente sus intenciones formateando el código de una manera fácil de leer, utilizando identificadores bien nombrados y prestando atención a escribir código comprensible.

Dicho esto, no he tocado mucho Visual Basic desde los días de VB3 (de ahí el ejemplo con la sintaxis "antigua"), pero el hecho de que se pueda abusar de un lenguaje no significa que no se pueda usar correctamente para escribir código bastante robusto . Claro, puede haber algunas deficiencias, pero los enfoques diseñados para solucionar esos problemas también muestran las habilidades de un programador sobre otro.

(La fumigación indiscriminada me On Error Resume Nextviene a la mente como una forma no tan buena de solucionar las deficiencias de la falta de excepciones en VB en los días anteriores a .NET).

La mayor parte de su argumentación contra VB solo es aplicable a VB-Classic (segundo enlace) o se basa en argumentos débiles u obsoletos

• Incluso en VBC, no usarás GoSub ... Return etc.
• ¿Qué tiene de malo static? C ++ también lo admite.
• VB10 introduce la continuación de línea implícita (ni siquiera necesita semicola redundante como C #)
• Las diferentes funciones de conversión existen en C ++ y C # también. C # 's (object)(expr)-Cast-Syntax y object as typeson aún más confusos e inconsistentes.
• ¿De qué está mal with? Puede crear estructuras de árbol anidadas de una manera muy intuitiva que no es posible en C #.
• La gestión de eventos en VB es mucho más elegante que en C #. Puede introducir y manejar eventos con una sola palabra clave ( WithEvents) sin tener que inicializar delegados, eventos, controladores, etc. Esto hace que la programación de GUI en VB sea mucho más cómoda y no necesita generar código de evento por parte del diseñador .
• Los parámetros opcionales se introducen en el nuevo C #, por lo tanto, parecen ser buenos.
• VB.NET tiene ambos operadores estrictas y de acceso directo-booleana.
• Usted no comprueba los errores de sintaxis en tiempo de compilación a menos que corra VB como un lenguaje de script.
• End Ifes más útil que acaba }. Al tener estructuras sintácticas complejas, todas las llaves son confusas, mientras que un concreto lo End ...ayuda a determinar qué bloque no se ha cerrado.
• Literales XML: el script XML ahora es parte del código, totalmente compatible con intellisense.

Con todo, solo hay algunas diferencias objetivas entre VB.NET y C # aparte de la sintaxis. EG: El diseño de GUI es mucho más eficiente en VB debido a un mejor sistema de eventos y un mejor IDE, mientras que, por ejemplo, los algoritmos se pueden expresar mejor en C # porque la sintaxis es más concisa.

El resto es solo una cuestión de tu estilo personal. Los programadores de C-Style se sienten cómodos con C #, VB (o tal vez Pascal?) - Los programadores de Style usan VB.

Pero la sintaxis VB más explícita basada en palabras puede ser más fácil de leer para principiantes que todos los símbolos en C. Compare:

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

a

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

Esto no significa que un idioma sea mejor que otro.

Editar: -----------------------------------------

Para el argumento VB sería propenso a errores. Cuando lo usa Option Strict Ones tan estricto como C # pero no nos permite cometer tales errores:

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

Históricamente, el entorno de desarrollo de VB era una forma rápida y efectiva de crear ciertos tipos de aplicaciones (por ejemplo, aplicaciones GUI). Eso lo llevó a ser una opción muy popular. Creo que VB fue el lenguaje más utilizado durante su apogeo (por ejemplo, VB6).

Con ese tipo de base instalada, no es sorprendente que todavía haya mucho trabajo por hacer.

Todo comenzó antes de que C # existiera

En ~ 1999, teníamos Visual Studio 5/6. Si usted era un proveedor de software independiente o una empresa que utilizaba Windows y necesitaba una aplicación escrita que pudiera, por ejemplo, rastrear el tiempo empleado por los empleados en proyectos, tenía algunas opciones:

1. Formularios en Visual Basic.
2. MFC, ATL o Win32 en Visual C ++.
3. Formularios en Access 97/2000.
4. Sitio web de ASP.
5. Applet de Java

En ese momento, estábamos justo antes de que estallara la burbuja Dot-Com, por lo que cualquiera que fuera bueno con (4) o (5) se fue a negociar opciones de compra de acciones en cualquier punto-com increíble que se sintieran atraídos.

(3) tenía problemas con el bloqueo y la escalabilidad general, pero vi muchas soluciones basadas en Access que se ejecutarían para ejecutar funciones de soporte según sea necesario.

Entonces eso nos deja con VB y VC ++:

El editor de formularios en VB era, en ese momento, excelente para la productividad. Puede arrastrar y soltar sus componentes, no solo botones, etiquetas y cuadros de texto, sino la caja de herramientas completa de 'controles OLE' de componentes reutilizables como Cuadrículas inteligentes, hojas de Excel o instancias de IE. El cableado se realizó detrás de escena: todo era como un objeto y simplemente hacía doble clic en las cosas para agregar controladores de eventos. Esto fue mucho más difícil en Visual C ++. Como miembro del equipo de soporte de desarrolladores de Visual Studio en ese momento, puedo recordar cómo las llamadas de soporte de Visual Basic se referían principalmente a qué componente era mejor usar o cómo optimizar su aplicación de ciertas maneras. Casi nunca fue "cómo hago una aplicación con las funciones de interfaz de usuario X, Y y Z".

Construir una interfaz de usuario rica en Visual C ++ fue un desafío diferente. Aunque había soporte de editor visual para diálogos y formularios SDI / MDI, era bastante limitado. El soporte para incrustar controles OLE (ActiveX) en MFC o Win32 fue un arte negro, aunque un poco más fácil en ATL. Conectar cosas simples como cambiar el tamaño de los eventos o el dibujo del propietario fue bastante doloroso, y mucho menos los puntos de conexión necesarios para los eventos personalizados en los componentes.

Sí, VC ++ tenía la velocidad de ejecución, la capacidad de depuración y las opciones flexibles de frameworks / bibliotecas / UI, pero el soporte IDE no podía cubrir todo ese terreno, por lo que abordó las operaciones más comunes con cosas como Wizards, jerarquías de clase MFC integrales y 90 días / 2-incidentes libres de líneas de soporte.

IIRC, el empaquetador de aplicaciones que se envió con VB podría empaquetar su aplicación, el tiempo de ejecución de VB y las últimas DLL de controles comunes y proporcionarle un instalador EXE independiente que podría poner en un CD y llegar a los clientes. Nada de esto '¿qué msvcrtXX.dll y mfcxx.dll tiene instalado?', Lo que afectó a los desarrolladores de MFC.

Por lo tanto, por razones de tiempo de comercialización y una interfaz de usuario rica, VB obtuvo muchos seguidores.

Cuando Visual J ++ y Visual Interdev llegaron a VS6, estaba claro que el IDE de Visual Basic había ganado alguna batalla sobre el Visual C ++, lo cual era justo en mi humilde opinión. No fue ninguna sorpresa que Visual Studio .NET tuviera un editor de formularios tipo VB para el nuevo lenguaje COOL C #.

El nuevo lenguaje similar a Java / C / C ++ junto con el diseñador de UI que disfrutan las personas de VB durante todo este tiempo proporcionó una nueva ruta de migración para las personas de C ++ que ahora habían terminado con MFC / ATL / Win32. Para las personas VB 3/4/5/6 a las que no les gustaba la falta de compatibilidad con el 100% hacia atrás en VB.net, esto ofrecía la oportunidad de aprender un nuevo idioma en un entorno familiar.

Las razones por las que VB era un producto tan completo probablemente tengan algo que ver con los orígenes de Microsoft, con Basic como su producto desarrollador insignia, pero no tengo ninguna cita en este momento.

Por muy feo que sea, cualquier idioma dado puede ser la razón por la que se adhiere a él: es muy costoso desechar una gran base de código y el hecho de que los desarrolladores ya conozcan el idioma hace que sea más barato de usar que otros idiomas.

VB.NET es más fácil de aprender, tiene razón, y en general es más fácil que C #, en mi opinión. Es el primer punto por el que VB es tan popular. Otro, y el punto más importante, creo, es que hay una gran comunidad de desarrolladores que trabajaron con VB 6 y versiones anteriores de este lenguaje y les es más fácil desarrollar aplicaciones con VB.net que aprender un nuevo idioma.

Como han dicho otros, su juicio estético sobre la sintaxis del lenguaje depende en gran medida de lo que sabía antes. Durante más de una década, parece que ha sido un concurso similar a C, con llaves para "bloques", "->" para indirección (perl, php), paréntesis para argumentos de llamada a funciones, // para comentarios, y un punto y coma en cada extremo de la línea. Algunas personas incluso pensaron que gracias a este 'pensée unique', si conoces un idioma, los conoces a todos, lo cual es realmente ridículo. Pero esto inculcó la idea entre la gente de C ++ / Java de que la única sintaxis estética correcta y cualquier otra cosa es tratar de clonar COBOL.

Hace unos años me cambié a rubí, y ahora a Python, y no puedo soportar más puntos y comas feos, llaves y otros caracteres sin sentido. El código fuente está destinado a ser leído por humanos. Cuando probé el estudio visual, elegí VB sobre C #. Sospecho que algunos programadores eligen C # solo para "verse serio" con su sintaxis similar a Java, pero vamos, las mismas características están ahí ... dale un descanso a tus ojos.

Bueno, si estás hablando de .NET, hay uno realmente fácil en el que puedo pensar:

El editor de VB.NET en Visual Studio es mucho mejor para detectar errores de sintaxis que C # 's.

Si bien el editor de C # obtuvo una gran mejora en VS2008 SP1, todavía hay algunos errores de sintaxis que el editor no detecta hasta que intente compilar el programa.

Gran parte de la popularidad de VB se originó en un momento en que las herramientas de VB eran mucho más amigables que otros idiomas disponibles. El VB "clásico" ofreció una manera fácil de construir aplicaciones de Windows sin tener que aprender las agallas de la API Win32 o molestarse con la administración manual de memoria. La barrera de entrada para los programadores principiantes fue mucho menor con VB que C ++, por lo que mucha gente se cortó los dientes con VB.

En estos días, creo que VB una ventaja sobre C # es la familiaridad para aquellos que han trabajado con VB a través de los años. Otra ventaja es que el código VB es fácil de leer debido a la tendencia a usar palabras clave en lugar de signos de puntuación. Como alguien que trabaja en VB, Java, C, C # y Python, encuentro que VB es el lenguaje más fácil para volver a saltar al revisar el código que escribí hace años. La sintaxis es más detallada, lo que a menudo hace que sea más fácil leer el código, y Visual Studio siempre ha hecho un gran trabajo formateando el código VB para limpiar el formato a medida que escribe para que el código tenga un formato constante (independientemente de la descuido del autor).

Como nota al margen, considero que Python es extremadamente fácil de leer y revisar por razones similares. En Python, el intérprete impone el formato del código en lugar del IDE, pero el resultado final es el mismo. Python también favorece las palabras clave a la puntuación, aunque podría decirse que menos que VB.

Sería difícil argumentar que es más o menos "propenso a errores" que cualquier otro idioma. También dudo del punto re "gran mayoría de la web comercial de MS"; por lo que he visto, C # está tomando la delantera en el desarrollo de .NET (siendo .NET la herramienta estrella en la pila de MS para cosas que no son controladores de dispositivos, etc.).

Una ventaja que VB.NET tiene sobre C # (que desaparecerá con C # 4), es la configuración predeterminada y los parámetros con nombre, algo muy bueno cuando se usa VSTO.

VB / VB.NET pertenece a la categoría RAD (Desarrollo rápido de aplicaciones). Puede desarrollar aplicaciones con solo controles de arrastrar y soltar desde la caja de herramientas y menos código.

Bueno, creo que tienes que diferenciar entre VB clásico y VB.NET.

Siento que VB.NET no es muy popular, pero Visual Basic "Classic" todavía lo es1. La razón es que es MUY fácil crear una aplicación de Windows. Compare esto con una aplicación de Windows en C ++ / Mfc, que era casi la única alternativa en este momento.

Por la misma razón, Delphi fue muy popular alguna vez.

VB es muy detallado y fácil de acostumbrarse en comparación con C #, que distingue entre mayúsculas y minúsculas. Para un programador novato es el mejor punto de partida.

Para nombrar unos pocos:

• facilidad de uso
• nombre familiar (básico fue uno de los primeros lenguajes populares de programación de computadoras)
• no subestimes el marketing de microsoft

Creo que parte de la razón es porque los viejos programadores de asp que ingresan a .NET como yo lo he hecho ya están muy familiarizados con VB porque el script VB es el lenguaje ASP clásico utilizado en su mayor parte. Sentí que tomaba menos tiempo escribir en VB en .NET porque ya sabía cómo hablar VB. VB también es menos llorón que C #. Puedo leer / escribir en ambos, pero prefiero VB porque es fácil hacer amigos si eres un nuevo programador.

Trabajo en un ambiente donde usamos ambos. Hemos cambiado a C # a favor de ASP y VB clásicos. En mi opinión, no hay acuerdos entre los idiomas. Para la mayoría de los proyectos, puede hacer el mismo trabajo con ambos idiomas. Ahora comparto su opinión sobre la propensión a errores y también encuentro que VB está abarrotado (sin ninguna razón).

Como otros han mencionado, VB es muy simple e históricamente podrías construir proyectos muy rápido. Esto vivió en el desarrollo web (que se desarrolla rápidamente), pero creo que cuando las personas se den cuenta de que C # es tan rápido como desarrollado, VB se desvanecerá. Otra razón por la que creo que se desvanecerá es que todo lo demás que codifica (CSS, JavaScript) al hacer aplicaciones web se parece más a C # que a VB, por lo que tiene sentido usar C #, incluso para principiantes.

Personalmente, me gusta la forma en que los eventos se adjuntan en vb.net con la palabra clave 'maneja' ... El IDE / Visual Studio / también es más receptivo cuando se trata de VB y maneja automáticamente la mayoría de los end-ifs y similares ... C # es, por supuesto, mucho más consistente y limpio (en mi humilde opinión, he trabajado con ambos bastante)

A partir del marco 4.0, solo hay un pequeño puñado de cosas que VB carece en comparación con C #, y lo contrario también es cierto. A saber:

1. Lo más notable es que VB.NET no tiene la Yieldpalabra clave, pero pronto llegará a VB.NET con el nuevo marco asíncrono.
2. No hay unsafepalabra clave Nunca lo he encontrado necesario, pero seguramente hay algunas personas que lo han hecho.
3. No hay cadenas de varias líneas. Las cadenas de varias líneas se logran mediante el uso de operadores + (o los operadores heredados y) entre líneas. O bien, pueden llevarse a cabo mediante el uso de la sintaxis XML literal: Dim s = <s>My string... multiple lines...</s>.Value. No es bonito, pero si no eres exigente y realmente quieres cadenas de varias líneas, funciona. Y puede hacer una interpolación de cadenas con la <%= myVar %>sintaxis, lo cual es bueno.
4. No hay un equivalente de ámbito variable de dynamic. Las variables dinámicas han existido en VB durante mucho tiempo con Option Compare Off, pero ese es el alcance del archivo, por lo que no es tan bueno como dynamicporque dynamiclimita el alcance solo a la variable declarada de esa manera.
5. VB carece de una sintaxis lambda concisa. Las lambdas están ahí, pero tienes que usar Function(x)o Sub(x).

Algunas características que VB.NET tiene que C # no:

1. Literales XML, que son útiles para todo tipo de cosas, no solo XML.
2. La insensibilidad a mayúsculas y minúsculas en un idioma es el maullido del gato. No muchos otros idiomas lo permiten, pero qué diferencia hace en la velocidad de codificación para no tener que presionar la tecla Mayús cuando está escribiendo y hacer que su código se formatee automáticamente de la manera que lo desee.
3. La Selectcláusula a menudo innecesaria puede omitirse de las consultas de Linq.
4. La Nothingpalabra clave es mucho más útil que nullen que todo (incluso los tipos de valor) se puede establecer Nothingy obtener el valor predeterminado. No hay necesidad de la defaultpalabra clave.
5. VB.NET se compila constantemente en Visual Studio para que pueda ver los errores de inmediato. No presionar CTRL-SHIFT-B durante todo el día como en C #.

Mi tienda hace MVC3 con Razor usando VB.NET y una vez que superas los prejuicios (en su mayoría infundados), en realidad es un lenguaje muy agradable de usar. En realidad, no es más detallado que C # como afirman muchos (excepto en el caso de lambdas), y es más o menos paralelo a C #. Descubrí que la mayoría de las personas que odian no han codificado realmente en VB.NET moderno por ningún período de tiempo.