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
