EDICIóN GENERAL

El Poder Judicial estudia implementar robots que predigan sentencias

#93 mi función cubre los mismos casos que los cambios de estado que el propone.
No, no lo hace. Devuelve falso para casos no contemplados por el algoritmo original. Y ademas no hace diferenciacion de esos casos. En el mundo real esto es un bug de libro. Esto no es pedanteria, es simplemente constatacion de un hecho. Si quieres dartelas de listo, por mi bien, pero luego asegurate de que lo que dices tiene un minimo de coherencia. Si tu codigo es de este estilo mal vamos, y si tu sentido de humildad es ese, aun peor.


Madre mía, que nivel

En eso estamos de acuerdo. Con lo del goto, bueno en fin... Mejor mirate la ultima frase de tu comentario, es una gran verdad.
#94

No, no lo hace. Devuelve falso para casos no contemplados por el algoritmo original.


Claro, pero es que el algoritmo original devolvía false para esos casos, o bien fallaba.

Vamos a repasar el algoritmo original:

If acusado=hombre and delito=viogen then
Culpable=true
End if


Perfecto, como puedes observar, este trozo de código altera el estado de una variable, pero claro, como no hay mas código, suponemos que ese es el programa o módulo completo (que otra opción tenemos?).

Si te fijas, ese modulo no tiene sentido, por que no devuelve nada. Lee unas variables y asigna un valor, que no utiliza para nada, y luego termina el programa o módulo en cuestión. Como le he explicado al usuario eso conceptualmente es inutil, además de evidenciar paradigmas de computación y de programación anticuados e ineficientes (en cuanto a costes de creación y mantenimiento de los programas informáticos).

Es divertido que me digas que mi transformación expresada en forma de función tiene un bug por que devuelve false para los casos que el usuario no ha contemplado. Si lees su ejemplo, verás que no cubre ningún otro caso, por lo que forzosamente su transformación tiene que devolver un valor evaluable a false como resultado de la ejecución del algoritmo.

¿Que valor contiene Culpable si no se entra en el if? Pues en base al código que el usuario ha decidido postear, un valor dependiente de la plataforma pero evaluable a false. undefined, null, empty, nil, false... todo eso son detalles implementativos, pues su código se basa en lógica booleana y todos esos valores evaluarían a false en cualquier plataforma de computación convencional.

De hecho, esto que comentas es un claro ejemplo de por que tengo razón: el modelo de computación que utiliza el usuario para construir el programa no especifica el dominio completo de la función, por lo que es imposible nisiquiera computarla, solo con ese ejemplo.

Y ademas no hace diferenciacion de esos casos.

Es que como programador debes conseguir que el computador haga las transformaciones necesarias para que el programa haga lo que la especificación dicta, no inventarte cosas por que a ti te parecen subjetivamente razonables. Es el clásico error de junior, que cree que tiene que construir una catedral de su propia imaginación cada vez que le piden que gestione 4 casos concretos.

El programa original gestionaba un caso, y el resto estaban indefinidios (lo cual evalua a falso). Mi función se comporta de la misma manera, pero explicita esa decisión del anterior usuario. En mi ejemplo pasa lo mismo que en el suyo, solo que en el mio las cosas son legibles y explicitas.

En el mundo real esto es un bug de libro.

¿Y que bug es? Su algoritmo solo especifica que en caso de viogen y hombre, el resultado debe ser true. No se específica nada mas. Ponerte a inventarte tus películas en las historias de usuario no es algo positivo, y ceñirse a la historia/requisitos no es un bug.

Nadie ha pedido que debe pasar con otros casos, ni se ha especificado ningún caso mas. Además, en este foro y con este ejemplo no hay contexto suficiente para decir que compartimos un entendimiento de la realidad para construir un modelo, al estilo DDD, del cual podamos deducir esos casos que no han sido especificados.

Esto no es pedanteria, es simplemente constatacion de un hecho

No, no es pedantería. Es ignorancia sobre el estado del arte de ingeniería del software y sobre ciencias de la computación.


Si quieres dartelas de listo, por mi bien, pero luego asegurate de que lo que dices tiene un minimo de coherencia.

Lo que he dicho es completamente coherente, a diferencia de tus observaciones donde me indicas que debería cubrir casos no cubiertos sobre un dominio indefinido. ¿Eres de Barcelona? Lo digo por que si te dedicas al software y eres de Barcelona es probable que nos conozcamos o conozcamos a gente en común. Tengo curiosidad por saber a que te dedicas, ya que demuestras un conocimiento muy limitado de como se construye software y por que se hacen las cosas como se hacen.

Si tu codigo es de este estilo mal vamos, y si tu sentido de humildad es ese, aun peor.

Que tiene que ver la humildad en un debate de ingenieria y ciencias de la computación? La humildad no tiene nada que ver con aceptar práticas suboptimas, o con no decirte las cosas como son.

Obviamente yo no tengo la verdad absoluta, ni tampoco soy el mejor programador o ingeniero de software del mundo, ni tampoco pretendo serlo, pero las cosas como son, si el usuario pretendía expresar un algoritmo que hace una transformación así de simple, la abstracción mas pertinente para ello es una función. Como función, luego puede constituir una pieza de otra estructura, por ejemplo de una clase, para convertirse en un método. Pero supongo que no te hace falta que te explique las ventajas de entender los programas como funciones que llaman a funciones, en lugar de como pedazos de código que alteran estados arbitrarios. ¿O si hace falta?

En eso estamos de acuerdo. Con lo del goto, bueno en fin...

La programación estructurada es un concepto que nació cuando se eliminó el goto en ALGOL.

Te cito de la propia wikipedia:

It emerged in the late 1950s with the appearance of the ALGOL 58 and ALGOL 60 programming languages,[1] with the latter including support for block structures. Contributing factors to its popularity and widespread acceptance, at first in academia and later among practitioners, include the discovery of what is now known as the structured program theorem in 1966,[2] and the publication of the influential "Go To Statement Considered Harmful" open letter in 1968 by Dutch computer scientist Edsger W. Dijkstra, who coined the term "structured programming".[3]

Las block structures de las que habla son el mecanismo que permite eliminar el goto, y convierte los programas en secuencias con principio y final definido, y no en instrucciones sobre las que saltas adelante y atrás.

Te sugiero que antes de entrar al trapo estudies un poco mas sobre ciertos asuntos, y no presupongas que la gente no tiene ni idea de lo que habla ;)

menéame