Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
¿Por qué en C?

man ls's Diary
Por man ls
departamento preguntas vanas , Sección Diarios
Puesto a las Tue Jul 27th, 2004 at 02:23:39 AM CET
En esta época de tanto cavilar sobre lenguajes, a veces pienso en algunos proyectos (el kelmer o Linux propiamente dicho, GNOME) y por qué demonios estarán hechos en C. En estos tiempos.

 


Vamos a ver: ¿no funcionaría exactamente igual de bien un kernel en C++? ¿O por lo menos un driver? Entiendo que, si tienes que programar un driver binario, no puedas usar perl: de alguna manera tienes que escribir en ciertas direcciones de memoria directamente, enmascarar cosas en binario a toda leche, y tal. Y el ensamblador no mola. Pero que yo sepa, en C++ se puede hacer todo eso igual de bien.

Lo que ya me parece la repera es tener un entorno gráfico en C, como GNOME. Un tipo pequeñito que llevo dentro muy ignorante, pero que habla de todo a voces, me dice que algunos de los muchísimos problemas comentados magistralmente por Ed Hunter en esta noticia tienen su origen en el uso de C.

Y ya puestos, ¿por qué será que todos estos desarrollos de base (entornos gráficos, gestores de ventas) se hacen en C o C++? No vale sólo la velocidad: lenguajes funcionales como lisp u ocaml han demostrado ser casi tan rápidos como C, o más según a quién le preguntes. Como dice Paul Graham, autor del libro de lisp que me estoy tragando: es cierto que lisp se lleva fatal con C, pero no es menos cierto que C parece llevarse fatal con todo el mundo a la hora de llamar a otra gente. (Por cierto, el libro está en pdf aquí.)

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.

Todo esto es mera curiosidad, así que espero ansioso vuestras respuestas. Quedo a la espera de un kelmer en ocaml, atentamente, tal y tal y turbo-pascual.

