EDICIóN GENERAL
136 meneos
1633 clics

Nuevo en PHP 8 [ENG]

Se espera que PHP 8, la nueva versión principal de PHP, se lance a fines de 2020. Está en un desarrollo muy activo en este momento, por lo que es probable que las cosas cambien mucho en los próximos meses. En esta publicación mantendré una lista actualizada de lo que se espera que venga: nuevas características, mejoras de rendimiento y cambios importantes. Debido a que PHP 8 es una nueva versión principal, hay una mayor probabilidad de que su código se rompa. Sin embargo, si se ha mantenido al día con las últimas versiones, la actualización no debería ser demasiado difícil, ya que la mayoría de los cambios importantes ya no se usaban en las versiones 7. *.

| etiquetas: php8 , php
php, cruzcampo y murcia que bonitos sois!
Siempre que se habla de PHP hay unos cuantos comentarios sobre lo terrible que es PHP, pero sin ninguna explicación. Tengo curiosidad por saber qué es lo terrible de PHP, teniendo en cuenta que va por la versión 7.x (cas 8.x) y muchas cosas han cambiado desde que era una colección de scripts hasta ahora.

Al final cada lenguaje es una herramienta y normalmente tiene unas condiciones o circunstancias en las que es una gran elección, pero no hay 'balas de plata', no hay lenguaje netamente y claramente superior a los otros.

/cc #25 #12 #18 #10 #9
#43 Yo no he dicho que sea terrible. Trabajé 10 años con él y me parece cojonudo, pero creo que se ha quedado anticuado. ¿Renderizar en el servidor? Nah. Y para backend hay cosas mejor paridas.
#49 ¿Qué razones ves para calificarlo de anticuado? Lo digo porque PHP es un lenguaje que sigue evolucionando, añadiendo tipado opcional, avanzando en capacidades funcionales, mejorando rendimiento.

Por otro lado, el renderizado en servidor no es lo único que hace el backend. Es más, el renderizado en servidor sigue siendo algo dominante. Tenemos el ejemplo de Twitter que lo renderizaba todo en cliente pero les introducía un retardo hasta que el usuario podía ver el contenido, por lo que lo…   » ver todo el comentario
#51 Probablemente porque empecé a usarlo en 2002, por eso me parece anticuado. Ahora le saco mucho partido a las capacidades asíncronas de NodeJS. Seguro que ha evolucionado mucho, pero sigue siendo un preprocesador de hypertexto que tiene que unirse a un servidor web para poder ejecutar una aplicación para web. He hecho muchas comparativas de rendimiento NodeJS vs PHP (usando FPM y demás técnicas, varios servidores web, etc.) y no hay color. Trabajar con objetos JS nativamente sin necesidad de…   » ver todo el comentario
#53 He hecho muchas comparativas de rendimiento NodeJS vs PHP

Lo que tengo entendido es que PHP tiene mejor rendimiento que NodeJS en cuanto a ejecución del lenguaje. Nodejs gana seguramente en el número de peticiones por segundo cuando la petición es una respuesta relativamente simple (es maś sencillo del uso de callbacks en Nodejs que en PHP).

una vez captados los conceptos de asincronía, me parece todo mucho mejor integrado

En un entorno asíncrono cosas como la…   » ver todo el comentario
#53 Yo he hecho por aprender un pequeño juego html5 multiplayer en nodejs (todavía sin pulir) aprovechando la experiencia que ya tenía de front-end clásico (tipo jquery y demás) y es muy muy fácil perder el hilo de lo que estás haciendo en cuanto el programa se vuelve complejo, y además los IDE te ayudan sólo de forma limitada precisamente por esto.

De hecho creo que reescribiré el servidor en Rust, Javascript es en realidad potente de cojones porque permite mil pajas mentales que además…   » ver todo el comentario
#66 tienes toda la razón. Puedes usar la ñapa de typescript para un tipado simple que te salvaría en la mayoría de situaciones dadas en desarrollos de aplicaciones normales. Y es cierto que hay mucha parafernalia. Al principio me volvía loco, pero ahora que más o menos controlo el caos me centro en la parte buena, que es que tienes paquetes hechos para lo que se te ocurra, y eso me hace ganar mucho más tiempo que el que pierdo ahora conteniendo el caos.
#57 La sintaxis de PHP es básicamente la misma que C, C++ o Java. Quizá viste PHP embebido en HTML, cosa que actualmente se usa poco.
#64 Pues para mí usar templating en PHP es como ponerle otro motor a un coche que ya lo tiene: redundante y complicar las cosas.
PHP es en sí mismo un lenguaje de templating en el que tienes todo ya.
Una template en PHP debe ser básicamente HTML con puntos de inserción de strings, no hace falta complicarse la vida con otra librería innecesaria que te va a limitar.

