Header Ads Widget

Ticker

6/recent/ticker-posts

Sweet API: Syntactic Sugar y usted

 

sweet-api-syntactic-sugar-and-you-nordic-apis

Internet es la herramienta más efectiva y sorprendente para conectar a las personas. Sin embargo, lo que históricamente no es una herramienta eficaz y sorprendente para conectar a las personas con los sistemas . Si bien las redes se forman y se comparte la información, los sistemas subyacentes históricamente se han ocultado bajo un código complejo y una abstracción.

Ingrese el azúcar sintáctico , una sintaxis que elimina mucha complejidad para el desarrollador promedio, todo mientras hace que la capa siempre presente de abstracción sea más transparente. La incorporación de azúcar sintáctico en el desarrollo puede cerrar la brecha entre el sistema y el usuario, creando un lenguaje digerible y comprensible que empodera tanto a los usuarios como a los desarrolladores.

¿Qué es el azúcar sintáctico?

El azúcar sintáctico se describe mejor simplemente como una sintaxis que mueve el código legible por máquina hacia la digestibilidad humana. Parte del problema con la codificación es que el desarrollador fundamentalmente instruye a una máquina para que realice ciertas funciones; debido a esto, el código debajo del sistema generalmente está hecho para que lo entiendan las máquinas, no las personas.

Para mover el enfoque en la comprensibilidad hacia el extremo humano de la escala de digestibilidad , los desarrolladores a menudo se han enfocado en aclarar la funcionalidad a través de la adopción del lenguaje. En 1964, Peter J. Landin acuñó el término "azúcar sintáctico" cuando describió la sintaxis de un lenguaje similar a ALGOL en el que trabajaba. Al reemplazar el símbolo lambda (λ) con el alias "dónde", Landin simplificó enormemente la construcción del lenguaje, sin eliminar ninguna de las construcciones básicas y esenciales.

Esta, entonces, es la esencia del azúcar sintáctico: aclarar y simplificar los procesos sin eliminar o alterar las estructuras fundamentales que contienen .

Como ejemplo simple, considere la operación matemática "lhs.Add (rhs)". Para el profano, esta operación es confusa, incluso si el significado pudiera abstraerse de ella, la puntuación, la estructura y la organización son innecesariamente complejas, especialmente cuando se mira un gran grupo de tales operaciones.

Sin embargo, la operación anterior podría simplificarse fácilmente a la siguiente función: “lhs + lrs”. Al observar la nueva operación, el usuario comprende inmediatamente exactamente lo que está haciendo y puede comunicar más fácilmente esta función a otros, utilizarla en su propio código e incluso modificarla para ampliar la funcionalidad.

Sin embargo, este equilibrio de la digestibilidad humana y de la máquina tiene un costo: si bien hay muchos beneficios, quizás suficientes para garantizar la inclusión por parte del desarrollador de la conceptualización del azúcar sintáctica durante el desarrollo, también hay muchos inconvenientes.

Conozca los tres enfoques diferentes para el desarrollo de microservicios

Beneficios de la codificación sintáctica

Uno de los mayores beneficios del azúcar sintáctico es el evidente aumento de la legibilidad humana . Al alejarse de la sintaxis compleja y optar por operaciones más simples, sencillas y claras, el código se simplifica drásticamente.

Esto tiene el beneficio adicional de hacer que el desarrollo por parte de usuarios novatos y desarrolladores de bifurcaciones sea un proceso mucho más fácil. Cuando una API se explica con más claridad y los procesos dentro de ella están mejor documentados, la API se puede transformar y ampliar más fácilmente. A medida que se implementan y admiten construcciones cada vez más avanzadas, y se expande el uso de Hypermedia , esta comprensión se ha vuelto cada vez más importante.

Asimismo, esto tiene grandes beneficios a la hora de solucionar problemas y experimentar con el código base. Con la claridad viene la simplicidad, y tener un código bien comentado que se entienda fácilmente significa que los problemas se pueden identificar más claramente antes de que entren en producción y, una vez en producción, se pueden identificar más fácilmente como la causa raíz de un problema.

Más concretamente, el azúcar sintáctico elimina mucha confusión, incluso dentro del equipo de desarrollo. Cuando la sintaxis se abstrae en un formato más fácil de entender, los elementos funcionales y las clases que son similares en estructura pero diferentes en función son más difíciles de confundir y combinar entre sí, lo que hace que la depuración y la comprensión sean un asunto mucho más fácil.

