"Novedades para PHP 5.3: namespaces, closures, Phar"

[enriqueplace]

Veo esta noticia hoy, y la verdad que muy interesante la lista de agregados para la versión 5.3... el punto es, no estoy de acuerdo con algunos de ellos, como ser los "closures", pero si me alegra y sorprende que agreguen los "phar" (tipo .jar de java).

Pero bueno, la idea es no quedarse quieto tampoco

[GatorV]

Muy buena noticia, ya quiero que saquen PHP 5.3, va a ser muy divertido estar probando y migrando las cosas.

Yo si estoy de acuerdo con los "closures", ya que bien usados se pueden utilizar para cosas muy acertadas.

Saludos.

[enriqueplace]

Qué quieres que te diga, my friend, "sé como el agua"... pero potable, no turbia.

[GatorV]

No se me ocurre algún buen ejemplo, pero si recuerdo haber necesitado que PHP dispusiera de cosas así (como Javascript) al resolver ciertos problemas, pero deja meditar en un ejemplo clave y con gusto lo comparto.

[enriqueplace]

Por este tema también están discutiendo si incorporarlo o no en Java; argumentan que su uso terminará haciendo daño cualquier diseño POO.

Sigo pensando que la necesidad de este tipo de "salidas" lo único que hace es romper los diseños. Habría que ver bien cuando se justificaría, pero obviamente habrá abuso de su uso, para variar, y no creo que aporte a nuestro contexto (PHP, mal uso de POO, etc).

[GatorV]

Mmm si en efecto, ahora que lo pienso por ejemplo hay códigos en Python que son dificiles de leer por lo mismo pero sin embargo son muy funcionales, (y rapidos).

Habría que justificar perfectamente el cambio.

[venkman]

Yo creo estas cosas:

1. Que todo puede tener su lugar, y diferentes estilos tienen tanto diferentes inconvenientes como diferentes ventajas.
2. Que las closures son exactamente lo mismo que los objetos.
3. Que el hecho de mantener un código legible, ordenado y consistente es independiente del estilo/paradigma utilizado.
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).
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)
6. Que la OO no es el único paradigma que permite tener el código ordenado. La programación funcional es limpia y ordenada.
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.
8. No existe One True Way (tm).


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?

[vb2005]

lo de los phar creo que es genial, ya que podemos reducir todo en un solo archivo, para asi tener todo más "ordenado"

[Mort20]

Vaya, qué gran noticia lo de los namespaces. Yo que programo tanto en C++ como en PHP anda que no los echo en falta

Lo de los Phar en un principio también parece fantabuloso pero soy muy escéptico: hasta que no lo vea no me lo creo XDDD

Y lo de las Closures, yo no las voy utilizar pero, ¿porqué no permitir esa opción? Qué cada cual programe como quiera.
Y yo no las utilizaré porqué creo que ofuscan bastante el código, aunque todo depende del uso que se haga, muchas veces he visto casos de uso y abuso del tema quedando unas funciones con extensos parámetros de montones de funciones y.... bueno, es casi ilegible. Aunque por supuesto, si esas cosas se separasen que se puede hacer sin problemas y al final la closure sólo quedara con 1 o 2 funciones simples, entonces ya no sería tanta la ofuscación. Aunque a mi parecer seguiría siendolo.

Como siempre, todo depende del uso que se haga de las cosas. Pero por tener la opción, que la haya! XDD Contra más opciones mejor.

[enriqueplace]

Vamos por partes, dijo Jack...

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

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?

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

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

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

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

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

8. No existe One True Way (tm).

De acuerdo, pero hay tendencias y corrientes claras (por lo menos dos).

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!

[venkman]

Esteee.. sí, igual no dijiste nada con sustancia

Quizá un día le encuentras algo de sustancia, pero gracias por intentarlo. De todos modos aclaro que no todo lo que decía iba necesariamente referido a ti :)


