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.
|
etiquetas: php , fundación , nikita popov 
![La Nueva Vida de PHP - La Fundación PHP [EN]](https://peta.meneame.net/backend/media?type=link&id=3587144&version=0&ts=1637648466&image.jpeg)
Hoy en día PHP está muy bien, pero siempre depende del desarrollador el como lo utilice, igual pasa con otros lenguajes. Pero obviamente PHP es para desarrollo web, no mucho más.
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.
¿Tu uso habitual es Inteligencia Artificial? Python (principalmente)
¿Desarrollo Web? PHP, Javascript (TypeScript)
¿App móviles? Java
Y luego tienes Go, Rust, y un sin fin.
Ah, y por favor, no empecemos un flame war, por favor, que os veo.
Se pueden hacer proyectos muy muy profesionales y con un altísimo rendimiento tanto en la 7.4 como en la 8.
Lo demás, para los haters.
P.D.: Si quereis os puedo hablar de mi libro.
- inconsistencia en la nomenclatura de algunos métodos antiguos (que van desapareciendo poco a poco, por suerte)
- la guarrada que permite mezclar HTML y PHP en un mismo archivo...
- el símbolo de dólar para denotar variables..
Y en cuanto a "debilidades", el caso más claro es el mal soporte para ejecución concurrente de código (y esto incluye tanto hilos, como programación asíncrona), pero es algo que parece estar a la vuelta de la esquina, la introducción de PHP 7.x hace años, y más recientemente 8.x ha allanado el camino para introducir mejoras que resuelvan estos problemas.
Respecto a IA... depende de lo que estés haciendo, supongo que te refieres a IA "clásica".
Todos se nutren entre sí, por ejemplo php ha metido recientemente funciones flecha (cogidas de typescript) y cosas así. Pero al final el ecosistema, la enorme cantidad de proyectos y de información que hay en php, la curva de aprendizaje... y sobretodo dos cosas: la flexibilidad que tiene este lenguaje y el rendimiento (que también van mejorando cada versión, vuela con pocos recursos) lo hacen un lenguaje muy muy bueno en mi opinión.
PHP ha ganado mucho en los últimos años (después del desastroso intento de PHP 6), con PHP 7.x y PHP 8.0 la velocidad y la actualización de muchos conceptos de programación lo hacen un lenguaje perfectamente válido para ese concepto difuso que el es el desarrollo web.
El curso que hice de IA solo usamos Python y no recuerdo que hayan mencionado ningún otro lenguaje, así que
Esos espacios de nombres tienen "dueños", por lo que nadie puede publicar paquetes dentro de los espacios de nombres que tú controlas. Eso dificulta mucho que nadie cree paquetes malignos con nombres parecidos, es mucho más fácil de identificar visualmente.
Añade ruido visual innecesario (el resaltado de sintaxis es más que suficiente para saber que un identificador corresponde a una variable, no hacen falta símbolos extra) que sólo parece gustar a una minoría muy pequeña, y además impone ciertas limitaciones arbitrarias a la hora de hacer evolucionar el lenguaje.
Aparte de eso... un minuto de silencio por el doble dólar: $$var , una de las features más problemáticas de PHP, que pueden resultar interesantes para novatos, pero que cualquiera con un mínimo de experiencia aprende a meter en la categoría de "ni con un palo de 15 metros de longitud".
Para inteligencia artificial siempre he creído que lo ideal eran lenguajes declarativos como LISP o ML.
El ejemplo más claro es packaging y distribución: Aquí Python apesta por todo lo alto (se pueden escribir miles de líneas sobre ello), y no proveen ni siquiera features básicas como "espacios de nombres" para la distribución de paquetes (ya ni hablemos de firmado), con lo que ataques como typosquatting son exageradamente sencillos de practicar. Esto se resolvió en PHP hace ya muchos, muchos años.
- mejor soporte para programación asíncrona
- en el caso específico de Go, mayor rendimiento. (No aplica tanto para NodeJS, o al menos ya no, antes sí podía ser un factor).
- En los bootcamps ya casi no se enseña PHP, sino JS+TS, porque permite formar a desarrolladores "fullstack", así que si quieres contratar a programadores recién salidos del horno y con sueldos bajos... te sale más a cuenta que tu stack se base en NodeJS (eso no aplica a Go).
Python muchas veces no se contempla como opción porque... es JODIDAMENTE LENTO, y su ecosistema de paquetes es un maldito desastre (nota: mucha gente no lo ve como un desastre porque o bien no han podido comparar con nada más, o bien no han hecho nada mínimamente complejo que toque aspectos como distribución de software). Que sí, por lo general, si no se hacen virguerías, es suficiente, pero los ecosistemas de NodeJS y el de PHP son mucho más maduros si se trabaja en web.
* github.com/eusonlito/crypto - Plataforma de gestion de cryptos.
* github.com/eusonlito/Password-Manager - Gestor de contraseñas web.
Alguien ha hablado de jsx (o tsx) para mezclar javascript y html (o typescrypt y html).
Lo invento Facebook y lo peor que antes lo intento con PHP que existe (pero no se usa por suerte) en.wikipedia.org/wiki/XHP
Backend: Node.js (Javascript o Typescript), Spring Boot (Java), .Net (C#).
Frontend: Angular (Typescript), React (Javascript y TS también), VUE (Javascript)
Yo soy front con Angular y por ejemplo en bancos como el BBVA o Inversis el Back está en Java con Spring, en Gestamp por ejemplo se tiende hacia .Net aunque también hay cosas en Java incluso Python.
Como dato curioso en Front React es muy popular en el mundo más que Angular, pero en España creo que este último es más popular sobre todo en grandes corporaciones.
Te veo un poco desfasado.
¿A qué lenguajes dices que migran su "stack"?
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...
Digo que lo intentaba, no que me saliera siempre (o que me dejasen)
Yo sigo haciendo apps para móviles usando Ionic, si necesito ya funcionalidades del móvil procuro hacerlas de forma nativa, en Java, mira por dónde, ya que es el lenguaje que se usa para móviles Android. Lo veo más práctico que dejarme llevar por "modas".
De hecho, Kothlin ni me he molestado en aprenderlo.
Yo para grandes proyectos usaría Typescript que al final es JS.
Bienvenido al mundo actual donde lo que hoy vale, mañana no, y por supuesto no va por funcionalidades / capacidades del lenguaje sino por moda y marketing de la empresa que mas invierta en publicidad de su lenguaje / API / entorno de desarrollo.
"si necesito ya funcionalidades del móvil procuro hacerlas de forma nativa, en Java". Yo diria que aunque Android es el sistema operativo basado en Java, hablar de funcionalidades nativas en Java es mucho decir. Yo diria funcionalidades de Android, mas que nativas. Lo más nativo seria ensamblador y en su defecto C y C++ que si te dan acceso nativo al hardware. Android/Java si o si necesitan de C/C++/Ensamblador por debajo para acceder al hardware, pero como basicamente todo en la informatica. Los lenguajes modernos en su mayoria son todo moda, y basicamente capas y capas encima de maquinas virtuales que por debajo usan C/C++ y Ensamblador para acceder al sistema operativo y el hardware.
Felicidades y gracias por compartirlo!
Y así con todo, no tengo claro que esté maduro de verdad, sigue con cordova
1000 por decir algo, pero vamos, que todo lo que se salga de un miniscript tiene que respetar MVC (o arder en el infierno)
Pues no te dejes C++ como si se te hubiera olvidado. Aquí huele a javato.
No es la peor de las opciones, pero es que para usar PHP usas Python. La gran ventaja de PHP es que los programadores de la empresa tengan el conocimiento.
#9 Yo no he conseguido ver a nadie, de verdad "difuminar" la línea entre back y front.
Sí, puedes usar el mismo lenguaje, pero al final muy poquitas cosas se aprovechan en front y en back, poquito código reutilizas.
La idea es esa, claro. Lo he visto con en Kotlin. Empresas que, aprovechando que el desarrollo android es en kotlin y que kotlin transcompila a JS, lo usan en todos lados. Al final no sé si les ha salido rentable no usar una opción más segura como JS o TS, pero sí que sé que no han aprovechado "las ventajas" que teóricamente tendría a la hora de ahorrar código.
Ahora que me acuerdo también lo vi con JS. Pero aquí les salió regular como a todo el mundo que ha intentado hacer apps android e ios con cualquier sistema "global". Al final se ven lanzando PR y arreglando nativescript.
Ahora microsoft ha sacado la evolución de Xamarin, la presentaron la semana pasada. Otro """fracaso""" de "unir tecnologías", ya que en iOS funciona decentemente pero va muy mal con versiones antiguas android.
perdón por el tocho
Usemos la herramienta adecuada para el problema concreto que tenemos enfrente.
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.
Es más si la usas para IA, puede ser útil también usarlo en la web. Así reduces el número de lenguajes.
Y ya que estamos, ¿por qué hay gente que migra PHP a Go o nodeJS?
Y ya que estamos, ¿por qué hay gente que migra PHP a Go o nodeJS? <-- Habrá que preguntárselo a ellos
Para mí es la primer opción para el fullstack, aunque entiendo que si tienes que hacer una API pura puedas preferir go o rust, si te importa más la eficiencia que el tiempo de desarrollo, pero a la larga si hay posibilidad de tener que compartir librerías con el front, usar javascript es una ventaja.
Justo ese es el problema. Cada cosa es para lo que es.
¿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...
Tal vez sea así en España, en el extranjero por dónde me he movido se referían a gente técnicamente buena y que no vendiese humo. Nada que ver con las ideas que tenéis
#54 en concreto hablo de gente que pueden perfectamente contratar por ~80k
La migración del stack por lo que he visto suele ser a microservicios, a elección del equipo o rama de ingeniería, pero vamos golang, algún sabor de Java, nodejs, python..
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.