Por qué C#?

Ya puestos, si eres "todo un hombre" puedes probar el C++/CLI,

Estaba buscando informacion para aprender un poco del tema porque me
gusta c++ y encontre esto sacado de tu blog:

"...porque abandono el lenguaje y de momento siempre que pueda haré las cosas en C#"

No me das mucha confianza la verdad ;)

Salu2!

Hola,

Basicamente pq c# es mas estricto con tdo, y ya de entrada te evitas muchos
errores, ademas es el lenguaje clave de .net... vb.net tb esta bien pero no
es tan ordenado, metodico como c#...yo particularmente c# por ser un lenguaje
bien formado

Yo uso ambos, pero cuando es un proyecto grande y si el cliente le da igual
el lenguaje nos decantamos siempre por c# quieras o no vb.net va a quedar
nulo algun dia u otro y sera por excelencia c#...ademas si vas a los
webcast/conferencias de microsoft ADORAN a c#... ;)

Francesc Jaumot
-
Si te caes 7 veces levantante 8 - Viejo probervio chino


"Harvey Triana" wrote:

> Por que debería elegir C# por sobre VB.net?

C# es el lenguaje por excelencia de .NET. - VB.NET es un espeji$mo del
mismo. Cualquiera te sirve. Personalmente no usaria VB.NET para nada serio,
y eso que soy uno de aquellos gurus dinosaurios del VB -- Clásico.

<ht />
http://vexpert.mvps.org


"Guillermo Martin" escribió en el mensaje
news:
> Hola a todos,
> Estamos evaluando comenzar un desarrollo grande de base de datos (un
> sistema
> administrativo contable).
> Las bases estarían en SQL.
> Posiblemente se realizarán consultas desde dispositivos móviles y/o Linux,
> pero no en lo inmediato.
> Estamos en duda con respecto al lenguaje a utilizar, estamos entre VB y C#
> Sabemos las ventajas que tienen uno y el otro, y la verdad no sabemos con
> cual quedarnos.
> La pregunta es:
>
> Por que debería elegir C# por sobre VB.net?
>
> Desde ya les agradezco!
> Guille
>
>
>

En Sat, 24 Mar 2007 00:36:30 +0100, Diego Jancic
escribió:

Ya puestos, si eres "todo un hombre" puedes probar el C++/CLI,

Estaba buscando informacion para aprender un poco del tema porque me
gusta c++ y encontre esto sacado de tu blog:

"...porque abandono el lenguaje y de momento siempre que pueda haré
las cosas en C#"

No me das mucha confianza la verdad ;)

Salu2!

El .NET pese a lo complejo que es no es muy buggy, pero algunos claman al
cielo, como el tema de las excepciones en los constructores/métodos
estáticos o que en determinadas situaciones de estress (sobre todo si hay
mucha IO a dispositivos) se caiga la VM, una compilación de código
verificado funciona completamente diferente compilada en x86 que en
AnyCPU, en AnyCPU a veces las excepciones no se lanzan y la VM traga sin
problemas con variables sin inicializar...

El C++/CLI tiene aparte de eso una espuerta de bugs más, tanto en el
compilador como en el IDE, y como usa cosas del .NET que sólo se usan con
él, también en el .NET. El tema del C++/CLI está reconocido por los
propios mantenedores del compilador: este es muy viejo y está al límite (y
se extrañan de que funcione tan bien, e IMHO es cierto), tienen previsto
hacer uno nuevo después de Orcas... Pero hacer un compilador que trague
con C++ y C++/CLI etc no es moco de pavo...

Pero el C++/CLI tiene dos ventajas enormes sobre el C# y el VB.NET:

-Velocidad en el cambio de contexto entre nativo/manejado (de hecho son
dos hilos independientes que comparten memoria), junto al hecho de que
llamar a código nativo desde un programa C++/CLI es directo: incluye
windows.h y haz la llamada.

-La otra ventaja es el control total que tienes sobre el .NET, destrucción
determinista, variables en pila o en montículo manejado (aunque realmente
no estén en la pila a todos los efectos lo están, se pasan por valor, etc,
etc), mayor potencia a la hora de declarar clases y un largo etcétera. Y
posiblemente después de Orcas podamos tener punteros (no referencias, si
no punteros con la semántica de punteros del C++ nativo) a elementos
manejados y al revés mediante objetos proxi que sólo añadirán una
indirección más.

Inconvenientes tiene muchos: el IDE es lentísimo, al compilador hay que
entenderlo, a veces se le olvida compilar partes de ficheros (cosa que han
solucionado con el SP1 pero sólo parcialmente), es lentísimo compilando y
cargando, no soporta el Compact Framework, a veces hace cosas un poco
"raritas" por decirlo de alguna manera...

