Mailinglist Archive: opensuse-es (1576 mails)

["Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



El 2008-12-03 a las 20:36 -0500, Shinji Ikari escribió:

> > > modelar el problema.
> >
> > Sí, un intento más.
>
> O.O??!!
> Raíces de POO en los 60s, lo dice su artículo de Wikipedia, no le desprecien.
> http://en.wikipedia.org/wiki/Object-oriented_programming

Si no lo despreciamos.

> luego en el enlace que pase anteriormente mencionan otros paradigmas:
> http://en.wikipedia.org/wiki/Programming_paradigm
>
> muchos la verdad. Métodos para abordar un problema nunca faltan, algo por lo
> que hay que sentirse orgullosamente humanos. ;)
> Sin embargo la reutilización del código, herencia, me parecen características
> muy interesantes. Por ejemplo, un método para mostrar mensajes. Si uno es
> principiante, hace un método por cada mensaje que tenga que mostrar. =)

No obstante, la reutilización del código no es una característica 
exclusiva de la POO. Puedes hacerlo perfectamente con programación 
estructurada, o secuencial. Y puedes también no reutilizar código con POO. 
Lo único es que se suele enseñar a reutilizar al enseñar POO, y que invita 
más a hacerlo, lo facilita.

Sólo tienes que fijarte que los programas que usan POO son a menudo mucho 
mayores que los "normales", y más lentos, luego no están reutilizando y 
optimizando tanto los recursos como sus proponentes defienden. Las cosas 
no son tan meridianamente claras.


> > > Los "procedurales"( suena horrible) interpretan el problema desde el
> > > lado del programador.
> >
> > Igual que los OOP - aunque lo nieguen. ¡No van a estar orientados al
> > usuario! El usuario no programador no tiene ni idea de qué hacer con un
> > objeto.
>
> El lusuario se confunde con muchas cosas, en la mañana leí de uno que exigió
> que se desconecte los cables de poder de los ordenadores para evitar que fugue
> información confidencial...

Lo cual es absolutamente cierto, y no es broma.

> y de otros con el posavasos para el portátil.

Lo cual creo que es sólo una leyenda urbana.


> > > Lineal o no lineal... es otro concepto, escribir 8900 lineas seguidas o
> > > modularizar el problema.
> >
> > Lineal sólo significa que el programa sigue una secuencia definida de
> > sucesos, que es previsible desde el principio. Se ejecuta una cosa, detrás
> > otra, detrás otra... en una secuencia definida; aunque lo dividas en
> > procedimientos, funciones, o incluso objetos, la secuencia es lineal.
>
> O.O?? bueno, somos lineales también, todo de golpe no nos puede entrar.
> Primero mecánica estática y luego la dinámica y antes de eso matemática, que
> siempre va a estar allí. Pero ojo que lo que dice aquí se puede confundir un
> poco con lo que dice después respecto a los eventos, el usuario al ser
> impredecible... como hacer un programa que no sea lineal. Suena confuso ¿no?
> No se en que parte exactamente leí respecto a la programación para ordenadores
> con varios procesadores. Apple sacará su siguiente versión enfocada en eso.

Me sospecho que no has pillado la diferencia entre programación secuencial 
o por eventos, o estructurada o orientada a objetos :-)

secuencial:

  1: abre el fichero
  2: lee el primer campo
  3: Procésalo (puede ser un procedimiento o un método)
  4: repite hasta terminar el fichero
  5: imprime los resultados.

En ese programa se sabe exactamente lo que va a hacer, cuando, y en que 
orden: es secuencial.

Por eventos:

  - procesar tecla <-- disparar si evento: pulsación de tecla 'Q'
    terminar programa.

  - procesar tecla <-- disparar si evento: pulsación de tecla 'C'
    cambiar color del reloj

  - avanzar reloj un segundo  <-- disparar si evento: ha pasado un segundo


  - inicializar
     pintar un reloj en pantalla

main:
  1: decirle al sistema operativo que me mande eventos de tecla y de
     segundos
  2: pintar reloj
fin.


Sólo la parte 1 y 2 se sabe cuando se ejecutan. Los tres métodos de 
procesar teclas o avanzar el reloj no se sabe en qué orden se van a 
ejecutar: no es secuencial, es casi aleatorio: depende de lo que haga el 
usuario, de eventos externos.


> Algo que recuerdo también es cierta mención de un docente acerca de que se
> debería enseñar a programar orientado a objetos primero y luego los
> procedimientos. ¿Preferible aprender java primero y luego C?

Las opiniones son como el c..., cada uno tiene una -- que dijo cierto 
actor de manera un tanto bruta :-P


> > > Los primeros compiladores orientados a objetos, solo eran un frontend
> > > del compilador habitual.
> > >
> > > Al fin y al cabo, el codigo maquina es el que es. Independientemente de
> > > los compiladores utilizados.
> >
> > Obviamente.
>
> O.O!! ¿entonces GCC sacaría el mismo resultado que el compilador de Borland o
> el de Metrowerks (Codewarrior, lo recuerdo cuando era maquero =P~)? Creo que
> Intel también está en esas cosas.

No, no serán iguales.


> > > La utilización de Eventos ( alias interrupciones) es comun a todas las
> > > formas de programación.
> >
> > No, los eventos no son las interrupciones, eso es otra cosa. Son los
> > eventos en OOP: se asocia un "método" a un determinado evento, que puede
> > ser, por ejemplo, que el usuario hace click en la barra de tareas, o que
> > selecciona el menú de abrir archivo, o que aprieta el botón de "Ok". Eso
> > no son interrupciones, son otra cosa. Cuando sucede el "evento" se ejecuta
> > un "método", que no deja de ser una función con otro nombre. Como los
> > eventos, que la mayoría son originados por el usuario, son imprevisibles,
> > la secuencia de ejecución del programa es también imprevisible: es
> > entonces cuando el programa deja de ser "secuencial" o "lineal".
>
> Hmm, eso me recuerda cuando vi algunas líneas de programación para mac, los
> eventos tenían nombres propios, completamente relacionados con el OS. Una
> interrupción se referirá a algo de más bajo nivel, como Assembler supongo.

Tampoco, pero... bueno, algo parecido. Es más complejo de explicar, no voy 
a entrar en eso aquí. Es una funcionalidad del procesador.

> No se mucho de programación en ambientes gráficos, pero supongo que es un
> marco que contiene los métodos para los eventos y los procedimientos y
> funciones que hace el programa, tal que el marco es el que se encarga de
> capturar los eventos y pasarlos a las funciones correspondientes que
> responden, y simultáneamente los procedimientos y funciones principales del
> programa se siguen ejecutando, como minimizar el navegador, mientras está
> cargando un página. Lo cual indica que estos tienen prioridad en la ejecución,
> por que mientras se está realizando alguna tarea, el usuario puede cerrar la
> ventana.

Puede haber eventos con prioridades (no te se decir seguro), pero lo 
normal es que se procesen en el orden en que llegan. Según como hayan 
hecho las cosas, se podrían ejecutar varios simultáneamente. O parecerlo.

> Los tíos que hacen esas cosas son humanos ¿verdad? y si no es así, ¿donde
> hacen los implantes de cerebros positrónicos? =P

Eso en el aula de métodos complejos :-p


- -- 
Saludos
       Carlos E.R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk3Sj0ACgkQtTMYHG2NR9Ux1ACeKyNx9/3SImCf6PvgkJTgYB41
l5UAn39rsJlBwE8bvOyuM1Vk0qrjIyCT
=Rm3s
-----END PGP SIGNATURE-----