> ¿No será que los Smalltalkers son todos revolucionarios? Jaja... :).
> Aparte, te comento que el que uso yo, si tiene eso, ni se nota... > ¿Como se da uno cuenta si el Smalltalk que usa tiene "undefined behavior"? A mi por lo menos me pasa seguido de enterarme cuando un cliente grande viene y dice algo como "nuestra aplicacion [que no puede fallar porque xyz] se cuelga una vez por mes en 2 de las N maquinas en produccion --- arreglen eso". Y ahi si te queres matar. Donde esta el error? Como lo reproducis? Y cuando finalmente lo encontras y ves que es algo del estilo undefined behavior, despues de varias semanas de rascarse la cabeza... que se puede decir. Ahi si te empiezan a importar los standards, porque te duele el cuero cabelludo de tanto rascar. Tambien nos pasa que estamos revisando algo que no tiene que ver, y nos damos cuenta de que otra cosa tampoco sigue su standard correspondiente (o sea, "undefined behavior"). Ahi ya te molesta porque sabes que tarde o temprano el undefined behavior va a saltar por algun lado. Ahora bien, imaginate que tenes, no se, 10 de estos problemas dando vueltas por ahi. Arreglarlos no es facil. A cuatro semanas por problema, tenes basicamente un año de sufrir sin poder programar cosas nuevas. Y entonces si que es serio lo de los standards. > ¿Tenes un conjunto de tests para eso o solo podrias saberlo revisando el > codigo de la vm nada mas? A medida que encontramos estas cosas agregamos tests. Si ves el problema en el codigo, seguro que es serio porque es demasiado obvio. O sea, si el problema es evidente, entonces te asusta pensar que el que programo las cosas ni miro el standard. Pero... no siempre es posible darse cuenta mirando el codigo asi no mas. A veces necesitas un test case... pero, y si no es deterministico porque el behavior es undefined?... Bueh. Ese es el problema... no seguis los standards, y entonces tenes esta clase de quilombos. Y no es solo para la VM... suponete que usas DLLCC o algun equivalente para llamar al sistema operativo y usar sockets o lo que fuera. Eso si que esta super mal. Andres. > > Saludos > GallegO > > > El 25 de julio de 2009 14:22, Andres Valloud <[email protected]> > escribió: >> >> No te parece que estaria copado que nuestros Smalltalks no tuvieran >> "undefined behavior? Bueno, como logramos eso cuando en general no >> nos importan los standards? >> >> 2009/7/25 Esteban A. Maringolo <[email protected]>: >> > >> > Andrés: >> > >> > Concuerdo mucho con lo que decis, pero no entiendo a que apunta tu >> > comentario. >> > >> > >> > Saludos. >> > >> > Esteban A. Maringolo >> > >> > >> > >> > El 25 de julio de 2009 01:38, Andres Valloud<[email protected]> >> > escribió: >> >> >> >> Es preferible hacer las cosas, totalmente. A eso le agregaria que no >> >> todo lo que brilla tiene que ser Smalltalk :). Por poner ejemplos >> >> propios... cuando aprendi Smalltalk deje de programar todos los dias >> >> en Pascal/assembler pensando que lo que habia hecho era totalmente >> >> obsoleto. Lo de la obsolescencia probablemente siga siendo cierto. >> >> Pero, siendo que hoy trabajo todos los dias en C, tengo que decir que >> >> C no me parece tan horrible. >> >> >> >> Bueno, ahora, un comentario al margen. Segun lo que voy aprendiendo >> >> del mundo procedural, hay cosas que si hacen que C sea horrible. Es >> >> super importante entender como la mentalidad estandar de programar >> >> Smalltalk se lleva a las patadas con la realidad de lo que es >> >> programar para la mayoria. Por ejemplo, esta el tema de los >> >> standards. A nosotros los Smalltalkers en general (y segun mi >> >> experiencia), los standards no nos importan. Una consecuencia de esto >> >> es que, en la imagen, lo normal es *no ver* objetos que dependen del >> >> sistema operativo segun sus standards correspondientes. De hecho, >> >> demasiadas veces se considera razonable tomar la decision conciente de >> >> *ignorar* los standards y APIs del sistema operativo o libreria que >> >> corresponda. >> >> >> >> Que importa de esto? Que entonces es *imposible* predecir la conducta >> >> de nuestro programa. Lo peor es que, entonces, nuestros programas >> >> *parecen* funcionar. Me cuesta encontrar una expresion que comunique >> >> la violencia intelectual que implica decir que algo *parece* >> >> funcionar. No es una especie de "me rindo, no le encuentro mas bugs". >> >> Es mucho peor, es decir que el hecho de que un programa funcione es >> >> simplemente un *accidente*. >> >> >> >> Los ejemplos concretos son brutales. Por ejemplo, supongamos que >> >> estamos escribiendo una maquina virtual para Linux. Pues bien, algo >> >> que hay que escribir son los signal handlers. Los signal handlers >> >> tienen su standard, y el standard dice que los signal handlers se >> >> pueden escribir usando funciones de una lista limitada. Pueden ver la >> >> lista si van a http://www.unix.org/single_unix_specification/ (no >> >> cuesta registrarse) y se fijan casi al final del articulo "signal >> >> concepts". Al final de la lista, el standard dice: >> >> >> >> "All functions not in the above table are considered to be unsafe with >> >> respect to signals. In the presence of signals, all functions defined >> >> by this volume of IEEE Std 1003.1-2001 shall behave as defined when >> >> called from or interrupted by a signal-catching function, with a >> >> single exception: when a signal interrupts an unsafe function and the >> >> signal-catching function calls an unsafe function, the behavior is >> >> undefined." >> >> >> >> Una funcion que no esta en la lista es printf(). Por lo tanto, no es >> >> seguro usar printf() en signal handlers para debuggear cosas. Ahora, >> >> supongamos que uno "es macho y se la banca" (digamos) y usa printf() >> >> lo mismo. Para debuggear, entonces, el programa puede *parecer* >> >> funcionar. Sin embargo, el standard dice: >> >> >> >> "All functions not in the above table are considered to be unsafe with >> >> respect to signals [...] when a signal interrupts an unsafe function >> >> and the signal-catching function calls an unsafe function, the >> >> behavior is undefined." >> >> >> >> El tema es esa palabrita, "undefined". Si nuestro programa llega al >> >> punto de tener *undefined behavior*, entonces, desde el momento que >> >> (en nuestro ejemplo) se ejecuta printf() en un signal handler, no es >> >> posible hacer ninguna suposicion acerca de nada. Si nuestro programa >> >> parece funcionar, pues bien gracias, pero nada dice que en alguna otra >> >> oportunidad la conducta no vaya a ser "formatear todos los discos, >> >> seguido de un colgazo". >> >> >> >> En terminos practicos, cada vez que un standard de esta naturaleza >> >> dice "undefined behavior", el 99.9% de las veces se puede reemplazar >> >> "undefined behavior" por "segmentation fault". Y ese, exactamente, es >> >> el problema de ignorar los standards. Hay standards (o, en su >> >> defecto, documentacion) para un monton de cosas. Sockets, archivos, >> >> memoria, graficos, dispositivos externos, librerias, el sistema >> >> operativo, etc. O sea, ignorar los standards hacen que basicamente >> >> cualquier cosa interesante que hagamos tiene, en efecto, "undefined >> >> behavior". >> >> >> >> Cuando programamos en Smalltalk, lo mas normal es que no nos importen >> >> ninguno de estos (voluminosos!!!) standards o tomos de documentacion. >> >> Es tan facil crear cosas nuevas que a veces caemos en el vandalismo >> >> inverso del que habla Alan Kay... hacer cosas porque es posible >> >> hacerlas. Para cosas como los objetos del dominio, o para los objetos >> >> del negocio, o para estructurar los requerimientos del cliente, esa >> >> actitud puede ser increiblemente productiva y Smalltalk esta mandado a >> >> hacer para ayudar en esta clase de trabajo. Pero para todo lo que >> >> tenga documentacion, como www.msdn.com (por mas mala que sea), o el >> >> Single Unix Specification, la actitud de reinventar las cosas porque >> >> en Smalltalk seguro sale mejor *no sirve*. Simplemente, es una >> >> actitud incompatible con la realidad. >> >> >> >> Desde que programo maquinas virtuales, esto es cada vez mas obvio para >> >> mi. Pero, hace 3 años, si alguien me hubiera preguntado acerca del >> >> Single Unix Specification, habria contestado "lo que?". Eso es lo >> >> triste. Supongo que hay Smalltalkers mucho mas iluminados que yo. >> >> Sin embargo, despues de leer standards y programar cosas segun dice el >> >> standard, es increiblemente dificil convencer a Smalltalkers >> >> "promedio" de que no esta bien pensar cosas que, en efecto, son >> >> equivalentes a "yo soy mas genio en 3 segundos que miles de personas >> >> trabajando durante años". >> >> >> >> Lo que tambien es triste es ver que no tenemos standards en Smalltalk. >> >> Si agarramos a un programador promedio, lo mas probable es que sepa >> >> que quieren decir los terminos "standard" y "documentacion". Que es >> >> lo mejor que podemos decirle a alguien que recien empieza? Esta el >> >> ANSI standard de 1998, cubre una parte de la libreria base, pero del >> >> resto (sockets, archivos, memoria, graficos, dispositivos externos, >> >> librerias, el sistema operativo, etc), depende de lo que haga cada >> >> Smalltalk. Por supuesto, esto es absolutamente ridiculo porque >> >> supuestamente todos los Smalltalks estan regidos por los mismos >> >> standards! Es decir, si Dolphin, Squeak, VA, VisualWorks y tantos >> >> otros funcionan en Windows, todos deberian tener implementaciones de >> >> sockets basicamente equivalentes que reflejen la documentacion de >> >> MSDN. Y lo mismo con archivos, memoria, graficos, dispositivos >> >> externos, librerias, y el sistema operativo. En la practica, lo mas >> >> probable es que todos ellos tengan "undefined behavior". >> >> >> >> Bueno... podria seguir, pero espero que con esto que escribi haya >> >> podido transmitir con un minimo de claridad lo que hoy hace que se me >> >> caiga el pelo. >> >> >> >> >> >> 2009/7/24 Germán Arduino <[email protected]>: >> >>> >> >>> A veces el tiempo no da y no queda otra que, para no perder la >> >>> oportunidad de hacer lo que uno necesita o desea hacer, hay que >> >>> recurrir a otros productos como el que señalás. Pero, en lo >> >>> particular, me gustaría mucho tener todos mis sitios y todo lo que >> >>> hago en Smalltalk, ya que se supone que de eso vivo y ahí está mi know >> >>> how. >> >>> >> >>> Ahora estoy en proceso de ver si armo todo el aplicativo de >> >>> venta/renovaciones/etc de webhosting en Smalltalk, veremos si me da el >> >>> tiempo y las posibilidades. >> >>> >> >>> Saludos. >> >>> >> >>> El 24 de julio de 2009 20:46, Andres Valloud<[email protected]> >> >>> escribió: >> >>>> >> >>>> Y, no se si estoy tan de acuerdo con que las paginas de Smalltalk >> >>>> tienen que estar hechas en Smalltalk... por ejemplo, a mi no me >> >>>> parece >> >>>> mal que www.visualworksforums.org este hecha en otra cosa. >> >>>> >> >>>> 2009/7/24 Mariano Martinez Peck <[email protected]>: >> >>>>> >> >>>>> >> >>>>> 2009/7/24 Pablo Gancharov <[email protected]> >> >>>>>> >> >>>>>> Llego a vos a través de un post que vi en taringa. >> >>>>>> >> >>>>>> Me presento: >> >>>>>> Soy Pablo Gancharov y soy estudiante de ingeniería en sistemas de >> >>>>>> información de la UTN, regional Concepción del Uruguay. >> >>>>>> >> >>>>>> El motivo de este mensaje es que me gusta mucho el paradigma de >> >>>>>> Objetos y >> >>>>>> estoy un poco desilusionado por la poca aceptacion que tiene >> >>>>>> Smalltalk entre >> >>>>>> los programadores, tal vez porque es muy revolucionario para los >> >>>>>> programadores y en realidad intenta que los no-programadores lo >> >>>>>> utilicen. >> >>>>>> >> >>>>>> El punto es que No me gusta que las cosas queden como están y me >> >>>>>> puse >> >>>>>> manos a la obra con un proyecto, crear una pagina web donde la >> >>>>>> comunidad de >> >>>>>> Smalltalk de habla hispana pueda compartir sus experiencias y sus >> >>>>>> códigos, >> >>>>> >> >>>>> Cualquier intento de fomentar el uso de Smalltalk es más que >> >>>>> bienvenido para >> >>>>> mí. >> >>>>> >> >>>>>> >> >>>>>> No soy un diseñador de Paginas por eso tome un CMS conocido: Drupal >> >>>>>> y lo >> >>>>>> armé, como me pareció que debe ser. >> >>>>>> >> >>>>>> >> >>>>>> Estoy trabajando solo en este momento, por eso estoy tratando de >> >>>>>> conectarme con gente que le entusiasme mi proyecto. >> >>>>>> >> >>>>>> http://www.unapalabra.eshost.com.ar/ >> >>>>>> >> >>>>>> >> >>>>>> Bueno desde ya muchas gracias y espero recibir tus consejos acerca >> >>>>>> de mi >> >>>>>> proyecto. >> >>>>> >> >>>>> El primer consejo que te puedo dar es que ni bien estes >> >>>>> familiarizado con >> >>>>> herramientas como Seaside, Pier y Magritte migres tu sitio de drupal >> >>>>> a Pier. >> >>>>> O sea, suponete alguien que está entrando en el mundo smalltalk y >> >>>>> entra a la >> >>>>> página, se va a desilucionar si no está escrita en Smalltalk. Vah, >> >>>>> no se, >> >>>>> eso es lo que me pasaría a mi ajaja. >> >>>>> >> >>>>> Te dejo los links por si te interesa y no los conoces: >> >>>>> >> >>>>> - http://www.seaside.st/ >> >>>>> - http://www.piercms.com/ >> >>>>> >> >>>>> Saludos y felicitaciones por la idea! >> >>>>> >> >>>>> Mariano >> >>>>> >> >>>>>> >> >>>>>> (Obviamente que están invitados a participar, tal ves podamos unir >> >>>>>> fuerzas) >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>> > >> >>>>> >> >>>> >> >>>> > >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Germán S. Arduino >> >>> http://www.arsol.biz >> >>> http://www.arsol.net >> >>> >> >>> > >> >>> >> >> >> >> > >> >> >> > >> > > >> > >> >> > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
