Si, lo que yo veo es como que hay una especie de objetivo subyacente en estos mails que es que smalltlak se convierta en un mainstream.
En Smalltalking por lo menos ese debate ya esta saldado :), si nos interesa tener una plataforma que nos permita desarrollarnos y no quedar colgados de una palmera el dia de mañana cuando el proveedor de la vm no le es rentable el negocio o se lo chupa otra empresa y deja de existir, de allí surgió la formulación de "Invisible Machine". Obviamente queremos lograr una masa critica de gente que lo use, ya que esta pensado para la industria y no para el sector educativo (que puede estar contenido pero claramente no es allí a donde apuntamos). Creo que incluso el hecho de que Smalltalk no sea mainstream es una ventaja competitiva de negocio, eso creo que muchos aquí lo saben. Saludos! Leo -----Mensaje original----- De: [email protected] [mailto:[email protected]] En nombre de Esteban A. Maringolo Enviado el: lunes, 05 de noviembre de 2012 14:51 Para: [email protected] Asunto: Re: Re: [clubSmalltalk] Sobre CUIS y Pharo 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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
