Consenting adults, consenting ducks
Hace poco, escribía en los comentarios de otra entrada que esto la Informática no es una ciencia, sino una ingeniería... y Alfredo Novoa respondía que ni siquiera eso. La siguiente anécdota demuestra cuán cierta es, desgraciadamente, esta afirmación.
La historia viene a cuento de una característica "novedosa" llamada duck typing. Según sus defensores, si una clase tiene métodos Add, Remove e Insert, y un indexador, ¿qué hay de malo en asignar una instancia de la clase a una variable de tipo ICollection? Eso es, en pocas palabras, el duck typing: si algo camina como un pato, nada como un pato, vuela como un pato (es decir, las tres cosas las hace mal) y además caga como un pato (es decir, constantemente), entonces, según los adeptos del mecanismo, tiene que ser un pato. Naturalmente, yo digo que puede ser una oca, o un pato robot, o el conde Duckula. No es buena idea tratar al señor conde como a un vulgar pato. Y así lo hice ver aquí, aunque de pasada:
Algún tiempo más tarde, alguien se quejó en un comentario... y como no suelo llevar cuenta de los comentarios tras cierto tiempo, no me percaté del hecho hasta hace un par de días. Esta es el comentario:
Cuál es el problema que le ves al "duck typing". Los que lo utilizan, suponen que los programadores son "consenting adults".
Consenting adults, eh...
En principio, eso serviría también para justificar las conversiones de tipos bestiales que son el pan de cada día en C++. Al fin y al cabo, si yo sé que un puntero se representa como un entero de 32 bits en mi plataforma, ¿por qué no voy a poder incrementar ese entero en cuatro para acceder al siguiente elemento de un vector? Consenting adults. No estamos locos. Sabemos lo que queremos...
Ahora bien, ¿es tan peligroso el duck typing como las conversiones bestiales? Veo dos problemas principales:
- Una pila no es simplemente un objeto que tiene dos métodos Push y Pop. Esos dos métodos, además, tienen que satisfacer determinado contrato. En la práctica, si el pato es mío, es un descuido mío el que no haya hecho que la clase correspondiente implemente la interfaz deseada. Si el pato es ajeno, es muy peligroso asumir que puedo tratar a un águila como a un pato simplemente porque ambos tienen pico.
- Si el pato es ajeno, además, los problemas con el versionado de clases pueden ser peliagudos. O "plumiagudos", si lo prefiere...
En cualquier caso, me hace gracia el uso de la teoría de los consenting adults. Hace poco, en Alemania, un buen señor pidió a otro consenting adult que le cortase la picha y se la comiese (en ese orden). El otro, efectivamente, cumplió con lo pactado. Luego mató a la víctima, como ésta había solicitado, se comió un muslo, y puso el otro a secarse para hacer jamón. Al caníbal lo pillaron, y lo llevaron a juicio. E inmediatamente, se armó el correspondiente revuelo: ¿por qué condenarlo? ¿No se limitó a hacer lo que el otro pirado le pedía? ¿No eran una parejita de consenting adults?
Evidentemente, tengo mi propia opinión al respecto. Yo, al canibalizado, si lo pillase antes de ser devorado, no le haría nada. Al fin y al cabo, si quiere que otro lo mate y se lo zampe, es su problema. Es, en efecto, un consenting adult: se supone que sabe lo que hace. Mi problema es con el caníbal: es un pirado, y tengo serias sospechas de que intentará repetir la acción. La próxima vez, no estoy seguro de que vaya a encontrar un consenting adult para satisfacer sus antojos culinarios. Es un individuo peligroso. No sé si eso bastará (junto con lo que ya ha hecho) para enviarlo a la cárcel, pero en mi barrio no lo quiero.
Lo mismo se aplica a los duck typers. ¿De manera que usted es aficionado a transformar el agua en vino, perros en patos y patos en borricos? Ah, claro, usted sabe lo que hace. Pero lo que usted hace es peligroso. No me gustaría verle enredando con mis proyectos...
15 Comments:
la Informática no es una ciencia
Pero hay dos formas muy diferentes de afrontar esto:
1) Como no es una ciencia vamos a portarnos todos como curanderos y alquimistas y echar cosas a lo loco en un caldero, revolver y ver que pasa.
2) Intentemos que sea lo más parecido a una ciencia que sea posible.
Por desgracia la mayoría opta por la primera opción.
Lo primero que hay que hacer para analizar estas cosas es traducirlas a términos formales. La antropomorfización (aunque en este caso es animalización :) es un vicio muy anglosajón y poca gente se da cuenta de lo dañina que es.
Dijstra escribió unas cuantas veces sobre esto:
Dijkstra on analogies and anthropomorphism
El "duck typing" simplemente consiste en omitir las comprobaciones de tipos en las invocaciones a operadores. Si hay algo mal ya cascará el operador por dentro. Los riesgos de esto son evidentes: errores en tiempo de compilación que antes se detectaban ahora ya no se detectan. Sobre las ventajas he buscado y no he encontrado nada.
Por cierto. ¿Que opinas de lo que dicen algunos de que C# ya tiene "duck typing" desde el principio con la instrucción foreach.
Intentemos que sea lo más parecido a una ciencia que sea posible
Ya. Lo que pasa es que uno se da cuenta de que la mitad de las explicaciones que circulan por ahí sobre por qué funcionan o no determinadas técnicas son puro vudú. A falta de un buen modelo y de métricas apropiadas, por ejemplo, es bastante artístico adivinar qué característica de un lenguaje es buena, mala o indiferente (excepto en casos extremos, que casi siempre son muy claros).
de que C# ya tiene "duck typing"
En mi opinión, es cierto. No sólo con el foreach: también pasa ahora con el inicializador de colecciones. La verdad es que, con el foreach, la idea tenía cierta lógica en la v1.1, porque te permitía evitar el boxing de la propiedad Current del IEnumerator. Ahora, ya no tiene sentido.
Lo que pasa es que uno se da cuenta de que la mitad de las explicaciones que circulan por ahí sobre por qué funcionan o no determinadas técnicas son puro vudú.
Eso pasa cuando lees a la gente que rechaza el enfoque científico.
La mayor parte del problema no está en la informática sino en el grado de preparación y la actitud de la mayoría de los informáticos (y no me refiero a si tienen masters o no).
A falta de un buen modelo y de métricas apropiadas, por ejemplo, es bastante artístico adivinar qué característica de un lenguaje es buena, mala o indiferente
Si que existen principios objetivos para el diseño de lenguajes de programación y en muchos casos sí que se pueden usar para determinar si una característica de un lenguaje es buena o mala. Lo que pasa es que esto difícilmente lo vas a encontrar en la "prensa de mercado".
Los lenguajes de programación si que son una parte de la informática que podemos acercar bastante a las matemáticas.
"... pidió a otro consenting adult que le cortase la picha y se la comiese (en ese orden)."
x'DDDDDDDDDD
La matización aquí era más que nunca necesaria...
Hola señores
Saliendome de este tema, quería preguntarles por alguna técnica "formal" de estimar proyectos de software. Esto se me ha vuelto un problema en la compañía pero nadie hace nada por tratar de formalizar un poco este tema. Algún libro recomendado, teniendo en cuenta que son proyectos .NET.
Pues puestos a pedir a mi me gustaría saber que opinais sobre si utilizar WPF (Windows Blurry Foundation) para desarrollar software de gestión o seguir con WinForms.
Al final, el duck tipyin es a .Net lo que la sobrecarga de operadores es a Java: existe en el lenguaje en si, pero no puede usarse por los programadores...
Hola Ian soy un fiel lector de todos tus escritos blogs, articulos, koans, tu libro de C# (muchas gracias ha sido de mucha ayuda)
Quisiera saber que les parece el EntLib y tambien el Dependency Injection (DI). No se si se sale del tema pero no se donde ponerlo que lo puedan ver ustedes que son los que mas saben de este asunto, me maravillo cada vez que leo algo en lo que Ian participa wao simplemente increhible) aqui en mi pais Republica Dominicana tipos como tu y Alfredo son conocidos como verdugos o monstruos que quiere decir alguien que se las sabe todas en una determinada atividad ;)
Gracias espero no causar problemas con mi comentario.
El "dependency injection" es una una buena idea, con un área de utilidad muy limitada, pero real. Intentar sacarla de ese contexto es el tipo de idea que se le ocurriría a un programador de Java con demasiado tiempo libre... o a Martin Fowler. MF lleva tiempo intentando inventarse la próxima "revolución", pero siempre falla por unos milímetros. Es un tipo capaz de explayarse sobre el problema del "dominio raquítico", sin llegar a la lógica conclusión de que los ORMs son una mala idea. Además, tuvo el mal gusto de escribir un libro sobre UML.
sobre si utilizar WPF (Windows Blurry Foundation)
Yo sigo con Windows Forms, de momento. A lo mejor WPF es buenísimo (aunque no veo la rejilla de datos por ninguna parte, y para utilizar una de terceros...), pero con sólo ver el tiempo que se tira VS2008 en refrescar un formulario, ya te echa para atrás.
Lo simpático del caso es que Cider, el componente de diseño, es precisamente en lo que estuvieron trabajando los refugiados de la destrucción del planeta Krypton... quiero decir, de Borland.
Yo sigo con Windows Forms, de momento.
Yo también.
A lo mejor WPF es buenísimo
A pesar del "pequeño" fallo que hace que sea imposible mostrar un texto nítido.
Eso es lo que definitivamente ha hecho que no lo considere en serio.
Eso y que tardo mucho más en crear un formulario.
(aunque no veo la rejilla de datos por ninguna parte, y para utilizar una de terceros...)
Ya, aunque la de WinForms también es mala de narices.
El "dependency injection" es una una buena idea, con un área de utilidad muy limitada, pero real. Intentar sacarla de ese contexto es el tipo de idea que se le ocurriría a un programador de Java con demasiado tiempo libre... o a Martin Fowler.
El problema es el de siempre. El típico javalí o emeuvepé piensa que un SGBD es fundamentalmente lo mismo que un archivo de texto, así que necesita de todos sus recursos de programación para reinventar la rueda de las bases de datos.
Aquí hay un ejemplo bastante bueno de como utilizar mal lo de las Dependency Injection:
Haciendo el tonto con Dependency Injection
Es increible lo que pueden llegar a hacer algunos para no escribir:
select * from Peliculas where Director='Roberto Benigni'
:) ¡Ostras, qué bueno!
Publicar un comentario
<< Home