|
Al final hay casos de uso en el que es más competente que en otros, y justamente has mostrado un posible ejemplo, al igual que yo he mostrado uno, en donde todavía no es competente, o por lo menos hasta este momento.
El ejemplo que das, por el nivel de abstracción que hay en los sistemas, en cierto sentido, es mucho más fácil que extraiga, de los ejemplos con los que la alimentan, patrones un poco más generales. Pero, si observas el código que generó para Arduino, en su combinación con FreeRTOS, casi le atinó, aún con la cantidad de ejemplos que existen tanto de Arduino, FreeRTOS o ambos en conjunto.
Pero el usar ese delay fue un error, aunque hay ejemplos concretos de la combinación Arduino+FreeRTOS, donde no usan esa función, de los cuales pudiera haber extraído los patrones adecuados. Incluso la documentación hace mención de no usar la función delay.
Además para algo tan simple, el hacer uso de un RTOS, no es que digamos, algo muy acertado, y puedes conseguir lo mismo sin usarlo por medio de simples máquinas de estado, sin ponerse a cazar patos a cañonazos.
Si la IA, comprendiera la documentación de Arduino y de FreeRTOS, se hubiera dado cuenta de eso, inclusive podría haberse decantado por usar FSM.
El problema que veo, son aquellos, que en lugar de ver una herramienta más, lo van a ver como una panacea y algo milagroso que es capaz de hacer de todo, y también aquellos que van a ser tan negativos como para decir que todos van a perder sus trabajos, en lugar de darle la dimensión adecuada. Y cualquiera de las dos posiciones pueden llevar a un desastre.
Es como esas discusiones infructuosas sobre que es mejor: ASM, C, C++, Rust, Python, etc.
He visto personas que, literalmente, argumentan que escribir el código en ASM es la única forma de evitar los errores, cuando los errores conceptuales que podamos tener no te los corrige el mero hecho de usar ASM o cualquier otro lenguaje de programación, que al final y al cabo son herramientas.
Lo mismo sucede cuando critican los generadores de código que facilitan la inicialización, en este caso, del microcontrolador y sus periféricos, argumentando que se debe de hacer a mano, cuando, si nos ponemos a analizar, la mayor parte del código no se va a esta parte, sino en hacer que todo los componentes trabajen juntos en armonía. Entonces deciden optimizar donde no es necesario, restando tiempo para lo que realmente importa. Dejan de ver las herramientas como meras herramientas, y las ven mas como competidores.
Lo mismo sucede a la inversa, cuando les dan un estatus nivel Dios a estas herramientas, cuando algo va mal, ni vas a saber de donde vino el golpe.
|