El problema del C10K lo resuelve node.js

http://www.kegel.com/c10k.html

http://programmers.stackexchange.com/questions/116114/does-node-js-actually-increase-scalability

Probablemente lo que se podría hacer con Cuis es:

1. Reimplementar node.js en Smalltalk. Esto debería ser la parte fácil.
2. Reimplementar Vaadin en Smalltalk. Esto llevaría tiempo, pero tal vez se
podría reutilizar parte de Smalltalk Express. Estaba muy bien hecho. Habría
que hacer que los componentes aprendan a pintarse en web. Y podría hacerse
usando algún patrón de diseño que permitiera posteriormente que los
componentes se pinten en un tablet, etc.
3. Crear una killer app que muestre los 2 anteriores en ejecución.

Y esto siempre y cuando Cuis realmente sea tan limpio que lo anterior sea
fácil de implementar, lo cuál es más fácil decirlo que hacerlo.

Saludos,
Guillermo.

2012/11/5 Esteban A. Maringolo <[email protected]>

> Los desarrollos de 37Signals.com fueron la killer app de Ruby on Rails,
> por ej.
>
> Seaside, en su momento, era un killer framework, nunca tuvo una killer
> app popular, ya que DabbleDB tuvo poco tiempo de vida y luego
> desapareció.
>
> La gente de LearnBoost y de Joyent aportaron cosas para node.js, que
> permitieron que desarrolladores "salten" a la plataforma.
>
> Erlang surgió desde las tripas de Ericsson y tiene cosas como CouchDB
> (entre otras) de uso masivo.
>
> Smalltalk tuvo su apogeo cuando IBM se metió en el juego con VAST,
> pero luego "faltó algo". Sin contar que era otra epoca y manera de
> hacer software (con licencias a 7000 dolares, imaginate...).
>
> Ahora la gente de Pharo quiere volver a crear cosas que realmente
> diferencien a Smalltalk (Pharo) del resto de las cosas. El tiempo dirá
> si eso se logra o no. Mi expectativa es a que lo logren, pero también
> deberá haber un cambio de paradigma externo que permita florecer.
>
> Hoy por hoy ningun Smalltalk resolvió el problema del C10K.
>
>
>
> Esteban A. Maringolo
>
>
> El día 5 de noviembre de 2012 14:33, Guillermo Schwarz
> <[email protected]> escribió:
> > Killer application = aplicación asesina (de otras plataformas)
> >
> > La idea de crear una plataforma es hacer aplicaciones (o módulos) sobre
> la
> > plataforma, de otra manera la plataforma es inútil.
> >
> > Si todas las plataformas son equivalentes, entonces los creadores de
> > aplicaciones deben gastar tiempo (ie: dinero) portando sus aplicaciones a
> > diferentes plataformas de modo que les resulta más caro llegar a su
> mercado
> > objetivo.
> >
> > Cuando existe una killer app, esta se implementa en una plataforma que
> se lo
> > permite (obvio), pero al mismo tiempo, no se puede implementar en otras
> > plataformas debido a que ellas no presentan la API (o el feature) que
> > permite hacer dicha aplicación. Aunque teóricamente todas las plataformas
> > son "turing compatible", por ejemplo si tengo una tablet con GPS,
> entonces
> > puedo hacer una aplicación que sólo funciona con GPS y mato a todas las
> > otras tablets que no pueden correr mi aplicación porque no tienen GPS.
> > Automáticamente, todos los clientes potenciales abandonan las plataformas
> > que no cumplen con los features que hacen posibles las killer apps.
> >
> > Obviamente, si doy bastante tiempo para reproducir los features de mi
> > plataforma, se acaba la ventaja de la killer app, por eso, los creadores
> de
> > plataformas agregan muchos features a su plataforma, cada uno de ellos
> > pensado en al menos una killer app, y crean muchas posibles killer app,
> > incluso si pueden ser reproducidas en otras plataformas, el tiempo que
> les
> > toma es tan largo, que puedo sacar la próxima killer app antes de que
> salga
> > la copia de la anterior...
> >
> > Y no, nunca he hecho una killer app. Típicamente son los fabricantes de
> > plataformas los que se encargan de fabricar tanto los features que hacen
> > posible la killer app como la killer app propiamente dicha.
> >
> > Saludos,
> > Guillermo.
> >
> >
> > 2012/11/5 Leo De Marco (Smalltalking) <[email protected]>
> >
> >> Que es una "killer application"? vos hiciste una? Donde la puedo ver?
> >>
> >>
> >>
> >> De: [email protected] [mailto:
> [email protected]]
> >> En nombre de Guillermo Schwarz
> >> Enviado el: lunes, 05 de noviembre de 2012 12:26
> >> Para: [email protected]
> >> Asunto: Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
> >>
> >>
> >>
> >> +1
> >>
> >>
> >>
> >> Lo único que agregaría es que Cuis al parecer no tiene ningún motivo
> para
> >> existir, ya que Pharo ocupó su lugar.
> >>
> >>
> >>
> >> Si Cuis realmente es más modular o más orientado al objeto o tiene
> alguna
> >> otra característica que lo haga superior, entonces debiera existir
> alguna
> >> "kill application" sobre Cuis que lo demuestre y que sea imposible de
> >> implementar sobre Pharo y sobre todo el resto de los Smalltalks
> disponibles.
> >>
> >>
> >>
> >> A mí me parece imposible hacer eso (a pesar de que aún no entiendo bien
> >> cómo funciona la modularización en Pharo y al menos me imagino algo
> >> funcionando mejor), para mí todavía el problema es irreductible. A lo
> mejor
> >> el fabricante de Cuis nos puede iluminar al respecto...
> >>
> >>
> >>
> >> Saludos,
> >>
> >> Guillermo.
> >>
> >>
> >>
> >> 2012/11/5 Esteban Lorenzano <[email protected]>
> >>
> >> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto.
> >> No quería meterme porque me parece una perdida absoluta de tiempo, pero
> >> viendo por donde empieza a rumbear esto...
> >>
> >> Cuis no se puede usar como núcleo de Pharo por varios motivos:
> >>
> >> 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene
> interés
> >> en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired")
> >>
> >> 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un
> >> control muy fuerte de lo que hay adentro", Pharo pretende ese mismo
> control
> >> para si mismo.
> >> Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un
> >> atributo "layout"... en el primer paso para transformar los atributos
> de una
> >> instancia en "first class instances"... slots, bah, y no solo #symbols
> como
> >> hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual
> que
> >> la inclusion de Traits, btw), es difícil pensar que eso se pudiera
> >> consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por
> supuesto,
> >> reclama para sí el mismo control que Juan reclama para su proyecto (¿Y
> que
> >> es lo malo de esto?)
> >>
> >> 3) Pharo pretende construir una reificación completa del concepto de
> >> imágen (hacer Pharo new y tener una imagen idem con la que comunicarse,
> y
> >> que esta imagen pueda correrse en otros threads, cores e incluso
> máquinas).
> >> Por supuesto, esto escapa al objetivo de Cuis, y requiere cambios en el
> >> Kernel que no son pocos. (Hazelnut, de hecho, es el primer paso de un
> largo
> >> camino en ese sentido)
> >>
> >> 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen
> (no
> >> un binario, sino una serializacion, que permita cargar la misma imagen
> en
> >> arquitecturas 64bits), eliminar el sources files y modificar los
> changes y
> >> lo que se guarda ahí.
> >>
> >> 5) Todo eso junto con la fundación de una plataforma que permita hacer
> >> software para negocios. Cualquiera que se haya tomado en serio
> promocionar
> >> un lenguaje sabe que eso no es tan fácil, que requiere construir una
> >> infraestructura que en mucho rebasa lo meramente técnico, pero que
> también
> >> tiene algunos elementos técnicos que son necesarios cumplir: procesos de
> >> reconstrucción (no habilitados con el proceso evolutivo de ahora),
> >> requerimientos de seguridad (que hoy no existe) y un larguísimo etc.
> >> De lo "no tecnico", lo más importante es crear una estructura que pueda
> >> ofrecer seguridad a empresas (con soporte y la garantía de que "hay
> alguien
> >> atrás").
> >>
> >> En esencia, el único objetivo común que tienen Cuis y Pharo es el de
> >> modularización, y hasta eso se encara con filosofías distintas (dado
> que no
> >> es solo separación, sino interacción entre módulos, etc.)... y por
> supuesto
> >> que hay ideas muy buenas en Cuis, y nosotros mantenemos un ojo ahí para
> ver
> >> que podemos "tomar prestado" (y tambien en Squeak), pero no veo por qué
> se
> >> insiste tanto en algo que simplemente no se ajusta a la realidad, la
> >> posibilidad de construir un Pharo o un Squeak a partir de un Cuis... Y
> no se
> >> ajusta a la realidad entre otras cosas porque pedir eso atrapa los
> ambientes
> >> los unos con los otros impidiéndoles evolucionar a todos.
> >>
> >> Después, bueno... los argumentos mezquinos realmente no me interesan, me
> >> parece que no contribuyen en nada a tener un debate constructivo, así
> que
> >> discúlpenme si no me detengo en ellos.
> >>
> >> Saludos,
> >> Esteban
> >>
> >>
> >> On Nov 5, 2012, at 1:38 PM, Andres Valloud <[email protected]>
> >> wrote:
> >>
> >> > Calmense muchachos, porque no pensamos en la arquitectura en el mundo
> de
> >> > IT?
> >> >
> >> >
> https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg
> >> >
> >> > 2012/11/5 Carlos E. Ferro <[email protected]>:
> >> >> On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote:
> >> >>
> >> >> Mmm, ¿te parece que son tan inocentes? Los académicos tienen
> necesidad
> >> >> de
> >> >> publicar papers. Una manera de hacerlo es escribir un poco de
> software,
> >> >> mostrar que más o menos funciona y escribirlo en un artículo. Un
> >> >> software
> >> >> robusto requiere un poco más que eso.
> >> >>
> >> >> Además están en otra, los revisores de las revistas científicas no
> >> >> deciden
> >> >> aceptar un paper por mejorar procedimientos de instalación,
> manuales, o
> >> >> depurar cosas viejas y aburridas.
> >> >>
> >> >>
> >> >> Hernán, me parece que con esto estás muy equivocado.
> >> >> La robustez es una de las preocupaciones del proyecto Pharo, y eso se
> >> >> ve.
> >> >> Pero eso, por supuesto es discutible.
> >> >>
> >> >> El proyecto tiene muchas facetas aparte de la académica, no es para
> >> >> producir
> >> >> papers sino que lo veo funcionando al revés: el hecho de posibilitar
> >> >> papers
> >> >> hace que Ducasse pueda tener una pila de estudiantes (muchos
> >> >> argentinos)
> >> >> trabajando en Pharo, y que al mismo tiempo avancen académicamente,
> >> >> terminando doctorados.
> >> >>
> >> >> Y hay muchos proyectos en marcha que son, justamente, las cosas que
> vos
> >> >> decís: procedimientos de instalación, debugging... Un ejemplo directo
> >> >> que me
> >> >> viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a
> >> >> presentar
> >> >> en Smalltalks, pero no tiene ningún interés académico, es una
> >> >> herramienta
> >> >> para configurar fácilmente imágenes con paquetes... Y, por supuesto,
> >> >> los
> >> >> libros de Pharo by Example de Ducasse, donde colabora mucha gente.
> Los
> >> >> libros tienen muy poco reconocimiento académico...
> >> >>
> >> >> Saludos
> >> >> --
> >> >>
> >> >> carlos e. ferro | senior developer |  caesar systems
> >> >>
> >> >> [email protected]
> >> >>
> >> >> --
> >> >> 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
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Saludos cordiales,
> >>
> >> Guillermo Schwarz
> >> Sun Certified Enterprise Architect
> >>
> >> --
> >> 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
> >
> >
> >
> >
> > --
> > Saludos cordiales,
> >
> > Guillermo Schwarz
> > Sun Certified Enterprise Architect
> >
> > --
> > 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
>



-- 
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

-- 
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]

http://www.clubSmalltalk.org

Responder a