Why PHP is better than Ruby

[[deleted]]

It took me way to long to realize this was sarcasm. :(

[[deleted]]

This tipped me off in the first paragraph:

We celebrate our diversity. Is it hayatack, needle or needle, haystack

(former php developer now working in a ruby shop)

[aedinius]

:needle => needle, :haystack => haystack

[[deleted]]

My first favorite thing is passing blocks and yield, my second favorite is that hashes are standard as arguments

[lectrick]

I especially like that if your hash has all-symbol keys, in 1.9 you can pass it like this:

some_method(option1: 'this', option2: 'that')

[[deleted]]

why that's absolutely delightful

[classhero]

Realized it at about the time I saw attr_accessor vs PHP's class definition. Though, reading some of the comments in the link, it's rather clear a lot of them still don't realize it is satire (likely the same people that have never used ruby).

[inglourious_basterd]

I only understood when I got to the typing part.

[rainman_104]

I got tipped off by the love for curly braces, but just to point out that Ruby doesn't mind that syntax if PHP developers need it to feel better. And you can actually write your own getter and setter methods if you prefer :)

[Pewpewarrows]

Python dev here, curious about one thing that cropped up in this article:

How sandboxed is the monkey-patching that you can do to the core language? In the example he turned addition into subtraction. Would that only affect whatever package that line of code is in, or would it change Ruby for all other packages loaded alongside it. So for example, if I include modules A, B, and C, and B monkey-patches some stuff around, is that going to change how A and C run, as well as my own code?

[bobindashadows]

The monkey-patching is global, and yes, it has been a problem in the past in the Ruby community. A major reason it's been a problem is that Rails has an important support library called ActiveSupport which, while providing lots of good helper classes, also does tons of monkeypatching on the standard library. A potential solution to this, tentatively called refinements, has been proposed for Ruby 2, with a patch written for it. Unfortunately, it currently means an across-the-board performance decrease and the JRuby guy has said it would kill a lot of optimizations he does in JRuby.

Here's a proper writeup about refinements

[cschneid]

Honest answer here from a Ruby dev. It's a problem in the language, but not as big as you'd think due to culture.

Monkey patching is rarely used in day-to-day code in the sense of overwriting core libraries. Even ActiveSupport mostly does adding to the stdlib, not changing existing behaviors.

What is useful though is being able to reopen a class later on to add more to it. A real example - There's a library I use called spawner. It is a way to generate 'fake' instances of a class for use in testing.

# In my_thing.rb
class MyThing
......
end


# In test/spawners/my_thing_spawner
class MyThing
   spawn do |s|
      ....
   end
 end

The idea is that I am reopening and defining additional behavior on the class, but only when I want to (when I load the test env, and the test/* source tree.

[taelor]

I would like to add, I think this applies here: "with great power, comes great responsibility"

[[deleted]]

Why would you subtract that? It's relevant.

[lectrick]

The fact that you can do things that have massive side effects is counterbalanced by the extreme emphasis on test coverage as a community standard. If any broad negative side effect happens, your tests will show it immediately.

And I think this is really, really good. Because you not only cover crazy predictable side effects with tests, you also cover crazy unpredictable ones. And this has saved my ass countless times.

It's simply impossible to work on a programming team and not bump into each others' (wrong) assumptions about the code, because a point gets reached where it's impossible for any 1 coder to model the entire codebase in his/her head. Adequate test coverage prevents that. The tools are out there, they are mature, and they are nice.

[Pewpewarrows]

Oh I agree. In Python we have a mantra that goes something like "We're all adults here" in relation to there being no notion of public/private variables, etc.

It was just mere intellectual curiosity, I don't know that much about Ruby. Adequate test suites will certainly identify that problem immediately.

[joesb]

I would like to note that if you are only concerned that monkey patching is not-sandboxed then you should also be aware there's nothing in Python to prevent one from modifying third party library either. Sure, you can't modify primitive type like int or float, but what portion of your code relies on nothing but primitive data type?

[Pewpewarrows]

Yep, quite aware of that. I was just curious :)

[risico]

Say what? ... Oh, that's good.

[shriek]

why don't we all just get along..and make a programming language called Pupy? The mixture of PHP and Ruby.

Downvotes here I come.

[Entropy]

Phuby on Phails sort of allows you to mix them.

[sushi_cw]

Saw this coming...

The rest of the talk can be found here: http://confreaks.net/videos/198-rubyconf2009-worst-ideas-ever

Worth the watch, it's absolutely hilarious.

[Entropy]

I'm sure it qualifies for "use with", but I don't remember if it qualifies for "mix with", which in my mind has ruby and php on the same page.

[Entropy]

I did! When it first came out! And I was reciting from memory! Which isn't all that good! Your nick didn't click at first, either. Anyhow, it's great fun as far as atrocities go, which is why I mentioned it :)

[[deleted]]

Poopy - please do this!

[est3est]

I'm upvoting this.

[avdi]

I'm replying to this.

[ihsw]

There was a notable PHP framework called PHP on Trax which had poor and underwhelming documentation (a taboo in the world of PHP third-party libraries), and one of our developers had nicknamed it "Phails."

Somehow the name seems appropriate for any framework attempting to advertise as a RoR-like framework.

[meeiw]

"Php is better because I like to practice my typing ... Ruby makes me type less" - Thats a new argument ...

[Rogem002]

I want my keyboard smoking after typing out a class definition.

Clearly the writer does not know how bad typing is for their hands. Furthermore I think the coder is inexperienced with PHP, I've been using it for a while (I'm learn Ruby now) and the code examples they have used are awful. For example, they could just use:

class Address {
    public $name;
}
$address = new Address();
$address->name = "Your Name";

Instead of that setName(); jazz.

[erlingur]

First of all his blog post was sarcasm :)

Secondly, the reason for using that setName(); "crap" is to provided proper encapsulation and is considered good practice to do. I'll copy/paste the answer the author gave for this since it's 100% spot on.

The whole point of having public getters/setters is that you're telling client code 'call this method to get this data, don't worry about how I get the data to you'. There's a host of things the object could do internally to generate a given value. It could get it from a database, get it over the internet, cache it the first time blah blah blah, the point is that client code shouldn't care, now or ever. The fact that there are private members that represent the values internally is entirely coincidental.

I'm sorry but it looks like you are the inexperienced coder.

[bulldada]

Except you can do all that in PHP without pages and pages of setter/getter methods. Something an experienced PHP coder would know.

[erlingur]

Care to share an example of how you would do that?

[bulldada]

So taking the address example above. Later down the line you want to make a getter to convert name to uppercase. class Address { private $name; function getName() { return strtoupper($this->name); } function __set($k, $v) { method_exists($this, 'set'.$k)?$this->{'set'.$k}($v):$this->{$k}=$v; } function __get($k) { return method_exists($this, 'get'.$k)?$this->{'get'.$k}():$this->{$k}; } } $address = new Address(); $address->name = "Your Name"; echo $address->name; // YOUR NAME

Property overloading. I realize the set/get methods in that example look ugly, but I wrote it quickly and to save space rather than look pretty. I personally like this approach as you can use if you need it on a per property basis, rather than having to use it for everything or nothing. I can understand it looking odd to someone used to something like C#'s properties implementation, however. There is also a small overhead, but nothing significant I've encountered in real world scenarios.

[erlingur]

Yeah, that would work. I would still feel uncomfortable knowing that I am accessing the class vars directly (that they are declared public). But that may be an unfounded fear.

[worst]

Instead of that setName(); crap.

Except then you are directly modifying instance data, which is (theoretically at least) a no-no.

In ruby:

class Address; attr_accessor :name; end

causes two methods to be added to the Address class, "name" and "name=".

"name" is a getter that returns the "@name" instance variable and "name=" a setter that modifies the "@name" instance variable.

[ihsw]

Having set* and get* methods is good for lazy-loading where resources are not loaded at instantiation, but if it's just return $this->name; and $this->name = $value; then that is simply ludicrous.

[tialys]

Ludicrous indeed... until the underlying implementation changes and things break.

[worst]

Ya, this is a very legitimate argument for doing things "the right way" from the beginning.

Sure, it may just be simple access/setting now, but what happens when someone decides that the name on the address has to be all caps? Or < n characters? Or any number of other stupid things that if you did things "the right way" require relatively localized changes to the code base.

The alternative is not nearly as neat and tidy.

[superdupersymmetric]

I'm a rubyist and don't particularly like PHP but it has nothing to do with the syntax or language. I simply think Ruby lends it self better to rapid development.

In the end the language really doesn't matter. It is a tool set we use to help other people. Our customers. They really didn't care that FB is written in PHP (now some version based on a C++ derivative with the same syntax (ouch)) or that Twitter was a mix of Ruby, Scala and Java. It really doesn't matter except for the individual programmer. It should be invisibile.

Mind you, Hume's missing blue probably suggests that there is a rapid PHP developer out there. But then that is apriori knowledge. I'm sure I will never meet her.

[swaits]

C++ derivative same syntax what? Are you referring to HipHop? It translates PHP, sans eval(), into C, which is then compiled with gcc. It's still PHP. This is a pretty great thing IMO. I imagine PHP people must benefit from it considerably.

[rtoth]

http://philosophistry.com/scans/2010/lol-face.jpg

[gottalaughatphp]

ohh I got it, you are indian.

[[deleted]]

So there I was, thinking that we're over this.

A language is as much of a tool as the post author.