Lo que no hay que hacer es mezclar código de presentación con código de negocio y ser disciplinado y ordenado. Hay mucho…   » ver todo el comentario
#68 Usar PHP embebido solo es conveniente para proyectos relativamente sencillos o con una estructura relativamente estática, cualquier software o framework medianamente complejo no lo usa (WordPress, Drupal, Laravel, Symfony), de hecho ahí está Twig, un sistema de templates para PHP (twig.symfony.com/).

Ahora, estoy de acuerdo en que conviene tender a la simplicidad y evaluar si realmente necesitas algo antes de meterlo porque está con todo el hype subido :-D
#68 pues a mi me encanta usar Smarty, aunque Twig le está ganando terreno.
#70 El PHP que conociste ya apenas se parece al PHP actual, por aquella época ni siquiera tenía soporte de objetos. Ahora tienes orientación a objetos, herencia horizontal mediante Traits, capacidades de lenguaje funcional, iteradores y generadores, funciones lambda, closures... En fin, es otra cosa completamente diferente. No te digo que tenga que gustar ahora, pero estás odiando algo que ya no existe.
Yo sigo esperando Perl 6.
#1 Ahora no hay Perl 6 , es Rakudo.

Sobre plataformas web, ojalá Scheme y la plataforma Artanis ganen atención. Más cuando Guile ahora tiene un JIT desde la version 3 y el rendimento llega a ser, literalmente, como entre 5 y 50 veces superior.

www.gnu.org/software/artanis/manual/manual.html
#1 Raku (antes Perl 6) salió en diciembre del 2015.
Rakudo es el nombre del compilador de Raku para las máquinas virtuales MoarVM y JVM.
rakudo.org/
Olvidé 10 años de PHP cuando conocí NodeJS.
#12 supongo que me debería de sentir afortunado por meterme en el mundillo ahora no? Hehe estoy aprendiendo nodejs, y dios me libre de php
#18 En realidad no. Pasarás por alto años de evolución tecnológica que quizá te sirvan.
#12 puta basura nodejs, yarn y los 2.000.000 de dependencias mantenidas por cuatro hipsters en github.
#29 LeftPad. Eso en Perl no pasaba, los módulos de coña estaban en Acme::
#12 Idem, pero con golang. Si puedo, no vuelvo a tocar el php, ni ningún lenguaje poco tipado.
#31 PHP cada vez tiene más opciones de tipado. Por ejemplo, hace tiempo que puedes tipar tanto los parámetros de las funciones como sus valores de retorno.
#42 Si...hasta que quieres hacer cosas como especificar que una función devuelve un array de objetos...y no se puede. O devuelves un array genérico, o te montas una clase "lista de cosas" que implemente un iterador.

Un coñazo...

Php se pensó para programar "mal", como lenguaje de scripting. Ni php 7 ni 8 aportan nada que otros lenguajes tengan desde hace mucho tiempo. Si me pagan por ello, lo usaré, pero no veo sentido empezar un proyecto nuevo en PHP. Ni en node, dicho sea de paso.
#61 ¿Y qué usarías tú?
#63 En backend, golang. O si eres de la escuela Java me tiraría había Scala o quizás kotlin. Rust no está mal, pero es ratito.

Todos son lenguajes muy modernos pensados para el hardware actual. Por ejemplo hoy cualquier cpu puede tener 8 o 12 cores. Dentro de 5 años quizás serán 100. ¿De verdad seguiremos usando lenguajes mono hilo?

En frontend no hay mucha más alternativa que no sea JavaScript en web y la familia Java en mobile.
#69 Esos lenguajes son efectivamente muy modernos. Yo diría que tienen muy buenas capacidades pero tienen limitaciones debido a novedad (menos soporte en hosting, menos ecosistema, cierta incertidumbre de si se consolidará o no). Al final, es cuestión de sopesar los pro y los contra para una situación dada.

Por otro lado, para aprovechar las capacidades multhilo golang entiendo que también tendrás que usar algoritmos y aproximaciones que sean multihilo (con la complejidad que lleva, aunque creo que golang ya hace mucho para facilitar la sincronización y gestión de recursos compartidos), ¿no?
#72 lanzar una función en paralelo, le pones go delante y listo. Para comunicacion entre hilos tiene los channels qué están sincronizados por defecto. Para paralelismo más esotérico, siempre quedan los mutex o lo atomics. Compilado con librerías estáticas. Todas las dependencias están en el ejecutable. Nada de tocar php.inis o similares. Los test vienen de serie, simplemente escribe un archivo llamado **_test go y ejecútalo. Formateo de código fuertemente opinado. Se acabaron…   » ver todo el comentario
#73 No hay color. Php es una cafetera vieja para código legacy.

