...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.
> ...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.
> ...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.
En realidad, todos los lenguajes tienen un paraiso asi. Quiza el tema
es que con Smalltalk es mas facil hacer cosas lindas, asi que el
contraste entre lo bueno y lo no tan bueno es mas evidente.
On Wed, Nov 11, 2009 at 10:47 AM, Rusty <oku...@gmail.com> wrote:
> 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 <fxgall...@gmail.com> wrote:
>> Se desato una discusion en el blog de cincom y rescato un comentario
>> que quiero compartir:
>> ...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.
en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que en
java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas podés
hacer?
On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
> 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 <fxgall...@gmail.com> wrote:
> > Se desato una discusion en el blog de cincom y rescato un comentario
> > que quiero compartir:
> > ...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.
No entendés nada Hernán! Lo que pasa es que como en Smalltalk no tenés
chequeo de tipos podés hacer cualquier cosa!
Obviamente no cuenta el hecho de que en c/c++ tenés que manejar la memoria a
mano y con casteos podés hacer siempre cualquier cagada. Esos son sólo
detalles... :D
Abrazo!
Mariano.
On Wed, Nov 11, 2009 at 5:56 PM, Hernan Wilkinson <
hernan.wilkin...@gmail.com> wrote:
> en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que en
> java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas podés
> hacer?
> On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
>> 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 <fxgall...@gmail.com> wrote:
>> > Se desato una discusion en el blog de cincom y rescato un comentario
>> > que quiero compartir:
>> > ...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.
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"
> ...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
En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
del código.
Un ejemplo conciso es el tipado.
Si en un lenguaje tipado definís un parámetro como int, vos después
podés hacer todos los chanchuyos que quieras.
Pero sabés que ahí va a caer un entero.
En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
true, false o unCocodrilo.
Imaginate programar un sistema con bronca. Quién lo programa piensa:
Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
rápida, mas sucia y mas directa posible.
En otros lenguajes por lo menos esa persona tiene que regirse por
reglas.
En Smalltalk el límite es el infierno.
Tal vez es un poco lo que comenta Andrés.
En Smalltalk hay cosas que no puedo ver.
Cuando veo nudos en otros lenguajes bueno ... realmente no me
horroriza, al fin y al cabo es C ! :P
On 11 nov, 17:56, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que en
> java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas podés
> hacer?
> On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
> > 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 <fxgall...@gmail.com> wrote:
> > > Se desato una discusion en el blog de cincom y rescato un comentario
> > > que quiero compartir:
> > > ...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.
El costo de esas reglas es que el costo de cambiar un programa bien
escrito en (por ejemplo) C tiende a ser muchisimo mas grande que el
costo de cambiar un programa bien escrito en Smalltalk. Quiza en
aplicaciones comparativamente poco complejas como websites que duran
pocos años antes de re-escribirse de cero no se nota. De hecho, si la
re-escritura se considera efectiva, entonces el software no tenia
tanto contenido intelectual como para que fuera mas valioso
preservarlo. Pero, apenas uno tiene problemas comparativamente mas
complejos, entonces no se puede andar re-escribiendo todo de cero
porque el costo es carisimo. Ahi es donde las ventajas de Smalltalk
brillan, porque en esos casos es mucho mejor (dado un programa
relativamente bien escrito) bajar el costo del cambio para no tener
que terminar con una re-escritura.
Lo que es medio triste es que aun hoy parece que inventamos lenguajes
desde cero todos los años para resolver problemas comparativamente
simples. El tema de fondo es que, la mayoria de las veces, no
escribimos software comparativamente sofisticado. O sea, si Rails
sirve para describir una seccion grande del software que se escribe,
bueno... eso es todo lo que vamos a hacer con nuestros enesimos
centros de computo cuyo consumo electrico se mide en mega watts por
hora? ABM en un browser? Ahi es donde miro el video de la demo de
Doug Engelbart y lo que siento es un cachetazo: desde 1968 hasta aca,
pareciera que no hicimos un pomo.
Entonces... si medimos nuestra capacidad con una vara como Rails,
entonces a la gente que cumple esas metas comparativamente poco
exigentes les puede parecer que Smalltalk no sirve para nada. Pero,
aunque parezca mentira, no todo en el mundo es hacer paginas web.
On Wed, Nov 11, 2009 at 2:40 PM, Rusty <oku...@gmail.com> wrote:
> En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
> del código.
> Un ejemplo conciso es el tipado.
> Si en un lenguaje tipado definís un parámetro como int, vos después
> podés hacer todos los chanchuyos que quieras.
> Pero sabés que ahí va a caer un entero.
> En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
> true, false o unCocodrilo.
> Imaginate programar un sistema con bronca. Quién lo programa piensa:
> Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
> rápida, mas sucia y mas directa posible.
> En otros lenguajes por lo menos esa persona tiene que regirse por
> reglas.
> En Smalltalk el límite es el infierno.
> Tal vez es un poco lo que comenta Andrés.
> En Smalltalk hay cosas que no puedo ver.
> Cuando veo nudos en otros lenguajes bueno ... realmente no me
> horroriza, al fin y al cabo es C ! :P
> On 11 nov, 17:56, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
>> en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que en
>> java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas podés
>> hacer?
>> On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
>> > 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 <fxgall...@gmail.com> wrote:
>> > > Se desato una discusion en el blog de cincom y rescato un comentario
>> > > que quiero compartir:
>> > > ...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.
Que tal Rusty,
sinceramente no concuerdo para nada con lo que estás diciendo. Por un lado
estás confundiendo qué tan fuerte es el chequeo de tipos con cuándo se hace
el chequeo de tipos.
Smalltalk hace chequeo de tipos fuerte y lo hace dinámicamente. Esto
significa que si en una variable donde estas esperando un entero pones un
boolean, no te avisa en el momento de la asignación de la variable pero te
avisa en el momento de mandarle un mensaje al objeto y no hay manera de
hacerle creer a nadie que un boolean puede ser un entero.
C tiene chequeo de tipos débil pero estático. Idem C++. Esto significa que
si en una variable donde estas esperando un entero pones un boolean, el
COMPILADOR te avisa del supuesto error, por eso se denomina estático. Pero
es débil porque con un simple casteo podes bypasear ese chequeo y asignale
el boolean a la variable para que luego todo se vaya a la mierda sin saber
porque.
Java tiene chequeo fuerte y estático, al igual que C#, pero como no es
posible realizar todos los chequeos de manera estática existen excepciones
como NullPointerException que solo se producen en tiempo de ejecución, o
sea, de manera dinámica finalmente...
Por lo tanto, lo que no hay duda es que el chequeo de tipos debe ser fuerte
y eso es justamente lo que hace Smalltalk.
Si pueden haber discusiones de si es mejor hacerlo de manera estática o
dinámica, pero si te gusta la estática tené en claro que no existe chequeo
de tipos estático que te de "seguridad" completa (en realidad falsa
seguridad) porque hay verificaciones que se deben hacer dinámicamente, ni
siquiera Eiffle que le rompe el c... al java y c# en chequeo de tipos puede
asegurar que todos los errores se encuentren en tiempo de compilación.
Que el chequeo de tipos sea dinámico no significa que podes hacer cualquier
cosa! lo que importa es si es fuerte o débil! podes hacer cualquier cosa con
chequeo de tipo débil como en c/c++
Y si sentís que con chequeo de tipo dinámico podes hacer cualquier cosa, es
porque nunca hiciste un sistema en serio con un lenguaje con chequeo fuerte
y dinamico de tipos como Smalltalk o lo hiciste mal, sin probar lo que
hiciste.
Perdoná que sea tan duro en mis observaciones, pero estoy cansado de ver
estos comentarios generados por errores conceptuales.
On Wed, Nov 11, 2009 at 7:40 PM, Rusty <oku...@gmail.com> wrote:
> En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
> del código.
> Un ejemplo conciso es el tipado.
> Si en un lenguaje tipado definís un parámetro como int, vos después
> podés hacer todos los chanchuyos que quieras.
> Pero sabés que ahí va a caer un entero.
> En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
> true, false o unCocodrilo.
> Imaginate programar un sistema con bronca. Quién lo programa piensa:
> Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
> rápida, mas sucia y mas directa posible.
> En otros lenguajes por lo menos esa persona tiene que regirse por
> reglas.
> En Smalltalk el límite es el infierno.
> Tal vez es un poco lo que comenta Andrés.
> En Smalltalk hay cosas que no puedo ver.
> Cuando veo nudos en otros lenguajes bueno ... realmente no me
> horroriza, al fin y al cabo es C ! :P
> On 11 nov, 17:56, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> > en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que
> en
> > java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas
> podés
> > hacer?
> > On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
> > > 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 <fxgall...@gmail.com> wrote:
> > > > Se desato una discusion en el blog de cincom y rescato un comentario
> > > > que quiero compartir:
> > > > ...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.
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.
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 <
> 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: clubsmalltalk@googlegroups.com [mailto:
> clubsmalltalk@googlegroups.com]
> 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 <fxgall...@gmail.com> wrote:
> > Se desato una discusion en el blog de cincom y rescato un comentario
> > que quiero compartir:
> > ...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
> 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 <
> smallt...@adinet.com.uy> 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: clubsmalltalk@googlegroups.com [mailto:
>> clubsmalltalk@googlegroups.com]
>> 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 <fxgall...@gmail.com> wrote:
>> > Se desato una discusion en el blog de cincom y rescato un comentario
>> > que quiero compartir:
>> > ...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
Estamos de acuerdo, las ventajas que presenta Smalltalk frente a otras
metodologias de construcción son impresionantes, pero explicaselo a un
programador C# o Java o Whatever ... :-P
2009/11/12 Mariano Abel Coca <marianoabelc...@gmail.com>
> 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 <
>> smallt...@adinet.com.uy> 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: clubsmalltalk@googlegroups.com [mailto:
>>> clubsmalltalk@googlegroups.com]
>>> 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 <fxgall...@gmail.com> wrote:
>>> > Se desato una discusion en el blog de cincom y rescato un comentario
>>> > que quiero compartir:
>>> > ...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
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 <marianoabelc...@gmail.com> wrote:
> > 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 <
> > smallt...@adinet.com.uy> 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: clubsmalltalk@googlegroups.com [mailto:
> >> clubsmalltalk@googlegroups.com]
> >> 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 <fxgall...@gmail.com> wrote:
> >> > Se desato una discusion en el blog de cincom y rescato un comentario
> >> > que quiero compartir:
> >> > ...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 -
> 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 <marianoabelc...@gmail.com> wrote:
> > Simplemente para aportar un detalle más.
> > > 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 <
> > > smallt...@adinet.com.uy> 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"
> > >> 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 <fxgall...@gmail.com> wrote:
> > >> > Se desato una discusion en el blog de cincom y rescato un comentario
> > >> > que quiero compartir:
> > >> > ...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 -
Hola Hernan.
No veo donde lo que escribí contradiga lo que dijiste vos, pero vamos
que lo del tipado fué sólo un ejemplo para ilustrar mi punto de vista
(y tema principal del thread) que es que la misma libertad que ofrece
Smalltalk puede usarse para 'bien' y para 'mal'.
De todas formas gracias por la clase gratuita sobre el tema, me quedó
claro que leíste bastante sobre él.
Y si por el sentimiento de una persona inferís el nivel de seriedad o
correctitud de sus sistemas no estás siendo duro, estás siendo
adivino.
Para esoterismo smalltalker hay otra lista. Creo que todavía existe,
no estoy seguro que haya mucha gente :D
Salutti.
Rusty.
On 12 nov, 08:23, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> Que tal Rusty,
> sinceramente no concuerdo para nada con lo que estás diciendo. Por un lado
> estás confundiendo qué tan fuerte es el chequeo de tipos con cuándo se hace
> el chequeo de tipos.
> Smalltalk hace chequeo de tipos fuerte y lo hace dinámicamente. Esto
> significa que si en una variable donde estas esperando un entero pones un
> boolean, no te avisa en el momento de la asignación de la variable pero te
> avisa en el momento de mandarle un mensaje al objeto y no hay manera de
> hacerle creer a nadie que un boolean puede ser un entero.
> C tiene chequeo de tipos débil pero estático. Idem C++. Esto significa que
> si en una variable donde estas esperando un entero pones un boolean, el
> COMPILADOR te avisa del supuesto error, por eso se denomina estático. Pero
> es débil porque con un simple casteo podes bypasear ese chequeo y asignale
> el boolean a la variable para que luego todo se vaya a la mierda sin saber
> porque.
> Java tiene chequeo fuerte y estático, al igual que C#, pero como no es
> posible realizar todos los chequeos de manera estática existen excepciones
> como NullPointerException que solo se producen en tiempo de ejecución, o
> sea, de manera dinámica finalmente...
> Por lo tanto, lo que no hay duda es que el chequeo de tipos debe ser fuerte
> y eso es justamente lo que hace Smalltalk.
> Si pueden haber discusiones de si es mejor hacerlo de manera estática o
> dinámica, pero si te gusta la estática tené en claro que no existe chequeo
> de tipos estático que te de "seguridad" completa (en realidad falsa
> seguridad) porque hay verificaciones que se deben hacer dinámicamente, ni
> siquiera Eiffle que le rompe el c... al java y c# en chequeo de tipos puede
> asegurar que todos los errores se encuentren en tiempo de compilación.
> Que el chequeo de tipos sea dinámico no significa que podes hacer cualquier
> cosa! lo que importa es si es fuerte o débil! podes hacer cualquier cosa con
> chequeo de tipo débil como en c/c++
> Y si sentís que con chequeo de tipo dinámico podes hacer cualquier cosa, es
> porque nunca hiciste un sistema en serio con un lenguaje con chequeo fuerte
> y dinamico de tipos como Smalltalk o lo hiciste mal, sin probar lo que
> hiciste.
> Perdoná que sea tan duro en mis observaciones, pero estoy cansado de ver
> estos comentarios generados por errores conceptuales.
> Saludos,
> Hernán.
> On Wed, Nov 11, 2009 at 7:40 PM, Rusty <oku...@gmail.com> wrote:
> > En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
> > del código.
> > Un ejemplo conciso es el tipado.
> > Si en un lenguaje tipado definís un parámetro como int, vos después
> > podés hacer todos los chanchuyos que quieras.
> > Pero sabés que ahí va a caer un entero.
> > En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
> > true, false o unCocodrilo.
> > Imaginate programar un sistema con bronca. Quién lo programa piensa:
> > Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
> > rápida, mas sucia y mas directa posible.
> > En otros lenguajes por lo menos esa persona tiene que regirse por
> > reglas.
> > En Smalltalk el límite es el infierno.
> > Tal vez es un poco lo que comenta Andrés.
> > En Smalltalk hay cosas que no puedo ver.
> > Cuando veo nudos en otros lenguajes bueno ... realmente no me
> > horroriza, al fin y al cabo es C ! :P
> > On 11 nov, 17:56, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> > > en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que
> > en
> > > java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas
> > podés
> > > hacer?
> > > On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
> > > > 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 <fxgall...@gmail.com> wrote:
> > > > > Se desato una discusion en el blog de cincom y rescato un comentario
> > > > > que quiero compartir:
> > > > > ...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.
> Hola Hernan.
> No veo donde lo que escribí contradiga lo que dijiste vos, pero vamos
> que lo del tipado fué sólo un ejemplo para ilustrar mi punto de vista
peor es un mal ejemplo y por lo tanto te hace inferir conclusiones erroneas
> (y tema principal del thread) que es que la misma libertad que ofrece
> Smalltalk puede usarse para 'bien' y para 'mal'.
como todo en la vida, y yo prefiero la libertad a no tenerla.
> De todas formas gracias por la clase gratuita sobre el tema, me quedó
> claro que leíste bastante sobre él.
de nada, un placer
> Y si por el sentimiento de una persona inferís el nivel de seriedad o
> correctitud de sus sistemas no estás siendo duro, estás siendo
> adivino.
no fue sentimiento, fue lo que escribiste. Por ejemplo pusiste "En Smalltalk
el límite es el infierno", pero peor es en c/c++, etc. O sea, no concuerdo
con tu conclusión y además sucede todo lo contrario.
Para esoterismo smalltalker hay otra lista. Creo que todavía existe,
> On 12 nov, 08:23, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> > Que tal Rusty,
> > sinceramente no concuerdo para nada con lo que estás diciendo. Por un
> lado
> > estás confundiendo qué tan fuerte es el chequeo de tipos con cuándo se
> hace
> > el chequeo de tipos.
> > Smalltalk hace chequeo de tipos fuerte y lo hace dinámicamente. Esto
> > significa que si en una variable donde estas esperando un entero pones un
> > boolean, no te avisa en el momento de la asignación de la variable pero
> te
> > avisa en el momento de mandarle un mensaje al objeto y no hay manera de
> > hacerle creer a nadie que un boolean puede ser un entero.
> > C tiene chequeo de tipos débil pero estático. Idem C++. Esto significa
> que
> > si en una variable donde estas esperando un entero pones un boolean, el
> > COMPILADOR te avisa del supuesto error, por eso se denomina estático.
> Pero
> > es débil porque con un simple casteo podes bypasear ese chequeo y
> asignale
> > el boolean a la variable para que luego todo se vaya a la mierda sin
> saber
> > porque.
> > Java tiene chequeo fuerte y estático, al igual que C#, pero como no es
> > posible realizar todos los chequeos de manera estática existen
> excepciones
> > como NullPointerException que solo se producen en tiempo de ejecución, o
> > sea, de manera dinámica finalmente...
> > Por lo tanto, lo que no hay duda es que el chequeo de tipos debe ser
> fuerte
> > y eso es justamente lo que hace Smalltalk.
> > Si pueden haber discusiones de si es mejor hacerlo de manera estática o
> > dinámica, pero si te gusta la estática tené en claro que no existe
> chequeo
> > de tipos estático que te de "seguridad" completa (en realidad falsa
> > seguridad) porque hay verificaciones que se deben hacer dinámicamente, ni
> > siquiera Eiffle que le rompe el c... al java y c# en chequeo de tipos
> puede
> > asegurar que todos los errores se encuentren en tiempo de compilación.
> > Que el chequeo de tipos sea dinámico no significa que podes hacer
> cualquier
> > cosa! lo que importa es si es fuerte o débil! podes hacer cualquier cosa
> con
> > chequeo de tipo débil como en c/c++
> > Y si sentís que con chequeo de tipo dinámico podes hacer cualquier cosa,
> es
> > porque nunca hiciste un sistema en serio con un lenguaje con chequeo
> fuerte
> > y dinamico de tipos como Smalltalk o lo hiciste mal, sin probar lo que
> > hiciste.
> > Perdoná que sea tan duro en mis observaciones, pero estoy cansado de ver
> > estos comentarios generados por errores conceptuales.
> > Saludos,
> > Hernán.
> > On Wed, Nov 11, 2009 at 7:40 PM, Rusty <oku...@gmail.com> wrote:
> > > En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
> > > del código.
> > > Un ejemplo conciso es el tipado.
> > > Si en un lenguaje tipado definís un parámetro como int, vos después
> > > podés hacer todos los chanchuyos que quieras.
> > > Pero sabés que ahí va a caer un entero.
> > > En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
> > > true, false o unCocodrilo.
> > > Imaginate programar un sistema con bronca. Quién lo programa piensa:
> > > Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
> > > rápida, mas sucia y mas directa posible.
> > > En otros lenguajes por lo menos esa persona tiene que regirse por
> > > reglas.
> > > En Smalltalk el límite es el infierno.
> > > Tal vez es un poco lo que comenta Andrés.
> > > En Smalltalk hay cosas que no puedo ver.
> > > Cuando veo nudos en otros lenguajes bueno ... realmente no me
> > > horroriza, al fin y al cabo es C ! :P
> > > On 11 nov, 17:56, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> > > > en smalltalk podes hacer cosas más desprolijas que en c? que en c++?
> que
> > > en
> > > > java?? no me lo creo... no entiendo por qué, qué cosas más
> desprolijas
> > > podés
> > > > hacer?
> > > > On Wed, Nov 11, 2009 at 3:47 PM, Rusty <oku...@gmail.com> wrote:
> > > > > 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 <fxgall...@gmail.com> wrote:
> > > > > > Se desato una discusion en el blog de cincom y rescato un
> comentario
> > > > > > que quiero compartir:
> > > > > > ...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.
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 <gab...@gmail.com> wrote:
> > 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 <marianoabelc...@gmail.com> wrote:
> > > Simplemente para aportar un detalle más.
> > > > 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 <
> > > > smallt...@adinet.com.uy> 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"
> > > >> 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 <fxgall...@gmail.com> wrote:
> > > >> > Se desato una discusion en el blog de cincom y rescato un comentario
> > > >> > que quiero compartir:
> > > >> > ...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 -
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?
¿Cuando desarrollas el producto si es que tenes que escribir tantos tests?
Es decir, las respuestas seguramente sean simples, pero las ecuaciones
en tiempo y dinero no.
Para mi, y para mi trabajo actual, no es tan simple.
Saludos
GallegO
El día 12 de noviembre de 2009 18:58, dcorone...@gmail.com
<dcorone...@gmail.com> 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 <gab...@gmail.com> wrote:
>> Diego, me interesa tu punto de vista, por qué afirmas que es nociva la
>> seguridad que te dan los tests?
>> > 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 <marianoabelc...@gmail.com> wrote:
>> > > Simplemente para aportar un detalle más.
>> > > > 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 <
>> > > > smallt...@adinet.com.uy> 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"
>> > > >> 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 <fxgall...@gmail.com> wrote:
>> > > >> > Se desato una discusion en el blog de cincom y rescato un comentario
>> > > >> > que quiero compartir:
> 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.
> On 12 nov, 12:52, Gabriel Brunstein <gab...@gmail.com> wrote:
> > Diego, me interesa tu punto de vista, por qué afirmas que es nociva la
> > seguridad que te dan los tests?
> > > 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 <marianoabelc...@gmail.com> wrote:
> > > > Simplemente para aportar un detalle más.
> > > > > 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 <
> > > > > smallt...@adinet.com.uy> 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
> 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, dcorone...@gmail.com
> <dcorone...@gmail.com> 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 <gab...@gmail.com> wrote:
> >> Diego, me interesa tu punto de vista, por qué afirmas que es nociva la
> >> seguridad que te dan los tests?
> >> > 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 <marianoabelc...@gmail.com>
> wrote:
> >> > > Simplemente para aportar un detalle más.
> >> > > > 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 <
> >> > > > smallt...@adinet.com.uy> 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.
Conociendo ti experiencia en el sistema XTrade (creo que se llama así)
>> ¿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
Uds realizaron el desarrollo de ese sistema desde la primera linea de codigo con tests o existio un momento en el cual empezaron a realizarlos y no pararon más?.
Me gustaria saber tambien cual es el nivel de refactoring que suelen aplicarle a ese sistema, si es que es normal introducir cambios que modifiquen protocolos considerablemente, jerarquias, renombramiento de clases, en fin pequeñas o grandes bombas :)
Tienen testeada la GUI?
>> 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.
Bueno, pero eso depende de cuanto cambie el sistema y como este hecho. Yo puedo decir que si un sistema está bien hecho y basado en conceptos simples, por mas que no tenga tests te va a traer menos problemas que uno totalmente testeado, complicado y obeso.
Lo bueno de los tests supongo es asegurar la calidad o correctitud del sistema. En ningún momento nos asegura no tener problemas grosos. Bueno, igual creo que es lo que vos quisiste decir tambien.
> Conociendo ti experiencia en el sistema XTrade (creo que se llama así)
Que haces Gallego,
si, se llama así
> >> ¿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
> Uds realizaron el desarrollo de ese sistema desde la primera linea de
> codigo con tests o existio un momento en el cual empezaron a
> realizarlos y no pararon más?.
Tuvimos la suerte de emperzar un sistema desde cero y lo hicimos usando tdd
desde el principio, ese es el mejor caso que se puede dar.
Si ya tenes un sistema, empezar a hacar tdd es muy dificil puesto que el
sistema està seguramente muy acoplado y por lo tanto es muy difìcil
testearlo...
> Me gustaria saber tambien cual es el nivel de refactoring que suelen
> aplicarle a ese sistema, si es que es normal introducir cambios que
> modifiquen protocolos considerablemente, jerarquias, renombramiento de
> clases, en fin pequeñas o grandes bombas :)
uh! hicimos de todos, rompimos y volvimos a hacer muchas cosas, cambiamos
cosas chiquitas, etc. todo lo que se te ocurra, pero nunca dejamos de hacer
tdd porque justamente eso nos permitía hacer esos cambios! sino, no había
manera de que nos animemos...
> Tienen testeada la GUI?
En un momento empezmaos a hacer test automatizados de ui pero tuvimos que
dejarlo por unos problemas técnicos y luego falta de gente, pero cuando lo
tuvimos ayudó mucho y siempre quisimos volver a hacerlo
> >> 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.
> Bueno, pero eso depende de cuanto cambie el sistema y como este hecho.
> Yo puedo decir que si un sistema está bien hecho y basado en conceptos
> simples, por mas que no tenga tests te va a traer menos problemas que
> uno totalmente testeado, complicado y obeso.
si y no, todo depende no? porque también hay que pensar en como cambia el
sistema, quien lo cambia, que rotación de gente tenes, etc. y tener test te
ayuda a transmitir mejor la idea de como se hicieron las cosas, asegurarte
que no metan la pata, etc. que se yo, para mi siempre paga.
> Lo bueno de los tests supongo es asegurar la calidad o correctitud del
> sistema.
> En ningún momento nos asegura no tener problemas grosos.
> Bueno, igual creo que es lo que vos quisiste decir tambien.
a que te referis con problemas grosos?
Un test te asegura que lo que testeaste funciona, nada mas, pero tdd es más
que hacer test, es ayudarte a explorar el dominio, ha hacer desarrollo
exploratorio, interativo, incremental y a tener resultados ràpido..
> > 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.
>> Lo bueno de los tests supongo es asegurar la calidad o correctitud del >> sistema. >> En ningún momento nos asegura no tener problemas grosos. >> Bueno, igual creo que es lo que vos quisiste decir tambien.
> a que te referis con problemas grosos?
Para mi un problema groso es algo que ya no se puede cambiar* y que impacta en muchos lugares en el sistema. Entonces, todo puede tener test y anda fenomeno, pero es una gran caca. Claro, podes decirme que como tenes los tests, podes cambiar todo lo que está mal, y es cierto.
A lo que apunto, y es algo que se VENDE hoy por hoy en el ambiente de desarrollo, es que si un sistema esta totalmente testeado, es un sistema bueno. Como vos decís, Y HAY QUE LEER MUY BIEN, lo testeado funciona. Eso no quiere decir que el sistema funcione, ni que el sistema sea "bueno", si esto se puede medir de alguna forma, más que con la opinión de los clientes.
Y creo que ese es el punto donde por ahí algunos disentimos. Aún así todo esta relacionado en alguna u otra forma. Un sistema sin errores va a tener clientes satisfechos siempre y cuando sea económico y en tiempo.
Es algo pendiente para mi darle una oportunidad al TDD. Las veces que lo intenté quizás no puse el suficiente esfurzo y como Diego sentí que un workspace era más simple. Obviamente el debugger y todo eso se usa, solo que no me banco hacer tests (por ahora) antes que otra cosa. Se ve que me falta un ingrediente.
Saludos GallegO
PD. Seguro es tarde pero estaria bueno una demo tuya en Smalltalks, donde te proponemos un sistema en el momento y comenzas a modelarlo e implementarlo de 0 con TDD. Nosotros miramos nomas :) y vemos como hacés.
|
