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

98

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?

Fran Sevillano
fuente
20
¿Has estado codificando en APL recientemente?
SK-logic
55
Echa un vistazo a Idiomas, verbosidad y Java por Dhanji R. Prasanna
Jeremy Heiler
67
"Un desarrollador solo tiene una cierta cantidad de teclas
presionadas
10
Tal vez debería preguntarle a "muchas personas que se quejan" cuáles son sus razones.
Eric Lippert
29
@EricLippert, creo que P.SE es un lugar perfecto para consultar a un gran número de desarrolladores "quejándose".
Kevin McCormick el

Respuestas:

168

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
Nathan Long
fuente
20
Yo diría que lo último se trata de legibilidad a nivel micro (donde generalmente preferimos una notación más detallada), mientras que lo primero se trata de legibilidad a nivel macro (donde generalmente preferimos más brevedad)
jk.
67
Para cualquier programa que realmente haga algo, Java con frecuencia se vuelve mucho más legible, especialmente con un buen uso de la biblioteca.
99
en realidad, un mejor ejemplo de verbosidad a escala macro podría ser patrones que funcionen en torno a una característica de lenguaje que falta
jk.
21
Yo diría que ese ejemplo con Java tampoco es el mejor. Cosas como la necesidad de definir una clase y un método son importantes en el código golf, pero difícilmente en aplicaciones reales. No es que Java requiera mucho código para generar algunas palabras, estas pocas líneas son necesarias para crear un programa, y ​​eso es diferente.
Malcolm
27
+1 para la distinción entre Señal vs. Ruido y
Críptico
118

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.

Martin Beckett
fuente
19
Creo que esta es la razón final. Legibilidad en un espacio limitado como un trozo de papel o un monitor.
1
+1, y estoy completamente de acuerdo, y codifico en una computadora portátil de 13 ", pero nuevamente este sitio tiene 3 monitores como su logotipo ... debe estar algo relacionado :)
ZJR
1
@ZJR: ver edición.
Martin Beckett el
3
Entonces, ¿qué hace el setmétodo aquí? ¿Realmente establece algo (es decir, el primer xparámetro) o devuelve algo (es decir, la asignación a xdespués de la llamada)? Yo diría que hay una duplicación extraña en el ejemplo detallado.
Jesse C. Slicer
8
Una cosa que falta aquí es la utilidad de los ideógrafos: que los símbolos pueden ser más significativos que las palabras. Por ejemplo, +es más significativo que plus. =es mejor que equals. Esto, por supuesto, puede llevarse demasiado lejos (y ha sido en varios idiomas), pero cuando se usa con moderación, es muy poderoso.
mcmcc
29

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.

Oded
fuente
66
Trabajo principalmente en C #, pero cuando leo VB me parece que lo leo como si fuera C #. Ignoro todo If .. Then .. End Ify leo solo lo que es importante.
Andy Hunt
77
Igual que Andy. Encuentro ambos igualmente legibles. Incluso tendería a decir que prefiero una pequeña variante de VB (a pesar de que estoy más acostumbrado a c #).
Dagnelies
99
¡VB.NET no es detallado en comparación con otros delincuentes peores!
3
@AndyBursh - Exactamente mi punto. Al leer VB.NET, hace una traducción mental más allá de comprender el código.
Oded
66
Oded, End-If es una construcción mucho más fácil de entender para el final de una declaración if que los corchetes cuando los corchetes se anidan dentro de otra declaración if, dentro de un ciclo, dentro de otro ciclo, dentro de una función que está dentro una clase. Todos los bloques mencionados anteriormente usan los mismos corchetes, lo que significa que tratar de averiguar con cuál de ellos se corresponde un corchete final menos intuitivo.
Andrew Neely
27

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.

revs usuario7519
fuente
15
¿No querías return the 0cuando escribiste eso? AppleScript es el único lenguaje que conozco que les permite a sus oponentes expresar palabras clave ... Me refiero a compañeros de trabajo.
ccoakley
Applescript IDE, Editor de secuencias de comandos, en los años 90, solía ayudar a lidiar con verbosidad con la grabación de acciones de applecript , no era terriblemente inteligente, pero era muy útil mientras buscaba secuencias de comandos ... alrededor de 1998 la grabación se interrumpió y nunca más se reparó . (no sé si la transición a OSX solucionó eso, IIRC, no)
ZJR
3
La respuesta de OSX a la complicación de AppleScript es Automator. ¡Reemplacemos el texto fácil de escribir con una biblioteca gigante de bloques de funcionalidad arrastrables, descritos detalladamente y mal explicados!
esponjoso
Lo peor de AppleScript es que cada aplicación que desea manejar puede tener una terminología diferente. Apple define ciertos conjuntos de comandos que todos los programas deberían admitir, pero en general, saber cómo crear una secuencia de comandos de una aplicación solo es de ayuda limitada para crear otra.
poco
1
Applescript es engorroso de escribir, pero fácil de comprender para los humanos ... dentro de los límites de los programadores que ponen los ganchos de AppleScript con sintaxis inteligible en la aplicación controlada.
aramis
23

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.

Dan Diplo
fuente
No consideraría conciso lo contrario de lo detallado. Verbose tiene una connotación negativa, por lo que probablemente sería más adecuado para un antónimo con una connotación positiva.
Joshua Drake
66
tersees el antónimo de verbose, tersepuede llevar la misma connotación negativa (ver Perl)
1
@JarrodRoberson: Odio ser pedante el viernes por la noche de todas las cosas, pero busqué algunos tesauros en línea y ninguno de ellos tiene tersecomo antónimo de verbose(o viceversa). / patos
Scott Mitchell
1
@ScottMitchell en.wiktionary.org/wiki/terse#Antomains
naught101
15

@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.

Terry Bollinger
fuente
8

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.

Jerry Coffin
fuente
6

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. :-)
MathAttack
fuente
5

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.