Ibas bien hasta esa frase :-(
#32 Si utilizas nodeJs en el front busca un psicologo.
#33 Mejor que busque un programador
#27 Huir del fuego para caer en las brasas.
#30 Uy yo no, soy feliz con PHP y Python. Y nodejs y tal para el front.
Los cambios no son tan visibles como de 5.6 a 7.4. La compilación Just In Time añadido al preloading y las mejoras de rendimiento en general que ya están en 7.4 sí que pone un poco más de distancia con Python y Ruby, que se están quedando un pelín más lentos en comparación, aunque en muchos casos no importe, e.g. si el trabajo pesado lo están haciendo librerías o extensiones en C de todas formas.

A diferencia del drama que tiene Python para pasar de 2 a 3, la gente no está teniendo problemas…   » ver todo el comentario
#2 de que drama hablas? si tienes un proyecto o app o lo que sea que necesite 2.x pues usas 2.x en el docker o en el entorno que sea. El que quiera pasar de 2 a 3 su proyecto por huevos, pues tendrá que pensar muy bien si le merece la pena. No hay ningun problema con python. el problema lo tiene el dev.
Php es un delirio. Al loro: www.exakat.io/weird-operators-in-php

Hace unos años recuerdo haber leído en Reddit sobre un huevo de pascua tontísimo que seguía ahí porque a nosequien le hacía gracia a pesar de creaba una vulnerabilidad como la copa de un pino. Tela.
#35 empecé con PHP en la versión 4.2 y nunca he necesitado esos operadores. Ni he visto quien los use.
#35 El artículo que comentas es un poco "tonto", y perfectamente ignorable. Lo que comentas del "huevo de pascua", parece más interesante, pero con los datos que tengo no he sido capaz de encontrarlo.
#37 perdón por tirar la piedra y esconder la mano. Yo mismo llevo tiempo buscando el post de Reddit éste
#38 #37 Me suena mucho eso de hace un porrón de años, voy a buscarlo y pongo el link si lo encuentro.

?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

En el php3 ya estaba y lo mismo viene de antes.
#39 ¿No se quitaban estas gaitas con un simple "expose php no", o algo similar.
#20 Ojo, python no es PHP. No suele ser buena práctica concatenar así.

print("El número es {}".format(a))

o más moderno:
print(f"El número es {a}")

Por cierto, en python3 (que ya lleva tiempo entre nosotros), print es una función. No culpes al lenguaje, una vez dominado, a veces puedes hacer en 5 líneas lo que en otros lenguajes requeriría más de 15.
#21 En PHP puedes hacer

"El número es: ". $numero

O mejor aún: "El número es: $numero"

De todas formas, a lo que iba es que eso es un "coñazo", ya que no es tan trivial como concatenar tal y como se hace con otros lenguajes, pero te acostumbras. Por supuesto que cada lenguaje tiene sus cosas y en algunos se hacen mejor algunas cosas y en otros otra.
#21 No suele ser buena práctica concatenar así.

Tampoco es buena practica declarar a = 1 sin declararle el tipo y Python lo hace asi. Yo nunca entendere cual es el punto positivo de no declarar tipos para luego tener que ir haciendo castings. De hecho en Python3 el 'type hints' se ha introducido por eso y no deja de ser una chapuza.

Cuando concatenas strings y el lenguaje se encuentra con un objeto que no es un string, lo normal seria que implicitamente lo intentara convertir en uno, tal y como hace Perl.
if (! $this->isASeriousLanguage(PHP::v8)) {
return Golang::last;
} else {
$this->publishWorldImplosion();
}
#47 Supongo que necesitas tirar código para eso: recorrer las columnas, guardar su valor medio, y luego recorrerlas de nuevo sustituyendo. Usando PHP en plan funcional con una combinación de array_walk y array_reduce no debería ser muy complicado. Es posible que existan librerías para hacerlo, pero en librerías de cálculo científico Python tiene bastante más oferta. Claro que eso no es una construcción del lenguaje, son las librerías que otra gente ha desarrollado.

¿Cómo lo haces el Python? Con una librería, ¿no?
#48 En Python:
df.fillna(df.mean(), inplace=True)

Pero como tu dices... cuestión de librerías, esa línea de Python se hace con la librería Pandas, pero es tan usada que es casi como si fuera del lenguaje y así otras tantas, posiblemente haya alguna en PHP que haga algo similar. Lo que ha hecho que Python destaque (IMHO) pienso que ha sido esa facilidad de tener las librerías rapidamente funcionando, poder controlar que version usas... una línea en consola y listo, no como en PHP tener que ir…   » ver todo el comentario
#52 Gracias por la explicación!

En lo que hago últimamente, scrapping, análisis de datos, machine learning, CSVs... de primeras lo intenté con PHP y finalmente lo abandoné, porque apenas encontré librerías que facilitaran la tarea.

En eso Python gana de calle, no hay duda.
#52 php puede ejecutarse en consola con php-cli y hay servidores para algunos frameworks como symfony o laravel
#58 ¡¡Toda la razón!! Lo usé hace mil años y no recordaba que se podía usar desde consola
#48 Con hacer una función de reemplazo y luego llamarla con array_walk_recursive se podría hacer en un par de líneas (quitando la declaración del array). Ahora bien, para eliminar los valores vacíos se puede usar array_filter y luego un array_sum para calcular el promedio (dividido por la cantidad de registros de la columna). Todo eso se podría meter en la misma función que se invoca desde array_walk_recursive. Así, a bote pronto, es lo que se me viene rápidamente a la cabeza. Habría que ver un ejemplo para aplicar.
Yo seguiré usando Typescript
#7 Comparar Typescript con PHP es como mezclar el tocino con la velocidad.
#11 No los he comparado. A parte cuanto mas tocino comes, menos velocidad coges
#17 Según, a lo mejor no aumentas tu velocidad punta, pero tu velocidad media si, porque no te entra la flojera después de kms corriendo.
#11 #7 En teoría si es lo mismo, puedes levantar un servidor con nodejs y tal para hacer lo mismo que PHP.
#27 Siguen sin parecerse. Nodejs usa un EventLoop mientras que PHP no (bueno, hay alguna librería para hacerlo). El esquema es bastante diferente.

Son lenguajes que cubren cosas diferentes. Por otro lado, el rendimiento de PHP es superior a Nodejs (a JS en general), y seguramente lo sea más con PHP 8 y su JIT.
#7 Y yo mi citröen C4 xD
#15 Deja las drogas :-P
#47 array_walk() con una función anónima. Las comprehensions de python no dejan de ser bucles escritos de forma comprimida. De hecho me sorprendería que hoy día hubiese algún lenguaje mainstream en el que no se pueda hacer algo similar.
#14 no entiendo qué dices.
a = 1
print(a) # mostrar un entero en pantalla, asquerosísimo hoyga.
#19 Intenta esto:

a = 1
print ("El numero es: " + a)
#20 mejor usar format siempre.
A buenas horas... ha perdido mucho terrero que ya no podrá recuperar
#3 Yo que principalmente me he movido en PHP, ahora estoy liado con Python y cuando hago algo con una línea en Python y pienso el follón que tendría que montar en PHP para hacer lo mismo.... También hice cosas en RoR antes de que saliera PHP 7 y estaba bastante por delante en mi humilde opinión, sobre todo hacer los despliegues a producción, que puta maravilla.
En PHP 7 la verdad que no estoy puesto de las novedades, lo que si noté una barbaridad es en la velocidad de ejecución.
Me alegro que saquen pronto otra versión, hasta PHP 5/6 estaban muy parados y me sigue gustando como lenguaje de servidor, es muy fácil de entender.
#5 pues me ha pasado lo contrario. Hace unos meses tuve que hacer una solución en Python y se me cayó un poco el mito. Por ejemplo, para imprimir por a pantalla tenia que hacer un "flush", no veía eso desde C. Me ocurrió tambien que tenía un concepto de tipado fuerte un poco raro, no recuerdo que era exactamente pero recuerdo tener problemas con eso. Además escuché Python 3 es incompatible con Python 2.

No sé, el programa funciona perfectamente pero no veo porque es tan popular.

PD: ya recuerdo que era, para imprimir una variable tenía que usar operaciones de conversión de tipo.
#8 en Python si quieres mostrar un entero por pantalla tienes que convertirlo antes a string. Es asqueroso, pero te acabas acostumbrando.
#5 cuando hago algo con una línea en Python y pienso el follón que tendría que montar en PHP para hacer lo mismo

¿Puedes poner un ejemplo? Puedo entender que haya librerías de Python que hagan cosas que en PHP, pero sabría indicar qué cosas hace Python tan habituales que con PHP con un jaleo.
#44
Por ejemplo, tienes una matriz bidimensional numérica enorme con muchos valores NaN y necesitas que tengan algún valor, así que decides que donde haya un valor NaN se sustituya por el valor medio de la columna. ¿Cómo lo haces en PHP?
#3 Pues yo personalmente lo estoy viendo mas fuerte. Sobretodo con frameworks como Laravevl
PHP, ese lenguaje que convierte niños en hombres. Para luego casarse con una chica Microsoft y pegarse el resto de su vida atado al Visual Studio y su intellisense y aguantar la suegra DevOps
#46 Agradezco tu intención de hacer analogías, pero comparar PHP con Microsoft no tiene mucho sentido, por no decir ninguno. Ya no te digo Visual Studio y DevOps :-P
Una no-noticia sobre una cosa que aún no existe... los friquis meneantes os estáis superando con las portadas...
comentarios cerrados

menéame