Qué buena tu discusión. Estoy 100% de acuerdo contigo. Es más. Cuando encontramos un error como ese podemos decir:
1. El problema es el proceso (en este caso la creación de clases). 2. El problema son las personas (que no siguen el proceso adecuadamente). Es lo mismo que ocurre cuando hay un accidente y dicen: 1. Causa humana. 2. Causa técnica. Al final todo, tanto las causas humanas, como las causas técnicas, son finalmente humanas. Si los aviones y los autos no se hacen solos. Lo que pasa es que consideramos que es diferente no hacerle mantenimiento a un auto en forma periòdica que hacer mal una maniobra de 5 segundos. De la misma forma, si "hay tantos sistemas que están mal diseñados desde el punto de vista de la herencia", ¿no será que la herencia no es un buen vehículo para el modelamiento de sistemas? ¿No será por eso que existen los traits? Esos son mis 2 centavos de aporte a esta interesante discusión. Saludos, Guillermo. 2011/2/28 Andres Valloud <[email protected]> > 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 > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
