Ojo con el buscaminas que no es trivial para nada... a mi me llevo un monton de tiempo hacerlo bien!
2009/11/13 Hernan Wilkinson <[email protected]>: > > > 2009/11/13 GallegO <[email protected]> >> >> Yo me prendería, aunque no se si da para mezclarlo con el día del >> Pharo sprint, medio que nos van a mandar a cag.ar > > no, vamos a otro laboratorio y listo, si se puede lo hacemos, no tengo > drama. > >> >> No se me ocurre que sería hacer algo groso. > > digo, no una pavada, pensar algún ejemplo interesante... yo tengo un par de > ejemplos pero son chiquitos, que se yo > Siempre tuve ganas de hacer un juego con tdd pero nunca tuve tiempo. como el > pacman, buscaminas, etc. > > >> >> Convengamos que seria algo sobre tdd suponiendo que ya conocemos el >> uso de sunit. > > si, tal cual > >> >> Estaría bueno. >> >> Saludos >> GallegO >> >> El día 13 de noviembre de 2009 14:03, Hernan Wilkinson >> <[email protected]> escribió: >> > 45 minutos no alcanzan para mostrar tdd en serio y tampoco alcanza una >> > tarde, es un cambio de hábito muy fuerte y se logra de a poco, pero yo >> > no >> > tengo problema el sabado por la tarde estemos toda la tarde haciendo un >> > sistema con tdd, algo groso, no un ejemplito pedorro. >> > >> > 2009/11/13 Mariano Abel Coca <[email protected]> >> >> >> >> Por lo que estuve leyendo, creo que el mayor problema con el que se han >> >> encontrado es que los tests que han definido no son funcionales sino >> >> estructurales. >> >> >> >> Los tests funcionales no debería ser necesario modificarlos o >> >> corregirlos >> >> salvo que cambie la funcionalidad del sistema. Es decir, debería poder >> >> hacer >> >> un refactoring sin tener que corregir ningún test. En esta situación, >> >> los >> >> tests ayudan al refactoring, y aseguran que el sistema sigue andando >> >> una vez >> >> de que cambiaste lo que querías, y está bueno. Hablo de tests que no >> >> testeen >> >> el protocolo de creación y accessing de un objeto, sino que testeen que >> >> se >> >> pueda hacer x o y en el sistema. >> >> >> >> Es por eso que me parece que es positivo que todos los programadores >> >> conozcan el dominio de lo que están modelando, les da la posibilidad de >> >> escribir esos tests funcionales automatizados. Lo bueno de estos tests >> >> es >> >> que liberan la carga de los testers de tener que hacer un test de >> >> regresión >> >> de semanas para garantizar que un refactoring no rompe nada. Cuando >> >> hago un >> >> refactoring groso corro 23.000 tests que garantizan que el sistema >> >> funciona, >> >> en menos de una hora. >> >> >> >> Hernán, me parece que es una buena idea la de armar un workshop de TDD, >> >> con un ejemplo sencillo y que se pueda desarrollar, al menos >> >> parcialmente, >> >> en la duración de una charla. No para esta Smalltalks que ya está >> >> bastante >> >> cerrada, pero si tenés tiempo para el año que viene, creo que estaría >> >> bueno >> >> y más de uno se anotaría para verla. Habría que pensar bien el ejemplo >> >> para >> >> que no sea ni demasiado complejo ni demasiado pavo, que aporte lo que >> >> se >> >> busca y que se pueda hacer en el tiempo acotado. >> >> >> >> Incluso puede ser la excusa para que encuentres el ejemplo ideal para >> >> tu >> >> clase de poo :) ¿Viste que buenos que somos para buscarte laburo? >> >> >> >> Saludos, >> >> >> >> Mariano. >> >> >> >> >> >> 2009/11/13 Guillermo Sapaya <[email protected]> >> >>> >> >>> Hola a todos, >> >>> >> >>> Hernán decía: >> >>> > no entiendo la pregunta... a ver, si queres tener software robusto >> >>> > tenemos >> >>> > que testear, creo que eso no tiene sentido discutirlo. >> >>> >> >>> Seguro, hasta acá venimos pensando igual :-) >> >>> >> >>> Luego decía: >> >>> >> >>> > no entiendo la pregunta... a ver, si queres tener software robusto >> >>> > tenemos >> >>> > que testear, creo que eso no tiene sentido discutirlo. >> >>> > La pregunta es, cuando queremos testear y como. Al principio o al >> >>> > final >> >>> > del >> >>> > desarrollo? de manera automática o manual? >> >>> > Para mi: cuanto antes mejor y de manera automática. >> >>> >> >>> Para mí también, pero igualmente no concuerdo en que la mejor forma de >> >>> testear sea haciendo TDD. Por lo menos no en mi caso y el de la otra >> >>> gente >> >>> que conozco. >> >>> IMHO TDD es muy bueno y productivo para cierto tipo de gente y para >> >>> otro, >> >>> muy "deprimente". >> >>> En mi caso me siento completamente atado de pies y manos y no me deja >> >>> trabajar explorando el dominio como vos decís pero a mi manera. >> >>> Siempre me >> >>> caractericé por hacer sistemas prototipando, generando mis primeros >> >>> objetitos y haciéndolos funcionar en conjunto para que estén >> >>> disponibles lo >> >>> antes posible para el usuario final. Y al contrario de lo que >> >>> argumentan los >> >>> pro TDD, querer prototipar o explorar el domino a partir de los tests >> >>> me >> >>> saca de foco mal. Creo que tiene mucho que ver con la forma de laburar >> >>> de >> >>> cada uno. >> >>> En mi caso (y el de muchos compañeros smalltalkers) priorizamos el >> >>> laburo >> >>> rápido, evolutivo e incremental y el refactorizar SIEMPRE que se crea >> >>> necesario sin importar lo grande que sea el impacto del refactoring >> >>> siempre >> >>> que sea para bien. Hacer eso con [ponga aquí el numero que desee] >> >>> tests de >> >>> fondo que después tengo que estar manteniendo para mí es >> >>> impracticable. >> >>> Repito, para mí. Seguramente en otros casos (como en el tuyo) les >> >>> resulta >> >>> satisfactorio. >> >>> Al contrario de lo que he oído muchas veces, opino que el test del >> >>> producto final NO es responsabilidad del desarrollador (seguramente >> >>> acá es >> >>> donde empiezan a dudar de mi buen desempeño como desarrollador y como >> >>> lider >> >>> de un grupo de desarrolladores :-P). >> >>> El desarrollador debe asegurar que lo que hizo y entregó al integrador >> >>> anda según lo pedido pero no debe hacer tests funcionales. Para ello >> >>> hay >> >>> otro rol que es el de testers, y un tester no tiene porque saber nada >> >>> de >> >>> Smalltalk, ni mucho menos de SUnit y TDD. Pero sí de la manera de >> >>> trabajar y >> >>> la sinergia del grupo de trabajo. >> >>> El grupo de desarrollo debería brindarle a los testers una herramienta >> >>> que permita poder trabajar en la realización de tests automáticos >> >>> desde un >> >>> principio. Me refiero a que el tester/usuario pueda definir todos los >> >>> casos >> >>> de uso que se le ocurra mediante el uso de dicha herramienta, y que >> >>> estos >> >>> casos de uso puedan "correrse" en cada nuevo release interno de >> >>> desarrollo o >> >>> cuando se desee. >> >>> En fin, es un tema para largo pero bueno, por lo menos expuse mi >> >>> opinión. >> >>> >> >>> Saludos, >> >>> Guillermo Sapaya >> >>> >> >>> ----- Original Message ----- >> >>> From: Hernan Wilkinson >> >>> [mailto:[email protected]] >> >>> To: [email protected] >> >>> Sent: >> >>> Fri, 13 Nov 2009 09:37:06 -0200 >> >>> Subject: [clubSmalltalk] Re: DIscusion >> >>> polemica >> >>> >> >>> >> >>> > 2009/11/12 GallegO <[email protected]> >> >>> > >> >>> > > >> >>> > > Hola Diego: >> >>> > > >> >>> > > Esto derivó en algo muy copado. El tema de los tests, creo que lo >> >>> > > describiste perfecto, yo también siento lo mismo. El tema es que a >> >>> > > medida que el desarrollo va madurando empieza a cambiar menos, >> >>> > > hasta >> >>> > > que se lo pone a prueba en distintas situaciones. En ese momento, >> >>> > > puede ser que haya pasado bastante tiempo desde que se escribió >> >>> > > ese >> >>> > > código, empieza a surgir la necesidad de cambio real, dada por >> >>> > > algo >> >>> > > externo. Vamos a modificar y empezamos a dejar caconas por todos >> >>> > > lados, sin darnos cuenta. No me quiero imaginar que pasa cuando >> >>> > > ese >> >>> > > mismo código lo toca alguien que no tiene el conocimiento de >> >>> > > haberlo >> >>> > > desarrollado, por más que sea una pieza única y bien pulida. >> >>> > > ¿Como se hace para tener tantos tests? >> >>> > > >> >>> > >> >>> > no entiendo la pregunta... a ver, si queres tener software robusto >> >>> > tenemos >> >>> > que testear, creo que eso no tiene sentido discutirlo. >> >>> > La pregunta es, cuando queremos testear y como. Al principio o al >> >>> > final >> >>> > del >> >>> > desarrollo? de manera automática o manual? >> >>> > Para mi: cuanto antes mejor y de manera automática. >> >>> > >> >>> > >> >>> > > ¿Cuando desarrollas el producto si es que tenes que escribir >> >>> > > tantos >> >>> > tests? >> >>> > > >> >>> > >> >>> > es un pregunta capciosa... lo escribis mienstras desarrollas... >> >>> > tambien >> >>> > podríamos decir, si hay que diseñar tanto o jugar tanto en el >> >>> > workspace, >> >>> > cuando desarrollas? pero la verdad es que si haces tdd bien, >> >>> > desarrollar >> >>> > mientras hacer funcionar los tests, directamente desde el debugger, >> >>> > es >> >>> > maravilloso >> >>> > >> >>> > >> >>> > > Es decir, las respuestas seguramente sean simples, pero las >> >>> > > ecuaciones >> >>> > > en tiempo y dinero no. >> >>> > > >> >>> > >> >>> > Eso es contextual y depende del tiempo... a mediano plazo cualquier >> >>> > sistema >> >>> > no testeado te va a traer más problemas que uno testeado. >> >>> > >> >>> > >> >>> > > >> >>> > > Para mi, y para mi trabajo actual, no es tan simple. >> >>> > > >> >>> > > Saludos >> >>> > > GallegO >> >>> > > >> >>> > > >> >>> > > El día 12 de noviembre de 2009 18:58, [email protected] >> >>> > > <[email protected]> escribió: >> >>> > > > >> >>> > > > Gabriel, >> >>> > > > Antes que nada aclaro que tanto el tipado como el uso de tests >> >>> > > > son >> >>> > > > técnicas que considero útiles en su debido contexto. Incluso >> >>> > > > creo >> >>> > > > que >> >>> > > > los smalltalkers deberían tipar un poquito mas, o un poquito >> >>> > > > antes. >> >>> > > > De los tests me preocupan dos aspectos: >> >>> > > > 1) Un conjunto de tests es un sistema en si mismo y tiende a >> >>> > > > estar >> >>> > > > fuertemente acoplado con el sistema que se quiere testear. Este >> >>> > > > acoplamiento, como casi todo acoplamiento, resulta un lastre en >> >>> > > > la >> >>> > > > evolución del sistema. Un sistema repleto de tests requiere mas >> >>> > > > tiempo >> >>> > > > para ser modificado. Los amantes de TDD argumentan que dicha >> >>> > > > evolución >> >>> > > > es "mas segura" porque está controlada por la validez de los >> >>> > > > tests, >> >>> > > > y >> >>> > > > a mi eso me genera serias dudas. Otro efecto similar que >> >>> > > > producen >> >>> > > > los >> >>> > > > tests es que el desarrollador (o jefe) se contenta con ver todas >> >>> > > > las >> >>> > > > luces verdes y puede que se relaje en actividades de >> >>> > > > factorización, >> >>> > > > en >> >>> > > > cambiar cosas, porque generalmente antes de fallar un tests, >> >>> > > > falla >> >>> > > > la >> >>> > > > implementación del mismo. >> >>> > > > 2) El segundo aspecto tiene que ver con el análisis y diseño. >> >>> > > > Está >> >>> > > > bueno ver que los programadores de Ruby, a partir de TDD, >> >>> > > > entienden >> >>> > > > que es bueno declarar primero la intención inicial y luego >> >>> > > > teclear >> >>> > > > la >> >>> > > > solución. En Smalltalk esto se puede hacer con tests o con un >> >>> > > > workspace. Esto implica haber entendido que era mejor escribir >> >>> > > > el >> >>> > > > problema y luego la solución, a que ir directamente con un >> >>> > > > diseño y >> >>> > > > luego ver si anda. Pero pensar que uno conoce el problema de >> >>> > > > antemano >> >>> > > > suele ser ingenuo también, por lo tanto es mas conveniente ir >> >>> > > > modificando también la intención inicial a partir de lo que se >> >>> > > > aprende >> >>> > > > en la interacción con el sistema. Entonces ahi me molestan los >> >>> > > > tests y >> >>> > > > prefiero usar workspaces, de esos que uso toco y tiro todo el >> >>> > > > tiempo. >> >>> > > > Porque no solo no está claro una solución antes de resolver un >> >>> > > > problema, sino que suele no estar claro el problema tampoco. >> >>> > > > Smalltalk >> >>> > > > nos da muchas herramientas para entender un problema y en ese >> >>> > > > ida y >> >>> > > > vuelta los tests estorban mas que ayudar. >> >>> > > > >> >>> > > > Saludos, >> >>> > > > Diego Coronel >> >>> > > > >> >>> > > > >> >>> > > > On 12 nov, 12:52, Gabriel Brunstein <[email protected]> wrote: >> >>> > > >> Diego, me interesa tu punto de vista, por qué afirmas que es >> >>> > > >> nociva la >> >>> > > >> seguridad que te dan los tests? >> >>> > > >> >> >>> > > >> 2009/11/12 [email protected] <[email protected]> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> > Mariano, >> >>> > > >> > Lo que decis me hizo relacionar el tipo de seguridad que da >> >>> > > >> > el >> >>> > > >> > tipado >> >>> > > >> > con el tipo de seguridad que dan los tests. En ambos casos, >> >>> > > >> > IMHO, >> >>> > > >> > sobredimensionada y nociva a corto plazo. >> >>> > > >> >> >>> > > >> > Diego >> >>> > > >> >> >>> > > >> > On 12 nov, 11:53, Mariano Abel Coca >> >>> > > >> > <[email protected]> >> >>> > > wrote: >> >>> > > >> > > Simplemente para aportar un detalle más. >> >>> > > >> >> >>> > > >> > > Saludos, >> >>> > > >> >> >>> > > >> > > Mariano. >> >>> > > >> >> >>> > > >> > > 2009/11/12 Hernán Galante <[email protected]> >> >>> > > >> >> >>> > > >> > > > Lindo intercambio :-) >> >>> > > >> > > > A mi parecer, no tiene tanto que ver la escritura en sí, >> >>> > > >> > > > porque >> >>> > > Ruby o >> >>> > > >> > > > Objective C son una copia casi del "Smalltalk lenguaje". >> >>> > > >> > > > Lo >> >>> > > >> > > > que >> >>> > en >> >>> > > mi >> >>> > > >> > > > opinión sucede es un mix de cosas. La primera, es el >> >>> > > >> > > > tipado. >> >>> > > >> > > > La >> >>> > > >> > compilación >> >>> > > >> > > > da cierta "seguridad", pues para el que escribe existe >> >>> > > >> > > > alguien >> >>> > que >> >>> > > se >> >>> > > >> > las >> >>> > > >> > > > sabe todas que te corrige (compilación para hacer el >> >>> > > >> > > > runtime). >> >>> > > Esta >> >>> > > >> > > > "seguridad" no se brinda en Smalltalk, pero todos sabemos >> >>> > > >> > > > que los >> >>> > > >> > > > errores también se compilan sin problemas, el punto aquí >> >>> > > >> > > > es >> >>> > > >> > > > que >> >>> > es >> >>> > > un >> >>> > > >> > engaño >> >>> > > >> > > > emocional que hace sentir más seguro a sus programadores. >> >>> > > >> >> >>> > > >> > > Esta seguridad en smalltalk la obtenés fácilmente con una >> >>> > > >> > > buena >> >>> > > batería >> >>> > > >> > de >> >>> > > >> > > tests, e inclusive la seguridad que dan los tests es mayor >> >>> > > >> > > que >> >>> > > >> > > la >> >>> > > que da >> >>> > > >> > el >> >>> > > >> > > compilador... Y no hablo sólo de tests funcionales sino de >> >>> > > >> > > tests >> >>> > del >> >>> > > >> > > metamodelo. Claro que esas cosas en los otros lenguajes no >> >>> > > >> > > existen >> >>> > > :) >> >>> > > >> >> >>> > > >> > > > La segunda que no entienden de Smalltalk es su concepto >> >>> > holístico. >> >>> > > Que >> >>> > > >> > no >> >>> > > >> > > > hay diferencia entre el sistema en desarrollo y el >> >>> > > >> > > > productivo, >> >>> > que >> >>> > > no >> >>> > > >> > hay >> >>> > > >> > > > diferencia entre IDE y sistema en construcción, no hay >> >>> > diferencia >> >>> > > entre >> >>> > > >> > mi >> >>> > > >> > > > código y el código que ya existe, etc, etc. Cuantas veces >> >>> > > >> > > > han >> >>> > > vistos o >> >>> > > >> > nos >> >>> > > >> > > > ha pasado cuando recién arrancábamos que nos poníamos en >> >>> > > >> > > > duda >> >>> > al >> >>> > > >> > modificar >> >>> > > >> > > > un método de una clase de base, o no entender que podemos >> >>> > > modificar el >> >>> > > >> > IDE >> >>> > > >> > > > para que browser haga las cosas que yo quiero, que puedo >> >>> > > >> > > > agregar >> >>> > > en >> >>> > > >> > cuestión >> >>> > > >> > > > de unos minutos nuevas opciones, etc. >> >>> > > >> > > > El otro punto, que tiene que ver con esto de un todo >> >>> > > >> > > > dentro >> >>> > > >> > > > de >> >>> > > >> > Smalltalk, >> >>> > > >> > > > es la no existencia de archivos. Esto genera cierta >> >>> > > >> > > > incomodidad >> >>> > > para >> >>> > > >> > > > programadores acostumbrados a que la unidad mínima sea un >> >>> > archivo, >> >>> > > pues >> >>> > > >> > es >> >>> > > >> > > > un esquema brindado fuertemente por el sistema operativo. >> >>> > > >> > > > El >> >>> > hecho >> >>> > > >> > también >> >>> > > >> > > > es educacional, pues el ambiente cuantas veces se >> >>> > > >> > > > "ensucia" >> >>> > > >> > > > o >> >>> > > >> > "contamina" y >> >>> > > >> > > > empezamos a no saber para que lado ir. Eso en un ambiente >> >>> > > >> > > > basado >> >>> > > en >> >>> > > >> > > > archivos, solo se disfraza la suciedad .. :-). Es más, el >> >>> > > >> > > > hecho >> >>> > de >> >>> > > >> > cambiar >> >>> > > >> > > > de una BBDD a un Gemstone por ejemplo, esto de luchar >> >>> > > >> > > > contra >> >>> > > >> > > > la >> >>> > > >> > "basura", es >> >>> > > >> > > > el principal problema a atender/atacar al administrarla, >> >>> > > >> > > > en >> >>> > > >> > > > una >> >>> > > BBDD la >> >>> > > >> > > > basura existe por siempre y no nos damos cuenta (hasta >> >>> > > >> > > > que >> >>> > > conectamos >> >>> > > >> > un >> >>> > > >> > > > producto BI y saltan todos los sapos). >> >>> > > >> > > > De hecho, no tener esta educación en nuestra sociedad >> >>> > > >> > > > entera >> >>> > > >> > > > nos >> >>> > > lleva >> >>> > > >> > a >> >>> > > >> > > > enfrentarnos que tenemos al planeta completo contaminado >> >>> > > >> > > > y >> >>> > > >> > > > no >> >>> > > sabemos >> >>> > > >> > ni que >> >>> > > >> > > > hacer. >> >>> > > >> > > > Smalltalk es demasiado avanzado para que todos lo >> >>> > > >> > > > entiendan, >> >>> > > >> > > > eso >> >>> > > es >> >>> > > >> > algo >> >>> > > >> > > > que hay que aceptar. Es una falta de educación en el >> >>> > > >> > > > fondo. >> >>> > > >> >> >>> > > >> > > > Saludos, >> >>> > > >> > > > Hernán.- >> >>> > > >> >> >>> > > >> > > > On Wed, Nov 11, 2009 at 3:14 PM, Bruno Buzzi Brassesco < >> >>> > > >> > > > [email protected]> wrote: >> >>> > > >> >> >>> > > >> > > >> Es una percepción general de la gente de los lenguajes >> >>> > > tradicionales. >> >>> > > >> > > >> En la software factory que trabajaba tambien pensaban >> >>> > > >> > > >> asi >> >>> > > >> > > >> lo que >> >>> > > >> > conocían >> >>> > > >> > > >> (aunque se a de nombre) Smalltalk. >> >>> > > >> >> >>> > > >> > > >> Pero no pienses que en C# no podes meter la pata, >> >>> > > >> > > >> trabaje >> >>> > > >> > > >> con un >> >>> > > >> > Framework >> >>> > > >> > > >> en C# que era algo lamentable, no voy a poner nombres, >> >>> > > >> > > >> pero >> >>> > > >> > > >> la >> >>> > > gente >> >>> > > >> > que >> >>> > > >> > > >> construyo esa cosa, era "gurus" de M$. Y mira que es >> >>> > > >> > > >> imposible >> >>> > > que te >> >>> > > >> > > >> imagines el dolor de los programadores cuando querian >> >>> > > >> > > >> construir >> >>> > > un >> >>> > > >> > sistema >> >>> > > >> > > >> usando esa cosa. >> >>> > > >> >> >>> > > >> > > >> El problema de C# en este caso es que el Framework >> >>> > > >> > > >> estaba >> >>> > > >> > > >> "bien >> >>> > > >> > pensando" >> >>> > > >> > > >> desde el punto de vista de la arquitectura, cuando >> >>> > > >> > > >> llevas >> >>> > > >> > > >> esa >> >>> > > "buena >> >>> > > >> > idea" >> >>> > > >> > > >> de arquitectura a la practica y construis, el ambiente >> >>> > > >> > > >> de >> >>> > > desarrollo >> >>> > > >> > te >> >>> > > >> > > >> queda algo que no se puede describir con palabras (un >> >>> > > >> > > >> desastre). >> >>> > > >> > > >> Y esto es porque C# no es homogeneo en Smalltalk no hay >> >>> > > diferencia >> >>> > > >> > entre >> >>> > > >> > > >> arquitectura y ambiente de desarrollo, hay objetos de... >> >>> > > >> >> >>> > > >> > > >> En broma les decia los programadores de C#, eso que >> >>> > > >> > > >> tenes >> >>> > > >> > > >> ahí >> >>> > es: >> >>> > > "un >> >>> > > >> > > >> compilador + un combo box". >> >>> > > >> > > >> Eso es C#, un compilador (c#) y ComboBox que te hace un >> >>> > > >> > > >> goto al >> >>> > > codigo >> >>> > > >> > > >> fuente. Y la librería de C# es usanda como un gran >> >>> > > >> > > >> repositorio >> >>> > de >> >>> > > >> > > >> procedimientos, asi usan C# todos los programadores, >> >>> > > >> > > >> incluso los >> >>> > > Mega >> >>> > > >> > Mega >> >>> > > >> > > >> MS Mega Seniors Expert. >> >>> > > >> >> >>> > > >> > > >> En la tecnologia tradicional lo que llaman "orientado a >> >>> > > >> > > >> objetos" >> >>> > > NO se >> >>> > > >> > > >> acerca ni por asomo a como se trabaja en Smalltalk, es >> >>> > > >> > > >> muy >> >>> > > diferente >> >>> > > >> > la >> >>> > > >> > > >> forma de resolver problemas y construir sistemas. >> >>> > > >> > > >> La confusion radica en que se usa el mismo termino: " >> >>> > > >> > > >> orientado >> >>> > a >> >>> > > >> > objetos" >> >>> > > >> >> >>> > > >> > > >> Saludos, >> >>> > > >> > > >> Bruno >> >>> > > >> >> >>> > > >> > > >> -----Original Message----- >> >>> > > >> > > >> From: [email protected] [mailto: >> >>> > > >> > > >> [email protected]] >> >>> > > >> > > >> On Behalf Of Rusty >> >>> > > >> > > >> Sent: Wednesday, November 11, 2009 4:47 PM >> >>> > > >> > > >> To: ClubSmalltalk >> >>> > > >> > > >> Subject: [clubSmalltalk] Re: DIscusion polemica >> >>> > > >> >> >>> > > >> > > >> No sé si es lo que lo mató, o si siquiera está muerto. >> >>> > > >> > > >> Pero si sé que estoy de acuerdo con el comentario. >> >>> > > >> >> >>> > > >> > > >> Smalltalk es el paraíso de los buenos programadores. >> >>> > > >> > > >> Pero también es el paraíso para el desprolijo y el que >> >>> > > >> > > >> ata >> >>> > > >> > > >> con >> >>> > > >> > > >> alambre. >> >>> > > >> > > >> Y eso último es jo-di-do. >> >>> > > >> >> >>> > > >> > > >> Salutes. >> >>> > > >> >> >>> > > >> > > >> Rusty. >> >>> > > >> >> >>> > > >> > > >> On 10 nov, 10:31, GallegO <[email protected]> wrote: >> >>> > > >> > > >> > Se desato una discusion en el blog de cincom y rescato >> >>> > > >> > > >> > un >> >>> > > comentario >> >>> > > >> > > >> > que quiero compartir: >> >>> > > >> >> >>> > > >> > > >> > Completo enhttp://bit.ly/Uu517 >> >>> > > >> >> >>> > > >> > > >> > ...but I think the context of the quote is being >> >>> > misinterpreted >> >>> > > >> > > >> > somewhat. My impression from the video wasn't that >> >>> > > >> > > >> > Bob >> >>> > > >> > > >> > was >> >>> > > >> > > >> > misrepresenting Cunningham's meaning, but just that he >> >>> > > >> > > >> > wasn't >> >>> > > >> > > >> > explaining it very well. >> >>> > > >> > > >> > 'What killed Smalltalk is that it was just too easy to >> >>> > > >> > > >> > make a >> >>> > > mess." >> >>> > > >> > > >> > I think that's absolutely true, but it isn't >> >>> > > >> > > >> > necessarily >> >>> > > >> > > >> > a bad >> >>> > > >> > thing. >> >>> > > >> > > >> > The truth is that in Smalltalk it's often easier to do >> >>> > > anything, >> >>> > > >> > both >> >>> > > >> > > >> > good and bad. It's rather like saying that the >> >>> > > >> > > >> > problem >> >>> > > >> > > >> > with a >> >>> > > >> > > >> > motorcycle, compared to a bicycle, is that it's just >> >>> > > >> > > >> > too >> >>> > > >> > > >> > easy >> >>> > > to go >> >>> > > >> > > >> > too fast and wreck one. With programming languages, >> >>> > > >> > > >> > as >> >>> > > >> > > >> > with >> >>> > > bikes, >> >>> > > >> > if >> >>> > > >> > > >> > you give a powerful tool to an undisciplined, >> >>> > > >> > > >> > inexperienced >> >>> > > user, >> >>> > > >> > they >> >>> > > >> > > >> > can cause a lot of damage. >> >>> > > >> > > >> > If the only vehicle you give someone is a one-gear >> >>> > > >> > > >> > bicycle >> >>> > with >> >>> > > >> > street >> >>> > > >> > > >> > tires and training wheels, it'll be really hard for >> >>> > > >> > > >> > them >> >>> > > >> > > >> > to >> >>> > > hurt >> >>> > > >> > > >> > themselves, but they're never going to go very far or >> >>> > > >> > > >> > very >> >>> > > fast, >> >>> > > >> > > >> > either. >> >>> > > >> >> >>> > > >> > > >> > Saludos >> >>> > > >> > > >> > GallegO >> >>> > > >> >> >>> > > >> > > >> No virus found in this incoming message. >> >>> > > >> > > >> Checked by AVG -www.avg.com >> >>> > > >> > > >> Version: 8.5.424 / Virus Database: 270.14.53/2486 - >> >>> > > >> > > >> Release >> >>> > Date: >> >>> > > >> > 11/07/09 >> >>> > > >> > > >> 07:38:00- Ocultar texto de la cita - >> >>> > > >> >> >>> > > >> > > - Mostrar texto de la cita -- Ocultar texto de la cita - >> >>> > > >> >> >>> > > >> - Mostrar texto de la cita - >> >>> > > > > >> >>> > > > >> >>> > > >> >>> > > > >> >>> > > >> >>> > >> >>> > > >> >>> > >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
