legibilidad de programación funcional [cerrado]

12

Tengo curiosidad por esto porque recuerdo que antes de aprender cualquier lenguaje funcional, los consideré horriblemente, terriblemente, terriblemente ilegibles. Ahora que conozco a Haskell y f #, creo que se necesita un poco más de tiempo para leer menos código, pero ese pequeño código hace mucho más que una cantidad equivalente en un lenguaje imperativo, por lo que se siente como una ganancia neta y no soy extremadamente Practicado en funcional.

Aquí está mi pregunta, constantemente escucho de la gente de OOP que el estilo funcional es terriblemente ilegible. Tengo curiosidad por saber si este es el caso y me estoy engañando, o si se tomaron el tiempo para aprender un lenguaje funcional, ¿el estilo completo ya no sería más ilegible que la POO?

¿Alguien ha visto alguna evidencia o ha obtenido alguna anécdota en la que haya visto que esto sucediera de una manera u otra con la frecuencia suficiente como para decirlo? Si escribir funcionalmente es de una menor legibilidad, entonces no quiero seguir usándolo, pero realmente no sé si ese es el caso o no ...

    
pregunta Jimmy Hoffa 02.09.2012 - 07:45

5 respuestas

14

La legibilidad del código es muy subjetiva . Debido a esto, diferentes personas considerarían el mismo código como legible o ilegible.

Una asignación, x = x + 1 suena raro para un matemático, porque una asignación parece engañosa similar a una comparación.

Un patrón de diseño de OOP simple sería totalmente incierto para alguien que no esté familiarizado con estos patrones. Considere singleton . Alguien preguntaría "¿Por qué necesito un constructor privado? ¿Cuál es el método misterioso getInstance() ? ¿Por qué no creamos una variable global y asignamos un objeto allí?"

Lo mismo se aplica a un código de FP. A menos que sepa los patrones lógicos detrás de escena, será muy difícil incluso entender algo muy básico, por ejemplo. cómo pasar una función como argumento a otra función.

Habiendo dicho esto, uno debe entender que el FP no es una bala de plata. Hay muchas aplicaciones en las que la PF sería difícil de aplicar y, por lo tanto, dará lugar a un código legible peor .

    
respondido por el bytebuster 02.09.2012 - 13:11
11

Respuesta corta:

Uno de los elementos que hacen que la gente diga que el código de programación funcional es difícil de leer es que da preferencia a una sintaxis más compacta.

Respuesta larga:

La programación funcional en sí misma no puede ser legible o ilegible, ya que es un paradigma, no un estilo de escritura de código. En C # por ejemplo, la programación funcional se ve así:

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

y cualquier persona con experiencia suficiente en Java, C # o lenguajes similares lo considerará legible.

