Krita, o lo que Gimp debería ser

#101   pues como no haya mejorado mucho... hace un par de años era lento con avaricia el krita este. No estaba preparado para ser usado, aunque prometia.

#103   no entiendo, o prefiero no entender porque votan negativo a #58, solo dice que ha comparado varios programas y cual es el que mejor le va

#104   #57 En la página de Adobe el precio de una licencia de CS5 -programa completo no actualización- es de 1.001,82€ (Versión física. Si lo descargas vale 1.027,29€ ¿?)

Uhmmm, creo que para cualquiera que no se dedique a ello de manera profesional no le compensa.

#105   #86 Entiendo perfectamente tus reservas. Yo he sido durante muchos años programador de ASM y al pasar a C tuve resistencias similares, las tuve también de C a C++, de hecho, las mismas o muy parecidas a las tuyas.

Mira, tienes razón en que todo lo que hace C++ se puede implementar en C (de hecho, en ASM también), pero cuando ves la gran diferencia es cuando trabajas en un proyecto con muchos programadores (sin llegar a cientos, que también).
A uno, programando solo, le puede parecer irrelevante declarar los miembros de una clase como public, private o protected, por poner un ejemplo sencillo, y eso solo se puede hacer en C++. Ciertamente el código generado no varía, pero cuando meten mano a un repositorio muchos programadores, un proyecto C es muy dificil de mantener (uno en ASM, aún peor). Sin embargo, esos detalles aparentemente irrelevantes como declarar correctamente los private de una clase ayudan a mantener un cierto orden dentro del caos que a la larga, ahorra muchísimos bugs. La abstracción (muchas veces con tendencia a la sobre-abstracción, como bien dices), también simplifican mucho la programación entre muchas personas, al hacer clases que son autonómas por si mismas y mucho más fáciles de mantener.
En mi experiencia, cuanta más gente mete mano en el código, más se aprecian las virtudes del C++, que no son efectivamente en pro de una mayor velocidad de ejecución si no de una mayor robusted y/o modularidad. Más sencilllo de mantener, en definitiva.

Las herencias son una herramienta muy potente de C++ que si bien pueden implementarse en C, son un poco follón de hacer. Abusando o mal implementando pueden ser horribles, pero bien usadas ahorran una barbaridad de trabajo y el código no tiene por qué perder eficicencia. Creo que la mayoría de los programadores de C abrazan definitivamente el C++ cuando aprenden a usar bien las herencias y descubren la potencia de utilizar las clases de una forma abstracta. Pensar "en C++" no es lo mismo que pensar "en C". Cuando un programador ASM empieza a programar en C, se nota, hace C al estilo ASM. Lo mismo cuando un programador de C pasa a C++, tarda un tiempo en apreciarlo y sacarle jugo (más si va con prejucios).

En cuanto a las redefiniciones caóticas de operadores como new, u otros operadores, el abuso es un vicio en C++ que debe evitarse o manejarse con precaución. En principio, el operador new estándar no tiene mucho misterio, es un malloc o bien un alojamiento en el stack de los datos de una clase y posterior llamada al constructor. Puedes ver el código en el runtime estándar o puedes desensamblarlo.

Yo que no tengo ningún prejucio a priori con ningún lenguaje (en el mismo proyecto puedo usar ASM, C, C++, PHP y Bash Script, por decirte algo), te animaría a que te acercases al C++ con la mente abierta, y descubras las grandes ventajas que tiene. Hay por ahí un libro, "Think in C++", que te recomiendo encarecidamente. Un saludo.

#106   Lo siento, no me convence el artículo y se empeora mi opinión cuando leo los comentarios del mismo (no tienen desperdicio ). De todas formas, no se porqué siempre establezco está comparativa, para mi Krita es una especie de Paint Shop Pro y Gimp otra especie de Photoshop. Hace mucho que no he usado estos programas, desde que dejé de utilizar windows, basicamente (ya va casi una decada), asi que no me mateis por la comparativa, no quiero decir que uno sea mejor el otro, ni que los libres sean mejores ni peores, solo que simplemente son tan diferentes que no se les puede comparar, son dos formas distintas de hacer las cosas, por eso me parece que para alabar Krita, no me parece muy buena idea meterse con Gimp.

