Para su corte, es más bien una pregunta de artículo, un razonamiento de artículo y, en algunos lugares, desconcierto. Por un lado, se nos presentó la opinión autorizada de Leslie Lamport, "La programación debería ser más que codificación", que coloca la programación y la codificación en una tabla de clasificación improvisada. En el lado opuesto, yo, que no tengo el estatus suficiente para disputas con el maestro y la legendaria universidad, que él representa ... pero no puedo negarme tanto placer y riesgo. Espero que camaradas más experimentados corrijan mis fallas en el razonamiento.
Comprendo intelectualmente que la codificación en el mundo moderno generalmente se percibe como el nivel más bajo de actividad de ingeniería, que en el gráfico evolutivo está más cerca de un chimpancé que de un programador. Y quizás este sea nuestro gran error, porque el código es como el ADN. Solo cuatro nucleótidos, y qué biomasa abigarrada en la línea de productos.
Como ingenieros experimentados, somos maestros de la abstracción. Por lo tanto, no será difícil para nosotros presentar un programador condicional llamado Leslie Lampport (todos los nombres y coincidencias no son aleatorios) y su herramienta principal es la máquina de Turing. Es un maestro de su oficio, en gran parte gracias al tao de hierro:
- Decide qué debe hacer el programa.
- Determine cómo debe cumplir exactamente su tarea.
- Escribe el código apropiado.
El último paso, aunque le parece importante, claramente no le gusta y sugiere ignorarlo. Y es difícil discutir con eso. Mover el puntero a lo largo de la cinta sin fin de una máquina de Turing es un anhelo mortal.
Y aquí su genio se revela completamente. Pero este proceso, como un sharpie con dedales, debe ser monitoreado con mucho cuidado. Toma tres puntos de su programa y coloca una pelota con un código debajo del último. Asintimos y hacemos apuestas. Luego, los dedales se mezclan deliberadamente lentamente. Donde esta el codigo
Prácticamente no tenemos dudas de dónde está el tercer dedal, y el código está ... bajo el dedal número 1. Los espectadores están en estado de shock, el Sr. Lamport también parece desconcertado, pero en su corazón sabe que hizo trampa. Y justo en ese momento, cuando silenciosamente rodó la pelota con el código del artículo 3 en el artículo 1, realmente quería agarrarla por la manga.
Lo que parece un pato grazna como un pato, e incluso es seguro que es más probable que lo sea. Si ha desarrollado el lenguaje TLA + para especificaciones, gritando con toda su apariencia y comportamiento que es un código, eso es todo. El hecho de que lo haya utilizado en la etapa de especificación del programa, es decir, el punto 1 de la "decisión de qué debe hacer el programa", no eliminó la necesidad del punto 3 de "escribir el código apropiado".
Interpolemos a Leslie durante diez años, durante los cuales utiliza metódicamente el TLA + que creó para escribir especificaciones. Creo que, independientemente de si los analistas, nosotros, arquitectos o ingenieros de bases de datos, admitimos de mala gana que nos estamos convirtiendo en algo así como un codificador en el sentido más rutinario de la palabra. Diferentes dialectos, diferentes diccionarios, pero el mismo aparato reflejo, que con un aspecto aburrido da patrones de diseño, diagramas ER o especificaciones en el caso de nuestro personaje. Y ahora, bajo el engañoso ítem # 1, el autor de la tesis de que "la codificación no es tan importante" oculta esta codificación.
Para ilustrar, invitaré a otro testigo, llamémoslo John McCarthy. Programar una máquina de Turing es tan irritante para cualquiera como John, especialmente cuando se trata de las tareas que tanto ama en el campo de la inteligencia artificial. Y en la salvación, inventa un nuevo estilo de codificación declarativa para describir cómo se debe realizar la tarea (párrafo 2 de la lista de Leslie). Llamémoslo condicionalmente LISP.
Supongamos que John no ha escrito un solo programa en su vida, que, según la fórmula de Lamport, lo coloca en el ranking a nivel de plancton, aunque tiene la relación más directa con el código. Surge la pregunta: ¿cuál es su grado de perplejidad y qué le dirá en una reunión?
No presentaré docenas de ejemplos idénticos, pero intentaré ofrecer un resumen a la corte de colegas. La codificación es el pulso del desarrollo. Está presente en todas las etapas de una forma u otra. Un cardiograma parece aburrido, pero es un indicador necesario de que el proyecto está vivo. Por lo tanto, la redacción * -as-a-Code está apareciendo cada vez más.
Todos somos codificadores. Tenemos un cierto aparato y reglas para esto, solo que todos lo hacen en su propio piso. No hay ninguna razón justificada para que una persona que produce código PHP sea algo más estúpida que un analista que crea especificaciones ejecutables, y juntos pierden ante un joven hacker que piensa de inmediato en los códigos de máquina.
La diferencia es que algunos de nosotros veremos algo que otros no han notado y agregarán valor a este proceso. McCarthy - LISP, Lampport - LaTeX y TLA +. Y cuando clasificas códigos tales como el sistema de números decimales, el alfabeto Braille, la radio o los emoticones, tu lengua no se levanta para decir que "la programación debería ser más que codificación".
PD: Quizás alguien de los visitantes de la conferencia quiera hacer las preguntas planteadas. Si le parecen tontas al orador y al público, tráigame todo.
PPS Dio la casualidad de que tengo muchos materiales sobre el tema del código y la codificación, y si este tema es de interés, lo compartiré con mucho gusto.