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