#107   #100 Sigue sin ser tan flexible. Gimp permite perl y phyton como scripting NATIVO (y lo siento... eso mola)

#108   Aún conservo la esperanza de que algún día llegaré a leer una crítica de este tipo en la que el protagonista haya donado o colaborado activamente en el proyecto en cuestión.

#109   #28 Pues no se que decirte. No creo que a un profesional le resulte cara una licencia para todo lo que ofrece y cómo lo ofrece. Ante estos programas que llevan toda la vida de Dios siendo el mejor yo me quito el sombrero.

Otra cosa es que sea necesario para correcciones típicas de nuestras fotos.

#110   #86 menuda sarta de disparates estas diciendo.

Para empezar, C++ tiene genéricos, que no es lo mismo que un puntero void. Ya que los genéricos, el compilador se encarga de detectar posibles errores en tiempo de compilación. Y posiblemente este es uno de los puntos mas fuertes de C++ enfocada a la meta programación. codeando.blogspot.com/2006/11/metaprogramacin-por-medio-de-templates.h

Luego tenemos, las múltiples cosas que nos ofrece el paradigma orientado a objetos. Como la herencia, la ligadura dinámica, clases abstractas, etc... mírate la teoría de la orientación a objetos. Que es muchísimo mas que simples clases y objetos.

Pero vamos, por ti seguiríamos programando en ensamblador de 8086.

Por cierto, vete mirando una cosa llamada Scala. Buen lenguaje.

#111   pero qué flamewar se ha montado en un periquete no?

#112   Con magia de templates en ciertos casos C++ puede tumbar lo que sea

#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.

#114   #113 Echale un vistazo a LISP

#115   #107 Kross permite también Python, al igual que Ruby, Javascript y (en desarrollo) Java y Falcon. Y para todo programa que lo integre, equivale a tragar scripts en cualquiera de esos lenguajes.

No digo que sea la panacea, pero tampoco es que haya tanta distancia (técnica) entre los scripts de GIMP y los de Krita.

#116   #47, tienes razón, pero a la cárcel, como se suele decir. En ámbitos informáticos (e ingenieriles, seguramente), se usa "óptimo" de una manera bastante libre, que para algunos puede que viole su significado correcto, y a otros puede parecerles una figura retórica, como la metonimia o la hipérbole. Ciertamente si yo dijera "Bebí una copa", nadie podría corregirme diciendo "La copa no se bebe. Bebiste el contenido de la copa", ya que estoy usando la metonimia. Similarmente para decir "Tuve que hacer mil tareas aburridas".

En informática se aplica "óptimo" como sujeto del acto de optimizar (intentar convertir algo, normalmente un programa, en lo "mejor" posible), aunque en efecto tal sujeto no haya sido mejorado hasta el extremo, sino sólo en cierto grado (y por tanto no sea "óptimo"). Podría compararse con que si tengo un lienzo y le aplico un tinte para dejarlo completamente negro (lo "ennegrezco"), pero dejo el proceso cuando todavía está gris, quizá diga que el lienzo está "ennegrecido", cuando en realidad está "engrisecido".

Al igual que de dos lienzos diría que el "más ennegrecido" (o incluso "más negro") es aquel que, siendo gris (no negro), es más oscuro (aunque técnicamente la cualidad de "negro" no es gradable: o se es negro, o no se es), también se dice de dos programas que el "más óptimo" es aquel que, siendo bueno (no óptimo), es mejor (aunque técnicamente la cualidad de "optimo" no es gradable: o se es óptimo, o no se es).