La sintaxis del idioma, por otro lado, es más compacta para muchos idiomas funcionales (incluidos Haskell y F #) en comparación con los lenguajes OOP populares, dando preferencia a los símbolos en lugar de palabras en un lenguaje sencillo.

Esto también se aplica a idiomas fuera de FP. Si comparas los idiomas OOP populares con algunos menos populares que tienden a usar más palabras en inglés, las últimas se sentirían más fáciles de entender para las personas sin experiencia en programación.

Comparar:

public void IsWithinRanges<T>(T number, param Range<T>[] ranges) where T : INumeric
{
    foreach (var range in ranges)
    {
        if (number >= range.Left && number <= range.Right)
        {
            return true;
        }
    }

    return false;
}

a:

public function void IsWithinRanges
    with parameters T number, param array of (Range of T) ranges
    using generic type T
    given that T implements INumeric
{
    for each (var range in ranges)
    {
        if (number is from range.Left to range.Right)
        {
            return true;
        }
    }

    return false;
}

De la misma manera:

var a = ((b - c) in 1..n) ? d : 0;

podría expresarse en un lenguaje imaginario como:

define variable a being equal to d if (b minus c) is between 1 and n or 0 otherwise;

¿Cuándo es mejor la sintaxis más corta?

Si bien una sintaxis más detallada es más fácil de entender para un principiante, una sintaxis más compacta es más fácil para los desarrolladores experimentados. Un código más corto significa menos caracteres que escribir, lo que significa más productividad.

Especialmente, realmente no tiene sentido forzar a una persona a escribir una palabra clave para indicar algo que puede deducirse de la sintaxis.

Ejemplos:

  • En PHP, debe escribir function antes de cada función o método, sin ninguna razón específica para hacerlo.

  • Ada siempre me horrorizó por obligar a los desarrolladores a escribir muchas palabras en inglés, especialmente porque no hay un IDE correcto con autocompletar. No he usado Ada recientemente y su tutorial oficial está caído, así que no puedo dar un ejemplo. Si alguien tiene un ejemplo, siéntase libre de modificar mi respuesta.

  • La sintaxis 1..n , utilizada en muchos FP (y Matlab), podría reemplazarse por between 1, n o between 1 and n o between (1, n) . La palabra clave between hace que sea mucho más fácil de entender para las personas que no están familiarizadas con la sintaxis del idioma, pero aún así, dos puntos son mucho más rápidos de escribir.

respondido por el Arseni Mourzenko 02.09.2012 - 13:45
6

Creo que una de las razones es que la programación funcional tiende a funcionar con conceptos mucho más abstractos. Esto hace que el código sea más corto y más legible para las personas que conocen y comprenden los conceptos (porque expresan adecuadamente la esencia del problema), pero es ilegible para las personas que no están familiarizadas con ellos.

Por ejemplo, para un programador funcional es natural escribir un código que puede fallar en diferentes puntos dentro de la mónada Maybe , o la mónada Either . O, para escribir un cálculo con estado con la ayuda de la mónada State . Pero para alguien que no entiende el concepto de mónadas, todo esto parece una especie de hechicería negra.

Así que creo que sería razonable usar bits de programación funcional incluso en un equipo de personas de POO, siempre y cuando uno use conceptos que sean fáciles de entender o aprender, como mapear una colección con una función o cierres .

(Y, por supuesto, también depende del programador que escribió algún fragmento de código. Puede escribir código terriblemente ilegible en cualquier idioma, así como escribir en un estilo agradable y limpio).

    
respondido por el Petr Pudlák 02.09.2012 - 09:06
2

La legibilidad no tiene nada que ver con los paradigmas, modelos y demás. Cuanto más código refleja la semántica de su dominio de problemas, más opera una terminología e idiomas de dicho dominio de problemas, más legible es.

Esta es la razón por la que el código OOP no es tan legible: no es que muchos problemas del mundo real se expresen naturalmente en términos de taxonomías jerárquicas. Los objetos que se pasan unos a otros son un concepto extraño, y está muy lejos de ser algo "real". Sorprendentemente, hay muchos más conceptos del mundo real que pueden asignarse naturalmente a los lenguajes funcionales. Los problemas tienden a definirse declarativamente, por lo tanto, una solución declarativa es más natural.

Aunque, hay muchas otras semánticas que podrían estar más cerca del mundo real que una OOP puramente funcional, pura, flujo de datos puro o cualquier cosa que sea. Y debido a este hecho, un enfoque orientado al lenguaje para la resolución de problemas produce el código más legible, superando todos los paradigmas "puros" existentes. Con los lenguajes específicos del dominio, cada problema se expresa en su propia terminología natural. Y los lenguajes funcionales son un poco mejores que los elementos principales de la programación orientada a objetos para facilitar la implementación de los DSL (aunque hay muchos enfoques mejores disponibles).

    
respondido por el SK-logic 02.09.2012 - 14:03
1

La legibilidad del código es subjetiva. Estoy seguro de que algunas personas lo critican por falta de comprensión. Naturalmente, hay diferentes modismos en la forma en que se implementan los patrones comunes. Por ejemplo, el patrón de visitante realmente no tiene sentido en un idioma con coincidencia de patrón .

La inferencia de tipos puede ser una característica difícil. Por lo general, es un gran acelerador del desarrollo, sin embargo, a veces puede ser difícil averiguar qué tipos están involucrados debido a la falta de contexto que conduce a errores confusos. Esto no se limita a los lenguajes de programación funcional, ¡también lo he visto en plantillas de C ++!

Los idiomas modernos tienden a ser multi-paradigma . Esto incluye tanto C # como F #. Es posible escribir un estilo funcional en C # y un estilo imperativo en F #. Las mismas personas que critican los lenguajes funcionales probablemente escriban código funcional en su lenguaje orientado a objetos.

El desarrollo comercial en lenguajes funcionales todavía es relativamente inmaduro. He visto una serie de errores cometidos que se considerarían de mala forma en cualquier idioma. Tales como:

  1. Cambiar el estilo a medida que aprendes el idioma (y no la refactorización) lo que lleva a una inconsistencia.
  2. Demasiado en un archivo.
  3. Demasiadas declaraciones en una línea.
respondido por el Dave Hillier 02.09.2012 - 14:00

Lea otras preguntas en las etiquetas

Comentarios Recientes

No ++ compatibilidad con argumentos basados en atributos No se encontró precedencia del analizador Referencias 2.11.1.2 El estilo de las constantes "planas" del estilo Java utilizadas en los "efectos" que utilizan la precedencia del operador Algunas comparaciones de igualdad del estilo Perl HTML 5 no se puede definir Ninguno dado por las pruebas 0 restricciones Cadenas verdaderas descarte Elaborado análisis / scripting Soporte RFC 19826: RFC actual como publicado Hackin 'actual Docman: Redacción (sujeto a cambios)... Lee mas