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
A diferencia del drama que tiene Python para pasar de 2 a 3, la gente no está teniendo problemas para mantenerse al día con PHP (están los típicos servidores compartidos con Wordpress en 5.6 y las mil y una webs donde simplemente el número tolerable de actualizaciones es cero, pero por lo demás actualizar una app es simple y puedes simplemente ir incorporando type hints y demás características nuevas).
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
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.
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.
ahora es raku
a = 1
print(a) # mostrar un entero en pantalla, asquerosísimo hoyga.
a = 1
print ("El numero es: " + a)
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.
"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.
return Golang::last;
} else {
$this->publishWorldImplosion();
}
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.
?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
En el php3 ya estaba y lo mismo viene de antes.
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
¿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.
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.
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?
¿Cómo lo haces el Python? Con una librería, ¿no?
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 rehicieron renderizando en servidor usando técnicas de JS isomórfico. Pero en ese caso el primer renderizado sigue ocurriendo en el servidor, y es básicamente porque los navegadores (casi) solo entienden JavaScript. Una opción es un backend puro que se comunique con Nodejs que se encarga del prerenderizado, por ejemplo.
En fin, que Nodejs está muy bien, como también lo está PHP. Es cuestión de usar la herramienta adecuada para el problema adecuado, y PHP sigue siendo adecuado para muchos problemas (igual que para otros Nodejs es mejor opción).
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 a la web, descargar el zip, ponerlo en la carpeta del proyecto.... por suerte en PHP cuando han integrado Composer la cosa se ha igualado en ese sentido, pero mientras no lo ha tenido la comunidad Python y RoR ha crecido bastante, además en PHP hay muchísima dispersión, tienes cientos y cientos de frameworks, librerías para casi lo mismo... y te aburres de buscar la que mejor se adapte a tí, en Python llevo poco, pero lo que veo es que casi todo el mundo usa las mismas porque son bastante potentes y no tienes que complicarte buscando el Santo Grial.
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 cuanto al lenguaje no llevo tanto para poder decir que sea mejor o peor, al final cuando pasas por muchos lenguajes te dan igual los pequeños detalles, aún me cuesta no poner el punto y coma al final de línea, los corchetes... o lo que dice #8 el alto tipado de variables, acostumbrado a concatenar cualquier cosa... en Python tienes que hacer antes casting y cuando estás probando a imprimir variables para ver que resultados sacan es un poco rollo, aunque ejecutando Python desde algún IDE puedes tener un explorador de variables que te ahorra tener que estar haciendo print/echo constantemente.
También me gusta el poder ejecutar Python sin tener que arrancar ningún servidor, poder hacerlo ejecutable, en PHP me parece que había algún desarrollo también para hacer el script ejecutable incluso con QT, pero bueno, eso ya es pirarse la pinza, para mi están en dos mundos separados, a día de hoy si me tengo que decantar por hacer una web seguiría haciendolo con PHP, pero a la hora de tratar el backend probablemente lo haría en Python en lugar de PHP.
Cuando lleve más tiempo en Python ya le iré sacando pegas
Yo no digo que esté mal, pero ahora lo hago todo con NodeJS y Typescript y, una vez captados los conceptos de asincronía, me parece todo mucho mejor integrado, más flexible, con mejor rendimiento y acortando tiempos de desarrollo considerablemente, por no hablar de reutilizar estructuras de datos tanto en back como en front.
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.
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 programación reactiva (supongo que usas RxJS, o algo similar) es maravilloso, no hay nada mejor para gestionar la alta asincronía. De hecho ante proyectos muy asíncronos en el servidor me he planteado usar nodejs por poder usar toda la potencia de la RxJS (y alguna cosa más). Hay Rx para PHP pero no tienen todo. También es cierto que en el modelo de PHP de petición-respuesta no suele haber asincronía, por lo que no ganas demasiado.
Para un entorno asíncrono y ligero: nodejs suena muy bien. Para un entorno sin asincronía y peticiones más complejas, creo que PHP sigue siendo una buena opción.
TypeScript es un gran lenguaje, y lo dice alguien que sus dos frentes son ahora mismo PHP y TypeScript. Y lo de la JS isomórfico es una gran aproximación si puedes contar con un backend (completo o parcial) en JS.
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.
De hecho creo que reescribiré el servidor en Rust, Javascript es en realidad potente de cojones porque permite mil pajas mentales que además funcionan, pero una pesadilla si quieres hacer algo serio precisamente porque todo es tan mutable y flexible que llega un momento que no sabes qué es cada objeto que estás manejando (puedes meter, sacar, poner y quitar lo que quieras sobre la marcha al ser todo un diccionario en el fondo) y puedes darte tiros en el pie de mil formas diferentes.
Para cosas complejas se hace muy necesario un sistema de tipos. Typescript es una buena idea, pero no deja de ser una ñapa que además acaba sin dar todas las ventajas de un lenguaje compilado, ya que al final ejecutas javascript igualmente y los tipos no ayudan al JIT.
No quiero ni empezar a hablar de toda la mierda de ecosistema (transpilers, gestores de paquetes que crean tantos problemas como solucionan, polyfills, builders, etc.) que hay hoy día detrás de javascript, múltiples herramientas que hacen complicado lo que debería ser trivial, que al final tienes que montarte un sistema de build para un puto lenguaje de scripting. Me parece pesadillesco y sujeto con cinta aislante.
Rakudo es el nombre del compilador de Raku para las máquinas virtuales MoarVM y JVM.
rakudo.org/
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 cargo-culting en la programación en la que la gente hace lo que está de moda en lugar de pensar si realmente es lo más práctico, mantenible o eficiente.
Según pasan los años, en mi experiencia la filosofía KISS (Keep It Simple, Stupid) es la regla de oro y sólo se deben complicar las cosas si el problema lo exige. Representar texto HTML en PHP no lo exige. En otros lenguajes es mucho más necesario ya que no puedes hacer la salida HTML de una forma tan directa.
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.
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
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?
No hay color. Php es una cafetera vieja para código legacy.
Ibas bien hasta esa frase