Reasons that PHP is better than Ruby | Hacker News Reader

Reasons that PHP is better than Ruby

najafali.com

15 pointsalinajaf19 comments

There are reasons that PHP is better than Ruby but instead of pointing those out this article chose to:

  1. focus on some of the ways that Ruby is better than PHP
  2. lie about the topic in the title
  3. have an annoying sarcastic tone throughout.

-1

You're familiar with the idea of satire, right?

The fact that something is a joke doesn't automatically exempt it from criticism. If a joke is making a point, it still needs to make the point well. Even if a joke is just meant to be funny, it still needs to, you know, be funny.

This "satire" is merely stating his point backwards, not cleverly exposing hidden flaws in an idea. Nobody touts the inconsistency of PHP's standard library as a strength of the language. Not many people even claim that PHP is better than Ruby. The positions he purports to make fun of aren't real. He's beating a dead unicorn.

I've said this before but i'll say it again.

It doesn't matter if you develop in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code.

Can we stop the language flame wars now?

Actually you get different types of people working with different languages. It does somewhat matter when you're hiring "X programmers". Good programmers can switch, but are often aware of these communities and keep certain languages at arms lengths because of this.

I smell illusory superiority...

Are you implying programming communities do not have timbres?

I do not understand your use of the word timbre.

Basically imagine the word tone applied to the community, also encompassing a lot more of the non-content parts.

So not just the tone of the discussions, but also the way questions are asked, how new people to communities are treated, the length and style of response and discourse.

People basically use it to say "the tone++ of the discussion" to badly abuse a programming metaphor.

Even though this is satire, you could rebut a few of his arguments (specifically, the typing skills one).

Can we just move on as a development community and let each developer/team choose whatever language, framework, or toolset they find suits them best?

They are free to choose, but if a friend came to you and said "Hey I'm doing a web startup, I want to write it in assembly" wouldn't you advise him against it unless there was some kind of restraint that required running on embedded hardware? Even then you might suggest C if a compiler is available for that chip.

Sure, but if someone said, "I'm going to use PHP, Python, or Ruby", I'd say, "Use whichever one you feel most comfortable with. You can be competent or incompetent in any of them."

Done deal, we can stop fighting about it now.

I don't get it. Was he making fun of both or just PHP?

Some of the things I "think" he was ripping on PHP for are some of my favorite things.

I don't program in Ruby and the part where he said the code didn't make sense - well, it didn't. But was he saying it did sarcastically? Or was he saying it was good that it couldn't be read?

Anyway, I wish I had a down arrow next to articles for this one because I really didn't like the way this was done.

Sorry, but this is just: lame.

Ruby may be better than PHP, but the kind of attitude that Ruby seems to encourage has always been a huge turn-off for me. The amount of time Ruby supporters will take in bashing other languages seems... immature, at best. It doesn't seem as though it's always been this way, but it has become that way.

For me, Python is the place to go if you want a good language with an emotionally mature community. Maybe that will change, just like it has for Ruby.

Luckily, there's always the PHP community for people who will never cop an attitude about how beautiful their language is. Such is the inevitability of a pragmatic, patchwork language.

Excellent points, for me these arguments are also highly applicable as to why C# is better than F#. The extra code really helps with readability and maintainability.

You'd scarcely need any developers at all to maintain that ruby class.

Regarding Ruby's attr_accessor automatically 'generating' getters and setters:

If all you're doing is returning the internal value, or setting it blindly to the value provided, why bother? Why not just directly access the member variable if you're not doing any parameter validation or business logic?

Does Ruby provide some syntactically elegant mechanism for adding logic to the getters and setters? Because as it stands, it looks like Ruby has an elegant solution for a problem that didn't actually exist.

In Ruby, you can't[0] access an instance variable without an accessor; they're private by default, with all that implies. Also, when you use attr_accessor, all it does is literally[1] create a getter and a setter method. Adding logic to them later is a simple matter of replacing the attr_accessor shortcut with a method with the right name. None of the client code has to change, and that's the important part.

[0] Not quite; see Object#instance_variable_get. But that's cheating, ugly, and generally frowned upon.

[1] Not quite, but the difference is an implementation detail.

As Ruby instance variables are private, you need a getter to read them. Doing it this way (making everything private, but giving you simple methods for creating getters and setters) gives you the best of both worlds: Encapsulation and simple and concise code. attr_accessor simply creates the boilerplate code you would write yourself or use an IDE for in other languages. If you want to change a getter, just write a new method with the name of the variable and do whatever you want. This makes it easy to change your class logic later, but won't fill your classes with generic getter/setter code.

Reply on news.ycombinator.com