A challenge for all who cares

> ¿Qué opinan de lo que dice Guido?
>
>
> Nadie tiene la bola de cristal, pero es cierto (en mi modesto punto de vista)
> que tanto en Squeak, como ahora en Pharo, se tienen interminables ciclos de
> desarrollo de las herramientas, que nunca logran ponerse estables.....o que si
> lo hacen (como Pharo 1.1.1) duran muy poco.
>
> Muchas veces me da la sensación que trabajo con un entorno medio "de
> mentirita" o que dura muy poco. Por ejemplo implementé XMLRPC, algo por lo
> cual ESUG pagó y quedó inusable a la siguiente versión de Pharo.
>
> Es algo que desanima bastante, porque uno no sabe cuanto va a servir su
> trabajo, casi lo mismo que con las herramientas que tanto critico (ergo MS).
> Por otro lado, en Dolphin (a pesar que lamentablemente es sólo Windows) las
> cosas siguen funcionando desde hace varios años.
>
> Con seaside pass igual, o sea los cambios son tan permanentes digamos que es
> impensable tener las cosas andando mucho tiempo......Bueno, sólo unos
> pensamientos que se me ocurrieron compartir acá.
>
> Saludos.

> **
>
>
> > ¿Qué opinan de lo que dice Guido?
> >
> >
> > Nadie tiene la bola de cristal, pero es cierto (en mi modesto punto de
> vista)
> > que tanto en Squeak, como ahora en Pharo, se tienen interminables ciclos
> de
> > desarrollo de las herramientas, que nunca logran ponerse estables.....o
> que si
> > lo hacen (como Pharo 1.1.1) duran muy poco.
> >
> > Muchas veces me da la sensación que trabajo con un entorno medio "de
> > mentirita" o que dura muy poco. Por ejemplo implementé XMLRPC, algo por
> lo
> > cual ESUG pagó y quedó inusable a la siguiente versión de Pharo.
> >
> > Es algo que desanima bastante, porque uno no sabe cuanto va a servir su
> > trabajo, casi lo mismo que con las herramientas que tanto critico (ergo
> MS).
> > Por otro lado, en Dolphin (a pesar que lamentablemente es sólo Windows)
> las
> > cosas siguen funcionando desde hace varios años.
> >
> > Con seaside pass igual, o sea los cambios son tan permanentes digamos
> que es
> > impensable tener las cosas andando mucho tiempo......Bueno, sólo unos
> > pensamientos que se me ocurrieron compartir acá.
> >
> > Saludos.
>
> Y porque pensas que me mato con mis propios forks ?
> Al menos tengo claro que es lo que hago y por donde vienen los dramas.
> Me considero muy cerca de lo que vengo buscando hace años.
> Aca http://jqueryui.com/ vi algunas cosas que le pienso poner a mi
> engendro
> prontito.
>
> The 2010s, pronounced "twenty-tens"[1]
> <http://en.wikipedia.org/wiki/2010s_decade#cite_note-0> or "two thousand
> (and) tens",[2] <http://en.wikipedia.org/wiki/2010s_decade#cite_note-1>
> [3]
> <http://en.wikipedia.org/wiki/2010s_decade#cite_note-2> [4]
> <http://en.wikipedia.org/wiki/2010s_decade#cite_note-guardian-3> [5]
> <http://en.wikipedia.org/wiki/2010s_decade#cite_note-bbcnews-4> is the
> current decade which began on January 1, 2010 and will end on December 31,
> 2019. The decade is also called the second decade of the 21st century and
> 3rd millennium <http://en.wikipedia.org/wiki/3rd_millennium>
>
> Asi que no mas Naughties sino HV2010sWiki
>
> Edgar
>
>  
>