Y respecto a mi comentario que citas, es completamente cierto (pero no
deja de ser una falacia personal): lo que ocurre es que la mayoría de mis
proyectos usan código nativo y elementos nativos, aparte de que muchas
cosas sólo existen en Win32 y no en el .NET, etc, así que tener un
programa al 50% con interop estilo C# es, hablando claro, un jaleo
impresionante aparte de ineficaz, por lo tanto ese "siempre que pueda" se
refiere al 10% de mi trabajo diario, es decir, aquellas aplicaciones que
es indiferente si se realizan en C++/CLI o C#, se realizarán en C#... Ten
en cuenta que yo hago lo que se puede llamar "aplicaciones de sistemas", y
lo más cerca que estoy de una aplicación de bases de datos es cuando me
paso por administración a darle una patada a la impresora porque no
funciona... Pero aun así, y pese a todas las pegas, el .NET me acelera
mucho, pero mucho, el desarrollo (teniendo en cuenta esa semana extra para
lidiar con los bugs del IDE/compilador/net).
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
Un alma grande está por encima de la injuria, de la injusticia y del dolor.

Hay alguna traduccion para este mensaje?

"RFOG" escribió en el mensaje
news:

En Sat, 24 Mar 2007 00:36:30 +0100, Diego Jancic
escribió:

Ya puestos, si eres "todo un hombre" puedes probar el C++/CLI,

Estaba buscando informacion para aprender un poco del tema porque me
gusta c++ y encontre esto sacado de tu blog:

"...porque abandono el lenguaje y de momento siempre que pueda haré
las cosas en C#"

No me das mucha confianza la verdad ;)

Salu2!

El .NET pese a lo complejo que es no es muy buggy, pero algunos claman al
cielo, como el tema de las excepciones en los constructores/métodos
estáticos o que en determinadas situaciones de estress (sobre todo si hay
mucha IO a dispositivos) se caiga la VM, una compilación de código
verificado funciona completamente diferente compilada en x86 que en
AnyCPU, en AnyCPU a veces las excepciones no se lanzan y la VM traga sin
problemas con variables sin inicializar...

El C++/CLI tiene aparte de eso una espuerta de bugs más, tanto en el
compilador como en el IDE, y como usa cosas del .NET que sólo se usan con
él, también en el .NET. El tema del C++/CLI está reconocido por los
propios mantenedores del compilador: este es muy viejo y está al límite (y
se extrañan de que funcione tan bien, e IMHO es cierto), tienen previsto
hacer uno nuevo después de Orcas... Pero hacer un compilador que trague
con C++ y C++/CLI etc no es moco de pavo...

Pero el C++/CLI tiene dos ventajas enormes sobre el C# y el VB.NET:

-Velocidad en el cambio de contexto entre nativo/manejado (de hecho son
dos hilos independientes que comparten memoria), junto al hecho de que
llamar a código nativo desde un programa C++/CLI es directo: incluye
windows.h y haz la llamada.

-La otra ventaja es el control total que tienes sobre el .NET, destrucción
determinista, variables en pila o en montículo manejado (aunque realmente
no estén en la pila a todos los efectos lo están, se pasan por valor, etc,
etc), mayor potencia a la hora de declarar clases y un largo etcétera. Y
posiblemente después de Orcas podamos tener punteros (no referencias, si
no punteros con la semántica de punteros del C++ nativo) a elementos
manejados y al revés mediante objetos proxi que sólo añadirán una
indirección más.

Inconvenientes tiene muchos: el IDE es lentísimo, al compilador hay que
entenderlo, a veces se le olvida compilar partes de ficheros (cosa que han
solucionado con el SP1 pero sólo parcialmente), es lentísimo compilando y
cargando, no soporta el Compact Framework, a veces hace cosas un poco
"raritas" por decirlo de alguna manera...

Y respecto a mi comentario que citas, es completamente cierto (pero no
deja de ser una falacia personal): lo que ocurre es que la mayoría de mis
proyectos usan código nativo y elementos nativos, aparte de que muchas
cosas sólo existen en Win32 y no en el .NET, etc, así que tener un
programa al 50% con interop estilo C# es, hablando claro, un jaleo
impresionante aparte de ineficaz, por lo tanto ese "siempre que pueda" se
refiere al 10% de mi trabajo diario, es decir, aquellas aplicaciones que
es indiferente si se realizan en C++/CLI o C#, se realizarán en C#... Ten
en cuenta que yo hago lo que se puede llamar "aplicaciones de sistemas", y
lo más cerca que estoy de una aplicación de bases de datos es cuando me
paso por administración a darle una patada a la impresora porque no
funciona... Pero aun así, y pese a todas las pegas, el .NET me acelera
mucho, pero mucho, el desarrollo (teniendo en cuenta esa semana extra para
lidiar con los bugs del IDE/compilador/net).
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
> Un alma grande está por encima de la injuria, de la injusticia y del
dolor.