Que closures y objetos sean lo mismo no quiere decir que se pueda hacer lo mismo con un sistema funcional y con uno orientado a objetos. Son morfológicamente equivalentes a algunos niveles, pero en un sistema funcional, las funciones tienen la misma entidad que los objetos. En uno completamente orientado a objetos no es así. En uno priman los verbos, en otro los nombres. Que se pueda hacer lo mismo no quiere decir que se pueda hacer igual.

Tú no serás ingenuo y comprenderás los temas, sin embargo lanzas proclamas como que cualquier otra cosa que no sea OOP está en desuso o cayendo en desuso. Es extraño entonces que lenguajes como Haskell estén no sólo ganando empuje sino atrayendo tanta atención. O precisamente que exista este resurgimiento de la orientación funcional en muchos lenguajes y entornos.

No, no serás ingenuo, pero ciertamente pareces no querer salir de tus ideas preestablecidas.

algo que en el mundo PHP carecemos completamente (culturalmente hablando).

El problema ahí es doble. Por un lado que, efectivamente en el mundo PHP se caece de esta cultura. Pero por otro lado, el problema está en que algunos precisamente lo prefieran así.

Me explico. Tú hablas de escribir lo más simple posible (a lo que yo añadiría "pero no más") para que todo el equipo y/o futuros desarrolladores lo puedan entender y mantener. Pero digo yo... ¿acaso no les deja eso estancados para siempre en ese nivel? ¿Acaso no sería preferible solucionar el problema aumentando el nivel, enseñando a la gente?

El problema de la programación funcional y de la closures no es otro que el de hacer un esfuerzo inicial por pensar de otro modo. Claro, si lo que se quiere es mantener siempre el mínimo esfuerzo intelectual posible, pues estupendo. Sin embargo, no conteis conmigo.

De acuerdo, pero hay tendencias y corrientes claras (por lo menos dos).

Sí, y te diré que la programación funcional es una tendencia clara. Más aún te diría que ahora mismo hay más gente utilizando lenguajes con capacidades funcionales que sin ellas. Pero el asunto no es ese. El asunto es que esa frase tuya, lo único que hace es restringirte.
No hay una única forma de hacer las cosas - digo yo. Y tú, con tu frase lo que pareces matizar es "sí, pero todas son malas menos esta" (o estas dos, si prefieres). Y la realidad no es así. La realidad es que esta ciencia es todavía tremendamente joven y por ahora todas las formas de hacer las cosas tienen ventajas e inconvenientes y se pueden usar bien y se pueden usar mal. Y es aún muy pronto para desestimarlas completamente. Es más, es aún muy pronto para decir que ya hemos encontrado la forma buena de hacerlo.

[enriqueplace]

Iniciado por venkman

Quizá un día le encuentras algo de sustancia, pero gracias por intentarlo. De todos modos aclaro que no todo lo que decía iba necesariamente referido a ti :)

Me preocupa que tan rápidamente pases de discutir sobre conceptos a atacar directamente mi persona.

Si esto es una nueva competencia de "¿quién se cree que sabe más?", directamente paso, no compito, me parece innecesario (no tengo la necesidad de demostrar nada a nadie).

Tú no serás ingenuo y comprenderás los temas, sin embargo lanzas proclamas como que cualquier otra cosa que no sea OOP está en desuso o cayendo en desuso. Es extraño entonces que lenguajes como Haskell estén no sólo ganando empuje sino atrayendo tanta atención. O precisamente que exista este resurgimiento de la orientación funcional en muchos lenguajes y entornos.

Bien, avisame cuando desarrollen el primer sistema comercial con ese paradigma y retomamos la discusión.

No, no serás ingenuo, pero ciertamente pareces no querer salir de tus ideas preestablecidas.

No estoy de acuerdo con tus ideas, pero defiendo tú derecho a expresarte. Las ideas "preestablecidas" que hablas se desprenden claramente del mercado actual.

Me explico. Tú hablas de escribir lo más simple posible (a lo que yo añadiría "pero no más") para que todo el equipo y/o futuros desarrolladores lo puedan entender y mantener. Pero digo yo... ¿acaso no les deja eso estancados para siempre en ese nivel? ¿Acaso no sería preferible solucionar el problema aumentando el nivel, enseñando a la gente?

