Yo digo: en general aparecen los argumentos de que las clases son malas a posteriori, como post mortem de un programa ya escrito. Pero porque alguien podria hacer un post mortem? O sea, si el programa esta escrito una vez y chau, que te calienta que la implementacion sea una basura?
Porque eventualmente, si el programa sirve, entonces hay que cambiarlo. Y ahi es donde se ve que los programadores de mandaron demasiados mocos, y entonces es ahi donde se dice que hay que boletear las clases. En realidad, probablemente lo que pasa es que escribimos un monton de programas 1.0 sin tener demasiado en cuenta que va a pasar con la version 5.0. Por eso programamos sin demasiado cuidado un monton de cosas. Ahora claro, si usamos programas escritos sin el cuidado correspondiente, y por esos programas (muchos de los cuales ni siquiera estuvieron pensados para tener una version 5.0) tomamos conclusiones en general acerca de como se tiene que programar o no... bueh... Ahora bien. En las universidades, los programas de los estudiantes (me parece a mi) mayormente se escriben una vez. Esto es porque sirven para obtener una nota. Obtenida la nota, quiza los programas estos pierden sentido. No quiere decir eso que los que estudian programacion salen escribiendo programas 1.0 a un mundo que en ciertos casos valora las versiones 5.0 tambien? Y si es asi, en que medida la universidad puede transmitir la experiencia de haber pasado por proyectos con versiones 20.0? Espero que no les caiga mal lo de los estudiantes. Aca por ejemplo se ve lo mismo con los abogados. Es obvio que un abogado que recien sale de la universidad sabra de leyes y lo que quieras, pero a los bifes todavia no le toco ir. Por lo tanto, o cobra un tercio de lo que cobra un abogado con experiencia (si le cae algun cliente), o se pone a trabajar en la firma de otro abogado con experiencia. Igual le pagan un tercio, o menos :), pero por lo menos tiene trabajo y aprende. Bueno, porque no pasa lo mismo con nosotros? Andres. 2011/2/28 Guillermo Schwarz <[email protected]>: > 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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