El mayor beneficio no proviene de lo que hace el azúcar sintáctico, sino de lo que no hace. El azúcar sintáctico no cambia la interacción entre la máquina y el código, y el consumidor siempre puede usar el código base si lo prefiere. Una cosa sería si un desarrollador utilizara un lenguaje cuestionable o de baja adopción en aras de la brevedad y la claridad, porque en este caso, perderían tanto, si no más, como ganaron.

Sin embargo, al adoptar el azúcar sintáctico, no se pierde nada técnicamente: los humanos pueden leer el código más fácilmente y las máquinas pueden utilizar las mismas operaciones utilizando el mismo código base. Cuando se combina con API Gateways , una API se puede hacer simple, pero engañosamente poderosa.

Aprenda a codificar API RESTful mediante Play Framework

Inconvenientes de la codificación sintáctica

Sin embargo, el azúcar sintáctico no es todo brevedad y claridad; si bien el caso para la adopción del azúcar sintáctico es bastante sólido, hay una gran cantidad de inconvenientes inherentes al enfoque.

El primero de ellos es el hecho de que el azúcar sintáctico, a pesar de simplificar la base de código para el lector a primera vista, tiene el potencial de complicar demasiado los lenguajes y sistemas utilizados por los desarrolladores. Si no se aborda y documenta correctamente, el azúcar sintáctico puede resultar en una variante más compleja y menos estandarizada de un lenguaje que obliga al usuario a volver a aprender mucho de lo que ya sabe, incluso si lo que necesita aprender es más fácil de entender.

Esto no puede exagerarse como una advertencia importante: emplear azúcar sintáctica significa que hay otra cosa nueva que el desarrollador debe aprender. Incluso si la sintaxis es más simple, cualquier desarrollador que se precie querrá aprender el código subyacente del que se está abstrayendo, agregando otra capa. Lo que pierden en el tiempo de aprendizaje inicial, lo compensan con el uso, pero sigue siendo un sumidero de tiempo inicial significativo que debe tenerse en cuenta.

Hay una gran cantidad de desarrolladores que se han pronunciado en contra del azúcar sintáctico, entre los que destaca Alan Perlis , un importante contribuyente al desarrollo temprano de la programación de computadoras. Al hablar sobre idiomas delimitados por corchetes en sus “Epigramas sobre programación” , dijo:

“El azúcar sintáctico causa cáncer de punto y coma”.

A lo que se refería Perlis es al hecho de que el azúcar sintáctico puede causar problemas con la capacidad de análisis al migrar entre idiomas. Argumentó que, dada la avalancha de lenguajes ya fáciles de entender, el azúcar sintáctico podría considerarse frívolo y derrochador. Algunos lenguajes incluso ya admiten el azúcar sintáctico, como RAML , lo que elimina la necesidad de un azúcar sintáctico personalizado.

Además, existe preocupación por la complejidad y extensión de la documentación cuando se emplea azúcar sintáctico. A medida que se crea y se abstrae más sintaxis, cada adición debe documentarse, extendiendo la extensión de la documentación y, en consecuencia, el esfuerzo requerido para mantener y corregir la documentación a lo largo del ciclo de vida del lenguaje o API.

Obtenga más información sobre cómo equilibrar la simplicidad y la complejidad en el diseño de API

Ejemplos de

Para comprender mejor cómo el azúcar sintáctico influye en el código base después de la adopción, veamos algunas implementaciones, tanto desde la perspectiva del desarrollador como del consumidor.

Ejemplos de desarrolladores

En COBOL, una operación de azúcar sintáctica simple se puede ver en la modificación de la operación de movimiento:

MOVE A B

Cuando se aclara bajo azúcar sintáctico, la operación cambia a esto:

MOVE A TO B

Si bien este es un ejemplo bastante simple, la simple adición de "TO" a la operación aclara la relación entre A y B, mostrando específicamente que A es el punto de origen y B es el destino.

Esto puede parecer una cosa pequeña, pero cuando se enfrenta a una base de código de varios cientos de miles de líneas de código, tener operaciones lúcidas es muy importante y útil.

Sin embargo, la aclaración no es todo lo que hace el azúcar sintáctico, sino que también puede acortar funciones al tiempo que aclara su propósito. Tome la siguiente restricción de función matemática:

