Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

hosting en interdominios
265 lecturas y 4 respuestas
  • Boca de Pez Boca de Pez
    6

    Programar en PHP como si fuera C (PHP procedural)

    Eso es lo que yo hago, para proyectos .com propios que lanzo en solitario (con intenciones de generar dinero con AdSense) ("yo me lo guiso, yo me lo como"). Tiene muchos inconvenientes, pero también muchas ventajas. 0% OOP... muchas funciones simples dedicadas a temas muy concretos, un sistema básico de templates creado por mí (para no mezclar el HTML con el código PHP) y que utiliza bastante HEREDOC (los que tengais algo de idea de PHP sabreis lo que es), epartir las funciones en diversos .php segun lo que hagan para luego hacer require_once(), etc. En stackoverflow hay muchas discusiones sobre el PHP procedural (es decir, lo que yo hago) VS cakephp (y similares). Parece que no hay una opción "aplastante", queda algo asi como 70% prefieren cakephp, 30% siguen con PHP procedural. Hay gente que dice que programar de esta forma (procedural) es por pereza, que estamos en 2012 y no en 2002, que es por ser mal programador (no entender bien OOP), y que entender luego el código para ampliarlo, etc. es un caos.......... para mi no es un caos, pero entiendo que si alguien lee lo que yo he programado, desde 0, le puede costar bastante entenderlo, incluso teniendo las funciones agrupadas en diferentes .php segun el tema que traten (igual que se puede ver en el código PHP del sistema de foros phpBB, por ejemplo). En un servidor dedicado con nginx (nada de apache) + php-fpm + "acelerado" por xcaché (alternativa a APC y eaccelerator), todo funciona "rápido y bien". Lo de que programado en cakephp seria mucho más rápido, no lo tengo claro, pero como no lo he probado.... Qué opinais vosotros de esto?

    Este tema lleva más de 6 meses inactivo. Es recomendable que abras un nuevo tema para retomar la conversación.
      • Boca de Pez Boca de Pez
        6

        En efecto, hay un editor WYSIWYG en este foro, pero por algún…

        En efecto, hay un editor WYSIWYG en este foro, pero por algún motivo, con Opera no carga y hay que andar poniendo los tags html a pelo...

        Después de tanto tiempo yo ya no tengo fe de que lo arreglen...

        ¿Programación secuencial más lenta que OOP? ¿Quien ha dicho eso? Dudo que el intérprete PHP esté tan, tan, tan... optimizado en OOP como para ir más rápido que en secuencial... la abstracción siempre tiene un coste y eso implicaría que el intérprete PHP sería una patata con el código procedural, que por mucho que metas objetos por encima, va a haberlo en todo programa... que los métodos no son menos procedimentales que una función cualquiera, lo único que están tras más saltos de indirección/abstracción... la mentira de que en OOP no hay punteros, cuando un método es el puntero a una función desde el puntero a un objeto que a su vez trata con múltiples punteros para acceder a los datos... vamos, siempre va a ser menos eficiente, si se adopta es solo por la facilidad y la modularidad.

    • Usar un framework es mas rápido porque ya te viene casi todo…

      Usar un framework es mas rápido porque ya te viene casi todo echo, pocas cosas vasa a tener que implementar. El problema de usar un framework? Que algunos parecen ser un lenguaje aparte, desde mi punto de vista. De echo por eso siempre me a dado palo aprender alguno.

      Usar OOP, hace que todo este mas claro, poder abstraer las cosas, hacerlas mas genéricas, separar un poco el HTML del PHP, y si usas MVC con algún Template Engine todo esta mucho mas ordenado. Pero bueno, para gustos y colores.

    • Boca de Pez Boca de Pez
      6

      según mi parecer, la programación orientada a objetos y el…

      según mi parecer, la programación orientada a objetos y el uso del MVC en aplicaciones web, puede ser ventajoso, si existe una mayoría importante que los domine; de lo contrario, muchos terminan migrando a PHP puro, por un tema de dinero, tiempo y recursos. por otra parte, ocurre que los frameworks que usan el patrón MVC (cakephp, etc), son muy poco flexibles a la hora de implementar requerimientos muy específicos, simplemente en la mayor parte de las veces, descubrimos que hay cosas que no se pueden hacer usando el patrón MVC, y limitan en forma importante, tanto al desarrollador en su capacidad de dar soluciones, como en nuevas funcionalidades para nutrir esa aplicación (para mi escalabilidad, tiene que ir de la mano con flexibilidad) y nos damos cuenta que mientras más abstraemos en la POO, menos flexible se nos vuelve la programación. es mi parecer, solo quise compartirlo.