Vamos por partes, dijo Jack...
Cita: Yo creo estas cosas:
1. Que todo puede tener su lugar, y diferentes estilos tienen tanto diferentes inconvenientes como diferentes ventajas.
Esteee.. sí, igual no dijiste nada con sustancia
Cita: 2. Que las closures son exactamente lo mismo que los objetos.
Ese es el "buen punto" que muchos argumentan: para que hacer más confuso los diseños si ya contamos con objetos y esto se puede hacer con ellos?
Cita: 3. Que el hecho de mantener un código legible, ordenado y consistente es independiente del estilo/paradigma utilizado.
Mmm... sí, pero en "nuestro contexto", creo que nos estamos ahogando en nuestra propia "flexibilidad", ya que para ser tan "libres" debemos ser metódicos, ordenados, fundamentados, con una buena base teórica y conceptual... algo que en el mundo PHP carecemos completamente (culturalmente hablando).
Cita: 4. Que es muy ingenuo desestimar un lenguaje, un paradigma o un tipo de construcciones sólo porque se ha visto mal utilizado alguna vez o porque uno no le encuentra uso (o no comprende para qué se puede usar).
Las generalizaciones son injustas. No soy ingenuo y comprendo lo que se está planteando y tengo argumentos para afirmar que tanta flexibilidad nos va a causar más daño que beneficio.
A las pruebas me remito (con solo ver las preguntas de los foros, los proyectos realizados enteramente en PHP, etc).
Cita: 5. Que en Java la discusión sobre closures se centra en dos problemas: el soporte en sí y la sintaxis. Y el principal problema es la sintaxis, porque Java ya viene teniendo una serie de nuevas sintaxis que están haciendo que el código parezca cada vez más ofuscado (no querría imaginarme usar generics en una closure xD)
Por lo que yo tengo entendido, no, justamente el punto más polémico si la existencia de los "closures" generarán violaciones a los principios de diseño (otros ya comentan que está sucediendo con otro tipo de construcciones).
Cita: 6. Que la OO no es el único paradigma que permite tener el código ordenado. La programación funcional es limpia y ordenada.
Descontando la POO, todo lo demás está o en camino a estar "fuera de uso".
Cita: 7. Que en determinadas situaciones es aceptable fijarse como objetivo número uno hacer el código tan simple que cualquier programador sin experiencia pueda entenderlo. Pero en otras situaciones es igual de aceptable exigir un determinado esfuerzo o experiencia para comprender un código.
Nadie dice que uno debe codificar por los novatos, lo que se sugiere es mantener la complejidad lo más baja posible para que todos puedan entender lo que se está haciendo ("la mejor arquitectura es la simplicidad"), más si estamos hablando que los proyectos son generalmente "trabajos en equipo".
Si vamos a pasar la mayor parte del tiempo manteniendo sistemas, debemos construir pensando en evitar la complejidad innecesaria. Hacer una línea de código no es mejor que cuatro si queda más claro (algo muy habitual en los programadores, piensan que "cuanto menos es más" y en realidad "cuanto menos es menos").
Alguien dijo una vez:
"si testear es el doble de difícil que codificar, no hagas código dificil... ya que será imposible testearlo" (no es literal, así la recuerdo).
Cita: 8. No existe One True Way (tm).
De acuerdo, pero hay tendencias y corrientes claras (por lo menos dos).
Cita: Por otra parte hay algo que no tengo claro del todo. Enriqueplace: ¿Estás en contra de las closures o incluso del simple uso de funciones anónimas y/o de la programación funcional?
Pensé que a esta altura era evidente...de todo eso!