Smalltalk en ADVA
Locked
12
12
 
|
Facundo,
Tenés razón, pero tal vez lo que hice peor fue escribir código Smalltalk fuera de Smalltalk (en un mail) dando a entender de que era un algortímo cuando no lo es. No solo porque Smalltalk me hubiese avisado de ese punto que decis, sino porque no considero el ambiente, que es lo mas importante. Y no alcanzaría con especificar la clase del método, debería especificar todos los métodos y clases del ambiente, los objetos instanciados, todo... y seguiría sin alcanzar porque es un ambiente. Lo digo desde el punto de vista práctico (creo filosofía en esto). Respecto a los negativos, mas allá de la definición matemática, remarco que los métodos no siempre se pueden enviar a todos los objetos posibles del dominio de una clase. En general los métodos no resuelven todo lo que un receptor de esa clase puede devolver, y sería un error hacer programación defensiva con eso. Asi como no se le puede enviar #copyFrom: 5 a cualquier String, ni #new a cualquier clase, ni #arcCos a cualquier Float. La responsabilidad en el envió de un mensaje está del lado del emisor y no del receptor o método que lo resuelve. Saludos, Diego On Sep 15, 6:44 am, Facundo Vozzi <[hidden email]> wrote: > Si termina, lo que no estaría bien es que -10 factorial devolvería 1 cuando > el factorial de -10 no esta definido,según recuerdo, matemáticamente. > Lo único que tiene mal el método (por si querés probarlo) de Diego es el > punto al final del ifTrue: [] > > Saludos, > Facundo > > 2010/9/15 Guillermo Schwarz <[hidden email]> > > > > > Off topic, pero tu algoritmo no termina si se le pasa un número > > negativo... > > > factorial > > "Returns the factorial of the receiver." > > > ^self <= 0 > > ifTrue: [1]. > > ifFalse: [self * (self - 1) factorial]. > > > Para comparar las soluciones en distintos lenguajes habría que hacer un > > benchmark. Esos benchmarks existen, no veo la razón para hacerlos de nuevo > > acá. Gana SML siempre. > > > Una de las optimizaciones que hacen los compiladores se llama tail > > recursion elimination y consiste en que la llamada recursiva final se > > reemplaza por un goto al principio del método. > > > ¿Porqué sería tan importante la velocidad en RAM? > > > En la práctica la velocidad de acceso a disco lo domina todo. Un disco más > > rápido hace toda la diferencia y hasta el momento los SSD son los más > > rápidos. > > > Saludos, > > Guillermo. > > > On Mon, 2010-09-13 at 06:45 -0700, [hidden email] wrote: > > > Hay varias implementaciones de factorial, pero la que haría un > > > Smalltalker, al menos inicialmente, sería: > > > > factorial > > > "Returns the factorial of the receiver." > > > > ^self = 0 > > > ifTrue: [1]. > > > ifFalse: [self * (self - 1) factorial]. > > > > Esta implementación, con mucho por mejorar sigue siendo rápida y > > > "esconde" cosas que en otros lenguajes son evidentes y complejas. Como > > > decías el GC es importante , otra cosa es el operador "*", que podría > > > ejecutarse en distintas clases según el tamaño del receptor, gracias > > > el carácter dinámico de Smalltalk y a que los números son objetos. > > > Quienes además conocen la implementación interna de Smalltalk, como > > > vos, tal vez puedan agregar muchos detalles de la implementación de > > > todo esto. Pero tal vez, lo que hace rápido en Smalltalk, es que un > > > ignorante (como yo) puede hacer algo rápido y de forma muy natural y > > > obvia. > > > > Yo pondría el esfuerzo por hacer algo rápido como parte de la > > > comparación entre lenguajes. Porque hay esfuerzos que son > > > impracticables, entonces en la práctica no se hacen y terminan como > > > sistemas lentos en C/C++. Cargar una librería C solo sirve para lo ya > > > resuelto, sería bueno saber cuánto esfuerzo requiere hacer esa > > > librería C (en Smaltalk escribir #factorial llevaría 2 líneas si no > > > estuviera hecho). > > > > Diego Coronelbegin_of_the_skype_highlighting end_of_the_skype_highlighting > > > > On Sep 10, 8:24 pm, Andres Valloud <[hidden email]> wrote: > > > > En general menciono a JP Morgan porque trabaje ahi, pero Cincom tiene > > > > pila de bancos de clientes... > > > > > Calcular 10000 factorial simplemente mide > > > > > a) la velocidad de la primitiva que multiplica large integers (que en > > > > general se implementa con el algoritmo simple de la primaria porque es > > > > rapido para numeros chicos, asi que cuando se usa con numeros > > > > gigantescos entonces no es tan bueno, ver por ejemplohttp:// > > blogten.blogspot.com/2008/07/mr-karatsuba.htmly similares), > > > > > b) la velocidad de la implementacion de factorial, que en general es > > > > algo asi como > > > > > | answer | > > > > self < 0 ifTrue: [self error]. > > > > self < 2 ifTrue: [^1]. > > > > answer := 1. > > > > 2 to: self do: [:each | answer := answer * each]. > > > > ^answer > > > > > y que en general es mas o menos la peor manera posible de implementar > > > > factorial para argumentos grandes. Por ejemplo, es muchisimo usar la > > > > propiedad asociativa recursivamente y calcular > > > > > (1*2) * (3*4) * ... (9999 * 10000) > > > > > y luego > > > > > ((1*2) * (3*4)) * ((5*6) * (7*8)) * ... > > > > > y asi hasta llegar al resultado. Pero eso no se dice... > > > > > c) calcular 10000 factorial en C?... vas a necesitar GMP, pero esa es > > > > una libreria dedicada a numeros grandes, en vez de un lenguaje pensado > > > > para uso general sin objetivos demasiado especificos. Por algo GMP no > > > > viene standard en C. Pero entonces no estamos comparando la misma > > > > cosa... > > > > > d) ademas, en Smalltalk vas a tener que incluir la comparacion del > > > > garbage collect de los resultados intermedios contra el garbage > > > > collect (manual o automatico) de los resultados intermedios en otro > > > > lenguaje... no es tan facil comparar. > > > > > Andres. > > > > > 2010/9/10 [hidden email] <[hidden email]>: > > > > > > Gabriel, > > > > > Disculpame si lo dije mal, el punto es que siempre parece que se > > apela > > > > > a JPMorgan para mostrar que Smalltalk se usa (yo lo hago a veces). Y > > > > > como he hecho sistemas para bancos en Smalltalk, Java y Visual Basic, > > > > > no me termina de convencer como argumento válido. Mucho mas cuando la > > > > > estrella de los sistemas bancarios suele ser Cobol, y a buena honra. > > > > > Igual puede que tengas razón en este punto. > > > > > > Respecto a la lentitud no estoy de acuerdo, creo que es un tema de > > > > > definir qué es velocidad. Si velocidad es cronometraer un loop, > > > > > entonces lo mas rápido es agarrar una pila y conectar un cable entre > > > > > los polos. Pero de qué sirven los test sobre torres de hanoi? son > > > > > útiles para cosas muy básicas, pero con un mínimo de complejidad (muy > > > > > poco) se hace inútil la velocidad de ejecución de instrucciones y > > > > > pasan a ser mucho mas importantes otras cosas, como la administración > > > > > de memoria por ejemplo. Y con un poquitito mas de complejidad pasan a > > > > > ser mas importantes la capacidad de abstracción y lidiar con la > > > > > complejidad. Y digo mas importantes desde el punto de vista de > > > > > velocidad. Evaluar 10000 factorial es una prueba de todo eso (es la > > > > > prueba de Smalltalk que mas me gusta). > > > > > > Yo tengo un sistema de inteligencia de negocios por ejemplo, que hace > > > > > cosas muchisimo mas rápido que cualquier base de datos programadas en > > > > > C. Y son cosas que solo puedo hacer en Smalltalk, en cualquier otra > > > > > cosa serían impracticables. Saludos. > > > > > > Diego > > > > > > On Sep 10, 3:46 pm, Gabriel Brunstein <[hidden email]> wrote: > > > > >> Diego, yo fui el que di esos ejemplos, porque me pareció adecuado > > decir que > > > > >> en la empresa en donde trabajo hacemos software para esos bancos que > > son > > > > >> importantes. Lo dije como ejemplo de software complejos y "serios", > > ya que > > > > >> alguien ahí opinaba que en Smalltalk no se puede hacer algo así. > > > > >> Con respecto a la lentitud, que acaso hay que mentir? Smalltalk > > suele > > > > >> consumir más recursos que C++ por ejemplo, lo que hay que ver es > > cuando es > > > > >> crítico ese factor y cuando no... > > > > >> Igualmente son solo opiniones. > > > > >> Saludos. > > > > > >> 2010/9/10 [hidden email] <[hidden email]> > > > > > >> > Hay que reconocer que el tipo ese que habla mal de Smalltalk > > conoce > > > > >> > algo, sabe lo que es VisualWorks o Seaside. Yo no sabría ni a qué > > > > >> > compilador de C o Java pegarle hoy en día. Lo mas típico de esos > > foros > > > > >> > es ver como los amantes de Smalltalk lo entierran diciendo que es > > > > >> > lento o que lo usa tal o cual banco. También coincido que con > > > > >> > Smalltalk no se puede hacer nada serio, y supongo que es el motivo > > por > > > > >> > el que estoy en esto. > > > > > >> > Diego > > > > > >> > On Sep 10, 2:14 pm, Jose Gregoris <[hidden email]> > > wrote: > > > > >> > > da la cara vengador enmascarado aahhahah > > > > > >> > > --- El vie 10-sep-10, Jose Gregoris <[hidden email]> > > escribió: > > > > > >> > > De: Jose Gregoris <[hidden email]> > > > > >> > > Asunto: Re: [clubSmalltalk] Smalltalk en ADVA > > > > >> > > Para: [hidden email] > > > > >> > > Fecha: viernes, 10 de septiembre de 2010, 16:03 > > > > > >> > > Hola gente , Esteban > > > > > >> > > no se pierdan los últimos comentarios ahahahha > > > > >> > > es para descostillarse ahahahah. Alguien que usa ST contesto > > al estilo > > > > >> > diego y es genial ahhahahah. > > > > >> > > Hace rato no me reía así ahahhahha > > > > > >> > > saludos > > > > > >> > > --- El vie 10-sep-10, Esteban A. Maringolo < > > [hidden email]> > > > > >> > escribió: > > > > > >> > > De: Esteban A. Maringolo <[hidden email]> > > > > >> > > Asunto: Re: [clubSmalltalk] Smalltalk en ADVA > > > > >> > > Para: [hidden email] > > > > >> > > Fecha: viernes, 10 de septiembre de 2010, 14:25 > > > > > >> > > Kiko: > > > > > >> > > No te gastes... cada cual tiene con qué programar a su gusto. > > > > >> > > Por suerte existe Smalltalk. > > > > > >> > > Saludos! > > > > > >> > > Esteban A. Maringolo > > > > > >> > > -- > > > > >> > > To post to this group, send > > > > >> > > email to [hidden email] > > > > >> > > To unsubscribe from this group, send email to > > > > >> > [hidden email]<clubSmalltalk%2Bunsubscribe@googlegroups.com> > > <clubSmalltalk%2Bunsubscribe@googlegroups.com> > > > > > >> > >http://www.clubSmalltalk.org > > > > > >> > > -- > > > > > >> > > To post to this group, send email to > > [hidden email] > > > > > >> > > To unsubscribe from this group, send email to > > > > >> > [hidden email]<clubSmalltalk%2Bunsubscribe@googlegroups.com> > > <clubSmalltalk%2Bunsubscribe@googlegroups.com> > > > > > >> > >http://www.clubSmalltalk.org > > > > > >> > -- > > > > >> > To post to this group, send email to > > [hidden email] > > > > >> > To unsubscribe from this group, send email to > > ... > > read more »- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Respecto a los negativos, mas allá de la definición matemática, -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
On Sep 15, 8:50 am, Gabriel Brunstein <[hidden email]> wrote: > > Respecto a los negativos, mas allá de la definición matemática, > > remarco que los métodos no siempre se pueden enviar a todos los > > objetos posibles del dominio de una clase. En general los métodos no > > resuelven todo lo que un receptor de esa clase puede devolver, y sería > > un error hacer programación defensiva con eso. Asi como no se le puede > > enviar #copyFrom: 5 a cualquier String, ni #new a cualquier clase, ni > > #arcCos a cualquier Float. La responsabilidad en el envió de un > > mensaje está del lado del emisor y no del receptor o método que lo > > resuelve. > > Cuando se envía un mensaje, hay un contrato implícito entre el emisor y el > receptor. En mi opinión, si ese contrato se rompe (por ejemplo: > colaboradores no válidos), se debería producir una excepción. Eso es adecuado cuando se trabaja con interfaces (como en cualquier OOP), pero en Smalltalk hay objetos que responden a a mensajes que no tienen un método o interfaz previamente "contratada", asi como hay mensajes que no se saben responder y existen métodos implementados en su clase (como los ejemplos que ponía). Las excepeciones yo solo las uso cuando interactúo con cosas externas a Smalltalk como archivos, librerías externas o cosas de las que no tengo control, y tengo que atajar lo que venga. Dentro de Smalltalk una excepción generalmente esconde los detalles mas ricos de un "error" y es preferible no usarlas. Quién define la interfaz de un objeto es el emisor, por eso generalmente se escriben los mensajes antes que los métodos. Un Saludo. Diego -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
No entiendo a que te referís con que eso es adecuado cuando se trabaja con interfaces. Si te referís a interfaces como las de java, lo único que especifican son los tipos y no la semántica de los mensajes a los que puede responder un objeto. Saber cuando un contrato se está rompiendo es una cuestión de semántica y no necesariamente de tipos.
Por otro lado, no entiendo a que te referís con que con las excepciones se esconden los detalles más ricos de un error, me interesa ese punto de vista, podrías explicarlo un poco más? 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 dcoronel32@gmail.com
Sí, estoy de acuerdo en lo que decís. Solo quería poner que el método si "terminaba" para los negativos. Después que pasa con el factorial de un negativo es discutible porque no está definido matematicamente así que podría devolver 1 o tirar una excepción. También si tuvieramos modelados los Naturales más el cero podrías implementar el método solo ahí.
Otro saludo. 2010/9/15 [hidden email] <[hidden email]> Facundo, To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Está bueno eso, incluso serái interesante jugar con clases como Cero o
Uno, asi como hacemos con True y False. El método que escribí sería mas lindo. Nos sacaríamos IFs por todos lados (y supongo que nos ganaríamos otros problemas) On Sep 15, 9:22 am, Facundo Vozzi <[hidden email]> wrote: > Sí, estoy de acuerdo en lo que decís. Solo quería poner que el método si > "terminaba" para los negativos. Después que pasa con el factorial de un > negativo es discutible porque no está definido matematicamente así que > podría devolver 1 o tirar una excepción. También si tuvieramos modelados los > Naturales más el cero podrías implementar el método solo ahí. > > Otro saludo. > > 2010/9/15 [hidden email] <[hidden email]> > > > > > Facundo, > > Tenés razón, pero tal vez lo que hice peor fue escribir código > > Smalltalk fuera de Smalltalk (en un mail) dando a entender de que era > > un algortímo cuando no lo es. No solo porque Smalltalk me hubiese > > avisado de ese punto que decis, sino porque no considero el ambiente, > > que es lo mas importante. Y no alcanzaría con especificar la clase del > > método, debería especificar todos los métodos y clases del ambiente, > > los objetos instanciados, todo... y seguiría sin alcanzar porque es un > > ambiente. Lo digo desde el punto de vista práctico (creo filosofía en > > esto). > > Respecto a los negativos, mas allá de la definición matemática, > > remarco que los métodos no siempre se pueden enviar a todos los > > objetos posibles del dominio de una clase. En general los métodos no > > resuelven todo lo que un receptor de esa clase puede devolver, y sería > > un error hacer programación defensiva con eso. Asi como no se le puede > > enviar #copyFrom: 5 a cualquier String, ni #new a cualquier clase, ni > > #arcCos a cualquier Float. La responsabilidad en el envió de un > > mensaje está del lado del emisor y no del receptor o método que lo > > resuelve. > > > Saludos, > > Diego > > > On Sep 15, 6:44 am, Facundo Vozzi <[hidden email]> wrote: > > > Si termina, lo que no estaría bien es que -10 factorial devolvería 1 > > cuando > > > el factorial de -10 no esta definido,según recuerdo, matemáticamente. > > > Lo único que tiene mal el método (por si querés probarlo) de Diego es el > > > punto al final del ifTrue: [] > > > > Saludos, > > > Facundo > > > > 2010/9/15 Guillermo Schwarz <[hidden email]> > > > > > Off topic, pero tu algoritmo no termina si se le pasa un número > > > > negativo... > > > > > factorial > > > > "Returns the factorial of the receiver." > > > > > ^self <= 0 > > > > ifTrue: [1]. > > > > ifFalse: [self * (self - 1) factorial]. > > > > > Para comparar las soluciones en distintos lenguajes habría que hacer un > > > > benchmark. Esos benchmarks existen, no veo la razón para hacerlos de > > nuevo > > > > acá. Gana SML siempre. > > > > > Una de las optimizaciones que hacen los compiladores se llama tail > > > > recursion elimination y consiste en que la llamada recursiva final se > > > > reemplaza por un goto al principio del método. > > > > > ¿Porqué sería tan importante la velocidad en RAM? > > > > > En la práctica la velocidad de acceso a disco lo domina todo. Un disco > > más > > > > rápido hace toda la diferencia y hasta el momento los SSD son los más > > > > rápidos. > > > > > Saludos, > > > > Guillermo. > > > > > On Mon, 2010-09-13 at 06:45 -0700, [hidden email] wrote: > > > > > Hay varias implementaciones de factorial, pero la que haría un > > > > > Smalltalker, al menos inicialmente, sería: > > > > > > factorial > > > > > "Returns the factorial of the receiver." > > > > > > ^self = 0 > > > > > ifTrue: [1]. > > > > > ifFalse: [self * (self - 1) factorial]. > > > > > > Esta implementación, con mucho por mejorar sigue siendo rápida y > > > > > "esconde" cosas que en otros lenguajes son evidentes y complejas. > > Como > > > > > decías el GC es importante , otra cosa es el operador "*", que podría > > > > > ejecutarse en distintas clases según el tamaño del receptor, gracias > > > > > el carácter dinámico de Smalltalk y a que los números son objetos. > > > > > Quienes además conocen la implementación interna de Smalltalk, como > > > > > vos, tal vez puedan agregar muchos detalles de la implementación de > > > > > todo esto. Pero tal vez, lo que hace rápido en Smalltalk, es que un > > > > > ignorante (como yo) puede hacer algo rápido y de forma muy natural y > > > > > obvia. > > > > > > Yo pondría el esfuerzo por hacer algo rápido como parte de la > > > > > comparación entre lenguajes. Porque hay esfuerzos que son > > > > > impracticables, entonces en la práctica no se hacen y terminan como > > > > > sistemas lentos en C/C++. Cargar una librería C solo sirve para lo ya > > > > > resuelto, sería bueno saber cuánto esfuerzo requiere hacer esa > > > > > librería C (en Smaltalk escribir #factorial llevaría 2 líneas si no > > > > > estuviera hecho). > > > > > > Diego > > Coronelbegin_of_the_skype_highlighting end_of_the_skype_highlighting > > > > > > On Sep 10, 8:24 pm, Andres Valloud <[hidden email]> wrote: > > > > > > En general menciono a JP Morgan porque trabaje ahi, pero Cincom > > tiene > > > > > > pila de bancos de clientes... > > > > > > > Calcular 10000 factorial simplemente mide > > > > > > > a) la velocidad de la primitiva que multiplica large integers (que > > en > > > > > > general se implementa con el algoritmo simple de la primaria porque > > es > > > > > > rapido para numeros chicos, asi que cuando se usa con numeros > > > > > > gigantescos entonces no es tan bueno, ver por ejemplohttp:// > > > > blogten.blogspot.com/2008/07/mr-karatsuba.htmly similares), > > > > > > > b) la velocidad de la implementacion de factorial, que en general > > es > > > > > > algo asi como > > > > > > > | answer | > > > > > > self < 0 ifTrue: [self error]. > > > > > > self < 2 ifTrue: [^1]. > > > > > > answer := 1. > > > > > > 2 to: self do: [:each | answer := answer * each]. > > > > > > ^answer > > > > > > > y que en general es mas o menos la peor manera posible de > > implementar > > > > > > factorial para argumentos grandes. Por ejemplo, es muchisimo usar > > la > > > > > > propiedad asociativa recursivamente y calcular > > > > > > > (1*2) * (3*4) * ... (9999 * 10000) > > > > > > > y luego > > > > > > > ((1*2) * (3*4)) * ((5*6) * (7*8)) * ... > > > > > > > y asi hasta llegar al resultado. Pero eso no se dice... > > > > > > > c) calcular 10000 factorial en C?... vas a necesitar GMP, pero esa > > es > > > > > > una libreria dedicada a numeros grandes, en vez de un lenguaje > > pensado > > > > > > para uso general sin objetivos demasiado especificos. Por algo GMP > > no > > > > > > viene standard en C. Pero entonces no estamos comparando la misma > > > > > > cosa... > > > > > > > d) ademas, en Smalltalk vas a tener que incluir la comparacion del > > > > > > garbage collect de los resultados intermedios contra el garbage > > > > > > collect (manual o automatico) de los resultados intermedios en otro > > > > > > lenguaje... no es tan facil comparar. > > > > > > > Andres. > > > > > > > 2010/9/10 [hidden email] <[hidden email]>: > > > > > > > > Gabriel, > > > > > > > Disculpame si lo dije mal, el punto es que siempre parece que se > > > > apela > > > > > > > a JPMorgan para mostrar que Smalltalk se usa (yo lo hago a > > veces). Y > > > > > > > como he hecho sistemas para bancos en Smalltalk, Java y Visual > > Basic, > > > > > > > no me termina de convencer como argumento válido. Mucho mas > > cuando la > > > > > > > estrella de los sistemas bancarios suele ser Cobol, y a buena > > honra. > > > > > > > Igual puede que tengas razón en este punto. > > > > > > > > Respecto a la lentitud no estoy de acuerdo, creo que es un tema > > de > > > > > > > definir qué es velocidad. Si velocidad es cronometraer un loop, > > > > > > > entonces lo mas rápido es agarrar una pila y conectar un cable > > entre > > > > > > > los polos. Pero de qué sirven los test sobre torres de hanoi? son > > > > > > > útiles para cosas muy básicas, pero con un mínimo de complejidad > > (muy > > > > > > > poco) se hace inútil la velocidad de ejecución de instrucciones y > > > > > > > pasan a ser mucho mas importantes otras cosas, como la > > administración > > > > > > > de memoria por ejemplo. Y con un poquitito mas de complejidad > > pasan a > > > > > > > ser mas importantes la capacidad de abstracción y lidiar con la > > > > > > > complejidad. Y digo mas importantes desde el punto de vista de > > > > > > > velocidad. Evaluar 10000 factorial es una prueba de todo eso (es > > la > > > > > > > prueba de Smalltalk que mas me gusta). > > > > > > > > Yo tengo un sistema de inteligencia de negocios por ejemplo, que > > hace > > > > > > > cosas muchisimo mas rápido que cualquier base de datos > > programadas en > > > > > > > C. Y son cosas que solo puedo hacer en Smalltalk, en cualquier > > otra > > > > > > > cosa serían impracticables. Saludos. > > > > > > > > Diego > > > > > > > > On Sep 10, 3:46 pm, Gabriel Brunstein <[hidden email]> wrote: > > > > > > >> Diego, yo fui el que di esos ejemplos, porque me pareció > > adecuado > > > > decir que > > > > > > >> en la empresa en donde trabajo hacemos software para esos bancos > > que > > > > son > > > > > > >> importantes. Lo dije como ejemplo de software complejos y > > "serios", > > > > ya que > > > > > > >> alguien ahí opinaba que en Smalltalk no se puede hacer algo así. > > > > > > >> Con respecto a la lentitud, que acaso hay que mentir? Smalltalk > > > > suele > > > > > > >> consumir más recursos que C++ por ejemplo, lo que hay que ver es > > > > cuando es > > > > > > >> crítico ese factor y cuando no... > > > > > > >> Igualmente son solo opiniones. > > > > > > >> Saludos. > > > > > > > >> 2010/9/10 [hidden email] <[hidden email]> > > > > > > > >> > Hay que reconocer que el tipo ese que habla mal de Smalltalk > > > > conoce > > > > > > >> > algo, sabe lo que es VisualWorks o Seaside. Yo no sabría ni a > > qué > > > > > > >> > compilador de C o Java pegarle hoy en día. Lo mas típico de > > esos > > > > foros > > > > > > >> > es ver como los amantes de Smalltalk lo entierran diciendo que > > es > > > > > > >> > lento o que lo usa tal o cual banco. También coincido que con > > > > > > >> > Smalltalk no se puede hacer nada serio, y supongo que es el > > motivo > > > > por > > > > > > >> > el que estoy en esto. > > ... > > read more »- Hide quoted text - > > - Show quoted text - -- 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 Gaboto
> No entiendo a que te referís con que eso es adecuado cuando se trabaja con > interfaces. Si te referís a interfaces como las de java, lo único que > especifican son los tipos y no la semántica de los mensajes a los que puede > responder un objeto. Saber cuando un contrato se está rompiendo es una > cuestión de semántica y no necesariamente de tipos. Por ejempo si tenés una caja negra cerrada, como un componente (o una clase en lenguajes donde hay cosas privadas), lo único que te queda es ese contrato con la interfaz de eso. > Por otro lado, no entiendo a que te referís con que con las excepciones se > esconden los detalles más ricos de un error, me interesa ese punto de vista, > podrías explicarlo un poco más? Supongo que no leí bien tu correo, me refería a atrapar excepciones como una mala práctica y creo que vos hablabas de generarlas. -- 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 Gaboto
Claro, pero la semántica de las interfaces en Java puede estar definida en pruebas unitarias.
Definirla en clases (donde está la implementación) no tiene sentido si estás trabajando contra interfaces.
Luego habría que ejecutar las pruebas sobre todas las clases que implementen las interfaces. Saludos, Guillermo.
-- 2010/9/15 Gabriel Brunstein <[hidden email]>
-- 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 dcoronel32@gmail.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 |
|
|
On Sep 16, 7:02 am, Jose Gregoris <[hidden email]> wrote:
> Hola Diego > > Me comentas como usas el manejo de excepciones . > Donde usas #error: y donde Exception ? > > saludos kiko Hola Kiko, No se si hay recetas que puedan aplicarse siempre pero generalmente uso #error: para evitar una respuesta incorrecta, pero no para documentar mejor un error, ni mucho menos para atrapar otro error y luego disparar el mio. Si envio un mensaje con un argumento inadecuado y la implementación dél método, en lugar de generar un error, devuelve un resultado incorrecto, ahi disparo #error:. Respecto a las excepciones no las uso hasta que interactúo con algo externo a Smalltalk, porque el problema es que al atrapar un error lo mas probable es este se haya generado varios mensajes antes y al atraparlo estoy perdiendo toda esa información. Creo que los errores deben considerarse como algo muy bueno en un sistema, porque subrayan las diferencias entre el modelo y la realidad. Por eso trato de no taparlos y hacerlos bien evidentes y con toda la información posible, especialmente en sistemas en producción. Está claro que llenar el sistema de "error trapping" nos dejaría un sistema sin cartelitos feos, pero un cartelito no es peligroso en producción (solo se enoja el usuario) ni tampoco es tan grave que el sistema se cuelgue de la peor manera. Lo mas dañino es que pasen cosas incorrectas y nadie se entere, como un sistema de facturación que pierda facturas, o un firewall que no proteja, o un sistema de cálculo que calcule mal... de esas cosas no se vuelve. Igual, como te decía, no son recetas y hay muchos grises. Un saludo. Diego -- 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 Jose Gregoris
Este martes vino un tipo a mi escuela que si no me equivoco se llamaba
"Mario Benedetti" o algo parecido, a dar una charla... bueno la cosa es que es un argentino que trabaja en el LHC "La maquina de Dios", al final de la charla dijo, lo que hagan, haganlo por amor no por la plata y veran como todo vuelve a uno. y con respecto a ese banana del foro "es una plataforma aislada que vive en su propio mundo" tengo que decir que, que lindo es mi mundo y como me gusta. -- 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 dcoronel32@gmail.com
El día 15 de septiembre de 2010 10:39, [hidden email]
<[hidden email]> escribió: > Facundo, > Tenés razón, pero tal vez lo que hice peor fue escribir código > Smalltalk fuera de Smalltalk (en un mail) ... [..] Ahora bien, el *entorno* de trabajo Smalltalk, llevado a su extremo, ¿no incluye MUA? En ese caso, cualquier panel de edición te permitiría inspeccionar/hacer/evaluar código :) (pun intended) ¿Cómo sería una pc-smalltalk? O mejor dicho, ateniéndose a la historia, ¿cómo sería una pc? Es claro que hardware único, placa única de red y de vídeo, pocos drivers para desarrollar, nada de expandir (eso crea necesidad de más drivers) O sea, el que fabrica el entorno de software, más vale que fabrique el hardware y de esa manera ajuste uno con otro. Hay una cita por ahí de Alan Kay sobre esto, ¿no? Apple parece que hace eso, aunque eligió un pariente de Smalltalk. FORTH se ha aprovechado del hardware especial fabricado por otros. Aunque debo reconocer que los lenguajes concatenativos me atraen, soy sólo un fan que va a la tribuna, no a la platea. ¿Qué queda para nosotros por explorar? * Consolas de video juegos * arduino? (con minúsculas no tiene nada que ver con German :) * OLPC? * netbooks? hardware no tan específico, debo reconocer, un híbrido de OLPC y PC De paso, ¡qué atractiva la Squeak-NOS! Se ve que ahí también chocan con el problema de la multiplicidad de dispositivos que deben funcionar. Tiene esa atracción fatal: te lleva hacia ella, pero después no sabés como alejarte :) Si te quedás, la variación de hardware te mata; la virtualización del hardware puede ser una salida de ese dilema. A lo mejor la salida esta por ahí, ¿no?: Establecer una virtualizción del hardware (tipo Qemu, o algo así) que provea placas de red y otros con virtio, de manera que sean altamente eficientes, y que al final sean UNA sola máquina posible. Encima de ese hardware virtualizado se puede meter la VM de Smalltalk, y como dicen los matemáticos, "estamos en el caso anterior". A lo mejor habrá que refrasear a Alan Kay diciendo que los que verdaderamente se preocupan por su software, diseñan sus propios emuladores de hardware virtual. Bueno, espero no aburrirlos con mi off-topic de ADVA, pero aquí calzaba bien, porque la programación de video juegos muchas veces trata con hardware especial y que la imagen cargada hace todo lo que se necesita para interactuar con el sistema. Lo cual nos lleva de nuevo al problema de escribir mail fuera de Smalltalk, actividad que sería una contradicción en uno de estos entornos. Y eso nos hace pensar en cómo serían las pc... Un abrazo! -- It's not enough to teach students to surf the Net, we must teach them to make waves. My pedagogical theory is relate, create, donate, which suggests that students work in teams, create ambitious projects and then donate these to people who can use and build upon them. --Ben Shneiderman -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola:
Mario Benedetti o "-algo parecedio-" se murió hace un año jajaja, 17 de mayo 2009. Efectivamente este señor -el ingeniero- se llama igual que el escritor -el talentoso- :). Lo mismo que dice y parece soreprenderte respecto al amor y el dinero lo dice cristo, buda, osho, el dalai lama, ekhart tolle y tantos otros iluminados espirituales que no conocimos y nada tienen tuvieron o tendrán que ver con la ciencia; ergo, no ha dicho algo que ya no supieramos :) todos somos dioses, supremos y perfectos, en conexión y armonía con el universo, pero faltos de luz y conciencia para darnos cuenta. great off-topic, ya que estamos.....
-- "...Establecer una virtualizción del hardware (tipo Qemu, o algo así) que
provea placas de red y otros con virtio, de manera que sean altamente eficientes, y que al final sean UNA sola máquina posible..." Lo veo poco performante, al hardware no hay con que darle.
Respecto al arduino, no se, pero cuando haga correr una vm en el SAM9M10 que tengo en casa te cuento que onda con los embebidos :D
Saludos. 2010/9/17 Cesar Ballardini <[hidden email]> El día 15 de septiembre de 2010 10:39, [hidden email] 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 Cesar Ballardini-2
On 09/17/2010 02:38 PM, Cesar Ballardini wrote:
> Ahora bien, el *entorno* de trabajo Smalltalk, llevado a su extremo, > ¿no incluye MUA? En ese caso, cualquier panel de edición te > permitiría inspeccionar/hacer/evaluar código :) (pun intended) > SqueakNOS :) Supongo que en la Smalltalks 2010 van a presentar algo nuevo que están cocinando en este mismo momento! saludos! richie -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
El día 18 de septiembre de 2010 15:38, Gerardo Richarte
<[hidden email]> escribió: > On 09/17/2010 02:38 PM, Cesar Ballardini wrote: >> Ahora bien, el *entorno* de trabajo Smalltalk, llevado a su extremo, >> ¿no incluye MUA? En ese caso, cualquier panel de edición te >> permitiría inspeccionar/hacer/evaluar código :) (pun intended) >> > SqueakNOS :) > > Supongo que en la Smalltalks 2010 van a presentar algo nuevo que > están cocinando en este mismo momento! > Después de escribir el mail, y mientras buscaba un entorno de desarrollo que pueda caber sobre J2ME (mi celular no admite muchas cosas que son interesantes) me encontré con esto: http://ngaro.jottit.com/ ¿SqueakNOS -> Squeak/ngaro para cuando? :)) Aguante richie! PD: bueno, ngaro2 será, porque ngaro parece bastante flaco para la tarea, pero la idea sique la misma, usar una máquina virtual, con énfasis en "máquina", algo como el legendario MIX de Knuth, y no algo con miras a un conjunto de bytecodes a ejecutar. -- It's not enough to teach students to surf the Net, we must teach them to make waves. My pedagogical theory is relate, create, donate, which suggests that students work in teams, create ambitious projects and then donate these to people who can use and build upon them. --Ben Shneiderman -- 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 |