No Code y la progresiva automatización de la programación

IMAGE: No Code

Un equipo de investigadores del MIT y de Intel han desarrollado un algoritmo capaz de crear algoritmos. Y antes de que algunos empiecen a fantasear con la ciencia-ficción que ven en las películas y con esa Skynet que acaba con la humanidad, dejemos claro que de lo que hablamos, en realidad, es de la posibilidad de que una máquina sea capaz de automatizar las tareas de programación, de manera que un programador pueda automatizar múltiples tareas tediosas o repetitivas o, llevándolo a su límite, que cualquier persona sea capaz de programar simplemente describiendo las tareas que desea que ese programa lleve a cabo.

Para lograrlo, se utiliza mediante un sistema de similitud de código inferido por máquina (MISIM), un motor automatizado diseñado para aprender lo que una pieza de software pretende hacer, estudiando la estructura del código y analizando las diferencias sintácticas de otros códigos con comportamiento similar. Una idea, la de los ordenadores capaces de programarse a sí mismos a partir de unas instrucciones dadas en lenguaje natural, que lleva tiempo apuntándose como una posibilidad y que, de hecho, se ha puesto ya en práctica en varias iniciativas del tipo No-code development platforms, o NCDPs, y a todo un movimiento encuadrado en la denominación No Code.

Cada vez más compañías, particularmente startups con la capacidad de diseñar sus sistemas desde cero, ponen en marcha sus actividades mediante el desarrollo de estructuras basadas en código escrito por terceros o tomado de repositorios y plataformas, que es ensamblado en piezas para obtener la funcionalidad deseada. Algunos afirman que la pandemia de coronavirus y el incremento del trabajo distribuido se han convertido también en un incentivo para la adopción de este tipo de plataformas y herramientas. El pasado mes de junio, Amazon lanzó su plataforma Honeycode, que permite diseñar y construir aplicaciones a partir del ensamblaje de módulos de diversos tipos. En el mismo sentido, Salesforce ofrece Lightning App Builder, Google tiene App Maker, Microsoft ofrece Flow y Power Apps, o podríamos considerar herramientas de construcción de páginas como WordPress, de automatización de tareas como IFTTT, o muchas más.

¿Son las plataformas de tipo low code o no code el futuro? En realidad, plataformas de ese tipo siempre han estado, a ciertos niveles, entre nosotros. En su momento, mis primeras páginas web las construí, como mucha gente, con herramientas visuales como FrontPage o Dreamweaver que no requerían prácticamente ningún conocimiento de programación, y que en muchos sentidos, me enseñaron a entender mucho más sobre lo que había detrás de una página web o sobre los comandos que soportaban determinadas funcionalidades.

Para muchos, la idea de poner herramientas de este tipo en manos de usuarios incapaces de revisar el código que generan resulta poco sostenible, y terminaría por dar lugar a sistemas tipo Frankenstein con piezas muy difíciles de mantener, de evolucionar o de actualizar, además de suponer potencialmente más problemas de seguridad derivados tanto del escaso conocimiento de sus responsables, como de la posibilidades de aparición de vulnerabilidades derivadas de la propia plataforma, que podrían ser explotadas en todas las aplicaciones construidas a partir de ellas.

Otros afirman que ese tipo de herramientas servirán para asistir a los desarrolladores en la construcción y mantenimiento de sistemas en entornos cada vez más complejos y más difíciles de dominar por una sola persona, y que el papel y las responsabilidades de los que hoy son programadores se elevarán en consecuencia hacia tareas de supervisión y de otros tipos.

De un modo u otro, hablamos de poner la posibilidad de diseñar y construir sistemas en manos de muchísimas más personas, con todo lo que ello podría llegar a tener en términos de potencial de disrupción, y todo indica que, en función de la evolución de la tecnología, la idea de describir una funcionalidad en palabras o mediante diagramas a una máquina para que construya a partir de esa descripción el código necesario será algo que termine siendo posible, una simple cuestión de tiempo. De ahí a que eso signifique que los actuales programadores se vayan al paro, o que de verdad cualquiera pueda construir un sistema con una complejidad elevada simplemente mediante menús y clics, va todo un salto conceptual que, por el momento, no me parece en absoluto sencillo ni realista.


This article was also published in English on Forbes, «Could No Code put programmers out of a job?»


