> > On 13 nov, 05:33, Hernan Wilkinson <[email protected]> wrote: > > 2009/11/12 [email protected] <[email protected]> > > > > > > > > > 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. > > > > yo creo que no... :-) > Aclaro un poquito, dije algo un poco fuerte y me arrepiento :-), pero > te pongo un ejemplo en donde veo cierta ingenuidad o hipocresía > smalltalkera al diseñar: Suponete que creas una clase Person con un iv > #phones, como es Smalltalk #phones no lleva tipo y hasta presupones > que podría ser un String, una Collection o un objeto muy complejo que > se conecte a 44 empresas de telefonía. Total como es Smalltalk no debo > especificar tipo. Pero a los 10 minutos estás dibujando un textBox en > una view para meter eso, y luego tal vez lo guardas en un varchar de > una base de datos y en otro momento lo mandás a un reporte o html. En > todos estos usos de #phones, que usan gran parte del protocolo de > String, estás diciendo implícitamente que #phones es un String, lo vas > diciendo de a poco y desordenadamente. Además luego de un tiempo te > das cuenta que estaba bien que haya sido un String y que es poco > rentable sofisticar a #phones, porque no es tan importante en el > sistema y no querés invertir tiempo en hacer el megaobjeto > superpolimórfico para algo tan poco relevante. Entonces pienso que si > se hubiese aclarado en algún momento, de alguna manera blanda (no digo > tipar estaticamente ni nada tan drástico) entonces ni siquiera se > hubiese tenido que dibujar el textBox porque se podría haber dibujado > solo, el campo varchar de la tabla se hubiese generado solo y todas > las demas interacciones hubiesen sido menos costosas. > Yendo un poco mas lejos, creo que en Smalltalk hay una característica > que suele quedar desapercibida y genera problemas de diseño. Y es el > hecho de que existe una distancia muy grande en términos de > abstracción entre una clase y un objeto. Esto es bueno creo, pero > conviene tenerlo muy presente porque es necesario llenar ese gap > ordenadamente. Por ejemplo en Java/C++/.NET/etc. las clases son mas > concretas porque son tipadas, porque hay cosas privadas, publicas, > protegidas, amigas y quien sabe cuanto invento mas. Son mas concretas > porque dicen mas acerca de sus instancias, lamentablemente. Por el > contrario en Smalltalk los objetos son mas concretos, no se me ocurre > nada mas concreto que evaluar 3+4. Entonces lo que creo es que esa > distancia es necesaria considerarla al momento de hacer cosas como > interfaces con otros sistemas, GUIs, persitencia o distribución. > Ejemplo: hacer un generador de tablas para persistencia relacional en > Java es mas simple porque ya se qué tipo de datos ponerle a los > campos. Hay muchos ejemplos mas en esta línea. >
Me perdi con que las clases son mas concretas en java que en smalltalk, o que en smalltalk los objetos son mas concretos... no se a que te referis, creo que tenemos raices muy distintas sobre el significado de estas cosas > > 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. > > > > No es tan así, depende de que cambios hagas, cuanto impacte, etc. > > De última, es mejor arreglar test que arreglar errores en producción no? > Supongo que coincidimos que para estar bien en producción es necesario > lograr estabilidad. Creo que esa estabilidad se logra antes y con > menos esfuerzo si no tengo a los tests como lastre, si puedo alterar > mucho y muy seguido al sistema con un bajo costo. > Si tenes tests como lastre, no estás haciendo bien tdd. > > > No entiendo por qué la gente se preocupa tanto por tener que manterner > > tests. Si están bien hechos, no cuesta y la seguridad que te dan paga > varias > > veces lo que te lleva hacerlo y mantenerlo. > Hace algunos años, con gente de esta lista :-), hicimos una clase > FixedDecimal para instanciar números que respresenten dinero. En estos > casos creo que si es aconsejable meterle tests, como en todo caso en > donde la especificación es muy clara. Agregamos todos los que > encontramos (creo que eran los ANSI) y se nos ocurrieron, daba todo > verde y todos "demasiados" tranquilos. Hace poco encontré un error > aritmético en dicha clase que puede que haya producido diferencias > monetarias en TODOS los sistemas que hice hasta ahora. Semejante > cagadón que nos mandamos hubiese sido mas evidente sin los tests, > porque me hubiese asignado mas tiempo a revisar esa clase en lugar de > escribir tests. Porque la incertidumbre hubiese jugado a favor de > factorizar y emprolijar todo lo posible una clase tan crítica. > o por ahí hubiese sido mejor hacer mejores tests... de vuelta, un test solo asegura que lo que testeas funciona, si no testeaste algo no te dice nada. Igual, no te olvides que tdd dice justamete "refactorizar y mejorar el modelo" por lo tanto esa revisión que comentas la hubiese hecho si haces tdd correctamente > > Mi experiencia, en un sistema donde hicimos 17000 tests, nunca tuvimos un > > problema grave de parar un release por modificar test, de última > asumiamos > > el riesgo de salir con esos test fallando para ir arreglandolos de a poco > Lo que habría que evaluar no es cuantos problemas tiene dicho sistema, > sino cuánto cambió realmente y a qué costo. > uh! cuanto cambio? muchisimo! tiene cerca de 10000 clases, hace unos años creo que 800 mil lineas de codigo y se le esta agregando funcionalidad constantemente, por ejemplo en el congreso van a mostrar toda la parte de curvas y riesgo.. o sea, cambiar, cambio muchisimo y lo sigue haciendo. > > > > > 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. > > > > por qué? de vuelta, habiendo hecho tdd seriamente, es así. A ver, de una > > manera u otra tenes que testear cualquier cambio que hagas, o lo haces > con > > test automatizados, o lo haces a mano o lo hace el usuario en > producción... > Cuando el sistema adquiere un nivel de estabilidad y las entidades mas > importantes un grado de abstracción importante, entonces los sistemas > tienden a tener dos tipos de errores: inofensivos o cuelgues totales. > Ambos tipos de errores no suelen ser nocivos en producción y en ese > punto te diría qeu si, que se haga en producción. > un cuelge total en producción? guau.. bueno, pensamos muy distinto... no se si tiene sentido conversar sobre esto con ideas bàsicas tan distintas. > > > > > 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, > > > > entonces no estás haciendo tdd en serio... y ese gerente o jefe que no te > > deja hacer refactorizacion si tenés tests, menos te va a dejar si no > tenés > > tests! va a decir "don't fix it if it aint break"! o sea, un cagón > total.... > > entonces esto no es un problema de tdd sino de ese tipo > No es solo lo que te diga tu jefe, es un tema económico, es mas caro > factorizar con tests. > > de vuelta, no estás poniendo todo en la ecuación. como estàs seguro que es más caro factorizar con tests? estàs teniendo en cuenta los errores que surgen por hacer cambios que te evitar con tdd y no te evitas por no hacerlo? Yo creo que estamos opinando en base a experiencias y mi experiencia con tdd es buena. Seguramente la tuya es mala y seguis diciendo que cambiar el modelo con tdd cuesta, bueno, mi respuesta a eso es que seguramente los tests no eran buenos o la tecnologìa que usaste no era buena, por que de vuelta, eso a mi no me paso > > > > > > > > > > > > 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. > > > > pero los test son workspaces que quedan en el tiempo... nunca perdés lo > que > > hiciste y podés hacer regresión. A un workspace una vez que terminaste > con > > tus pruebas (o sea, tests) lo perdiste... o sea, tdd te sirve para hacer > > programación exploratoria tanto como un workspace y es mejor porque queda > > todo lo que explorarte para asegurarte en cada cambio que hagas... > > > > > 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. > > > > De vuelta, no estoy de acuerdo. Los tests son primero casos concretos que > te > > permiten aprender (como lo que haces en el workspace) y luego son test. > El > > nombre TDD es misleading porque parece que lo principal es el test, pero > la > > verdad es que no, la verdad es que lo más importante es que haces > desarrollo > > exploratorio, iterativo, incremental y además, te asegurar de que > funcione > > bien y la computadora te ayuda en cada cambio que hagas de avisarte si > > cometiste algún error. > Coincido en algunas cosas que decis, pero creo que los tests deben > usarse solo en aquellas partes en donde la definición está muy clara > de entrada. claro que no! tenes que hacer tdd cuando no tenes ni idea sobre lo que estás modelando! justamente es una de las mayores ventajas! > Por ejemplo si vas a implementar TCP, te bajás el rfc y > escribís ese documento en forma de tests. Pero si te ponés a escribis > tests sobre cómo manejar el buffer o cualquier otra cosas que no hace > a la especificación concreta, entonces creo que estás limitando la > capacidad de laburo que te da Smalltalk. > De vuelta no coincido, cuando hago tdd es cuando uso smalltalk a full, cambio cosas en el debugger, levanto inspectores, modifico objetos, etc. Saludos, Hernan. > > > saludos, > > Hernan. > > Saludos, y aprovecho para agradecerte a vos y a los demás que hacen > Smalltalks2009. No podré asistir pero me alegra que haya gente que > ponga tanto esfuerzo en algo que cada año mejora su calidad. > > > > > > > > > > > > > > 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 > > > > ... > > > > leer más »- 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 -~----------~----~----~----~------~----~------~--~---
