Barrapunto

Tu opinion me parece interesante, coherente y bien pensada.

Pero dejame apuntarte que no estupido dejar la cuestion del tamaño y velocidad a segundo plano a favor de la extensibilidad, mantenimiento y rehutilización. Por poner un ejemplo, no me importa perder un segundo en el inicio cargando plugins, teniendo en cuenta que en los ordenadores de mañana ese segundo desaparecera pero los plugins (es decir, su arquitectura) seguira ahi. Un ejemplo más claro es la arquitectura de componentes, un tanto pesado pero impresionante.

Esta claro que todo lo que puedes hacer en C++ puedes hacerlo en C, Pascal, Python o lo que quieras, ya que son lenguajes completos. Pero C++ creo que da un balance optimo entre velocidad y abstracción. Tambien es cierto que C++ es un lenguaje complejo, pero puedes evitar esa complicación con un diseño adecuado (como el de KDE, donde todo encaja en su sitio y las cosas salen solas.

Eficiente en el consumo de recursos. ¿Alguien sabe hasta donde puede Gtk+ ser más eficiente que Qt?. Tengo que decir que al final elegí Gtk+, porque es un toolkit bastante eficiente, y porque su lenguaje nativo es C, con lo cuál se eliminan todos las estructuras intermedias que mantienen en memoria los programas escritos en C++.

Lamento mucho corregirte, pero GTK+ implementa objetos en C, que invariablemente implica todas esas estructuras intermedias en memoria que comentas en C++.

No se hasta que punto GTK+ es más eficiente que Qt, al menos por el aspecto que comentas.

C, C++, eficiencia, GTK+, ... pues usa D [digitalmars.com].

Hay versiones Linux y Windows, tiene un foro muy activo, el front-end es libre y se está portando para funcionar con GCC (aunque el compilador de Walter deja al gcc por los suelos).

Es un lenguaje en el que ya he escrito un par de programillas, y no le veo ninguna desventaja: sería como tener todo lo de C, C++, Java y Python en un lenguaje ...

Saludos

Si no usas la STL y otras basuras y sabes lo que haces, el C++ puede ser MAS eficiente (o igual, pero nunca menos) en velocidad y gasto de memoria que el C, para algoritmos complejos equivalentes y con las mismas salvaguardias.

¿Cómo lo sé? Hace 20 años que programo profesionalmente y tengo mucha experiencia con el ensamblador, ya que antiguamente era casi el único lenguaje que utilizaba. De vez en cuando examino el código que generan los compiladores para ver cómo traducen algunas partes críticas de mi trabajo o el de mi equipo, y ahí es dónde lo veo.

NOTA: He llamado basura a la STL porque así me parecen las implementaciones que he visto. Tal vez se puedan mejorar, pero, además, la especificación usual de la STL me parece un mal ejemplo de diseño, aunque contiene unas pocas buenas ideas.

C es un lenguaje totalmente imperativo, basado en las órdenes o algoritmos que utilizas; estas órdenes se apoyan o usan ciertas estructuras de datos que pueden ser incluso objetos, pero el centro del programa, el principal método de desarrollo, el corazón del programa sigue siendo el algoritmo. C++ es, sin embargo, un lenguaje orientado a objetos, donde la parte principal del programa, el verdadero enfoque que realiza el programador no es lo que el programa tiene que hacer, sino las estructuras que utilizan; estas estructruas (los objetos) se apoyan en órdenes y algoritmos, pero la base aquí son las estructuras de datos.

Por tanto, al pertenecer a distintos paradigmas, son útiles para uno determinado tipo de tareas. Por ejemplo, si quieres programar un driver no tiene mucho sentido utilizar clases y cosas por el estilo, pero para un programa de alto nivel como OpenOffice.org [openoffice.org] la orientación a objetos se hace tremendamente útil.

Es cierto que ambos pueden hacer lo mismo, de hecho, todo lenguaje capaz de implementar la Máquina de Turing (bendito Alan Turing [turing.org.uk]) tiene plena capacidad para hacer todo lo computable. Por poner un ejemplo, un lenguaje de tipo declarativo que implemente la Máquina de Turing, como ProLog [inria.fr], también es capaz de hacer lo mismo que C y C++, pero estaremos de acuerdo que no tiene mucho sentido programar KDE usando ProLog...