[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]El vie, 01-11-2002 a las 23:42, Antonio Cardenas escribió:
> La programación orientada a objetos surgió como una
> necesidad al desarrollarse programas cada vez mas
> grandes, como fue el caso de la antigua programación
> tipo espagueti que fue sustituida por la programación
> estructurada por ofrecer está muchas mas ventajas. De
> ahí el surgimiento del lenguaje C, el cual con la
> aparición de la programación orientada a objetos tuvo
> que emigrar a lo que hoy se conoce como C++. Es
> innegable todas las ventajas que la programación
> orientada a objetos ofrece sobre la programación
> estructurada. En cualquier buen libro de programación
> vienen explicadas todas las ventajas.
Estoy de acuerdo. En cualquier libro de programacion de manufactura
relativamente reciente encontraras que la verdad de la vida es la
programacion orientada a objetos. Pero desafortunadamente, siempre
existe una diferencia entre el texto academico y la Vida Real(mr). Las
ventajas de C++ con respecto a C desaparecen porque en ambos tienes que
manejar apuntadores, y administrar la memoria sin utilizar un recolector
de basura. Las maravillosas ventajas de OOP (encapsulamiento,
polimorfismo, herencia, reuso de codigo) se esfuman cuando desbordas la
pila, o tienes fugas en la memoria, sin importar que haya sucedido en
una funcion, o en un constructor de clase. Combinado esto con algunos
'goto's, indispensables en ambos lenguajes, puedes hacer spaguetti
estructurado u orientado a objetos, a tu eleccion. Puedes solucionar
algunas cosas utilizando Objective-C, pero muchos ni siquiera lo han
escuchado mencionar. :-|
> El tener un kernel construido con programación
> orientada a objetos lo hace mas fácil de recibir
> mantenimiento y de hacerle modificaciones. También
> esto conlleva a una mayor capacidad de multihilado lo
> cual permite la construcción de clusters mas
> eficientes. También se tienen mas privilegios sin
> necesidad de ser root; es posible desarrollar y probar
> nuevos componentes del kernel sin necesidad de un
> reboot y sin interferir con otros usuarios.
De verdad es mas facil depurar un nucleo orientado a objetos
multihilos? Como puedes determinar cual de los hilos fallo, a partir de
la informacion de volcado de memoria? Como puedes depurar un sistema, si
el objeto que administra la memoria muere, sin tener tiempo de notificar
(por paso de mensajes) al objeto que administra el sistema de archivos
para generar un volcado de memoria? Ojo, no estoy diciendo que sea
imposible, pero las soluciones para estos problemas no son triviales, y
no facilitan en nada el desarrollo de un nucleo de dichas
caracteristicas.
Ahora con los clusters, Como incrementas su eficiencia con multihilos,
cuando el cuello de botella principal en un cluster es la comunicacion
entre los nodos?
Y como último detalle: no es indispensable que tu nucleo sea orientado
a objetos para poder crear nuevas extensiones. En Linux, como en
cualquier otro sistema operativo moderno, puedes crear controladores sin
necesidad de reiniciar y/o interferir con otros usuarios. Y de cualquier
forma, hay modificaciones o extensiones que (por el momento), te forza a
reiniciar tu equipo. En este momento pienso en el administrador de
memoria, aqui se puede agregar otros mas.
> Este no es un proyecto nuevo, se inicio en 1983 (desde
> antes de Linux) y fue la primer idea de crear un
> sistema operativo completamente libre, lo que si es
> nuevo es que ya dejo de ser solo un proyecto, este
> kernel ya existe aunque aún está en pañales y le
> faltan años de desarrollo.
Desafortunadamente, le falta mucho a HURD para convertirse en una
alternativa viable a cualquier otro sistema operativo que se encuentra
en produccion en estos dias. Las mismas dificultades que he mencionado
anteriormente hacen mas lento su desarrollo (no mas rapido, como
argumentas), y se vuelve tedioso trabajar con el. Toma en cuenta que
funcionara de maravilla cuando la plataforma que ofrece este madura,
pero esa plataforma ni siquiera esta completa en este momento.
No quisiera ser ave de mal aguero, pero, si HURD llega a una
version 1.0, sera simplemente un juguete academico mas en desuso, como
Minix, o Amoeba.
> El kernel de Linux crece muy rápido, su tamaño en
> archivo tar.gz de la versión 1.0 apenas pasaba de 1
> MB, la versión 1.2 ya era de 2.2 MB, la versión
> 2.0.29 ya fue de 5.8 MB, la versión 2.2.22 fue de 18.8
> MB y la versión 2.4.19 que es la última estable ya fue
> de 30.7 MB; actualmente se está trabajando en la
> 2.5.45 que lleva un tamaño de 36.4 MB pero ya
> descomprimido anda cerca de los 200 MB, trabajar con
> tanto código con solo programación estructurada se
> vuelve más y más tedioso a medida que el kernel crece,
> el que se pueda configurar el kernel de Linux por
> módulos alivia un poco el problema pero no lo
> soluciona. Esto es lo que hace atractivo al Kernel
> Hurd para el futuro. Será un kernel más poderoso y más
> fácil de depurar y actualizar.
De verdad el tedio de programar estructuradamente impide el
desarrollo posterior? De verdad el hecho que el codigo sea escrito
en C es un problema para Linux? Yo diria que al contrario. En
realidad, la cantidad de personas que hace programacion estructurada
es mucho mayor que la que hace programacion orientada a objetos.
Y la cantidad de programadores que conocen C es mayor que la que
utiliza C++. Ahi Linux aprovecha una masa critica importante de
desarrolladores, que pueden entender, modificar y actualizar codigo
en este momento, no en algun futuro feliz donde todo se vuelva
mas facil.
> Es por lo anterior que el MIT se propuso hacer
> realidad el proyecto y los desarrolladores de Linux
> Debian lo están apoyando, si ya se tienen drivers
> hechos para Linux, no hace falta reinventar el hilo
> negro, solo hay que adaptarlos para Hurd en
> programación orientada a objetos.
Cual es la ventaja REAL de cambiar un controlador para que funcione
con programacion orientada a objetos? Si le haces caso al paradigma de
programacion orientada a objetos, lo que realmente importa es tener una
interfaz sana para permitir que tu codigo se integre al resto del
proyecto, hacer transparente los recursos que se utilizaran en otras
partes del proyecto, y hacer opacos los metodos y funciones propios y
unicos de tu codigo. Y para hacer eso no necesitas C++, simplemente
saber escribir bien C.
> Cualquier modalidad de sexo torcido no tiene nada que
> ver aquí con Unix, el que hayas hecho ese comentario
> puede hacer hacer pensar a muchos en que existe un
> desequilibrio mental.
> Comprendo la pasión de muchos por Linux, yo también la
> tengo, pero no hay que estar cerrados en la idea de
> que no es superable.
>
> http://www.gnu.ai.mit.edu/software/hurd/hurd.html
De acuerdo: Linux debe ser superado. No me queda la menor duda. Pero no
he visto la menor pista para que HURD corresponda al siguiente paso
evolutivo de Linux en un corto o mediano plazo.
Saludos
--
__(o< | Nombres/Names: Cristian Othón | cfuga en itam mx
\/|/ | Apellidos/Last Names: Martínez Vera | http://cfuga.net/
/_/_ | | http://linuxppp.com/
| "Pulchrum est paucorum hominum" - Horace
_______________________________________________
Ayuda mailing list
Ayuda en linux org mx
Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/