Estás agregando cosas que no dije. "Codificar complicado" para demostrar "cuanto sé" es un problema de ego, pero sumamente contraproducente para el desarrollo de un proyecto y el trabajo de un equipo.

El problema de la programación funcional y de la closures no es otro que el de hacer un esfuerzo inicial por pensar de otro modo. Claro, si lo que se quiere es mantener siempre el mínimo esfuerzo intelectual posible, pues estupendo. Sin embargo, no conteis conmigo.

Muy probablemente serás un "franco tirador que trabaja en solitario".

Sí, y te diré que la programación funcional es una tendencia clara. Más aún te diría que ahora mismo hay más gente utilizando lenguajes con capacidades funcionales que sin ellas. Pero el asunto no es ese. El asunto es que esa frase tuya, lo único que hace es restringirte.

Dame ejemplos concretos de tus dichos.

No hay una única forma de hacer las cosas - digo yo. Y tú, con tu frase lo que pareces matizar es "sí, pero todas son malas menos esta" (o estas dos, si prefieres). Y la realidad no es así.

Seamos pragmáticos. El mercado comercial en general habla de POO, en el mercado particular del desarrollo web habla POO, y en el mundo particular de PHP un gran porcentaje no entiende de POO, pero las empresas están necesitando dejar de hacer páginas dinámicas con programación estructurada y pasar a hacer "sistemas" y el paradigma actual para ello es POO.

Si me hablas de lo que hacen las universidades, de lo que se está investigando o en contextos muy particulares y reducidos, estás fuera de lugar.

La realidad es que esta ciencia es todavía tremendamente joven y por ahora todas las formas de hacer las cosas tienen ventajas e inconvenientes y se pueden usar bien y se pueden usar mal. Y es aún muy pronto para desestimarlas completamente. Es más, es aún muy pronto para decir que ya hemos encontrado la forma buena de hacerlo.

Creo que te fuiste "al infinito y más allá", este es un foro de PHP y ese es el contexto. Discutir de teorías, futurología o sexo de los ángeles es casi off-topic.

[venkman]

En vista de que te parece que todo esto sea off-topic (aunque yo creía estar hablando de los méritos o no de incluir soporte para closures en un lenguaje... en concreto en PHP), contestaré sólo a una cosa. Más que nada por aclararlo:

Me preocupa que tan rápidamente pases de discutir sobre conceptos a atacar directamente mi persona.

En esto te equivocas. No creo haber atacado nada de tu persona. Tan sólo contestaba a eso de que no digo nada de sustancia. Si te has molestado, lo siento, pero has sido tú solo.

[enriqueplace]

Iniciado por venkman

En vista de que te parece que todo esto sea off-topic (aunque yo creía estar hablando de los méritos o no de incluir soporte para closures en un lenguaje... en concreto en PHP), contestaré sólo a una cosa. Más que nada por aclararlo:

En esto te equivocas. No creo haber atacado nada de tu persona. Tan sólo contestaba a eso de que no digo nada de sustancia. Si te has molestado, lo siento, pero has sido tú solo.

No me malinterpretes, estoy abierto a discutir sobre cosas concretas sin llegar a la descalificación personal. Si quieres teorizar sobre "el sexo de los ángeles" o lo que será dentro de 50 años el futuro de la informática, me parece fuera de lugar con respecto al tema que estamos tratando (si quieres abre otro tema).

Planteas lenguajes o paradigmas que no están en uso comercialmente. Nadie discutió que la informática terminó con la POO y no se va a descubrir más nada, pero a estas alturas y luego de tantos años desde su creación, no creo que sea prudente empezar a hablar de un cambio de paradigma inmediato.

Me gustaría nos concentráramos en tus afirmaciones:

• "Sí, y te diré que la programación funcional es una tendencia clara. Más aún te diría que ahora mismo hay más gente utilizando lenguajes con capacidades funcionales que sin ellas"

Me gustaría conocer ejemplos concretos sobre este tema, ya que no me consta.

[venkman]

Ejemplos concretos así que me vienen a la cabeza...