Pues ve anotando en una libretita lo que no entiendas y ya sabes: estudia.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
La literatura no puede reflejar todo lo negro de la vida. La razón principal
es que la literatura escoge y la vida no.

"Juan Carlos Biancotti" escribió en el
mensaje de noticias news:

Hay alguna traduccion para este mensaje?

"RFOG" escribió en el mensaje
news:

En Sat, 24 Mar 2007 00:36:30 +0100, Diego Jancic
escribió:

Ya puestos, si eres "todo un hombre" puedes probar el C++/CLI,

Estaba buscando informacion para aprender un poco del tema porque me
gusta c++ y encontre esto sacado de tu blog:

"...porque abandono el lenguaje y de momento siempre que pueda haré
las cosas en C#"

No me das mucha confianza la verdad ;)

Salu2!

El .NET pese a lo complejo que es no es muy buggy, pero algunos claman al
cielo, como el tema de las excepciones en los constructores/métodos
estáticos o que en determinadas situaciones de estress (sobre todo si hay
mucha IO a dispositivos) se caiga la VM, una compilación de código
verificado funciona completamente diferente compilada en x86 que en
AnyCPU, en AnyCPU a veces las excepciones no se lanzan y la VM traga sin
problemas con variables sin inicializar...

El C++/CLI tiene aparte de eso una espuerta de bugs más, tanto en el
compilador como en el IDE, y como usa cosas del .NET que sólo se usan con
él, también en el .NET. El tema del C++/CLI está reconocido por los
propios mantenedores del compilador: este es muy viejo y está al límite
(y se extrañan de que funcione tan bien, e IMHO es cierto), tienen
previsto hacer uno nuevo después de Orcas... Pero hacer un compilador que
trague con C++ y C++/CLI etc no es moco de pavo...

Pero el C++/CLI tiene dos ventajas enormes sobre el C# y el VB.NET:

-Velocidad en el cambio de contexto entre nativo/manejado (de hecho son
dos hilos independientes que comparten memoria), junto al hecho de que
llamar a código nativo desde un programa C++/CLI es directo: incluye
windows.h y haz la llamada.

-La otra ventaja es el control total que tienes sobre el .NET,
destrucción determinista, variables en pila o en montículo manejado
(aunque realmente no estén en la pila a todos los efectos lo están, se
pasan por valor, etc, etc), mayor potencia a la hora de declarar clases y
un largo etcétera. Y posiblemente después de Orcas podamos tener punteros
(no referencias, si no punteros con la semántica de punteros del C++
nativo) a elementos manejados y al revés mediante objetos proxi que sólo
añadirán una indirección más.

Inconvenientes tiene muchos: el IDE es lentísimo, al compilador hay que
entenderlo, a veces se le olvida compilar partes de ficheros (cosa que
han solucionado con el SP1 pero sólo parcialmente), es lentísimo
compilando y cargando, no soporta el Compact Framework, a veces hace
cosas un poco "raritas" por decirlo de alguna manera...

Y respecto a mi comentario que citas, es completamente cierto (pero no
deja de ser una falacia personal): lo que ocurre es que la mayoría de mis
proyectos usan código nativo y elementos nativos, aparte de que muchas
cosas sólo existen en Win32 y no en el .NET, etc, así que tener un
programa al 50% con interop estilo C# es, hablando claro, un jaleo
impresionante aparte de ineficaz, por lo tanto ese "siempre que pueda" se
refiere al 10% de mi trabajo diario, es decir, aquellas aplicaciones que
es indiferente si se realizan en C++/CLI o C#, se realizarán en C#... Ten
en cuenta que yo hago lo que se puede llamar "aplicaciones de sistemas",
y lo más cerca que estoy de una aplicación de bases de datos es cuando me
paso por administración a darle una patada a la impresora porque no
funciona... Pero aun así, y pese a todas las pegas, el .NET me acelera
mucho, pero mucho, el desarrollo (teniendo en cuenta esa semana extra
para lidiar con los bugs del IDE/compilador/net).
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
>> Un alma grande está por encima de la injuria, de la injusticia y del
dolor.