Live data from Hacker News

PHP the Wrong Way

phpthewrongway.com

131–140 of 194 posts

Re: PHP the Wrong Way

#131
post #40

Earlier quoted context omitted.

PHP was the first language I ever used professionally. The code I wrote - the code every single one of my colleagues wrote - was atrocious. We were paid bottom dollar ($30k in 2008) to write absolute shit code. The PHP community in my area was the same. All newbies, all paid barely more than a fast food manager, all writing code that could be taken down by a HS student with Fiddler. I'm sure different experiences exi…

PHP is so vast that it's a ghetto, the rich uptown area, a sprawling suburban middle class, and more. I share some of your experiences - I'm disturbed by how easy it is for people without basic coding knowledge to make money "building php websites". But I also see and run in to a large number of people who can do fantastic PHP code (testable, documented, clean, modular, etc). One thing I've noticed is that most of th…

> someone's PHP code quality is higher if they've done more than just PHP.

That's how most quality frameworks for PHP were born, by folks having used other languages.

That being said, I find Symfony3 to be very decent. I was surprised by the quality of its documentation.

Re: PHP the Wrong Way

#132
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…

> So, to sum up, the author here is right: this is insanity, until PHP provides a module system that can handle PHP abstractions. I suspect you're being downvoted because we have this: https://getcomposer.org + https://secure.php.net/manual/en/language.oop5.abstract.php

I worked with PHP for 5 years and I am well aware of the composer; I am being downvoted because I said that author is right on some point.

Re: PHP the Wrong Way

#133

Earlier quoted context omitted.

> 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. It got a bad name due to the weird nature of PHP which is still a template engine , no matter how much features you had on top. It's like developing webapps in pure HAML, Jinja or Handlebars. PHP a…

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 Turing-complete due to the needs.

The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.

I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.

[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.

Re: PHP the Wrong Way

#134
post #90

Earlier quoted context omitted.

No, you use PDO::quote().

No, you use $pdo->prepare("SELECT id FROM foo WHERE bar = ? AND baz = ?") ->execute([$baz, $qux]); ...while taking care to set PDO::ATTR_MODE to PDO::ERRMODE_EXCEPTION and PDO::ATTR_EMULATE_PREPARES to false when your PDO object is initialized. https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4... See also: http://stackoverflow.com/a/12118602/2224584

This is the problem I have with PHP. 15 ways to do something seemingly simple, and only one obscure way is correct (What's PDO::ATTR_MODE ?) And why does PDO try to emulate prepares ?

Re: PHP the Wrong Way

#135

The usage of that Paul Graham quote is hilarious. The author misses the point entirely! Graham uses the word pattern to describe a repeated piece of code that matches a pattern. And it's a sign of trouble: a violation of the DRY principle. Nothing to do with design patterns really. Are all the other quotes used as unsuitable, we don't know.

No, the author does not miss the point - though I assume he may not understand it fully. The quote is written in context of Lisp macro facilities, which let you DRY your code from a lot of things, including GoF-style design patterns. So e.g. if you see yourself using "Memento pattern" (or whatever) in many places in your code, writing the same kind of methods doing the same thing everywhere, you should consider writing a macro that'll do that for you instead. That is, if your language lets you do that. Design patterns really start where the language's ability to abstract ends.

Re: PHP the Wrong Way

#136
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…

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…

Not sure why you think it doesn't happen in other fields. Every time I spoke with a software developer, they were constantly cursing the architecture of the code they had to dealt with.

Re: PHP the Wrong Way

#137
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…

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 creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO.

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

Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").

Re: PHP the Wrong Way

#138
post #73

Earlier quoted context omitted.

Frameworks allow you to shoot yourself in the foot with a Tank.

Perfect example. You nailed it! (Anyone close to familiar with tanks will know it will take quite some effort compared to any of the smaller alternatives ;-)

But you can easily get yourself crushed by a tank, and also "why oh WHY DID YOU DRIVE A TANK TO PICK UP OUR KIDS FROM THE SCHOOL?!?"

Re: PHP the Wrong Way

#139
It's rather a shame that the author of this site has chosen to be anonymous; I should like to understand why they choose to reject a number of points generally considered best practice in software engineering, regardless of programming language: patterns; frameworks; library reuse; standards bodies etc.

This unfortunately sounds like the cry of a programmer who has worked on their own for years suddenly encountering the requirements of working with a team of coders.

Re: PHP the Wrong Way

#140

Earlier quoted context omitted.

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

> Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often I think this is just confirmation bias - you won't notice all the times you are not fighting the framework, but you do when you are. > Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things Only if "some person" is real fast…

[deleted]
Post reply on HN