Barrapunto

Anda, disminuye los recursos del servidor, como los virus informáticos.

Otro compilador que añadir a la lista de PHP Compilers [phplens.com].

Curioso el PHP4Mono.

¿Para qué usar un lenguaje interpretado si luego lo vas a convertir a uno compilado mediante una adaptación con rendimiento inferior seguramente al que obtendrías haciendo el programa directamente en ese lenguaje compilado? Mi no entender

alguna buena tenían que tener.

Ahora voy a tener un motivo para defender a feisbuc en las charlas con amigos, al menos... Por fin voy a sentirme menos excluido (?)

...el endemoniado script, y testear la velocidad ganada con respecto a la densidad del código, y sobre todo, el margen de error; por supuesto teniendo en cuenta que en los mvc y desarrollos con menor número de algoritmos no tendría demasiada cabida. De todos modos, siempre se ha demostrado que, a larga, hubiere salido mejor empezar de cero. Total, la carga de trabajo radica más en la planificación, las estructuras de datos, la vista....y no en las horas que van a echar los picadores, que eso a la empresa le importa tirando a cero, aunque sean jóvenes progres y revolucionarios, vamos..'cools'.

Lo bueno es que si la transformacion es realmente 1:1, y tienen unos objetos C++ imitadores de los "objetos" de PHP bastante optimizdos, esto correra a mil leches por hora.

Lo malo es que en la mayor parte de los sitios web PHP ya es rapido, y las mejoras de velocidad se pueden conseguir de otras maneras menos complicadas.

Lo malo es que ya sabemos la historia que tienen los generadores de codigo. Cada vez que un informatico crea un generador de codigo, dios mata un gatito. Algun dia alguien tendra que meter mano al C++ generado, y se cagara en el creador, todos los usuarios de facebook, y en la humanidad en general.

La noticia es muy interesante, y sera bonito ver ese compilador^h^htraductor en funcionamiento.

Yo creia siempre sospeche que era un simple


rename *.aspx *.php

Bueno, Wikipedia está usando PHP también, y funciona estupendamente. Desde luego el montaje que tienen no es sencillo, pero creo recordar que lo hacen a base de varias capas de caché (en las BBDD, caché de PHP, proxys para el contenido estático o no modificado, etc.).

PHP tiene cosas malas, como todo en esta vida, pero que no sirva para proyectos muy grandes es un mito que ya podríamos ir liquidando.

En mi opinión esto no tiene mucho que ver con php, y ya dudo que tenga que ver con moodle. Más bien con la incompetencia de determinados servicios.

En mi universidad (que no digo, claro) había un grupo de profesores con un moodle que iba genial de rápido. Ya sé que pocos usuarios, etc., pero iba rapidísimo. Montaron el campus virtual para todo el mundo, y ya en fase de pruebas (es decir, sin ser accedido por el alumnado) el acceso a una página desde la propia red de la universidad tardaba 1 minuto (a veces más). Una basura de instalación y personalización, vamos.

Como dicen por ahí, wikipedia y las wikis en general van bien, y son php. Y lo dice alguien que no es fan de php.

Ah, y publico esto anónimamente porque paso de rollos con mi universidad.

Y la respuesta es: sin una GUI digna en el escritorio para los tiempos modernos que corren, con una red con latencia y ancho de banda entre el cliente y el servidor y con un javascript que haria esto todo mas humano. ¿ Realamente vale la pena compilar ?

No te vendría mal leer el post original, pedazo de troll.

Además, es público (y publicitado) que FB usa un enjambre de lenguajes y tecnologías, por eso construyeron Thrift:

a framework for scalable cross-language services development. Thrift combines a powerful software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, and Ruby.