8 ms·

When I started programming a few years back, I was told that PHP is legacy tech and a terrible language I should avoid like a plague. After years of battling wi

When I started programming a few years back, I was told that PHP is legacy tech and a terrible language I should avoid like a plague. After years of battling with Node.js on the backend, I took a closer look at modern PHP and the Laravel framework and I was amazed by how good the developer experience was. The language itself feels like a lite version of Java. I believe everyone starting on web development should know PHP. It's hugely deployed, it has a very mature and rich ecosystem and it's a great language to build your side project/business without spending your time on meaningless tasks. Don't be driven by FOMO like I was, there's no such thing as a "perfect programming language". Every language has it's quirks and that's fine. PHP might be old and boring but it helps you get things done faster than using the new coolest language.

clairity 7y ago
php is definitely better these days (i used to use it early in my career), but unless you're already knee-deep in php, i can't think of a web project where php/laravel would generally be a better choice than ruby/rails. alas, ruby has become passé too, in favor of javascript, a decidedly unrefined language. javascript has too many hidden ways to shoot yourself in the foot, and just hasn't evolved for developer happiness the way php and ruby have.
- sowhatquestion 7y ago
  As a Laravel dev who almost went down the Rails path, I’m curious: what advantages do you think Rails has over Laravel at this point?
  - tylerjwilk00 7y ago
    Definitely not performance [1]. Maybe aesthetics? [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - todotask 7y ago
      Which part do you see that is not performance in that benchmark which shown the average time? I have tried benchmark on my own and PHP took longer than RubyJIT.
      - tylerjwilk00 7y ago
        Every benchmark on that page is faster for PHP
        todotask 7y ago
        "Every benchmark on that page is faster for PHP" Let me advice you to benchmark it "accuracy" on your machine setup, don't rely what is on that page. Make sure the error with --jit-verbose=1 which will show whether it uses MJIT correctly. ruby --jit-verbose=1 - N-Body single core Ruby 2.6.3 6:22.00s RubyJIT 2.6.3 3:58.18s PHP 7.3.xx 4:10.90s
        igouy 7y ago
        > will show whether it uses MJIT correctly … JIT success (511.7ms): initialize@nbody.rb:14 -> /tmp/_ruby_mjit_p5804u105.c JIT success (397.5ms): block in offset_momentum@nbody.rb:68 -> /tmp/_ruby_mjit_p5804u106.c JIT success (607.0ms): block in energy@nbody.rb:50 -> /tmp/_ruby_mjit_p5804u108.c JIT compaction (53.6ms): Compacted 111 methods -> /tmp/_ruby_mjit_p5804u111.so Successful MJIT finish real 6m4.201s user 6m42.813s sys 0m4.041s $ time /opt/src/php-7.3.11/bin/php -n nbody.php 50000000 -0.169075164 -0.169059907 real 5m24.915s user 5m24.808s sys 0m0.020
        todotask 7y ago
        As for mine, Ruby slightly faster 4:05s - 4:09s which is close to PHP in timing. ruby 2.7.0dev (2019-11-23T07:06:30Z master b563439274) [x86_64-darwin18] gtime -v /usr/local/bin/ruby --jit -W0 nbody.rb 50000000 -0.169075164 -0.169059907 Command being timed: "/usr/local/bin/ruby --jit -W0 nbody.rb 50000000" User time (seconds): 249.30 System time (seconds): 0.58 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:08.97 --- PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:52) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies gtime -v php -n nbody.php 50000000 -0.169075164 -0.169059907 Command being timed: "php -n nbody.php 50000000" User time (seconds): 248.02 System time (seconds): 0.49 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:09.82
  - clairity 7y ago
    honestly i haven't looked at laravel recently enough to remember the specifics (although others here seem to have), but 2 general stengths are (1) ruby is more consistent, intuitive and fun vs. php, and (2) rails has reasonable defaults, easy configurability on top of that, and a nice ecosystem of both built-in and community-built widgets. it's so fast to get up and running with rails. but i'd pick php over js any day! (probably even over python/django, unless data mining is a core concern)
  - cutler 7y ago
    Polish and refinement. Ruby's expressiveness and clean design make possible a level of elegance in Rails that I haven't seen in any other web framework. Ruby lends itself to DSLs much more than most other languages, Clojure excepted, and its meta-programming makes possible a number of shortcuts which help you to get a project up and running in record time. Add to that the magnitude of commits to the Rails project over its 14-year history and you have an ideal tool for SME web projects.
