none
Opinión del V C++ RRS feed

Respuestas

  • Es una simple cuestión de productividad. VC++ es imprescindible en escenarios de programación de periféricos o en los que necesitamos obtener el rendimiento más alto posible. Para aplicaciones más "cotidianas" otros lenguajes nos permiten olvidarnos de ciertas preocupaciones (gestión de memoria, punteros, etc.) que simplifican el desarrollo, con ciertas penalizaciones que para la mayoría nos resultan asumibles.

     

    Lo mismo pasa si le preguntas a un programador de VC++ porque no programa en Assembler. Se trata de buscar el punto adecueado a las necesidadse de cada uno.

     

    Salud y suerte!

    lunes, 21 de enero de 2008 7:53
  •  

    VC++ es una herramienta muy  buena, la mejor del mercado para C++ y C++ es uno de los mejores lenguajes de programación jamas creado...

     

    Sin embargo C++ ya es obsoleto para la inmensa mayoria de desarrollos que se requieren hacer hoy en día, y aunque aún es muy vigente para cosas como:

     

    Videojuegos

    Antivirus

    Sistemas Operativos

    Controladores de dispositivos

    Proyectos cientificos

     

    Y por otro lado C++ es comparativamente muy dificil si se compara por ejemplo con C#, que si bien no es que sea muy facil para un novato , realmente si es mucho mas facil que otros lenguajes.

    lunes, 21 de enero de 2008 13:18
    Moderador
  • claro, por ejemplo antes de vb.net 2.0 no se podia hacer sobrecarga de operadores ... desde luego ahora si se puede...

    pero si se fijan no hablo puntualmente del lenguaje sino de las tendencias de los desarrolladores que utilizan cada herramienta, yo no dudo que en vb.net se pueda hacer otra libreria como Math.Net desde luego que se puede hacer pero habran limitantes unas muy tontas y otras no tanto...

    ejemplo de cosas que estan en C# y no en vb.net

    *el operador ++ y el operador --
    *La opcion de generart codigo con apuntadores (unsafe)
    *Los dos anteriores unidos= navegacion en punteros...

    el solo hecho de poder musar codigo inseguro en C# lo vuelve increiblemente mas rapido. Pero no ves la diferencia en consultas a bd ni nada por el estilo... lo vez trabajando con imagenes (millones de pixeles) y en calculos matematicos ciclicos por ejemplo en las simulaciones.

    Imageinemos programando videojuegos o una api de matematicas o fisica o una aplicacion cientifica utilizando type narrowing conversion... con vb seria un desastre... pero una pagina web con visual basic usando eso... es una bendicion... o no?

    Declaracion opcional de variables... para sistemas de infromacion o paginas web o otros ejemplos es muy bueno pues va en pro de la productividad en la crecion de codigo...
    ahora imaginemos utilizar ese tipo de cosas en proyectos como seti o rosseta... seguramente llevaria a un exceso en el consumo de memoria y procesamiento del gc.., la opcion de decidir acerca de strong tiping o weak typing solo este disponible en C#.


    Respecto a la generacion de IL y al performance del CLR solo digo dos cosas:

    el CLR es el mismo.. asi que no afecta...

    el código generado si bien en ambos casos es IL si es dieferente ed acuerdo a como funciona  los compiladores...
    usualmente entre mas cosas automatice el compilador (y aplica para cualquier lenguaje) es mas factible que hayan problemas de performance ya que que la generalizacion(contrario a especializacion) de funcionalidad  va en detrimento del tiempo de ejecución... en este punto vb puede tener ciera debilidad si bien podria considerarce despreciable y fuera de lugar porque el código generado no depende del lenguaje sino del compilador...

    sin embargo allí hay diferencias tangibles y criticas a la hora de decidir que lenguaje utilizar segun el tipo de proyecto en que estés... es decir misma funcionalidad en vb.net y en C# produce (debido a los compiladores y a algunas característcias de cada lenguaje) codigo IL mucho mas eficiente en uno que en otro... antes tenia un ejemplo que siempre mostraba pero como no lo tengo a la mano les dejo este link:


    http://microsoft.apress.com/asptodayarchive/73656/microsoft-intermediate-language-comparison-between-c-and-vbnet


    Y para finalizar anoto nuevamente que no estoy diciendo que vb sea malo, lo que quiero mostrar es que si hay diferencias que han surgido debido al uso especifico que la tendencia de mercado le ha dado a cada lenguaje. Cada cual es muy bueno en lo suyo, aunque si me ponen a elegir nunca dejaria C#... ahora pongan a elegir a alguien que venga de  vb6.0 o similar... a ver que dice... lo mismo nunca dejaraia su vb...

    Pero a todos nos gusta matar las pulgas de una manera diferente.... Wink


    saludos
    lunes, 21 de enero de 2008 21:42
    Moderador
  •  Juan Carlos Ruiz Pacheco Escribió:
    claro, por ejemplo antes de vb.net 2.0 no se podia hacer sobrecarga de operadores ... desde luego ahora si se puede...

    La sobrecarga de operadores es una vía para mejorar la productividad a la hora de codificar, pero no veo que afecte a la hora de poder realizar un proyecto u otro.

     Juan Carlos Ruiz Pacheco Escribió:

    pero si se fijan no hablo puntualmente del lenguaje sino de las tendencias de los desarrolladores que utilizan cada herramienta, yo no dudo que en vb.net se pueda hacer otra libreria como Math.Net desde luego que se puede hacer pero habran limitantes unas muy tontas y otras no tanto...

    En las "otras no tanto" me gustaría incidir. No veo que limitaciones tendré a la hora de programar una Math.Net con VB.

     Juan Carlos Ruiz Pacheco Escribió:

    ejemplo de cosas que estan en C# y no en vb.net

    *el operador ++ y el operador --
    *La opcion de generart codigo con apuntadores (unsafe)
    *Los dos anteriores unidos= navegacion en punteros...

    Lo de los operadores ++ o -- no deja de ser anecdótico, y volvemos a estar en una simple cuestión de sintaxis.
    El tema del Unsafe es más complejo, pero tal y como lo veo es sacar a C# del CLR. Es un giño a C++, pero en realidad convierte el código en no administrado, y en mi modesta opinión... para eso ya está C++.


     Juan Carlos Ruiz Pacheco Escribió:

    el solo hecho de poder musar codigo inseguro en C# lo vuelve increiblemente mas rapido. Pero no ves la diferencia en consultas a bd ni nada por el estilo... lo vez trabajando con imagenes (millones de pixeles) y en calculos matematicos ciclicos por ejemplo en las simulaciones.

    Aquí vuelvo un poco a lo mismo. Cödigo no administrado = Mayor rendimiento, peor productividad. Y si buscamos rendimiento, pq no usar directamente C++?


     Juan Carlos Ruiz Pacheco Escribió:

    Imageinemos programando videojuegos o una api de matematicas o fisica o una aplicacion cientifica utilizando type narrowing conversion... con vb seria un desastre... pero una pagina web con visual basic usando eso... es una bendicion... o no?

    Podemos deshabilitar este tipo de conversiones, no?

     Juan Carlos Ruiz Pacheco Escribió:

    Declaracion opcional de variables... para sistemas de infromacion o paginas web o otros ejemplos es muy bueno pues va en pro de la productividad en la crecion de codigo...
    ahora imaginemos utilizar ese tipo de cosas en proyectos como seti o rosseta... seguramente llevaria a un exceso en el consumo de memoria y procesamiento del gc.., la opcion de decidir acerca de strong tiping o weak typing solo este disponible en C#.

    De nuevo podemos deshabilitar estas características.

     Juan Carlos Ruiz Pacheco Escribió:

    Respecto a la generacion de IL y al performance del CLR solo digo dos cosas:

    el CLR es el mismo.. asi que no afecta...

    Totalmente de acuerdo.

     Juan Carlos Ruiz Pacheco Escribió:

    el código generado si bien en ambos casos es IL si es dieferente ed acuerdo a como funciona  los compiladores...
    usualmente entre mas cosas automatice el compilador (y aplica para cualquier lenguaje) es mas factible que hayan problemas de performance ya que que la generalizacion(contrario a especializacion) de funcionalidad  va en detrimento del tiempo de ejecución... en este punto vb puede tener ciera debilidad si bien podria considerarce despreciable y fuera de lugar porque el código generado no depende del lenguaje sino del compilador...

    Como bien dices es algo muy genérico, y en algunos casos puede ganar esa despreciable ventaja un lenguaje u otro.


     Juan Carlos Ruiz Pacheco Escribió:

    sin embargo allí hay diferencias tangibles y criticas a la hora de decidir que lenguaje utilizar segun el tipo de proyecto en que estés... es decir misma funcionalidad en vb.net y en C# produce (debido a los compiladores y a algunas característcias de cada lenguaje) codigo IL mucho mas eficiente en uno que en otro... antes tenia un ejemplo que siempre mostraba pero como no lo tengo a la mano les dejo este link:


    http://microsoft.apress.com/asptodayarchive/73656/microsoft-intermediate-language-comparison-between-c-and-vbnet

    Yo aquí no ando muy convencido la verdad. No creo que las diferencias sean tantas, ni que casos son más propicios para un lenguaje u otro.

     Juan Carlos Ruiz Pacheco Escribió:

    Y para finalizar anoto nuevamente que no estoy diciendo que vb sea malo, lo que quiero mostrar es que si hay diferencias que han surgido debido al uso especifico que la tendencia de mercado le ha dado a cada lenguaje. Cada cual es muy bueno en lo suyo, aunque si me ponen a elegir nunca dejaria C#... ahora pongan a elegir a alguien que venga de  vb6.0 o similar... a ver que dice... lo mismo nunca dejaraia su vb...

    Pero a todos nos gusta matar las pulgas de una manera diferente....

     

    Amén con lo de las pulgas... Stick out tongue

    Felicidades JC, te lo has currado! Wink

    lunes, 21 de enero de 2008 22:19
  • La sobrecarga de operadores es una vía para mejorar la productividad a la hora de codificar, pero no veo que afecte a la hora de poder realizar un proyecto u otro.

     

    Asi es, eso es lo que yo llamaria una caracteristica que no va de fondo... una tonta.

     

    En las "otras no tanto" me gustaría incidir. No veo que limitaciones tendré a la hora de programar una Math.Net con VB.

    Performance.

     

    El tema del Unsafe es más complejo, pero tal y como lo veo es sacar a C# del CLR. Es un giño a C++, pero en realidad convierte el código en no administrado, y en mi modesta opinión... para eso ya está C++.

     

    Nop, porque la gracia es poder utilizar fragmetos de codigo unsafe en entornos plenamente administrados.. y ahihay una gran diferencia, pues no necesitohacer que mi GUI o mis procesos basicos sean unsafe eso le agregaria demasiada complejidad innecesaria... pero puedo tener todo en un am,biente administrado y unicamente el modulo o funcion critica para mi trabajo de manera unsafe.

     

    Aquí vuelvo un poco a lo mismo. Cödigo no administrado = Mayor rendimiento, peor productividad. Y si buscamos rendimiento, pq no usar directamente C++?

     

    Por lo mismo de antes... te volveras muy improductivo utilizando caracteristicas que solo te dan valor agregado en algunas porciones del codigo.

     

    Podemos deshabilitar este tipo de conversiones, no?

    claro, pero lo usual sera no darse cuenta de eso sino hasta que tu aplicacion ya esta hecha un desastre... y en ese punto lo usual es gastar horas de depuracion hasta decir : 'oh se m e ha olvidado desactivarlas en esta dll'... eso no deberia pasar pero siempre pasa...

    Yo aquí no ando muy convencido la verdad. No creo que las diferencias sean tantas, ni que casos son más propicios para un lenguaje u otro.

     

    realmente depdende de lo que estes haciendo... y estoy muy seguro que en algunos casos no importara... y vuelvo a mi ejemplo de las paginas web  pero en otros no sera nada despreciable.... por ejemplo en videojuegos, aplicacion de filtros de imagenes, detecion de colisiones a nivel de pixel, procesamiento de Meshes etc etc.

    lunes, 21 de enero de 2008 22:35
    Moderador
  • jajajajaja

     

    lo se Toni lo se... no pretendia convencerte

     

    tu eres mas de la "quinta" del elguille jejejeje, de los de visual basic de toda la vida

     

    cualquiera se mete con el visual basic... lo defiendes a capa y espada... y ya no hace falta!!!! que ahora es un lenguaje bueno!!!... ya no tienes porque soltar las mentiras de siempre  jejeje

     

    Un saludo.

    martes, 22 de enero de 2008 8:51

