
PHP the Wrong Way - Illotus
http://www.phpthewrongway.com/
======
V-2
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 community leaders, and having other people use their latest “hip” Open
Source tools..."_

How lame of these people.

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.

On the other hand, if the codebase has been written from scratch by Greg, a
real carpenter of a programmer, who is no longer with the company, then good
luck. I'm at his mercy entirely.

I'll be having his "way of doing things" for dinner whether I want it or not,
the only difference is that I won't have a community of other people in the
same situation.

This aspect isn't addressed by the author at all, although he found just
enough time to provide us with a psychological analysis of framework authors
and their narcissist motivations :)

~~~
MustardTiger
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 the low barrier to entry and
corresponding low average experience of web developers plays a part in this
mentality.

~~~
kbenson
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?").

~~~
MustardTiger
> If you came upon someone's custom HTTP client, I imagine your response would
> be something along those lines.

No, why would it? What HTTP client framework am I supposed to be wishing they
used?

~~~
kbenson
Maybe cURL? Some other one I don't know of (I know the ones in my preferred
languages). Do we really need to also be responsible to dealing with already
solved problems as well as the problems specific to our domain? Do we really
want to _also_ deal with the not-fully-compliant HTTP client or making sure we
support HTTP/2, or do we want to use widely accepted solutions for those so we
can focus on the real problem at hand (which is usually not the intricacies of
HTTP negotiation, or some other well understood and supplied need).

~~~
MustardTiger
Curl isn't a framework.

>Do we really need to also be responsible to dealing with already solved
problems as well as the problems specific to our domain?

No? What does that have to do with anything?

>Do we really want to also deal with the not-fully-compliant HTTP client or
making sure we support HTTP/2, or do we want to use widely accepted solutions
for those so we can focus on the real problem at hand (which is usually not
the intricacies of HTTP negotiation, or some other well understood and
supplied need).

Did you reply to the wrong comment by mistake or something? What does any of
this have to do with me or what I said?

~~~
kbenson
> Curl isn't a framework.

I wasn't under the impression we should be limiting this to frameworks. What's
the difference between a framework and a library for the purpose of this
discussion? I think they are functionally equivalent. I was clear to equate it
to crypto originally, which doesn't really make sense when viewed as applying
to frameworks only. We're a couple comments removed from that, I thought that
wasn't in question. Same with an HTTP _client_. Frameworks don't event
necessarily implement clients. I'm addressing NIH syndrome, and I don't think
frameworks really deserve special consideration in any way.

> Did you reply to the wrong comment by mistake or something? What does any of
> this have to do with me or what I said?

See above. And I've been sticking with the same examples since the first
comment. Why is this all of a sudden not making sense?

~~~
MustardTiger
>I wasn't under the impression we should be limiting this to frameworks

The discussion is entirely and solely about frameworks..

>What's the difference between a framework and a library for the purpose of
this discussion?

Wikipedia exists.

>See above

Above what? Nothing you said above answers my question.

>And I've been sticking with the same examples since the first comment. Why is
this all of a sudden not making sense?

Because it has absolutely nothing to do with anything I said, like I clearly
stated.

~~~
kbenson
_My point was_ frameworks are functionally no different than a large complex
library, and as such, the same arguments apply.

That said, I'm not entirely happy with the way the tone of this conversation
is heading, so I'll excuse myself now.

~~~
MustardTiger
>My point was frameworks are functionally no different than a large complex
library

You'll have to forgive me for not guessing that given that nothing in your
post came anywhere close to even suggesting anything of the sort. I am limited
to reading what you write, and can not read your mind.

Yes, frameworks are different from libraries. Boy, that was productive.

------
gedrap
>>> 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 use one, you end up writing a
poor one, unless all you need is a page that outputs a result of a single SQL
query, or something equally trivial.

I've seen plenty of 10k+ LoC applications with home made frameworks, poorly
replicating open source ones, just because.

>>> In the world of Python and Ruby building websites from the ground up is
tiresome because neither Python nor Ruby was originally created to build
websites. As a result general purpose frameworks such as Django and Ruby on
Rails quickly became popular for building websites in these languages.

RoR, Django became popular because it's so simple to build basic CRUD apps,
which most of the applications are. Most of the stuff is done for you. Can't
say the same about plain PHP. The author largely ignores the reasons why the
mentioned frameworks became popular.

