
>Pero por otro lado, la solución mágica, siempre es un
>Pero nunca se plantea que el problema puede ser otro...
>This philosophy makes C++ more flexible, but also
Hola,
>Lo que me llamo la atención es que definitivamente reconozcan
> las dificultades de trabajar con C++, como se dice habitualmente
> "a confesión de partes, relevo de pruebas".
Yo he visto que las personas sensatas que trabajan en C++
no tienen inconvenientes en reconocer las dificultades
que presenta. En general, me parece que tratan de resolverlas
adicionando herramientas y/o librerías, lo cual me parece
conveniente.
Lo criciable es que esas soluciones los separan de los
demás trabajadores que usan C++; son soluciones
que no forman parte de C++, yo creo que es así
en parte porque:
1.- se entiende a C++ como un lenguaje de programación
y las herramientas no forman parte de éste.
2.- porque c++ fue definido como la mejor solucion
para generar sistemas OO con alta perfomance
(el c++ las personas no cuentan tanto como en la
época que fué definido C)
>Pero por otro lado, la solución mágica, siempre es un
> framework que soluciona todo !.
Y si... esto tiene que ver con la época en que fué propuesto
su uso para hacer software; una época dónde se apreciaba
el valor de Modula2 y Ada.
Esos valores hoy aún perduran en el aprecio de quien "adhiere"
a la idea de los componentes de software (y a la "industria
del software").
>Pero nunca se plantea que el problema puede ser otro...
Toda buena herramienta fuerza los limites de lo que uno ambisiona.
Dicho así... (sobre C++) parece un poco odiosa la frase :-)
Pensemoslo sobre Smalltalk y su historia reciente,
y veremos como los limites de lo que se ambisiona
en Smalltalk se ha reducido cada vez mas en forma
proporcional a la cantidad de gente que lo usa...
lo que quiero decir es que no esta en relacion con la
herramienta en si, sino con quienes la usan y para que la usan,
... no puede verse mas alla de la problemática que impone
el uso que uno le da a lo esta a mano.
>Además se lo critica al autor del paper por recomendar
> boost como solución definitiva, parece no haber
> consenso entre ellos. jajaj
Que no haya consenso es algo esperanzador.
Quienes no nos sentimos parte de esa comunidad, debemos
estar siempre atentos a brindar nuestra opinion, en caso de
ser consultados... y brindar la informacion MINIMA sobre lo
nuestro a quien pueda necesitarla/utilizarla.
>This philosophy makes C++ more flexible, but also
> harder to learn and use correctly, even if you use
> 3rd party libs instead of creating your own
Esto oculta (al inocente) la complejidad de ensamblar soluciones
de distintos proveedores que usan modelos diferentes para
soportes de base; o modificaciones basicas.
Cosa que no parece un problema solo despues de haberlo
"resuelto" (es decir debugeado y pagado un precio generalmente
mas alto que hacerlo si uno es un productor de software y no
un mero pegadorDePaquetes/integrador).
>Es mas flexible C++ ?.
Cómo puede ser flexible un lenguaje?
Si lo cambias ya no es ese lenguaje...
Si no lo cambias... no cambias nada,
solo pones mas piezas (en cuyo caso
no puede considearse flexibilidad, sino intercambiabiliad
de librerias que esta garantizada desde los 70
para cualquier plataforma de uso real posterior a Pascal).
>C++ is still used for games because it is best
> used to generate performance heavy code with.
No creo que este argumento sea correcto.
Creo que se usa C++ porque es facil conseguir empleo en
esa brecha laboral si uno dice que conoce C++,
en mi opinion, es como el uso de Java y hacer
aplicaciones web... (es lo que hay... de ambos lados,
en el que busca empleo y en el que busca personal)
>ES la única forma de lograr performance ?
Es una buena forma de perder perfomance.
"buena forma" porque podes perderla y nadie
sospechará que fué cupa tuya (si no es usado de la
"mejor manera" y/o no se hace la inversion necesaria
para lograr eficiencia).
hasta pronto,
Ale.
Sin conexión 
Enviar correo