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

141–150 of 194 posts

Re: PHP the Wrong Way

#141

Post by throwaway729 »

sangnoir wrote: post #130
romaniv wrote: post #118

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…

> Let me put it this way - I would rather maintain something that used those projects and not some custom solution written by a nameless developer in the same era

I wrote a very large PHP application around that era.

You are absolutely correct. Even I have a hard time maintaining that code.

Re: PHP the Wrong Way

#143

Post by rimantas »

mgkimsal wrote: post #52
Shanea93 wrote: post #49

Earlier quoted context omitted.

And since then tools such as Composer and Symfyony3 have been released. It's been almost 10 years. Hell, even Magento2 isn't that bad, if you can look past the awkward dependency injection they're in the process of fixing. PHP in 2008 is very different to PHP in 2016. PHP frameworks in 2008 are very different to PHP in 2016. PHP developers in 2008 are very different to PHP in 2016.

Just because those tools exist doesn't mean people use them. There were decent libraries and high quality code back in 2008 (and 2000) but people didn't necessarily use them. It's arguable somewhat easier today, but that's a relative term. If you're FTPing code from BBedit or Dreamweaver up to your godaddy shared hosting and clicking buttons in cpanel... composer/symfony won't help.

  > Just because those tools exist doesn't
  > mean people use them.
But, oh, they do! At least there in most of the jobs you will deal either with Symfony or with Laravel.

  > here were decent libraries and high quality code back in
  > 2008 (and 2000) but people didn't necessarily use them.
Please, name a couple from each year. PHP started to mature since PHP 5 and that was released in 2004. While you could have working and tolerable code before that the language was lacking features for high quality code. Maybe if you reframe that as "high quality given the limitations" I'd accept that. But I am seriously curious what would you consider high quality PHP libs from 2000.

Re: PHP the Wrong Way

#144

Post by brandon272 »

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…

More often than not, when I have inherited a project built on a common PHP framework the documentation and community knowledge available is limited because the framework used is, most commonly, not the latest version. So you are basically wading through the tall grass of online resources trying to ascertain what knowledge applies to what version, which for some frameworks can differ tremendously between major releases.

Many developers love a particular framework and they use it as often as possible and it works well for them, one reason being that over time they become familiar and accustomed to it's strengths, patterns, flaws and idiosyncrasies. But I personally find no pleasure in having to familiarize myself with a crusty old framework that I will never touch again in my career versus well-organized vanilla PHP.

Re: PHP the Wrong Way

#145

Post by reitanqild »

TeMPOraL wrote: post #138
reitanqild wrote: post #104

Earlier quoted context omitted.

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?!?"

Have my upvote.

Then again, most frameworks are more comparable to cars than tanks and people use cars all the time to pick up kids at school even if they could just walk.

Convenient you know and less chance of getting mistaken for a hipster :-]

Re: PHP the Wrong Way

#146

Post by stephenr »

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…

Couldn't agree more.

I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.

Re: PHP the Wrong Way

#147

Post by stephenr »

CiPHPerCoder wrote: post #115
greyman wrote: 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

Named parameters are much simpler to use IMO.

Re: PHP the Wrong Way

#148

Post by stephenr »

roblabla wrote: post #134
CiPHPerCoder wrote: post #115

Earlier quoted context omitted.

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 ?

That was 4 ways. The documentation identify what the options do.

Re: PHP the Wrong Way

#149

Post by kyberias »

TeMPOraL wrote: post #135
kyberias wrote: post #120

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

No, I don't think so. That's not a critique towards design patterns. It's critique towards ANY CODE THAT IS REPEATED. If I use a certain design pattern once in my code, I didn't repeat anything. Macros don't remove the design pattern, they just allow me not to repeat myself.

Re: PHP the Wrong Way

#150

Post by CiPHPerCoder »

stephenr wrote: post #147
CiPHPerCoder wrote: post #115

Earlier quoted context omitted.

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

Named parameters are much simpler to use IMO.

Simpler? No. Easier? Yes.
Post reply on HN