Yes, you could make a well engineered solution from scratch. But chances are
that you will not, time constraints being one of the reasons.

Sorry, couldn't read further than that.

~~~
throwanem
> 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 their documentation that a specific and entirely
innocuous-looking schema option causes the ORM to produce a query containing a
Cartesian join.

You can use an ORM. Or you can write SQL, work with arrays, and keep your code
and data separate. None of that is terribly difficult, and you are responsible
for the results no matter what you do. If you can't trust yourself not to get
basic things right, you have problems at a level that no library will solve.

~~~
codedokode
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.

~~~
joesmo
Doctrine 2 also often spends _10x_ the time on post-processing the data from
the database as it does actually making the database calls itself (it's not
fixable without dropping to straight SQL out of the ORM). Its query language
is atrocious and unnecessary. Their ideas of joins and internals are
absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the
perfect piece of code (it's exactly the opposite: total and utter shit), I'm
not going to slow down all my DB queries 10x for _anything_ , not to mention
the incredibly slow development speed of now having two query languages and a
million wrong ways of making simple queries and no ways of making proper
advanced queries. Everything with Doctrine takes many times longer than with
straight SQL even after years of working with it. I have yet to find an ORM
that doesn't have egregious failings like Doctrine 2. It is inherent in the
stupid concept of ORMs that implementations fail. See:
[http://solnic.eu/2015/09/18/ditch-your-
orm.html](http://solnic.eu/2015/09/18/ditch-your-orm.html)
[http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern](http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern)
and most importantly, see benchmarks for ORMs like Doctrine and observe their
destructive effects on programmer productivity.

~~~
codedokode
I agree, Doctrine has performance problems. I did some microbenchmarks too.
But you could try to optimize (or write your own custom) mapping code, or
maybe you could load less entities or write a better ORM. Sometimes you have
to use SQL queries too (when the result of a query cannot be mapped to
entities).

The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and
classes you will get undocumented JSON trees (or arrays) passed around.

> [http://solnic.eu/2015/09/18/ditch-your-
> orm.html](http://solnic.eu/2015/09/18/ditch-your-orm.html)

It seems to me that author wants to replace complex approach (OOP and ORM)
with even more complex one. So instead of having one object representing an
entity we can have ten objects representing the entity at different moments in
time. So we have to find out which one is the latest. And we will need even
more memory to keep them.

He writes:

> There is no User but it’s very likely there is SignupUser.

And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport
and others. And a bunch of methods to convert between them.

I don't understand what is the problem with mutable entities. They are
supposed to be mutable. I never had problems because of functions modifying
arguments given to them.

I don't believe functional programming can be use instead of OOP. Can you
represent a DOM tree, collection of GUI widgets, a graph of related database
entitites, a form with validation rules with functional programming? You will
just end up emulating classes and objects.

The author probably just likes the idealized concept and did not try to apply
it to a real world application (but if anyone did it would be interesting to
see the code).

I also took a look at Ruby Object Mapper he mentions in a post and don't
really like it. It uses arrays (that are called ROM::Struct there) a lot and I
don't see much functional programming there.

I also have read this article
[http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern](http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern)
and I partially disagree with the conclusion. Using key-value storage instead
of a database is generally bad idea. It doesn't solve "N + 1 queries" problem,
it doesn't provide foreign keys (and often transactions), and you have to
write messy custom code instead of shorter and better readable SQL query
(example: [https://www.kchodorow.com/blog/wp-
content/uploads/2011/12/SQ...](https://www.kchodorow.com/blog/wp-
content/uploads/2011/12/SQL-to-MongoDB2.jpg) ).

~~~
throwanem
> And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport
> and others

You...really can't think in any paradigm other than object-oriented
everything, can you? I mean I guess it works for you and that's great but
_please stop you 're really scaring me now._

------
omginternets
Is it me or is the author confused about the distinction between a library and
a framework?

To me, a framework implies inversion of control: you don't call the
framework's code; the framework's code calls _your_ code.

Granted, he skirts the issue with phrases like "A framework is a system that
helps you build software, but at the same time it forces you to work within
the limitations and restrictions of the framework itself", but this describes
what a framework achieves, not what it _is_.

Call me pedantic, but this I find this indicative of poor understanding, and
this article raises a number of red flags along these lines, such as this gem:

>PHP on the other hand was created from the beginning by Rasmus Lerdorf as a
set of tools written in C that would enable you to easily and quickly develop
dynamic HTML. As such PHP was, and still is, a framework in and of itself.

Uh... what?

Maybe I'm overstepping my bounds, but this article is furthering certain
stereotypes about PHP-programmers.

~~~
Fuxy
I kind of get what he is saying but he is saying it very badly I believe
Jeffrey Way the same things a lot better.

Yes you don't need a framework all the time you don't need to do OOP all the
time or follow design patterns all the time but the cases in which you don't
need to do that are edge cases that very few programmers run into.

Also if you think PHP is a framework then it must be the worst framework ever
designed. Libraries exist precisely because they were required to smooth out
the inconsistencies and insanities of the underlying language tools.

A framework is just a collection of libraries wove together with some sane
default ways of doing things. Some even allow you take them apart and
customize them but they give you a good starting point.

If the way the framework does things is not good for your requirements you can
try another and only if you are absolutely certain none of them do the job
should you roll your own because once you do the barrier to entry for someone
new to the code base will be that much higher.

The only thing I do agree with is that security should be a consideration in
the development process but here we get back to the fact that a tried and
tested framework has already dealt with the most common security issues and as
long as you don't do something stupid in your own code you should be OK.

~~~
omginternets
I agree that OOP and frameworks aren't necessary _in principle_. I vehemently
disagree with the notion that they aren't needed _in practice for PHP_.

I further contend that a PHP programmer advocating against the use of
frameworks who doesn't show a clear understanding of what they actually are is
not to be trusted. I even go out on a limb to claim that this is
representative of the ills of the PHP community at large. That last part, I
willingly concede, is debatable and ultimately beside the point :)

To return to the crux of the argument -- that frameworks are not necessary in
principle -- I would like to add that this assumes a well-designed standard
library. I don't use frameworks with Go, but I sure as hell use them with PHP
because the latter is an absolute minefield.

That someone advocating pragmatism would miss this point is astounding. My jaw
has dropped and shattered to the floor. How can you rail against principled
approaches to software design (a strange position to take, independently of
the current debate) only to get hung up on the theoretical feasibility of
writing PHP without a framework?!

It's further bewildering that the author would advocate a _pragmatic_ approach
to building software, yet neglect that frameworks offer a pragmatic solution
to the security concerns that plague PHP. It's almost as if he doesn't
understand the terms he's using!

------
Practicality
PHP is the very different from development in C# or Java. Anyone from those
backgrounds pretty much automatically hates it. PHP will punish you hard for
designs that would be fantastic in .NET or Java.

It's also very different than Perl or Python. It tries to be specific to the
web and that makes a lot of oddities that the more general languages do not
have.

OTOH you can make a fantastic design in PHP. It's just that there are very few
people who know how to do that. Frankly, because it's not taught... anywhere.

So, yeah, as much as I've learned how to use PHP (through 11 painful years),
it's really hard to figure out how to use correctly. It's possible.

The ideal PHP design (currently) is a hybrid between OOP and straight script
that will look bizarre to anyone from, well, any other background. As others
have mentioned you have to be very careful not to load too much into memory or
you will come crashing down fast.

I still use it, because now I know how, but, ironically, I wouldn't recommend
it. It's so very different from anything else that I don't know that the
skills transfer well to other languages (other than straight-up problem
solving).

------
yedpodtrzitko
I just skimmed the website, and I am still not sure if it's meant seriously or
if it's some kind of joke? Feels a bit contradictory eg. "dont use framework"
vs "make software secure by default". Isn't a security one of the gains of
using frameworks, beside other things? You would need to be a security expert
to cover all potential security issues when writing something from a scratch.

~~~
robert_tweed
You can also build horribly insecure applications with a framework. A
framework does not absolve you from thinking, which seems to be the point the
author is making.

There's a difference between frameworks and libraries and of course it is a
good idea to use trusted crypto implementations and avoid NIH syndrome, but a
large part of security is including it in the design process from the start.

You can't just assume "the framework will handle it", or "bcrypt is all I
need" or "the opsec team will find all the problems".

It rather sounds like you're expecting the author to hand you a magic-bullet
solution, which is rather the whole point of the article: there isn't one. You
_do_ need to know what you're doing.

~~~
tclancy
The jack of all trades is the master of none. Almost no generalist is going to
be good enough to properly handle all security concerns. I like knowing my
framework is constantly upgrading password handling, XSS attack prevention and
things I haven't even heard of yet. The fact you _can_ build insecure things
in a framework isn't an argument against it and why would someone who builds a
horribly insecure app in a framework produce a better result without using
one?

~~~
robert_tweed
They probably wouldn't, but that's neither something I said, nor is it the
article's premise.

However, a framework does increase the attack surface, which is something that
should be taken into account. If you save 20 lines of code by adding a 100,000
line framework, you need to ask yourself which of those is most likely to
contain a bug?

Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs
less so, because of the need to first _find_ the bug. The odds of that
happening will increase if the bug is common and obvious, or you are a
particularly high-value target. By using a framework you effectively increase
your value as a target to the sum value of all projects using that framework.
This becomes especially bad if the framework stops being maintained, because
the value to an attacker isn't lost as quickly.

The above also applies to libraries, but libraries tend to be more focused and
more stable than frameworks, since frameworks tend to "go stale" if not
continually updated in a way that most libraries do not.

------
mirekrusin
Paul Graham's quote in "Design Patterns" section actually says nothing or the
opposite of what the author is trying to say - Paul says that when he's seeing
in the code things (shapes <<of code>>) that repeat themselves, it's an
indication to him that he's missing some macro definition that would build
this shape for him so he doesn't need to repeat himself by manually creating
it all the time - that he can reuse it (as macro).

How does it relate to design patterns? Does it say not to use them? Absolutely
not. It says the opposite, if anything - to recognise patterns in your code.
"Design patterns" is just an idea that if you see your patterns repeating
themselves (some of your macros tend to be very similar in different projects)
then you should give it a name. This way when you explain system to your
colleagues it's easier to communicate.

------
iamd3vil
I generally agree with the view of keeping your application simple and not
using big frameworks but after seeing so many PHP programmers write spaghetti
and insecure code, I pretty much recommend frameworks now. You can say the
problem is not with writing PHP without any framework but with the
programmers, the problem lies with the low barrier for entry into PHP.
Frameworks atleast teach you how to make your code modular and make your
application secure (atleast sane defaults).

~~~
phillu
In my experience using a framework does not prevent spaghetti code.

~~~
iamd3vil
If you want to write spaghetti code, you can write it whichever approach you
take. It's more about making it difficult to shoot yourself in the foot.

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

~~~
reitanqild
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 ;-)

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

~~~
reitanqild
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 :-]

