Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
Mis humildes respuestas (4.66 / 3) (#4)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Tue Jul 27th, 2004 at 09:55:35 PM CET
(Información Usuario) http://speedball.servemp3.com

Tengo opiniones más o menos deformadas de todos los puntos, así que me voy a poner a la tarea ;)

  • ¿no funcionaría exactamente igual de bien un kernel en C++?


  • Se puede escribir el kernel en C++, incluso hay algún sistema operativo básicamente escrito todo él en dicho lenguaje.

    El primer problema es de rendimiento. El C++ es claramente más lento que el C debido a que el mecanismo de enlazado de clases es más complejo que el de simples funciones. El segundo problema tiene el mismo origen: al ser complicado el enlazado de clases, ha costado dios y ayuda a gcc crear un ABI (interficie binaria para aplicaciones) claro y coherente para C++, con lo que hasta la versión 3.0 no tenía un soporte decente de C++.

    Además, en el caso de Linux, al querer ser algo similar a UNIX, tiene un diseño claramente dirigido a C. Un kernel diseñado para C++ sería algo muy distinto a un kernel tradicional UNIX.

  • ¿O por lo menos un driver?


  • El driver debe enlazarse con el código C del kernel, con lo que volvemos a encontrarnos con el problema del ABI.

    Claro que con otros diseños de kernel eso no tiene porque pasar. Por ejemplo en el caso del Hurd los drivers van en espacio de usuario y pueden usar no sólo llamadas al kernel, sino cualquier librería. En Hurd se podría escribir (en teoría) el driver en cualquier lenguaje, incluso en Perl. Hurd no es un kernel estilo UNIX, de hecho tiene una capa de emulación POSIX por encima.

    Por otro lado no siempre se escriben kernels en C/C++ y similares. Nada impide programarlos en Pascal, Modula-2, Java... ¿Java? pues si, si consideras la JVM una arquitectura igual que lo pueda ser i386, y de hecho existe un JavaOS. Evidentemente esta pensado para ese aborto (por no llegar a ver la luz) que fueron los NC y para esa idea de Sun de micros que directamente ejecuten bytecode Java (evidentemente para NC y cosas similares).

    El éxito de C es que se acerca mucho al ensamblador siendo de alto nivel, esta muy estandarizado y hay muchos programadores entrenados en él. La ventaja de C++ es que se parece mucho al C.

  • Lo que ya me parece la repera es tener un entorno gráfico en C, como GNOME [...] algunos de los muchísimos problemas tienen su origen en el uso de C


  • No estoy deacuerdo en absoluto. Primero porque las mismas razones que recomiendan usar C en el kernel siguen siendo válidas: cuando se empezo GNOME el gcc no daba la talla con C++, y de eso saben mucho los desarrolladores de KDE.

    La orientación a objetos es una metodología de programación, igual que lo pueda ser la programación estructurada. Usar clases no hace que el programa sea orientado a objetos. Es cierto que es mucho más fácil hacer programas orientados a objetos usando C++ que C porque queda todo mucho más natural. El problema de GNOME no es que no use objetos, el problema en mi opinión es que no se han pensado demasiado bien la clasificación de esos objetos y que la cosa ha ido creciendo de forma caótica.

    Intentaré explicarlo: no han creado una clase fichero para encapsular el tratamiento de los ficheros desde un origen, sino que se han quedado con las utilidades que ya daba gtk+, que básicamente se diseñaron para que GIMP pudiese leer y guardar imágenes. Luego se han dado cuenta que las aplicaciones del escritorio tratan con ficheros, y que lo que da el GTK+ para el GIMP puede valer, pero para un escritorio "moderno"... así que se han puesto como locos a escribir unas clases megachulis de ficheros, lo han bautizado con el rimbonbante nombre de GNOME Virtual File System y se han quedado tan anchos. Pero claro, todo todito todo lo que había antes, ese mogollón de clases megachulis de la muerte que tarde o temprano utilizan un fichero están programadas usando las primitivas de ficheros de GTK+. Esta chapuza es de diseño, y se puede obtener exáctamente igual programando en C, en C++, en Java o en Python.

    ¿Como quieren arreglar el problema los chicos de GNOME? pues me temo que cagandola otra vez. En vez de rediseñar las puñeteras clases para que sean coherentes, quieren modificar las primitivas de GTK+ para que sean más vistosas. Si que el usuario verá una ventana de selección de fichero más aparente y espero que más cómoda (no hace falta gran cosa para lograrlo), pero lo lógico sería hacer que todas las clases que usan ficheros utilicen los procedimientos ofrecidos por GNOME-VFS, y así, por arte de magia potagia, no sólo podremos acceder a ficheros de diferentes medios (locales, compartidos, http, ftp...) desde el menú Archivo de las aplicaciones, sino que incluso las clases internas podrán acceder a esos ficheros sin que haga falta que el programa primero tenga que hacer una copia local en el tmp.

  • ¿por qué será que todos estos desarrollos de base (entornos gráficos, gestores de ventas) se hacen en C o C++?


  • Evidentemente no es sólo la velocidad, también esta la facilidad. Si las llamadas básicas del sistema (en el caso que nos ocupa, glibc y xlib) estan escritas en C, lo más fácil para interactuar con ellas es usar C. Paul Graham puede tener razón, pero como resulta que la base del sistema operativo esta escrita en C, todos los demás lenguajes se han visto obligados a encontrar algún método para acceder a código C de una forma rápida y eficiente. Esta perfectamente documentado cómo hacerlo y muy estudiado qué métodos son los más eficientes, con lo que resulta casi un problema de libro hacer que cualquier lenguaje pueda comunicarse con C.

    Una estúpida idea que me ronda por la cabeza tras cierto número de cervezas es crear un sistema operativo para 8086 basado en Python. De lo que se trata es de reprogramar el interprete de Python para que sólo utilice la BIOS original del PC y escribir en Python una interficie de usuario estilo a la de TurboPascal 4.0. Coger una máquina del tiempo y enseñarsela a IBM diez minutos antes de que Bill Gates les llame por teléfono :P. Evidentemente es absurdo: no hay máquinas del tiempo y meter un interprete Python en un 8086 hoy día no sirve para nada, pero tecnológicamente se puede hacer, y no se diferencia demasiado de lo que es el JavaOS o el proyecto Inferno. Hay muchas máquinas que se hicieron más o menos así, pero usando BASIC normalmente (pienso por ejemplo en el Sinclair QL y otras máquinas de la misma época que usaban M68K). De hecho no se porqué no hizo eso Bill Gates, supongo que porque le resultaba más barato comprar QDOS por $50000.

  • No sé, luego la gente se queja bastante de C++. Tanto que hasta han creado varias alternativas: Objective-C, Java, D (no, no es un chiste: es un lenguaje). Y de C no digamos; pero luego siempre se vuelve a ellos.


  • Creo que en realidad C++ y Objective-C se desarrollaron más o menos en paralelo y són dos aproximaciones diferentes a los objetos. Objective-C es mucho más canonica, y tiene una herencia clara de Smalltalk. C++ parece ser que ha ido un poco más a salto de mata. Digamos que C++ es C con objetos y Objective-C un lenguaje compilable orientado a objetos sintácticamente similar a C. Java sigue la idea de Objective-C, pero más o menos así: cogemos Smalltalk y le metemos la sintáxis del C++, ¡ah si!, y nos cargamos el browser de clases para que la máquina virtual quepa en una lavadora. Algún día me gustaría saber para qué coño querían meter los de Sun una JVM en una lavadora, pero quién dice lavadora dice teléfono móvil, navegador web, servidor de aplicaciones, etc.

    Básicamente Java es una reimplementación de Smalltalk para los programadores de C++ ;^)

    Speedball la banda de heavy más chunga
    Ven al Helvete Metal Bar


    Others have rated this comment as follows:
    gonzotba 5
    pbenavent 5
    thibaut 4

    ¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
    Ver: Modo: Orden:
    Menu
    · crear cuenta
    · FAQ
    · búsqueda
    · Fuentes de Noticias

    Login
    Nueva cuenta
    Usuario:
    Contraseña:

    ecol Logo Powered by Scoop
    Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
    Los comentarios son propiedad del que los escribe.
    Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
    El Resto © 2002 Escomposlinux.org y aledaños.

    Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

    El proyecto escomposlinux.org está dedicado a la memoria de tas

    crear cuenta | faq | búsqueda