

PHP Weekly improvements - inovica
http://www.phpweekly.com/archive/latest.html

======
JoeKM
Thank you for this.

I'm not fond of PHP, but I don't know it as well as Ruby and Python. Still, I
like to read about new technologies concerning PHP. I use HN to discover new
stuff, but HN is a poor resource concerning PHP. HN has tremendous vocal
disdain for PHP. Every PHP thread transforms into "Why I like or dislike PHP"
instead of actual discussion regarding new technologies or libraries. What's
worse is the debates feel like I've warped 10 years past because there is
nothing ever new to them. People complain about the old things of PHP and
never talk about the new things.

Put simply, even though I don't know PHP that well I feel like maybe it has
potential and can actually do good in the right hands, but HN brainwashes you
into thinking PHP is the worst.

~~~
PommeDeTerre
Professional software developers who care about creating secure and
maintainable applications that perform well will, by necessity, be very
hesitant to use or recommend the use of PHP.

It has a very poor track record when it comes to security flaws, for example.
It is also rife with inconsistencies and unjustifiable oddities throughout the
language itself, and its standard library. Factors like those then promote the
development of software that is of an unacceptable quality.

There do happen to be many extremely experienced software developers here at
HN, and we won't hesitate to point out the flaws with various technologies,
including PHP. This is not a bad thing; it's quite good. It's extremely
important to be vocal about low-quality technologies.

These days, there are just so many alternatives that are far superior to PHP
in every respect. Even with its new features, PHP is still not an acceptable
option. So we shouldn't be looking for positives where there just aren't any,
nor should we be surprised when all we find are negatives.

~~~
maratd
> Professional software developers who care about creating secure and
> maintainable applications that perform well will, by necessity, be very
> hesitant to use or recommend the use of PHP.

Nonsense. As the most widely deployed platform it has absolutely massive
exposure and security flaws are fixed quickly.

Don't confuse poor practices by newbies with platform security and stability.

> It has a very poor track record when it comes to security flaws, for
> example.

It does not.

> It is also rife with inconsistencies and unjustifiable oddities throughout
> the language itself

Every language has its warts. What's your point?

> These days, there are just so many alternatives that are far superior to PHP
> in every respect.

Yeah. Don't blame the tool. Blame the craftsman. And a craftsman who spends
quite a bit of time complaining about the tools others use ... well ... you
can fill in the rest.

------
quackerhacker
>Dealing with Duplicated Code

Anyone notice the duplicate topic under Tutorials and Talks "Offline
Processing in PHP with Advanced Queuing," just gave me a little chuckle when
one of the articles is dealing with duplicated code.

Aside from this, I LOVE PHP. A prospective employer was asking if I would be
open to learning RoR. Anyone who is experienced on Rails, could you let me
know if it's a similar structure as PHP (which I'm great at)? Thanks.

~~~
nkozyra
As Rails is a framework and not a language, it has a much more specified
"structure."

Syntactically, the languages are not all that similar. It's probably closer to
Python.

As much as people abhor PHP in programming communities (and I get that
sentiment), I find RoR to be a far, far worse platform to build upon.

~~~
jiggy2011
What do you find worse about RoR? Compared to whichever PHP framework.

~~~
fooyc
Ugly monkey patching everywhere, open classes, insecure by default (e.g. mass
assignment), global states, model classes easily too much tied to a single
controler, active record pattern, ...

~~~
rbanffy
It's interesting. Much of what I think is beautiful about Ruby (and Python,
and Objective C, and Smalltalk) is what people who like PHP consider ugly. I,
myself, and it's a matter of taste, find PHP (and most of the code written
with it) ugly. There is no objective measurement for ugliness.

~~~
prollyignored
There you go <https://github.com/runekaagaard/snowscript>

PHP is a kludge. You'd be surprised to know that world is made of kludges with
a few elegant hacks thrown in and not the other way round.

Performance hacks are always kludges. Can you live without them ?

Honest question, should I waste my time worrying about the "What makes syntax
elegant" than working with the existing kludge ? What makes that time well
spent ?

Why shouldn't I seek beauty in output and look for a programming language that
get's me the output quickly ?

~~~
rbanffy
> You'd be surprised to know that world is made of kludges

No. I wouldn't. I'm an electrical engineer by training.

> Performance hacks are always kludges.

Not always. Sometimes they bring out some inner beauty in the code that was
previously hidden. But, again, sometimes they don't.

> Honest question, should I waste my time worrying about the "What makes
> syntax elegant" than working with the existing kludge ?

It depends on your priorities. If you were a poet, would you be more worried
about making good poetry or selling more books?

> Why shouldn't I seek beauty in output and look for a programming language
> that get's me the output quickly ?

Again, it depends on what is your output and how you relate with the fact that
the thing generating that output is a horrible mess.

~~~
prollyignored
> No. I wouldn't. I'm an electrical engineer by training.

I agree. Electrical, Electronics, Civil, NASA aka Real Engineering will not
have more kludges.

Phone Radiation / Drainage Systems have a few "Oh well I'll just leave it here
..."

But what about medicine, law, newspapers ? Are they not part of the real messy
world ?

I agree to be a kludge worker and an idealist part time poet :) (pragmatic
choice)

------
rbanffy
After reading the linked [http://www.phpclasses.org/blog/post/208-5-Reasons-
Why-the-We...](http://www.phpclasses.org/blog/post/208-5-Reasons-Why-the-Web-
Platform-War-is-Over-PHP-Won-with-75-says-Google.html), I have to wonder why
people still think their favorite technology must "win".

~~~
kbenson
It may be a response to the PHP hate that's common. PHP _is_ very popular, so
an end run around technical merits may be alluring to those that don't know
how to argue the merits, can't find enough merits to argue, or are just
looking for a quick way to draw in the large audience of PHP users that are
looking for validation in their choices.

~~~
prollyignored
For all the hate given to PHP, I still can't understand why the cool-elite-
rockstar-ninja-sexy-hot-hackers of python/ruby/java/go/haskell/clojure/S __*t
can't come up with half-as-dumb replacement for mod_php and compete with it on
its own terms.

Good variable names and documentation are infinitely more important than new
shitty frameworks or do vs "{" vs "\t".

~~~
vec
Because mod_php is one of the main things that said hackers don't like about
PHP. 1 file to 1 url does not scale to even small blogs, and using mod_rewrite
to handle routing is both more complicated and less powerful than port
forwarding to an app server and letting it handle urls in application code.

I always hear people say this, but I've used both a fair bit and `rails s`
plus port forwarding is an order of magnitude easier than fighting with
apache's vhost config.

~~~
frenchy
> 1 file to 1 url does not scale to even small blogs,

I suspect you are aware of this, but using URL parameters it is quite easy to
make multiple urls map to the same file (i.e. `/foo/?abc=123` and
`/foo/?abc=234`).

~~~
vec
Of course you can, but most of the time you don't want
/blog/index.php?slug=title-of-the-article, you want /blog/title-of-the-
article. To do this in a CGI-style app (i.e. mod_whatever) you've got to
mangle the URL in the webserver layer. This moves application logic out of the
application and into a config file for some other program, so it would be bad
even if Apache's rewrite syntax wasn't incomprehensible black magic.

It cuts both ways, too. CGI-style routing gives a URL to _everything_ ,
whether you want to or not. Unless you explicitly disable it, visiting
/blog/config/database_credentials.ini (or whatever) will happily serve that
file to the client. Plus it allows any user to execute the code in any file in
your system out of context. Admittedly this will _probably_ either error out
or do nothing, but can you guarantee that for every single code file in your
whole tree?

~~~
Mahn
Technically speaking you would need one single rule in your web server
configuration that rewrites all urls to a single router.php file (for
instance), and code there your _own_ logic to handle urls in PHP. This is not
very different from other server languages except for the fact that you are in
control of the routing logic AND you can delegate it to a framework if you
choose to do so.

I've been using this technique (single url rewrite rule, send everything to
index.php, handle routing there) for some time and it's worked quite well for
me.

------
Treffynnon
Have you seen Wes Mason's PHP Weekly newsletter: <http://phpweekly.info>? Is
this intended as a replacement?

~~~
inovica
Hi there. We'd actually been running this as a weekly news list for some time
(we'd owned the domain for years) via a PHP-related product that I also run.
We decided to open this up wider based on seeing the Python Weekly one, as
we're also fans of Python. Someone pointed me to Wes last week and I dropped
him a line and we have exchanged some friendly emails between us. I need to
pick that up again after being away for nearly a week.

------
gee_totes
Since you seem to be taking suggestions, could you add "overflow:hidden;" to
the main div (#home)?

On Firefox 3 the site appears about 4000 pixels wide.

~~~
inovica
Will do! Thanks for this

------
inovica
Hi there. We posted about PHP Weekly last week and we had some really good
suggestions from people - mainly about how we'd not done a great job
explaining what we are doing!! Took all the suggestions on board and added in
an image, latest issue link as well as archives. We've also added in an RSS
feed, but I note the comment (on here) about the RSS feed being terrible.
Sorry, we'll work on that.

~~~
RossM
Thanks, I must have missed it last week. Looks like a much more readable
alternative to phpdeveloper.org (which has too many automated posts imo).

------
runnr_az
I really like the Javascript Weekly / HTML5 Weekly newsletters... since I'm
(theoretically, anyway) a PHP dev, this will be a nice addition.

------
adventured
Don't be afraid to make the text here:

<http://www.phpweekly.com/archive/latest.html>

larger, and expand the width of the layout some. If you're going to leverage a
simple layout like that in which the text is the sole focus, you might as well
go a bit larger font size.

~~~
inovica
Hi and thanks for the suggestion. As this is an archive from the email itself
thats why we used that width.

------
raveren
The news are nice, but the RSS feed is terrible - but a headline.

~~~
inovica
Thanks. We'll improve that

