Portada
mis comunidades
otras secciones
#4:
#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.
https://www.gnu.org/software/artanis/manual/manual.html
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.
https://www.gnu.org/software/artanis/manual/manual.html
Comentarios
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 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).
#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 parsear también es otra ventaja de NodeJS frente a PHP.
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.
#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 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.
#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 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.
#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.
#43 No recuerdo que version llegue a usar hace varios anyos en la uni, pero recuerdo que la sintaxis me era muy dificil de recordar y extraña comparada con otros lenguajes. Por eso lo odio. Nada mas.
#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 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.
#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 (https://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
#68 pues a mi me encanta usar Smarty, aunque Twig le está ganando terreno.
#64 Si, lo use para webs. Y no me parecio nada a c++ o java.
Te hablo de hace como 20 años. No se como sera ahora. Pero le pille mucho odio.
#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.
#74 Vale, entonces me callo y retiro mi comentario. Antes de quemarlo deberia revisarlo
Mis perdones.
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.
https://www.gnu.org/software/artanis/manual/manual.html
#1 El creador de Perl Larry Wall aprueba que Perl 6 pase a llamarse Raku (ENG)
El creador de Perl Larry Wall aprueba que Perl 6 p...
theregister.co.ukahora es raku
#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.
https://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 las 1000 PSRs del php y las discusiones eternas sobre dónde poner una llave. Descarga de librerías integrada en el entorno. Un int ocupa 4 bytes y sólo 4 bytes.... O si quieres, tienes int32 o int16 pero la idea es que cada vsriableses primitiva o estructura tiene un tamaño medible y óptimo.
No hay color. Php es una cafetera vieja para código legacy.
#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 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).
#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: https://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 ")
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)) else
Que lo quemen.
#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 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
#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
.Net Core
#15 Deja las drogas
#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.
#c-14" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3243695/order/14">#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
Una no-noticia sobre una cosa que aún no existe... los friquis meneantes os estáis superando con las portadas...