Why PHP is better than Ruby | Hacker News Reader

Why PHP is better than Ruby

najafali.com

53 pointskgutteridge36 comments

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

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

Real trolling is an art :)

You're right - I guess that's what I was trying to get at with the lack of subtlety. Or my standards have slipped.. ;-)

[[off-topic warning]]

``trolling is a art'' ;-)

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.

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

I'm a Ruby programmer and totally agree with you.

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.

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.

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

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

When have you needed to use PyGame in a web application?

Different tools for different things. Use 'em when appropriate.

As a sidenote: from my extremely limited experience with PyGame and (Lua) Love, Love kicks PyGame's ass all over the map.

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

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

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

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

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

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 :)

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.

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

2005 called; they want their blog post back.

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.

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.

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]

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

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

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

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 :)

Even more reasons: http://www.bitcetera.com/en/techblog/2009/04/07/10-reasons-w...

My favorite: DRY won’t Pay your Bills

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.

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.

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

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

Most IDE's use this for auto-completion.

I see what you did there.

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.

Reply on news.ycombinator.com