> **
>
>
> ¿Qué opinan de lo que dice Guido?
>
> Nadie tiene la bola de cristal, pero es cierto (en mi modesto punto de
> vista) que tanto en Squeak, como ahora en Pharo, se tienen interminables
> ciclos de desarrollo de las herramientas, que nunca logran ponerse
> estables.....o que si lo hacen (como Pharo 1.1.1) duran muy poco.
>
> Muchas veces me da la sensación que trabajo con un entorno medio "de
> mentirita" o que dura muy poco. Por ejemplo implementé XMLRPC, algo por lo
> cual ESUG pagó y quedó inusable a la siguiente versión de Pharo.
>
> Es algo que desanima bastante, porque uno no sabe cuanto va a servir su
> trabajo, casi lo mismo que con las herramientas que tanto critico (ergo
> MS). Por otro lado, en Dolphin (a pesar que lamentablemente es sólo
> Windows) las cosas siguen funcionando desde hace varios años.
>
> Con seaside pass igual, o sea los cambios son tan permanentes digamos que
> es impensable tener las cosas andando mucho tiempo......Bueno, sólo unos
> pensamientos que se me ocurrieron compartir acá.
>
> Saludos.
>
>
>
> ---------- Forwarded message ----------
> From: Guido Stepken <[hidden email]>
> Date: 2012/2/20
> Subject: Re: [Pharo-project] A challenge for all who cares
> To: [hidden email]
>
>
> I predicted it!
>
>
> http://forum.world.st/Hanging-connects-exhausted-resources-memory-leaks-bocked-everything-Unusable-td3669616.html
>
> You want me as experienced software architect and project manager predict
> more about Pharo's future (or doom), or are you willing to listen and learn?
>
> You will debug Pharo/Squeak until your 90 years old, because you (the
> Pharo team) is not able to address bugs systematically. This is fact!
>
> Look e.g. at LUAJit. Stable, used by estimated 10 mio users of WORLD OF
> WARCRAFT, Wikipedia, portable, rockstable.
>
> Pharo???? Unstable, nobody uses it, academic brainfuck. And Dr. Geo will
> soon be implemented in JavaScript, i think, the better solution, other apps
> will disappear soon, like CMSBOX, ... doom!
>
> My prediction, if you don't develop the development process any further!!!
>
> tnx 4 understanding,
>
> Guido Stepken
>
>  
>

> **
>
>
> En mi opinion, a veces el tema de que en Smalltalk en general las cosas
> son mas simples resulta un impedimento a largo plazo.  Por ejemplo:
>
> * "Es mas simple con Smalltalk" => "Todo lo que yo haga con Smalltalk es
> mas simple (y mejor)"
>
> * "Es mas simple con Smalltalk" => "Si no esta en Smalltalk esta mal por
> definicion"
>
> Estas premisas a la larga terminan siendo contraproducentes porque te
> cierran la cabeza.
>

> Despues de 5 años de VMs, siento que bueno, si, en Smalltalk un monton de
> cosas son mas simples y Smalltalk es buenisimo para hacer cosas complicadas
> porque no tenes que lidiar con un bardo de cosas que no tienen nada que ver
> con tu problema.  Eso sigue clarisimo.  Lo que no corre mas es esperar que
> las cosas que no tienen coneccion con Smalltalk tengan que seguir siendo
> simples.
>
> Un ejemplo de esto es ir y ver como hacer sockets como corresponde en
> varias plataformas diferentes.  Ahi te enteras que Windows no tiene nada
> que ver con *nix, y que aunque parezca cool no es necesariamente correcto
> usar sockets desde un FFI.  El problema con esto es que esta clase de
> problemas tecnicos, desde el punto de vista de Smalltalk, estan mal desde
> el vamos porque el nivel de complejidad inherente es mucho mas alto.  Por
> lo tanto, me parece que hay que reconocerlo, se desarrolla una tendencia a
> ser reticente a la hora de investigar lo que viene con el sistema operativo
> o librerias de terceros en detalle.  Porque las cosas deberian ser simples,
> no?
>
>