------
jpnave
So the author considers following PSR guidelines beyond 1 and 2 to be "the
wrong way"?

PSR-4 is the currently accepted best practice for autoloading and while it
"may [have] a direct effect upon how you code your software," it's the optimal
approach for 99% of projects I've encountered.

Following community interoperability guidelines is what allows developers to
move away from monolithic frameworks and compose projects based on the
packages they need.

~~~
stephenr
> currently accepted best practice for autoloading

According to who? FIG?

Are you aware that php has a built in auto loader that supports namespaces and
is written in C?

> compose projects based on the packages they need.

Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know
what this is but I'm gonna lick it" approach to development, where you end up
with 50 "micro-frameworks" or "utility libraries" each of which depends on a
further 20 other libraries.

I have some issues with this site but it's right that the FIG is a joke, and
anyone who claims its "best practice" is not paying attention.

~~~
jpnave
> According to who? FIG?

According to the vast majority of authors of the most widely used and tested
PHP libararies.

> Are you aware that php has a built in auto loader that supports namespaces
> and is written in C?

You mean the autoloader builtins that composer uses under the hood already?
This is better than a 1 line include how exactly?

> Ah, the NPM/Composer golden brick road to development. Aka, the "I don't
> know what this is but I'm gonna lick it" approach to development

I don't understand what you're saying here, everyone should be writing their
own libraries from scratch? It has always been up to the developer to vet the
dependencies they choose to include in their project. That applies to every
language ecosystem, not just Node.

