¿Por qué la verbosidad es mala para un lenguaje de programación? [cerrado]

He visto a muchas personas quejarse de verbosidad en los lenguajes de programación. Me parece que, dentro de algunos límites, cuanto más detallado es un lenguaje de programación, mejor es entenderlo. Creo que la verbosidad también refuerza la escritura más clara APIpara ese idioma en particular.

La única desventaja que se me ocurre es que te hace escribir más, pero quiero decir, la mayoría de las personas usan IDE que hacen todo el trabajo por ti.

Entonces, ¿cuáles son las posibles desventajas de un lenguaje de programación detallado?

El objetivo es la comprensión rápida.

"Detallado" significa "usa demasiadas palabras". La pregunta es qué es "demasiados".

Un buen código debería ser fácil de comprender de un vistazo. Esto es más fácil si la mayoría de los caracteres cumplen directamente el propósito del código .

Señal vs ruido

Si un idioma es detallado, más de su código es ruido. Compare el "Hello World" de Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... con Ruby:

print "Hello World!"

El ruido desperdicia energía mental.

Cryptic vs Clear

Por otro lado, la terquedad excesiva en un idioma también cuesta energía mental. Compare estos dos ejemplos de Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Afecta la cantidad de código que puede ver y analizar en una sola mirada

x++ más bien que set(x,Integeradd(get(x),1))

PD. No es solo cuestión de leer código. En los días de pantallas de 40x25, los lenguajes de tipo APL, o Perl, eran útiles sobre Cobol o Fortran por la cantidad de código que podía leer / página. Pero ahora se trata más de su propio caché interno: si una declaración tiene un solo operador, es más fácil para mi cerebro envejecer analizar que uno con 3 símbolos y 4 llamadas a funciones.

Si la verbosidad del lenguaje disminuye la legibilidad del código, entonces es malo.

