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) <[email protected]> > Contesto como "el fabricante de Cuis". > > El mensaje de Esteban muestra que los objetivos de Pharo son bastante > diferentes que los de Cuis ( http://www.jvuletich.org/Cuis/Index.html ). > Me parece entonces que estás muy equivocado al decir que Pharo ocupó su > lugar: son 2 lugares muy distintos Si aún creés que es así, te aconsejo que > browsees los 2 sistemas, e intentes comprenderlos. Algunas métricas de > complejidad y tamaño de código pueden ayudar. > > Por otra parte, no creo tener ninguna obligación de mostrar una killer > application. Hago Cuis porque quiero un Smalltalk como la gente. Y lo > comparto porque soy generoso. Los smalltalkers que tengan criterios > técnicos y estéticos similares a los míos lo apreciarán y lo usarán (y > colaborarán con el proyecto, si quieren). Y los que no, no. > > Saludos, > > Juan Vuletich > > Quoting Guillermo Schwarz <[email protected]>: > > +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 > > Cheers, > Juan Vuletich > -- 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