~~~
stephenr
> According to the vast majority of authors of the most widely used and tested
> PHP libararies.

So, FIG.

"Group of developers say that groups' work is the best. News at 11."

> You mean the autoloader builtins that composer uses under the hood already?

No, spl_autoload is a working namespace aware autoloader. Composer uses a
bunch of userland code.

> I don't understand what you're saying here, everyone should be writing their
> own libraries from scratch?

Did I say that? I've seen, multiple times the negative consequences of the
current fad to rely on 25 separate, single-purpose 3rd party Libs, all of
which are basic functionality that a well thought out library would give you,
but with the added "bonus" of each relying on 20 other libraries to do basic
things.

> It has always been up to the developer to vet the dependencies they choose
> to include in their project. That applies to every language ecosystem, not
> just Node.

Do the vast majority of developers know that? Because the ones I've had the
"pleasure" of working with, definitely don't.

------
d3ckard
I do not want to be mean, but I honestly feel there is no 'right way' in case
of PHP. There are communities that care about 'doing it right' and there are
some that want just to 'get the job done'. I prefer the former, PHP always
seemed to prefer the latter.

~~~
Shanea93
This is a massive overgeneralisation of a humongous amount of people and man-
hours of work. Why do you feel this? Do you have anything to back up this
statement?

Anecdotally speaking, I'm a Senior Software Engineer working with Go and PHP.

