Ralph Johnson es profesor de Objetos en la Universidad de Illinois y uno de los principales organizadores de OOPSLA, es más, es uno de las 5 personas que siempre participo de OOPSLA desde que esta conferencia comenzó (las otras son Brian Foote, Rebecca Wirfs-Brock, Allen Wirfs-Brook -el esposo- y Edwared Gehringer).
Ralph acaba de escribir un comentario interesante sobre ErLang, un lenguaje que le están dando mucha manija ahora. Una de las cosas que hace es clasificar la gente de OO en tres categorías, la escandinava, la mistica y la de ingeniería de software... según esta clasificación me da gusto ser un ingeniero de software escandinavo y místico!!! jaja (no veo porque las tres categorías que hacen deberían ser disjuntas...)
viernes, 10 de agosto de 2007
Suscribirse a:
Comentarios de la entrada (Atom)
2 comentarios:
Hola Hernan.
Despues de leer el articulo, me quedo la sgte duda: el problema de concurrencia y escalabilidad que resuelve erlang, ¿lo resuelve gemstone tambien? nunca use gemstone. ¿podrias comentar brevemente que diferencias hay entre gemstone y erlang?
saludos
martin
Que tal Martín,
de Erlang no conozco mucho más de lo que dice Ralph y que pareciera seguir el modelo de Actor (un lenguaje implementado por H. Libermman) donde la característica diferencial es que cada objeto posee su propia "thread" de ejecución.
Lo que si te puedo comentar son las características de GemStone. Conceptualmente GemStone se puede ver como una imagen de Smalltalk centralizada, transaccional con ejecución distribuida. O sea, hay una única imagen que es accedida con varias virtual machines y debido a esto, por ser un recurso compartido y para que no haya conflictos entre los distintos agente que la usan, tiene la capacidad de ser transaccional. A nivel implementativo es un poco mas compleja la cosa, pero a nivel conceptual es eso.
Por lo tanto, y sobre tu pregunta específica, GemStone es altamente escalable, tanto a nivel horizontal (misma maquina, varios procesadores) como vertical (distintas máquinas y hasta con distintos sistemas operativos) puesto que esta diseñado para que se puedan levantar la cantidad de virtual machines que se quiera. He escuchado de implementaciones que tienen más de 1000 VMs corriendo simultáneamente sobre la misma "imagen", desconozco en que arquitectura de hardware.
Es por este motivo que la gente de GemStone está dándole importancia a ofrecer soporte especial a aplicaciones Web con la implementación de SeaSide para GemStone y ahora con la de RubyOnRails. Para más info mirá http://support.gemstone.com/gemstone_s/learning_center/forum/msg03535.html
Por otro lado, lo que comenta Ralph es que Erlang tiene una facilidad de diseño para ser "multiproceso", está pensado para eso, mientras que Smalltalk o Java no, tiene el foco en otro lado. Mi opinión es que con Smalltalk o Erlang podés hacer lo mismo (al fin y al cabo son todas abstracciones de una máquina de Turing), pero parece que con Erlang es más fácil hacer algo multiproceso... habrá que tan fácil es hacer un buen modelo escalable en funcionalidad, con buenas características de diseño, etc., y es en esto donde diciento un poco de Ralph respecto de su hype sobre Erlang... en tiempo dirá.
Espero haber contestado tu pregunta, cualquier cosa avisá!
Publicar un comentario