On 11/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Pero no contestas la cuestión principal: ¿cuál es el inconveniente
de los formalismos para quien hace ciencia?
Para los que verdaderamente hacen ciencia, los que están en el borde del conociimiento humano, no basan sus ideas en formalismos, sino que crean formalismos para lo que tienen que es una intuición y luego el formalismo sirve para que aquellos que no hacemos ciencia, entendamos de qué se trata y podamos aplicar las intuiciones de otros (que ojalá funcionen) en temas prácticos. Si piensan que los científicos están todo el día resolviendo ecuaciones, están muy equivocados, eso es para los ingenieros. Y los ingenieros no necesitan andar resolviendo ecuaciones tampoco, para eso están todas las ecuaciones resueltas en libros (conozco uno que otro científico que no estaría de acuerdo con lo que dije). Si hasta está tabulado cómo mejorar el desempeño de los sistemas.
Lo que sí me he encontrado es que hay ingenieros que ni saben que está tabulado. Se creen científicos y se dedican a hacer experimentos y les pagan por hacer eso, en proyectos que deberían haber sido entregados hace 6 meses, pero las pruebas se dejaron para el final y mostraron que el usuario no esperaría 30 minutos a que apareciera la pantalla de login. A pesar de que es muy loable que tengan ese espíritu experimentador (no muchos tienen tanta paciencia), si está tabulado y no les da la gana tomar el libro, están perdiendo el tiempo.
Lo mismo para cualquier ingeniero que no es capaz de leer libros que formalizan soluciones para los problemas que está tratando de resolver. Tratar de reinventar la rueda puede ser muy entretenido, y en algunos casos hasta necesario, sin embargo en todas las comunidades científicas se exige que primero se lea todo respecto a un tema antes de ponerse a hacer experimentos. Eso se llama reinventar la rueda. Y si ven Discovery Channel habrán visto que hoy en día uno de los factores limitantes de las tecnologías son justamente las ruedas, de modo que se está invirtiendo millones de dólares en crear nuevos tipos de ruedas y hacer experiementos con ellas. Eso le dará a los países que lo logren ventajas para desarrollar las tecnologías del siglo XXI.
También dices que es un espacio público, cosa que todos sabemos, pero
mi pregunta era otra: si tu no haces ciencia ¿para qué opinas? ¿qué
sentido tiene leer a alguien que opina sobre algo que desconoce?
Ese es uno de los peligros de Internet, la gente opina porque sí,
porque tiene la posibilidad, porque se le canta, no importa saber o no
de lo que se habla; e incluso hasta se puede estar orgulloso de eso.
Oye pero entonces no podemos opinar de nada, porque no conozco un científico que estudie 2 temas. Ni un científico que además haga trabajo de ingeniero. En ciencias de la computación se dedican a estudiar el "orden" de los algoritmos de ordenamiento o estudian la triangulación en los algortimos de modelamiento de sólidos. Temas tan específicos que uno pensaría que lo tiene resuelto en 1 o 2 años. Los vuelves a ver en 10 años más y siguen con el mismo tema, muchas veces sin haber hecho ningún avance significativo (desde el punto de vista de uno que siempre es el de la ignorancia, porque son temas en los que necesitas un doctorado para empezar a entender de qué se trata).
El punto de fondo, creo, es que los formalismos sí deberían ayudar a los ingenieros en informática. El problema es que tenemos muy pocos formalismos. En el caso del análisis de algoritmos, me parece ridículo pensar que nos vamos a poner a analizar el orden de un algoritmo. Probablemente usaremos el algoritmo que está tabulado que es mejor, no nos vamos a poner a inventar un algoritmo para luego analizar su orden y finalmente experimentar con él. En el caso de las bases de datos, el formalismo del álgebra relacional, las dependencias funcionales, me parece muy úitl. En el caso de los autómatas, también me parece imprescindible. Creo que se acabaron los formalismos en ciencias de la computación.
La ingeniería de software es semi-formal, porque a pesar de que tiene mediciones, no hay ninguna que sea 100% aceptada. Se puede medir el número de líneas de código, o se puede usar puntos de función. Pero siempre la base de medición es subjetiva y genera incentivos perversos. En el caso de las líneas de código, se incentiva el copy&paste. Empresas muy conocidas en el mundo, como Microsoft, utilizan recompensas para los programadores por la cantidad de líneas de código que escriben, lo que incentiva a que hagan mucho copy&paste. Esta medición serviría si se eliminara el código repetido, pero ese es un problema O(n^2). En el caso de los puntos de función, ¿cómo calcular cuántos puntos de función tiene una clase? Los puntos de función sirven para COBOL, pero en el caso de Java, depende de cómo se estructure el código si tienes más o menos puntos de función. He visto que los puntos de función se calculan en la base de cuántas variables de instancia y cuántos métodos tiene una clase. Ese es un incentivo perverso para crear más variables de instancia y más métodos, haciendo las clases innecesariamente complicadas.
Luego está UML, Unwanted Modelling Language: http://martinfowler.com/bliki/UnwantedModelingLanguage.html
UML pretende parecer formal, pero no lo es. Esa falta de formalismo es "por diseño". El resultado es que como medio de comunicación UML es bstante pobre, porque depende de quién recibe el mensaje, lo que significa. Los patrones de diseño escritos en UML se ven casi todos iguales. El problema es que quienes piensan que pueden documentar un diseño con UML se encuentran con que 3 meses después miran el diseño´e interpretan diferentemente el mismo dibujo. Nuestro cerebro (humano supongo ;-) está acostumbrado a tratar con temas ambiguos que no están 100% definidos, que pueden ser interpretados, como la política. Ese margen de interpretación puede ser más o menos grande, pero en el caso de UML uno descubre rápidamente que la idea importante se pierde y lo único que queda son cosas irrelevantes como los nombres de las variables de instancia, los nombres de los métodos y una que otra flecha que no se sabe a ciencia cierta qué significa.
Me parece que eso de las flechitas se refería a UML, ¿no?
Saludos,
Guillermo.
