[gugs] Re: [asamblea-sd] Cursos de los de gugs por emilio?

[Javier]

Esteve dijo:

> On Mon, 21 Oct 2002 14:38:10 +0200
> Javier <outermind en eresmas.net> wrote:
> 
> > Esto y el simil que haces justo debajo es con lo que no estoy de
> > acuerdo respecto a la OOP. Igual le cuesta a una persona (creo yo)
> > aprender a subdividir un problema en pequeños problemas
> > (programación procedimental), que aprender a identificar objetos.
> > Incluso hay quien dice que es más natural la programación orientada
> > a objetos. La
> 
> Probablemente sí... o probablemente no ;) Si se utiliza la POO
> basándose en cosas "reales" (como la clase vehículo, la clase heredada
> coche, etc.) se acaban limitando "las ideas". Cuando aprendes a hacer
> abstracciones mucho más complicadas que no tienen correspondencia
> "real"(por ejemplo, una clase que represente un algoritmo, un estado
> de una conexión, etc.), es cuando realmente saboreas la POO :D
> 

Recordemos que se trata de una introducción, de aprender a programar,
manejar ese tipo de cosas "limpiamente" en programación procedimental
resulta igual de imposible/engorroso a los novatos.

> > No hace falta en un curso de introducción enseñar TODO lo que te
> > permite la OOP, que si polimorfismo y demás movidas (al igual que en
> > programación procedimental no se enseñan cosas como punteros), eso
> > son mecanismos de apoyo a la OOP no la OOP en sí misma. Se puede
> > explicar el concepto de clase e incluso herencia sin que haya un
> > incremento de conceptos a estudiar y creo que realmente merece la
> > pena, cuanto antes te quites la idea de la programación
> > procedimental mejor.
> 
> Es que para mi la POO no es sólo hacer estructuras de datos. El
> enfoque que presenta la POO es mucho más, la herencia es primordial,
> la encapsulación es necesaria, la sobrecarga es importantísima, etc.


La programación orientada a objetos es algo muy conciso, es una técnica
de diseño que se centra en identificar los "objetos" que componen tu
programa en contraposición a solucionar problemas más pequeños que
componen la solución al problema global. Todo lo que incluyen los
programas orientados a objetos son apoyos no la esencia de la OOP.

Si me gusta que los lenguajes OO obliguen a ese enfoque es porque ese es
el enfoque que me parece más limpio, pero si eres muy consciente de la
OO puedes programar OO en cualquier lenguaje sin nigún tipo de apoyos.

Cosas como el encapsulamiento no es nada especial en OOP, en realidad en
los lenguajes en los que no se puede acceder a la implementación de sus
tipos (diría que todos salvo C) hay encapsulamiento implícito, no es un
cocepto "extraño", y la sobrecarga es claramente un "extra". En
realidad, cuando se piensa en diagramas y pseudocódigo lo que se hace es
cosas como obj.suma(), luego si te lo permite el lenguaje puedes
sustituir eso por una sobrecarga de operadores. Si te refieres a la
sobrecarga de funciones es algo que se incluye en los lenguajes
procedimentales desde hace tiempo, cosas como la visibilidad provocan
sobrecarga (de variables y según el lenguaje de funciones). En fin, que
siguen siendo apoyos, lo realmente importante es la forma de pensar.

> Es decir, si muestras sólo qué es una clase, hay el peligro de crear
> una clase nueva por todo, por eso veo tan importante el diseño. Y la
> procedural viene bien, por aprender a crear las funciones y los
> procedimientos, que más tarde se convierten en métodos de las
> diferentes clases.
> 

Esa es la gran enfermedad de los que aprendimos procedimental, seguimos
pensando (yo me esfuerzo por bloquear ese pensamiento) en funciones y no
objetos. Es muy típico pensar primero en que funciones necesitas y luego
buscar en que objeto los metes pero en realidad se trata de buscar los
objetos y luedo dotarlos de un interfaz. Por eso mi teoría de que
aprender directamente OOP te quita ese feo vicio. En un curso de
introducción lo que haces es añadir el concepto de objeto, las ayudas
extra se pueden dejar para un curso más avanzado, todo lo demás lo ves
también en programación procedimental (al fin y al cabo programar es
programar y el paradigma es en realidad el mismo, programación
declarativa, y usa los mismos mecanismos) pero das un enfoque distinto a
la solución de problemas. No hay una "carga docente extra", el tiempo
dará o quitará la razón de todos modos, experimentar ya se experimenta
:)

> > > Creo que es mejor aprender un lenguaje que te permita programar de
> > > manera procedural, sin imponerte la OO (aunque realmente, esté
> > 
> > Pues aquí es de donde viene nuestro desacuerdo, a mi me parece bien
> > imponer la OO, al fin y al cabo o impones la procedimental o impones
> > la OO (o dejas usar gotos y eso si que es coger vicios tontos). La
> 
> No creo que sean excluyentes, utilizando el paradigma de la POO en
> todo el conjunto, se aplica la procedural allá donde sea necesaria.
>

Eso son vicios, se puede hacer OO directamente sin necesidad de dejar
soluciones raras o feas por ahí que son los vicios que yo aun cometo de
vez en cuando (aunque luego me dedique a corregirlos para dejarlo todo
OO el vicio lo sigo teniendo).

> > Más bien guerra de "paradigmas" docentes, pero todo se andará (C++
> > power!) ;D
> 
> Para mi la POO es EL PARADIGMA ;) (Una de las razones por las que no
> me acaba de gustar Python y por la que me pasé a Ruby, es que en
> Python la POO no era suficientemente orientada a objetos :D) Pero en
> el que es realmente necesario el diseño, si no, se llegan a resultados
> mucho peores que los que puede generar la procedural pura.
> 

Eso es verdad, en POO es difícil llegar a una solución guarra aceptable,
normalmente o es un desastre puro o es la belleza hecha código, pero eso
tampoco es que sea malo del todo ;P

No he probado Ruby pero has conseguido despertar mi curiosidad, voy a
echar un vistazo a ver que tal va...

Salud!