#117   #86 Decir que la orientación a objetos es "redundante" es gritar al cielo que no has programado nada de más de 1000 lineas e C.
Como han dicho ya en un comentario anterior, a día de hoy C es un subconjunto de C++. Es decir, ciertamente puedes hacer igual los programas que haces con C++ con lo que hay en C, pero renuncias a las facilidades que te da C++.
Es como si me dices que al pueblo de al lado puedo ir en bicicleta o en coche. La diferencia de tiempo es despreciable y en cambio me ahorro el combustible, el seguro, el mantenimiento abusivamente más caro del coche... y te daría la razón. El problema vendría cuando en lugar de ir al pueblo de al lado, quiera hacer un trayecto Madrid-Barcelona. Y el problema es cuando has visto el pueblo de al lado, luego quieres ver otros pueblos. Cuanto más viajas, más te interesa el coche.
Cierto es que se pueden implementar las características de C++ con C (los primeros compiladores de C++ se escribían en C). Pero es como si me dijeses que si a tu bicicleta le pusieses 2 ruedas más, un motor, frenos de disco, un volante con dirección asistida... haría lo mismo que el coche. Aunque claro, entonces la pregunta que te haría yo ¿vas a hacer el coche desde 0 solo pq no te interesa que el coche lleve elevalunas eléctrico?
En fín, por no alargar más esta explicación, pregúntale a alguien que tenga que hacer un programa medianamente grande (y GIMP por ejemplo lo sería), si lo haría con C o C++. Solo por la gestión de las cadenas en C++, ya vale la pena...

#118   #117, esto es absurdo. Hay bibliotecas que implementan una orientación a objetos en C y se usan con bastante éxito. Hay bibliotecas para el manejo de cadenas, vectores, listas y cualquier estructura que te venga a la cabeza en C que ríete tú de lo que proporciona C++. No es que yo quiera implementarlas desde cero, es que ya están implementadas aunque no como la biblioteca estándar de C. C++ puede tener una biblioteca estándar amplísima, pero eso no es más que utilería escrita para el lenguaje.

Y bueno, lo de aplicaciones medianamente grandes es un ejemplo nefasto. Gimp está en C. Linux está en C (cuando podría estar en objective-C como NeXT o C++ como el kernel de Liedtke). Gnome está mayoritariamente en C (cuando existen bindings a muchísimos lenguajes orientados a objetos). Aplicaciones de Windows en C ya se me escapan un poco porque no suelo usarlo, pero seguro que hay algunas cuantas.

Todo es cuestión de la calidad de las abstracciones que uses.

#114, me prometí aprender LISP este verano, pero al final entre pitos y flautas no hice nada. Llevo con la promesa de LISP varios años ya, pff.

#119   #118 Si tienes que recurrir en librerías externas para hacer lo mismo que C++ ¿eso no es redundante?
Linux está C porque cuando se empezó a programar, se hizo en C (observese que Linux viene de Minix). Gnome está en C porque cuando se empezó a desarrollar C++ no estaba suficiente establecido aún...
Si, la mayor parte de proyectos grandes que me puedas mencionar están hechos en C, pero no precisamente porque C sea más rápido, si no porque (al menos entonces) la base de programadores de C es más grande que la de C++. También influye el que inicia el proyecto qué lenguaje domina (pregúntales a los que mantienen el aMSN si dejarían de usar tcl/tk a pesar de que hay lenguajes que le ganan por goleada en más de un sentido).
Además, la discusión es un poco absurda. En el peor de los casos con C++ puedo hacer exactamente lo mismo que con C. Con C también puedo llegar a hacer lo mismo que C++... pero tengo que programarlo. Y hacer una librería para que C tenga de manera "artificial" lo que me proporciona C++ y que además lo supere en rendimiento... no es moco de pavo.
Insisto en lo mismo, que un código en C++ que haga lo mismo que otro en C obtenga un rendimiento inferior, habla más de la capacidad del programador que del lenguaje. Porque insisto en lo mismo, el mismo código en C (con ligerísimas modificaciones) me compila en C++. Así que utilizando las ventajas que cada lenguaje me proporciona, y configurando el compilador de forma adecuada, difícilmente notaré diferencias de rendimiento entre un lenguaje y otro. A no ser, claro está, que se abuse de la abstracción, como también han comentado anteriormente.

#120   #119, es todo lo contrario a redundante. Redundante es cuando hago parte del lenguaje algo que ya puedo hacer con bibliotecas externas.

Linux está en C porque se decidió hacer en C. Linux no está basado en Minix. Está inspirado en Minix, pero está muy lejos de estar basado en él. No comparten código.

Gnome se empezó a desarrollar a finales de los noventa. Y en cualquier caso, esto no es lo importante del debate.