idoubtit 7y ago
PHP has come a long way, and nowadays it's in the same category as Python. Worse in many ways, but better by other, like the type declarations and their (runtime) enforcing. Yet there are still many ugly sides to PHP, and Laravel illustrates most of them. There is so much magic that IDE can't follow: some classes have a `__call()` magic function that redirect methods calls to other instances. Some functions return values of varying types, with no common interface. I've worked with several PHP frameworks, and Laravel is by far the worst. Its awful documentation plays a big role in this (no real reference doc, just a tutorial ; no links to classes or function in the doc ; the API doc is a joke ; the acclaimed "laracasts" are useless for serious work). The fact that this framework is dominant in the PHP community is worrying.
- CodeWriter23 7y ago
  How long ago was your experience? I started using Laravel early last year, took a hiatus and have been actively developing in it for the past 7 months. This is coming from years with Perl Dancer / Dancer2. I have not run into these issues. But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”. I’ve also found Laravel superior to Dancer in every way. But I did have to get into a different mindset.
  - lone_haxx0r 7y ago
    > But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”. I don't think it's about preferring one approach or the other. A good library/framework should have both instructional documentation and reference documentation. They have different use-cases and are not interchangeable.
  - cutler 7y ago
    Comparing Dancer with Laravel is a bit apples to organges, no? Mojolicious or Catalyst would make a better comparison with Laravel.
- thdrdt 7y ago
  Laravel is popular because it allows you to setup your project very quickly. And then the trouble starts. Remember what properties your models had? No? Well so doesn't your IDE. There is just too much magic going on to keep things maintainable. If you like a framework like Laravel you should go with Symfony instead. But don't use annotations. Keeps things separated so you and your colleagues can find routing and database information at logical places instead of all over the place in classes.
ashton314 7y ago
> there's no such thing as a "perfect programming language". Every language has it's quirks and that's fine. PHP might be old and boring but it helps you get things done faster than using the new coolest language. I disagree with you on this point. I worked with PHP for two years on some legacy systems, as well as some Laravel-based systems. While Laravel yields results that are worlds away from PHP build in the 90's, I still wasted dozens of hours because of poor constructs that the language is unfortunately coupled to. I documented each instance where I wasted a significant amount of time due to issues like scoping issues, closure problems, arrays-that-are-arrays-sometimes-but-maps-other-times, etc. PHP has gotten better. But there are so many good choices that provide much better tooling, guarantees, etc. Examples: Ruby, Go, and Elixir. Heck, even Perl is more sane about its data types in some ways by enforcing consistent comparisons with `==` vs. `eq` and much more robust data structures. I agree that every language has it's quirks. But I think PHP has so many that it seriously gets in the way often. I don't think it offers any significant velocity gains over using, say, Ruby.
- dabernathy89 7y ago
  Never heard anyone complain about scoping or closure issues with PHP. I'd be interested to hear more if you recall.
- jamroom 7y ago
  I don’t believe there are maps in PHP - just plain arrays which to be honest are pretty simple to use. Unlike say JavaScript where arrays are always numerically indexed, PHP can use any value as an index.
  - azernik 7y ago
    JavaScript, by contrast, doesn't have arrays - it just has objects, which can have numerical keys. a = [] a.foo = 'bar' // works! b = {} b[0] = 42 // also works! I happen to think these designs are both INSANE, but even if you like them, PHP has no advantage here.
    - 7y ago
lone_haxx0r 7y ago
There's no such thing as the perfect programming language, but there are languages that are plainly bad. For example: I don't think anyone would seriously defend the idea that brainfuck is a reasonable language to write production code in.
cutler 7y ago
Considering PHP's pseudo-Java verbosity I wouldn't exactly classify it as a fast-to-develop language. Doc-block comments are an abomination if you come from Ruby,Python or Javascript and if you follow the numerous PSRs to the letter you're lucky if you can fit a couple of lines of real code on a screen surrounded as they will be by space-wasting blank lines, doc-block annotations and KR-style braces.
- melicerte 7y ago
  I guess you have not read the post you are commenting. One of the rationale behind union types is to reduce the doc-block comments. It is also, I believe, one of the idea of introducing a stronger type system in PHP. From the original post: [quote] Supporting union types in the language allows us to move more type information from phpdoc into function signatures, ... [/quote]

