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 -~----------~----~----~----~------~----~------~--~---