Todas las respuestas

  • Es una simple cuestión de productividad. VC++ es imprescindible en escenarios de programación de periféricos o en los que necesitamos obtener el rendimiento más alto posible. Para aplicaciones más "cotidianas" otros lenguajes nos permiten olvidarnos de ciertas preocupaciones (gestión de memoria, punteros, etc.) que simplifican el desarrollo, con ciertas penalizaciones que para la mayoría nos resultan asumibles.

     

    Lo mismo pasa si le preguntas a un programador de VC++ porque no programa en Assembler. Se trata de buscar el punto adecueado a las necesidadse de cada uno.

     

    Salud y suerte!

    lunes, 21 de enero de 2008 7:53
  • Entendido, aunque si estoy con Assembler de PIC, es algo que requiere tiempo pero es eficaz de naturaleza.
    lunes, 21 de enero de 2008 9:01
  •  

    VC++ es una herramienta muy  buena, la mejor del mercado para C++ y C++ es uno de los mejores lenguajes de programación jamas creado...

     

    Sin embargo C++ ya es obsoleto para la inmensa mayoria de desarrollos que se requieren hacer hoy en día, y aunque aún es muy vigente para cosas como:

     

    Videojuegos

    Antivirus

    Sistemas Operativos

    Controladores de dispositivos

    Proyectos cientificos

     

    Y por otro lado C++ es comparativamente muy dificil si se compara por ejemplo con C#, que si bien no es que sea muy facil para un novato , realmente si es mucho mas facil que otros lenguajes.

    lunes, 21 de enero de 2008 13:18
    Moderador
  • Lo que se que en cada foro que voy le digo a la gente que c# es bueno y mejor que C++, uff los defensores del C++ casi me matan. Se niega a creer que C# es mejor aunque lo diga MS. Aún aí algunos pasan a C#. El VB si que lo veo un poco desuso pero no tanto que el pascal.
    lunes, 21 de enero de 2008 19:00
  • algunos desarroladores de C++ se creen los reyes del mundo y usualmente se consideran genios y tienen un ego muy alto... para ellos cualquier cosa diferente  de C++ y assembly es una basura... y no hay razones que valgan...


    evidentemente estan equivocados... y con el tiempo se quedaran sin trabajo... salvo que se actualicen a managed C++ extensions...

    Ahora si vas a un foro de C++ veraz como cada vez son mas las personas que llegan apreguntar de C++ pero colocan las preguntas con codigo de managed extensions... lo he vivido....
    lunes, 21 de enero de 2008 19:04
    Moderador
  • Y yo que le tengo tanto cariño a mi querido VB.NET... Wink

     

    Antes de que entre todos me lo enterreis a base de C... sólo quería comentar algo, y es que en .NET el 70% de desarrolladores usan VB.NET en contra del 30% que lo hacen con C#, con lo que... larga vida a VB!!!! Stick out tongue

     

    Nada... ya me he sacado la espinita, no me lo tengais en cuenta....

    lunes, 21 de enero de 2008 19:33
  •  Toni Recio Escribió:

    Y yo que le tengo tanto cariño a mi querido VB.NET... Wink

     

    Antes de que entre todos me lo enterreis a base de C... sólo quería comentar algo, y es que en .NET el 70% de desarrolladores usan VB.NET en contra del 30% que lo hacen con C#, con lo que... larga vida a VB!!!! Stick out tongue

     

    Nada... ya me he sacado la espinita, no me lo tengais en cuenta....



    Eso por la inmensa mayoria del mercado son desarrollos para sistemas de infromacion... desde luego orientados a datos e internet... porque la mayoria de otros proyectos son hechos en C#... de hecho por ejemplo XNA solo funciona con C# al igual que algunos motores de videojuegos, y la mayoria de proyectos de lo que se puede llamar el 'hard core' son hechos tambiein en C#...

    ejemplo:

    http://www.cdrnet.net/projects/nmath/

    Y no es desprestigiando a los sistemas de informacion, solo que son dos enfoques diferentes que requieren habilidades muy diferentes desde el punto de vista de la construccion de sw....


    Para mencionar solo una diferencia, el desarrollador de VB (con sus IS y los desarrollos web) generalmente esta mas enfocado a ser mas productivo y desarrollar más rápido... por eso en VB.NET hay cosas que se hacen mas faciles que en C#, mientras que el desarrollador de C# casi siempre esta mas orientado a optimizacion de procesos y programacion por componentes  por eso hay cosas que se pueden hacer en C# y no en visual basic o cosas que en visual basic son mas faciles pero no hay tanto 'control'  de como funcionan las cosas.

    Es una estrategia muy valida porque la mayoria de los desarrolldores de VB.NET vienen de vb 6.0 o anterior y hay varios paradigmas que cuesta trabajo romper, para un desarrollador de vb hubiese sido traumatico comenzar con C#  mientras que la mayoria de los desarroladores de C# vienen  de C++ o Java o son nuevos y estan acostumbrados a otros estilos de codificacion.
    lunes, 21 de enero de 2008 19:46
    Moderador
  • La verdad es que no es la primera vez que me tengo que oir que hay cosas que se pueden hacer con C# pero no con VB, y al revés, bueno para ser sincero, siempre escucho que que con C# hay cosas que no se pueden hacer en VB.NET, pero que con C# se puede hacer todo....

     

    Yo todavía estoy esperando que alguien me enseñe lo que puede hacer C# y VB no, en serio. Siempre que miro cuestiones de arquitectura, del CLR, MSIL, etc... la conclusión es siempre la misma, VB.NET y C# son solo sintaxis diferentes para expresar lo mismo.

     

    Perdonar que sea tan "radical", pero es que tengo en muy buen concepto la opinión de JC por eso me interesa mucho su punto de vista. No es por crear polémica, ni por ganas de tener la razón, pero no acabo de estar de acuerdo con algunas afirmaciones del post anterior, y me gustaría crear un poco de sano debate... Wink

    lunes, 21 de enero de 2008 20:06
  • claro, por ejemplo antes de vb.net 2.0 no se podia hacer sobrecarga de operadores ... desde luego ahora si se puede...

    pero si se fijan no hablo puntualmente del lenguaje sino de las tendencias de los desarrolladores que utilizan cada herramienta, yo no dudo que en vb.net se pueda hacer otra libreria como Math.Net desde luego que se puede hacer pero habran limitantes unas muy tontas y otras no tanto...

    ejemplo de cosas que estan en C# y no en vb.net

    *el operador ++ y el operador --
    *La opcion de generart codigo con apuntadores (unsafe)
    *Los dos anteriores unidos= navegacion en punteros...

    el solo hecho de poder musar codigo inseguro en C# lo vuelve increiblemente mas rapido. Pero no ves la diferencia en consultas a bd ni nada por el estilo... lo vez trabajando con imagenes (millones de pixeles) y en calculos matematicos ciclicos por ejemplo en las simulaciones.

    Imageinemos programando videojuegos o una api de matematicas o fisica o una aplicacion cientifica utilizando type narrowing conversion... con vb seria un desastre... pero una pagina web con visual basic usando eso... es una bendicion... o no?

    Declaracion opcional de variables... para sistemas de infromacion o paginas web o otros ejemplos es muy bueno pues va en pro de la productividad en la crecion de codigo...
    ahora imaginemos utilizar ese tipo de cosas en proyectos como seti o rosseta... seguramente llevaria a un exceso en el consumo de memoria y procesamiento del gc.., la opcion de decidir acerca de strong tiping o weak typing solo este disponible en C#.


    Respecto a la generacion de IL y al performance del CLR solo digo dos cosas:

    el CLR es el mismo.. asi que no afecta...

    el código generado si bien en ambos casos es IL si es dieferente ed acuerdo a como funciona  los compiladores...
    usualmente entre mas cosas automatice el compilador (y aplica para cualquier lenguaje) es mas factible que hayan problemas de performance ya que que la generalizacion(contrario a especializacion) de funcionalidad  va en detrimento del tiempo de ejecución... en este punto vb puede tener ciera debilidad si bien podria considerarce despreciable y fuera de lugar porque el código generado no depende del lenguaje sino del compilador...

    sin embargo allí hay diferencias tangibles y criticas a la hora de decidir que lenguaje utilizar segun el tipo de proyecto en que estés... es decir misma funcionalidad en vb.net y en C# produce (debido a los compiladores y a algunas característcias de cada lenguaje) codigo IL mucho mas eficiente en uno que en otro... antes tenia un ejemplo que siempre mostraba pero como no lo tengo a la mano les dejo este link:


    http://microsoft.apress.com/asptodayarchive/73656/microsoft-intermediate-language-comparison-between-c-and-vbnet


    Y para finalizar anoto nuevamente que no estoy diciendo que vb sea malo, lo que quiero mostrar es que si hay diferencias que han surgido debido al uso especifico que la tendencia de mercado le ha dado a cada lenguaje. Cada cual es muy bueno en lo suyo, aunque si me ponen a elegir nunca dejaria C#... ahora pongan a elegir a alguien que venga de  vb6.0 o similar... a ver que dice... lo mismo nunca dejaraia su vb...

    Pero a todos nos gusta matar las pulgas de una manera diferente.... Wink


    saludos
    lunes, 21 de enero de 2008 21:42
    Moderador
  •  Juan Carlos Ruiz Pacheco Escribió:
    claro, por ejemplo antes de vb.net 2.0 no se podia hacer sobrecarga de operadores ... desde luego ahora si se puede...

    La sobrecarga de operadores es una vía para mejorar la productividad a la hora de codificar, pero no veo que afecte a la hora de poder realizar un proyecto u otro.

     Juan Carlos Ruiz Pacheco Escribió:

    pero si se fijan no hablo puntualmente del lenguaje sino de las tendencias de los desarrolladores que utilizan cada herramienta, yo no dudo que en vb.net se pueda hacer otra libreria como Math.Net desde luego que se puede hacer pero habran limitantes unas muy tontas y otras no tanto...

    En las "otras no tanto" me gustaría incidir. No veo que limitaciones tendré a la hora de programar una Math.Net con VB.

     Juan Carlos Ruiz Pacheco Escribió:

    ejemplo de cosas que estan en C# y no en vb.net

    *el operador ++ y el operador --
    *La opcion de generart codigo con apuntadores (unsafe)
    *Los dos anteriores unidos= navegacion en punteros...

    Lo de los operadores ++ o -- no deja de ser anecdótico, y volvemos a estar en una simple cuestión de sintaxis.
    El tema del Unsafe es más complejo, pero tal y como lo veo es sacar a C# del CLR. Es un giño a C++, pero en realidad convierte el código en no administrado, y en mi modesta opinión... para eso ya está C++.


     Juan Carlos Ruiz Pacheco Escribió:

    el solo hecho de poder musar codigo inseguro en C# lo vuelve increiblemente mas rapido. Pero no ves la diferencia en consultas a bd ni nada por el estilo... lo vez trabajando con imagenes (millones de pixeles) y en calculos matematicos ciclicos por ejemplo en las simulaciones.

    Aquí vuelvo un poco a lo mismo. Cödigo no administrado = Mayor rendimiento, peor productividad. Y si buscamos rendimiento, pq no usar directamente C++?


     Juan Carlos Ruiz Pacheco Escribió:

    Imageinemos programando videojuegos o una api de matematicas o fisica o una aplicacion cientifica utilizando type narrowing conversion... con vb seria un desastre... pero una pagina web con visual basic usando eso... es una bendicion... o no?

    Podemos deshabilitar este tipo de conversiones, no?

     Juan Carlos Ruiz Pacheco Escribió:

    Declaracion opcional de variables... para sistemas de infromacion o paginas web o otros ejemplos es muy bueno pues va en pro de la productividad en la crecion de codigo...
    ahora imaginemos utilizar ese tipo de cosas en proyectos como seti o rosseta... seguramente llevaria a un exceso en el consumo de memoria y procesamiento del gc.., la opcion de decidir acerca de strong tiping o weak typing solo este disponible en C#.

    De nuevo podemos deshabilitar estas características.

     Juan Carlos Ruiz Pacheco Escribió:

    Respecto a la generacion de IL y al performance del CLR solo digo dos cosas:

    el CLR es el mismo.. asi que no afecta...

    Totalmente de acuerdo.

     Juan Carlos Ruiz Pacheco Escribió:

    el código generado si bien en ambos casos es IL si es dieferente ed acuerdo a como funciona  los compiladores...
    usualmente entre mas cosas automatice el compilador (y aplica para cualquier lenguaje) es mas factible que hayan problemas de performance ya que que la generalizacion(contrario a especializacion) de funcionalidad  va en detrimento del tiempo de ejecución... en este punto vb puede tener ciera debilidad si bien podria considerarce despreciable y fuera de lugar porque el código generado no depende del lenguaje sino del compilador...

    Como bien dices es algo muy genérico, y en algunos casos puede ganar esa despreciable ventaja un lenguaje u otro.


     Juan Carlos Ruiz Pacheco Escribió:

    sin embargo allí hay diferencias tangibles y criticas a la hora de decidir que lenguaje utilizar segun el tipo de proyecto en que estés... es decir misma funcionalidad en vb.net y en C# produce (debido a los compiladores y a algunas característcias de cada lenguaje) codigo IL mucho mas eficiente en uno que en otro... antes tenia un ejemplo que siempre mostraba pero como no lo tengo a la mano les dejo este link:


    http://microsoft.apress.com/asptodayarchive/73656/microsoft-intermediate-language-comparison-between-c-and-vbnet

    Yo aquí no ando muy convencido la verdad. No creo que las diferencias sean tantas, ni que casos son más propicios para un lenguaje u otro.

     Juan Carlos Ruiz Pacheco Escribió:

    Y para finalizar anoto nuevamente que no estoy diciendo que vb sea malo, lo que quiero mostrar es que si hay diferencias que han surgido debido al uso especifico que la tendencia de mercado le ha dado a cada lenguaje. Cada cual es muy bueno en lo suyo, aunque si me ponen a elegir nunca dejaria C#... ahora pongan a elegir a alguien que venga de  vb6.0 o similar... a ver que dice... lo mismo nunca dejaraia su vb...

    Pero a todos nos gusta matar las pulgas de una manera diferente....

     

    Amén con lo de las pulgas... Stick out tongue

    Felicidades JC, te lo has currado! Wink

    lunes, 21 de enero de 2008 22:19
  • La sobrecarga de operadores es una vía para mejorar la productividad a la hora de codificar, pero no veo que afecte a la hora de poder realizar un proyecto u otro.

     

    Asi es, eso es lo que yo llamaria una caracteristica que no va de fondo... una tonta.

     

    En las "otras no tanto" me gustaría incidir. No veo que limitaciones tendré a la hora de programar una Math.Net con VB.

    Performance.

     

    El tema del Unsafe es más complejo, pero tal y como lo veo es sacar a C# del CLR. Es un giño a C++, pero en realidad convierte el código en no administrado, y en mi modesta opinión... para eso ya está C++.

     

    Nop, porque la gracia es poder utilizar fragmetos de codigo unsafe en entornos plenamente administrados.. y ahihay una gran diferencia, pues no necesitohacer que mi GUI o mis procesos basicos sean unsafe eso le agregaria demasiada complejidad innecesaria... pero puedo tener todo en un am,biente administrado y unicamente el modulo o funcion critica para mi trabajo de manera unsafe.

     

    Aquí vuelvo un poco a lo mismo. Cödigo no administrado = Mayor rendimiento, peor productividad. Y si buscamos rendimiento, pq no usar directamente C++?

     

    Por lo mismo de antes... te volveras muy improductivo utilizando caracteristicas que solo te dan valor agregado en algunas porciones del codigo.

     

    Podemos deshabilitar este tipo de conversiones, no?

    claro, pero lo usual sera no darse cuenta de eso sino hasta que tu aplicacion ya esta hecha un desastre... y en ese punto lo usual es gastar horas de depuracion hasta decir : 'oh se m e ha olvidado desactivarlas en esta dll'... eso no deberia pasar pero siempre pasa...

    Yo aquí no ando muy convencido la verdad. No creo que las diferencias sean tantas, ni que casos son más propicios para un lenguaje u otro.

     

    realmente depdende de lo que estes haciendo... y estoy muy seguro que en algunos casos no importara... y vuelvo a mi ejemplo de las paginas web  pero en otros no sera nada despreciable.... por ejemplo en videojuegos, aplicacion de filtros de imagenes, detecion de colisiones a nivel de pixel, procesamiento de Meshes etc etc.

    lunes, 21 de enero de 2008 22:35
    Moderador
  • uffff....

     

    La madre que os trajo.... menudos panda de rayados

     

    A ver señores un poquito de sensatez...

     

    El C++ es jodido de implementar... punto... esa es su principal pega.

     

    El Visual Basic... ¿tu ya sabes lo que opino del basic verdad Toni?  ... ahora se ha convertido en un lenguaje decente... pero hasta hace bien poquito... en sus versiones 6 y 5 (que todavia se utilizan mucho) era un lenguaje bastante pobre.

     

    El C# es un lenaguaje nuevo diseñado especialmente para .Net ... es una adaptacion del c++ a .net... aunque a veces parece mas una adaptacion de java a .net

     

    Pero bueno... yo soy de los de C#.... pero porque me resulta mas elegante... he trabajo con los tres, y en cuestion de sintaxis es el que mas me gusta.

     

    Por cierto Toni, te voy a decir una cosa que no puede hacer con Visual Basic .Net y que yo estoy muy acostumbrado a hacer en C#:

     

    Tengo una clase con tropecientas mil propiedades publicas... pues bien en c# puedes escribir cada propiedad en una unica linea... mientras que en Visual Basic la clase tiende a hacerse mas y mas grande por momentos jejeje

     

    (asi como curiosidad graciosa )

     

    Pues eso... que a cada uno le gusta el leguaje que le gusta... y no has mas que hablar jejeje esto es muy subjetivo

     

    es como si yo le pregunto a Toni ¿oye te gusta mas hablar en español o en catalan?

     

    (y prefiero no saber la respuesta jajajajaja)

     

    Un saludo a todos.

    martes, 22 de enero de 2008 8:32
  • A mí en lo único que me medio convence de vuestros argumentos es lo del "unsafe". Soy más partidario de agregar a mi solución un proyecto de C++ para estas cosas, pero está claro que si te acostumbras a C# luego trabajar con C++ es más sencillo.

     

    Por lo demás, dentro del código administrado... no me convenceis.... Wink

    martes, 22 de enero de 2008 8:43
  • jajajajaja

     

    lo se Toni lo se... no pretendia convencerte

     

    tu eres mas de la "quinta" del elguille jejejeje, de los de visual basic de toda la vida

     

    cualquiera se mete con el visual basic... lo defiendes a capa y espada... y ya no hace falta!!!! que ahora es un lenguaje bueno!!!... ya no tienes porque soltar las mentiras de siempre  jejeje

     

    Un saludo.

    martes, 22 de enero de 2008 8:51
  •  

    Por favor no olvides marcar las respuestas que te hayan sido de ayuda como correctas   .

    sábado, 26 de enero de 2008 15:26
    Moderador
  • Por hacerme perder el tiempo con solo leer lo que pides. Pues la pondré a todos en correcta menos a ti.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Es broma.

     

    jueves, 31 de enero de 2008 0:12
  •  

    jueves, 31 de enero de 2008 0:18
    Moderador
  • Mmm... sí, hay gente que tiene el ego alto, pero la verdad es que tienen (tenemos) buenas razones para desconfiar de lenguajes como C# (y yo programto también en éste).

    El hecho de que C# te oculte muchas cosas hace que muchos programadores cometan errores. Un ejemplo clásico que te encuentras en C# es que hay muchas personas que creen que por el hecho de tener código administrado ya no hay que preocuparse por la memoria (i.e. que no hay memory leaks). Falso por supuesto, hay muchas formas de provocar memory leaks en C#. Y eso se da porque no se preocupan por aprender las interioridades del lenguaje. Cosa diferente a C++, donde _tienes_qué_ hacerlo o te mueres de hambre. Todo esto resulta en sistemas pesados y muchas veces ineficientes, que es algo que, aunado al peso intrínseco del .NET Framework, aterra a la mayoría de programadores de C++. Este es un ejemplo.

    Claro, siempre hay los petulantes (espero no encontrarme entre ellos), pero en general creo que hay buenas razones.

    Por cierto, con respecto al mercado laboral, es interesante ver que conviene más saber C++ que C#. Al menos en México. Un buen programador de C++ no baja de los $25,000 al mes (unos 1500 euros) mientras que uno de C# los hay desde 15000 (poquito menos de 1000 euros). Interesante. Al menos acá, el mercado está demandando muchísimo más a programadores de C++. En fin, estadísticas a final de cuentas.

    Y sobre tu comentario de "si vas a un foro de C++...", es cierto para foros de Microsoft o de Visual C++. Es falso para cualquier otro lugar (lawebdelprogramador.com, codeproject.com, y los miles de grupos en usenet, por ejemplo). C++ está bastante vivito y, si consideras a C y C++ como una unidad en cuanto a lenguaje, sigue siendo el más empleado del mundo, seguido por Java y C#.

    En mi opinión, C# es un buen lenguaje. Bueno, hasta C# 2.0 se me hacía un buen lenguaje. No sabes cómo me desagrada C# 3 y .NET 3.0 / 3.5. C# me parece que es la mejor opción para la mayoría de desarrollos a la medida, cuando tu cliente tiene la billetera abierta y políticas no tan restrictivas, y que el sistema no sea tan crítico. Que es la mayoría de los casos de desarrollos a la medida. Desarrollos comerciales de "software empaquetado", me parece que C++ sigue siendo la única opción feasible si quieres abarcar un buen nicho de mercado.

    En fin, como decían arriba, hay que escoger la mejor herramienta para cada desarrollo. Aún Cobol se emplea hoy día.

    Mis dos centavos.

    Saludos.
    jueves, 10 de abril de 2008 15:14