clairity 7y ago

php is definitely better these days (i used to use it early in my career), but unless you're already knee-deep in php, i can't think of a web project where php/laravel would generally be a better choice than ruby/rails. alas, ruby has become passé too, in favor of javascript, a decidedly unrefined language. javascript has too many hidden ways to shoot yourself in the foot, and just hasn't evolved for developer happiness the way php and ruby have.

sowhatquestion 7y ago
As a Laravel dev who almost went down the Rails path, I’m curious: what advantages do you think Rails has over Laravel at this point?
- tylerjwilk00 7y ago
  Definitely not performance [1]. Maybe aesthetics? [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - todotask 7y ago
    Which part do you see that is not performance in that benchmark which shown the average time? I have tried benchmark on my own and PHP took longer than RubyJIT.
    - tylerjwilk00 7y ago
      Every benchmark on that page is faster for PHP
      - todotask 7y ago
        "Every benchmark on that page is faster for PHP" Let me advice you to benchmark it "accuracy" on your machine setup, don't rely what is on that page. Make sure the error with --jit-verbose=1 which will show whether it uses MJIT correctly. ruby --jit-verbose=1 - N-Body single core Ruby 2.6.3 6:22.00s RubyJIT 2.6.3 3:58.18s PHP 7.3.xx 4:10.90s
        igouy 7y ago
        > will show whether it uses MJIT correctly … JIT success (511.7ms): initialize@nbody.rb:14 -> /tmp/_ruby_mjit_p5804u105.c JIT success (397.5ms): block in offset_momentum@nbody.rb:68 -> /tmp/_ruby_mjit_p5804u106.c JIT success (607.0ms): block in energy@nbody.rb:50 -> /tmp/_ruby_mjit_p5804u108.c JIT compaction (53.6ms): Compacted 111 methods -> /tmp/_ruby_mjit_p5804u111.so Successful MJIT finish real 6m4.201s user 6m42.813s sys 0m4.041s $ time /opt/src/php-7.3.11/bin/php -n nbody.php 50000000 -0.169075164 -0.169059907 real 5m24.915s user 5m24.808s sys 0m0.020
        todotask 7y ago
        As for mine, Ruby slightly faster 4:05s - 4:09s which is close to PHP in timing. ruby 2.7.0dev (2019-11-23T07:06:30Z master b563439274) [x86_64-darwin18] gtime -v /usr/local/bin/ruby --jit -W0 nbody.rb 50000000 -0.169075164 -0.169059907 Command being timed: "/usr/local/bin/ruby --jit -W0 nbody.rb 50000000" User time (seconds): 249.30 System time (seconds): 0.58 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:08.97 --- PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:52) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.11, Copyright (c) 1999-2018, by Zend Technologies gtime -v php -n nbody.php 50000000 -0.169075164 -0.169059907 Command being timed: "php -n nbody.php 50000000" User time (seconds): 248.02 System time (seconds): 0.49 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 4:09.82
- clairity 7y ago
  honestly i haven't looked at laravel recently enough to remember the specifics (although others here seem to have), but 2 general stengths are (1) ruby is more consistent, intuitive and fun vs. php, and (2) rails has reasonable defaults, easy configurability on top of that, and a nice ecosystem of both built-in and community-built widgets. it's so fast to get up and running with rails. but i'd pick php over js any day! (probably even over python/django, unless data mining is a core concern)
- cutler 7y ago
  Polish and refinement. Ruby's expressiveness and clean design make possible a level of elegance in Rails that I haven't seen in any other web framework. Ruby lends itself to DSLs much more than most other languages, Clojure excepted, and its meta-programming makes possible a number of shortcuts which help you to get a project up and running in record time. Add to that the magnitude of commits to the Rails project over its 14-year history and you have an ideal tool for SME web projects.

idoubtit 7y ago

