Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP the Wrong Way

phpthewrongway.com

Post reply on HN
Print view View original

161–170 of 194 posts

Re: PHP the Wrong Way

#161

Post by spdionis »

nercury wrote: post #86

It is near impossible to write "Modern" PHP and achieve good performance. On every request, PHP reads and parses every file that is referenced somehow. It is in direct contradiction to the language constructs the PHP itself provides - especially Exceptions, Interfaces and Inheritance. People want to use these features, because they help design better systems, where the concerns are separated, and features are plugins…

And yet PHP mostly outperforms both ruby and python.

You probably haven't even used opcache.

Re: PHP the Wrong Way

#162

Post by brightball »

paulryanrogers wrote: post #153
brightball wrote: post #151

Earlier quoted context omitted.

The underlying issue is that PHP is bad at frameworks and because of that there are dozens of them. If there was one, clear, dominant framework it would be one thing...but there's not so investing in using any particular PHP framework is just about as risky of a proposition as rolling your own.

This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's. Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.) Regardless, there has been some c…

That's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib.

That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.

Re: PHP the Wrong Way

#163

Post by [deleted] »

romaniv wrote: post #118
V-2 wrote: post #107

Why learn frameworks when you can build everything from scratch and become a true carpenter ( "building software using general purpose frameworks doesn’t make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter" ). "These people [framework creators] seems to be infatuated by the though of having other people follow their “way of doing things”, becoming some kind of PHP c…

> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry. Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often. Not to mention that learning a new framework is not fundamentally different from learning some person's approa…

[deleted]

Re: PHP the Wrong Way

#164

Post by [deleted] »

gedrap wrote: post #92

>>> The wrong way: Always use a framework on top of PHP I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me). It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't u…

[deleted]

Re: PHP the Wrong Way

#165

Post by PolCPP »

RyanZAG wrote: post #59
PolCPP wrote: post #46

Earlier quoted context omitted.

Also, he mentions that company uses framework, won't scale and start ripping it apart to take unnecesary parts. You don't do that for a 50 line script

You often do though: as in, if each independent problem was handled by a microservice PHP script, it would just be a 50 line script. But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.

Theres a few things here.

1.- Massive project where you're not using 75% of the framework.

Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working.

And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need.

Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller

2.- Separate parts stuck on a massive project

Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works.

3.- Those microservices may not follow a standard.

While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily.

On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).

Re: PHP the Wrong Way

#166

Post by [deleted] »

kbenson wrote: post #137
MustardTiger wrote: post #112

Earlier quoted context omitted.

I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". It is just normal. Perhaps t…

Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially cre…

[deleted]

Re: PHP the Wrong Way

#167

Post by programminggeek »

CiPHPerCoder wrote: post #113
programminggeek wrote: post #93

PHP is really great. I'm not sure why so many people hate it so violently. It's useful and runs like 1/4th of the web.

You're thinking WordPress, which runs 25% of the web. PHP runs a lot more. Over 80% according to w3techs.

My bad.

Re: PHP the Wrong Way

#168

Post by codedokode »

throwanem wrote: post #154
gedrap wrote: post #92

>>> The wrong way: Always use a framework on top of PHP I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me). It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't u…

> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in thei…

The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something.

This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support.

ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM.

ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.

Re: PHP the Wrong Way

#169

Post by codedokode »

mseebach wrote: post #68
throwaway1974 wrote: post #14

Earlier quoted context omitted.

"The very existence of PHP is a contradiction" Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes. PHP is a hammer, bla…

PHP is pretty objectively bad. For every thing PHP does decently well, something else does it better. Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later…

There are more popular and worse languages, for example Javascript:

- no classes (so people end up emulating them: Backbone has methods to emulate class declaration and class inheritance)

- no type hinting. You cannot specify function argument type or return type. It makes code harder to read and to maintain.

- too forgiving. You can divide by zero or mistype a property name and get no error. You can add arrays to strings. It makes bugs harder to find.

- no coding standard. Everyone uses whatever style they like

- no single modules standard

- no syntax for asynchronous operations

- difficult to install XML library on Windows (you need to setup a Visual Studio to compile binary modules)

> Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.

You have to learn Linux and command line to use Ruby. No wonder it is more difficult for a newbie. Deploying and running an application is more complicated in Ruby. Also with long-living applications it is easy to get a memory leak.

But recently PHP started to depend more on CLI tools too (installing and using composer might be not easy for people who got used to GUI and don't understand concepts like "working directory").

Re: PHP the Wrong Way

#170

Post by codedokode »

TeMPOraL wrote: post #133
throwaway1974 wrote: post #53

Earlier quoted context omitted.

PHP "can be" used as a templating engine, but its not the right way to do it nor do you have to use it in that manner. The correct way is to use Twig for your templates PHP is alot more than a "templating engine" if thats all you think of it then that is your choice

Template engines are one of the more ridiculous inventions on the web, if you think of it. Doubly so if you have them in PHP, which is a perfectly good template engine - sure the syntax could be better, but the popular templating engines are even worse at any but most trivial tasks. They all start as an attempt to remove the possibility of writing meaningful code in them[0], and then grow cruft until they become Turi…

PHP actually is a bad templating engine for HTML because it doesn't have a feature to convert special characters to HTML entities by default. It is easy to forget a call to htmlspecialchars() (especially for beginners) so the code gets vulnerable to XSS.

That is why you should prefer Twig or other templating engine with autoescaping.

> They all start as an attempt to remove the possibility of writing meaningful code

I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/

Post reply on HN