Algunos lenguajes tienen una sintaxis tan detallada que toma más tiempo comprender el significado del código (estoy pensando en VB.NET versus C #):

If something Then
End If

if(something)
{}

Realmente se reduce a lo que un codificador está familiarizado y cómodo.

Ve a ver AppleScript , uno de los lenguajes más detallados que puedo pensar que podría considerarse actual , intenta escribir algo trivial en él y vuelve y prueba y argumenta que la verbosidad es un buen rasgo en un lenguaje.

Intentar recordar toda la semántica de dónde van las palabras clave y cuáles son no es trivial si no lo haces todos los días.

Solo mire todo el ruido de palabras clave en este ejemplo trivial:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

Conceder lo mismo bashcon las herramientas tradicionales de Unix sería breve pero críptico para la mayoría de los usuarios de OSX, por lo que hay que lograr un equilibrio.

Creo que debe darle la vuelta a la pregunta y preguntar: ¿por qué algunas personas piensan que el código conciso es bueno?

Mi respuesta sería que hay dos razones básicas:

Razones por las cuales Terse puede ser mejor

Estos incluyen ser más legibles, de la misma manera que una oración corta puede ser más comprensible que una oración florida y verbosa. A menudo, los lenguajes de programación que intentan emular la gramática del idioma inglés terminan siendo horriblemente largos, lo que requiere enormes extensiones de código para realizar las acciones más simples. A menudo encontrará que cuanto más emula un idioma un idioma escrito, más difícil es convencerlo para que realice operaciones lógicamente complejas.

Razones por las cuales Terse puede ser peor

Algunos idiomas (y estoy pensando en Perl) usan una serie de símbolos extraños, que parecen haber sido seleccionados casi arbitrariamente, como parte de su sintaxis. Para cualquiera que no esté familiarizado con estos jeroglíficos, el lenguaje se vuelve impenetrable. También se vuelve fácil cometer errores tipográficos que no se ven fácilmente. Las expresiones regulares tal vez personifican este tipo de terquedad.

Además, a algunas personas les gusta presumir escribiendo código conciso porque, francamente, piensan que les hace parecer inteligentes. Esto se ve a veces en StackOverflow, donde las personas a menudo envían respuestas que son extremadamente compactas a expensas de la legibilidad. Esta es una especie de "impresionar a sus compañeros" con lo mucho que sabe de filosofía, pero los buenos programadores se dan cuenta de que el " código de golf " no es la forma de crear software mantenible.

@frowing, sugeriría que una forma de ver el problema de la verbosidad es darse cuenta de que la programación siempre es una mezcla de dos estilos bastante diferentes de encontrar y expresar una solución.

El primer y más detallado estilo es la programación orientada al lenguaje (lingüística). Este estilo combina palabras parecidas a sustantivos y verbos dentro de estructuras parecidas a oraciones, y está destinado a ser leído y entendido de la misma manera que un párrafo bien escrito. La programación lingüística es el estilo de programación más universal ya que el lenguaje en sí es universal. Por esa misma razón, el soporte de programas a largo plazo siempre necesita un componente lingüístico poderoso, ya que lo primero que buscará un nuevo programador es una comprensión conceptual de lo que se está haciendo. Como regla general, cuanto más se aleje del contexto en el que creó un programa, más importante será un estilo lingüístico de programación para garantizar que sus suposiciones y conceptos no sean mal interpretados por la próxima persona que intente comprender su código. .

El segundo y más conciso estilo es la programación matemática (matemática). Este estilo de razonamiento también se basa en el lenguaje, ya que, por ejemplo, las variables son análogas a los sustantivos y los operadores a los verbos. Sin embargo, el razonamiento matemático aprovecha la sorprendente y altamente paralela capacidad de nuestros cerebros para realizar transformaciones espaciales complejas en objetos que están dentro de nuestra línea de visión. Al representar sustantivos y verbos como símbolos compactos y distintivos que se pueden organizar en objetos imaginarios bien estructurados (ecuaciones), podemos usar nuestras capacidades visuales altamente paralelas para realizar rotaciones, reemplazos, movimientos, inversiones y otras transformaciones en estos imaginarios objetos. El resultado es una enorme amplificación del número de casos que podemos manejar a la vez, ya que cada símbolo puede representar clases enteras de objetos estrechamente relacionados.

Tenga en cuenta que para aplicar el procesamiento visual de manera efectiva, debe mantener su objeto imaginario lo más similar posible en tamaño y características a un objeto real. Si el campo de visión necesario se ensancha demasiado, o los símbolos no se pueden usar como marcas móviles en un objeto, o si tiene que "leer letras" y convertirlas en palabras, la capacidad de realizar transformaciones complejas de manera confiable disminuirá rápidamente incluso para un muy buen matemático.

Es por eso que las personas inmersas profundamente en el estilo matemático de programación pueden ser seriamente infelices si una ecuación se extiende y se expresa en lo que llamarían un estilo lingüístico "detallado". No es porque la ecuación haya cambiado significativamente, es porque extenderla así puede hacer que sea casi imposible aplicarle un estilo visual de comprensión. Sin embargo, al mismo tiempo, es probable que un nuevo programador que no esté familiarizado con los símbolos cortos prefiera una versión más detallada que proporcione más información lingüística para comprender inicialmente lo que hace el código.

Entonces, ¿qué recomendaría?

Use ambos estilos, pero preste especial atención a por qué está usando cada estilo.

Por ejemplo, cualquier cosa que tenga la posibilidad de interactuar con el mundo exterior debe ser intensamente detallada en algún nivel, incluso si se trata solo de comentarios en línea mezclados con el código, y también debe incluir comprobaciones automáticas para un uso correcto. Las anotaciones crípticas y especialmente definidas de manera incompleta no tienen nada que ver en tales interfaces, ya que casi se garantiza que se malinterpretarán en algún momento. La pérdida de 1999 del Mars Climate Obiter debido a la incapacidad de reconocer si las unidades de interfaz de software se expresaron en libras o Newtons es un ejemplo particularmente significativo de los peligros de confiar demasiado casualmente en números brutos en las interfaces de software o hardware.

Por el contrario, cualquier forma de programación que sea profundamente algorítmica y matemática es un buen candidato para una programación sucinta que admita el estilo matemático de razonamiento. Si alguien nuevo debe mantener dicho código, generalmente sería mejor para ellos aprender las notaciones matemáticas en lugar de tratar de transformar el código en formas más detalladas. Por supuesto, en todo momento debe haber documentación fácilmente disponible para explicar las partes matemáticas del código disponible para dichos desarrolladores, pero ese es un tema aparte.

Entre estos extremos hay muchos casos en los que el programador tiene considerable discreción. Sugeriría mirar cómo se mantendrá el código a largo plazo e intentar acomodar las necesidades de las personas con más probabilidades de mantener el código a largo plazo.

Varias personas han insinuado algo que creo que probablemente debería declararse explícitamente.

La verbosidad tiende a favorecer la comprensión a nivel microscópico; generalmente conduce a que una declaración individual sea fácil de leer y comprender. La verbosidad también tiende a reducir el grado de familiaridad con el lenguaje necesario para comprenderlo (al menos hasta cierto punto). Los lenguajes más detallados (p. Ej., COBOL) pueden ser al menos algo legibles incluso para no programadores completos.

La concisión tiende a lo contrario: ayuda a la comprensión a nivel macroscópico, especialmente por parte de los programadores con la familiaridad más íntima con ese lenguaje en particular. Al mismo tiempo, la falta de familiaridad con ese lenguaje específico puede evitar incluso la comprensión rudimentaria, incluso de los programadores que de otro modo tienen bastante experiencia.

Como tal, la legibilidad varía ampliamente dependiendo del público objetivo. Por un lado, considere un proyecto grande y complejo que está siendo escrito y mantenido por personas que trabajan casi exclusivamente en ese proyecto, la mayoría de los cuales tienen experiencia y programación sustancial (por ejemplo, muchos doctorados). Esto tenderá a favorecer un lenguaje más conciso.

En el extremo opuesto más o menos, considere un proyecto que sea considerablemente más simple (aunque posiblemente aún bastante grande) que se mantiene principalmente por personas que realmente se especializan en el negocio asociado con el software, en lugar de hacerlo en el software en sí. Esto seguramente favorecerá un lenguaje mucho más detallado.

En lugar de ir a un libro técnico, vuelvo a los Elementos del estilo * de Strunk and White. El concepto subyacente es "Sea preciso" y "No diga más de lo necesario". Todo lo demás es comentario.

Aplicado a la programación, se trata de ser muy preciso, pero no tener pelusas innecesarias. La pelusa adicional puede ser sintaxis, pero también podría ser más palabras de las necesarias para transmitir significado. (Por supuesto, no muy pocos para permitir la ambigüedad tampoco)

• Cito la versión original ya que es la más concisa. :-)

