Krita, o lo que Gimp debería ser

#52   #50, no, por ahí sí que no paso. C++ va a tener un tiempo de ejecución siempre mayor igual que el mismo programa en C. Más que nada, porque C++ no es más que C con un montón de características redundantes que se pueden implementar también en C. C++ no ha aportado ninguna característica nueva. En todo caso, ha limitado algunas cosas.

#86   #55, las mejoras de C++ son meramente sintácticas. La orientación a objetos puede implementarse en C perfectamente.

#59, los objetos SON redundantes. Modelar una aplicación en forma de objetos no requiere un lenguaje orientado a objetos. Y si me hablas de que bajo el mismo programador poco hábil, un lenguaje produce un código más óptimo que otro lenguaje, eso realmente no es un argumento.

#68, a ver, es obvio que si utilizo el gcc y el g++ para compilar el mismo archivo las diferencias van a ser miserables (quizá g++ incluya algún extraño thunk con impacto nulo en un código bastante trabajoso). Y sobre lo que dices, a ver, está claro que depende del programador. Pero también está claro que cada lenguaje tiene sus tendencias y sus formas. Si usas C++ es porque vas a usar objetos. Y es aquí donde se debe establecer la comparativa con C.

#69, no son el mismo proyecto. C tiene un estándar, C++ tiene otro y objective-C tiene otro distinto. Y a ver, también he de dejar claro por qué defiendo C a ultranza. C++ es un lenguaje con el que no me meto si lo más duro que vas a hacer va a ser la mítica aplicación gráfica de usuario que manipula representaciones de elementos del mundo real. Te rompes menos la cabeza. Sin embargo, yo he tenido que programar mis rollos desde el más puro bajo nivel hasta la más abstracta interfaz gráfica (no es que haya programado tampoco demasiado, pero sí en muy diversos ámbitos). He usado GTK (aún cuando Qt seguramente tenga bindings para C) el cual, pese a ser tradicionalmente en C incorpora una orientación a objetos. Y el hecho de que C pueda usarlo a tantos niveles con la misma facilidad me parece realmente atractivo.

#78, explícame eso de los ámbitos. Yo he tenido que desensamblar binarios en C y C++, y estos últimos incorporan una cantidad ingente de basura que lo último en lo que te hacen pensar es en un compilador con mucha información.

Veréis, y así quizá os responda a todos, mi problema con C++ es doble. El primero es que la abstracción a objetos no requiere una nueva sintaxis en C. De hecho, quizá algo que me parece bastante desagradable de muchos de los proyectos en C++ que he visto por ahí es la sobreabstracción de algunos elementos sacrificando una eficiencia que puede llegar a ser importante. El segundo es todo el código de apoyo que tiene que generar para mantener todas esas abstracciones, que lo aleja más de su estructura una vez compilado. Quizá lo que más miedo me da es el operador "new". ¿Cómo funciona? ¿Necesita paginación para funcionar? ¿Dónde reserva? ¿Puedo tocar sus estructuras internas? ¿Y qué pasa con malloc? Tengo un operador que hace cosas muy complicadas con la memoria, cuando eso es algo que normalmente se deja a la merced una función. Los operadores deberían hacer operaciones atómicas, o casi atómicas. Si esto fuese como Java quizá no me escandalizaría tanto, pues la memoria es una caja negra que la VM sabe cómo manejar.

Quizá sea un anticuado y tenga la cabeza cuadriculada, pero a mí tantas abstracciones a tan diversos niveles en el mismo lenguaje me asustan.

#28   #26 Me gustaría ver si la gente tuviera que pagar lo que vale el Photoshop cuanta gente pasaba a necesitarlo realmente ...

#78   #52 Esto no es cierto, C++ tiene ámbitos en los que el compilador tiene más información sobre qué hace el código, por lo que puede generar un código máquina más adecuado.

Por favor, si hay que desprestigiar algo, proporciona datos por lo menos.

#10   #7 gimp si tiene soporte para CMYK. No de forma nativa pero si que lo soporta. Ahora bien, linux lo que necesita urgentemente es un buen curro en el tratamiento de la gestión del color. Es de las pocas cosas que le falta a linux para poder trabajar con impresoras, scaneres y todo lo relacionado en AAGG.

#17   Me parecen un poco injustos los comentarios que hace el articulista. GIMP es un excelente programa, y aunque es cierto que hace tiempo que no añade nuevas funcionalidades, según tengo entendido el problema es que se ha ido quedando sin desarrolladores, y ahora mismo tiene a muy pocos trabajando en el proyecto.
En cuanto a Kirita, quizá ahora sea una buena alternativa, pero eso no quiere decir que lo fuera en el pasado, motivo por el que las distros posiblemente no le daban tanta importancia como a GIMP, y esto no se le ha ocurrido al redactor antes de lanzarse a la piscina de esa manera y hablar gratuitamente de talibanismo.

#40   #36, C++ es más lento. No mucho más, pero es más lento.

#50   #40 Si el compilador es decente y haces las cosas bien no solo C++ puede ser igual de rapido que C sino que puede sobrepasarlo y todo

#57   #28 Photoshop no es demasiado caro para lo que el uso que se le puede llegar a dar (y los beneficios que puedes obtener gracias a el si te dedicas a algo del mundillo). Aparte, hace un par de años, no se si aún es igual, podías comprarte 5 licencias de photoshop (o algo asi) por unos 400€ (aprox). Si lo compras entre varios no es nada del otro mundo.

#68   #52 sé lo que quieres decir, pero no es cierto en términos absolutos. C es un subconjunto de C++ hoy en día, lo que quiere decir que el compilador es el mismo, con funciones deshabilitadas cuando compila en C. Si tu haces un for, un while, lo que sea, en C y C++, el código de máquina resultante va a ser idéntico porque de hecho, lo compila el mismo compilador sea C o C++.

Por tanto, un programa en C++ va a ser exactamente igual de rápido que un programa en C que haga lo mismo. Pero (y ahí es donde tienes tu parte de razón) la estructura orientada a objetos de C++ tiende a una programación redundante que acaba realizando más proceso del necesario, mientras que en C se tiende a economizar, el mismo fenómeno que ocurre en ASM. Pero esto es un problema del programador y de diseño y no del lenguaje en sí mismo. Nada te impide en un programa C++ hacer funciones críticas en ASM incluso si lo deseas. Y por supuesto, un buen programador puede hacer código más eficiente en C++ que un mal programador en ASM. Saludos.

#72   #31 utilizar GIMP, es dañino y doloroso. No puedes cambiar eso, ni siquiera su comunidad quiere (o tal vez no puede) cambiarlo.


Hace poco comenté en otra noticia que GIMP era un cadáver que ya olía, y a los pocos segundos ya tenía el primer negativo. Supongo que a este tipo de fanboys es al que se refiere el autor del artículo, y es que los radicalismos no son buenos.

#113   #110, pero es que yo puedo hacer una plantilla con macros. De hecho, muchos de mis programas utilizan plantillas basadas en macros.

De ser por mí, utilizaría un lenguaje cuya sintaxis se pudiese definir dentro del propio lenguaje (sin necesidad de una máquina virtual o algo así). Y C no hace eso, pero tiene sus trucos. No sé, hasta el momento C++ no me ha enseñado nada que no pueda hacer con C con mayor control.

He mirado Scala y tiene buena pinta (lo de mezclar programación funcional con objetos es muy atractivo), lo que es una lástima es que corra bajo una máquina virtual de Java. Quizá chapucee un poco con él un día de estos.