HispaMSX

RE: [hispamsx] El tono de mis mensajes

2000-03-14 10:54:00


Hola!

    Por otra parte, hacer afirmaciones como
    > - El software de UNIX se compila de forma transparente entre
plataformas,
    > gracias a un compilador C standard (egcs/gcc).

    es faltar a la verdad de una forma bastante burda... me tiro todo el día
programando sobre Solaris, System V y Linux, y todas las cabeceras llevan
'tropecientas' condiciones, preguntando por etiquetas de compilación para
cada kernel... claro!! así si es estandar y portable...


Hombre en parte tienes razon, pero no totalmente, por ejemplo yo pude
compilar el fuente del fmsx para linux, y solo tuve que cambiar la
definicion para el sonido (que esto no es estandar en UNIX, ya que a un
sistema como UNIX le importa una mierda el sonido)


    Decir que todos los 'kernel' de Unix son iguales y que se "compila de
forma transparente", es como decir que todos los coches llevan los mismos
modelos de tornillos... ve con un BMW a la Seat, y le pides recambios....


Ahi llevas toda la razon, porque los kernels de Unix se diferencian entre
si como minimo en un 20% (suponiendo que hablemos de sistemas basados en
un UNIX como el System V, porque como supongo que sabra la mayoria de la
gente, LINUX es totalmente diferente de UNIX.


    E insisto: el C no es el estádar... es el C++. Y alguno dirá: "... hay
que saber C para C++". Sí; pero lo que se reutilizan son clases e
interfaces, no punteros....

 ARGHH!!!!, muera el C++, todo C puro y duro. Ya en serio yo apoyo el C
por la simple razon de que es un lenguaje intermedio, y con un poco de
conocimiento interno del compilador puedes llegar a saber exactamente
(instruccion a instruccion) como sera el codigo generado, ademas lo bueno 
de C es el uso de los punteros (alguien se imagina como seria programar
en ensamblador sin el uso de los punteros), por lo que C puede llegar a
ser un macro-macroensamblador cojonodo. C++ es una chapuza, las clases no
son mas que estructuras (si a una clase le haces un casting a struct,
puedes tocar la parte privada).


    Y, por eso, los usuarios de Unix dejan de utilizar C, y pasar a otros
lenguajes (Tcl, Perl, GTK,...)


Repito: ¿para qué reinventar la rueda? Si quieres un lenguaje rápido,
fácil
de usar, potente e interpretado, usa Perl.
[>]
    ¡¡También digo yo eso!!

¿Has intentado alguna vez hacer algo costoso en CPU con PERL?, yo si y no
estoy en acuerdo con lo que has dicho antes.



El acceso a los periféricos es una característica del sistema operativo,
no
del lenguaje.
[>]
    El lenguaje tendrá que poseer las instrucciones apropiadas para manejar
la E/S, ya sea a alto o a bajo nivel....
    En C, toda la entrada/salida se maneja como ficheros, ya sean "cooked" o
"raw"... y eso es simplificar demasiado el modelo para todos los tipos de
máquinas. Por eso luego se tienen que estar "inventando" librerías que
complementan el kernel, y permiten hacer otra serie de accesos a los
dispositivos que no son "secuenciales"...

Esa es la potencia de C, PUEDES HACER LO QUE TE DE LA GANA!, y si quieres
algo de mayor nivel de abstracción, buscate los fuentes de la libreria que
lo haga y los compilas y ya esta (seguro que los encuentras).



    No me enrollo mucho más... no merece la pena.
    Llamaremos al Sr. Tanenbaum (si te escucharan los alumnos de aquí, de la
Técnica de Informática y de la Técnica de Teleco de Madrid el nombre de ese
pibe, y ponerlo como ejemplo... la que se podría formar), y le diremos que
haga un SO estilo UNIX sin un microprocesador que implemente modo protegido,
sin un hardware que implemente espacio virtual de direccionamiento... y por
supuesto, que implemente un servidor X-Window sobre un VDP, que apenas se
sostiene haciendo SCREEN 8....


 Yo hace tiempo estudie la posibilidad de portar el MINIX (sistema
operativo escrito por Tanenbaum, cuyos fuentes son de libre distribucion
para la enseñanza y ademas no tiene mas de 10000 lineas de codigo) a MSX.
El codigo estaba escrito para ser usado en un 8086, sin disco duro, sin
modo protegido, y tan solo con la administracion de memoria del 8086.
Nosotros tenemos disco duro y un mapper (nos permite una mayor
flexibilidad que la MMU del 8086), asi que todo es posible.


Digo todo esto porque no estoy de acuerdo con lo dijo hace poco Zorita,
sobre las ventajas de implementar un lenguaje interpretado, aunque tiene
mucha razon al decir que haber quien es capaz de hacer el compilador (yo
por lo menos no soy capaz), pero que conste que es solo una opinion, y que
se haga lo que se haga yo lo apoyare :) .


Roberto.


<Anterior en la conversación] Conversación actual [Siguiente en la conversación>