28 comentarios

  • #001
    Xaquín - 9 agosto 2020 - 15:46

    Sencillo no, pero si tiene visos de posibilidad futura, entonces también los tiene de futura realidad. Y como dices , y ya pasa con los virus, por ejemplo, que algún dios nos coja confesados, si no cambia la versión humana del homo sapiens.

  • #002
    Benji - 9 agosto 2020 - 16:16

    Considero (como programador) que la abstracción debe ser cada vez mayor.
    De hecho, el 99% de los programadores usamos algún lenguaje de alto nivel. Llámalo C, PHP, Basic… pero ninguno de nosotros «baja» a las tripas en código «Ensamblador» que hay por debajo. Para mí, cualquier subida de «C» a otra capa de lenguaje natural sería muy positiva.

    Por otro lado, es muy difícil que esto signifique el fin de los programadores. Una pieza de código se puede usar todas las veces que haga falta, pero configurarlo en la herramienta X del cliente, manejo y soporte de la API al final siempre tendrá un técnico detrás.

  • #003
    Gorki - 9 agosto 2020 - 17:40

    Yo no lo he utilizado pero, en mi entorno sí, Había una especie de lenguaje de programación que era algo parecido a un pseudocódigo, que con cierta frexibilidad en el las palabras que introducías, permitia que la máquina lo trasladara al COBOl.

    Algo asi como escribir

    open file NNNNNl
    read key file XXXX
    add amount 9999 to total_ amount

    Y luego un programa editaba el fuente en Cobol.

    Supongo que esto que indicas será un paso mas allá. Yo creo que es posible hacerlo, con el nivel que se ha alcanzado en los Alexas y Siris creo que pudiera hasta dictarse y que el programa tradujera a código tus instruccions..

  • #004
    sin censura - 9 agosto 2020 - 18:00

    Cualquiera que ha programado algo, ha hecho scripts que escriben programas, para ahorrar tiempo. Lo que jamás me han parecido útiles son plataformas de terceros que lo hagan por ti, y menos en entornos visuales, que consumen memoria y encarecen el código final en memoria y complejidades no requeridas.

    La idea no es nueva, lo más viejo que conozco, creo que de los 70 es el propio «make» que hace cosas parecidas para facilitar la compilación.

    O como señala Gorki, crearte plantillas de lo que quieres hacer, en un seudocódigo que te genera el código… y se corre como entrada en un preprocesador

    • Lua65 - 10 agosto 2020 - 09:34

      Depender de terceros siempre es una mierda (con perdon)

      Como he dicho abajo, he estado años programando en i4GL/iSQL.

      Llegue a hacerme una especie de parser (en i4GL) que escribia en lenguaje natural y me generaba pseudocodigo que via yacc acababa en C

      En la dB tenia cientos de funciones pre-fabricadas y el se encargaba de encadenarlas.

      No era perfecto, pero me resolvia muchas horas de tecleo.

  • #006
    Javier Lux - 9 agosto 2020 - 18:38

    Aquí seguro que me van a contradecir, pero las tecnologías de internet para el programador han sido un paso hacia atrás, y solo python y ruby on rails han intentador corregir esa deriva. Me explico:

    En los 80 había herramientas que se llamaban 4GL que facilitaban ENORMEMENTE la programación que entonces se hacía, que eran aplicaciones de base de datos. Herramientas como INFORMIX, PowerHouse, postgres o PowerBuilder o el Visual Basic eran infiniamente mejores para desarrollar aplicaciones ad-hoc con bases de datos que el Lenguaje-C o el mismisimo Cobol. He visto alucinates desarrollos hechos con Ms Access. Por no hablar del Lotus Notes, que tenia hasta el eMail dentro del server.

    Pero llegó internet y para hace una triste aplicación de BD hay que saber HTML, Javascript y adminsitración de S.O. para configurar todo en integrarlo. Horas de trabajo y hasta que no dispones de buenos templates, queda un truño. Javascript es similar a Lenguace-C, por lo tanto lenguaje de bajo nivel de abstracción.

    Lo de MS Access clama el cielo. Que por llevar a internet abandonen esa magnifica herramienta es una pena. Esperemos que esta moda LowCode corrija ese despropósito

    • Javier - 9 agosto 2020 - 19:46

      La iniciativa No Code es sumamente atractiva, no lo dudo, pero en mi caso, y para mi negocio, me sigo planteando una BD en Access como Front End conectada a un servidor MySQL como Back End donde estén las tablas.

      Gano en mucho: casi sin límites de usuarios, ni conexiones. Económico y versatil. Y quedan ya sentadas las bases para futuras ampliaciones y desarrollos.

      La programación en VBA la haría yo o la delegaría, pero en todo caso, ya tengo mi BD en la nube. Y listo.

      Con eso soluciono el problema que mencionas para Access + Internet

      ;-)

      • Javier Lux - 10 agosto 2020 - 11:38

        Así es. Los aluciantes desarrollos con MS Access que he visto usaban la herramienta como font-end.

        Realizar una UI de una app en Ms Access es hiper-productivo, mucho más que el mismisimo ruby -on rais, que es lo mejor que he visto de Browser Internet UI db applications.

    • Carlos Quintero - 9 agosto 2020 - 20:13

      Solo te voy a contradecir parcialmente en que al menos varias de esas herramientas (Visual Basic, PowerBuilder, Access) son de los 90, no de los 80 :-)

      Si alguno te contradice en algo más, será que no conoció esos años, donde con solo 2 tecnologías (un lenguaje de programación y SQL), que podías dominar a fondo, podías hacer aplicaciones empresariales completas. Hoy en día, donde para hacer una aplicación necesitas «n» tecnologías, lenguajes o frameworks, y que como para cada una necesitas un par de años para dominarlas bien no llegas a dominar porque te las van cambiando, se programa mucho «a salto de mata», copiando/pegando código, buscando en internet cómo hacer las cosas, sin saber depurar/diagnosticar/averiguar la causa raíz de los problemas cuando surgen y lo peor de todo, sin entender realmente cómo funcionan las cosas. Siempre digo que si se apagara stackoverflow.com unas semanas, no se podrían hacer nuevos desarrollos en las empresas :-)

      La informática (incluida la programación) es muy compleja, no importa cuántas capas de abstración se le pongan por encima y por tanto siempren se necesitarán (buenos) informáticos. Ejemplos hay muchos: Excel parece simple, pero hay usuarios que lo emplean cuando deberían usar una BD, y montan unos líos tremendos, y más si el Excel es compartido. WordPress parece simple (para escribir posts), pero no lo sabría configurar ningún blogger que no tuviera conocimientos de informática, ni para añadir/configurar un plugin si ya se lo da montado un proveedor de hosting.

      Y el tipo de no-code que solo requiere configuración con clicks de ratón, al final necesita control de versiones, y se vuelve a usar código. Ej: en DevOps el «pipeline as code» que deja obsoletos los asistentes visuales de Jenkins o Microsoft Azure DevOps y hay que usar YAML, o Groovy, o lo que inventen como código que se pueda guardar en un archivo de texto en un repo Git.

      PD: No se me entienda mal, empecé a desarrollar software antes de la era de los PCs y a día de hoy me mantengo razonablemente al día habiendo pasado por muchos lenguajes de programación/frameworks/paradigmas y ciclos de vida del desarrollo de software en equipo, etc. y me encanta, pero me da mucha ternura cuando oigo hablar del no-code… ;-).

      • Javier Lux - 10 agosto 2020 - 11:43

        100% de acuerdo. Incluso en el Ms Access, al final hay programación en VBA, e incluso se pueden hacer llamadas a sistemas exteriores..

        El Low-Code siempre se podrá llevar a altísimas complejidades.

      • Lua65 - 10 agosto 2020 - 12:05

        En cuanto a Excel, te puedo decir que ha sido la herramienta mas odiada (por mi, junto a Lotus) en su momento (siendo realista, elimino a muchos programas propietarios en empresas y con ello a sus programadores), a ser una herramienta de la que hoy en dia no puedo prescindir (digamos que es mi «calculadora»), sobretodo cuando hago migraciones de propietarios a ERP, amen, que mi dedicacion a la formacion continua en empresas hacen de ella mi piedra angular…

        Mi incursion en VBA me ha llevado a hacer pequeñas aplicaciones (para pequeñas empresitas) en tres patadas. Pero aun asi, sigo echando de menos aquel «lo estoy pariendo todo desde cero»…

        Llevo desde 2005 «retirado voluntario» de la informatica, aunque siempre digo que es mentira, nunca lo dejas, y nunca dejo de preocuparme por aprender mas cosas, aunque ya no les de salida…

    • Lua65 - 10 agosto 2020 - 09:14

      INFORMIX y i4GL ahhh que tiempos…!!! XDDD

      (vale, me vuelvo a mi retiro) :)

  • #013
    Krigan - 9 agosto 2020 - 19:55

    En realidad la programación de la muy amplia y creciente lista de tareas que se hacen mediante IA ya es algo que se hace de manera mayormente automática. En lugar de especificar los pasos concretos que debe ejecutar el programa, lo que se hace es entrenar la red neuronal. Lo cual no es moco de pavo, porque la IA se está usando para casi cualquier cosa que se pueda imaginar.

    Ahora bien, la programación tradicional es algo que se va a seguir usando para otras muchas tareas, y en realidad no son cosas antagónicas, sino que lo habitual en cualquier programa está siendo usar tanto IA como programación tradicional entremezcladas.

    Por eso esto del machine programming es algo que puede ayudar mucho en producir más código, y más depurado y eficiente.

  • #014
    Juan T. - 9 agosto 2020 - 20:05

    Todo tiene los visos de que el ser humano va a tener tanto apoyo a su creatividad que va quedar reducido simplemente a tener el criterio final.

    Pongamos por ejemplo los programas de producción musical en los que una persona tiene a su disposición todo lo necesario para componer, arreglar, sintetizar, mezclar masterizar, etc.

    Hay tantos programas y aplicaciones que se encargan de automatizar todos esos procesos, que, finalmente, los que van a destacar en ese campo no son los que tienen el conocimiento técnico, sino los que tienen el criterio para saber cuando algo suena bien probando distintas configuraciones de ritmos, sonidos, melodías etc.

  • #015
    Daniel Toja - 9 agosto 2020 - 21:43

    Seguirán existiendo los compositores, los músicos que tocan el saxo y los violinistas. Son los verdaderos artesanos.
    Pero el Rey de la pista es el DJ, que junta fragmentos de música, desata loops, y pone efectos electrónicos de sonido.
    La música electrónica ha sido la democratización de la producción musical, espero que el nocode sea la democratización de la producción de aplicaciones.
    Será un avance para la sociedad, puesto que el problema con el que nos encontramos actualmente es que el que sabe codigo no es experto en ningún campo empresarial. Y el que tiene el empresarial, no tiene de codificar.
    El que puedan coincidir ambos skills , es un plus.

  • #016
    Luis Hernandez - 10 agosto 2020 - 09:56

    Al final siempre tendrás que explicarle a la máquina que es lo que quieres que haga y eso es a lo que se llama «programar». Puedes hacerlo a muy bajo nivel con código ensamblador o a muy alto nivel, con lenguaje natural que es lo que más se paracería a un verdadero «No Code», pero la lógica de los procesos y el sentido mismo del programa, es cosa del programador.

    El proyecto en el que trabajo, VisualNEO, es una herramineta visual de programación con un lenguaje de alto nivel que incluso puedes extender tu mismo, añadiendo Wizards que hagan innecesario memorizar nada.

    • Gorki - 10 agosto 2020 - 10:08

      Explicar lo que quiere que se haga, no es programar es análisis, Programar es como hacer que lo que quieren que se haga, se ejecute en el equipo,

      Algo de este tipo, es simplemente crear un lenguaje de programacion más próximo al lenguaje humano, lo que se viene intentando desde el Ensambador.

      Esto no reducirá el número de analistas, pero hará a los programadores mucho mas productivos, Por tanto se necesitaran menos programadores para programar lo mismo.

      • sin censura - 10 agosto 2020 - 11:06

        Pero además si es un algoritmo el que codifica…

        Todos sabemos que la resolución de un problema se puede atacar con distintos algoritmos, el ejemplo clásico es ordenación. En análisis puedes decir «ordenar la tabla fulanita» y hacerlo de un modo chapucero o de forma eficiente. Así llegar a la solución se podrá llegar por distintos caminos, y en este ejemplo trivial alguno nos dirá elige quicksort… ahora un algoritmo inteligente no tiene solo que buscar el camino más rápido, sino también el que mejor mantenimiento tenga, el más versatil para poder depurar correctamente, si no hay un «pollo» detrás de todo esto, nos puede pasar como con el famoso caso creo que era con diagnósticos médicos que alguien se da cuenta con el tiempo que «joer» teniamos un bug, y llevamos años dando resultados erróneos…

        • Gorki - 10 agosto 2020 - 12:11

          Absolutamente de acuerdo, (al menos antes), estos sistemas producen un código poco efeciente y lleno de módulos que nunca se utilizan, Por tanto no son ni mucho menos lo mejor en cuanto optimización y ademas es imposible corregir un bug o modificarlos con nuevas prestaciones,, hay que volver a programar desde cero, porque no hay mente humana que pueda seguir aquella madeja deforme de instrucciones,

          Pero una vez que funcionan, son eficientes, solo precisan de una máquina suficientemente potente para correr por ellos,

          Pero hoy es mucho mas barato compara una máquina el doble de potente, que pagar el doble de sueldos de programación.

      • Luis Hernandez - 10 agosto 2020 - 13:25

        Ok, aunque yo considero programar como un todo donde el análisis no es más que una fase:
        Fases del proceso de programación.

        • Lua65 - 10 agosto 2020 - 13:46

          En mis tiempos, cuando los brontosaurios, un analista se dedicaba exclusivamente a eso… luego como mucho, existia la figura del analista organico (se diferenciaba del funcional, en que te entregaba casi pseudo codigo) y finalmente estaba el «teclas»…

          La ventaja es que este modelo servia perfectamente para el reparto incondicional de culpas llegado el momento (que siempre llegaba) XDDD

    • Lua65 - 10 agosto 2020 - 10:37

      Quizas porque peco de «purista» o porque me niego a dejar de ser «de la vieja escuela» (Unix/Xenix/C, desde 1986)

      Pero a mi, todas estas herramientas (de las que NO pongo en duda su utilidad), me parecen generadores de programadores «terminal tonto» (los viejos me entendereis)

      Se pierden las viejas costumbres, «rascar codigo», y luego vienen los «esto no se puede hacer» (porque la herramienta no da para mas)

      Las aplicaciones que desarrollaba en i4GL, tenian mucho de C «a pelo», donde no llegaba por un lado, lo hacia por el otro.

      imaginacion… requisito indispensable, eso no se aprende en la uni, se tiene o no se tiene.

      y para mi, estos avances, limitan esas capacidades.
      que si, que es otra forma de hacer las cosas y quizas mas productiva, pero hay que ser muy atrevido para llamar analista/programador a esos «usuarios» (que es lo que son) que cada vez, hacen menos :)

      Venga, ya podeis machacarme… XDDD

      • Luis Hernández - 10 agosto 2020 - 13:29

        Una herramienta como VisualNEO Web te permite ambas cosas: ser un usuario que reutilice código e incluso diseños y programas completos o programar «a pelo» incluso con webassembly si lo necesitas, creando tus propias extensiones si quieres.

        • Lua65 - 10 agosto 2020 - 13:44

          Algo que no pueda hacer uno mismo si se lo propone?

          Pregunto, ehh? No conozco programadores que no tengan sus propias librerias (y que se reutilizan en casi todo proyecto, unos mas otros menos)

          Yo no estoy entrando en la «productividad», sino en el concepto «programador AS IS» de toda la vida vs «el que se lo dan todo mascado» (y que al final, si quiere ser eficiente, tendra que rascar si o si, o ser un conformista como ya he dicho: si el framework no lo permite, no se puede…)

          E insisto, no quiero desmerecer esas herramientas, que de estar yo en produccion a buen seguro, alguna utilizaria… aunque a regañadientes… XDDD

    • Kinsol - 10 agosto 2020 - 15:29

      VisualNEO, me interesa,

  • #026
    Pedro Torres Asdrúbal - 10 agosto 2020 - 12:07

    Toda nuestra historia nos hemos creído los hijos de Dios, la culminación de su creación, y ahora justo estamos aprendiendo que somos insoportablemente leves.

    Estamos en los albores de cambiar el hacer lo que nos marcan los demás, la cultura, los usos y costumbres, a hacer lo que nos «recomienden» las máquinas.

  • #027
    Miguel Pérez - 10 agosto 2020 - 18:10

    Todas las empresas utilizan desarrollos técnicamente sencillos, nómina, contabilidad, inventarios y los ERP la mayoría ya con 40 años desde su diseño. Se han venido ajustando para mejor explotación de los datos sin embargo En la operación diaria de las empresas en ¿dónde cabe la IA, o la realidad virtual? Cuáles retos de operación empresarial requieren soluciones tan sofisticadas. La publicidad o la ciencia tal vez.

    • Lua65 - 10 agosto 2020 - 19:40

      Ya te lo digo yo, ejemplo practico:

      Una empresa donde despues de 10 años, al fin tiene en «produccion» una aplicacion propietaria que se empezo 8 años antes (no me voy a meter en entresijos, que dan para un Netflix), llega el consultor de turno y dice que Navision es la monda… vamos, que nos ibamos a hacer pajas galacticas….

      Dos años despues de empezar esa «migracion», la aplicacion (la nueva) seguia en bragas (cuando la anterior estaba lista)

      El ERP era Navision… XDDD

Dejar un Comentario

Los comentarios están cerrados