Ingeniería, Ciencia, Arte y Negocio

Bueno, se acabó la época estival y ya es hora de salir del aletargamiento propio de los largos día de calor que se sufren en Málaga para dar paso a un poco de acción. Aunque sé que no lo voy a cumplir, intentaré a partir de ahora, actualizar este blog con más asiduidad.

Durante este verano he estado leyendo varios artículos, numerosas webs y algunos libros. Debido a esto, me encuentro ahora con nuevas inquietudes sobre las que me gustaría profundizar. Me gustaría avanzar en mis conocimientos de programación concurrente al mismo tiempo que me gustaría intentar sacar partido a CUDA para conseguir ganar potencia de cálculo. Siempre me ha gustado la representación gráfica por ordenador y este verano he adquirido un libro sobre OpenGL. Quizás sea momento de poner todo esto en práctica.

Para contar con un buen entorno de trabajo he actualizado mi ordenador y he comprado las siguientes componentes:

- Procesador Intel 2 Quad Core

- Placa que lo soporta

- 2 Gb de RAM con la intención de actualizar a 4 u 8. No me gusta 6 (no es potencia de 2)

- Tarjeta gráfica NVIDIA GeForce 8500 GT de 1G

El software que he instalado es una distribución Ubuntu de 64bits con la intención de poder utilizar los compiladores y herramientas de Intel que estan disponibles para gratuitamente para linux si no se hace uso comercial.

Durante los próximos post, iré escribiendo los experimentos que vaya haciendo asi como los resultados obtenidos.

A veces me da por participar en debates estériles simplemente porque me divierten. Aunque, ahora que me doy cuenta, que si me divierten, ya no son tan estériles. He leido cientos de hilos en listas de correo con los típicas comparaciones. Kde vs Gnome, C++ vs C, C++ vs Java, Gtk+ vs Qt, Linux vs Windows…

A día de hoy, o mejor dicho, a día de hace una semana, estaba totalmente convencido que el C++ era mejor que C. Sin embargo ahora no empiezo a tenerlo claro. Y es que, tengo un grave problema, cuanta más experiencia tengo, cuanto más tecnologías diferentes analizo, menos claras tengo las cosas cuando supuestamente debería ser lo contrario.

El caso, es que en estos momentos tengo un proyecto entre manos, para el que necesito crear algún tipo de interfaz gráfico para el usuario. Tenía que elegir unas librerías que me permitieran hacer esto. Mi elección de manera natural estaba clara, elegiría Qt porque es una librería probada sobradamente (KDE la usa en su escritorio) y que además tiene una magnifica documentación. Pero sobre todo, mi inclinación por usar Qt era porque estaban programadas en C++. Sin embargo, mientras he ido madurando la aplicación, he empezado a tener menos claro si debo poner mi aplicación con licencia GPL o no, y aunque no lo tengo decidido aún, con Qt no tengo elección, debe ser GPL. Es cierto que existe otra licencia comercial de Qt que no me obliga a ello, pero los costes no son asumibles por mí en este momento.

Buscando una alternativa, llegué de nuevo a Gtk+. Ya conocía Gtk+ pero la mantenía un poco en la distancia porque estaban realizadas en C, sin embargo tenía una gran ventaja para mi, su licencia era LGPL. Esta licencia me permite hacer con mi código lo que me venga en gana. Es decir, me dar libertad verdadera.

Sé que el tipo de licencia no debería ser un factor a tener muy en cuenta para decidir la tecnología que vas a utilizar para el desarrollo de una aplicación, sin embargo, en esta ocasión decidí echarle un vistazo. Para los que no lo sepan, Gtk+ es a Gnome, lo que Qt es a KDE. Por lo tanto, ni que decir tiene que Gtk+ también es una librería madura.

Gtk no pertenece a ninguna empresa. Qt en realidad, en su versión GPL tampoco, pero sí pertenece a medias entre Trolltech (recientemente adquirido por Nokia) y la Foundación KDE. Sea como sea, y aunque no dudo sobre las buenas intenciones de la Fundación KDE, Qt tiene dueños. Sin embargo Gtk+ no pertenece a nadie. Este es otro factor que me hizo pensar que merecía la pena echarle un ojo.

Sinceramente, aún estoy frotándome los ojos cuando miré el código por dentro. Es un código diseñado con un gusto exquisito, y con una filosofía orientada a objetos, que me gustaría ver en muchos de los programas desarrollados en C++. Ya sabéis la programación orientada a objetos no es una cuestión del lenguaje si no de diseño. Esto queda reflejado de forma patente en el código de las GTK+

Ahora bien, si está pensado con OOP en la cabeza, porqué no usar un lenguaje orientado a objetos. Según algunos de los desarrolladores de Gtk+ y según se puede leer en numerosos sitios de internet a poco que busques por internet, la mayoria de la gente que decide usar C sobre C++ es porque piensan que C++ te obliga a meter una serie de sobrecargas que no son necesarias, y que lleva a la gente que usa el lenguaje a hacer malos diseños. Tampoco les suele gustar mucho el uso de las STL o de las Boosts.

