Algo que no me termina de cerrar es que en general aparecen esta clase
de pronunciamientos ("las clases son un error historico") cuando el
promedio de los programadores se mandan demasiados mocos. O sea,
"los programadores hacen cualquier cosa con las clases" => "inventamos final"
"los programadores hacen cualquier cosa con los tipos" => "inventamos
strong typing"
"los programadores hacen cualquier cosa con do: aBlock" => "inventamos generics"
Es el argumento de que las clases son inherentemente malas uno mas de
la lista de arriba? Porque si es asi, entonces no hay que perder de
vista de que las clases no programan solas. Los mocos siguen siendo
nuestros. De hecho, Hernan cada tanto comenta que se cruza con
ejemplos medio bizarros de subclasificacion, y que no es facil
agarrarle la vuelta a cuando subclasificar. Y si es asi, entonces
cual es el problema? Que nosotros no programamos bien con clases? O
que las clases y sus defectos inherentes nos hacen programar mal, y
que por eso no hay que usar mas clases?
Si, como parece ser el mantra del dia, nosotros no usamos bien
clases... bueno, probablemente tampoco las entendamos demasiado bien.
Entonces porque le tiramos la culpa a las clases, si los que no
entendemos somos nosotros?
Pero bueno, esta bien, saquemos las clases porque son complicadas. Y
ya que estamos, que tal si reemplazamos "clases" por "multithreading"
en la discusion de arriba? Tambien el multithreading es un error
historico? Si no entendemos bien como usar clases, con multithreading
vamos fritos al toque. En definitiva, que es lo que queda para
programar si algo como "clases" es inabordable? Muy poco o nada. Y
en ese caso, que es lo que esta mal? Las clases, o el argumento de
que son dificiles?
Andres.
2011/2/28 Javier Burroni <[email protected]>:
> Esta bueno el video.
> Me había anotado unas cosas para comentar, pero creo que va a ser
> mejor hacerlo sobre los puntos de Hernán.
>
> 2011/2/18 Hernan Wilkinson <[email protected]>:
>> lo más interesante de la charla por lo menos para mi, es que muestra
>> claramente un par de cosas:
>> 1) la programación con objetos no obliga a tener clases (cosas que el 98% de
>> los programadores cree... es más una vez un profesor de universidad me dijo
>> que la programación orientada a objetos debia llamarse programacion
>> orientada a clases... asi que imaginense como daba clase! jaja)
> Es bueno tener en claro que la programación con objetos no implica
> clases, pero me hubiese gustado que en la charla haga una exposición
> mas positiva. Esto sería algo así como: "estamos usando un esquema de
> clases y metaclases por que nos permiten hacer esto, lo otro, y
> aquello... ahora, surge tal problema". La percepción que tuve fue que
> el concepto de clases fue un error historico del que tenemos que salir
> de cualquier manera. Entender bien las ventajas ayuda a cambiar de
> paradigma conociendo las perdidas, no?
>> 2) La otra es la importancia de ir de lo concreto a lo genérico y cómo para
>> ello los lenguajes de prototipación son mejores que los de clasificación.
>> Lamentablemente en este último punto le falta un poco de base conceptual en
>> lo que dice, le falta hablar de organización de conocimiento y termina
>> mostrando como que lo bueno de eso es la "performance", cosa que para mi no
>> es lo más importante del tema (y además un poco misleading, cuando comparan
>> self con smalltalk en performance, en esa époco self tenía ya implementado
>> pic y en smalltalk no habia ninguna vm que lo hiciera, self tenía jit y no
>> creo que muchas vms de smalltalk lo hicieran, etc. Habría que ver ahora como
>> anda esa comparación... a lo que voy es que no creo que usar prototipos
>> sobre clases sea el motivo que haga que self fuese más rápido que smalltalk
>> en esa época). Debido a que no aborda el tema de la organización de
>> conocimiento es que no termina viendo/mostrando que al final, no es tan
>> sencillo tener todo al mismo meta-nivel... en definitiva, existe "mi auto" y
>> también el concepto de "auto"... el problema con los lenguajes de
>> programación de clasificación es que tengo que crear "auto" antes de poder
>> trabajar con "mi auto" (entre otras cosas)
> je, esto esta realacionado con lo que decía antes. Como no se mete con
> las cuestiones conceptuales, las criticas que realizan suenan un poco
> superficiales. Las semanticas de clases y jerarquias aportan (como
> todo con semantica :) ), al conocimiento, y a la comunicación. También
> habría que tener en cuenta cuestiones de organización de los
> comportamientos, y posiblemente algo de ingenieria. En un momento
> habla sobre poder usar un esquema organizativo por que uno quiere, y
> no por que el sistema te obliga. Bueno, supongo que eso puede generar
> discución.
> Lo de la performance suena raro, por que finalmente nombra a v8
> (http://code.google.com/apis/v8/design.html, con cita a
> http://portal.acm.org/citation.cfm?id=800017.800542), lo que genera
> ciertas dudas sobre la penalidad de performance. Ademas me surgió la
> duda de si no es bueno que a través de las clases se revele al
> programador algo que de hecho el sistema usa -con pros, cons, pero hay
> que pensarlo-.
> saludos
> jb
>
> --
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
>
> http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