We use Go when working on performance critical code, because for us that's
where it excels.

We use PHP when we need simple interoperability with the legacy Magento site
our company runs and for jobs like running a CSV importer or some other oft-
visited-task. We both get the job done and care about doing it right. You can
write some truly beautiful code in PHP if you have the correct level of
patience, process and experience behind you.

~~~
pc86
99% of people who get paid to write PHP do not have the requisite level of
patience, process, or experience to write a fibonacci method let alone write
"truly beautiful" PHP.

~~~
Shanea93
It's really easy to make up statistics on the spot with absolutely no source.

I very much doubt that people would be getting paid to write any code if they
couldn't implement a single for loop in their primary programming language.

~~~
pc86
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 exist, but the majority of folks who I speak to
have experiences that match mine very closely.

PHP is a ghetto.

~~~
mgkimsal
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 the people who can do _good_ PHP code
(at least in the sense that it's _not crappy_ ) have also worked in other
languages/tech, either before or during their PHP work. I know the exceptions,
but for the most part, someone's PHP code quality is higher if they've done
more than just PHP.

~~~
wooptoo
> 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.

------
czarpino
This is satirical right? Unless you're building something super trivial, a
framework is the way to go. You end up reinventing the wheel anyway.

Here's a sober reason why to use a framework [http://symfony.com/why-use-a-
framework](http://symfony.com/why-use-a-framework).

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

~~~
TeMPOraL
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.

~~~
kyberias
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.

~~~
TeMPOraL
You rarely use design patterns _only once_ in a project. And while this quote
does not cover it, you can also use macros to better communicate that one-off
design pattern instance - instead of identifying a pattern by noticing a set
of familiar methods or a typical inheritance graph, the person reading your
code can just see the the macro invocation and know he's dealing with a
particular design pattern here.

Design patterns aren't bad per se, even if they imply some problems with
language's capabilities to abstract - because they shift an abstraction from
code to programmers' shared knowledge. The problem is with what I would call
"design-pattern-driven development" \- attempting to fit your problem into the
bunch of design patterns you know. It's unfortunately very common.

~~~
kyberias
I don't think there's such a problem really. We all try to fit the problems we
encounter in designing software into a bunch of knowledge that we know. That
bunch might be a set of design patterns. There's nothing wrong with that.
Sometimes they fit perfectly and sometimes they don't. Sometimes the software
we produce is not perfect.

------
laurent123456
The problem is that companies that don't use frameworks end up re-implementing
their own as complexity grows, and of course usually do so extremely poorly.
No matter what, for any non-trivial application, you DO need a framework - the
choice is either to use an existing one or to implement your own. The big
advantage of existing ones, in my view, is that they are well documented and
everybody can learn them. That pretty much never happens with bespoke
frameworks.

------
mediaserf
This is awesome, thank you! PHP may have started out as a "set of tools", but
it evolved into a complete language. Like any programming language, you can
write sloppy code or elegant code in PHP - with or without a framework.

Languages are foundations on which frameworks and design patterns can be built
to solve common problems. The trap that we fall into is trying to fit all of
our problems into those common ones that frameworks and design patterns solve.
This leaves potential edge cases that become bigger problems.

PHP can be has hacky or as elegant as you make it. The versatility of that
makes it a great utility. It also makes it very approachable. This is a big
contributor to why it runs a big part of the web.

------
fareesh
IMO one of the key missing points here that is not really considered, is that
when you use a well documented and relatively mature framework, it greatly
simplifies some of the non-programming related aspects of software
development, particularly with regard to getting new developers up to speed,
and ensuring that even your junior-most developers are able to contribute
without having to become heavily acquainted with your specific implementation
of authentication, file uploads, routing, etc.

------
siegecraft
The entire argument could be reduced to: "be informed, and make good
decisions" which is a very banal statement that could be applied to almost
every endeavor in life. Because PHP makes it so easy to be productive without
being informed you run the risk of unknowingly making bad decisions. There is
an exhortation to use frameworks so that if you aren't informed you at least
get the guide rails / hand-holding / best practices that the framework imposes
on you.

------
artificialidiot
The article pretty much applies to any comparable language, really.

------
efficax
This is why I don't use Cocoa to write iPhone apps, or Swift, but ARM
assembly. True carpentry! Jesus was a carpenter too, and God spoke the machine
code of the universe.

------
paulgrimes1
If every project had unlimited budget and only quality developers, this site
would be a little bible. The reality is much different - communities exist so
we can stand on the shoulders of our peers :)