- El lenguaje con más número de instalaciones en todo el mundo actualmente: Javascript. Es un lenguaje multiparadigma, con fuerte componente funcional e importante inspiración en Lisp.
- Sistemas con 70 millones de usuarios. El chat de Facebook, hecho en Erlang, un lenguaje fuertemente funcional. Igualmente SimpleDB de Amazon.
- Erlang además maneja una enorme cantidad de sistemas de comunicación telefónica en el mundo.
- Haskell no se queda en universidades, no. Bancos como Barclays o Credit Suisse. O compañías como Nokia tienen importantes sistemas desarrollados en Haskell. Un ejemplo bonito es el de Xmonad, un gestor de ventanas para Linux (puedes buscar una presentación que hay por ahí muy chula sobre cómo está hecho). Microsoft está impulsando bastante (relativamente, claro) el uso de Haskell.
- XSLT, el lenguaje de transformaciones para XML es un lenguaje completamente funcional y su uso es relativamente amplio.
- Python es también multiparadigma (entre ellos funcional) y Google lo utiliza extensivamente en muchos de sus sistemas. Python daría para muchos ejemplos, pero no podría asegurar en qué medida su uso es funcional o menos.
- Daxter, el videojuego de Playstation está escrito en Lisp (sí, Lisp!). También se podría hablar de AutoCAD (AutoLisp) pero un ejemplo más chulo es el de los sistemas de control de las atracciones de Disneyland: escritos en Scheme. De todos modos Lisp daría para muchos muchos muchos ejemplos.


Como ves, ejemplos hay y muchos. Todos ellos "activos comercialmente". Yo no he hablado de ningún cambio de paradigma inmediato. He hablado de una tendencia, de un resurgimiento del paradigma funcional. Ni cambio, ni inmediato.

[enriqueplace]

Gracias por los ejemplos, los comento:

- El lenguaje con más número de instalaciones en todo el mundo actualmente: Javascript. Es un lenguaje multiparadigma, con fuerte componente funcional e importante inspiración en Lisp.

Si, que Javascripts sea un lenguaje que puedas hacer "cualquier cosa" (para bien o para mal), no veo que sea un sustento para el paradigma funcional.

- Sistemas con 70 millones de usuarios. El chat de Facebook, hecho en Erlang, un lenguaje fuertemente funcional. Igualmente SimpleDB de Amazon.

Es lindo ejemplo, pero nuevamente, es un caso muy aislado y puntual. Habría que ver las razones técnicas para haber decidido por "Erlang" (no sé quién se le ocurriría en su sano juicio elegir un lenguaje tan poco usado).

- Erlang además maneja una enorme cantidad de sistemas de comunicación telefónica en el mundo.

"Sistemas de comunicación teléfonica"... nuevamente -en mi opinión- es un contexto muy particular.

- Haskell no se queda en universidades, no. Bancos como Barclays o Credit Suisse. O compañías como Nokia tienen importantes sistemas desarrollados en Haskell. Un ejemplo bonito es el de Xmonad, un gestor de ventanas para Linux (puedes buscar una presentación que hay por ahí muy chula sobre cómo está hecho). Microsoft está impulsando bastante (relativamente, claro) el uso de Haskell.

Yo que sé, me parece nuevamente muy "tirado de los pelos" (con el mayor de los respetos te lo digo). Es como si yo te diera como argumento que Ada es un buen ejemplo porque lo usan todos los sistemas de los aviones modernos... y?

No veo que sea muy habitual poder elegir Ada, Haskell o Erlang.

- XSLT, el lenguaje de transformaciones para XML es un lenguaje completamente funcional y su uso es relativamente amplio.

Ok, pero no veo relación con la programación funcional.

- Python es también multiparadigma (entre ellos funcional) y Google lo utiliza extensivamente en muchos de sus sistemas. Python daría para muchos ejemplos, pero no podría asegurar en qué medida su uso es funcional o menos.

Python es recientemente un lenguaje que está adquiriendo popularidad, pero tampoco lo puedo -en lo personal- tomar como un ejemplo sólido.

