Live data from Hacker News

PHP – The Right Way

phptherightway.com

21–30 of 349 posts

Re: PHP – The Right Way

#21
post #5

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.

There is legacy code out there, and I think people are grateful for these frameworks :).

Re: PHP – The Right Way

#22

Quoted 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.

I'm definitely not the fondest user of PHP. There is an extreme gap between the users and the ones being able to develop the language. That gap for example, is a lot smaller in Golang.

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

#23
post #20

My 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

Re: PHP – The Right Way

#24
post #14
post #6

Earlier 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.

Same here. None of my web projects is designed for a larger audience, hence the biggest advantage of my tiny public Linux host is that it has a fixed cost. An HN “hug of death” would bring the respective application server, and possibly the whole machine, to its knees.

Re: PHP – The Right Way

#25
post #10
post #6

Earlier 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.

"new hipster" programming languages:

Python 1.0: January 1994

PHP 1.0: june 1995

Ruby 1.0: December 1996

Re: PHP – The Right Way

#26
post #23
post #20

My 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

That is not what I mean.

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

#27
post #20

My 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.

Re: PHP – The Right Way

#28
post #20

My 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…

There is 'use as'.

But it is infuriating having to namespace your code when a folder name/heirarchy could do.

Re: PHP – The Right Way

#29

Earlier 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.

As the one who did the comment, I've never seen or heard PHP devs calling themselves artisans. My phrasing was an analogy. What I meant was, don't confuse PHP with the bad practices that were propagated for years from careless devs.

Re: PHP – The Right Way

#30
post #20

My 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.

[deleted]
Post reply on HN