> Bueno entonces el quilombo me parece viene porque Smalltalk no nos entrena
> para lidiar con el quilombo que es el mundo de las APIs el dia de hoy, y
> porque nos falta entrenamiento (comparado con otra gente que quiza tiene
> una experiencia de trabajo diario diferente) nos cuesta el triple.  Eso, me
> parece, tambien se nota a la hora de atacar problemas jodidos como la
> modularidad, o la compatibilidad a largo plazo, o tener mayormente una
> cierta certeza de que tu programa efectivamente funciona.
>
> Y ojo que a mi no necesariamente me divierte ir y leer MSDN... me
> encantaria que estuviera mejor escrito, que tuviera cross-references, que
> tuviera FAQs vetados por los ingenieros de Microsoft, que no inventarar la
> n-esima manera de hacer las cosas solo por ser Microsoft... y lo mismo con
> un monton de otra gente que hace del embrace and extend la tactica por
> defecto para evitar a toda costa que un grupo de 3-5 personas pueda hacer
> un programa decente simplemente por el hecho de que es imposible entender
> todas las especificaciones pertinentes... en ese sentido no queda otra que
> apreciar la simplicidad potencial de los sistemas como Smalltalk.
>

>
> Bueno pero eso es ocmparar Smalltalk con C y demas.  La leccion que yo
> veo, sin embargo, es que tener que lidiar con el quilombo te cambia la
> manera de encarar las cosas y despues escribis Smalltalk diferente.  No
> agregas features al pedo.  No haces las cosas mas complicadas de lo que
> tienen que ser.  No usas hasta el ultimo truco tecnico porque es cool.  No
> te importa si Symbol>>value: esta implementado o no, y probablemente si
> esta implementado no lo uses porque no es esencial.  Y lo mas importante:
> te cambia el criterio para decidir cuando las cosas estan terminadas.  Los
> proyectos del fin de semana no corren mas como cosa terminada que tiene que
> tener un release.  Si no contemplas un monton de cosas que pueden andar
> mal, y como tu programa va a responder ante las eventualidades, entonces no
> te parece que esta terminado y listo para que otros lo usen.
>

> Sufrir con la fragilidad de C, donde pequeños deslices de otros hacen que
> no puedas depender de lo que hicieron, te hace ver que aunque en Smalltalk
> los programas son mucho mas robustos esos deslices tambien existen y hay
> que mantener la vigilancia y, sorpresa, el mismo tipo de disciplina que uno
> tiene cuando programa en C.  Si no, la consecuencia es que le haces la vida
> imposible a los demas.
>
> Y que tiene que ver esto con la fragilidad y demas?  Bueno, todos en
> cierto modo tenemos ese problema.  Lo vemos en VisualWorks, y me imagino
> que existe en Pharo / Squeak y en un monton de otros Smalltalks.  Hacer las
> cosas realmente bien para que no sean fragiles es *dificil* mas alla del
> ambiente.  En VisualWorks es dificil, y en Dolphin tambien, y en C lo
> mismo, etc.  No es joda.
>
> Hay dos cosas para hacer, basicamente.  La primera es simplificar para
> bajar el nivel de complejidad de fondo.  Esto es en parte a donde apunta el
> proyecto de Alan Kay de escribir un sistema de computacion completo en
> 20000 lineas de codigo.  Que lo tiro, que diferencia, ojala solo tuviera
> que leer 20000 lineas de especificaciones.  El standard del lenguaje C ya
> es mucho mas que eso --- solo la especificacion de lo que es el lenguaje
> tiene mas de 500 paginas, y no habla de librerias ni de compiladores ni de
> plataformas ni de ABIs, etc...
>
> La otra es tomarse las cosas con mas paciencia, con un plan a largo plazo
> de aca a 2 años, investigando lo que hay ya hecho antes de hacer lo tuyo
> durante unas semanas, etc.  Y si estas trabajando en C o parecido, leer un
> monton (y digo un *monton*) de especificaciones para saber que es legal y
> que no, porque eso te dice si tu programa puede que funcione o directamente
> es imposible que funcione.  No queda otra.
>
> Asi que, Macaya, que aprendi en estos años?  Que los proyectos del fin de
> semana mucho no importan a largo plazo.  Que las cosas bien hechas cuestan
> mucho mas de lo que parece, asi que conviene hacer menos cosas pero que
> esas esten bien hechas asi otros pueden depender de tu trabajo y hacer la
> suya.  Que lo "cool" en general no sirve.  Que borrar codigo es maravilloso
> (en estos 5 años borramos 30% de la VM de VisualWorks), porque te evita
> tener que investigar basura mas adelante.  Que lo bueno si breve dos veces
> bueno, y que si 10 veces breve entonces e^10 veces bueno.  Que antes de
> decir "me parece que", o "tal cosa deberia ser asi y andando [porque a mi
> me gusta]", hay que ir y leer al respecto... que lo que se dice en los
> foros de donde cualquiera opina y dice cualquier cosa es jodido y que hay
> que tener cuidado.  Que mejor el silencio antes que opiniones dudosas.
>
> Y que me gustaria que despues de tanto tiempo no estuvieramos peleandonos
> con los mismos problemas que hace 10 años.  Vamos muchachos, es dificil
> pero no hay vuelta que darle.  Limpiar codigo y limpiarlo bien una vez y
> para siempre tiene que tener mas valor que el n-esimo experimento cool que
> hoy empieza y mañana se abandona en favor de otro.  Tiene que haber un
> plan, y prioridades, y disciplina, y demas.
>
> Sip, un plan con prioridades y un camino trazado de antemano, que de