Nasir
fuente
55
¿Cómo responde esto a la pregunta?
ChrisF
la verbosidad es diferente para todos. Esa fue la intención de mi comentario. Si está en el campamento C / C ++, la verbosidad aceptada es diferente en comparación con si está en el campamento perl.
Nasir
El código escrito por un perl ninja es mágico? En serio, creo que es una pesadilla.
Kevin
Me mantengo alejado de Perl :)
Nasir
Para los programadores, COBOL puede ser demasiado detallado en comparación con otros idiomas. Sin embargo, COBOL bien escrito puede ser fácil de leer para los clientes comerciales. Esto les permite verificar que el código hace lo que requieren al leerlo.
BillThor
4

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.

Spencer Rathbun
fuente
Nadie en contra de los comentarios. El problema son los lenguajes como Java, AppleScript o Visual Basic, que tienen muchos elementos redundantes pero obligatorios.
Marcin
2
@ Marcin No estoy en contra de los comentarios, pero cuando son así: i++; //this is adding one to var ies redundante.
Spencer Rathbun
Sin embargo, la pregunta es sobre lenguajes de programación.
Brendan Long
2
@BrendanLong Hmm, tal vez no estaba claro. Estaba equiparando comentarios innecesarios con lenguajes de programación detallados. Muchas palabras para decir lo mismo, solo un lenguaje de programación detallado las requiere en todo momento.
Spencer Rathbun
Se podría argumentar que una función no debería consistir en más de unas pocas líneas de todos modos. Si es difícil comprender cómo funciona la función, probablemente no se deba a demasiados comentarios. Pero estoy de acuerdo en que los comentarios que solo dicen lo que está claro de todos modos deberían evitarse mejor.
Leftaroundabout
4

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.

Jilles van Gurp
fuente
3

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.
Brendan Long
fuente
¿realmente cuánto desplazamiento se realiza en una pantalla de 1920 X 1080 con un tamaño de fuente razonablemente legible? También hay estas cosas llamadas atajos de teclado para la navegación en ambos sentidos.
@JarrodRoberson: mi pantalla muestra aproximadamente 30 líneas. Si hago que la ventana de código aparezca en pantalla completa y reduzco el tamaño de la fuente para que apenas se pueda leer, obtengo 60 líneas. He tenido que trabajar en varios miles de archivos de línea (no por elección, se lo aseguro). Utilizo el "navegador" en mi IDE, pero todavía no es tan conveniente como mirar entre dos secciones de código que están en la pantalla.
Brendan Long
¿Su IDE no admite vistas divididas?
Leftaroundabout
2
Ambos están perdiendo el punto: si mi IDE puede hacer que el desplazamiento sea menos malo , nunca será tan bueno como no tener que desplazarse (o usar teclas de acceso rápido o pantalla dividida) . Es como decir "Los teclados en pantalla están bien, ¿nunca has oído hablar de hacer clic en las cosas?"; Obviamente lo tengo, pero no supera tener un teclado real.
Brendan Long
Recuerdo vagamente que en realidad hay estudios que demuestran que esto es cierto (particularmente la parte de desplazamiento). Tener que desplazarse para ver una unidad lógica completa hace que sea más difícil de comprender. Suena plausible, por lo menos.
Konrad Rudolph
1

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.