Al final del día, cualquier cosa que sea 'diferente' hará que la gente grite. Me siento cómodo con la sintaxis de estilo C y, por lo tanto, estoy bien con otros lenguajes que comparten una sintaxis similar (C ++, Java, C #). Entonces tiendo a favorecer este estilo particular.

Las lenguas tienden a encontrar un equilibrio entre lo suficientemente descriptivo y no detallado.

Perl es un ejemplo de dónde puedes escribir código muy conciso. Para los no iniciados, el código escrito por un ninja de Perl es mágico.

COBOL es un ejemplo de demasiado detallado.

Una vez leí en alguna parte que una gran parte del debate detallado proviene de nuevos programadores versus viejos. La analogía utilizada fue que cuando aprendemos algo nuevo, nos contamos una "historia" para superarlo (piense en cuándo aprendió álgebra en HS). A medida que ganamos experiencia, vamos más allá de la necesidad de una historia que explique los componentes individuales y comprendamos una mayor cantidad. Nuestro código se vuelve más denso y conciso, con comentarios que solo explican los elementos necesarios, en lugar de reiterar lo que dice el código.

He descubierto que esto es cierto entre yo y un compañero de trabajo. Ella escribe código con muchos comentarios explicando cuáles son las líneas de código y muchos espacios en blanco. Si lo estoy leyendo, encuentro que solo puedo ajustar unas pocas líneas de código en una pantalla debido a esto. Eso hace que la comprensión de cada línea individual sea mucho más fácil, pero asimilar toda la función es mucho más difícil.

Tiendo a escribir código sin espacios en blanco o comentarios adicionales. Esto hace que ver todo sea mucho más fácil, pero debe poder simplemente "obtener" las "palabras" del código individual. Si trataste de leer esta respuesta con cada palabra en su propia línea, con muchos espacios en blanco / comentarios / verborrea adicional, entonces sería mucho más fácil entender cada palabra individual, pero mucho más difícil de entender el todo.

Einstein acertó: "Haga las cosas lo más simple posible, pero no más simple".

Esto también se aplica al código. Si puede simplificar el código eliminando elementos repetitivos y innecesariamente detallados, eso es algo bueno.

Además, algunos estudios de caso sugieren que la productividad del programador medida en líneas de código es más o menos constante. También lo es la cantidad de errores por LOC. Por lo tanto, cambiar a un idioma que le permita hacer más por línea de código puede considerarse una mejora de la productividad, si todo lo demás se mantiene igual.

Dicho esto, hay una tendencia en esta industria a diseñar en exceso y complicar lo que deberían ser cosas simples. Cosas simples como rellenar detalles de contacto en una base de datos relacional. He visto algunas soluciones ridículamente complicadas y equivocadas ( tos MDA) para ese problema en particular. Los lenguajes como Scala y Ruby son buenos ejemplos de herramientas poderosas que, en manos de ciertas personas, dan como resultado un código ininteligible, demasiado complicado y poco sostenible. El hecho de que pueda usar múltiples niveles de indirección con unos pocos golpes de tecla no significa que tenga que clavar cada clavo a la vista con ese martillo en particular.

Cuando se usa correctamente, obtienes un código limpio y agradable que es corto y fácil de entender. Cuando se usa mal, es mejor limitar al individuo en cuestión a usar visual basic o un lenguaje limitado de manera similar para evitar mayores daños.

La verdadera habilidad radica en hacer cosas complejas de una manera simple, no en hacer cosas simples de una manera complicada.

Algo que nadie más ha alcanzado es la cantidad de código que puede caber en una pantalla. Ayuda por varias razones:

• Menos desplazamiento hacia adelante y hacia atrás cuando trabajas (o lees) múltiples funciones en un archivo.
• Menos desplazamiento horizontal (detener la lectura, hacer clic y arrastrar la barra de desplazamiento, detener la lectura, hacer clic y arrastrar la barra de desplazamiento ...).
• Escaneo más rápido, ya que hay una sintaxis menos inútil que se interpone en el camino para encontrar lo que desea.

Porque más código significa más tiempos de desarrollo y más errores.

Si escribe 100 líneas de códigos en lugar de 300 líneas de códigos. Eso significa casi 1/3 de los tiempos de desarrollo que necesita y 1/3 de posibles errores que puede encontrar.

En la mayoría de las circunstancias, necesita equilibrar la eficiencia y la concisión, ya que escribir menos códigos significa que la máquina necesita hacer más cosas y disminuirá la eficiencia.

Por lo general, las personas prefieren los idiomas legibles / verbosos sobre los crípticos / concisos. Sin embargo, creo que la mayoría de las personas asimilaron "verbosidad" con "desorden", que no son lo mismo.

Por ejemplo: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

Es una declaración muy breve. Contiene todo lo que quieres saber. Sin embargo, debido a su brevedad, es difícil de entender. Por otro lado, una versión un poco más detallada del mismo programa sería bastante sencilla de entender porque es más legible. Por supuesto, esto no es una propiedad del lenguaje en sí, pero algunos lenguajes tienden a ser más verbosos, mientras que otros tienden a ser más concisos en su forma de programación.

Al otro extremo de la verbosidad, está http://en.wikipedia.org/wiki/Literate_programming , que considero un concepto bastante interesante.

Otro aspecto es la "verbosidad no deseada", también llamada "desorden". Cosas que debe agregar por razones técnicas, falta de azúcar sintáctica, API hinchadas, etc.

Creo que una sintaxis clara e intuitiva es muy importante. También tiene que ser lo suficientemente detallado como para facilitar una lectura fácil. Las declaraciones demasiado cortas con demasiada lógica a menudo pueden llevar a más tiempo para descifrar que sus contrapartes un poco más largas. Por otro lado, un código inflado inútil lleno de líneas repetitivas para hacer algo completamente simple es igualmente una molestia.

La verbosidad es una tendencia a usar grandes cantidades de texto, y en pocas palabras el uso de muy poco texto ...

La verbosidad es mala porque:

1. presenta más oportunidades de error tipográfico
2. hace que sea más difícil leer el código en la pantalla o papel, y / o ingresar en la tarjeta perforada
   1. esto aumenta los tiempos de depuración
   2. esto dificulta la comprensión del código para la actualización / mantenimiento
   3. Esto puede conducir a una duplicación de código no deseada
3. aumenta un poco la probabilidad de error de sintaxis
4. disminuye la flexibilidad de codificación, ya que la mayoría de los lenguajes detallados están altamente estructurados y no tienen múltiples formas de decir lo mismo.
5. aumenta los tiempos de codificación y compilación
6. Puede tomar más espacio de almacenamiento.

Sin embargo, un cierto nivel de verbosidad es esencial para la claridad ...

un nivel mínimo de verbosidad es bueno porque:

1. Es más fácil para los humanos leer y atribuir valor semántico que un código puramente simbólico
2. En los nombres de variables y funciones, facilita la depuración, el puerto y el mantenimiento del código
3. en operaciones de lenguaje de nivel base y palabras clave de idiomas complejos, conduce a menos operaciones incorrectas / asignaciones de palabras clave.

Algunos ejemplos maravillosos de comandos demasiado concisos para muchas personas incluyen los viejos modos BASIC de val(x$), str$(x)y chr$(x)... devuelven un número de su representación de cadena, devuelven una cadena para un número y devuelven un solo carácter que tiene un valor ascii x como cadena.

O el puntero C / C ++ y por operadores de referencia &y *contra la byrefpalabra clave BASIC . En C / C ++, puedo tener una variable X y pasar un puntero a esa variable, pero tengo que recordar cuál es el puntero y cuál es el "usar puntero como la variable a la que apunta"; en básico, simplemente paso la referencia con una palabra clave byref en la llamada a la función, que es más clara, pero menos flexible:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

En este código, el contenido de x se modifica debido al indicador byref. Algunos sabores permiten byref en llamada, otros en definición, algunos en cualquiera.

La verbosidad es importante para que los programadores casuales puedan usar el simbolismo más fácilmente; BASIC o python son más legibles para los humanos y más detallados que C / C ++, y por lo tanto mucho más útiles para programadores casuales; La brevedad de C / C ++ lo hace mucho mejor para los programadores más experimentados, que necesitan ver más código y código más complejo en una sola pantalla, pero han tenido que aprender las diversas convenciones de estructura simbólica. En el otro extremo está APL, que es casi completamente humano ilegible.

Un tema íntimamente relacionado es la claridad: el código breve a menudo no está claro, y el código excesivamente detallado (como en AppleScript) puede ser igualmente incierto. La familiaridad con un lenguaje dado aumenta la claridad del código conciso dentro de ese lenguaje: un principiante en bruto, que enfrenta el código C ++ es probable que pueda analizar solo las fórmulas, e incluso mucho código BASIC o Python funcional es demasiado conciso para la comprensión, pero AppleScript puede estar desconcertado, en general, sin recurrir a diccionarios de idiomas. Lo menos claro que he encontrado sin ofuscación intencional es Inform 7 ...

En los viejos tiempos

Otra consideración importante en el pasado, pero que ya no es tan importante para el codificador de pasatiempos, es el espacio de operación y almacenamiento. (Sigue siendo vital en el extremo superior). Teniendo en cuenta que se interpretaron muchos idiomas, especialmente los sabores BÁSICOS, y muchos más se compilaron en tiempo de ejecución, el espacio de código era importante, especialmente cuando los discos solo contenían 128 KB y las tarjetas perforadas individuales solo 80 B.

Existían varias soluciones: la tokenización era extremadamente común en BASIC; las palabras clave de idioma individuales se redujeron a una palabra de 1 o 2 bytes en el espacio superior de 128 o en el espacio de caracteres de control. La tokenización también conduce a la compilación de bytecode (como en Inform y la máquina Z).

La compilación y vinculación de archivos de objetos múltiples también se utilizó para sortear las limitaciones de espacio. Una sección de código Pascal de 100 KB puede compilarse a solo 5 KB; Al vincular múltiples archivos compilados, uno podría construir aplicaciones masivas sin tener acceso a unidades de gran formato (recordando que 10MiB era asombrosamente grande, y comprar un auto nuevo caro).

Sin embargo, los lenguajes más concisos obtuvieron más código en una porción dada de disco y ram, y así compilaron porciones más grandes a la vez. Teniendo en cuenta: las "minicomputadoras" de principios de la década de 1970 podrían tener solo 64KiB de ram (Honeywell 800 tenía una instalación base de 4 bancos cada uno de 2048 palabras de 8B cada una). APL y lenguajes simbólicos similares se acercaron a 1B por instrucción más sus operandos, en comparación con los 3B-10B mucho más grandes por instrucción más operandos. (Fue una pesadilla escribir en tarjetas perforadas, especialmente porque los símbolos eran esencialmente una fuente en type-ball, y muchos punzones no tenían los símbolos en las teclas ...)

Además, tenga en cuenta que las tarjetas no se pueden borrar ... y muchos programas se ingresaron en las tarjetas. Si bien no es costoso individualmente, cuanto más comprimido esté su código en la tarjeta, menos necesitará y más grandes serán los programas o menos costosos. Esto es parte de la razón por la que BASIC tiene una concatenación de múltiples instrucciones por línea en la mayoría de los sabores: se introdujo para ahorrar en tarjetas perforadas. (O eso dice mi texto de programación de Vax Basic). Si bien no he programado para un lector de tarjetas, he hecho la perforación de la tarjeta para un Honeywell 800 en FORTRAN, BASIC, APL y un par de otros lenguajes altamente simbólicos.

Como con tantas cosas, la respuesta depende de la definición concreta de "verbosidad". Si la definición es tal que la verbosidad implica redundancia, entonces diría que siempre es malo. Tenga en cuenta que con tal definición, el programa Java hello world que se cita a menudo no calificaría como "detallado", porque no hay nada en él que sea redundante.

Los programadores tienden a gustar los lenguajes con poder expresivo, ya que les permite codificar las cosas simples, que a menudo tienen que hacerse con frecuencia, en pequeños fragmentos de código. Los lenguajes detallados tienden a significar que se deben usar muchas, muchas líneas de código para hacer lo mismo una y otra vez. Sin embargo, puede haber un precio a pagar con lenguajes expresivos, ya que puede que no sean tan rápidos de ejecutar como los idiomas de alto nivel más simples. Si puedo dar un ejemplo en el contraste entre C y C ++. C ++ da más poder expresivo a los escritores de código: pueden encapsular la idea de objetos del mundo real en clases. Los programadores de C pueden lograr las mismas cosas, pero tienen el poder expresivo de la construcción de la clase para ayudarlos, por lo que a menudo tienen que escribir código más largo y más complicado (para comprender). Pero ese código puede ejecutarse más rápido (aunque esto depende en gran medida de la calidad del compilador, etc.) porque no utiliza el "enlace tardío" de C ++ (es decir, la refactorización del tiempo de ejecución) para ejecutar el código. C simplemente ejecuta el código compilado y vinculado, C ++ tiene que tomar una decisión (en ciertas circunstancias) en tiempo de ejecución sobre qué piezas de código ejecutar.

Creo que hay una respuesta a la pregunta basada en un tema más fundamental y teórico que la legibilidad y esta respuesta está relacionada con la teoría de la información algorítmica fundada por Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Dicho en pocas palabras, "el contenido de información de una cadena es equivalente a la longitud de la representación autónoma más corta posible de esa cadena", esto implica que el programa más corto (es decir, en términos de su longitud lexicográfica) resuelve un problema dado de cerca coincide con la complejidad intrínseca del problema al que da una solución y, por lo tanto, depende más de la naturaleza del problema y menos de la representación del problema.