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.
> > 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.
>
> Los test "usan" el sistema, pero el sistema ni se entera de los test.
Ningún objeto de Smalltalk se entera de quien lo usa hasta que recibe
un mensaje.
El
> acoplamiento va de los test al sistema (creo que es lo que decis) de la
> misma manera que existe el acoplamiento del "usuario" hacia el sistema...
Un usuario es una entidad muchisimo mas adaptativa que una batería de
tests el grado de acoplamiento es ínfimo comparado con un test.
no
> estás haciendo más que simular un usuario con los tests si querés verlo así,
> por lo tanto a mi me parece buenísimo.
Los tests expresan lo que el programador cree que hará o debe hacer un
usuario, es muy distintinto.
> > 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.
> 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.
> 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.
> > 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.
> > 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.
>
>
>
>
> > 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. 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.
> 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
-~----------~----~----~----~------~----~------~--~---