< El canon. Objetivo: el Tribunal Constitucional (7 comments) | Documentacion? Que documentacion? (12 comments) >
Enlaces Relacionados
· escomposlinux.org
· tanto cavilar sobre lenguajes
· comentados magistralmente por Ed Hunter
· esta noticia
· casi tan rápidos como C
· a quién le preguntes
· Paul Graham
· aquí
· D
· More on man ls's Diary
· Also by man ls

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

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


    Puntualizando (4.50 / 2) (#6)
    por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 01:42:20 AM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    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

    C++ no es más lento que C: el coste de llamar a un método es exactamente el mismo que el de hacer una llamada a función. El coste de llamar a un método virtual es el mismo que llamar a una función a través de un puntero a función (un nivel de indirección más).

    Un característica de C++ es que todas las funcionalidades son "opcionales" (a diferencia de Objective C). Algunas pueden enlentecer o no. Las excepciones como las implementa gcc no tienen impacto en tiempo de ejecución, rtti y casts inteligentes siempre tendrán un coste... Pero puedes prescindir de ellas.

    Por otra parte, el compilador de C++ tiende a escupir más código porque en un programa de C++ normalmente se hacen más cosas que en C y eso se nota en peso y en velocidad, pero código en C que hiciera lo mismo que C++ incluye de serie sería igual de lento, o más aún porque el compilador de C++ al menos sabe cómo optimizar código orientado a objetos.

    Quiero decir: si quieres hacer programación orientada a objetos, C++ es posiblemente más rápido que C, y sin duda más cómodo. En otro caso, como C es casi un subconjunto de C++, puedes programar al estilo de C con tu compilador de C++ sin merma, como si fuera un compilador de áquel pero atiborrado de esteroides.

    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)

    Nop, el problema ha sido otro. A diferencia de C, C++ no ha tenido un ABI estandar hasta hace poco y antes cada compilador implementaba el que mejor le parecía, así que enlazar código generado por distintos compiladores era bastante complicado. De la misma manera, mientras que llamar a una función C está chupado desde cualquier lenguaje, hacer lo mismo con C++ te obligaba a conocer el ABI del compilador primero.

    En la versión 3.0 se decide reescribir entero el ABI de g++, al que no le pasaba nada más que no era estándar (como el de los otros compiladores), y adoptar el ABI oficial de reciente publicación.

    Y aquí empieza el lío: aparte del problema de ingeniería de tener que reescribir parte de g++, de los bugs que se pueden introducir en la implementación y de que el nuevo es incompatible con el viejo, resulta que en el propio ABI estándar había bugs y ambigüedades en algunos puntos que se dejan al buen criterio del que hace el compilador (con lo que enlazar código generado por distintos compiladores sólo está resuelto en teoría). Todo esto ha tenido que irse ajustando "en caliente", en versiones supuestamente estables.

    Hay muchas máquinas que se hicieron más o menos asi [monitor y interprete de BASIC de interfaz]. De hecho no se porqué no hizo eso Bill Gates

    En el PC original hay espacio para el mapa de memoria para un intérprete de BASIC. Si no puede arrancar de disco estaba previsto que saltase al intérprete como último recurso. Yo tengo un IBM XT que se comporta de esa manera.

    Supongo Microsoft se pondría en contacto con IBM en primer lugar para venderles el BASIC del PC. Luego vieron la oportunidad de meter la cabeza con el fiasco de DR y no sólo les vendieron el intérprete sino el sistema operativo.

    Hace un tiempo hablamos por aquí de QDOS y de su leyenda :-) en Historia de Microsoft.

    [ Padre ]


    Yo no lo tengo tan claro (none / 0) (#7)
    por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Jul 28th, 2004 at 10:43:38 AM CET
    (Información Usuario) http://speedball.servemp3.com

    No me he documentado para este hilo, sino que hablo más por lo que recuerdo de las discusiones al respecto de los problemas de gcc 2.7, egcs y gcc 2.9x. Sobre todo enmarcadas ante los problemas que se presentaban tanto con el kernel como con el C++.

    Creo recordar que uno de los problemas más importantes eran la perdida de rendimiento a la hora de enlazar de forma dinámica bibliotecas de clases, cosa que afectaba negativamente a KDE. Eso unido a que el soporte de C++ era muy incompleto, por lo que la libqt requería precompiladores extra (ahora no se como va la cosa: me pasé a GNOME).

    No he hablado del sistema de llamada a los métodos, sino el enlazado, el link. En el caso de enlazado estático el rendimiento es idéntico, ya que la faena de enlazado se produjo en lo que habitualmente llamamos compilación. Pero en el caso de usar enlazado dinámico, el enlazado se produce en tiempo de ejecución, con lo que en el caso de usar C++, al ser los objetos a enlazar más complejos que los objetos de C, el enlazador tarda más y por tanto el programa tarda más y nos aparece más lento.

    Ese problema tenía negros a los desarrolladores de KDE, y si miras en las listas de discusión de la época del KDE 1.x verás como muchos reniegan de Linux y del gcc.

    Se lleva desde los tiempos del egcs intentando lograr un ABI decente para C++ que ayudase al enlazador dinámico en su tarea. Ni lo consiguieron con el egcs, ni con el gcc 2.95, ni esta excesivamente claro si con los gcc 3.x lo han logrado, a pesar de su estandarización. Estandarización inexistente, ya que no podemos mezclar demasiado binario de diferentes versiones de compilador.

    Tal como ya he dicho, escribo de memoria basandome en las impresiones que me dejaron las discusiones y problemas que había hace cinco o seis años y posiblemente este muy equivocado.

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


    El enlazador y el montador de enlaces (none / 0) (#8)
    por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 11:59:35 AM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    Creo recordar que uno de los problemas más importantes eran la perdida de rendimiento a la hora de enlazar de forma dinámica bibliotecas de clases, cosa que afectaba negativamente a KDE.

    En realidad el problema al que te refieres, el del prelink ¿no?, era un problema del montador de enlaces. El ld.so sufría bastante para resolver todos los símbolos de una aplicación de KDE y especialmente el tiempo de arranque se disparaba. En realidad no es un problema de C++ (a una aplicación escrita en C con el mismo número de dependencias y resoluciones le pasaba lo mismo) pero sí que es verdad que se notaba más en C++ porque habitualmente en ese lenguaje se hacen más resoluciones (piensa en un método virtual en una biblioteca compartida, repetido en varias vtables y resuelto cada vez).

    El problema se resolvió modificando el enlazador (no confundas enlazador con montador de enlaces) de manera que organizase la información para que permitiera el cacheado de símbolos y simplificara el número de las secciones reloc. Consulta la documentación sobre la opción combreloc, que es activa por defecto.

    En resumen que, si es eso a lo que te refieres, desde luego no es/era un problema del ABI de C++.

    Ese problema tenía negros a los desarrolladores de KDE, y si miras en las listas de discusión de la época del KDE 1.x

    Bueno, creo que en tiempos del KDE 1.x el menor de los problemas de g++ era ese. El compilador de C++ de GNU fue francamente penoso hasta que se metió Redhat de por medio (tampoco es que hoy por hoy sea nada del otro jueves, pero esa es otra historia).

    De los bugs más escandalosos que recuerde de esa época estan el de las plantillas con parámetros, el del orden de los parámetros en los constructores (según como los ordenases podía funcionar o no :-D), etc. Además había dos ramas: la del egcs (bastante mejor) y la de gcc y lo que compilaba en la primera a veces (muchas) no lo hacía en la segunda, y por versiones eran incompatibles a nivel binario también.

    Una de las razones con más peso que hizo que la gente de Gnome escogiera C fue que, cuando empezaron, no había compilador ni medio decente de C++ que fuera libre. Pienso que viendo el panorama actual escoger C++ hubiera sido la decisión de futuro.

    [ Padre ]


    En eso estoy de acuerdo (none / 0) (#9)
    por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Jul 28th, 2004 at 01:29:11 PM CET
    (Información Usuario) http://speedball.servemp3.com

    Tengo claro que la razón por la que GTK+ y GNOME están programados en C es claramente por una razón histórica y no por una razón tecnológica del año 2004, y que seguramente resultaría más fácil programar GNOME usando C++.

    Pero de todas formas el problema que le encuentro a GNOME, en mi opinión, no es la selección del lenguaje de implementación, sino más bien de diseño. Tiene muchas tecnologías bonitas, pero no trabajan conjuntamente, y es que se nota que no tenían nada claro que es lo que querían hacer.

    Las incomodidades del C las deberían ver los que programan el GNOME en si mismo, pero si realmente GNOME llegase a ser independiente del lenguaje, las aplicaciones deberían poderse programar sin problemas usando C, C++, Objective-C, Perl, Python, Pascal, ADA, etc.

    Linux, glibc, XFree86, etc. están programados en C puro y duro pero uno puede desarrollar aplicaciones para Linux sin picar ni una sola línea de C. Lo mismo debería (y pretendían) suceder con el entorno de escritorio, sea GNOME, sea KDE, sea AfterStep...

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


    La independencia del lenguaje (none / 0) (#11)
    por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 04:33:27 PM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    Las incomodidades del C las deberían ver los que programan el GNOME en si mismo, pero si realmente GNOME llegase a ser independiente del lenguaje, las aplicaciones deberían poderse programar sin problemas usando C, C++, Objective-C, Perl, Python, Pascal, ADA, etc.

    Eso sería lo ideal pero en la práctica no funciona. El API C de Gnome no puede ser independiente del lenguaje.

    Primero porque los bindings y los wrappers no siempre están sincronizados con el api canónico C. Aunque hagamos los bindings de forma automática a partir de la última versión del api oficial hay lenguajes que necesitan más información de la que C necesita y de la que hay en las cabeceras, así que siempre habrá que hacer ajustes manualmente.

    Segundo porque C impone limitaciones a los bindings que no son evidentes a los programadores de otros lenguajes y que hacen que la integración con los mismos chirrie. Un par de ejemplos:

    Hasta hace una versión, el wrapper de C++ de Gnome y Gtk (que es fantástico, por cierto) obligaba a cazar las excepciones localmente o a no usarlas, porque si una excepción remontaba el stack podría darse el caso que estuviera apilada una función C del api nativo y sin información adicional para propagar la excepción (con fallo fatal como resultado).

    En Python, cuando subclasificas un control de Gnome o Gtk y la aplicación recibe un evento de él, ésta no recibe el objeto de la subclase que generó el evento como sería de esperar sino de su clase padre, sin posibilidad de hacer algo como un dynamic_cast<> en C++.

    Tercero porque los bindings sólo van en una dirección: si yo no quiero derivar mis clases con el api C sino comodamente desde C++ lo puedo hacer, pero mi amiguete que programa en Ruby no puede usar mis clases directamente ni yo las que escriba él extendiendo el api.

    Todas estas pegas son las que resuelve .NET sobre el papel. Con Mono el api sería el mismo para todos los lenguajes soportados. Las mismas posibilidades/limitaciones para todos, no habría problemas de sincronización y funcionaría "en ambas direcciones": lo que escribas en lenguaje1.NET yo podré usarlo en lenguaje2.NET directamente sin más, y viceversa.

    [ Padre ]


     
    Motivos de la elección de C (none / 0) (#10)
    por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Wed Jul 28th, 2004 at 04:09:11 PM CET
    (Información Usuario) http://www.escomposlinux.org/jcantero/

    Una de las razones con más peso que hizo que la gente de Gnome escogiera C fue que, cuando empezaron, no había compilador ni medio decente de C++ que fuera libre.
    Mi impresión es que la portabilidad a otros sistemas pesó mucho en la decisión de usar C. Al fin y al cabo, un compilador ANSI C es fácil de conseguir casi en cualquier plataformas. No tenéis más que fijaros en los gpointer, gint's y demás para ver por donde voy. Aunque unos cuantos libertonianos seguro que pueden contarnos fehacientemente de lo poco que ha valido eso.

    Lo de la portabilidad, por cierto, es una obsesión permanente del proyecto GNU. Por ahí es por donde le viene a GNOME (en mi opinión).

    --
    "Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
    [ Padre ]


    Un poco de todo (none / 0) (#12)
    por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 05:17:14 PM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    Cuando me refería a que lo eligieron porque había un compilador libre de C, gcc, debería haber añadido que además multiplataforma y ampliamente disponible.

    Supongo que en la elección de C pesaron varias cosas:

    Gtk+ es un api en C y si Gnome extiende Gtk+ a priori usar el mismo lenguaje parece la elección adecuada. No había ningún otro toolkit C++ "libre".

    Tradicionalmente la programación de interfaces gráficas en los Unix se ha hecho en C: en parte por la amplia difusión de Motif (que es C y es horrible) y en parte porque los compiladores de C++ eran una castaña. Había disponible un montón de mano de obra voluntaria si se escogía C. De la misma manera ya había mucho trabajo hecho en forma de aplicaciones C libres listas para ser "gnomificadas" e integradas en el escritorio (como xscreensaver, gestores de ventanas, etc).

    La posibilidad de hacer bindings: es mucho más fácil hacer un wrapper de C que de C++. La premisa de poder programar en varios lenguajes era prioritaria al principio, aunque al final en eso se hayan quedado a medio camino.

    Etc, etc. No se consideró un factor sólo pero sí parece a toro pasado que la decisión fue equivocada. Quizás se arregle con Mono si al final Gnome lo adopta.

    [ Padre ]


     
    Curioso (none / 0) (#1)
    por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Tue Jul 27th, 2004 at 10:37:57 AM CET
    (Información Usuario) http://www.escomposlinux.org/jcantero/

    Curioso que digas que C se lleva mal con todos los lenguajes. Precisamente había leído/oído que una de los principales argumentos para usar C en GNOME era su capacidad para luego enlazar con otros lenguajes mediante bindings.

    Porque hacer programación OO con un lenguaje como C (como han hecho en GTK+/GNOME) deja un código bastante enrevesado, y es lógico que uno se pregunte por qué no emplear entonces un lenguaje que de un auténtico soporte a ello.

    Siendo malvados, podríamos decir que incluso Icaza ha salido corriendo y se ha abrazado a su Mono/C#/GTK#, entendiendo que la programación de aplicaciones gráficas con lenguajes como C, no iba a ir a ninguna parte.

    En fin, hay mucha incertidumbre en el panorama que se extiende ante nosotros (tiempos interesantes) y no se sabe qué derroteros va a tomar la cosa.

    --
    "Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson


    pobre Icaza (none / 0) (#2)
    por man ls a las Tue Jul 27th, 2004 at 11:46:17 AM CET
    (Información Usuario)

    Curioso que digas que C se lleva mal con todos los lenguajes. Precisamente había leído/oído que una de los principales argumentos para usar C en GNOME era su capacidad para luego enlazar con otros lenguajes mediante bindings.
    Eso sí (excepto, según parece por la cita de Paul Graham, con Lisp). Me refiero justo a lo contrario: que es difícil hacer bindings de otros lenguajes para usar en C. Llamar código Pascal, digamos, desde C.
    Porque hacer programación OO con un lenguaje como C (como han hecho en GTK+/GNOME) deja un código bastante enrevesado, y es lógico que uno se pregunte por qué no emplear entonces un lenguaje que de un auténtico soporte a ello.
    Ésta es la parte que no entiendo: ¿no es igual de fácil hacer los bindings con C++? Vamos, no exportar la creación de objetos y todo eso, pero sí que puedes encapsular las funciones en unas cuantas llamadas estáticas y tal, ¿no?
    Siendo malvados, podríamos decir que incluso Icaza ha salido corriendo y se ha abrazado a su Mono/C#/GTK#, entendiendo que la programación de aplicaciones gráficas con lenguajes como C, no iba a ir a ninguna parte.
    Je, ahora entiendo muchas cosas. Pobre diablo, entre la espada y la pared. O, como dicen los yanquis, between a rock and a hard place: entre una piedra y un sitio duro. Hum, vaya expresión más absurda tienen los yanquis.

    [ Padre ]


     
    El dilema de Gnome (none / 0) (#5)
    por melenas a las Wed Jul 28th, 2004 at 12:15:39 AM CET
    (Información Usuario)

    Siendo malvados, podríamos decir que incluso Icaza ha salido corriendo y se ha abrazado a su Mono/C#/GTK#, entendiendo que la programación de aplicaciones gráficas con lenguajes como C, no iba a ir a ninguna parte.

    Esto podría dar lugar a un interesante debate, Mono vs. Java y es que creo que la gente del core de Gnome, se han dado cuenta de que se tienen que pasar a un lenguaje POO, pero parece que no saben a cual:

    Por un lado está Java, arropada por Sun, empresa que está apoyando totalmente a Gnome, pero sin embargo tienen problemas debido a su "presunta" falta de libertad, no voy a entrar en la discusión de si es libre o no, pero decir que mucha gente que apoya a Gnome (que son normalmente muy GNUistas) no les gusta Java.

    Por el otro está Mono, libre gracias a que se apoya en unos estandares públicos pero parece ser que cualquier patente que aplicase Microsoft les podría dejar con el curo al aire, de nuevo tenemos a los Gnomeros más gnuistas que no verían con buenos ojos que su escritorio estuviera basado en un lenguaje creado por el maligno.

    No entiendo mucho de estos asuntos, y puede que me haya equivocado en algo, pero creo que los derroteros van por ahí.


    FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
    [ Padre ]


     
    ¿Por qué no? (none / 0) (#3)
    por Logann a las Tue Jul 27th, 2004 at 09:53:50 PM CET
    (Información Usuario)

    Podriamos plantear la duda de esta forma, por qué no en C?
    Pues supongo que depende del caso concreto, por ejemplo en un driver gráfico de la VBE, puedo elegir entre C i C++.

    1. ¿Utilizare POO?, ¿que ventajas saco de POO en un driver gràfico?
    2. Si no utilizo POO ¿que ventajas tengo si utilizo C++?

    Y este es un caso fàcil, no me imagino decidir si escribir el nucleo de SO en C o C++ ._.



     
    No se que poner aqui (none / 0) (#13)
    por thuban a las Wed Jul 28th, 2004 at 06:43:34 PM CET
    (Información Usuario)

    De verdad que es un problema elegir el titulo...

    Tal vez no se use C++ ni ningun lenguaje moderno orientado a objetos porque los lenguajes orientados a objetos no sean adecuados para hacer un kernel.

    No es una afirmacion si no una suposicion, aunque pueda leerse de otra manera.

    Veamos. Los lenguajes orientados a objetos son adecuados cuando en el analisis puedes hacer una jerarquia de clases, cuando hay una mama que tiene unas cuantas hijas que se parecen mucho a mama paro que no son exactamente iguales. Entonces la POO te viene de miedo porque creas una variable de tipo Mama y la puedes asignar a cualquiera de sus hijas.

    ¿Al diseñar un kernel se da esa necesidad de diseño? Si. Podemos meter un algoritmo basico de planificacion de procesos dentro de una ProcPlanifMami y despues ponernos a escribir varios PorcPlanifHijo1, PorcPlanifHijo2, PorcPlanifHijo3... permitir a root o al mismisimo usuario cual prefiere aplicar (cad uno dentro de su espacio, claro) y aplicar el que elija.

    Estaria bien, pero ¿cuantos sistemas operativos lo permiten realmente? Uno o ninguno. En realidad el SO viene con un algoritmo y te aguantas. Como mucho se puede variar (y lo estoy aventurando) en la instalacion o se podria modificar si te permiten compilarlo. Pero una vez instalado, te aguantas con el que viene.

    Y asi, con todos los kernels que lo tienen todo dentro. Los kernels que estan hechos de modulos diferentes para gestionar cosas diferentes, como dispositivos diferentes, sistemas de archivos y otras cositas de esas que hay en los ordenadores, cargan para hacer el trabajo todos los modulos que hagan falta, pero estos modulos son cosas diferentes al kernel. Estan muy relacionados pero no son el kernel.

    El kernel en si no requiere hacer un diseño orientado a objetos, asi que por pequeña que sea la sobrecarga del sistema, por pequeño que sea el primer inconveniente que aparezca, se desestima y se va al viejo y conocido C que funciona bien y es *suficiente* para hacer el trabajo. Y en algunos sitios, incluso ensamblador.

    Otra cosa es el asunto de los entornos graficos, en los que ni entro ni salgo.



    No me convences :) (none / 0) (#14)
    por man ls a las Wed Jul 28th, 2004 at 08:07:21 PM CET
    (Información Usuario)

    El asunto de la herencia no me parece lo más importante de la orientación a objetos. Puedes hacer que nadie herede de tus objetos y listo.

    Lo que veo es que los desarrolladores del kelmer se pasan la vida inventando pseudo-objetos para gestionar objetos, de los que encima hay que contar las referencias (otra cosa que en C++ se hace de manera más natural). Eso por no hablar de los incomodísimos nombres de las funciones, lógico ya que en C no hay espacios de nombres.

    Me da la impresión de que están siendo constreñidos por el lenguaje que usan. Vamos, que las herramientas se les quedan pequeñas. ¿No os parece?

    [ Padre ]


     
    OOP en el Kernel (none / 0) (#16)
    por ridiculum a las Thu Jul 29th, 2004 at 12:50:00 AM CET
    (Información Usuario)

    El kernel de Linux, y el de los BSD tienen unas partes bastante importantes que se pueden modelar como OO. Sin ir mas lejos, el VFS es OO. Tienes un "objeto" generico que representa un sistema de archivos, con un buen puñado de funciones virtuales (implementadas como punteros a funcion) y luego, cada sistema de archivos real "hereda" de ese objeto generico y proporciona la implementacion de esas funciones virtuales.
    Ese es el primer susbsitema que se me viene a la cabeza que use OO, pero seguramente los drivers de los dispositivos se puedan generalizar de ese modo, a parte de los kobjects ya mencionados.

    Sobre la variedad de planificadores, si nos centramos en los planificadores de I/O, en linux puedes elegir entre 3, sino recuerdo mal (rama 2.6): Anticipatory, Deadline, CFQ, asi que bien podria usarse herencia, no?. Respecto de los planificadores de CPU, cero que ahora mismo solo hay uno, pero con diferentes politicas: Round Robin, FIFO, Other (se puede cambiar la politica con sched_setscheduler() y Other es la politica que siguen los procesos por omision).

    Luego nos podriamos ir a las diferentes disciplinas de colas que se usan para el QoS, que bien podria entenderse como un modelo de herencia, al igual que los casos anteriores.

    [ Padre ]


     
    El planificador de tareas configurable (none / 0) (#17)
    por jorginius ("jorginius" en Google Mail) a las Thu Jul 29th, 2004 at 01:01:59 AM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    Estaría bien, pero ¿cuantos sistemas operativos lo permiten realmente [cambiar el planificador]? Uno o ninguno. En realidad el SO viene con un algoritmo y te aguantas.

    Muchos por no decir todos. Incluso en Linux puedes escoger para una tarea un algoritmo u otro del planificador con la llamada de sistema sched_setscheduler(2) o sencillamente en función de la prioridad, en sistemas multiprocesador el algoritmo de planificación apenas cambia (pero lo hace) y en un Mosix es distinto.

    En general un microkernel da soporte para el diagrama de estados pero lo que es el planificador puede correr en espacio de usuario. Esto por ejemplo lo puedes ver en L4, donde puedes usar el tuyo si no te apetece usar el de por defecto en cualquier momento y desde espacio de usuario.

    Los kernels que estan hechos de modulos diferentes para gestionar cosas diferentes [...] pero estos modulos son cosas diferentes al kernel. Estan muy relacionados pero no son el kernel.

    Si lo dices por Linux, un módulo comparte el espacio de direccionamiento del kernel y a todo los efectos es lo mismo que él. Desde un módulo en teoría sólo deberías acceder a los símbolos públicos que cada módulo y el kernel exportan, con sus chequeos de licencia y demás, pero nada te impide leer/escribir en cualquier otra dirección de memoria. Fijaté que el kernel exporta sus símbolos de la misma manera que todos los módulos. En muchos sentidos se comporta bastante como un módulo más.

    ... Y ya que hablamos de planificadores, no me parece tan descabellado tener un planificador de tareas modular haciendo relativamente pocos cambios en el kernel.

    El kernel en si no requiere hacer un diseño orientado a objetos, asi que por pequeña que sea la sobrecarga del sistema, por pequeño que sea el primer inconveniente que aparezca, se desestima y se va al viejo y conocido C que funciona bien y es *suficiente*

    El kernel de NT está orientado a objetos, a pesar de estar escrito en C. En el de BeOS es aún más claro la orientación al estar escrito en C++. En el kernel de Linux hay un montón de abstracciones que recuerdan a clases y objetos (como la capa de VFS o la estructura de los drivers del framebuffer). La orientación a objetos no tiene porque no pegar bien dentro del kernel.

    En el caso de Linux, del C y de cómo está escrito supongo que hay que pensar en quién lo escribió y con qué herramientas: Linus después de todo era un estudiante en rodaje, así que siguió el manual y diseñó el kernel semejante al del UNIX clasico, opción más sencilla que inventar un innovador nuevo diseño microkernel orientado a objetos... Y para programarlo usando las herramientas de Gnu que usaba habitualmente tenía sólo un compilador de C, porque si el compilador de C++ apestaba en 1993 un año antes debía ser para echarse a llorar (todo esto suponiendo que Linus estuviera lo bastante familiarizado con el "novedoso" C++ como para considerar usarlo en el kernel).

    En fin, sea como sea lo que sí es cierto es que reescribirse ahora mismo el kernel en C++ es un trabajo enorme, no digo ya si además hacemos reingeinería para que quede más OO... Y tampoco es que las mejoras fueran a ser brutales, si es que hubiera alguna.

    [ Padre ]


    Para man ls, ridiculum y jorginius (none / 0) (#18)
    por thuban a las Thu Jul 29th, 2004 at 10:20:59 AM CET
    (Información Usuario)

    Es que no me apetece escribir lo mismo tres veces...

    Cuando escribia eso estaba pensando que en el caso del sistema de archivos la OO si tenia sentido, pero lo tiene a nivel de diseño en una pizarra: tenemos un sistema de ficheros generico con unas cuantas operaciones y un monton de hijos que heredan de el y uno implementa reiser, otro fat que a su vez es mama de fat16, fat32... En la pizarra queda bien y la OO se adapta muy bien al caso. Pero se me ocurren dos cosas:

    - ahora eso se hace con C mondo y lirondo y funciona, asi que no hace tanta falta, y alguna ventaja tendra...

    - si se hace con OO, no se van a conformar con hacer esa jerarquia de clases. Haran un objeto Fichero, un objeto Atributo, un objeto Informacion que diga lo que puede hacer el "driver" en cuestion... Vamos, que va a quedar precioso en la pizarra pero va a ser pesadisimo (como el Swing de Java, en otro orden de cosas)

    Tambien se puede hacer un diseño OO con pocas clases, pero entonces ¿para que OO? ¿Esta bien hacer un diseño OO "a medias"? Incluso se podria programar en C pero compilando con C++, de manera que se podrian declarar las variables cerca de donde se usan y hacer mas legible el codigo, pero eso no es POO.

    Y con todo lo demas, parecido.

    No se trata de hacer un sistema que sea teoricamente correcto si no de hacer un sistema que funcione y ademas que lo haga muy bien, porque si el kernel no funciona bien, nada funciona bien.

    La POO tiene muchas ventajas cuando se trata de hacer el codigo mantenible, ampliable y todo eso siempre que te pases una buena temporada planificandolo todo antes de tirar la primnera linea, pero en el kernel del sistema la facilidad para meter modificaciones o para ampliar el sistema pasa a ser una cuestion secundaria frente al rendimiento y el ahorro de recursos.

    No digo que no se puedan modelar cosas del kernel con OO, digo que no es necesario modelarlas asi para que funcione.

    PD: No sabia lo de la funcion esa, pero me pregunto eso se puede usar en la practica para cambiar EN VUELO la politica de planificacion de un proceso (¿solo de un proceso?) y tener varios algoritmos funcionando al mismo tiempo en el sistema. Me refiero a que si escribo un comando que reciba por parametro un PID, lo pongo en /usr/bin con el bit de "root el Destructor" o en el sudoers para que cualquiera lo ejecute, ¿podria tener varias politicas funcionando al mismo tiempo?

    PD2: A lo que me referia con lo de los modulos es que los modulos pueden estar escritos con cualquier cosa que te funcione porque al fin y al cabo, no son el kernel. Si cargas un modulo pesado escrito en Java compilado (es un ejemplo extremo) es cosa tuya. Los que han hecho el kernel no seran culpables de que tu ordenador vaya despacio. Pero si es culpa suya si el kernel mismo va despacio.

    PD3: Si es muy probable que el kernel este escrito en C y sea monolitico porque Linus no supiera hacerlo mejor siendo estudiante. De hecho soy de los que piensan que Linux se le fue a Linus de las manos y que el debio ser de los primeros sorprendidos con el exito que ha tenido.

    PD4: Parece que ultimamente en Libertonia hay comentarios...

    [ Padre ]


    Los libros no muerden :-) (none / 0) (#19)
    por jorginius ("jorginius" en Google Mail) a las Thu Jul 29th, 2004 at 01:04:48 PM CET
    (Información Usuario) http://www.rodriguezmoreno.com

    Cuando escribia eso estaba pensando que en el caso del sistema de archivos la OO si tenia sentido [...] Pero se me ocurren dos cosas:

    - ahora eso se hace con C mondo y lirondo y funciona, asi que no hace tanta falta, y alguna ventaja tendra...


    Ahora está escrito en C, pero es orientado a objetos. La capa VFS de Linux es más o menos como la describes desde que se introdujo en la versión 2.0, y hay más ejemplos de POO en Linux.

    - si se hace con OO, no se van a conformar con hacer esa jerarquia de clases. Harán un objeto [tal y cual que haga pascual y...]

    Si quieres ver como se hace realmente, consulta el diseño de otros sistema donde la POO se haya considerado desde el principio. Por ejemplo NT, donde "todo" lo que maneja el kernel es o un objeto dispatcher o un objeto de control y donde la jerarquía de herencia se amplía capa a capa (la clase thread de usuario hereda de thread del kernel y así) o BeOS o QNX o cualquer sistema operativo moderno en realidad.

    No sabia lo de la funcion esa, pero me pregunto eso se puede usar en la practica para cambiar EN VUELO la politica de planificacion de un proceso [...] ¿podria tener varias politicas funcionando al mismo tiempo?

    Sí. Las tareas de tiempo compartido no se planifican igual que las tareas de tiempo real (blando) y puedes tener de ambos tipos (diferentes colas con diferentes políticas) en un sistema. Consulta las páginas man.

    Lo que no puedes hacer en Linux es introducir nuevas políticas en caliente, a menos que añadieses soporte modular para planificadores de tareas. Debes escoger entre las que hay. En frío puedes parchear con varios planificadores alternativos bastante populares. Otros sistemas dan más opciones o incluso permiten planificadores en espacio de usuario.

    PD2: A lo que me referia con lo de los modulos es que los modulos pueden estar escritos con cualquier cosa que te funcione porque al fin y al cabo, no son el kernel. Si cargas un modulo pesado escrito en Java compilado (es un ejemplo extremo) es cosa tuya.

    Te equivocas: los módulos son núcleo. Cuando lo cargas, el código del módulo es insertado en alguna parte del espacio de direccionamiento del kernel y corre desde allí, en modo privilegiado y demás, exáctamente igual que lo hace el código que no es modular. Deberías repasar cómo funciona.

    Desde luego no podrías programar ningún módulo en Java a menos que incluyeses de alguna forma la JVM dentro del kernel. Lo mismo si quieres usar una biblioteca de usuario como glib o pcre. No tienes más libertad para programarlos que la que tienes para escribir otro código del kernel.

    Para que fuera como tu dices, Linux debería ser micronúcleo :-D

    PD4: Parece que ultimamente en Libertonia hay comentarios...

    Mejor que estudiar...

    [ Padre ]


     
    Hagamos un microkernel (none / 0) (#15)
    por TSDgeos a las Thu Jul 29th, 2004 at 12:45:40 AM CET
    (Información Usuario)

    Ya se que linux no es un microkernel y también se que los microkernels no estan de moda, pero si pensais detenidamente los microkernels encajan completamente en la filosofia OO, pequeños trozos de sistema operativo que son autocontenidos y se comunican los unos con los otros... quizá los microkernels fracasaron pq no estan escritos con un lenguaje OO ... (lo dudo pero bueno :D)



     
    ¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
    Ver: Modo: Orden:

    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