Está claro que, del mal diseño de una aplicación no tiene la culpa el lenguaje si no el que lo diseña. Pero… un lenguaje está claro que te condiciona la forma en la que enfocas un problema. Es más complicado hacer un buen programa en Perl que en Java.

En un hilo de discusión muy famoso, Linus dijo que había elegido C para el desarrollo de Git porque le parece mucha mejor opción. Y dijo también “si elegir C sirve para mantener apartado del proyecto a los programadores de C++, ya es una buena opcion”. Otra de las perlas que soltó fue, que “a cualquier persona que eliga C++ en vez de C para un proyecto, no la quería tener en su proyecto”. Sin duda alguna estas no son maneras de expresarse, pero más allá de esa questión, yo me pregunto ¿tendrá razón?.

Generalizar es un pecado mortal en estos contextos, pero, debido a la naturaleza del lenguaje, quien pensáis que por regla general conoce mejor el funcionamiento de los ordenadores, ¿un programador de C o uno de Java? y ¿entre uno de C y otro de C++?. A pesar de tirarme piedras sobre mi propio tejado, yo creo que por regla general el de C. Y aunque no estoy de acuerdo con Linus en las formas como lo dijo, empiezo a estar de acuerdo en el fondo de lo que dijo.

La gente suele decir, que con C++ se pueden abordar projectos más grandes que con C. Bueno, eso depende. Probablemente ninguna de estas personas haya trabajado en proyectos tan grande como pueden ser Gnome, Evolution o GiMP por poner algunos ejemplos. Sin embargo todos ellos están desarrollados en C. Lo que si te obliga C es a llevar una disciplina que sólo los buenos conocedores de como funciona el software son capaces de llevar a cabo. En C no hay recolección automática de basura, eso lo tiene que hacer el programador, en C++ ocurre lo mismo, pero… en C si te creas un polimorfismo sabes exactamente lo que estás haciendo porque lo hace el propio programador, mientras que en C++ muchos de los paradigmas de la programación orientada a objetos están ocultas en la sintaxis del programa, como debe ser en un lenguaje pensado para el desarrollo orientado a objetos. Lo mismo ocurre con el uso de strings, que en determindas ocasiones cuando son utilizadas en C++ para concatenar, requiere de muchos recursos para hacerlo y es extremadamente lento. Sin embargo, al estar todo oculto, es complicado de que un programador pueda detectarlo.

En definitiva, creo que, en los proyectos donde tan sólo se permite C, la probabilidad de que haya un mal programador es más baja, que en los proyectos donde se desarrolla en C++. También es cierto que un buen programador en C++ suele tener muy claros determinados conceptos sobre la programación orientada a objetos y sobre la programación genérica que no tiene por qué tener un programador en C.

Estoy convencido de que, entre los programadores de las Gtk+ hay muy pocos programadores malos a la vista del código y del diseño. Queda patente una gran formación en la ingeniería del software y unas ideas muy claras de como hacer las cosas bien.

Cuando me hice cargo del mantenimiento del paquete de software libre DDD. Pensé en ponerle un mejor entorno gráfico, ya que actualmente usa Motif que ya no se mantienen a buen ritmo, y pensé en reescribir algunas de las parte en C++. Sin embargo, ahora lo que vamos a hacer es dejar el C, no reescribir nada en C++ y meter Gtk en vez de Qt como tenía pensado. Ya veremos cual es la experiencia.

De hecho, después de ver como está hecho Gtk+, y como está organizado la plataforma de desarrollo de Gnome, me estoy replanteando muchas cosas que hasta hace una semana daba por hecho.

C++ es sin duda alguna mi lenguaje de programación favorito. Por un lado tengo acceso a bajo nivel, me da el control absoluto sobre el ordenador y al mismo tiempo me permite hacer software fácilmente mantenible. A me gusta decidir cuando liberar la memoria.

El ensamblador me permitiría quizas tener más control sobre el hardware y podría decirle a mi ordenador excatamente que hacer y como hacerlo. Sin embargo, veo muy complicado hacer un programa con 200.000 lineas y que fuese fácilmente mantenible en ensamblador. Ni que decir tiene, el problema que tendría la detección de errores y su resolución. Es por eso, por lo que C++ es mi lenguaje principal.

C++ sin embargo tenía un inconveniente si lo comparamos con otros lenguajes como Java. Java tiene dentro de su estandar una gran cantidad de librería que hacían la vida más fácil al programador. Sin embargo, esto está cambiando y con el nuevo estandar que se espera sea liberado este año, esto ya va a cambiar. El nuevo estandar C++09 constará de una gran cantidad de librerías estandar que harán la vida más fácil tambien al programador de C++.

Si quieres ver en que estado se encuentra el nuevo estandar , lo puedes hacer consultando un documento que se genera cada vez que se toman decisiones importantes en la evolución del nuevo estandar.

Si quieres estar al día de lo que se está haciendo al respecto, podeis ver este documento.

Algunos compiladores como g++ ya tienen implementada la TR2. Mucho antes que incluso Visual Studio 2008