------
Olap84
Wait, is this satire or not? Does it advocate people don't use frameworks?

Loved the opening paragraph though

~~~
syntex
It's definitely not a satire. They are some valid points. It's not against
using frameworks. I think it's more about finding the right solution for the
problem.

~~~
Olap84
What I take from is not to use PHP, which I do as it pays the bills, but why
would anyone choose it for a new project baffles me. This article doesn't help
it.

~~~
fredleblanc
I love PHP. It feels like a complete toolbox to me, whereas other languages
like Python or Ruby feel like I'm buying an entire Home Depot for every
project. Sometimes you need the whole store. Most times I don't.

I think the OP has some good points about reconsidering the standard answers
that everyone gives to questions when asked. There are no silver bullets in
web, but many things sure are treated like them.

Maybe there are projects where PHP isn't right. There are probably tons. But
that doesn't mean that it's always wrong. PHP is what got me into making web
things in the first place. I loved (and still love) how utilitarian it can be.

But perhaps that's where I differ from most people. I see myself as someone
that makes web stuff. Most seem to see themselves as app creators or system
builders. And they probably are. Sure, I do that too when the time comes, but
if most of the time I'm building a front-end to a CMS, I'm hardly
"engineering" anything. I'm mostly just trying to make specific art for other
people.

Anyway, I don't understand why PHP would immediately be ruled out from this
article. It feels like the JavaScript of the server-side world to me. Use as
little or as much as you want. You can do awful things with it, but also
wonderful things.

~~~
Olap84
Well I certainly agree with the right tool for the right job. And PHP has some
roles. My point was more about the article, which would, imo, put programmers
off PHP with its contrariness and smugness.

------
vlunkr
So if I was starting a new project now, I shouldn't use a framework or any
pattern too strictly, so.. what do I do? Following this logic will give me
spaghetti code and reinvented wheels. If there are some basic patterns to
follow they should be included here.

~~~
corobo
My feeling is I should just start coding with whatever I know and not bother
getting involved in arguments about the underlying language. Time is money
friend!

------
tga
There is a grain of truth in what they're trying to say, but the conclusions
are outright misguided.

My favorite is "The wrong way: Thinking of patterns when solving problems."
\-- textbook reinventing the wheel / NIH.

~~~
pvdebbe
I don't think it's saying exactly that. One should think up a solution first,
then see if one needs patterns to fit that solution into the code base in
language of choice. PHP certainly doesn't need all of Gang of Four recipes due
to dynamicity and other factors.

------
qwertyuiop924
I'm not a huge fan of OO, but this gets the history of OO soooo wrong. I mean,
really, this has to be a joke.

------
swalsh
PHP is certainly a unique community, a very pragmatic bunch they are, but
that's why we love em'

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

~~~
CiPHPerCoder
You're thinking WordPress, which runs 25% of the web.

PHP runs a lot more. Over 80% according to w3techs.

~~~
programminggeek
My bad.

------
paulgrimes1
This reads to me as a parent saying to a kid (me) "Well, you _could_ stick
your hand in the fire, but.."

------
nercury
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 instead of
hardcoded all over the place.