> No es aburrido ni un embole ni poco gratificante.  Por lo menos en mi
> experiencia esta bueno.  No se en detalle en que andaran los demas asi que
> no me queda otra que hablar de mi trabajo porque es lo que mas conozco.  Lo
> ultimo medio grande que hice fue re-escribir el scavenger de VisualWorks.
> Me llevo unos meses pero al final borre 1000 lineas de codigo, arregle un
> monton de bugs, anda mas rapido, le puse mas o menos 2000 tests.  Ahora
> esta escrito sin hackeaduras para que el proximo que tenga que mirarlo no
> se arranque los pelos de la frustracion.  Y a los clientes que hacian sus
> cosas raras y se les colgaba la VM, ahora les das algo que no se cuelga
> mas.  Esto esta bueno porque ahi ves que otros pueden construir cosas sobre
> una base solida que les diste.
>
>

> Bueno, entonces no me queda otra que pensar que asi hay que ir y darle al
> resto de los problemas: con el palo de amasar hasta resolverlos *del
> todo*.  Sin entrenamiento no sale.  Ahi quiza, en creer cosas del estilo de
> que como Smalltalk es facil y simple entonces lograr facil y simple es
> automatico, es donde terminamos cayendo en la trampa y por eso al final las
> cosas tienen a no salirnos como comunidad en general.  No te van a
> contratar del Barcelona para reemplazar a Messi solo por ponerte los mismos
> botines naranja.  No queda otra, hay que arremangarse y fomentar el
> arremangamiento a largo plazo.  En la mayoria de las disciplinas cuesta
> años de laburo, no siempre tenes el exito que esperas y a veces te cuesta
> diez veces mas de lo que pensabas, pero lo que hacen en La Masia y lugares
> asi bien que vale...
>
>