- Daxter, el videojuego de Playstation está escrito en Lisp (sí, Lisp!). También se podría hablar de AutoCAD (AutoLisp) pero un ejemplo más chulo es el de los sistemas de control de las atracciones de Disneyland: escritos en Scheme. De todos modos Lisp daría para muchos muchos muchos ejemplos.

Si, también otro ejemplo muy extremo, como los sistemas para aviones.

Como ves, ejemplos hay y muchos. Todos ellos "activos comercialmente". Yo no he hablado de ningún cambio de paradigma inmediato. He hablado de una tendencia, de un resurgimiento del paradigma funcional. Ni cambio, ni inmediato.

Ok, vale la aclaración, pero nuevamente repito y en mi gran humilde opinión, son casos muy particulares y donde tampoco está fehacientemente demostrado que el "paradigma funcional" se una tendencia concreta o casos aislados que no pasarán de eso, casos aislados (aunque se comercialicen, ya que no creo que encuentres clientes muy habituales que te soliciten estas tecnologías).

El paradigma de la OO es algo que hace muchos años está planteado y que llevó muchos años imponer, y no hay duda del beneficio de su uso y por sobre otros paradigmas (como la programación estructurada).

Volviendo a nuestro contexto, Web primero, y PHP después, no creo que en un mundo que aún se aferra a viejas prácticas sea conveniente crear un escenario por demás confuso ("multiparadigma").

No dudo que determinadas características estén disponibles para quién quiera y se anime (y se haga responsable) de usarlas, pero creo que están en mejores condiciones lenguajes más estrictos como Java discutir de dar un poco más de flexibilidad, que un lenguaje como PHP donde tiene demasiada flexibilidad y donde no siguen estándares a la hora de desarrollar, donde discutimos a cada rato que cada uno tiene su propio estándar de nomenclatura, me parece que seguir el mismo rumbo no aporta, y que beneficiaría mucho dar un poco de rigidés a tanto desorden.

[venkman]

Vamos, que ponga el ejemplo que ponga, lo rechazas.

El caso extremo, me parece completamente absurdo tu rechazo al ejemplo de XSLT. El lenguaje es 100% funcional y no admite otro modo de programación que no sea funcional. Pero... ¿no sabes "qué relación tiene con la programación funcional"? En fin...

El paradigma de la OO es algo que hace muchos años está planteado y que llevó muchos años imponer, y no hay duda del beneficio de su uso y por sobre otros paradigmas (como la programación estructurada).

Debo decir que me pides ejemplos concretos pero que tus argumentos son bastante genéricos y más bien poco concretos. Pero te diré que la programación funcional es tan antigua/madura como la OO y que realmente no ocurrió que OO se impusiera sobre ella. Simplemente OO ha llamado más la atención. Pero la programación funcional ha estado siempre ahí.


Lo que comentas sobre la cultura existente alrededor de PHP sinceramente no es un problema de OO vs. funcional ni nada similar. Ni de ser estrictos frente a ser flexibles.
Esa es la cultura existente en este entorno y te puedo asegurar que no se cambia con más rigidez en el lenguaje. Esa cultura parte de fuentes muy concretas. Parte de lo que PHP es en sí mismo, de cómo mantiene esa idea de "cualquiera puede usarlo sin ningún esfuerzo", de "me leo un tutorial y lo hago y ya preguntaré en foros cuando tenga problemas", parte de la enorme cantidad de gente que hace algo mal (sucio) pero le funciona y entonces se lo enseña a otra gente y esos aprenden mal. No parte en absoluto de "oh, puedo hacer programación estructurada en lugar de orientación a objetos". De hecho, no creo que nadie se plantee "voy a usar mi propia nomenclatura en lugar del estándar". Simplemente ni siquiera imaginan que puede haber un estándar o incluso que eso tenga la mas mínima importancia.



Nota:
Se me olvidaba añadir este enlace. Es interesante.

[enriqueplace]

Vamos, que ponga el ejemplo que ponga, lo rechazas.

"Vamos", que ya te comenté que no es un concurso de quién sabe más o quién convence al otro, simplemente opino distinto y en lo personal no busco que me des la razón. Y verdaderamente tus aportes son muy buenos y útiles para tener suficiente información para que cada uno pueda discernir por sí mismo.

El caso extremo, me parece completamente absurdo tu rechazo al ejemplo de XSLT. El lenguaje es 100% funcional y no admite otro modo de programación que no sea funcional. Pero... ¿no sabes "qué relación tiene con la programación funcional"? En fin...

Epa, estimado, no pongas intencionalidad donde no hay, fue una simple pregunta ya que conozco conceptualmente "por arriba" lo que es XSLT pero no es algo que haya utilizado. Pensé que era algo más relacionado a XML y no como un lenguaje que pudieras aplicar "programación funcional".

Si me iluminas, estaré agradecido.

Debo decir que me pides ejemplos concretos pero que tus argumentos son bastante genéricos y más bien poco concretos.

Estamos en un mundo con prediminio de POO y tu argumentas que no, que lo que casi domina es la "programación funcional", de ahí es que te solicité sobre ese punto en particular ejemplos concretos ya que no te estaba entendiendo por qué lo decías.

Pero te diré que la programación funcional es tan antigua/madura como la OO y que realmente no ocurrió que OO se impusiera sobre ella. Simplemente OO ha llamado más la atención. Pero la programación funcional ha estado siempre ahí.

No digo que no haya estado, pero como bien tú dices, no es algo que puedas comparar con la adopción de la POO.

Lo que comentas sobre la cultura existente alrededor de PHP sinceramente no es un problema de OO vs. funcional ni nada similar. Ni de ser estrictos frente a ser flexibles. Esa es la cultura existente en este entorno y te puedo asegurar que no se cambia con más rigidez en el lenguaje.

No lo puedo asegurar para evitar equivocarme, sí puedo opinar que desde mi punto de vista no veo que más flexibilidad aporte algo para darnos un poco más de nivel a los desarrolladores PHP (de la misma forma, la actitud permisiva de la empresa Zend en comparación a una empresa más estricta como Sun).

Esa cultura parte de fuentes muy concretas. Parte de lo que PHP es en sí mismo, de cómo mantiene esa idea de "cualquiera puede usarlo sin ningún esfuerzo", de "me leo un tutorial y lo hago y ya preguntaré en foros cuando tenga problemas", parte de la enorme cantidad de gente que hace algo mal (sucio) pero le funciona y entonces se lo enseña a otra gente y esos aprenden mal. No parte en absoluto de "oh, puedo hacer programación estructurada en lugar de orientación a objetos". De hecho, no creo que nadie se plantee "voy a usar mi propia nomenclatura en lugar del estándar". Simplemente ni siquiera imaginan que puede haber un estándar o incluso que eso tenga la mas mínima importancia.

Si el lenguaje fuera como Java que no te permite hacer algo que no esté dentro de una clase, solo eso, ya generaría un cambio importante en la mentalidad de los desarrolladores PHP (por lo menos los obligaría a hacer clases y usar métodos, aunque todos los atributos los hagan públicos).

Con respecto a los estándares, se ha visto de todo. Zend tiene que imponer y comunicar claramente el estándar, y fielmente los desarrolladores lo deben seguir (existen muchos casos donde saben que hay algo especificado por Zend y se reusan a seguirlo, llegando a casos donde usan un híbrido entre muchos otros estándares).

Gracias por tu aporte.

[venkman]

Iniciado por enriqueplace

Epa, estimado, no pongas intencionalidad donde no hay

No he dicho que haya intencionalidad. Lo que sí tengo la sensación de que puede haber es falta de interés por hacer un mínimo esfuerzo. No te lo tomes mal, pero si descnoces algo, dilo claramente, no hagas suponer que no tenga relación.

XLST es un lenguaje de programación, es Turing complete, y es 100% funcional. Es el único paradigma que soporta. XLST es un lenguaje creado para el procesado de XML, sí, y es ampliamente utilizado en ese ámbito en gran cantidad de entornos (entre ellos web).

