Como nuestros lenguajes imperativos favoritos ganan constructos funcionales, ¿deberían considerarse los bucles como un olor a código?

Question

En alusión a las impresiones de Dare Obasanjo en Map, Reduce, Filter (Functional Programming in C# 3.0: How Map/Reduce/Filter can Rock your World) "Con estos tres bloques de construcción, podría reemplazar la mayoría de los bucles de procedimiento en su aplicación con una sola línea de código. C# 3.0 no solo detente ahí."

¿Deberíamos usarlos cada vez más en lugar de bucles? ¿Y debería haber loops (en lugar de esos tres componentes básicos de manipulación de datos) para ser una de las métricas para codificar horrores en las revisiones de código? ¿Y por qué?

[NOTA] No estoy abogando por la programación de todas las funciones en esos códigos que podrían ser simplemente traducen a los bucles (por ejemplo. Recurrencias cola)

La solicitud de politer plazo. Teniendo en cuenta que la frase "olor a código" no es tan diplomática, publiqué otra pregunta https://stackoverflow.com/questions/432492/whats-the-politer-word-for-code-smell sobre la palabra correcta para "olor a código", er ... código completamente incorrecto. ¿Debería esa frase ocupar un lugar en nuestro lenguaje de programación?

Answer 1

Cambiemos nuestra actitud tradicional hacia la construcción de programas: en lugar de imaginar que nuestra tarea principal es instruir a una computadora sobre qué hacer, concéntrese en explicar a los seres humanos lo que queremos que haga una computadora.

- Donald Knuth

Answer 2

¿Por qué? ¡Voto absolutamente no!

Este tipo de bucle:

for x in list: 
    .... 

es aceptable, y no hay nada horrible al respecto.

Answer 3

historia de la lengua probablemente afecta esto: si el lenguaje X tenía una 'foreach' construir hasta ahora, la mayoría de los programadores se acostumbra a ella. Puede tomar un tiempo para que cambie el idioma, si es que lo hace.

Answer 4

¿Podemos encontrar una palabra más educada que 'oler'? La frase "código de olor" debe reservarse para lo que se pretende: fuertes pistas de que algo ha sido mal codificado. Lo que tenemos aquí es una suave pista de que puede haber oportunidades para el refinamiento.

El hecho de que tenga acceso a las operaciones de asignación/reducción/filtro significa que muchos bucles en las colecciones son una oportunidad para refactorizar. Puede obtener un código ligeramente más compacto y legible (siempre que el lector comprenda los conceptos). Es posible que obtenga un mejor rendimiento en el futuro, si se encuentra en una plataforma que puede paralelizar tales operaciones.

Sin embargo, siempre habrá situaciones en las que un bucle realmente significa un bucle. Desea hacer las cosas en secuencia, y la sintaxis del bucle es la forma más clara de escribir eso.

while(c=getchar) { 
    // see? 
} 

Answer 5

Seguramente no se recomienda muy encarecidamente el uso de bucles cuando se utiliza un lenguaje como APL, o cualquier otro idioma de forma natural diseñado para trabajar directamente con matrices (de vectores unidimensionales a hypercubes) sin tener que tratar de forma iterativa con cada uno elemento. Piensa en agregar 2 matrices: en matemáticas simplemente escribirías M1 + M2, ya que cualquiera lo programaría en APL; escribir un ciclo para esto es una mala programación.
C# está empezando a tomar prestadas algunas características muy potentes que hacen que APL sea tan eficiente como Reduce (f/AVector donde el operador f se aplica entre cada elemento de AVector como AVector 1 f AVector [2] f ... f AVector [n]) o tomar ...

Answer 6

No creo que debamos renunciar a los bucles en absoluto. Si miras lo que dice Dare, él tampoco recomienda eso. Después de todo, casi todos los métodos en la clase Enumerable y en LINQ se enfocan en devolver una implementación de IEnumerable.

Todo está hecho para ser repetido.

Lo que él está tratando de decir es que ahora podemos tener una separación mucho más clara de código con LINQ, ya que podemos filtrar, transformar y mapear elementos en una enumeración mucho más fácilmente fuera de un bucle de una manera más declarativa manera, en lugar de ofuscar el propósito del propio bucle, que generalmente actúa sobre un conjunto de esos elementos filtrados, transformaciones y mapas.

Answer 7

He programado smalltalk hace 15 años. Recuerdo bastante, pero ni siquiera puedo recordar si smalltalk tenía para cada iteración (por lo que no podría haber sido muy importante). Como estamos reinventando/redescubriendo todo esto otra vez, creo que la historia tiene la respuesta.

Answer 8

@grettke: ¡+1 por esta cita de Knuth!

Todas las construcciones que tenemos (bucles, recursión, goto, regex reemplazos, llamadas a funciones, ...) se pueden utilizar con prudencia o se pueden utilizar indebidamente para escribir código completamente oscuro. Prohibir a uno de ellos sería inútil.

Las vistas dogmáticas como "todo es una función", "todo es un objeto", etc. son más dañinas que útiles. Uno terminaría encajando a la fuerza en un esquema predefinido que sacrificaría la claridad (esa debería ser la principal preocupación al escribir código).

¿Es una "construcción de bucles" profundamente anidada cuando se puede usar una "concatenación de llamadas a función" más simple? ¡SÍ!

¿Es una "recursiva recursiva" de llamada de función "mala" cuando se puede usar un "bucle" más simple? ¡SÍ!

Así que, por favor, dame la libertad de usar lo que siento mejor para expresar lo que quiero decir en mi código y culparme por el desastre, ¡no por el idioma!

Answer 9

Depende. Si el for-loop expresa con precisión la intención del código: "haz estas cosas en este orden particular, uno a la vez", entonces todo está bien.

Por otro lado, si realmente quiso decir "hacer estas cosas sin un orden en particular, y está bien hacer más de una a la vez", entonces realmente quería algo funcional (por ejemplo, LINQ paralelo).