He estado en lugares de trabajo donde, al comienzo de un proyecto, se ha planteado la pregunta "¿Deberíamos usar VB.Net o C #?".
De acuerdo, es probable que sea menos común tener que tomar esa decisión ahora que en los primeros días de .Net, particularmente dada la tendencia hacia la convergencia de idiomas, pero aún puede ser un debate acalorado.
Entonces, entre VB.Net y C #, ¿qué idioma prefieres y por qué?
Solo para lanzar una llave inglesa en los trabajos, hay algunos productos (por ejemplo, diseñador de WF en VS2010) que solo admiten la sintaxis de VB.Net ...
Damovisa
Por aquí, a los programadores de C # se les paga más que a los programadores de VB.NET.
SeanX
Eliminé parte del título "Lo eterno" que parece realmente "poco constructivo". La pregunta en sí es muy útil y la calidad de las respuestas es una indicación mucho mejor de cómo es constructivo que las infames "seis pautas".
Wizard79
A menudo me pregunto si eso se revertirá si la tendencia continúa hacia C #, lo que hace que las personas con VB.NET tengan una experiencia más escasa y puedan obtener una prima más alta.
+1 SO está reemplazando rápidamente a Google como mi fuente preferida de ayuda de programación.
Tipo anónimo
12
La pregunta es si las 10 veces más etiquetas C # significan que el tema está mejor cubierto, más uso o tiene más problemas. +1 en disponibilidad de trabajo.
JeffO
12
Sería cauteloso con cualquier empleador que no contratara a un programador de VB.NET para hacer C #.
Matt Olenik
@Anónimo: SO reemplazó google por el día 2 (hace más de un año). Firefox en casa tiene SO, MSDN y Programadores como mis 3 sitios principales de búsqueda.
IAbstract
@IAbstract, jajaja, muy cierto.
Tipo anónimo el
27
Odio VB.NET. Los días que todavía paso usándolo son los días de los que me arrepiento. Dicho esto, mis gustos son parte de mi situación y experiencia, y no necesariamente tienen ninguna relevancia con lo que estás haciendo ...
Creo que es importante, al comparar lenguajes en constante evolución como C # y VB.NET, mirar hacia atrás en su historia y ver cómo llegaron a su estado actual:
Las ventajas originales de BASIC en microcomputadoras incluían tamaño y simplicidad (sintaxis pequeña y fácil de analizar hecha para intérpretes pequeños y razonablemente rápidos y espacio en memoria para el programa y los datos reales), un entorno interactivo que permitió la experimentación y una sintaxis que evitaban símbolos y estructuras breves para una sintaxis razonablemente clara, similar a la inglesa. Sin embargo, no era adecuado para programas grandes y estructurados, y tendía a fomentar el código de espagueti. Aún así, su disponibilidad y simplicidad lo convirtieron en una excelente opción para una introducción a la programación.
QuickBasic actualizó la sintaxis para permitir programas grandes y más estructurados, y agregó compilación para una ejecución más rápida.
VisualBasic proporcionó un generador de formularios potente y fácil de usar para permitir la construcción rápida de aplicaciones GUI, al tiempo que adoptó la sintaxis QB para usar en la creación de secuencias de comandos de estas IU. Funcionó mejor cuando se usaba para crear interfaces de usuario para lógica de bajo nivel proporcionada como componentes preconstruidos (generalmente escritos en algún otro idioma). Con el tiempo, la sintaxis se hizo cada vez más grande e inconsistente a medida que se añadieron nuevas características. El enfoque en la elaboración de una interfaz de usuario primero y luego completar los fragmentos de script funcionó bien para aplicaciones pequeñas centradas en la interfaz de usuario, pero tendió a fomentar la programación de copiar y pegar y una variación en el código de espagueti al tiempo que desalienta la reutilización, estructuras de datos complejas y separación de intereses. En la mente de muchos, "código VB" se convirtió en sinónimo de "gran bola de lodo"; "Programador VB" con "hack inexperto".
VB.NET es un lenguaje similar a VB en la plataforma .NET, un intento (no del todo exitoso) de limpiar y modernizar la sintaxis de VB. No era perfectamente compatible con el código VB existente, y no hizo ningún esfuerzo para proporcionar compatibilidad con los formularios VB (posiblemente la parte más importante de VB). Esto dejó a muchos propietarios de productos VB con la desagradable opción de reescribir efectivamente sus aplicaciones en VB.NET (lidiando con incompatibilidades sutiles en cada rutina que no fue examinada cuidadosamente) o realmente reescribiendo sus aplicaciones en C # (lidiando con un desconocido sintaxis además dela nueva biblioteca de tiempo de ejecución y diseñador de formularios). La mayoría de los usuarios de VB.NET eran usuarios de VB que se apegaban a ella solo por la sintaxis, muchos de ellos la usaban como muleta mientras aprendían C #. Como resultado, adquirió inmediatamente la reputación de ser un paraíso para los programadores que se habían quedado atascados en su camino, no dispuestos o incapaces de expandir o mejorar sus habilidades.
En este momento, VB.NET continúa evolucionando, eliminando poco a poco el equipaje mientras recoge una sintaxis nueva e interesante (LINQ, literales XML). Aún así, no conserva casi ninguna de las ventajas originales de BASIC: es un lenguaje grande y complejo con una curva de aprendizaje bastante pronunciada y oportunidades limitadas para la experimentación interactiva.
Para los programadores antiguos que se han quedado con él en los últimos 30 años, no es una mala elección, siempre que no se limiten a ello.
Para los nuevos programadores, la semejanza cada vez más vaga de los programas de VB con el inglés apenas vale la pena los extraños guiños a la compatibilidad con versiones anteriores y el estigma social.
Para proyectos nuevos , VB.NET es una elección extraña a menos que el proyecto esté muy involucrado en una de las pocas tareas para las que está optimizado el lenguaje: integración con componentes COM mal escritos (Office ...) (aunque C # 4.0 reduce esta ventaja considerablemente ) o generación XML en línea.
Con C # 4 no veo ninguna ventaja que VB.Net todavía tenga con respecto a la integración COM. Creo que la generación de XML en línea podría ser una característica útil; Intento no usar XML (¡y he tenido éxito durante los últimos 5 años!), Pero si tengo un proyecto .net que necesita generar mucho XML, probablemente crearé un proyecto VB solo para la generación de XML.
configurador
3
Estaba disfrutando leer tu respuesta, pero pareció detenerse de repente. Proporcionas un historial básico que es interesante y supongo correcto. Esperaba descubrir por qué no le gusta VB.NET y / o por qué le gusta C #. "Para nuevos proyectos, VB.NET es una elección extraña" ¿Por qué?
Tim Murphy
@Tim: No me gusta VB [.NET] porque la mayor parte del código que encuentro es un código de espagueti sin tipo escrito por programadores que lo recogieron en el trabajo hace años (o fueron enseñados por dichos codificadores). Sin embargo, esa no es necesariamente una buena razón para que a alguien más no le guste. Una mejor razón es simplemente que el lenguaje ha hecho demasiadas concesiones a la compatibilidad con versiones anteriores ... y, sin embargo, en realidad no es compatible con versiones anteriores. Entonces, a menos que esté buscando escribir un nuevo código de espagueti sin tipo ...
Shog9
20
Estoy familiarizado con ambos, pero hice muchos de mis primeros trabajos de programación en VB4, VB5 y VB6. Ahora que ambos lenguajes en .NET han pasado por algunas iteraciones y han convergido bastante en sus capacidades, creo que el debate es francamente tonto, muy parecido a "cuál es su color favorito".
Personalmente, me gustan los dos por diferentes razones.
VB.NET
Mucha gente habla sobre cómo la sintaxis de C # es más intuitiva, pero eso es muy subjetivo y se basa en gran medida en lo que comenzaste a saber. Yo diría que si fuera completamente objetivo, la sintaxis de VB.NET es probablemente más intuitiva si no asume conocimientos previos en otro idioma. Por ejemplo, dado el mismo programa en C # y VB.NET, ¿qué crees que sería más descifrable para alguien que no tiene conocimientos de programación? Me parece bastante claro.
La otra cosa que es agradable acerca de esta sintaxis es que es mucho más explícito acerca del cierre de estructuras (END IF, END WHILE, NEXT X) en comparación con el modelo de bracketing. Hace que el código sea un poco más legible y, a menudo, permite que el compilador sea más preciso en qué número de línea está causando errores de compilación. Si alguna vez se ha perdido una búsqueda de soporte / punto y coma debido a un error del compilador a 50 líneas del problema, ya sabe a qué me refiero.
Además, en la columna ganadora de VB.NET, en mi opinión, hay falta de == / = como operadores de comparación / asignación. Los beneficios poco comunes de tener un operador distinto para cada uno nunca compensarán todas las debilidades (a veces) difíciles de descubrir que ayuda a crear.
Finalmente, odio las mayúsculas y minúsculas en los lenguajes de programación. Una de las quejas sobre VB es que tiene mucho equipaje, pero C # llevó el albatros de la sensibilidad a mayúsculas y minúsculas de C. Nunca he estado en una situación en la que quisiera que dos identificadores en el mismo alcance difieran solo por caso. Simplemente hace un trabajo ocupado y me frena. VB.NET obtiene algunos puntos sobre C # en este sentido para mí.
Los programadores de C #
adoran ser concisos, por eso creo que generalmente favorecen esta sintaxis. Simplemente tiene un cierto atractivo estético. Sin embargo, desde una perspectiva completamente práctica, me gusta porque es muy similar a lenguajes como Java, JavaScript y C ++.
Dado que realizo mucho desarrollo web que requiere programación tanto del lado del servidor como del cliente, me resulta más fácil cambiar mentalmente entre C # y JavaScript, como a menudo se me exige.
También me gusta el hecho de que, en su mayor parte, que si alguna vez tuviera que hacer la transición para hacer programación Java o C ++, tendría un poco de ventaja si usara C # la mayor parte del tiempo.
+1 para el comentario de desarrollo web. Utilizo VB.NET y C #, dependiendo del proyecto, y me resulta mucho más fácil ir y venir entre C # y Javascript que VB.NET y JS.
Paperjam
2
"Nunca he estado en una situación en la que quisiera que dos identificadores en el mismo alcance difieran solo por caso". Es puramente subjetivo. Esta es exactamente una de las razones por las que prefiero C #. Cuando se aplica correctamente y en consecuencia, podría tener sentido para el mundo tener, por ejemplo, un parámetro en el constructor con el nombre namey una propiedad pública con el nombre Namey luego asignarlo a través Name = name;. Siempre que mantenga un estándar de codificación, de lo contrario, estoy de acuerdo, entonces puede causar confusión.
Aidiakapi
1
Necesitar un estándar de codificación para evitar errores insidiosos como ese, para mí, es negativo. La presencia de una solución alternativa no lo disculpa.
JohnFx
Debería ser difícil escribir código descuidado en cualquier lenguaje de programación. La insensibilidad a mayúsculas y minúsculas alienta el código descuidado. La sensibilidad a mayúsculas y minúsculas no te ralentiza en absoluto, ¿qué tipo de argumento es este? Te ralentiza cuando haces muchos errores tipográficos y luego es bueno que te estén frenando.
Halcón
Es solo un código descuidado porque el compilador no puede interpretarlo. Si todos los compiladores no distinguen entre mayúsculas y minúsculas, no importaría nada. Nuestro trabajo no es escribir código para imprimir en una revista, es escribir código que haga un trabajo. El caso "descuidado" no inhibe ese bit.
JohnFx
19
Prefiero la sintaxis de soporte de los lenguajes de estilo C a la sintaxis más "detallada" de los lenguajes de estilo BASIC.
Mi introducción a la programación fue con Turbo Pascal. (La parte de programación BÁSICA que hice en el Commodore 64, cuando era niño, realmente no cuenta). Después de aprender Java, nunca miré hacia atrás y preferí la sintaxis de estilo C.
"Sintaxis" detallada "de los lenguajes de estilo BASIC". - Sí, nunca volví a mirar a VB cuando viif something then code endif
TheLQ
1
Je, me sorprendió que alguien hubiera rechazado esto. (Esperaba que fuera la pregunta de Emacs vs Vim.)
George Marian
3
@TheLQ: y también el AndAlso!
Gerry
Extraño mis días de Turbo Pascal. Eso fue muy divertido.
MetalMikester
1
Encuentro la sintaxis de soporte más fácil de leer. Un símbolo genérico para un bloque en lugar de varias palabras específicas de contexto.
Michael K
12
Funcionalmente son iguales, no hay nada que pueda hacer en uno que no pueda hacer en el otro, y para el futuro Microsoft ha prometido que los equipos de idiomas se desarrollarán de manera uniforme, por lo que es poco probable que esto cambie.
[Nota: aunque soy un desarrollador de C #, la conclusión del artículo vinculado no refleja necesariamente mi opinión personal, es solo un enfoque alternativo interesante en el debate]
No es del todo cierto: por ejemplo, VB.NET no tiene iteradores, que son una excelente característica de C #.
Thomas Levesque
2
C # no tiene los literales XML de VB.NET: blogs.msdn.com/b/wriju/archive/2008/02/07/… (aunque no soy un fanático de la característica por razones arquitectónicas, ES genial)
Steven Striga
@Thomas @WeekendWarrior: Buenos ejemplos, pero solo para señalar, dije "Funcionalmente lo mismo", que son. Ambos compilan a IL, por lo que se puede lograr el mismo conjunto de funcionalidades. Estos ejemplos son solo atajos de idioma para la funcionalidad que se puede lograr de otras maneras.
Simon P Stevens
8
Llegué a .NET desde C y C ++ (con un poco de Java, Ada y Pascal), así que C # fue la progresión natural para mí.
Si apareciera un trabajo que requiriera VB.NET, ciertamente no lo rechazaría.
He trabajado mucho con VB.NET, pero entiendo suficiente C # para entender lo que está sucediendo en el código. Mi preferencia actual es VB.NET porque estoy más familiarizado con él (obviamente), pero realmente no tengo preferencia entre la sintaxis BASIC detallada y la sintaxis de estilo C, ambas son muy legibles y comprensibles para mí.
La mayor parte de la experiencia de programación de mi compañero de trabajo es COBOL y VB6, por lo que VB.NET fue la opción de lenguaje .NET más cómoda para nosotros como equipo. No había una razón sólida para nosotros que hiciera que aprender C # fuera un requisito ya que funcionalmente son lo mismo.
Dicho esto, aprender C # definitivamente está en mi lista de cosas que hacer.
Estoy en el mismo problema. :) y prefiero VB.NET de la misma manera que prefiero Coca-Cola, no Pepsi. Pero, si comenzamos un nuevo proyecto, C # es la mejor opción porque encontraremos más programadores que conocen y prefieren C #. Comprendí que la estrategia de MS para VB era traer la comunidad VB a la plataforma .NET.
Pagotti
5
Prefiero C #.
Comencé como programador de VB.NET, pero con el paso del tiempo se hizo evidente que muchas características nuevas están llegando primero a C # y luego a VB.NET (por ejemplo, propiedad automática). Y la comunidad que rodea a C # es mucho más animada que la de VB.NET.
Además, si tiene la intención de aprender Java o un lenguaje similar, C # es un mejor punto de partida: la sintaxis es casi la misma en todos los lenguajes derivados de C. Aunque esto no sería un punto de inflexión para mí, ya que la sintaxis es algo que puedes aprender rápidamente de todos modos.
"Sin embargo," las características llegan primero a C # "No siempre es así. Ver stackoverflow.com/questions/181188/… (Solo para lanzar otra llave inglesa en proceso)
Nota para uno mismo - piense en un nombre
Aquí es donde estoy. Todavía soy aficionado a VB, ya que es donde comencé, pero en mi opinión C # tiene una mejor sintaxis en cosas como las expresiones lambda. Por otro lado, VB tiene XML Literals, que C # solo puede soñar. Creo que vale la pena romper un proyecto VB separado para un trabajo XML pesado.
Kyralessa
1
Con cada generación de herramientas, los argumentos de "características" cambian un poco. Lo único que puedo pensar de qué C # tiene a partir de vs2010 que le falta a vb.net es iteradores; por el contrario, vb.net ofrece indexadores con nombre, filtros de excepción, literales XML, un operador "Is" que es 1000 veces más atractivo que Object.ReferenceEquals, un manejo de eventos que está casi bien hecho y una experiencia IDE más fluida. VB.net hace posible, aunque un poco incómodo, que los inicializadores de campo usen parámetros de constructor o creen IDisposableobjetos de forma segura sin tener que usar ThreadStaticvariables; C # no lo hace.
supercat
5
Además de las otras respuestas publicadas aquí, elegiría C # sobre VB porque a los programadores de C # se les paga más. Más experiencia con C # = más $$ :)
Sé que ambos idiomas son casi iguales y es muy fácil cambiar entre los dos, pero creo que cuando la gerencia mira un montón de llaves y punto y coma, aceptan el hecho de que estamos haciendo algo que no pueden hacer, donde con VB. Net podrían mirarlo y decir "oh, eso no debe ser tan difícil de hacer si puedo entenderlo".
Creo que un punto bastante válido que a menudo se pasa por alto dependiendo de la industria / región.
Tipo anónimo el
4
C # porque puedo cambiar entre él y Java con un mínimo esfuerzo
VB.NET es una sintaxis completamente diferente. C #, ser similar a Java y otros lenguajes me da una mejor posición para adaptarme rápidamente a cosas nuevas. Dado que la salida de C # y VB.NET son prácticamente intercambiables, tiene sentido ir con C #. Además, si el código de su empresa está en C #, es más probable que pueda capacitar a un desarrollador de Java sobre cómo codificar C # que a un desarrollador de Java VB. Solo hay ventajas sutiles, pero sutiles sigue siendo una ventaja.
Dejando a un lado mis preferencias personales. Como alguien que ha estado reclutando (y tratando de ser reclutado) últimamente, cuando tuvimos este debate en la oficina, el consenso general fue que deberíamos buscar pasar a C # desde VB.
¿Por qué? Debido a que C # era más frecuente en el mercado (a nuestro alrededor de todos modos), lo que nos permite reclutar más fácilmente y ser reclutados más fácilmente.
Parece que se ha ido un círculo completo; la gente aprende C # porque los reclutadores lo quieren, porque hay más candidatos.
Siendo un desarrollador algo mayor (¿es 59 "algo" mayor?), Aprendí BASIC primero en un Commodore VIC-20, me enseñé Turbo Pascal (v1!), Aprendí COBOL en la universidad y pasé 14 años desarrollando en IBM mainframes, con breves diversiones escribiendo aplicaciones de tamaño mediano en Revelation BASIC (una variante de PICK BASIC) y algunas utilidades en Modula-2, antes de pasar a VB5 y VB6. Y luego vino .NET.
Debido a mi experiencia básica, pensé que debería comenzar con VB.NET, solo para descubrir que seguía tratando de hacer las cosas a la "antigua" y me estaba volviendo loco (está bien, más locos). Siendo que había hecho algo de trabajo en C, pensé en darle un giro a C # para ver cómo iba eso. ¡Y OMG, eso fue como salir de un túnel oscuro a la clara luz del día! Totalmente inesperado Y solía hacer ruidos despectivos acerca de que C era un lenguaje "de solo escritura", "tan difícil de entender que un programador de C no podía entender qué hacía su propio código 6 meses después de que lo escribió", una observación hecha por novelista semi-famoso que pensé que sonaba lindo en ese momento.
Entonces, en virtud de no estar familiarizado con C, C # fue paradójicamente más fácil para mí aprender programación .NET que el paradigma básico mucho más familiar. Todavía me gusta VB6, pero he llegado a amar C #. El mejor lenguaje de programación del planeta.
Respuesta interesante, creo que esto al menos en parte, echa por tierra la idea de que la "gente mayor" tienden a pegarse a VB.NET sobre C #
Anónimo Tipo
3
¡Me desarrollo en Visual Basic .Net desde 2001 y me encanta y lo odio!
El orden de presentación de estos puntos se basa solo en el orden en que vino a mi mente ...
En vb.net con Visual Studio, hay un salto de línea visual entre cada método, propiedad. Para muchas personas, no es una buena razón para preferir vb.net sobre c #, pero no entiendo por qué el equipo de c # en Microsoft no lo ha implementado. Hay un complemento que dibuja esta línea en c # pero agradece nuevamente a Microsoft que tenga un equipo ac # y un equipo visual básico que no se comuniquen entre sí.
En vb.net, cuando crea una forma de triunfo, tiene dos cuadros combinados en Visual Studio en la parte superior del editor y puede generar eventos automáticamente al seleccionar un evento en el cuadro combinado correcto. Cuando adjuntas docenas de eventos cada día, puede ser muy engorroso no tener esta función. Con c #, tiene un pequeño botón en la parte superior de la cuadrícula de propiedades que puede generar eventos, pero no es tan rápido como en vb.net. Además, si adjunta un evento de control en c # y elimina el control en el formulario, el delegado creado en el código generado automáticamente para manejar el evento debe eliminarse manualmente. Gracias de nuevo Microsoft.
En vb.net, cuando intenta modificar un método que contiene una consulta linq sin modificar la consulta en sí, no hay problema, pero en c #, todo el código del método está bloqueado. Si tiene muchas consultas linq o expresiones lambda, la función de edición y continuación será rápidamente algo bueno. Ok, un poco de exageración ... pero :)
En vb.net, cuando crea un nombre de método y toca enter, se creará automáticamente el 'fin de sub'. En c #, hágalo usted mismo. Ok, si tiene resharper o devexpress instalado, será mejor, pero ¿por qué todas estas pequeñas pero excelentes características no se implementaron en c #?
En vb.net, cuando tiene errores en su código, los errores se muestran automáticamente y cuando lo corrige, estos errores se eliminan de la pila en tiempo real. En c #, debe crear su proyecto para darse cuenta de que ha corregido correctamente o no los errores especificados. ¿Por qué el equipo de C # no ha puesto una opción para verificar el error en tiempo real como en vb.net? Con una gran solución, ninguna verificación de error en tiempo real puede ser una optimización muy agradable del rendimiento, pero me encanta ver desaparecer un montón de errores mientras lo corrijo.
Como otra persona ha mencionado, creo que es más fácil leer la condición vb.net si ... termine si, seleccione el caso ... finalice la selección pero con el soporte de pintura devexpress, olvide lo que dije.
Con vb.net, hay muchos errores en Visual Studio. Solo por mencionar uno en Visual Studio 2010, los intellisens no filtran correctamente la enumeración si tiene el modo "común" activado en lugar de "todos".
Con vb.net, eres percibido como un tipo ficticio porque estáticamente, más programadores malos usan vb.net en lugar de c # porque c # es más difícil de aprender y promover una mejor práctica de programación.
Como dijo otro, el programador de C # tiene más posibilidades de tener un buen trabajo con más dinero.
En la cabeza del cliente, vb.net = chico que programa en su sótano con un bol de espagueti de código. c # = wow, eres muy inteligente. El hecho es que no es porque programes en c #, que haces un buen programa, sino estáticamente, sí.
Con todos estos puntos, elegí convertir todo mi código vb en c #. Programo con todas las mejores prácticas de orientación a objetos, patrón de diseño, código limpio con estándares y sintaxis estricta y puedo programar así durante 50 años, pero desde la perspectiva de la comunidad, no soy un buen programador. Convertiré mi código en c # sin otras prácticas recomendadas y seré otra persona; un gran tipo al que debes respetar ..... :( ¡qué broma ... !!! pero es la realidad.
Aquí hay una forma de verlo: entre SO y CodePlex, ¿qué idioma es más popular? C # o VB.Net?
A veces, seguir al rebaño es algo bueno porque es el rebaño el que podrá ayudarlo cuando lo necesite. Por defecto, C # será más rápido que Vb.Net. Sin embargo, creo que usar Option Strict podría igualarlo. La última vez que comparé IL entre los dos, el tipo de seguridad de VB.Net terminó agregando aproximadamente un 15% más a la IL. Esto se traduce en gastos generales adicionales. Y ... dados los idiomas que hacen básicamente lo mismo, tomaré el más rápido. Mi conveniencia no debe anular la experiencia de mi usuario en general.
Me gusta decir que la única razón por la que BASIC sigue siendo popular es porque fue el primer producto de Microsoft, y lo han estado empujando en nuestras gargantas durante los últimos 35 años. Debería haber muerto hace mucho tiempo.
Dicho esto, trabajé en dos proyectos .NET considerables y ambos se realizaron con VB.Net, aunque había un poco de C # porque la traducción era una perra o la construcción no existía en VB.Net. La única ventaja que veo con VB.Net es que el editor de Visual Studio es mucho más amigable (en mi experiencia de todos modos) que con C # - Intellisense parece mejor, y también lo hace el autoformato (tenga en cuenta que, dado que no he usado C # tanto, es posible que me falte algo en la configuración del IDE ...)
Una desventaja importante en VB.Net es que trajeron una gran cantidad de basura de la era VB6 en .NET 1.x para facilitar la conversión del código VB6. Eso todavía está ahí, y los codificadores VB6 están codificando código nuevo usando esas ... "extensiones" en lugar de usar las clases / métodos .NET más neutrales. No sé cuántas veces le pregunté a mi jefe por qué todavía usaba esa basura. "Pero ... Funciona ..." Correcto. Oye, me gusta quejarme.
Mientras buscaba ayuda en la web, descubrí que la gran mayoría de las soluciones estaban en C #: consulte los foros de MSDN, varios blogs, etc. Los libros tienden a centrarse en C #, y si hay una versión VB, generalmente viene meses después (por ejemplo, Pro LINQ ... de Apress).
Muchos lenguajes comparten la ascendencia C, lo que facilita mucho el cambio entre C, C ++, C #, Java, PHP y algunos otros. PHP es un poco exagerado aquí, pero tiene muchas construcciones similares a C. VB? Bueno, es prácticamente su propia cosita y eso es todo.
Un líder de proyecto en mi organización me dijo recientemente que se están desarrollando más y más proyectos nuevos usando C # en lugar de VB - FINALMENTE. Cuando se introdujo .NET en nuestra organización, más o menos se unieron oficialmente a VB.Net debido a toda la codificación VB6 que ya estaba en curso. Los poderes que más tarde me admitieron que ese no era su mejor movimiento.
Como alguien más señaló anteriormente, no diría que no a un proyecto de VB.Net, pero todavía espero que sea erradicado lentamente del desarrollo más reciente en mi lugar de trabajo.
Bueno, hoy hay poca o ninguna razón real para usar VB.net. Al principio era solo una forma de dar a los programadores de VB una sintaxis familiar, pero era esencialmente una reasignación de C # similar a BASIC. Por lo tanto, su única ventaja real es una sintaxis más familiar, y su sintaxis BÁSICA también es su único límite real.
Con el tiempo, los dos idiomas evolucionaron junto, la única diferencia significativa es el my pseudo espacio de nombres.
Recomendaría a todos los programadores .net que no estén familiarizados con C # que lo aprendan, ya que la comunidad es bastante más grande y la sintaxis tipo C es común a la mayoría de los lenguajes más utilizados.
Otra consideración importante de por qué existe VB.NET es que hizo una ruta de actualización más fácil para proyectos que estaban en ASP "Classic" / VBScript o VB6. Fue mucho menos trabajo portar grandes aplicaciones existentes.
JohnFx
1
VB, el lenguaje es más fácil de leer para los novatos, tienden a escribir su primera, segunda y tercera aplicación en él y todos sabemos cómo se codifican nuestras primeras aplicaciones, terriblemente.
Los programadores de C ++, Java y etc. se han mudado a C #, mientras que los desarrolladores de VB.NET provienen de VBA, VB y BASIC, programadores esenciales no tradicionales.
Parece que hay más ejemplos de código C # en línea que ejemplos de VB.NET. No es que sea tan difícil convertir uno a otro, pero ¿por qué molestarse si no es necesario?
Respuestas:
Prefiero C # sobre VB.NET porque
(desde stackoverflow)
fuente
Odio VB.NET. Los días que todavía paso usándolo son los días de los que me arrepiento. Dicho esto, mis gustos son parte de mi situación y experiencia, y no necesariamente tienen ninguna relevancia con lo que estás haciendo ...
Creo que es importante, al comparar lenguajes en constante evolución como C # y VB.NET, mirar hacia atrás en su historia y ver cómo llegaron a su estado actual:
Las ventajas originales de BASIC en microcomputadoras incluían tamaño y simplicidad (sintaxis pequeña y fácil de analizar hecha para intérpretes pequeños y razonablemente rápidos y espacio en memoria para el programa y los datos reales), un entorno interactivo que permitió la experimentación y una sintaxis que evitaban símbolos y estructuras breves para una sintaxis razonablemente clara, similar a la inglesa. Sin embargo, no era adecuado para programas grandes y estructurados, y tendía a fomentar el código de espagueti. Aún así, su disponibilidad y simplicidad lo convirtieron en una excelente opción para una introducción a la programación.
QuickBasic actualizó la sintaxis para permitir programas grandes y más estructurados, y agregó compilación para una ejecución más rápida.
VisualBasic proporcionó un generador de formularios potente y fácil de usar para permitir la construcción rápida de aplicaciones GUI, al tiempo que adoptó la sintaxis QB para usar en la creación de secuencias de comandos de estas IU. Funcionó mejor cuando se usaba para crear interfaces de usuario para lógica de bajo nivel proporcionada como componentes preconstruidos (generalmente escritos en algún otro idioma). Con el tiempo, la sintaxis se hizo cada vez más grande e inconsistente a medida que se añadieron nuevas características. El enfoque en la elaboración de una interfaz de usuario primero y luego completar los fragmentos de script funcionó bien para aplicaciones pequeñas centradas en la interfaz de usuario, pero tendió a fomentar la programación de copiar y pegar y una variación en el código de espagueti al tiempo que desalienta la reutilización, estructuras de datos complejas y separación de intereses. En la mente de muchos, "código VB" se convirtió en sinónimo de "gran bola de lodo"; "Programador VB" con "hack inexperto".
VB.NET es un lenguaje similar a VB en la plataforma .NET, un intento (no del todo exitoso) de limpiar y modernizar la sintaxis de VB. No era perfectamente compatible con el código VB existente, y no hizo ningún esfuerzo para proporcionar compatibilidad con los formularios VB (posiblemente la parte más importante de VB). Esto dejó a muchos propietarios de productos VB con la desagradable opción de reescribir efectivamente sus aplicaciones en VB.NET (lidiando con incompatibilidades sutiles en cada rutina que no fue examinada cuidadosamente) o realmente reescribiendo sus aplicaciones en C # (lidiando con un desconocido sintaxis además dela nueva biblioteca de tiempo de ejecución y diseñador de formularios). La mayoría de los usuarios de VB.NET eran usuarios de VB que se apegaban a ella solo por la sintaxis, muchos de ellos la usaban como muleta mientras aprendían C #. Como resultado, adquirió inmediatamente la reputación de ser un paraíso para los programadores que se habían quedado atascados en su camino, no dispuestos o incapaces de expandir o mejorar sus habilidades.
En este momento, VB.NET continúa evolucionando, eliminando poco a poco el equipaje mientras recoge una sintaxis nueva e interesante (LINQ, literales XML). Aún así, no conserva casi ninguna de las ventajas originales de BASIC: es un lenguaje grande y complejo con una curva de aprendizaje bastante pronunciada y oportunidades limitadas para la experimentación interactiva.
fuente
Estoy familiarizado con ambos, pero hice muchos de mis primeros trabajos de programación en VB4, VB5 y VB6. Ahora que ambos lenguajes en .NET han pasado por algunas iteraciones y han convergido bastante en sus capacidades, creo que el debate es francamente tonto, muy parecido a "cuál es su color favorito".
Personalmente, me gustan los dos por diferentes razones.
VB.NET
Mucha gente habla sobre cómo la sintaxis de C # es más intuitiva, pero eso es muy subjetivo y se basa en gran medida en lo que comenzaste a saber. Yo diría que si fuera completamente objetivo, la sintaxis de VB.NET es probablemente más intuitiva si no asume conocimientos previos en otro idioma. Por ejemplo, dado el mismo programa en C # y VB.NET, ¿qué crees que sería más descifrable para alguien que no tiene conocimientos de programación? Me parece bastante claro.
La otra cosa que es agradable acerca de esta sintaxis es que es mucho más explícito acerca del cierre de estructuras (END IF, END WHILE, NEXT X) en comparación con el modelo de bracketing. Hace que el código sea un poco más legible y, a menudo, permite que el compilador sea más preciso en qué número de línea está causando errores de compilación. Si alguna vez se ha perdido una búsqueda de soporte / punto y coma debido a un error del compilador a 50 líneas del problema, ya sabe a qué me refiero.
Además, en la columna ganadora de VB.NET, en mi opinión, hay falta de == / = como operadores de comparación / asignación. Los beneficios poco comunes de tener un operador distinto para cada uno nunca compensarán todas las debilidades (a veces) difíciles de descubrir que ayuda a crear.
Finalmente, odio las mayúsculas y minúsculas en los lenguajes de programación. Una de las quejas sobre VB es que tiene mucho equipaje, pero C # llevó el albatros de la sensibilidad a mayúsculas y minúsculas de C. Nunca he estado en una situación en la que quisiera que dos identificadores en el mismo alcance difieran solo por caso. Simplemente hace un trabajo ocupado y me frena. VB.NET obtiene algunos puntos sobre C # en este sentido para mí.
Los programadores de C #
adoran ser concisos, por eso creo que generalmente favorecen esta sintaxis. Simplemente tiene un cierto atractivo estético. Sin embargo, desde una perspectiva completamente práctica, me gusta porque es muy similar a lenguajes como Java, JavaScript y C ++.
Dado que realizo mucho desarrollo web que requiere programación tanto del lado del servidor como del cliente, me resulta más fácil cambiar mentalmente entre C # y JavaScript, como a menudo se me exige.
También me gusta el hecho de que, en su mayor parte, que si alguna vez tuviera que hacer la transición para hacer programación Java o C ++, tendría un poco de ventaja si usara C # la mayor parte del tiempo.
fuente
namey una propiedad pública con el nombreNamey luego asignarlo a travésName = name;. Siempre que mantenga un estándar de codificación, de lo contrario, estoy de acuerdo, entonces puede causar confusión.Prefiero la sintaxis de soporte de los lenguajes de estilo C a la sintaxis más "detallada" de los lenguajes de estilo BASIC.
Mi introducción a la programación fue con Turbo Pascal. (La parte de programación BÁSICA que hice en el Commodore 64, cuando era niño, realmente no cuenta). Después de aprender Java, nunca miré hacia atrás y preferí la sintaxis de estilo C.
fuente
if something then code endifFuncionalmente son iguales, no hay nada que pueda hacer en uno que no pueda hacer en el otro, y para el futuro Microsoft ha prometido que los equipos de idiomas se desarrollarán de manera uniforme, por lo que es poco probable que esto cambie.
Las diferencias ahora son puramente culturales y personales. Este artículo es una lectura interesante sobre las diferencias entre las culturas de los programadores que usan C # y VB.net
[Nota: aunque soy un desarrollador de C #, la conclusión del artículo vinculado no refleja necesariamente mi opinión personal, es solo un enfoque alternativo interesante en el debate]
fuente
Llegué a .NET desde C y C ++ (con un poco de Java, Ada y Pascal), así que C # fue la progresión natural para mí.
Si apareciera un trabajo que requiriera VB.NET, ciertamente no lo rechazaría.
fuente
He trabajado mucho con VB.NET, pero entiendo suficiente C # para entender lo que está sucediendo en el código. Mi preferencia actual es VB.NET porque estoy más familiarizado con él (obviamente), pero realmente no tengo preferencia entre la sintaxis BASIC detallada y la sintaxis de estilo C, ambas son muy legibles y comprensibles para mí.
La mayor parte de la experiencia de programación de mi compañero de trabajo es COBOL y VB6, por lo que VB.NET fue la opción de lenguaje .NET más cómoda para nosotros como equipo. No había una razón sólida para nosotros que hiciera que aprender C # fuera un requisito ya que funcionalmente son lo mismo.
Dicho esto, aprender C # definitivamente está en mi lista de cosas que hacer.
fuente
Prefiero C #.
Comencé como programador de VB.NET, pero con el paso del tiempo se hizo evidente que muchas características nuevas están llegando primero a C # y luego a VB.NET (por ejemplo, propiedad automática). Y la comunidad que rodea a C # es mucho más animada que la de VB.NET.
Además, si tiene la intención de aprender Java o un lenguaje similar, C # es un mejor punto de partida: la sintaxis es casi la misma en todos los lenguajes derivados de C. Aunque esto no sería un punto de inflexión para mí, ya que la sintaxis es algo que puedes aprender rápidamente de todos modos.
fuente
Object.ReferenceEquals, un manejo de eventos que está casi bien hecho y una experiencia IDE más fluida. VB.net hace posible, aunque un poco incómodo, que los inicializadores de campo usen parámetros de constructor o creenIDisposableobjetos de forma segura sin tener que usarThreadStaticvariables; C # no lo hace.Además de las otras respuestas publicadas aquí, elegiría C # sobre VB porque a los programadores de C # se les paga más. Más experiencia con C # = más $$ :)
Sé que ambos idiomas son casi iguales y es muy fácil cambiar entre los dos, pero creo que cuando la gerencia mira un montón de llaves y punto y coma, aceptan el hecho de que estamos haciendo algo que no pueden hacer, donde con VB. Net podrían mirarlo y decir "oh, eso no debe ser tan difícil de hacer si puedo entenderlo".
fuente
C # porque puedo cambiar entre él y Java con un mínimo esfuerzo
VB.NET es una sintaxis completamente diferente. C #, ser similar a Java y otros lenguajes me da una mejor posición para adaptarme rápidamente a cosas nuevas. Dado que la salida de C # y VB.NET son prácticamente intercambiables, tiene sentido ir con C #. Además, si el código de su empresa está en C #, es más probable que pueda capacitar a un desarrollador de Java sobre cómo codificar C # que a un desarrollador de Java VB. Solo hay ventajas sutiles, pero sutiles sigue siendo una ventaja.
fuente
Dejando a un lado mis preferencias personales. Como alguien que ha estado reclutando (y tratando de ser reclutado) últimamente, cuando tuvimos este debate en la oficina, el consenso general fue que deberíamos buscar pasar a C # desde VB.
¿Por qué? Debido a que C # era más frecuente en el mercado (a nuestro alrededor de todos modos), lo que nos permite reclutar más fácilmente y ser reclutados más fácilmente.
Parece que se ha ido un círculo completo; la gente aprende C # porque los reclutadores lo quieren, porque hay más candidatos.
fuente
Siendo un desarrollador algo mayor (¿es 59 "algo" mayor?), Aprendí BASIC primero en un Commodore VIC-20, me enseñé Turbo Pascal (v1!), Aprendí COBOL en la universidad y pasé 14 años desarrollando en IBM mainframes, con breves diversiones escribiendo aplicaciones de tamaño mediano en Revelation BASIC (una variante de PICK BASIC) y algunas utilidades en Modula-2, antes de pasar a VB5 y VB6. Y luego vino .NET.
Debido a mi experiencia básica, pensé que debería comenzar con VB.NET, solo para descubrir que seguía tratando de hacer las cosas a la "antigua" y me estaba volviendo loco (está bien, más locos). Siendo que había hecho algo de trabajo en C, pensé en darle un giro a C # para ver cómo iba eso. ¡Y OMG, eso fue como salir de un túnel oscuro a la clara luz del día! Totalmente inesperado Y solía hacer ruidos despectivos acerca de que C era un lenguaje "de solo escritura", "tan difícil de entender que un programador de C no podía entender qué hacía su propio código 6 meses después de que lo escribió", una observación hecha por novelista semi-famoso que pensé que sonaba lindo en ese momento.
Entonces, en virtud de no estar familiarizado con C, C # fue paradójicamente más fácil para mí aprender programación .NET que el paradigma básico mucho más familiar. Todavía me gusta VB6, pero he llegado a amar C #. El mejor lenguaje de programación del planeta.
fuente
¡Me desarrollo en Visual Basic .Net desde 2001 y me encanta y lo odio!
El orden de presentación de estos puntos se basa solo en el orden en que vino a mi mente ...
En vb.net con Visual Studio, hay un salto de línea visual entre cada método, propiedad. Para muchas personas, no es una buena razón para preferir vb.net sobre c #, pero no entiendo por qué el equipo de c # en Microsoft no lo ha implementado. Hay un complemento que dibuja esta línea en c # pero agradece nuevamente a Microsoft que tenga un equipo ac # y un equipo visual básico que no se comuniquen entre sí.
En vb.net, cuando crea una forma de triunfo, tiene dos cuadros combinados en Visual Studio en la parte superior del editor y puede generar eventos automáticamente al seleccionar un evento en el cuadro combinado correcto. Cuando adjuntas docenas de eventos cada día, puede ser muy engorroso no tener esta función. Con c #, tiene un pequeño botón en la parte superior de la cuadrícula de propiedades que puede generar eventos, pero no es tan rápido como en vb.net. Además, si adjunta un evento de control en c # y elimina el control en el formulario, el delegado creado en el código generado automáticamente para manejar el evento debe eliminarse manualmente. Gracias de nuevo Microsoft.
En vb.net, cuando intenta modificar un método que contiene una consulta linq sin modificar la consulta en sí, no hay problema, pero en c #, todo el código del método está bloqueado. Si tiene muchas consultas linq o expresiones lambda, la función de edición y continuación será rápidamente algo bueno. Ok, un poco de exageración ... pero :)
En vb.net, cuando crea un nombre de método y toca enter, se creará automáticamente el 'fin de sub'. En c #, hágalo usted mismo. Ok, si tiene resharper o devexpress instalado, será mejor, pero ¿por qué todas estas pequeñas pero excelentes características no se implementaron en c #?
En vb.net, cuando tiene errores en su código, los errores se muestran automáticamente y cuando lo corrige, estos errores se eliminan de la pila en tiempo real. En c #, debe crear su proyecto para darse cuenta de que ha corregido correctamente o no los errores especificados. ¿Por qué el equipo de C # no ha puesto una opción para verificar el error en tiempo real como en vb.net? Con una gran solución, ninguna verificación de error en tiempo real puede ser una optimización muy agradable del rendimiento, pero me encanta ver desaparecer un montón de errores mientras lo corrijo.
Como otra persona ha mencionado, creo que es más fácil leer la condición vb.net si ... termine si, seleccione el caso ... finalice la selección pero con el soporte de pintura devexpress, olvide lo que dije.
Con vb.net, hay muchos errores en Visual Studio. Solo por mencionar uno en Visual Studio 2010, los intellisens no filtran correctamente la enumeración si tiene el modo "común" activado en lugar de "todos".
Con vb.net, eres percibido como un tipo ficticio porque estáticamente, más programadores malos usan vb.net en lugar de c # porque c # es más difícil de aprender y promover una mejor práctica de programación.
Como dijo otro, el programador de C # tiene más posibilidades de tener un buen trabajo con más dinero.
En la cabeza del cliente, vb.net = chico que programa en su sótano con un bol de espagueti de código. c # = wow, eres muy inteligente. El hecho es que no es porque programes en c #, que haces un buen programa, sino estáticamente, sí.
Con todos estos puntos, elegí convertir todo mi código vb en c #. Programo con todas las mejores prácticas de orientación a objetos, patrón de diseño, código limpio con estándares y sintaxis estricta y puedo programar así durante 50 años, pero desde la perspectiva de la comunidad, no soy un buen programador. Convertiré mi código en c # sin otras prácticas recomendadas y seré otra persona; un gran tipo al que debes respetar ..... :( ¡qué broma ... !!! pero es la realidad.
fuente
Aquí hay una forma de verlo: entre SO y CodePlex, ¿qué idioma es más popular? C # o VB.Net?
A veces, seguir al rebaño es algo bueno porque es el rebaño el que podrá ayudarlo cuando lo necesite. Por defecto, C # será más rápido que Vb.Net. Sin embargo, creo que usar Option Strict podría igualarlo. La última vez que comparé IL entre los dos, el tipo de seguridad de VB.Net terminó agregando aproximadamente un 15% más a la IL. Esto se traduce en gastos generales adicionales. Y ... dados los idiomas que hacen básicamente lo mismo, tomaré el más rápido. Mi conveniencia no debe anular la experiencia de mi usuario en general.
fuente
Me gusta decir que la única razón por la que BASIC sigue siendo popular es porque fue el primer producto de Microsoft, y lo han estado empujando en nuestras gargantas durante los últimos 35 años. Debería haber muerto hace mucho tiempo.
Dicho esto, trabajé en dos proyectos .NET considerables y ambos se realizaron con VB.Net, aunque había un poco de C # porque la traducción era una perra o la construcción no existía en VB.Net. La única ventaja que veo con VB.Net es que el editor de Visual Studio es mucho más amigable (en mi experiencia de todos modos) que con C # - Intellisense parece mejor, y también lo hace el autoformato (tenga en cuenta que, dado que no he usado C # tanto, es posible que me falte algo en la configuración del IDE ...)
Una desventaja importante en VB.Net es que trajeron una gran cantidad de basura de la era VB6 en .NET 1.x para facilitar la conversión del código VB6. Eso todavía está ahí, y los codificadores VB6 están codificando código nuevo usando esas ... "extensiones" en lugar de usar las clases / métodos .NET más neutrales. No sé cuántas veces le pregunté a mi jefe por qué todavía usaba esa basura. "Pero ... Funciona ..." Correcto. Oye, me gusta quejarme.
Mientras buscaba ayuda en la web, descubrí que la gran mayoría de las soluciones estaban en C #: consulte los foros de MSDN, varios blogs, etc. Los libros tienden a centrarse en C #, y si hay una versión VB, generalmente viene meses después (por ejemplo, Pro LINQ ... de Apress).
Muchos lenguajes comparten la ascendencia C, lo que facilita mucho el cambio entre C, C ++, C #, Java, PHP y algunos otros. PHP es un poco exagerado aquí, pero tiene muchas construcciones similares a C. VB? Bueno, es prácticamente su propia cosita y eso es todo.
Un líder de proyecto en mi organización me dijo recientemente que se están desarrollando más y más proyectos nuevos usando C # en lugar de VB - FINALMENTE. Cuando se introdujo .NET en nuestra organización, más o menos se unieron oficialmente a VB.Net debido a toda la codificación VB6 que ya estaba en curso. Los poderes que más tarde me admitieron que ese no era su mejor movimiento.
Como alguien más señaló anteriormente, no diría que no a un proyecto de VB.Net, pero todavía espero que sea erradicado lentamente del desarrollo más reciente en mi lugar de trabajo.
fuente
Bueno, hoy hay poca o ninguna razón real para usar VB.net. Al principio era solo una forma de dar a los programadores de VB una sintaxis familiar, pero era esencialmente una reasignación de C # similar a BASIC. Por lo tanto, su única ventaja real es una sintaxis más familiar, y su sintaxis BÁSICA también es su único límite real.
Con el tiempo, los dos idiomas evolucionaron junto, la única diferencia significativa es el
mypseudo espacio de nombres.Recomendaría a todos los programadores .net que no estén familiarizados con C # que lo aprendan, ya que la comunidad es bastante más grande y la sintaxis tipo C es común a la mayoría de los lenguajes más utilizados.
fuente
VB, el lenguaje es más fácil de leer para los novatos, tienden a escribir su primera, segunda y tercera aplicación en él y todos sabemos cómo se codifican nuestras primeras aplicaciones, terriblemente.
Los programadores de C ++, Java y etc. se han mudado a C #, mientras que los desarrolladores de VB.NET provienen de VBA, VB y BASIC, programadores esenciales no tradicionales.
fuente
Parece que hay más ejemplos de código C # en línea que ejemplos de VB.NET. No es que sea tan difícil convertir uno a otro, pero ¿por qué molestarse si no es necesario?
fuente
Prefiero VB .Net sobre C #,
fuente
C#. Es solo porque hice C y Java, así que siento que C # me es más legible. C # es para mí, como VB.NET es para los antiguos programadores de VB.
fuente