2011/2/28 Andres Valloud <[email protected]>: > 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? Que buena idea que acabas de tirar (va, no la dijiste, pero se lee... hacer un programa a lo largo de la facultad, e ir mutandolo je). Fuera de broma, es un buen punto la disociación entre el aprendizaje (formal, o con un pet-project), y el desarrollo efectivo (actual?). Lo mismo creo que ocurre con ciertas discusiones de las que el video es un buen ejemplo. Existen muchas cosas para las que -por ejemplo-, las clases sirven ,que exceden a la definición puramente teórica; negarlo solamente puede llevar a una pequeña catástrofe (v.gr: escribir un muy bonito y puro código usando protopiting, para luego darse cuenta que es inmantenible, o no abordable). Por eso decía que me hubiese gustado ver una construcción mas positiva. Decir: "las clases se usan para todo esto, y la verdad, funcionan para esto, pero tienen sus problemas. Como agregamos?" > > 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
-- " To be is to do " ( Socrates ) " To be or not to be " ( Shakespeare ) " To do is to be " ( Sartre ) " Do be do be do " ( Sinatra ) -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