if x then y else false

Para el desarrollador promedio, la función es relativamente fácil de entender. Sin embargo, para un desarrollador nuevo, o un desarrollador acostumbrado a sintaxis de operaciones matemáticas alternativas, esto puede resultar confuso.

Cuando se implementa con azúcar sintáctico, esa operación se simplifica enormemente:

x and y

Esta simple reducción de longitud especifica en términos inequívocos que se requieren xey. La reducción de la longitud aquí es mucho más importante que la pérdida de verbosidad con el resultado "else false", y para muchos programadores, la comprensión entre las operaciones "y" y "o" es bastante universal.

Esto se puede ver aún mejor en la reducción de la siguiente operación matemática:

(lam(v1 : typof(x1), ..., vn : typeof(xn)) { body })(x1, ..., xn)

Cuando se reduce, la operación se convierte en una operación simple:

let v1 = x1, …, vn=xn

Cualquiera que esté familiarizado con las matemáticas puede comprender instantáneamente lo que significa esta secuencia y con mayor facilidad que la operación original.

Finalmente, podemos ver la implementación PERL de una declaración condicional:

if(not condition) {...}

Si bien esto es algo fácil de entender, la frase "no condición" es algo extraña en la lengua. Cuando se restringe bajo azúcar sintáctico, obtenemos:

unless(condition) {...}

Esto deja en claro que lo siguiente solo ocurre en ausencia de la condición indicada. A menos que sea fácil de entender, y mucho más fácil de entender que "no condición".

Ejemplos de consumidores

Si bien al principio el usuario promedio puede no experimentar un gran cambio de operadores simples a operadores aún más simplificados a través del azúcar sintáctico, los principales beneficios aparecen con bases de código más grandes.

A medida que el código base crece, la capacidad de ver el “panorama general” y comprender cada operación individual y cómo funciona a menudo se pierde. Al simplificar las operaciones y aclarar el lenguaje que contienen, perderse en la complejidad se convierte en una hazaña en sí misma.

Además, los beneficios que se agregan al solucionar problemas no son evidentes, pero cuando un usuario soluciona errores en su código e interacciones, el azúcar sintáctico da a conocer sus beneficios muy rápidamente.

Imagine, por un momento, que un usuario accede a una API que convierte el formato de audio de flujos FLAC de alta tasa de bits a MP3 comprimidos de 320 kbps. Cuando miles de líneas de código no tienen claro exactamente cómo se establece la transmisión, en qué situaciones ocurren ciertas operaciones (especialmente en el caso de "si" y "a menos que") y cómo se mueven los datos, el código se vuelve innecesariamente complejo y difícil de entender.

El usuario se encuentra muy rápidamente en una situación en la que una complejidad innecesaria da como resultado una falla en comprender dónde ocurre exactamente un punto de falla. Al especificar la función exacta de la operación, el usuario puede capturar la conversión de audio en el medio, reconocer el error y rectificarlo, con un conocimiento mínimo de las complejidades bajo el capó, por así decirlo.

El azúcar sintáctico es esencialmente un enfoque para los consumidores: si bien mejora la experiencia de desarrollo hasta cierto punto, la claridad y la naturaleza explicativa del azúcar sintáctico hace que sea más fácil para los consumidores y los desarrolladores externos utilizar el código.

Un argumento de la vejez

La adaptación o no del azúcar sintáctico es un argumento antiguo que, en última instancia, se reduce a la elección personal entre dos enfoques distintos, ambos con amplios beneficios e inconvenientes.

Las API azucaradas son más fáciles de consumir por su propia naturaleza y, por lo tanto, son más aptas para nuevos desarrolladores y usuarios. El azúcar sintáctico hace que el código sea más fácil de entender, implementar, transformar y conceptualizar para el usuario promedio. Desafortunadamente, esto tiene el costo de una mayor abstracción y pérdida de estandarización.

La pregunta se refiere al tamaño y la estandarización por encima de la comprensibilidad. Si su elección es un tamaño de base de código pequeño y la estandarización, entonces renunciar al azúcar sintáctico es una buena opción, aunque hace que el lenguaje sea más complejo.

Sin embargo, si la comprensión y la concisión de las bases de código son más importantes, el azúcar sintáctico es una opción maravillosa y debe implementarse.

Publicar un comentario

0 Comentarios