Unfortunately, the required files for a request can pile up quite quickly, to
the point where bytecode cache does not help, serving multiple requests per
PHP load does not help, prewarming cache for frontend such as Varnish does not
help, memory usage is over the roof because of trashed heap memory.

So, to sum up, the author here is right: this is insanity, until PHP provides
a module system that can handle PHP abstractions.

~~~
CiPHPerCoder
> 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://getcomposer.org) \+
[https://secure.php.net/manual/en/language.oop5.abstract.php](https://secure.php.net/manual/en/language.oop5.abstract.php)

~~~
nercury
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.

------
michaldudek
And that's how Laravel was born...

This website should be taken down. Wanna be back to the 2000's, are we?

------
spdionis
Between composer and symfony and php 7 I would say PHP is ahead of both ruby
and python communities in terms of code quality, perfomance and ease of
deployment.

There are some minor drawbacks in the core language, nothing compared to the
python 2/3 split and all the virtualenv and packaging mess, and the sub-par
arhitecture of rails (as far as i heard).

Mind you this is limited to web development, php does not shine in any other
field.

People FTPing their code to a server or writing code in pure (probably sub-
optimally designed) PHP beyond trivial scripts and web pages are not
representative of the PHP community at all. At least not in europe.

------
wehadfun
I didn't read it all but some people are do dogmatic about things it is
stupid. I have dealt with plenty of co-workers who read some book and promptly
beat everyone with it.

------
ungzd
PHP community had always been anti-frameworks and anti-libraries. I worked at
company where use of third-party libraries was entirely forbidden on most
projects. I think it's because:

\- Quality of PHP frameworks is low (at least it was last time I used it) \-
PHP parses and evaluates whole libraries and framework code on each requests.
There's proprietary commercial (lol!) software to enable at least caching of
bytecode \- Packaging just does not work (Pear, now there's Composer, not
tried it, seems that it works)

Overall, last time I used PHP i had sense of its community mostly being
nihilistic and preferring cowboy programming. It's straight opposite to Java
where you will be shamed for not using dependency injection and EJBs for page
visits counter. In PHP world you are considered insane misfit if you're
writing tests.

For some things advice to just code and don't use unnecessary libs is useful.
Recently I had that php/cgi feeling when I worked on small microservice in
clojure: no OOP, no MVC, no ORM, no templates, no separating each 10 lines of
code to module, just take Ring request and return Ring response which are
simple associative arrays. This was a refreshing feeling.

~~~
andyfleming
If you haven't used PHP since composer became a standard in projects, you
don't know modern PHP.

~~~
fredleblanc
"Modern PHP" being one of the trigger words in the OP.

That said, in terms of timeline, PHP has gotten better as a whole since then.

------
justinhj
I feel like this could have been a tweet not a website

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

------
hthbh65
beat a dead horse, will ya

------
joesmo
_At over a dozen PHP jobs in over ten years, I 've never seen a real
application without a framework be anything but fucking garbage._

Garbage. You know it's going to be garbage when some idiot tells you not to
use a framework but is too fucking stupid to realize that if you don't use
one, you have to write one yourself. Every single time. And PHP as a framework
itself? Please. PHP is a horribly shitty framework itself for any app that's
going to be more than a couple hundred lines of code. It's only with a proper
framework on top that it becomes a proper web development platform (some may
argue otherwise but their ignorance can be safely ignored). But I assume the
author has never written anything more than a demo app, so yeah, if you're
writing short scripts under 500 lines, don't use a framework. If you're
writing real apps, don't listen to idiots like this author. This isn't PHP
specific. There's nothing that makes PHP different from Ruby or Python.
Appeals to PHP having been developed for the web are idiotic because while
true, it's irrelevant due to the poor quality of PHP < 5 and especially PHP <
3\. Yes, it was specifically developed for the web _poorly_ and we've been
fixing that ever since. If the author wants to use PHP 2 or 3 (or whatever the
fuck they were called), that's one thing, but to pretend that coding in PHP
2/3 style is what makes proper apps these days is fucking insane.

------
w3clan
We don't have to reinvent the wheel everytime we create apps or any product
using framework. Like imagine , When my every product needs login / register
mechanism , i would look for something that is really fast, secure and may/may
not have better approach of doing that.

So, framework are basically to speed up work in same elegant way the others
are doing.

