El porqué C# siempre tendrá novedades aunque Visual Basic ya no

Pues eso… el otro día estaba leyendo un artículo de Anthony D. Green (miembro del team de Visual Basic de Microsoft del 2010 al 2018) sobre todo lo relacionado con la que se lio por el tema de que a Visual Basic no se le añadirán nuevas características, (
Future features of .NET Core that require language changes may not be supported in Visual Basic.), pero no es de eso de lo que te quiero hablar aquí. Es de lo que dice Anthony en su artículo.

Concretamente esta parte es la que me ha hecho reflexionar un poco sobre C#:

C# advances the .NET platform.
I’m not begrudging or envying them that role but recognizing that that’s what the language has always done where VB is traditionally focused on innovation in experience.
It’s not that you can’t write a library or a framework in VB (and people have) but the .NET platform is not and will never be dependent on the VB language (or F#) to make leaps.
But if C# is late developing generics, .NET 2.0 doesn’t ship.
If C# hasn’t figured out the shape and behavior of nullable value types those types can’t appear in any new APIs.
If it’s late on LINQ, .NET 3.5 doesn’t ship.
If async isn’t complete, .NET 4.5 can’t ship with new asynchronous APIs.
If C# language design can’t converge on ref returns or nullable annotations the platform teams (like mscorlib) that depend on those features literally cannot ship their platforms for anyone.
And for what it’s worth, C# is ALWAYS late on those things (a fact I learned too late) because getting it right takes all the time in the world.
Which is why it’s insane (in hindsight) to envision an “ideal” world where you couple or serialize a language which does not fulfill that mission critical role with so many downstream dependencies and its customers’ productivity with one that does and expect good things for both of them.

Extracto de: Un manual sobre por qué el sufrimiento crónico de la comunidad de VB.NET no es necesario ni una cuestión de gastos o practicidad

Es decir, C# tiene que estar siempre actualizado ya que la plataforma .NET depende de C# (o casi). El casi es porque es el lenguaje de .NET que Microsoft tiene para poder usar las novedades que se agreguen a .NET.

Y como ahora .NET ya no será una continua actualización de .NET Framework, si no de .NET Core (multiplataforma), es lógico que también deba incorporar las novedades enfocadas a ser utilizado tanto en Windows como en MacOS, Linux, iOS, Android, etcétera.

¿Debo olvidarme de Visual Basic y pasarme a C#?

Esto no significa que a Visual Basic no se le deba seguir añadiendo nuevas características en el lenguaje, que según dice Anthony en su artículo es posible hacerlo si Microsoft dedica un par de profesionales a seguir manteniendo el lenguaje, que de otra parte puede recibir ayuda de la comunidad, como ya lo ha hecho con la última incorporación al lenguaje: Comentarios permitidos en más lugares dentro de las instrucciones que precisamente la ha agregado un participante de la comunidad: Paul1956 (Paul M Cohen).

Lo que sí tendrá Visual Basic son nuevas funcionalidades en el editor de Visual Studio (ver figura 1), pero no tendrá, por ejemplo el equivalente a record (registro) o init (establecedor de solo inicialización) en las propiedades.

Figura 1. Mostrar Inline parameters (parámetros en línea)

Así que… si quieres tener un lenguaje de programación para .NET que esté siempre actualizado a las novedades de la plataforma .NET, debes decantarte por C#.

Si no te gusta programar en C# pero sí en Visual Basic, recuerda que este último se quedará estancado en la versión 16.0, mientras que C# seguirá avanzando.
Eso no significa que no puedas seguir usando Visual Basic.

Pero si eres de los que quiere usar .NET 5.0 o las versiones que sigan apareciendo (cada año habrá una nueva y por tanto tendrá cosas nuevas), recuerda que podrás hacerlo, pero con las cosas que actualmente tiene Visual Basic.

Y si eres de los que no quieren usar nada relacionado con .NET / .NET Core / .NET Standard, podrás seguir usando Visual Basic en .NET Framework 4.8 (o anteriores), aunque este último seguirá estando disponible mientras Windows exista.

Resumiendo:
No te quedarás obsoleto si sigues usando Visual Basic. Pero si quieres poder usar en tu código las novedades agregadas a .NET tendrás que plantearte el cambio a C#, aunque sea para poder crear alguna biblioteca de clases que utilice esas novedades de .NET y las pongas a disposición de tu código de Visual Basic (la cuestión es querer arreglar las cosas 😉 ).

Aprender C#

Y si quieres pasarte a C#, ya sabes que en elGuille.info (y en este blog) tienes un montón de código en C# con su equivalente en Visual Basic (o viceversa), ya que desde enero de 2001 (sí, hace ya 19 añitos de nada) todo (o prácticamente todo) lo que he ido publicando para Visual Basic (trucos, API, utilidades, WPF/XAML, etc.) está con el código para los dos lenguajes. Y, lo más importante: ¡TODO GRATIS! (aunque también puedes hacer una donación con PayPal 😉 ).

Por supuesto también puedes apuntarte a algunos de los muchos cursos que hay en las plataformas de enseñanza online y aprender (pagando) el lenguaje C#.

Cómo lo hagas, si decides hacerlo, es cuestión tuya.

Por mi parte, seguiré usando Visual Basic como lenguaje de programación principal, sin olvidarme de C# e ir aprendiendo las cosas nuevas que vayan apareciendo.
Tanto de uno como de otro lenguaje, iré publicando artículos para que te sirva de aprendizaje o para que te aclares un poco más

En un próximo artículo te explicaré algunas de las novedades de C# 9.0 como son los tipos de registro (record), inicializadores en las propiedades (init) o instrucciones de nivel superior (Top-level statements).

Nos vemos.
Guillermo

P.S.
Traducción (automatizada del párrafo en inglés):

C# avanza la plataforma .NET.
No les estoy regateando ni envidiándoles ese papel, pero reconozco que eso es lo que siempre ha hecho el lenguaje, donde VB se centra tradicionalmente en la innovación en la experiencia.
No es que no pueda escribir una biblioteca o un marco de trabajo en VB (y la gente lo ha hecho), pero la plataforma .NET no depende y nunca dependerá del lenguaje VB (o F #) para avanzar.
Pero si C# desarrolla genéricos tarde, .NET 2.0 no sale.
Si C# no ha descubierto la forma y el comportamiento de los tipos de valores que aceptan valores NULL, esos tipos no pueden aparecer en ninguna API nueva.
Si llega tarde en LINQ, .NET 3.5 no se distribuye.
Si async no está completo, .NET 4.5 no se puede enviar con nuevas API asincrónicas.
Si el diseño del lenguaje C# no puede converger en devoluciones de referencia o anotaciones que aceptan valores NULL, los equipos de la plataforma (como mscorlib) que dependen de esas características, literalmente, no pueden enviar sus plataformas a nadie.
Y por si sirve de algo, C# SIEMPRE llega tarde en esas cosas (un hecho que aprendí demasiado tarde) porque hacerlo bien lleva todo el tiempo del mundo.
Es por eso que es una locura (en retrospectiva) imaginar un mundo «ideal» en el que se acopla o serializa un lenguaje que no cumple esa función crítica con tantas dependencias posteriores y la productividad de sus clientes con uno que sí y espera cosas buenas para ambos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *