La Nueva Vida de PHP - La Fundación PHP [EN]

Durante los 26 años de historia de PHP, el lenguaje ha sido desarrollado activamente por una gran cantidad de personas, tales como Ramsus Lerdorf, Zeev Suraski, Andi Gutmans, Nikita Popov y mucho muchos otros. En 2021, PHP está preparado para otra vuelta en su evolución.

[#101 elGude]

#82 Discrepo. PHP para servidor es de lo mejor que hay, haces una API como si fueran churros.

[#102 elGude]

#68 Te quiero.

Justo ese es el problema. Cada cosa es para lo que es.

[#103 elGude]

#60 En lo único que estoy de acuerdo contigo es lo de $$var. Eso es el cáncer.

[#104 elGude]

#97 Nadie es perfecto

[#105 FooDev]

#96 Respecto a lo que comentas de Docker, para el caso de Python (y cualquier otro lenguaje backend) sería igual ¿no?

Entiendo que lo suyo es tener siempre la aplicación en un contenedor distinto al del servidor (que puede estar soportando muchas otras aplicaciones web).

[#106 Toponotomalasuerte]

#88 tu dale. Pero es absurdo, ni por ecosistema, ni por productividad.
La única razón para escoger python es pq tu lo vales. Jijijiji. Luego organiza una aplicación un poquito grande. Jijijiji
Algún microservicio aislado y muy aislado, te lo puedo comprar... Como le metas algun dominio algo complejo lo veo ridículo.

[#107 --624466--]

#46 ¿Y qué aplicaciones en PHP dices que se distribuyen y que no sean backend webs? Porque en Python hay unos cuantos ejemplos de éxito (tipo Dropbox y otras apps de software libre), a pesar de sus carencias para empaquetar cosas que no sean librerías.

He probado extensamente maven, npm, cargo... Y pip/PyPI no tiene mucho que envidiar, más bien al contrario.

Increible como arremeten los PHPeros contra otros lenguajes usando prejuicios también, se nota que escuece el éxito de otros.

En cuanto al rendimiento de CPython, es un SW de 30 anos que nadie se ha preocupado en optimizar el rendimiento de forma profunda. En un par de versiones, con todo el dinero que está metiendo MS, Google y Facebook en esto, veremos a ver qué pasa.

[#108 armadilloamarillo]

#4 Acerca de los flame wars, recuerdo que cuando he sido más "talibán" de los lenguajes de programación "buenos" era cuando empezaba y no tenía ni idea, aunque creía que sabía como iba todo más o menos.

Conforme se adquieren conocimientos, se van viendo las similitudes entre unos y otros lenguajes, que al final no existe ninguna solución "perfecta", que los programadores no son artistas, que en programación ser un "rockstar" no es algo deseable, que apuntarse a lo último solo porque es lo último y es divertido casi nunca vale la pena, que no existe una "bala mágica" (framework, librería, lenguaje, editor) que sea todo lo necesario para cualquier proyecto, que emperrarse en usar la solución "perfecta" en vez de la que funciona es pegarse un tiro en el pie, que a veces es mejor copiar y pegar que meter una abstracción con calzador, etc.

Vamos, que al principio hubiera dicho en serio "PHP es una basura, Rust/Go/Kotlin es la puta caña" pero ahora, habiendo visto proyectos en PHP que estaban muy bien estructurados y escritos, como proyectos escritos en "lo último y mejor" por "expertos acreditados" que luego eran una basura rota, ilegible, inmantenible y en gran parte copia/pega de manuales y tutoriales, con chapuzas de todo tipo... ahora diría, el mejor lenguaje es aquél con el que puedas hacer lo que necesitas con más facilidad y eso depende únicamente de ti y de lo que quieras hacer. Lo mejor es definir bien lo que necesitas y luego investigar.

[#109 llorencs]

#106 mmm, que ventajas tiene usar PHP sobre Python.

¿Ecosistema? Que carencias le encuentras a Python que no sirva para backend.

En Python tienes más bibliotecas que en PHP,.. El soporte de programación asíncrona ya está bastante establecido...

[#110 --369745--]

#4 Por curiosidad, por qué Typescript concretamente? Gracias

[#111 darklooker]

Llevo en PHP desde la versión 3.
Aún hoy en día sigo en versiones 5.x

Donde puedo encontrar un refresh decente para saltar a 8.x? Tened en cuenta que que,.por ejemplo, nunca he usado frameworks, o composer. Todo a chaleco, librerías con includes, y más codigo spaghetti de lo que incluso yo desearía.

[#113 --26321--]

#110 Hablando siempre de mi propia experiencia: TypeScript me gusta para tener un frontend (usando Vue) más tipado. Es más, recuerdo una vez que estaba programando en TypeScript y me daba error en algunos navegadores... Sí, estamos hablando de IE (que para aquella web era importante mantener contento a los usuarios de IE). Pues simplemente tuve que cambiar la versión de Javascript a la que quería que TypeScript generara los ficheros y, voilà, sin dolores de cabeza ya tenía el sitio funcionando para IE.

[#114 --26321--]

#108 No puedo estar más de acuerdo contigo. Ese enamoramiento irracional de algunos con algunos lenguajes puede ser un síntoma de "juventud".

Usemos la herramienta adecuada para el problema concreto que tenemos enfrente.

[#115 aiguy]

#78 Tengo que confesar que busqué los tests en la carpeta "tests", no en las de dominio. Me doy por corregido y animo a quien tenga un ratillo a que se mire el proyecto de gestor de contraseñas. A nivel de crypto no sé qué tal está (así que esto no es una recomendación a usarlo) pero a nivel de arquitectura y buenas prácticas... ya me gustaría a mi que todos los proyectos fueran así!

Felicidades y gracias por compartirlo!

[#116 --369745--]

#113 Curioso, yo es que aprendí JS antiguo, intenté actualizarme a ES6+ pero me está costando y como lo hago por mi cuenta ya que no es por trabajo, pues con la infinidad de lenguajes que hay y que están saliendo ya no se que aprender y en que basarme. Python, que es con lo que estoy ahora, bien, me gustaría retomar JS o Node pero no se por qué me da dolor de cabeza. Ya de Java no hablo porque tiene algo que no me llama nada...

[#117 meneandro]

#60 De perl y de lenguajes de shell existentes. El primero se libra porque el dolar no sólo indica que se trata de una variable, sino de que es una variable "individual" (o sea, no se trata de una lista o conjunto, cosa que se denota con @... si, perl es un lenguaje donde hay singular y plural entre otras cosas exóticas como las bendiciones ). En otros lenguajes de shell, no tiene más función.

[#118 --514246--]

#105 No, en el caso de Python o Node tu lanzas el Docker con el proceso 1 siendo el propio servidor con todo lo necesario y si por algún motivo cae pues el docker muere y se levanta uno nuevo puesto que a muerto el PID 1.

La gracia de Docker es hacer contenedores stateless que contienen todo lo necesario para funcionar por si mismos de manera que si el estado pasa a ser desconocido o el docker se para lo puedes borrar tan tranquilo y lanzar uno nuevo, es por ejemplo como funciona en Kubernetes o ECS.

[#119 Opinator_3.0]

#69 Kotlin no ha sustituido a Java

[#120 FooDev]

#118 Pero algún servidor web estara respaldando la aplicación python/nodejs ¿no?

Si tanto el servidor como la aplicación se encuentran en el mismo contenedor a mi me huele que no se está cumpliendo con la filosofía de los contenedores, los cuales se supone que deben correr un único proceso ¿cierto? ¿El motor de bbdd al que previsiblemente esté conectada la aplicación también corre en el mismo contenedor? Sería el horror.

Además, en el caso de que el servidor web soportara más de una aplicación ¿qué hacemos? No entiendo muy bien que tiene que ver lo que comentas respecto al stateless por cierto.

[#121 Toponotomalasuerte]

#109 tiempo y dinero.
Pero puedes usar lo q quieras. Nosotros el python para cosas muy concretas y muy simples. Si hay q crear mucho paquete o un dominio complejo, barajamos otras opciones, preferiblemente go. Que es lo q esta copando todo nuestro backend salvo para la api central que se encarga de procesar la request, consumir servicios de dominio y envolver la response(esto en php porque tiene 5 años, pero actualizado a 7.4) ... Por detrás todo go y algún servicio puente con elementos externos desarrollado en node.

[#122 Lito]

#115 muchas gracias! hay cosas que sé que son **buenas prácticas** y nunca uso, como por ejemplo los repositorios, o las entidades unitarias para cada campo de tabla, o algún detalle más de acoplamiento entre capas, pero bueno, con el resto aún me voy adaptando.

[#123 --514246--]

#120 Imagínate una API en node, tendrías lo siguiente:
- un load balancer que seria a donde apuntaría el dominio
- un a imagen de docker con node instalado y los ficheros dentro, por ejemplo en /app, que al iniciar hace node /app/server.js
- un mysql metido en un server tradicional o en un RDS de AWS.

Al visitar irias al LB, el cual llamaria a uno de los dockers que hay detrás y que pasan las pruebas de healthcheck y estos se conectan al mysql para consultar los datos con estado.

Con este setup consigues poder escalar hasta millones de users sin ningún problema y si un docker falla simplemente se mata y se lanza uno nuevo.

[#124 coderspirit]

#107 No soy PHPero. Hace muchos años que no lo toco.

Pero chico, si realmente te crees eso de "todo lo contrario"... vives en el mundo de la piruleta. Que la forma oficial de instalar paquetes siga siendo PIP con su cutrisimo requirements.txt es de puta pena, que ni tansiquiera permite distinguir entre dependencias de desarrollo y dependencias de producción. Y si se quiere algo más potente, hay que irse a soluciones no estandar como el infame pipenv (al que su autor le atribuyó falsamente la medalla de solución "oficial"), o "nuevas" alternativas como poetry (que, para variar, introducen nuevos formatos de configuración incompatibles con los anteriores...).

Y aquí me estoy refiriendo SOLO a distribución, y más concretamente, sólo a distribución de bibliotecas. Porque si hablamos de software "standalone", y si entramos en el barrizal de los formatos de paquete, y las bibliotecas asociadas... madre mía, de verdad, que tengas los huevos de decir que Python está mejor que Node+NPM, o que PHP+Composer.

Y en cuanto a los virtualenv, que son prácticamente imposibles de mover (se tienen que volver a recrear de cero), porque se rompen cientos o miles de referencias "hardcodeadas" en el momento de crear el entorno... otro asunto que deja a Python muy, pero que muy mal.

Y respecto a lo de que nadie se ha ocupado de optimizar CPython... si el panorama es un puto barrizal. Tenemos: Cython (ya sé que Cython es para darle de comer aparte), PyPy, Pyston, Cmypy, Numba, Pyjion, Cinder... Y por lo que sea nadie consigue (o quiere) integrar ninguna de las mejoras en CPython.

[#125 FooDev]

#123 Pero... ¿qué parte de eso que comentas no puede hacerse con PHP?

[#126 casiguapo]

#111 buff. Quizá tendrías que buscar algún curso que lo complemente con patrones de diseño. Prueba a ver si los chicos de codely.tv te sirven

[#127 --514246--]

#125 Si puedes, pero para servir PHP necesitas dos procesos lo cual rompe la relacion de que el proceso que sirve el contenido es el PID 1 y por lo tanto puedes ligar el ciclo de vida del docker al PID 1.

[#128 PacoJones]

#108 Por fin un comentario sensato, gracias.

[#129 Pablosky]

#112 Perdona que me he explicado como el culo, decía un único proyecto de 1000 líneas en total. Si es una chorrada pequeña vale que mezcles php y html (aunque no deberías), si es algo más grande ni de puta coña, y wordpress lo hace...

Espero no tener que ver muchos ficheros de más de 1000, son el infierno en la tierra (Y he sido el responsable de alguno, pero nunca más).

Yo tenía antaño como buena práctica (cuando me dejaban y no tenía que estar todo "para ayer") ponerme a refactorizar cualquier función/método/clase que no me entrase en la pantalla sin hacer scroll, y no usaba un monitor de 70 pulgadas precisamente...

[#131 Pablosky]

#130

Digo que lo intentaba, no que me saliera siempre (o que me dejasen)

[#132 angat]

#119 es el lenguaje recomendado por Google para desarrollo de apps nativas android, a eso me refería nada más, a que es el "principal" como antes lo era Java

[#133 angat]

#63 anda! He usado unos cuantos de tus repos de Laravel en proyectos personales y alguno en algún proyecto profesional bastante tocho, hasta ahí puedo leer jeje

[#134 cosmonauta]

#8 Aquella era la epoca buena. Hasta el 2010 aprox. Es ahora cuándo lo han hecho tan aburrido que n oaporta nada respecto a otros lenguajes.

[#135 Lito]

#133 mis paquetes no son los mejores del mundo, funcionan, pero esos sí están hechos hace bastante tiempo y ahora mismo los haría de manera muy diferente

[#136 --624466--]

#124 He dicho que pip es bueno en cuanto a la cantidad de paquetes y funcionalidad que ofrece. He trabajado en proyectos bastante grandes con Python y sin problemas, por cutre que sea el requirements.txt, es funcional. Los virtualenv tampoco veo tanta necesidad de estar moviéndolos a otras máquinas, porque en local lo puedes activar desde cualquier sitio. Es más, me he estado encontrando, por mucho que me guste el mundo TS/JS, desarrolladores con más historias de terror con npm que con pip (a pesar de ser javeros con los cojones pelados los primeros y data scientists neófitos los segundos), ya que he tomado un rol de ayudarles con estas cosas: problemas de compilación incompresibles con el fsevents pinneado en el package-lock.json y su versión de node (que no entiendo por qué las dependencias básicas no van incluidas en el runtime), changesets de cientos de líneas en el package-lock.json cada vez que un programador diferente mergea algo...

Lo que no me has dicho (era lo único que te pedí) es qué app standalone en PHP se distribuye como un ejecutable al público general no experto en informática (como es, o era, el cliente de Dropbox). Y, ojo, no estoy diciendo que python no sea un desastre en este apartado y que casi cualquier lenguaje de propósito general de los importantes lo supera: Java, C/C++, C#, JavaScript, Rust, Go...

Esta claro que los core developers de CPython prefirieron durante mucho tiempo la simplicidad de implementación del intérprete y extensibilidad al rendimiento. Entiendo que, para el caso de uso para el que se pretendía Python, tenía sentido y la estrategia de delegar las partes más críticas a c-extensions no les ha ido tan mal (a tenor de las cifras de usuarios). Sin embargo, me consta que se están poniendo las pilas con esta vergüenza y que hay varios equipos (incluido Guido), para mejorar la historia de concurrencia y mejorar el rendimiento N veces mediante una rearquitectura del intérprete (incluyendo un compilador jit).

[#137 --624466--]

#107 Calibre, openshot y el cli de AWS son otros ejemplos buenos

[#138 PortgasDAce]

#96 podrías contar algo más concreto sobre esto? me gustaría saber como lo resuelven JS y PHP para ver las diferencias (a grandes rasgos, obviamente).