>
>
> 2012/2/21 Germán Arduino <[hidden email]>
>
>> **
>>
>>
>> ¿Qué opinan de lo que dice Guido?
>>
>> Nadie tiene la bola de cristal, pero es cierto (en mi modesto punto de
>> vista) que tanto en Squeak, como ahora en Pharo, se tienen interminables
>> ciclos de desarrollo de las herramientas, que nunca logran ponerse
>> estables.....o que si lo hacen (como Pharo 1.1.1) duran muy poco.
>>
>> Muchas veces me da la sensación que trabajo con un entorno medio "de
>> mentirita" o que dura muy poco. Por ejemplo implementé XMLRPC, algo por lo
>> cual ESUG pagó y quedó inusable a la siguiente versión de Pharo.
>>
>> Es algo que desanima bastante, porque uno no sabe cuanto va a servir su
>> trabajo, casi lo mismo que con las herramientas que tanto critico (ergo
>> MS). Por otro lado, en Dolphin (a pesar que lamentablemente es sólo
>> Windows) las cosas siguen funcionando desde hace varios años.
>>
>> Con seaside pass igual, o sea los cambios son tan permanentes digamos que
>> es impensable tener las cosas andando mucho tiempo......Bueno, sólo unos
>> pensamientos que se me ocurrieron compartir acá.
>>
>> Saludos.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Guido Stepken <[hidden email]>
>> Date: 2012/2/20
>> Subject: Re: [Pharo-project] A challenge for all who cares
>> To: [hidden email]
>>
>>
>> I predicted it!
>>
>>
>> http://forum.world.st/Hanging-connects-exhausted-resources-memory-leaks-bocked-everything-Unusable-td3669616.html
>>
>> You want me as experienced software architect and project manager predict
>> more about Pharo's future (or doom), or are you willing to listen and learn?
>>
>> You will debug Pharo/Squeak until your 90 years old, because you (the
>> Pharo team) is not able to address bugs systematically. This is fact!
>>
>> Look e.g. at LUAJit. Stable, used by estimated 10 mio users of WORLD OF
>> WARCRAFT, Wikipedia, portable, rockstable.
>>
>> Pharo???? Unstable, nobody uses it, academic brainfuck. And Dr. Geo will
>> soon be implemented in JavaScript, i think, the better solution, other apps
>> will disappear soon, like CMSBOX, ... doom!
>>
>> My prediction, if you don't develop the development process any further!!!
>>
>> tnx 4 understanding,
>>
>> Guido Stepken
>>
>>
>  
>

