Justo ayer estaba pensando en cosas parecidas... disculpa el mail kilometrico, me diste un buen pie :).
> Ok, this can be controversial, so as always, this is just my point of view. I > love Smalltalk. I love browsing for senders, implementors, references, doing > refactors, browsing methods and classes, etc. If you are reading this blog, > you probably understand my feelings :) There are people who love C. Ok, I > don’t. I’ve even contributed (with code and fixes) to the OpenDBX library > (written in C), so I can do it. But…… do you know how cool is to be able to > read and modify the VM from the same image that you usually use ? SLANG is > quite limited, and sometimes it looks like C, of course, but it is still much > better than coding in C for me: No se si me da para decir que I love C, pero... hay una pila de cosas que es directamente mejor escribir en C. Este argumento es dificil de aceptar porque Smalltalk siempre es mejor y todo eso. Y si, Smalltalk es mejor para muchas cosas. Por eso nos terminamos proponiendo escribir todo en Smalltalk. Pero, nos guste o no nos guste, por ejemplo Linux esta escrito en C y compilado con su propio compilador. Si queres una maquina virtual en Linux, mas o menos que tenes dos opciones: usar GCC, o re-escribir GCC en Smalltalk. Re-escribir GCC en Smalltalk? Para que este en la imagen y se pueda jugar con el compilador y todo eso? Si, y mientras tanto si usaras GCC todo el trabajo de hacer un compilador se reduce a #> make virtualMachine Y por supuesto uno quiere maquinas virtuales para Mac y para Windows, en 32 y 64 bits (son muy diferentes). Y en otros procesadores tambien, como SPARC o POWER. Tal vez los ARM de los telefonos moviles. Y cada una de estas plataformas te obliga a tener un compilador C... Bueno, entonces usamos el que ya esta escrito. Pero porque hace falta un compilador C? Si tenemos un JIT y podemos escribir todo el assembler que se nos cante mecanicamente sin tener que escribirlo a mano, para que sirve tener un compilador C? Porque, para algunas cosas, es la unica alternativa viable. Ya dijimos que no ibamos a re-escribir los compiladores C para cada plataforma (y por suerte, porque por ejemplo el compilador de Windows es un compilador C++). Basicamente la razon de arriba es la cantidad de esfuerzo para rehacer lo que llevo miles de años hombre. No alcanza el tiempo. La otra razon es que el compilador que uno escribe tiene que ser compatible con el compilador de la plataforma. Es decir, tiene que funcionar como si fuera el compilador de la plataforma. No es suficiente producir un ejecutable a partir de algo que parezca C. Es importante asegurarse que tu programa tiene que funcionar bien cuando estan dadas las condiciones para que esto suceda. En otras palabras, esta bueno cuando otros pueden depender del software que escribiste. Y porque esto no es asi sin un compilador C compatible con la plataforma? Porque todas las APIs de los sistemas operativos tienen especificaciones que requieren cierta conducta por parte del programa que las usa. Si uno viola las especificaciones... bueno, alla uno. Tarde o temprano aparecen bugs horribles que solo suceden una vez cada 3 meses. O si no, cosas raras como por ejemplo compilas hoy y funciona, compilas mañana y no funciona. O tenes que bajar el nivel de optimizacion porque si no la maquina virtual se cuelga. O no funciona el debugger de la plataforma porque el compilador que usamos todavia no implementa la ultima version de la informacion de debug (por ejemplo, en Windows hay varias de estas). Pero entonces como nos aseguramos de que las cosas funcionan? En C, la ley del oeste es la especificacion. No te queda otra, hay que cumplir la ley. No es opcional. Y si no es opcional, tarde o temprano uno termina diciendo "pero si ya una montaña de gente escribio el compilador, para que lo voy a re-escribir yo si total lo unico que hay que escribir para usarlo es #> make virtualMachine?". Bueno, entonces por lo menos el codigo que tiene que ver con la plataforma hay que escribirlo en C. De cuanto codigo estamos hablando? Justo esto estaba mirando ayer. En la maquina virtual de VisualWorks hay varias divisiones en el codigo. Por ejemplo estan los makefiles, las primitivas aritmeticas, el manejador de memoria (junto con los garbage collectors), el stack nativo, el translator (o nativizador, o el JIT), etc. El subsistema mas grande es... ... la mayor parte del codigo especifico de las plataformas. Eso se lleva mas o menos un 25% del codigo. No es tanto en bytes, pero lo que lleva de entender especificaciones es tremendo. Y si tomamos todo el codigo fuente y sacamos el stack nativo y el JIT, cuanto queda? Aproximadamente el 75%. Ahi se ve que ejecutar bytecodes es solo una parte chica de lo que es una maquina virtual (y esto no lo dije solo yo, que conste, Tim Rowledge dijo lo mismo en un mail de la lista de Squeak hace como 10 años). Pero bueno, que pasa con ese 25% del codigo que depende de la plataforma? Bueno, ese, precisamente ese codigo, es muy probable que estes obligado a escribirlo en C. Algunas cosas simplemente no se pueden hacer desde la imagen porque te obligaria a tener un compilador C en Smalltalk. Asi que por ejemplo, si queres cumplir la especificacion de sockets, vas a ver que hay detalles privados que se supone que el programador en C no tiene que saber. En la practica no importa porque todo esta armado para que el compilador se encargue de los detalles privados. Si subis eso a la imagen, entonces todo lo que era privado ahora es publico. Asi que si por ejemplo ahora alguien cambia un detalle privado, no te andan los sockets. Lo mismo pasa con los timers y muchas otras cosas. Y si uno agarra y dice que bueno, me la banco y leo todos los detalles privados de sockets y los entiendo mejor que el autor de turno, lo subo a la imagen y chau... que pasa? Bueno, ahi es donde la montaña de especificaciones te tapa. Solo las especificaciones de algo que se llame Unix son por lo menos 17mb. Antes de que te lo hayas aprendido ya salio la nueva version. Y dicho sea de paso eso no necesariamente cubre Mac porque ellos tienen una montaña muchisimo mas grande de documentacion, cosas cambiadas que no son mas BSD, etc. Es ahi donde a uno deberia caerle la ficha de que, para "salvar" el honor de que Smalltalk es mejor que muchisimas otras cosas, terminamos dandole poco o ningun valor al trabajo de los que no usan Smalltalk. Al final, esta posicion es limitante porque uno se vuelve miope y medio ciego. En particular, es tragicomico ver especificaciones de llamadas a funciones en C escritas en un FFI que ni siquiera se toman el trabajo de definir los tipos correctamente. De hecho, se ven cosas como asumir que un puntero es lo mismo que un unsigned int, que siempre caben 4 chars en un long, que da igual definir constantes como DWORD o como int, que escribir unsigned long es lo mismo que unsigned int, etc. Capaz que si uno no tiene el ojo avispado se le escapan los detalles de porque a la larga esas "licencias poeticas" te traen dolores de cabeza, pero cada uno de esas es mas o menos lo mismo que pensar que self es lo mismo que super. Y tal vez en algunos casos decir self new es lo mismo que super new, hasta que uno se cruza con el caso que es diferente y ahi no te andan mas las cosas. Por lo menos en Smalltalk te sale un debugger. En C... quiza parezca que todo sigue funcionando por varias horas, y despues se te cuelga todo (antes formateandote el disco rigido... no es chiste!!!). En pocas palabras, si no nos importa tanto C porque Smalltalk es mas cool, entonces eso ya nos predispone a nunca hacer un FFI que un programador no-Smalltalk quiera usar. En otras palabras, si sos un programador en C y te dicen que uses un FFI Smalltalk para usar un servicio Smalltalk, vas a querer que el FFI tenga especificaciones que cumplan la ley de C. Si no es asi, inmediatamente vas a pensar como programador C y vas a decir "si no hay especificacion (o la especificacion no cumple con las especificaciones de C), no se puede escribir un programa que funcione, adios...". Y despues nos preguntamos porque a los demas no les resulta interesante Smalltalk. Bueno, la verdad es que a veces nos portamos como si lo unico interesante fuera Smalltalk. Entiendo que es dificil porque el mundillo de C tiene mucho de ser "abogado de la especificacion" y a veces es medio denso, pero estaria bueno cambiar un poco. Es jodido, pero no queda otra... que el FFI a C este escrito en Smalltalk no te salva de aprender C. Andres. -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
