But what's the point? The beauty of perl scripts, and later php templates, was in their BASIC-like simplicity. They were not secure or structured in any way, but very accessible. Once you add these frameworks, you realize you could have started with Python or Java in the first place and get more mature infrastructure and better language along the way.
PHP – The Right Way
21–30 of 349 posts
Re: PHP – The Right Way
#22Quoted post unavailable.
Yet this internet myth of "PHP no bueno" persists. Don't confuse the tool with the artisan. PHP is an incredible language that's getting more mature with each new release.
Language improvements didn't happen until Hack started being a thing. The performance was a shitshow for 20 years until they got help from Intel engineers. Some of those fixes were extreme low hanging fruit, simple profiler based optimizations -- again, why was this not picked up sooner, imo due to said gap.
Also the community has a severe case of Stockholm syndrome. Always on the extreme defense of the language and the big frameworks (Symfony, laravel). It's a community which shuns other languages and makes fun of Enterprisey Java solutions, yet the average project made in Symfony reminds me of one thing, Java Enterprise projects. The practical difference being they swapped XML for YAML.
Re: PHP – The Right Way
#23My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
Re: PHP – The Right Way
#24Earlier quoted context omitted.
In the mid-00s the main selling point of PHP were shared hostings with mod_php which was a cheap way to host your own web site and database. Now with the cloud that advantage is utterly gone.
For my tiny website there is nothing that cloud brings other than being more costly. I have the same access to my shared hosting, and the amount of money per year is peanuts.
Re: PHP – The Right Way
#25Earlier quoted context omitted.
In the mid-00s the main selling point of PHP were shared hostings with mod_php which was a cheap way to host your own web site and database. Now with the cloud that advantage is utterly gone.
Shared hosts are still there, and are cheaper and much simpler to use than your average cloud based deployment. Some even support these new hipster programming languages ruby and python.
Python 1.0: January 1994
PHP 1.0: june 1995
Ruby 1.0: December 1996
Re: PHP – The Right Way
#26My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
You can `use Illuminate\Mail as Mailer` if you want
It would not prevent a clash with another "Illuminate" namespace.
The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it.
Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.
Re: PHP – The Right Way
#27My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
I think that neither do make assumptions on how the code is called when used, only one is preventing name collisions.
Re: PHP – The Right Way
#28My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
But it is infuriating having to namespace your code when a folder name/heirarchy could do.
Re: PHP – The Right Way
#29Earlier quoted context omitted.
Yet this internet myth of "PHP no bueno" persists. Don't confuse the tool with the artisan. PHP is an incredible language that's getting more mature with each new release.
Why do PHP developers insist on calling themselves artisans? Give me a call when PHP ditches backwards compatibility and cleans out all the shit from the standard library - 5845 global functions always available, most of which you are just supposed to know are shit... Just a nightmare.
Re: PHP – The Right Way
#30My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
The way I see it is that you alias the import mail as mailer. You hope there are no other libraries called mail in your import path. PHP fixes that by requiring all libraries called mail to be dependent on their own namespace so that there will be no collisions. I think that neither do make assumptions on how the code is called when used, only one is preventing name collisions.