PHP has come a long way, and nowadays it's in the same category as Python. Worse in many ways, but better by other, like the type declarations and their (runtime) enforcing. Yet there are still many ugly sides to PHP, and Laravel illustrates most of them. There is so much magic that IDE can't follow: some classes have a `__call()` magic function that redirect methods calls to other instances. Some functions return values of varying types, with no common interface. I've worked with several PHP frameworks, and Laravel is by far the worst. Its awful documentation plays a big role in this (no real reference doc, just a tutorial ; no links to classes or function in the doc ; the API doc is a joke ; the acclaimed "laracasts" are useless for serious work). The fact that this framework is dominant in the PHP community is worrying.

CodeWriter23 7y ago
How long ago was your experience? I started using Laravel early last year, took a hiatus and have been actively developing in it for the past 7 months. This is coming from years with Perl Dancer / Dancer2. I have not run into these issues. But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”. I’ve also found Laravel superior to Dancer in every way. But I did have to get into a different mindset.
- lone_haxx0r 7y ago
  > But I have to admit my own bias in preferring the “show me how” instructional method over “tell me everything, no matter how esoteric”. I don't think it's about preferring one approach or the other. A good library/framework should have both instructional documentation and reference documentation. They have different use-cases and are not interchangeable.
- cutler 7y ago
  Comparing Dancer with Laravel is a bit apples to organges, no? Mojolicious or Catalyst would make a better comparison with Laravel.
thdrdt 7y ago
Laravel is popular because it allows you to setup your project very quickly. And then the trouble starts. Remember what properties your models had? No? Well so doesn't your IDE. There is just too much magic going on to keep things maintainable. If you like a framework like Laravel you should go with Symfony instead. But don't use annotations. Keeps things separated so you and your colleagues can find routing and database information at logical places instead of all over the place in classes.

ashton314 7y ago

> there's no such thing as a "perfect programming language". Every language has it's quirks and that's fine. PHP might be old and boring but it helps you get things done faster than using the new coolest language. I disagree with you on this point. I worked with PHP for two years on some legacy systems, as well as some Laravel-based systems. While Laravel yields results that are worlds away from PHP build in the 90's, I still wasted dozens of hours because of poor constructs that the language is unfortunately coupled to. I documented each instance where I wasted a significant amount of time due to issues like scoping issues, closure problems, arrays-that-are-arrays-sometimes-but-maps-other-times, etc. PHP has gotten better. But there are so many good choices that provide much better tooling, guarantees, etc. Examples: Ruby, Go, and Elixir. Heck, even Perl is more sane about its data types in some ways by enforcing consistent comparisons with `==` vs. `eq` and much more robust data structures. I agree that every language has it's quirks. But I think PHP has so many that it seriously gets in the way often. I don't think it offers any significant velocity gains over using, say, Ruby.

dabernathy89 7y ago
Never heard anyone complain about scoping or closure issues with PHP. I'd be interested to hear more if you recall.
jamroom 7y ago
I don’t believe there are maps in PHP - just plain arrays which to be honest are pretty simple to use. Unlike say JavaScript where arrays are always numerically indexed, PHP can use any value as an index.
- azernik 7y ago
  JavaScript, by contrast, doesn't have arrays - it just has objects, which can have numerical keys. a = [] a.foo = 'bar' // works! b = {} b[0] = 42 // also works! I happen to think these designs are both INSANE, but even if you like them, PHP has no advantage here.
  - 7y ago

lone_haxx0r 7y ago

There's no such thing as the perfect programming language, but there are languages that are plainly bad. For example: I don't think anyone would seriously defend the idea that brainfuck is a reasonable language to write production code in.

cutler 7y ago

Considering PHP's pseudo-Java verbosity I wouldn't exactly classify it as a fast-to-develop language. Doc-block comments are an abomination if you come from Ruby,Python or Javascript and if you follow the numerous PSRs to the letter you're lucky if you can fit a couple of lines of real code on a screen surrounded as they will be by space-wasting blank lines, doc-block annotations and KR-style braces.

melicerte 7y ago
I guess you have not read the post you are commenting. One of the rationale behind union types is to reduce the doc-block comments. It is also, I believe, one of the idea of introducing a stronger type system in PHP. From the original post: [quote] Supporting union types in the language allows us to move more type information from phpdoc into function signatures, ... [/quote]