Fang Zhou
fuente
2
Esperaría muchos más errores ocultos en 100 líneas típicas de Perl que en 300 líneas de Ada. - En cuanto a "dado que escribir menos códigos significa que la máquina necesita hacer más cosas y disminuirá la eficiencia", puede haber tal correlación pero no es causalidad. Es solo que los lenguajes dinámicos y / o interpretados breves como Ruby, Perl y Python tienden a ser más lentos que los lenguajes compilados estáticos más detallados como C o Fortran. Sin embargo, los programas Haskell compilados, Python w / PyPy o C ++ pueden ser mucho más rápidos que los verbosos, por ejemplo, el código Basic, Groovy, Smalltalk o incluso C # interpretado.
Leftaroundabout
1

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.

arnaud
fuente
44
Es posible que desee verificar dos veces el [significado de conciso] ( en.wiktionary.org/wiki/concise ), ya que es casi un antónimo de críptico. ¿Quizás codificas en Java?
Joshua Drake
2
Prefiero código detallado escrito en idiomas concisos.
Brendan Long
@ Joshua: sí, noté que se puede interpretar de maneras muy diferentes, así que edité mi respuesta. ... y qué tiene que ver java con eso?
Dagnelies
1
Un comentario para indicar por qué fue rechazado puede ser más interesante que el voto negativo en sí.
Dagnelies
@arnaud, mi mal por usar wiktionary. La búsqueda de Google define: conciso comienza: "Dando mucha información claramente", que su código de muestra viola claramente. Aunque tengo que reconocer la implicación original de conciso, claro y conciso ahora viajan juntos.
Joshua Drake
1

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.

aramis
fuente
La verbosidad en muchos casos aumenta la probabilidad de que se detecten errores tipográficos en tiempo de compilación en lugar de simplemente generar un comportamiento erróneo.
supercat
-1

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.

Ingo
fuente
1
Los corchetes y los puntos y comas equilibrados son redundantes, como en gran medida las declaraciones de tipo.
Marcin
1
@ Marcin: Sí, pero hacen que escribir un analizador / analizador para el idioma sea más fácil. Estoy bastante convencido de que dicha sintaxis existe en beneficio del implementador del lenguaje, no del programador que usa el lenguaje.
ccoakley
1
@Marcin: depende completamente del idioma si las declaraciones de tipo son o no necesarias. Ciertos sistemas de tipos simplemente no son decidibles, por lo tanto ... con respecto a los corchetes y los puntos y comas, bueno, preferiría un lenguaje con una gramática inequívoca y una breve búsqueda anticipada, o compilar incluso programas pequeños podría llevar horas y al final tienes que elegir qué interpretación de tu programa prefieres.
Ingo
1
@ingo No conozco ningún lenguaje en el que todas las variables o funciones deben tener una declaración de tipo debido a la complejidad del sistema de tipos. De hecho, diría que es más probable que los lenguajes con sistemas de tipos más potentes permitan omitir tales declaraciones.
Marcin
1
@ Marcin, no hay razón para enojarse. Usted dijo que diría que es más probable que los lenguajes con sistemas de tipos más potentes permitan omitir tales declaraciones y le di un ejemplo, donde un sistema de tipos más potente requiere más anotaciones de tipo. Si siente que eso no contradice su stetement, entonces bueno, que así sea.
Ingo
-1

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.

adrianmcmenamin
fuente
Con este "enlace tardío" probablemente se refiera a llamadas a funciones virtuales. Pero esa es solo una forma entre muchas otras para lograr la reutilización del código. La escritura dinámica es otra, y probablemente sería un mejor ejemplo para su punto, ya que tiende a venir con mucha más sobrecarga que las llamadas virtuales de C ++. Pero también hay mecanismos que no afectan en absoluto el rendimiento del tiempo de ejecución porque pueden resolverse por completo en el momento de la compilación: en los lenguajes modernos orientados a objetos tiene plantillas / genéricos, en lenguajes funcionales estáticos polimorfismo paramétrico.
Leftaroundabout
El enlace tardío es lo que se utiliza para hacer que funcionen las llamadas de función virtual, así que no, no me refería a "llamadas virtuales", me refería al enlace tardío. Las llamadas virtuales son parte de la definición del lenguaje, el enlace tardío es lo que hace que esa parte funcione. Y sí, por supuesto, hay otros ejemplos en otros idiomas, estaba ofreciendo un ejemplo del potencial de intercambio entre el poder expresivo y la velocidad, no recomendando un idioma sobre otro.
adrianmcmenamin
-1

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.

Daniel
fuente