Hola gente! Ya algunos conocen mi postura. Comentario corto:
Prefiero una VM escrita sobre un VM con una libreria de clases, como Java, o .NET. Heredar de ahi el Garbage Collector. No hace FFI ni malabares, solo tener acceso a las clases y objetos que brinde la tecnologia. 32/64 bits, practicamente se evaporan diferencias (en la escritura de la VM). Portable, en el caso de Java, y en el caso de .NET (ejemplos mios corren en Mono, sin recompilar). Y forma de invocar a la VM desde la tecnologia host. No primitives, solamente forma de llamar a objetos y clases. La optimizacion la hacen los compiladores "de abajo". Fuera de implementar Smalltalk, Clojure debe ser el ejemplo que mas me viene a la mente. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2011/4/2 Mariano Martinez Peck <[email protected]> > Hola Andres. No te hagas drama, lo leí todo ;) > > En resumen, coincido con vos. Tal vez mi post no fue tan claro como yo > quise. Mi punto de vista era que el hecho de que esté escrita en SLANG está > buenísimo para que cualquier boludo cómo yo, la pueda > navegar/refactorizar/simular usando las herramientas mismas de Smalltalk. > Ponele si yo miro el interp.c (el archivo resultado de la transformación de > SLANG a C), y pienso que tengo que entender/modificar eso, me pego un tiro. > Claro, es autogenerado, así que supongo que si está hecho todo manual es > otra cosa, pero igual... > > No cabe duda de que hay muchísimas partes que se tienen que hacer directo > en C: cuestiones de performance, cuando depende de la plataforma, etc etc > etc. > > Más allá de eso, la simulación para muchos es terriblmente inpagable. > Ponele, si le preguntás a Eliot (por lo que me comentó en la Smalltalk o en > la Deep Smalltalk, no me acuerdo), está CHOCHO con poder simular la VM. De > hecho, puso bocha de esfuerzo en el simulador (incluso para la JIT). > > Saludos, > > Mariano > > > 2011/4/2 Andres Valloud <[email protected]> > >> 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 > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
