sábado, noviembre 29, 2008

Consenting adults, consenting ducks

No le toques los colmillos al Conde DuckulaHace 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:
  1. 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.
  2. 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...

Etiquetas: ,

15 Comments:

Blogger Alfredo Novoa said...

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.

miércoles, diciembre 03, 2008 4:05:00 p. m.  
Blogger Alfredo Novoa said...

Por cierto. ¿Que opinas de lo que dicen algunos de que C# ya tiene "duck typing" desde el principio con la instrucción foreach.

miércoles, diciembre 03, 2008 6:09:00 p. m.  
Blogger Ian Marteens said...

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.

miércoles, diciembre 03, 2008 11:14:00 p. m.  
Blogger Alfredo Novoa said...

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.

jueves, diciembre 04, 2008 12:10:00 a. m.  
Blogger PabloNetrix said...

"... 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...

jueves, diciembre 04, 2008 9:46:00 p. m.  
Blogger Andrés Ortíz said...

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.

sábado, diciembre 06, 2008 10:35:00 p. m.  
Blogger Alfredo Novoa said...

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.

domingo, diciembre 07, 2008 1:02:00 p. m.  
Blogger Pablo Grisafi said...

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...

domingo, diciembre 07, 2008 3:27:00 p. m.  
Blogger Ramon Garcia Perez said...

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.

lunes, diciembre 08, 2008 2:42:00 p. m.  
Blogger Ian Marteens said...

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.

miércoles, diciembre 10, 2008 9:21:00 a. m.  
Blogger Ian Marteens said...

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.

miércoles, diciembre 10, 2008 10:11:00 a. m.  
Blogger Alfredo Novoa said...

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.

miércoles, diciembre 10, 2008 10:48:00 a. m.  
Blogger Alfredo Novoa said...

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.

miércoles, diciembre 10, 2008 11:15:00 a. m.  
Blogger Alfredo Novoa said...

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'

martes, diciembre 16, 2008 4:14:00 p. m.  
Blogger Ian Marteens said...

:) ¡Ostras, qué bueno!

martes, diciembre 16, 2008 6:29:00 p. m.  

Publicar un comentario

<< Home