Andrés: ¿No será que los Smalltalkers son todos revolucionarios?
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"? ¿Tenes un conjunto de tests para eso o solo podrias saberlo revisando el codigo de la vm nada mas? 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 -~----------~----~----~----~------~----~------~--~---
