Bueno por eso los concursos de programacion de Smalltalk Solutions y Smalltalks estuvieron hechos asi. Primero tenes tiempo para tratar de resolver un problema sin demasiada complejidad (o sea, es resoluble con cosas mas o menos simples). La idea, sin embargo, es que no sea del todo claro cual es la solucion optima. Si no, caes en lo mismo de los algoritmos... gana el que aplica el ultimo paper, basicamente. Bueno, una vez que se tiene un programa, vas a la final donde tenes que hacer cambios con limite de tiempo. Si el codigo original es bueno, segun vi se resuelven las diferencias muy facilmente. Si el codigo original es medio feo, entonces el limite de tiempo es brutal y a veces los competidores no terminan.
2011/6/11 Javier Burroni <[email protected]>: > Hola a todos. Esto es un poco off topic, pero quizás a algunos de acá > les puede interesar. > Estaba leyendo este post: > http://tagide.com/blog/2011/05/programming-is-math-apparently/ que > reflexiona (o se cuestiona, mejor dicho) un poco sobre el tipo de > competencias de programación que hay últimamente. Aparentemente, la > mayoría de las competencias son de las que se pide solución a > problemas de indo algorítmico. Es esa la única dimensión donde se > evalúa. > M gustó la idea de pensar algún tipo de competencias de programación > donde se premien otras cosas que existen en la programación. Por > ejemplo: robustez del código, inteligibilidad, simpleza, etc. > > Pensé en este esquema: Existen dos problemas, A y B. Ademas, para cada > uno de estos problemas, dos particiones : A1 y A2, B1 y B2, tal que A1 > intercecsión A2 distinta de vacía (digamos, no son disjuntas), y lo > mismo para B1 y B2. > > A cada uno de los equipos (*) se les asigna otro equipo, que es su > pareja fantasma (fantasma por que ellos no saben quien es su pareja, > pero que las, las hay). Entonces, el equipo X tiene la pareja Y. > Al equipo X se le da el problema A1, y al equipo Y se les da el > problema B1. Luego de un determinado tiempo, al X se les da el > problema B2 y la solución Y(B1). De la misma forma, al equipo Y se le > da el problema A2 y la solución X(A1) (**). > Los "entregables" serían: X(B2(Y(B1))) e Y(A2(X(A1))). > Esto se hace con todas las parejas, y ganarían las parejas (no los > grupos), que mejor hayan resuelto los problemas A y B. > Sería importante que haya varias rondas para poder discriminar > niveles. Creo que para que esto funcione, las parejas tendrían que ser > mas o menos del mismo nivel. > > Esto no mide directamente cuestiones de las que había planteado (con > relación al código), pero si de una forma indirecta. Si el código se > entiende, es simple, y tiene tests, le facilita la vida al otro > equipo, que tiene que seguir construyendo sobre eso. > > Por otro lado, eso que parece excesivamente rebuscado, se basa sobre > los mismos principios por lo que uno haría las cosas de esa manera en > la practica. Me parece que puede ser una síntesis interesante. > > Bueno, comentarios son bienvenidos :) > > saludos > jb > > > * pueden ser equipos de uno, pero programación y equipos se llevan > bien, aparentemente > ** Comentarios están prohibidos. > > -- > " To be is to do " ( Socrates ) > " To be or not to be " ( Shakespeare ) > " To do is to be " ( Sartre ) > " Do be do be do " ( Sinatra ) > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