A ver, la comparativa no tiene sentido en lo que ambos lenguajes comparten porque en ambos es lo mismo. La comparativa debe hacerse con lo que un lenguaje proporciona y el otro no. Por eso mencioné el operador new (lo que yo dije, ejemplo de redundancia), los vectores o las cadenas. ¿Puede hacerse una biblioteca de tratamiento de cadenas en C más o menos eficiente que la de C++? ¿"Crear instancia" necesita un operador propio? Etc, etc.

Por cierto, este flame está siendo un canteo ya. ¿No podemos seguir por el IRC o algo así?

#121   #120 new no es en absoluto redundante: new llama al constructor en su caso, malloc no. También podríamos entrar al debate de si los constructores de C++ son prescindibles o no. Pero tanto en C++ como C tendrás una porción de código (función o método), que establezca el código a un estado inicial.
De todas formas, no voy a seguir más con el debate, porque está claro que hablaríamos mil años sobre el mismo tema y no llegaríamos a un acuerdo y tengo el arroz en el fuego...

#122   #109 Debe ser que hay millones de profesionales de la fotografía porque todo el mundo que conozco tiene instalado el Photoshop ...

#123   #113 Sin ánimo de ofender... Dudo mucho de tu profesionalidad cuando presupones que con macros obtienes lo mismo que con templates de C++.
Si bien es cierto que la implementación de templates de C++ no es una solución muy limpia por el diseño del lenguaje (medio nivel, fuertemente tipado, no basado en objetos, etc, etc..), las posibilidades y la calidad del resultado dista mucho de lo que puedas hacer con macros.

Es bastante habitual que uno se crea que está escribiendo código más rápido simplemente por usar un lenguaje de más bajo nivel, pero en la realidad casi siempre es lo contrario. Por ejemplo, la mayoría de la gente se preocupa por estupideces como el coste de la llamada a una función (que en C++ requiere niveles de indirección adicionales frente a C) y deja de lado aspectos realmente importantes como el coste de la creación, destrucción y acceso a memoria.
Con estas premisas viene uno de estos, lo programa en C, se crea sus propias estructuras de datos y obtiene una implementación más lenta que otro con un nivel de conocimiento similar que lo hizo en C++ con STL directamente. Además, (el primero) con mayor probabilidad de contener bugs, leaks y que el código sea complicado o directamente imposible de mantener.

Ahora viene un tercero, lo implementa en Java en la menos de la mitad de tiempo y se ríe de los otros dos porque la diferencia de rendimiento resulta inapreciable.

#124   Siempre es bueno que se mejoren programas , lo tengo viso años atrás y no le daba el toque que quería haber si esta nueva versión que se comenta . te dan ganas de utilizar . Como siempre hago probar las cosa por uno mismo , ya que los comentarios te dan una opinión pero no todos los aspectos.

#125   Por si alguien le aptece echarle un ojo, existe un dvd que explica cómo dibujar comics en krita:
krita.org/component/content/article/10-news/90-draw-comics-in-krita-dv
En la polémica, paso de entrar. Que cada uno use el que quiera.

#126   #122 Pues claro, pero también es ilegal ¿no? Me refiero a que la licencia no es cara para lo que ofrece. No se que querías decirme con tu respuesta exactamente.

#127   #126 Lo que quería decir con mi comentario original y con mi respueta, es que obviamente para los profesionales no les resulta cara la licencia pero si el resto de gente tuviera que pagar lo que vale, es entonces cuando veríamos cuanta gente lo necesita realmente o puede servirse de otras alternativas. Ahora mismo cualquier usuario casero es fácil que tenga más de 1000€ en software ilegal.

#128   #103 yo si que lo entiendo, pero meh, pa qué molestarse.

#129   Y una puta mierda.

Dejadme que explique mi sesudo argumento: A raíz del este artículo de meneame me instale krita (Ubuntu 11.04) y hoy decido probarlo con una foto. Una prueba sencilla.

Abrir JPG -> Scale Image -> Grabar cambios

Al darle al botón de grabar ha petado todo. Si, muy bonita la ventana con su backtrace y demás, pero lo que es la aplicación, ha cascado que da gusto. Redimensionando una imagen... Pero lo mejor viene ahora, hago doble clic en el JPG anterior y... ¡fichero corrupto!. Resultado: imagen perdida, de la cual no tenía ninguna copia.

Me vuelvo a mi GIMP y el krita se lo pueden meter sus autores por donde les quepa.