Re: Sobre CUIS y Pharo
Locked
12345
... 7
12345
... 7
 
|
Que es una "killer application"? vos hiciste una? Donde la puedo ver? De: [hidden email] [mailto:[hidden email]] En nombre de Guillermo Schwarz +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 <[hidden email]> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto.
> 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 <[hidden email]>: >> 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 >> >> [hidden email] >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org -- -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Cierto Juan, no se para que fuiste capaz de realizar lo que yo no podría. No me hagas el mundo incómodo por favor y elimina ese Cuis. Abrazo Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: [hidden email] email: [hidden email] twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 De: "Leo De Marco (Smalltalking)" <[hidden email]> Para: [hidden email] Enviados: Lunes, 5 de Noviembre 2012 13:19:53 Asunto: RE: Re: [clubSmalltalk] Sobre CUIS y Pharo Que es una "killer application"? vos hiciste una? Donde la puedo ver?
De: [hidden email] [mailto:[hidden email]] En nombre de Guillermo Schwarz
+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 <[hidden email]> Bueno, como pharo-dev asalariado, estoy en mi deber de responder 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. 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. 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,
> 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 <[hidden email]>: >> 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 >> >> [hidden email] >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org --
-- Guillermo Schwarz -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by J. Vuletich (mail lists)
Ok, los voy a mirar, porque me parece muy interesante la opinión que pusiste en la web, pero dudo mucho que encuentre las diferencias así a simple vista en menos de 1 año.
Esto lo digo porque a pesar de que he mirado como funciona Squeak y más recientemente Pharo, me parece que la típica crítica de que Smalltalk es simple, pero que la jerarquía de clases es gigante e incomprensible, se aplica 100% a ambos. A pesar de estar años aprendiendo Smalltalk, las bibliotecas y jerarquías de clases cambian constantemente, y aunque no lo hicieran, es al menos para mí casi imposible saber cómo se usa una clase si no encuentro otra clase que sirva como un ejemplo simple de su uso. ¿Cómo es que aún eso no se arregla en Smalltalk? ¿Dicen que Smalltalk está orientado a los niños? Debe ser una broma.
Incluso cuando programaba en C++ hacía al menos un ejemplo del uso de todas y cada una de las clases, el resultado era que no sólo era fácil usar las clases, sino que además de manera automática encontraba cuando introducía defectos sutiles, lo que en C++ no es trivial.
Entiendo porque cambia tanto la class hierarchy en Smalltalk, se llama evolución, pero si miras lo que se hacía antes y lo que se hace ahora, en general al parecer ahora no se puede hacer mucho más que antes, introduces un nuevo feature y arruinas 3. Es como si estuvieras construyendo una casa a 10 años plazo, y cada 3 o 4 años alguien llegara y derrumbara la casa para construir una nueva, mejor y más grande.
Lo bueno de Smalltalk es que te lo permite, pero lo malo es también que te lo permite, porque al alguien le gusta y a alguien no. Entonces se produce la fragmentación. Como alguien ya dijo en este thread, Smalltalk se ha disparado en el pie con la fragmentación, que no es otra cosa que reinventar la rueda una y otra vez. Tal vez sería bueno que se usara un enfoque como el de Linux, que las versiones pares impican estabilidad y las impares implican versiones experimentales, alguien se encarga de inventar, alguien de integrar, alguien de evaluar, alguien de mantener la estabilidad. [ültimamente he escuchado que Linux se preocupa casi exclusivamente de mantener la compatibilidad hacia atrás... lo que está pésimo... se convirtíó en un WIndows más... ]
Esto de crear versiones experimentales y de usar lenguajes dinámicos es importante porque lo importante de un lenguaje es que te permita pensar nuevas ideas y ponerlas en práctica rápido. Pero en la medida que vas implementando y usando tus nuevas ideas, te vas dando cuenta que hay ideas mejores que antes no habías pensado, entonces reimplementas una parte, te das cuenta de que es buena idea, y vuelves a hacer lo mismo una y otra vez, hasta que llegas a una idea tan limpia que son pocas líneas de código, pero hace todo lo que podrías imaginar. Lo importante en ese caso es ser "ruthless" y aplicar la idea en todo tu código de manera homogénea. Entonces te das cuenta que el código es tan simple que es casi obvio, es como si no hubieras hecho nada, pero lo importante como decía Steve Jobs es "La simplicidad es la máxima sofisticación".
Es como cuando partes programano con threads, aprendes a usar synchronized, mutexes, readwritelocks, non-locking data structures, y llegas a los EJBs que prohiben el synchronized y colocas un EJB proxy y es como haber dado la vuelta completa, escribes código lineal que se comporta como código multithreaded, sin race conditions posibles y sin locking. "La simplicidad es la máxima sofisticación", el problema es que te demoras 10 años en llegar ahí.
Además otra cosa que no entiendo es cómo un proyecto que "es lo mejor" como Morphic, siquiera antes que logre entender lo que pretende, ya fue dado como obsoleto. Uno podría pensar que como Smalltalk es más dinámico que el resto de los lenguajes, entonces los supera más rápido de lo que son capaces de copiarlo. Sería una buena respuesta, pero desgraciadamente al pensar en un lenguaje que evoluciona más lento (Java), me cuesta mucho entender lo que pasa en este momento en Smalltalk. ¿Realmente Morphic evoluciona tanto que ya no se soporta a si mismo?
Un comentario al margen, lo que le pasó a Andy Bower con el Dolphin Smalltalk. Si realmente piensa que es mejor dejarlo morir que hacerlo open source, ¿no convendría preguntarle por cuánto vendería su empresa o su producto y crear un fundriser en http://www.kickstarter.com/?
Lo del sitio web de Cuis, yo trataría de hacerlo más simple, con más ejemplos, con más videos, cosas pequeñas que llamen la atención. Ojalá videos de 30 segundos. Nada de más de 5 minutos. Te pongo un ejemplo de un sitio que en mi opinión funciona: https://vaadin.com/home Presiona "introduction".
¿Porqué te digo esto? Porque cualquiera puede decir "mi producto es más simple", o "mi producto está diseñado para ser simple". Pero como dice Alan Kay, sólo Lisp tiene un intérprete escrito en media página (la implementación de "eval").
Si pensamos en los sistemas comerciales, mientras más grande sea la lista de "features", mejor es el producto. Punto. Por lo tanto abres un RAD Websphere (u otro similar) y tiene desde modelamiento UML hasta deployment en la nube. Más features => sube el precio, aunque uses sólo 10 features de las 1.500 que tiene el producto.
Si pensamos en los lenguajes de programación, hasta donde entiendo el más completo era PL/1: http://www.softpanorama.info/Lang/pl1.shtml Pero le ganó un lenguaje minimal que ni siquiera tenía IO incorporado: C. Sin threads. Sin excepciones. ¿Porqué le podría ir mejor? Si tengo una facultad de ingeniería, me conviene que aprendan sobre algo gratis y que use pocos recursos. Eso piensan el 99% de las universidades. Luego se convierte en un standard y ya es lo mejor porque todos lo tienen.
De modo que en general un lenguaje más simple le gana a uno más complejo, por el simple hecho de que aprenderlo es más fácil, y cuando quieres realizar un proyecto, es más fácil encontrar programadores para el lenguaje fácil que para el lenguaje difícil, y está demás decir que cuando se trata de dinero, si puedes gastar menos y lograr lo mismo, esa es la estrategia ganadora (y eso evitando el problemaque ocurre cuando al bajar la calidad del producto nadie te lo compra).
Si Pharo tiene objetivos diferentes que Cuis, entonces no veo el problema en que sobrevivan los dos. De hecho no entiendo porqué le tienes bronca a Pharo. A mí me hubiera gustado que hubiera existido en 1990.
Saludos, Guillermo. 2012/11/5 Juan Vuletich (mail lists) <[hidden email]>
Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by leodm
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) <[hidden email]>
Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
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 <[hidden email]> 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) <[hidden email]> > >> Que es una "killer application"? vos hiciste una? Donde la puedo ver? >> >> >> >> De: [hidden email] [mailto:[hidden email]] >> En nombre de Guillermo Schwarz >> Enviado el: lunes, 05 de noviembre de 2012 12:26 >> Para: [hidden email] >> 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 <[hidden email]> >> >> 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 <[hidden email]> >> 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 <[hidden email]>: >> >> 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 >> >> >> >> [hidden email] >> >> >> >> -- >> >> To post to this group, send email to [hidden email] >> >> To unsubscribe from this group, send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> > >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org >> >> >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
El problema del C10K lo resuelve node.js 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 <[hidden email]> Los desarrollos de 37Signals.com fueron la killer app de Ruby on Rails, por ej. Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
El día 5 de noviembre de 2012 16:20, Guillermo Schwarz
<[hidden email]> escribió: > El problema del C10K lo resuelve node.js > http://www.kegel.com/c10k.html Ya conozco el problema, también lo resuelve Java, Ruby con EventMachine, o Erlang con YAWS. Me refiero a algo concreto HOY en alguna implementación de Smalltalk. Esteban A. Maringolo -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
¿Te estás construyendo algo? Saludos,
Guillermo.
-- 2012/11/5 Esteban A. Maringolo <[hidden email]> El día 5 de noviembre de 2012 16:20, Guillermo Schwarz Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
El día 5 de noviembre de 2012 16:39, Guillermo Schwarz
<[hidden email]> escribió: > > ¿Y eso para qué precisamente? > ¿Te estás construyendo algo? Una cucha para el perro. Para lo otro con C1K me alcanzaría. Saludos! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Esteban A. Maringolo
Hola Esteban,
El 5 de noviembre de 2012 12:43, Esteban A. Maringolo <[hidden email]> escribió: El día 5 de noviembre de 2012 01:06, Hernán Morales Durand En mi opinión su compromiso es primordialmente lo académico. Publicar papers, posters, charlas en Congresos, etc. Ningún académico va a poner en riesgo su carrera o status por darte soporte o un producto mejor, a no ser que puedas incrementar su índice h ;) Saludos -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola Hernán,
> En mi opinión su compromiso es primordialmente lo académico. Publicar papers, posters, charlas en Congresos, etc. Ningún académico va a poner en riesgo su carrera o status por darte soporte o un producto mejor, a no ser que puedas incrementar su índice h ;) Estoy de acuerdo que eso pasa muchos con los investigadores, pero no se puede generalizar. Conozco mucha gente que se preocupan muchos de los usuarios, y no solamente del indice h :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Carlos E. Ferro-2
El 5 de noviembre de 2012 13:17, Carlos E. Ferro <[hidden email]> escribió:
Hola Carlos, Sin querer irme mucho de tema, los científicos sobreviven con los papers. El proyecto que mencionás tambien sirvió como una pasantía para el INRIA, fijate que hay cosas publicadas. En esta lista hay varios que son o fueron de CONICET y saben como se evalúa la producción científica. O alguno que cuente lo que cuesta renovar una beca o que se pide para entrar a carrera de investigador... Tambien se publican capítulos de libros, son revisados y tienen reconocimiento como los artículos en revistas (no sé de donde sacas que tienen poco reconocimiento académico). Pero como te digo, el proyecto tiene otras facetas seguro, siendo la principal una plataforma de la que se pueda generar investigación (off the record, claro). Dicho de otro modo, si mañana Pharo "no da más", creo que Ducasse y cía. cambiarían a Python u otro lenguaje, de hecho alguna vez mencionó esa posibilidad. Y está perfecto, cada uno cuida su kiosco. Y algunas cosas buenas llegan de rebote. Saludos Hernán -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hernan,
Perdón por mi forma "Majul" de escribir, pero básicamente lo que saco de lo que decis es que el dia que no puedan hacer más papers con Pharo van a dejarlo de lado y salir a hacerlos con otra cosa (con Python o JS como bien alguna vez dijo Ducasse). Asi como lo planteas suena violento, y hasta te diría que triste para la pequeña comunidad Smalltalk. En lo personal veo en Pharo la última alternativa de Smalltalk para el tipo de desarrollo que se da hoy en día, donde se espera que la herramienta sea gratis, open source y con libraries/frameworks para cubrir la funcionalidad básica de la mayor parte de las cosas de desarrollo del contexto actual (y futuro). Si fuese como decis, estaría todo construido sobre arenas movedizas. Saludos! Esteban A. Maringolo El día 5 de noviembre de 2012 19:13, Hernán Morales Durand <[hidden email]> escribió: > > > El 5 de noviembre de 2012 13:17, Carlos E. Ferro <[hidden email]> > escribió: > >> 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... >> > > Hola Carlos, > Sin querer irme mucho de tema, los científicos sobreviven con los papers. El > proyecto que mencionás tambien sirvió como una pasantía para el INRIA, > fijate que hay cosas publicadas. En esta lista hay varios que son o fueron > de CONICET y saben como se evalúa la producción científica. O alguno que > cuente lo que cuesta renovar una beca o que se pide para entrar a carrera de > investigador... Tambien se publican capítulos de libros, son revisados y > tienen reconocimiento como los artículos en revistas (no sé de donde sacas > que tienen poco reconocimiento académico). > Pero como te digo, el proyecto tiene otras facetas seguro, siendo la > principal una plataforma de la que se pueda generar investigación (off the > record, claro). Dicho de otro modo, si mañana Pharo "no da más", creo que > Ducasse y cía. cambiarían a Python u otro lenguaje, de hecho alguna vez > mencionó esa posibilidad. Y está perfecto, cada uno cuida su kiosco. Y > algunas cosas buenas llegan de rebote. > Saludos > > Hernán > > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Esteban A. Maringolo
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: [hidden email] [mailto:[hidden email]] En nombre de Esteban A. Maringolo Enviado el: lunes, 05 de noviembre de 2012 14:51 Para: [hidden email] 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 <[hidden email]> 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 > 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) <[hidden email]> > >> Que es una "killer application"? vos hiciste una? Donde la puedo ver? >> >> >> >> De: [hidden email] >> [mailto:[hidden email]] >> En nombre de Guillermo Schwarz >> Enviado el: lunes, 05 de noviembre de 2012 12:26 >> Para: [hidden email] >> 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 >> >> >> >> 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 <[hidden email]> >> >> 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 >> 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 >> 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 >> >> 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 <[hidden email]> >> 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 <[hidden email]>: >> >> 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 >> >> >> >> [hidden email] >> >> >> >> -- >> >> To post to this group, send email to >> >> [hidden email] To unsubscribe from this group, >> >> send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> > >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org >> >> >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] To > unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
El día 7 de noviembre de 2012 12:54, Leo De Marco (Smalltalking)
<[hidden email]> escribió: > 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. No exactamente, pero sí que tenga una masa crítica que le de una sustentabilidad en el tiempo. Para mi un caso de referencia es Erlang, que sin ser mainstream a logrado posicionarse como una tecnología "diferente", e inclusive hay servidores hechos en Erlang que son usados por otras tecnologías, cosa que en la historia de Smalltalk nunca se dió (sí se dió de replicar la idea en otro lenguaje). > 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). Para mi en el caso de S8 hay una fragmentación innecesaria con Amber, si se sumasen los esfuerzos podría producirse algo superior. Pero parece que el estigma del Smalltalker es querer hacer TODO a su manera. > Creo que incluso > el hecho de que Smalltalk no sea mainstream es una ventaja competitiva de > negocio, eso creo que muchos aquí lo saben. Esto para mi dejó de ser cierto hace como 10 años. Es una herramienta muy valiosa, en determinados casos, para el desarrollador independiente, porque realmente permite laburar a mucha velocidad en cosas de una complejidad mediana. En cosas de baja complejidad, esta lleno de frameworks y soluciones precocinadas para otras tecnologías como Ruby, PHP, Python, etc. "Talk small and carry a big class library" era una frase que se usaba para Smalltalk, hoy la class library ya no es lo que era, y por lo general viene "detrás" de lo que van generando otros. Ni siquiera perl con su CPAN se quedó tan atrás. Saludos. Esteban A. Maringolo -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
>Para mi en el caso de S8 hay una fragmentación innecesaria con Amber, si se
sumasen los esfuerzos podría producirse algo superior. Pero parece que el estigma del Smalltalker es querer hacer TODO a su manera. Volvemos al caso Cuis-Pharo :), aunque tuvieron un mismo origen, tienen objetivos totalmente diferentes. > Creo que incluso > el hecho de que Smalltalk no sea mainstream es una ventaja competitiva > de negocio, eso creo que muchos aquí lo saben. >Esto para mi dejó de ser cierto hace como 10 años. Perdón por no aclarar, yo siempre vi a Smalltalk como una herramienta muy valiosa para dominios no tradicionales, en cambio para dominios tradicionales no conviene tanto (siempre refiriendome a nivel de negocio, en los casos de smalltalkers freelancers es diferente) Abrazo, Leo -----Mensaje original----- De: [hidden email] [mailto:[hidden email]] En nombre de Esteban A. Maringolo Enviado el: miércoles, 07 de noviembre de 2012 13:24 Para: [hidden email] Asunto: Re: Re: [clubSmalltalk] Sobre CUIS y Pharo El día 7 de noviembre de 2012 12:54, Leo De Marco (Smalltalking) <[hidden email]> escribió: > 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. No exactamente, pero sí que tenga una masa crítica que le de una sustentabilidad en el tiempo. Para mi un caso de referencia es Erlang, que sin ser mainstream a logrado posicionarse como una tecnología "diferente", e inclusive hay servidores hechos en Erlang que son usados por otras tecnologías, cosa que en la historia de Smalltalk nunca se dió (sí se dió de replicar la idea en otro lenguaje). > 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). Para mi en el caso de S8 hay una fragmentación innecesaria con Amber, si se sumasen los esfuerzos podría producirse algo superior. Pero parece que el estigma del Smalltalker es querer hacer TODO a su manera. > Creo que incluso > el hecho de que Smalltalk no sea mainstream es una ventaja competitiva > de negocio, eso creo que muchos aquí lo saben. Esto para mi dejó de ser cierto hace como 10 años. Es una herramienta muy valiosa, en determinados casos, para el desarrollador independiente, porque realmente permite laburar a mucha velocidad en cosas de una complejidad mediana. En cosas de baja complejidad, esta lleno de frameworks y soluciones precocinadas para otras tecnologías como Ruby, PHP, Python, etc. "Talk small and carry a big class library" era una frase que se usaba para Smalltalk, hoy la class library ya no es lo que era, y por lo general viene "detrás" de lo que van generando otros. Ni siquiera perl con su CPAN se quedó tan atrás. Saludos. Esteban A. Maringolo -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Estuve siguiendo el debate y la verdad que hay muchos puntos atendibles, de cada lado del mostrador.
Quiero dejar el mío (modesto pero es mi experiencia) desde el punto de vista de quien desarrolla software comercial (open o no) para clientes reales.....y la verdad que en ese contexto, los smalltalks open [1] cada día se alejan más de la posibilidad de competir en muchas cosas:
- Hosting - Integración con el resto de tecnologías - Abarcatividad de dispositivos - Escalabilidad / Disponibilidad - Comunidad - Cosas hechas para poder reutilizar / Frameworks (para cosas de negocio, no me refiero al ultimo compresor que gane un byte más que el anterior) Muchos de estos temas hacen a la productividad (a hacer las cosas más rápido) algo que es determinante en cualquier caso, pero mucho más en el de pequeños productores como es mi propio caso. Por cerrar la reflexión con un ejemplo, hace 2 años digamos, Pharo me servia....de un modo u otro, hoy ya no me sirve....(siempre hablo de mi propio contexto de trabajo).
Por eso, es que discrepo tanto (o no entiendo) cuando se dice que Pharo quiere ser un Smalltalk para negocios.....la verdad, no entendemos lo mismo por "un smalltalk para negocios". Saludos. [1] Los comerciales seguramente apuntan a otros mercados y no los conozco en la profundidad suficiente como para opinar, pero seguro que en algunos puntos adolecen de los mismos problemas, sumado a los costos. El 7 de noviembre de 2012 20:21, Leo De Marco (Smalltalking) <[hidden email]> escribió:
============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogspot.com ============================================ To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
2012/11/11 Germán Arduino <[hidden email]> Estuve siguiendo el debate y la verdad que hay muchos puntos atendibles, de cada lado del mostrador. Hola Germán. La verdad que no entiendo porque decís eso. Te respondo abajo
Cualquier Smalltalk open tiene los mismo problemas/ventajas de hosting que cualquier otro Smalltalk. De hecho, hacer un deploy de Pharo es lo mas facil del mundo. Copias el .image y sestas. Donde está la dificultad? servers corriendo? al menos existe (existia) seasidehosting, smallharbour, etc. En los otros que hay?
Bueno, existe NB, FFI y la posibilidad de escribir plugins en la VM. Que te falta que tengan los otros smalltalks? COM ?
Hay RPC (eso lo sabes jaja), XML, etc.. Ponele, ahora tenemos bindings para un monton de bases NoSQL. Que tienen los comerciales? TOdo el esfuerzo de usar GIt, tambien pasa en Pharo/Gemstone. El resto?
Que yo sepa Pharo/Squeak fue el primero (y unico?) en correr en android, iOS, rasperry pi, etc.
Cog trajo una rafaga bastante buena. Falta, pero creo que esta bastante bien. Realmente tuviste problemas de escalabilidad? porque la verdad que si tenes un esquema de persistencia adecuado, podes tener cuantas imagenes quieras corriendo al mismo tiempo en varias maquinas/cores....un apache adelante haciendo load balancing y listo
La comunidad Pharo es por lejos la mas activa y grande, incluso sumadno todos los propietarios juntos.
aca no te entendi mucho pucha, me queria mantener afuera de la discucion...
Mariano http://marianopeck.wordpress.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola Mariano: En principio te aclaro que hablo de los open porque son los que conozco, no digo que los mismos problemas no estén en los comerciales, eh....es más, lo aclaré al final, lo del hosting está seguro. El 11 de noviembre de 2012 18:20, Mariano Martinez Peck <[hidden email]> escribió:
Suponete que tenés una pequeña empresa que desarrolla software a medida, los clientes que te piden presupuesto, comparan mucho precios, y alguien que desarrolla en PHP hostea en cualquier parte. A eso me refiero, no hay opciones de hosting comercial accesibles para hostear soluciones Smalltalk. Me refiero a shared, un vps, ya cae fuera de competencia.
Hice más arriba la aclaración sobre los comerciales, no digo que no tengan los mismos problemas, más bien digo Smalltalk versus el resto, pero como no conozco bien los comerciales no quiero opinar.
Pero estamos muy lejos de poder desarrollar para plataformas móviles.....con widgets nativos (o al menos parecidos) y lo que se necesita para tener aplicaciones que realmente compitan y tengan posibilidad de venderse en un mundo comercial.
Si, si, conozco lo que decis, pero en otras plataformas no entras en esa complejidad y tenés posibilidades mucho más sólidas. Es por eso que había hecho el esfuerzo de desarrollar una forma de usar RedHat OpenShift mediante el cartridge DIY. Digo, simplemente, subo mis desarrollos y la plataforma me da la escalabilidad....no tengo que matarme haciendo cosas artesanales.
De nuevo aclaro la salvedad, no hablo versus Smalltalk comerciales, hablo versus otras cosas mucho mas difundidas. La comunidad de Smalltalkers (además de fragmentada) es chica y eso en algún punto se paga.
No hay (hoy día) una sóla startup de la cual podamos usar su experiencia como "buque insignia" como una vez lo fue DabbleDB. Si uno mira el mundo de las startups de Internet, (startuply.com, etc) la verdad es que no existimos.
No digo ni que esté bien ni mal, pero es un condicionante en muchos aspectos, cuando tenés una empresa propia.
Frameworks para desarrollos comerciales, que se yo, Magritte es lo mejor que tenemos, si vos buscas en otras herramientas como PHP, Python, etc, tenes miles de cosas disponibles, en Smalltalk casi nada. Por ejemplo, yo trabajo mucho con Criprografía, todo lo que hice en Smalltalk fue sangre, sudor y lágrimas y en otras herramientas tenes los algoritmos que quieras, implementados por expertos....que se yo, alguien me va a decir "y hacételo vos", pero bue, yo no vivo de hacer algoritmos, vivo de juntar muchas de esas cosas en una solución que le da otro valor agregado al negocio de un cliente.
Todo bien, que se yo, cada uno tiene sus puntos de vistas, yo sólo les comparto el mío. Saludos. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
je, quise escribir Criptografía.
El 11 de noviembre de 2012 18:48, Germán Arduino <[hidden email]> escribió:
============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogspot.com ============================================ -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |