edición general
123 meneos
1649 clics
La Nueva Vida de PHP - La Fundación PHP [EN]

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.

| etiquetas: php , fundación , nikita popov
«12
  1. #5 Algunos dicen que PHP es malo porque todavía están anclados en el pasado cuando se hacían malas prácticas y por su reputación que se granjeó en los 2000s con versiones más antiguas, además que hay gente que siempre tiene que odiar algo aunque sólo lo conozca de oídas.
    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.
  2. #3 PHP es para desarrollar el backend (tambien front), mira Laravel o Symfony, yo en mi caso me centro en desarrollar APIs Rest, teniendo hoy en dia tecnologias como Swoole o ejecutar php en AWS lambda, permite reducir los tiempos de ejecucion y tener un rendimiento muy alto en PHP al nivel de otro lenguajes como Node.
  3. #15 No me lo digas a mi, parece que ahora todo tiene que pasar por JavaScript por huevos, hay como una obsesión por utilizarlo como sea, parece como si todo lo demás fuera una mierda de la noche a la mañana.
  4. #8 llevo años programando en PHP y el lenguaje no ha parado de evolucionar.
  5. #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.
  6. #3 Depende de lo que se llame "uso habitual". Y aún así tienes varias elecciones:
    ¿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.
  7. PHP era muy malo, muchos aprendimos a programar al público en general con un lenguage con muchísimas carencias. La cuestión es que hay muchísima gente que se ha quedado con la versión 4 o 5, cuando las versiones más recientes de la 7 o la 8 no tienen nada que ver.

    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.
  8. #15 En todos los índices de uso de lenguajes Python aparece muy por encima de PHP. De hecho, los dos índices más conocidos (Tiobe y PYPL) ponen a Python como el lenguaje más usado actualmente.
  9. #5 PHP era malo. A día de hoy es bastante decente, tanto a nivel de sintaxis como a nivel de rendimiento y fiabilidad (mucha gente se sorprende de que sea mucho más rápido que Python). Aunque es cierto que todavía arrastra algunos errores del pasado:
    - 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.. :-( , de eso no creo que se vaya a librar nunca.

    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".
  10. #3 A día de hoy (y ya bastantes años) con composer, los frameworks que hay (Laravel por ejemplo), vagrant, docker, el camino hacia la versión 8... el rendimiento que tiene y los requisitos... no solo no tiene nada que envidiar a otros lenguajes, es que otros lenguajes deben envidiar a php.

    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.
  11. #5 Bueno, valorar algo como "malo" siempre es controversial. ¿Qué lo hace malo? ¿La velocidad? ¿Lo de algunas de sus funciones aceptan los parámetros de un modo diferente a otros?.

    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
  12. #81 No lo previene del todo, pero Packagist (el repositorio/registro principal de paquetes de PHP) impone el uso de espacios de nombre por defecto.

    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.
  13. #51 Lo del símbolo del dólar está ahí sólo porque lo copiaron de Perl... que a su vez lo hicieron porque en su momento, quien fuera que diseñó el lenguaje, no sabía suficiente sobre cómo implementar parsers.

    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".
  14. #4 pues eso, me refería a "desarrollo web" (aunque el concepto es difuso). Muchos dicen que PHP es muy malo (no sé si tienen razón o no porque no tengo conocimientos como para opinar), pero no sé si hay nada mucho mejor.

    Para inteligencia artificial siempre he creído que lo ideal eran lenguajes declarativos como LISP o ML.
  15. #5 Es que, en general, cuando alguien dice que trabaja con IA, realmente lo que quiere decir es que usa una API/librería que hace todas las matemáticas. Y Python tiene buenas librerías para IA. De ahí que se diga que Python va bien para IA.
  16. NOOOOOOOOOOOOOOOOOO
  17. #81 Por completar a #85: "Typo Squatting and Packagist" (seld.be/notes/typo-squatting-and-packagist), de uno de los co-fundadores de Packagist/Composer.
  18. #1 ¿Qué? ¡¿QUÉ?! ¿Que se va Nikita?
  19. #5 No me imagino yo a los desarrolladores de un videojuego utilizando LISP para crear una IA que controle un personaje que quiera que se asemeje a un jugador humano, eh :-P
  20. #5 Por ejemplo, en Boston Dynamics, trabajan fundamentalmente programando en C, C++ y para temas relacionados con la adquisición de datos (y ahí me imagino que para luego utilizarla en asuntos relacionados con IA), Python.
  21. #36 Si has dicho que es una ventaja lo de mezclar html y php que sepas que en el infierno hay un lugar guardado para ti, muy probablemente cerca del tío que hace los diseños de pizzas del telepizza xD
  22. #12 No es cierto. Y de hecho, si hablamos de ecosistema, su comunidad (con todos sus defectos) ha hecho un trabajo mucho mejor que el de, digamos, Python.

    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.
  23. #25 Migrar a NodeJS o Go se hace por varios motivos:
    - 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.
  24. #56 Puede que hasta tenga razón. No se puede usar un lenguaje como si fuera a servir para todo. Lo suyo sería evaluar cada sistema y utilizar la tecnología más óptima para su correcto funcionamiento. He conocido gente que han vendido maravillas de Angular a los clientes sin saber ni siquiera si era idóneo para resolver los problemas del cliente, sólo porque en aquel entonces era la moda. Eso sería entrar en el antipatrón "Golden Hammer" (Para un martillo, todo son clavos).
  25. #62 dos proyectos (míos) en PHP de calidad profesional:

    * github.com/eusonlito/crypto - Plataforma de gestion de cryptos.
    * github.com/eusonlito/Password-Manager - Gestor de contraseñas web.
  26. #32 "- la guarrada que permite mezclar HTML y PHP en un mismo archivo..."

    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
  27. #3 En desarrollo web las vertientes en empresas son:

    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.
  28. #13 yo llevo desde la versión 4.0 y la evolución es brutal, pero la verdad que hay otros lenguajes que son muy atractivos, aunque php permanecerá.
  29. #4 "¿App móviles? Java"

    Te veo un poco desfasado.
  30. #7 A mí aún me acaban de llamar esta semana solo por ver mi perfil de linkedin y mi experiencia de PHP
  31. #4 No lances la piedra y escondas la mano, cobárde.
  32. #15 ¿qué significa aplicaciones complejas?
  33. #7 ¿Talento? Si por talento llamas a buenos programadores, vas a tener problemas, porque escasean, en todos los ámbitos.

    ¿A qué lenguajes dices que migran su "stack"?
  34. #27 A mí es que el rollo ese de "buscamos talento" siempre me ha parecido muy difuso y sospechosamente parecido a una cortina de humo que no sabemos qué esconde exactamente.
  35. #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... :palm:

    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...
  36. #130 xD

    Digo que lo intentaba, no que me saliera siempre (o que me dejasen)
  37. He visto como varias empresas que buscan talento están virando su stack de PHP a otros lenguajes porque no encuentran talento
  38. #2 Nooooo, justo era el que mas cosas nuevas estaba aportando al lenguaje!
  39. #23 Supongo que eso explica porqué me contactan a veces para cosas de PHP teniendo el perfil de DevOps (y claro, cuando les digo que quiero cobrar más de lo que cobro ahora como DevOps para plantearme el cambio... pues como que les da la risa floja :shit: )
  40. #39 Por curiosidad, ¿Cómo previene el typosquatting PHP?
  41. #11 No lo sé, dilo tú. Yo llevo años sin problemas.
  42. #14 No era Kothlin hace dos años? Es que esto va por modas y no por funcionalidades / capacidades del lenguaje?

    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.
  43. #41 Se refiere a carne para vender por horas.
  44. #15 Hay grandes aplicaciones hechas con Node.js en back que es puro Javascript.

    Yo para grandes proyectos usaría Typescript que al final es JS.
  45. #65 "No era Kothlin hace dos años? Es que esto va por modas y no por funcionalidades / capacidades del lenguaje?"

    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.
  46. #72 Me quito el sombrero ante tal explicación, por fin alguien en este foro ha dicho algo con coherencia. Tienes toda la razón, está basado en capas, con lo que ya sabes cómo eso empeora el rendimiento (el famoso antipatrón YAML, Yet, Another More Layer).
  47. #4 Por curiosidad, por qué Typescript concretamente? Gracias
  48. #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
  49. #27 Yo cada vez que veo los términos "talento", "estrella", y por el parecidos refiriéndose a un trabajador, pienso que buscan a un chaval joven que sea bueno o medio bueno capaz de tragar mucho por el mínimo dinero posible. No sé si me equivoco.
  50. Sé que hay muchas críticas a PHP, pero me pregunto desde el desconocimiento qué lenguaje sería ideal a día de hoy para su caso de uso habitual.
  51. #75 El proyecto de contraseñas incluye los tests completos. El de cryptos, como es algo más para uso personal y tiene una total dependecia de terceros, he pasado bastante de hacer un mock por cada una de las peticiones externas que realizo.
  52. #8 Larga vida a Laravel
  53. #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!
  54. #71 Nosotros nos hemos pasado a capacitor pero solo lo hemos podido aplicar en un proyecto (el resto de apps que nos han entrado han ido en nativo). Pero bueno, que la experiencia con capacitor era constantemente "como mola esto!... qué facíl!....eh...mierda no funciona... ¿de verdad tengo que tocar este archivo gradle directamente?... bueno ahora si que si, cómo mola!.... uy esto tampoco va... ¿y ahora tengo que tocar un archivo .java?"

    Y así con todo, no tengo claro que esté maduro de verdad, sigue con cordova :-)
  55. #66 Todo lo que tenga más de 1000 líneas estaría mal hecho si como mínimo no respeta el modelo MVC.

    1000 por decir algo, pero vamos, que todo lo que se salga de un miniscript tiene que respetar MVC (o arder en el infierno)
  56. #2 Es un palo, pero también era hora que todas esas compañías arrimaran más el hombro. Es muy arriesgado que el desarrollo dependiera tanto de una persona en particular.
  57. #4 Puedes hacer app móviles con Ionic (typescript) o flutter.
  58. #4 " Ah, y por favor, no empecemos un flame war, por favor, que os veo. "

    Pues no te dejes C++ como si se te hubiera olvidado. Aquí huele a javato. :troll: :popcorn:
  59. #36 Sí, para gustos. Pero hay motivos objetivos por los que prácticamente nadie más se decanta por ese tipo de decisiones: Tienen muchas consecuencias negativas a medio y largo plazo.
  60. #7 Aprovecharán para salirse de PHP.

    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
  61. #64 Sí, conozco JSX y TSX... y puedes imaginar que no me gusta por mis comentarios anteriores. Pero hay algo que lo hace esencialmente "mejor" a lo que ofrece PHP: Que su principal objetivo es facilitar la escritura de código de "marcado" dentro de código ejecutable, y no al revés (como sucede en PHP).
  62. #70 No si no te lo niego, si a mi lo que mas me mataba (debe ser un TOC de ordenar las cosas) es el html que escupía PHP y también por otro lado el identado de PHP con bloques HTML.
  63. #95 Eso es verdad, me lo comentó un amigo el otro día. Pero como jamás lo he usado he evitado escribirlo.
  64. #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.
  65. #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.
  66. #7 Curioso ¿y a cuál lenguaje(s) están cambiando? Últimamente veo mucho React y todos esos frameworks javascript que van difuminando la línea entre Front-end y Back-end en alguna situaciones.
  67. #4 Sí, vamos a montar un complejo sistema de gestión usando TypeScrip. ¿Qué puede salir mal?
  68. #10 lo que se lleva ahora se llama Flooter o algo así.
  69. #9 JS no es para aplicaciones complejas. Si aun me dijeras Python, vale, pero hay muchos más desarrolladores de PHP que de Python
  70. #7 yo tuve una entrevista de una empresa que buscaban desarrolladores php y que se cambiaban a javascript (node) o Go, cada vez hay mas desarrolladores javascript ya que es el lenguage que estudia todo el mundo hoy en dia (bootcamps) y los desarrolladores que quedan de php son bastante demandados (ncluido yo guiño guiño)
  71. #4 Python también sirve para web.

    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?
  72. #4 Si hablas de lenguajes hay flame asegurado.
  73. #25 Es más si la usas para IA, puede ser útil también usarlo en la web. Así reduces el número de lenguajes. <-- Me imagino que esas decisiones no debes tomarlas sin tener en cuenta el rendimiento del sistema y la capacidad de gestionar el volumen del trabajo de mantenimiento y las actualizaciones del sistema que vayas realizando.

    Y ya que estamos, ¿por qué hay gente que migra PHP a Go o nodeJS? <-- Habrá que preguntárselo a ellos
  74. #12 algún ejemplo concreto de qué echas de menos?  
  75. #40 yo desde la siguiente. 10 años llevo con PHP y no ha parado de evolucionar.
  76. #32 Lo de símbolo del dólar para las variables es de lo mejor.
  77. #49 Y si usara, no sé, Python. ¿Cuanto discutirías? :-D
  78. #47 Le digo yo a mi jefe de migrar todo a TypeScrip y la carcajada la escucho desde casa sin necesidad de usar skype.
  79. #20 En mi caso un sistema de gestión de empleados, nóminas, una app tipo uber, otra de delivery y otras cosas más.
  80. #45 Hablanos, que me apunto yo con otro capítulo.
  81. #58 No veo por qué javascript sería una mala opción.

    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.
  82. #61 No veo el problema. Python se puede usar para backend perfectamente.
  83. #63 Yo proyectos personales pocos, pero profesionales de prácticamente de lo que quieras. Redes sociales, gestión de almacén, satélites, VTC, delivery, metro, tiendas y etc.
  84. #82 Discrepo. PHP para servidor es de lo mejor que hay, haces una API como si fueran churros.
  85. #68 Te quiero.

    Justo ese es el problema. Cada cosa es para lo que es.
  86. #60 En lo único que estoy de acuerdo contigo es lo de $$var. Eso es el cáncer.
  87. #97 Nadie es perfecto :-D
  88. #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...
  89. #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.
  90. #108 Por fin un comentario sensato, gracias.
  91. #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.
  92. Muero un poquito por dentro mirando los comentarios  media
  93. #27 #41 #54
    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 :shit:

    #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..
  94. #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.
  95. #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 xD). En otros lenguajes de shell, no tiene más función.
  96. #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.
  97. #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 :shit:
«12
comentarios cerrados

menéame