Iniciado por enriqueplace

Si el lenguaje fuera como Java que no te permite hacer algo que no esté dentro de una clase, solo eso, ya generaría un cambio importante en la mentalidad de los desarrolladores PHP

¿Hasta qué punto conoces el mundo Java? Lo pregunto de forma inocente, para no presuponer nada. Y no lo digo porque hayas dicho algo incorrecto sino porque... bueno... bien, Java es 99% OO pero no creo que deba verse como "la solución". Y resulta curioso que muchos de sus antiguos defensores hoy están promoviendo otras cosas con caracter funcional.

[Genetix]

Sobre los cambios en Zend Framework con respecto a la nueva versión de PHP (en especial los namespaces) hay una buena y una mala noticia

La buena
Que los namespaces serán incluidos en la versión ZF 2.0 que será publicado en el 2009 (aun sin fecha)

La Mala
Que la migración de los proyectos actuales va ser manual, y se vamos a tener que refactorizar nuestras clases (era de suponerse)



Aquí hay un link http://wiki.php.net/rfc/closures, donde explican la aplicación de los closures, para los que aun no estamos enterado mucho de esto (como yo), nos puede ayudar bastante a entenderlo.

Saludos

[enriqueplace]

No he dicho que haya intencionalidad. Lo que sí tengo la sensación de que puede haber es falta de interés por hacer un mínimo esfuerzo. No te lo tomes mal, pero si descnoces algo, dilo claramente, no hagas suponer que no tenga relación.

¿"Mínimo esfuerzo"? Me da la impresión que prejuzgas, si pregunto, es pregunta, no afirmación... si tu interpretas mal, presupones, que quieres que haga? Vuelve a preguntar si dudas, y en lo posible, de forma cordial.

XLST es un lenguaje de programación, es Turing complete, y es 100% funcional. Es el único paradigma que soporta. XLST es un lenguaje creado para el procesado de XML, sí, y es ampliamente utilizado en ese ámbito en gran cantidad de entornos (entre ellos web).

Sé que es utilizado, no he tenido la oportunidad, desconozco más allá de eso, no puedo opinar, por eso pregunto.

¿Hasta qué punto conoces el mundo Java? Lo pregunto de forma inocente, para no presuponer nada.

No soy experto, pero he realizado algunos trabajos en JSE y en JME, y mucho de lo que hago y promuevo para PHP viene de este mundo (no porque sea experto en Java, solo porque la ignorancia en el mundo PHP es mayúscula).

Y no lo digo porque hayas dicho algo incorrecto sino porque... bueno... bien, Java es 99% OO pero no creo que deba verse como "la solución". Y resulta curioso que muchos de sus antiguos defensores hoy están promoviendo otras cosas con caracter funcional.

Estimado, estimado, voy saliendo de la discusión por la puerta chica. No tengo deseos de seguir discutiendo temas que el ego pueda obligar.

Java no es 100% POO, estoy de acuerdo, pero por lejos es más POO que PHP, y desde PHP5 en adelante se ha tomado como base gran parte de cómo se hace en Java, y muchas ideas van por ese lado. Lo ha dicho Zend y varias empresas que la acompañan, entre ellas, IBM. Piensan que el futuro de PHP podría pasar por convertirse en una plataforma del estilo "JEE", pero mucho más simple y pragmática.

Volviendo al tema original, dado el estado de POO que tiene el lenguaje y que carece su comunidad, no veo con buenos ojos seguir preocupados en "caminos laterales o atajos" cuando carecemos de una estructura base sólida, y mucho de ello parte por las reglas de un lenguaje y por la definición y seguimiento de estándares promulgados por el responsable de turno, en este caso, la empresa Zend.

¿Cual es la responsabilidad de los desarrolladores? Mucha, tratar de mirar a los costados y ver qué pasa en otras plataformas / arquitecturas y tratar de aprender con conciencia, que no podemos seguir programando estructurado, que tenemos que aprender a desarrollar -seriamente- con OO y empezar a seguir principios de diseño, y que un "patrón de diseño" no es magia negra.