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... :-) > 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. 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... 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. > 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? 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. 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 > 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... > 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 > 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. saludos, Hernan. > > 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 -~----------~----~----~----~------~----~------~--~---
