Charla muy interesante
Locked
 
|
Si tienen tiempo miren esta charla que salió en InfoQ, es muy recomendable:
--
-- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hernan, Muy bueno en link algunas cosas no comparto, y me parece que
realmente no profundizo en el aprendizaje de Smalltalk. Un tema interesante que toca, es el de prototipado, es decir en
Self podes ir construyendo objetos sin tener clases. Para mi desde un punto de vista práctico (es decir no importa
que pasa por detrás) en Smalltalk podes hacer lo mismo, no hay diferencia con
Self. Nada me impide agregarle un botón al Flipper Inspector de
Dolphin para que agregue un slot o variable mas a la clase de objeto
inspeccionado . Es más podría agregar una nueva toobar “Self toolbar”
al Flipper Inspector de Dolphin (quizás sería un FlipperSelfInspector) para
simular lo que se hace en Self. Agregar variables al objeto, instanciarlas, clonarlas, etc. Hay diferencias entre Self y Smalltalk pero me parece que en
este punto no hay diferencia, en Smalltalk podes simular Self, y no es muy difícil. Otro error que comete es decir que difícil la parte de instancias,
clases y metaclases. Si quiere investigar un asunto entonces que le meta unas 4 u 8
horitas a Smalltalk… Y va a ver que no hay misterio alguno entre clases y metaclases,
instancias, etc… Pero parece que hoy en día para hablar de lo que hace uno hay
que descalificar al otro (da más rating….) Digo esto por el tono de la charla… Saludos, Bruno PD: Lo mate al pobre …. Fue lo que me salió De:
[hidden email] [mailto:[hidden email]] En
nombre de Hernan Wilkinson Si tienen tiempo miren esta charla que salió en InfoQ, es
muy recomendable: Aquellos que hayan cursado objetos en la uba verán que toca
temas que damos en la materia. -- Hernán
Wilkinson -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
> Pero parece que hoy en día para hablar de lo que hace uno hay que
> descalificar al otro (da más rating….) Y si... Knuth se queja de esto tambien, dice que basicamente hoy en dia no importa la cuestion practica sino el "one-upmanship" (mas o menos ir y hacer un ++ de lo anterior) incluso cuando no hace falta. Por ejemplo, se queja en concreto de que sale el algoritmo X que asintoticamente tiene complejidad O(n^2), e inmediatamente sale otro algoritmo que tiene complejidad O(n^1.99999) diciendo que claramente es mejor que O(n^2)... pero en casos concretos el O(n^2) va muchisimo mas rapido porque esta pensado para casos que ocurren en la practica, no para el comportamiento asintotico cuando por ejemplo n -> +\infty... A mi tampoco me gusta demasiado esto que decis, porque al final termina siendo todo una competicion entre Intrusos, Tinelli, etc en vez de hablar de cuestiones de programacion como seres racionales. Andres. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Aca esta lo que decia Knuth...
A lot of the recent literature is academic one-upmanship of limited interest to me; authors these days often introduce arcane methods that outperform the simpler techniques only when the problem size exceeds the number of protons in the universe. Such algorithms could never be important in a real computer application. I read hundreds of such papers to see if they might contain nuggets for programmers, but most of them wind up getting short shrift. 2011/2/17 Andres Valloud <[hidden email]>: >> Pero parece que hoy en día para hablar de lo que hace uno hay que >> descalificar al otro (da más rating….) > > Y si... Knuth se queja de esto tambien, dice que basicamente hoy en > dia no importa la cuestion practica sino el "one-upmanship" (mas o > menos ir y hacer un ++ de lo anterior) incluso cuando no hace falta. > Por ejemplo, se queja en concreto de que sale el algoritmo X que > asintoticamente tiene complejidad O(n^2), e inmediatamente sale otro > algoritmo que tiene complejidad O(n^1.99999) diciendo que claramente > es mejor que O(n^2)... pero en casos concretos el O(n^2) va muchisimo > mas rapido porque esta pensado para casos que ocurren en la practica, > no para el comportamiento asintotico cuando por ejemplo n -> > +\infty... > > A mi tampoco me gusta demasiado esto que decis, porque al final > termina siendo todo una competicion entre Intrusos, Tinelli, etc en > vez de hablar de cuestiones de programacion como seres racionales. > > Andres. > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Charla muy interesante
|
|
In reply to this post by BrunoBB
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)
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)
3) La otra cosa interesante, es que por primera vez veo a alguien (fuera de lo que venimos haciendo en la uba) criticar a la subclasificación, herramienta que a mi entender genera muchisimos errores de diseño y grandes dolores de cabeza, más aún con los novatos.
En definitva, lo que me sorprender/reconforta/gusta es que sale un video que pueden ver miles de personas donde se cuestiona el status quo con algo de sentido, y donde se habla de Self y Smalltalk, etc. o sea, no es más sopa.
Saludos, Hernan.
-- 2011/2/17 Smalltalk <[hidden email]>
-- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]>: > 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) 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 [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Charla muy interesante
|
|
2011/2/28 Javier Burroni <[hidden email]> Esta bueno el video. Y si... a veces las charlas tienen ese toque marketinero inevitable en los últimos tiempos Es interesante ver charlas de los viejos (naur, dikjstra, etc) donde el marketing no estaba presente... en fin.
Saludos, Hernan.
-- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Javier Burroni
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 <[hidden email]>: > 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 <[hidden email]>: >> 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 [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]> Algo que no me termina de cerrar es que en general aparecen esta clase -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
Andres, creo que en lo que estamos de acuerdo es en que la subclasificación es una herramienta más. No es a priori ni mala ni buena. En algunos contextos puede ser muy útil pero en algunos otros podrían ser útiles otras herramientas.
El problema es que cuando solo tenemos un martillo, vemos a todo problema como un clavo. Es decir, estaría bueno que el ambiente cuente con diferentes formas de compartir y agrupar conocimiento y que no solamente se cuente con subclasificación. No me parecería incorrecto que existan clases (conceptos) que definen el comportamiento de un grupo de objetos y por otro lado objetos sin clase, es decir, únicos y que no pertenecen a ninguna clase.
2011/2/28 Andres Valloud <[hidden email]> Algo que no me termina de cerrar es que en general aparecen esta clase -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
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 <[hidden email]>: > 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 <[hidden email]> >> >> 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 <[hidden email]>: >> > 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 <[hidden email]>: >> >> 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 [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
2011/2/28 Andres Valloud <[hidden email]>:
> 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? 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 <[hidden email]>: >> 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 <[hidden email]> >>> >>> 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 <[hidden email]>: >>> > 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 <[hidden email]>: >>> >> 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 [hidden email] >>> > To unsubscribe from this group, send email to >>> > [hidden email] >>> > >>> > http://www.clubSmalltalk.org >>> >>> -- >>> To post to this group, send email to [hidden email] >>> To unsubscribe from this group, send email to >>> [hidden email] >>> >>> http://www.clubSmalltalk.org >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > 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 [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
> 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). Creo que estaria bueno, asi se sufr :) digo se pueden ir aprendiendo las cuestiones practicas del oficio. Para mi, lo mas importante de esto es levantar la barra del promedio. > 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). Tal cual, por ejemplo. O incluso si con prototipos tambien te sale lindo, no es necesario caer en la guerra religiosa de "porque me gustan los prototipos entonces todo lo que esta hecho en clases esta mal". Por ejemplo, mas alla de que personalmente me gusta mas Smalltalk que Java, no seria correcto asumir que todo lo que se hace en Java esta hecho mal por definicion de mis gustos personales. Y quien dice Java dice C, o C#, o Python, o su Smalltalk favorito, etc... > 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?" Y si. No me gusta hacerme el autobombo, pero al mismo tiempo quiero aclarar que por lo menos en este caso no me quede en la queja e hice algo. De estas cuestiones de clases y herencia especificamente escribi en el capitulo 4 del volumen 1 del Fundamentals. Andres. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Charla muy interesante
|
|
In reply to this post by Andres Valloud-5
che Andres, me parece que agarraste para los tomates :-) por lo menos yo no dije que las clases no servían ni que la subclasificación tampoco... es más en el 2 punto digo que al final las clases son necesarias sino queda todo al mismo metanivel y eso también es confuso... y como toda herramienta, puede ser buena o mala según como se la use. No entiendo porque decís que "hay que sacarlas".
Pero de vuelta, lo que me parecio lo más importante de ese video es que alguien está mostrando que existe vida más allá de las clases y ese es un concepto que para mucha gente es novedoso por más que sea bastante antiguo, nada más.
Un abrazo Hernan. 2011/2/28 Andres Valloud <[hidden email]> Algo que no me termina de cerrar es que en general aparecen esta clase -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Jaja, no...
2011/2/28 Hernan Wilkinson <[hidden email]>: > che Andres, me parece que agarraste para los tomates :-) por lo menos yo no > dije que las clases no servían ni que la subclasificación tampoco... es más > en el 2 punto digo que al final las clases son necesarias sino queda todo al > mismo metanivel y eso también es confuso... y como toda herramienta, puede > ser buena o mala según como se la use. No entiendo porque decís que "hay que > sacarlas". Capaz que lo dije no tan claro... lo que quise decir es que cada tanto comentas que a veces es dificil conseguir subclasificaciones buenas, y que es comun (o por lo menos no sorprendente) encontrarse con ejemplos medio bizarros de subclasificaciones. Me quedo la idea de que tambien puede ser dificil de enseñar algun criterio facil para subclasificar bien. Bueno, suponiendo que hayas dicho eso :)... a lo que iba es que si es relativamente facil encontrar casos donde se subclasifica mal, me da la impresion de que hay argumentos del estilo "como se subclasifica mal en general, la culpa es de las clases" en vez de "como se subclasifica mal en general, entonces programamos mal en general". Bueno, entonces cada tanto sale alguien a dar alternativas a las clases, como por ejemplo "las clases son un error historico, y por lo tanto hay que usar prototipos". Si, bueno... pero como dijeron otros por aqui, la opinion un poco mas constructiva tambien vale. Por ejemplo, porque en general se subclasifica mal? A mi me da la impresion de que hay dos factores... por un lado esta el manejo de responsabilidades como fuerza antagonista a querer ahorrar escribir hasta el ultimo metodo posible. Como ilustracion: Dictionary como subclase de Set aunque la conducta es bastante diferente. O si no, poner FilaDeAlumnosDeLaPrimaria como subclase de SortedCollection y con el sortBlock por default reimplementado para hacer [:x :y | x altura <= y altura]. El otro factor es la facilidad de cambio. Cuando considerar el mantenimiento a futuro de las cosas no tiene tanta prioridad como otras cosas, entonces aparecen objetos con 20 variables de instancia (me acuerdo de algunos trabajos anteriores) o miles de metodos (Morph). Con un poco de subclasificacion o composicion+delegacion, esos problemas desaparecen. Lo que si es cierto es que diseñar esas cosas a largo plazo lleva bastante mas tiempo que poner mas variables de instancia y metodos para resolver el problema urgente que tiene que estar resuelto para hoy a la tarde. Hay soluciones para estos lios, desde ya. Que otros problemas tienen las clases? Y como se resuelven con prototipos? Que caracteristicas de mantenimiento a largo plazo tienen las soluciones de los problemas de las clases hechas de manera equivalente en prototipos? Andres. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Charla muy interesante
|
|
si, por eso yo siempre digo que subclasificar para reutilizar código no es bueno, hay que evitarlo, no está hecho para eso, sin embargo es como más se usa lamentablemente.
Los prototipos tienen muchas ventajas, se ve en la implementación de algunos patrones como decorator, adapter, etc (wrappers) pero también algunas falencias como la organización...
Un abrazo Hernan
-- 2011/2/28 Andres Valloud <[hidden email]> Jaja, no... -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Charla muy interesante
|
|
In reply to this post by hernan.wilkinson
Está bien la charla en los temas que plantea, aunque no estoy de
acuerdo con el contenido. Las clases, como muchos otros recursos suman y no restan. En todo caso el mal uso resta. Respecto a los prototipos tuve la suerte (mucha suerte), de trabajar con NewtonScript hace muchos años, cuando salió la Apple Newton a principios de los 90. El uso real, y no solo teórico, de los prototipos es acertado, es natural y eficiente preguntarle el color a la puerta de un auto rojo y que sin hacer nada te devuelva "rojo", obviamente. O esperar que un evento que se dispara contra un botón lo ataje la ventana contenedora si este no lo agarró. Estas cosas no pasan tan naturalmente en Smalltalk. En los dispositvos móviles además tiene la ventaja de ahorrar mucha memoria el prototipado, aunque como en ese caso se combinaban ambas herencias a veces requería de cuidados especiales. Pero puedo afirmar que por entonces vi y participé de sistemas reales, implementados en algo que podría verse como un pariente de Self (hijo o sobrino) y funcionaron como proyectos, además de ser divertidos tecnicamente. Lo aclaro porque, al igual que Smalltalk, se suelen pensar que estas cosas solo son teóricas y practicamente no tienen usuarios. De la charla me resulta interesante que recuerde (en el minuto 3 + o -), que en los inicios Smalltalk interpretaba los mensajes como strings, en lugar del method lookup de hoy en día. Supongo que hay razones de implementación para eso, pero si algo le pediría a un Smalltalk del futuro es que volviera a hacer eso. Saludos On 17 feb, 14:39, Hernan Wilkinson <[hidden email]> wrote: > Si tienen tiempo miren esta charla que salió en InfoQ, es muy recomendable:http://www.infoq.com/presentations/Classes-Are-Premature-Optimization > > <http://www.infoq.com/presentations/Classes-Are-Premature-Optimization>Aquellos > que hayan cursado objetos en la uba verán que toca temas que damos en la > materia. > Hernan. > -- > * > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Mobile:+54 - 911 - 4470 - 7207begin_of_the_skype_highlighting +54 - 911 - 4470 - 7207 end_of_the_skype_highlighting > email: [hidden email] > site:http://www.10Pines.com<http://www.10pines.com/> > * -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |