Cambio de lenguaje

C# es bastante más ortogonal que vb.net, su gramática es más
sencilla, todas las sentencias de control se describen de forma muy
regular y simple: sentencia-de-control bloque-de-sentencias. La forma
de describir las sentencias de control en vb.net es menos regular,
menos simple. Algo así como sentencia-de-control grupo-de-sentencias
End-tipo-correspondiente. Además, For, se termina con Next en lugar
de con End For, tal y como debería ser. Sé que es por razones
históricas, pero...

Bueno, esto creo que es una cuestion muy personal. Es comun perderse en C
con tanta llave y por eso es muy comun encontrar cosas como "} // xx" donde
xx es una referencia a la sentencia que "abrio" la llave. Encontrar el final
de los bloques suele ser mas simple en VB ya que (casi) todas las sentencias
terminan de forma diferente.

Además, en vb.net en ocasiones hay varias sintaxis para una misma
sentencia de control.

Bueno, algo similar tienes en C# ya que si el bloque de codigo es de una
sola linea puedes omitir la llaves.

Hay otros detalle de vb.net que no me gustan, por ejemplo que permita
invocar miembros de clase desde una instancia. Me produce bastante
confusión. Algo que parece hacer una cosa, hace otra completamente
distinta.

Si, eso es horrible (y para peor a veces lo uso!). Por suerte esta algo
cambiado en 2005 ya que hacer eso genera una advertencia.

Por supuesto, la sobrecarga de operadores. No hablo tanto de poder
definirla, como de poder utilizarla.

Si, eso es algo que les falto, aunque mas no sea se deberia poder usar.

Otra carencia que he advertido, es que en vb.net no se puede
reintroducir una interface. Por ejemplo, en vb.net solo se podrá
modificar la serialización en una clase heredera, si en la clase base
se definió GetObjectData como virtual. No hay forma de reintroducir
ISerializable en una clase heredera de otra que ya la implemente,
utilizando vb.net.

Esto creo que esta bien. El hecho de reimplementar la interface te puede
confundir que implementacion se esta llamando realmente. Como estamos
hablando de una misma clase lo logico es que la interface se implemente una
sola vez y el asunto depende mas del diseño de las clases que del lenguaje.

Este punto no lo veo nada claro. ¿Qué se puede hacer en vb.net que no
se pueda hacer en c#?

Hay algunas cosillas como por ejemplo el poder implementar metodos de
interfaces con nombres diferentes a los definidos en la interface.

Es mayormente cuestion de gustos y/o costumbre la eleccion del lenguaje que
mas usamos, pero de todas formas mientras estemos dentro de la plataforma
.net puedes usar ambos en una misma aplicacion sacando el mayor provecho de
ambos.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

opino lo mismo eso de que uno se pierde por las llaves es igual a tener
varios IF anidados en VB.

A mi no me gusta la sintaxis de VB porque hace que tengamos que escribir
mucho más codigo y recordar más intrucciones innecesariamente.

WHILE
WEND

IF
ENDIF (ni si quiera puedo recordar si es ENDIF o END IF)

y asi sigue...
pero en fin... como siempre es cuestión de gustos.
"Tristan" wrote in message
news:
Uyyyy, esto tiene pinta de ser una de esas conversaciones interminables
sobre cual es el mejor lenguaje. Y lo peor es que en realidad creo que más o
menos pensamos lo mismo :-)

Bueno, esto creo que es una cuestion muy personal. Es comun perderse en C
con tanta llave y por eso es muy comun encontrar cosas como "} // xx"
donde xx es una referencia a la sentencia que "abrio" la llave. Encontrar
el final de los bloques suele ser mas simple en VB ya que (casi) todas las
sentencias terminan de forma diferente.

Desde luego estoy de acuerdo en que es una cuestión personal.

Respecto a las llaves, lo mismo se podría decir de los paréntesis ¿no?
¿Crees que sería una buena idea utilizar distintos tipos de paréntesis para
distinguir el nivel? No parecería de gran ayuda. Pienso que con un adecuado
sangrado, el código queda muy claro entre llaves, y más con la ayuda que
ofrece intellisense. Pero sobre todo, nunca escribo métodos lo bastante
largos como para que sea difícil seguir las llaves. Por otro lado,
diferenciar el tipo de End, en vb, no ayuda si la sentencia de control es la
misma, por ejemplo con una serie de if anidados. A mi sinceramente no parece
de ninguna ayuda, y si en ciertos momentos dificultad, cuando quiero cambiar
una sentencia de control por otra.

Bueno, algo similar tienes en C# ya que si el bloque de codigo es de una
sola linea puedes omitir la llaves.

Bueno, en realidad yo no lo considero así. De hecho no está descrito así en
la gramática de C#:

Por ejemplo esta es la definición gramatical de while:

while-statement:
while ( boolean-expression ) embedded-statement

Y en todas las sentencias de control se utiliza de la misma forma. Es
embedded-statement el que incluye las dos opciones. Quiero decir que en
realidad es un esquema sistemático, común a todas las sentencias de control.

.

Juan Carlos Badiola
MVP - C#

opino lo mismo eso de que uno se pierde por las llaves es igual a tener
varios IF anidados en VB.

Es cierto, si son las mismas instrucciones anidadas es un problema en
cualquier lenguaje. Pero si son diferentes es mas complicado saber donde
esta faltando una llave en C que saber que bloque me quedo sin cerrar en
VB.NET. Por ejemplo si tenemos (donde falta cerrar el while):

If x Then
' ...
While y
' ...
'...
End If

if (x) {
// ...
while(y) {
// ...
// ...
}

En VB tendria este error "'While' must end with a matching 'End While'" (y
me marca el while al que le falta el end while) mientras que en C seria "Se
esperaba }" (y me marca la ultima llave que encuentra) sin saber exactamente
que bloque es el que falto cerrar. Aqui esta claro porque el codigo es muy
simple pero en algo mas complejo hay que analizar mas (o quizas el problema
soy yo?).

(Que cosa extraña, recien me doy cuenta que los error de VB me lo da en
ingles y los de c# en español!)

A mi no me gusta la sintaxis de VB porque hace que tengamos que escribir
mucho más codigo y recordar más intrucciones innecesariamente.

En otras epocas puede ser, pero cuando el IDE automaticamente completa la
instruccion ya no es mucho mas codigo que escribir. Y ni tanto que recordar
si es que todo finaliza con End mas la instruccion que abrio el bloque (La
unica instruccion que no sigue esta regla es Do que finaliza con Loop).
Aunque es cierto que otras cosas requieren mas escritura (como me cansa
escribir DirectCast!).

WHILE
WEND

Aqui una de las tonterias de VB.NET. Wend fue cambiado a End While (supongo
que para estandarizar todo a End xxxx). Sin embargo el compilador reconoce
Wend y genera el error "'Wend' statements are no longer supported; use 'End
While' statements instead." en lugar de un esperado y mas logico "Name
'Wend' is not declared".

IF
ENDIF (ni si quiera puedo recordar si es ENDIF o END IF)

Es End If. Siempre hay un espacio entre el End y lo que sigue.

y asi sigue...
pero en fin... como siempre es cuestión de gustos.

No solo gustos, costumbre tambien!

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo