

Why PHP is better than Ruby - kgutteridge
http://najafali.com/php-is-better-than-ruby.html

======
petercooper
_PHP allows me to practice my typing skills, ruby doesn't. As a touch-typing
enthusiast, I like to practice typing. The problem with ruby is that it allows
me to do the same things that I can do in PHP, but with much less typing. [..]
If I could create classes with public getters/setters that easily in my day-
job, my fingers would atrophe and I'd get no exercise at all. I want my
keyboard smoking after typing out a class definition, and a paltry three lines
of ruby fails to satisfy._

This is certainly the best designed troll blog post I've seen but far from the
most subtle..

~~~
bad_user
When the sarcasm is so clear, you can't call it a "troll".

Real trolling is an art :)

~~~
dexen
[[off-topic warning]]

``trolling is a art'' ;-)

------
callumjones
I'm all for hating on PHP, but this article really does a lot to help the
popular view that Ruby programmers are arrogant language elitists.

~~~
artpop
Really? Hating? Sweeping generalisations? Attempt at spreading said "popular
view"? Misappropriations of words? All in a single sentence? On HN? With
upvotes?

This place is going downhill...

------
kayoone
I am a long-time PHP programmer. I have first dabbled with PHP in 2000 when
making a Page for my Quake2 gaming clans and i still love it. (yeah boo-hoo)
That said, the syntax and language inconsistencies that are already described
in this post (which come from its origin as a website toolkit) are really
laughable. However, i got used to it over time. I can still produce results
much faster than say with Java.

Also PHP has matured alot. I use the symfony framework for all the projects i
do and its awesome, i think in some respects its even better than ROR and the
upcoming 2.0 version will raise the bar even further. If this awesome
framework wouldnt exist i would probably have switched to Python and Django by
now, but as things are now i have never really felt the need to.

~~~
bad_user
Things you don't have when working with PHP:

    
    
         http://www.nltk.org/
         http://www.scipy.org/
         http://www.pygame.org/ :-)

I also worked with Symfony on a project. IMHO it's far, far away from being a
match to ROR.

Though at the end of the day, you're most productive with the tools you know.

~~~
lukifer
Symfony is a labyrinthine nightmare. CodeIgniter and CakePHP are much closer
to Rails in usefulness and ease.

~~~
kayoone
Depends, its much cleaner and more flexible than CakePHP for example. But it
has quite a steep learning curve, i give you that.

------
code177
I am tired of the never ceasing language wars. It's true that some languages
are more elegant than others, but at the end of the day the only thing that
really matters to any person _other_ than the programmer is whether or not
they create something inspiring and/or useful.

All this time railing against other languages could be spent making awesome
things, rather getting the proverbial tape measure out (yet again).

------
mkramlich
Many of the positive points he cited for Ruby are true of Python as well.
Except you don't have to type end end end end end end end end everywhere.

Now I'll get myself-self-self-self-self off to bed...

------
yuvadam
Trolling or not, I cannot read these "my language is better" posts anymore.

~~~
izendejas
I agree. The article I link below (and which I believe I first saw here on HN)
should be closer to the model of what I would hope to see more of around here.

It gives you easy to read data which I believe is often more helpful than any
opinions because at the end of the day you want to know, what are the trade-
offs between performance and development time*, among other things. And it's
also careful to point out many relevant caveats.

[http://faves.eapen.in/performance-comparison-c-java-
python-r...](http://faves.eapen.in/performance-comparison-c-java-python-ruby-
jyt)

------
smokestack
"Oh, look! An opinion that goes against the mainstream on the news.yc
frontpage."

"Oh, got baited into another anti-PHP rant."

I know that PHP has tons of suckage but it's a point that's been made ad
nauseum. No need to point out that Hitler wasn't that nice of a guy. We all
know.

------
kingofspain
I long ago gave up trying to justify why I still use PHP as there will always
be a counterargument (usually a long one) about how wrong I am. Once you get
to that stage, there's a kind of serenity to be achieved :)

~~~
robryan
One I think is libraries for API's, sure this might not be the case among the
latest breed of startups but I think overall your most likely to come across a
PHP library and example code than Ruby.

~~~
xiongchiamiov
The only issue is that at least 80% of PHP code you'll find on the net is
utter crap.

------
gurraman
2005 called; they want their blog post back.

------
Newky
I use php in my part time work every day, and I can honestly say this
hilarious post made me consider using ruby. Unfortunately, I am the sole
developer/maintainer on a huge project which languages don't stretch beyond
php.

I came to this project in this state and I must say that clean code like
demonstrated in this post, would have made the cleanup job I've attempted a
heck of a lot easier.

Php is easy, but messy php code is not only extremely unsecure but also
extremely hard for a new developer to adapt to.

~~~
robryan
My own PHP work where I have been the sole developer for most is great for me
to work with. Having to mod a zen cart over the past week though makes me
agree with you, that thing most be the kind of messy and obscure PHP open
source projects.

------
dexen
The points the blogger touches are mostly three-fold:

* backward compatibility: a valid issue. Some of the APIs PHP exposes come from different backgrounds than others, and to serve the (un)holy cow of the backward compatibility, argument order is preserved. Regretably the PHP lang designers did not choose to deal with the issue, and instead fell for the trap of backward compatibility :-(

* syntax: conventions were carried from C and derivatives. Not a valid issue -- the syntax is perfectly OK for a language without macro capability. (should there be macro facilities like in LISP, complex syntax would be a no-no, but that's not the case in PHP).

* Java-isms like countless getter/setter methods: not a valid issue; nothing in PHP suggests that way of use. Merely bad habits on the part of the blogger. Get over it :-)

For the once-in-a-blue-moon need of real getter/setter, use __get(), __set(),
_call() etc. methods.

[EDIT: style]

~~~
masklinn
> For the once-in-a-blue-moon need of real getter/setter, use __get(), __set()

Unless I am mistaken, __get and __set in PHP are similar to Python's
__getattr__ and __setattr__: they are global to the instance and the
dispatching has to be performed manually.

It can be used for properties, but it looks like shit, it feels like shit and
you'll likely fail to match the language's own semantics when it's invoked
with the "wrong" field name.

As far as I can see, the PHP convention on "static" getter and setters follows
that of Java indeed, just as PHP's object system was lifted from Java.

~~~
dexen
Yes and no :)

Indeed, PHP's __get()/__set() behave the way you describe.

And if you have numerous getter/setters, it will feel and look like shit
indeed -- in any language, no matter how terse the syntax. However, in that
case the problem is with program design, not with the language itself. Ask
your co-workers kindly not to carry over Java thinking into PHP world. Really,
each language performs best when used in its default way.

Second, the PHP's ``own semantics when it's invoked with the "wrong" field
name'' is simple: issue a warning with E_NOTICE level on read access. You
implement that _exactly_ with trigger_error("some msg", E_NOTICE). Same
semantics, end of the story. Will be reported, or not reported, depending on
error_reporting configuration.

Also, you have __call() in similar vein, which lets you do pretty neat
results: <http://scriptor.github.com/pharen/index.html>

~~~
masklinn
> And if you have numerous getter/setters, it will feel and look like shit
> indeed -- in any language, no matter how terse the syntax. However, in that
> case the problem is with program design, not with the language itself.

You missed a core issue of the whole getter/setter/properties business:
future-proofing/evolvability.

In Java, people generate bunches of getters/setters because if you ever need
to create "virtual" members (add pre/post conditions) with public members
you've just broken your interface (it's also used by technologies like Java
Beans), you can't evolve gracefully from one to the other, hence Java IDEs
having become very good at auto-generating getters and setters (including the
type-induced naming variations). Likewise in C#, you can't replace a public
member by a property without recompiling all clients (and if you follow the C#
naming conventions, properties are PascalCased whereas members are
camelCased), hence new syntactic forms having been introduced over time to
make "direct proxy" properties easier and easier to create (last time I
checked, creating a R/W property called Foo in C# is down to `public $type Foo
{ get; set; }`, and no field declaration at all as the field is implicitly
generated by the property)

And so is it in PHP: if you use public members you can replace them by __get
or __set, but if you _ever_ need more than one or two fields you're fucked as
you end up with a ball of mud of manual static dispatches. If you go the Java
way, you get the Java result.

Now you assert that it's the same in every language. This is patently
incorrect, and let me demonstrate it with two languages as far apart on this
issue as they could be, Ruby and Python (very similar on most things, but not
on this)

* Ruby has no public members. Period, end of the story. In Ruby, a public member is already a property, but because it's common to just expose a member without pre/post conditions it has accelerators for this such as `attr_accessor`. `attr_accessor :foo` creates a read/write property (actually a pair of methods) `foo` on the object which will proxy to the private member `@foo`. This means if it's exposed in Ruby, it's already a property. If you want to add pre/post conditions, remove the `attr_accessor` call and replace it with an explicit pair of `def foo` and `def foo= value`. This evolves gracefully and scales trivially, declaring a property in Ruby is as terse as (if not terser than) declaring a _public member_ in PHP.

* Python goes the other way: everything is public. Period, end of the story. But it also has `property` which is an object implementing the descriptor protocol. Long story short, you can replace a public member `foo` by a property `foo` (created at the class level), and when accessed from the instance they will be indistinguishable. So in Python, just as in Ruby, you can trivially swap out a field for a property as needed without having to dispatch anything manually or defensively pre-generate a bunch of crap.

> Ask your co-workers kindly not to carry over Java thinking into PHP world.
> Really, each language performs best when used in its default way.

Getters and setters _is_ the default PHP way. Hell, _all_ of the Zend
framework uses getters and setters everywhere[0]. __get and __set (and __call
if you really want to talk about that one) are the special cases for _dynamic_
fields and methods (e.g. in ORM), not for _static_ properties.

As to my coworkers, they've switched well away from PHP a long time ago.

> Also, you have __call() in similar vein, which lets you do pretty neat
> results: <http://scriptor.github.com/pharen/index.html>

I don't see why you'd _need_ __call to compile Lisp into PHP.

[0] example: the request object
[http://framework.zend.com/manual/en/zend.controller.request....](http://framework.zend.com/manual/en/zend.controller.request.html)

~~~
dexen
First off, thank you for the informative and balanced response.

Second, I agree with your reasoning chain, but I don't subscribe to the
initial idea: accessors being about future-proofing. To me sprinkling
accessors all around is more about focusing on the (safer, easier) `known
unknowns' and satisfying kLOC metrics. And the assumption of being able to
freely exchange code underneath as long as the objects stay the same.

So no, I haven't missed the whole accessor/mutator business -- I consider them
special cases, to be used sparingly. And as such, I see no point in optimizing
for them.

To keep it short, lemme commit the Argument to Authority fallacy here:
<http://c2.com/cgi/wiki?YouArentGonnaNeedIt>
<http://c2.com/cgi/wiki?AccessorsAreEvil> and
<http://c2.com/cgi/wiki?LawOfDemeter>

But then again, perhaps one day I'll learn better, remember your remarks and
start making better use of accessors :)

------
eik3_de
Even more reasons:
[http://www.bitcetera.com/en/techblog/2009/04/07/10-reasons-w...](http://www.bitcetera.com/en/techblog/2009/04/07/10-reasons-
why-php-is-still-better-than-ruby--/)

My favorite: _DRY won’t Pay your Bills_

------
jessedhillon
Awesome. I think he could have picked some better criticisms of PHP though --
there's a truckload of them: <http://www.quora.com/What-are-the-crawling-
horrors-of-PHP>

It really is the worst of all the in-demand languages these days.

~~~
kenver
Read the article and there are a few times he compares php to rails - I didn't
realise php was a web framework.

There are certainly things to dislike about PHP. but I think he's trying too
hard in a few of the ones he cites.

------
tintin
Did he never hear about CTRL + Space? Anyway. If you don't like PHP just don't
use it.

~~~
olalonde
Mind explaining the ctrl+space reference? (I assume it's a Windows thing?)

~~~
tintin
Most IDE's use this for auto-completion.

------
baggachipz
I see what you did there.

------
djhworld
He's played this one well, I'd imagine 90% of the readers would read the first
paragraph and then run to HN/Reddit to lambast such a post.