> En mi opinion, a veces el tema de que en Smalltalk en general las cosas son
> mas simples resulta un impedimento a largo plazo.  Por ejemplo:
>
> * "Es mas simple con Smalltalk" => "Todo lo que yo haga con Smalltalk es mas
> simple (y mejor)"
>
> * "Es mas simple con Smalltalk" => "Si no esta en Smalltalk esta mal por
> definicion"
>
> Estas premisas a la larga terminan siendo contraproducentes porque te cierran
> la cabeza.  Despues de 5 años de VMs, siento que bueno, si, en Smalltalk un
> monton de cosas son mas simples y Smalltalk es buenisimo para hacer cosas
> complicadas porque no tenes que lidiar con un bardo de cosas que no tienen
> nada que ver con tu problema.  Eso sigue clarisimo.  Lo que no corre mas es
> esperar que las cosas que no tienen coneccion con Smalltalk tengan que seguir
> siendo simples.
>
> Un ejemplo de esto es ir y ver como hacer sockets como corresponde en varias
> plataformas diferentes.  Ahi te enteras que Windows no tiene nada que ver con
> *nix, y que aunque parezca cool no es necesariamente correcto usar sockets
> desde un FFI.  El problema con esto es que esta clase de problemas tecnicos,
> desde el punto de vista de Smalltalk, estan mal desde el vamos porque el nivel
> de complejidad inherente es mucho mas alto.  Por lo tanto, me parece que hay
> que reconocerlo, se desarrolla una tendencia a ser reticente a la hora de
> investigar lo que viene con el sistema operativo o librerias de terceros en
> detalle.  Porque las cosas deberian ser simples, no?
>
> Bueno entonces el quilombo me parece viene porque Smalltalk no nos entrena
> para lidiar con el quilombo que es el mundo de las APIs el dia de hoy, y
> porque nos falta entrenamiento (comparado con otra gente que quiza tiene una
> experiencia de trabajo diario diferente) nos cuesta el triple.  Eso, me
> parece, tambien se nota a la hora de atacar problemas jodidos como la
> modularidad, o la compatibilidad a largo plazo, o tener mayormente una cierta
> certeza de que tu programa efectivamente funciona.
>
> Y ojo que a mi no necesariamente me divierte ir y leer MSDN... me encantaria
> que estuviera mejor escrito, que tuviera cross-references, que tuviera FAQs
> vetados por los ingenieros de Microsoft, que no inventarar la n-esima manera
> de hacer las cosas solo por ser Microsoft... y lo mismo con un monton de otra
> gente que hace del embrace and extend la tactica por defecto para evitar a
> toda costa que un grupo de 3-5 personas pueda hacer un programa decente
> simplemente por el hecho de que es imposible entender todas las
> especificaciones pertinentes... en ese sentido no queda otra que apreciar la
> simplicidad potencial de los sistemas como Smalltalk.
>
> Bueno pero eso es ocmparar Smalltalk con C y demas.  La leccion que yo veo,
> sin embargo, es que tener que lidiar con el quilombo te cambia la manera de
> encarar las cosas y despues escribis Smalltalk diferente.  No agregas features
> al pedo.  No haces las cosas mas complicadas de lo que tienen que ser.  No
> usas hasta el ultimo truco tecnico porque es cool.  No te importa si
> Symbol>>value: esta implementado o no, y probablemente si esta implementado no
> lo uses porque no es esencial.  Y lo mas importante: te cambia el criterio
> para decidir cuando las cosas estan terminadas.  Los proyectos del fin de
> semana no corren mas como cosa terminada que tiene que tener un release.  Si
> no contemplas un monton de cosas que pueden andar mal, y como tu programa va a
> responder ante las eventualidades, entonces no te parece que esta terminado y
> listo para que otros lo usen.  Sufrir con la fragilidad de C, donde pequeños
> deslices de otros hacen que no puedas depender de lo que hicieron, te hace ver
> que aunque en Smalltalk los programas son mucho mas robustos esos deslices
> tambien existen y hay que mantener la vigilancia y, sorpresa, el mismo tipo de
> disciplina que uno tiene cuando programa en C.  Si no, la consecuencia es que
> le haces la vida imposible a los demas.
>
> Y que tiene que ver esto con la fragilidad y demas?  Bueno, todos en cierto
> modo tenemos ese problema.  Lo vemos en VisualWorks, y me imagino que existe
> en Pharo / Squeak y en un monton de otros Smalltalks.  Hacer las cosas
> realmente bien para que no sean fragiles es *dificil* mas alla del ambiente.
> En VisualWorks es dificil, y en Dolphin tambien, y en C lo mismo, etc.  No es
> joda.
>
> Hay dos cosas para hacer, basicamente.  La primera es simplificar para bajar
> el nivel de complejidad de fondo.  Esto es en parte a donde apunta el proyecto
> de Alan Kay de escribir un sistema de computacion completo en 20000 lineas de
> codigo.  Que lo tiro, que diferencia, ojala solo tuviera que leer 20000 lineas
> de especificaciones.  El standard del lenguaje C ya es mucho mas que eso ---
> solo la especificacion de lo que es el lenguaje tiene mas de 500 paginas, y no
> habla de librerias ni de compiladores ni de plataformas ni de ABIs, etc...
>
> La otra es tomarse las cosas con mas paciencia, con un plan a largo plazo de
> aca a 2 años, investigando lo que hay ya hecho antes de hacer lo tuyo durante
> unas semanas, etc.  Y si estas trabajando en C o parecido, leer un monton (y
> digo un *monton*) de especificaciones para saber que es legal y que no, porque
> eso te dice si tu programa puede que funcione o directamente es imposible que
> funcione.  No queda otra.
>
> Asi que, Macaya, que aprendi en estos años?  Que los proyectos del fin de
> semana mucho no importan a largo plazo.  Que las cosas bien hechas cuestan
> mucho mas de lo que parece, asi que conviene hacer menos cosas pero que esas
> esten bien hechas asi otros pueden depender de tu trabajo y hacer la suya.
> Que lo "cool" en general no sirve.  Que borrar codigo es maravilloso (en estos
> 5 años borramos 30% de la VM de VisualWorks), porque te evita tener que
> investigar basura mas adelante.  Que lo bueno si breve dos veces bueno, y que
> si 10 veces breve entonces e^10 veces bueno.  Que antes de decir "me parece
> que", o "tal cosa deberia ser asi y andando [porque a mi me gusta]", hay que
> ir y leer al respecto... que lo que se dice en los foros de donde cualquiera
> opina y dice cualquier cosa es jodido y que hay que tener cuidado.  Que mejor
> el silencio antes que opiniones dudosas.
>
> Y que me gustaria que despues de tanto tiempo no estuvieramos peleandonos con
> los mismos problemas que hace 10 años.  Vamos muchachos, es dificil pero no
> hay vuelta que darle.  Limpiar codigo y limpiarlo bien una vez y para siempre
> tiene que tener mas valor que el n-esimo experimento cool que hoy empieza y
> mañana se abandona en favor de otro.  Tiene que haber un plan, y prioridades,
> y disciplina, y demas.
>
> No es aburrido ni un embole ni poco gratificante.  Por lo menos en mi
> experiencia esta bueno.  No se en detalle en que andaran los demas asi que no
> me queda otra que hablar de mi trabajo porque es lo que mas conozco.  Lo
> ultimo medio grande que hice fue re-escribir el scavenger de VisualWorks.  Me
> llevo unos meses pero al final borre 1000 lineas de codigo, arregle un monton
> de bugs, anda mas rapido, le puse mas o menos 2000 tests.  Ahora esta escrito
> sin hackeaduras para que el proximo que tenga que mirarlo no se arranque los
> pelos de la frustracion.  Y a los clientes que hacian sus cosas raras y se les
> colgaba la VM, ahora les das algo que no se cuelga mas.  Esto esta bueno
> porque ahi ves que otros pueden construir cosas sobre una base solida que les
> diste.
>
> Bueno, entonces no me queda otra que pensar que asi hay que ir y darle al
> resto de los problemas: con el palo de amasar hasta resolverlos *del todo*.
> Sin entrenamiento no sale.  Ahi quiza, en creer cosas del estilo de que como
> Smalltalk es facil y simple entonces lograr facil y simple es automatico, es
> donde terminamos cayendo en la trampa y por eso al final las cosas tienen a no
> salirnos como comunidad en general.  No te van a contratar del Barcelona para
> reemplazar a Messi solo por ponerte los mismos botines naranja.  No queda
> otra, hay que arremangarse y fomentar el arremangamiento a largo plazo.  En la
> mayoria de las disciplinas cuesta años de laburo, no siempre tenes el exito
> que esperas y a veces te cuesta diez veces mas de lo que pensabas, pero lo que
> hacen en La Masia y lugares asi bien que vale...
>
> Mis dos centavitos...

> **
>
>
> Tanto las expresiones de Andrés, como los comentarios de Germán y Edgar,
> me han hecho recordar una frase que leí en un librito para aprender a
> tocar la armónica, que decía así:
>
> "Tocar la armónica es muy fácil, cualquiera que sepa soplar puede
> hacerlo, ahora, tocar BIEN la armónica es otra historia, requiere de
> paciencia, mucha práctica, tiempo y empeño"
>
> Un Abrazo,
>
> Francisco
>
> El mar, 21-02-2012 a las 17:20 -0200, Edgar J. De Cleene escribió:
>
> > Muy claro y contundente.
> > Es como les vengo diciendo, no quieran escalar el Everest si nunca
> > subieron
> > a La Montañita
> >
> > Edgar
>
>  
>