--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 05, 2010 at 11:11:18AM +0900, Ruby Me wrote:
> Thank you guys,
>=20
> It would be helpful if anyone writes any conde in PHP and then writing=20
> it in Ruby? I want to see the difference and how the code will be less.

As someone who has written a fair bit of both PHP and Ruby for the Web
over the years -- and very little of the Ruby actually using something
like Rails -- I think I know something about the subject when I say this:

1. Code snippets will not give you a good idea of how much one or the
other might save you any total code weight in the final version.  Pick
one small task that can be represented in a small snippet, and one
language wins; pick another, and the other small task wins.  In fact, for
the smallest tasks, PHP will almost certainly win because of its
literally *thousands* of core functions -- which, by the way, is *not* a
sign of good language design.  Last I checked, there were about 3100 core
functions, which is *obscenely* complex for a procedural language, and
pollutes the main namespace of the language to an insane degree.

2. Final code weight to accomplish a specific task is nowhere near the
same thing as the amount of code you have to *write*, anyway.  A lot of
code that gets written for any given non-trivial project is ultimately
deleted, usually to be replaced by other code.  One of the benefits of
Ruby is that it tends to lend itself to finding the "right" idiom for a
given task sooner rather than later.  PHP is not as good at that, and
tends to require a heck of a lot of refactoring as it scales up past the
size of a relatively trivial application.  A lot of projects simply do
not do that much refactoring, but the end result is a largely
unmaintainable mess of an application, like WordPress.  Reading the
source of WordPress is a bit like using thumbtacks for contact lenses.

3. Ruby's object model lends itself to far better code organization than
anything PHP offers.  This means that, even in cases where Ruby might
have the same amount of source code (or even more) to accomplish the same
task, it's a lot easier to understand because of the way it can be
divided up into discrete chunks that make sense.  PHP's unreasonable
facsimile of an object model and bolted-on half-baked namespace support,
by contrast, tends to creak under its own weight when developing any
nontrivial application.

All told, PHP is easier to use for the most trivial, single-page dynamic
templates, and harder to use to accomplish for anything more meaningful.
If all you're going to do is maintain a simplistic Website that contains
nothing but a little bit of simple logic in otherwise static pages,
perhaps populating some content areas from a couple of extra files, and
learn as little as possible, you might want to go with PHP.  If you're
going to do some real programming, though, I recommend Ruby; it'll
facilitate development more on larger projects, it'll encourage better
coding practices, and it'll be more fun.

A lot of people complain about the superficial ugliness of Perl.  PHP,
however, inherits pretty much all of Perl's flaws as a language, and
almost none of its benefits.  Ruby inherits a substantial percentage of
Perl's benefits, and not so many of its flaws -- even by the markedly
uncharitable opinion of what constitutes a "flaw" that may Pythonistas
would give you.

I have recently stumbled across a brilliant characterization of PHP as
training wheels without the bike.  It's hilarious -- and having used Ruby
for a while, it feels pretty true, too.  I suppose your mileage may vary.

Note that a lot of this has been a liberal mix of opinion and fact.  I
encourage you to *think* about what I said and do a little investigating
to confirm what I've said for yourself, rather than just taking my word
for it.  If you want my opinion, though, it's easily summed up:

I'm glad I don't have to write PHP these days.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAkzTuFUACgkQ9mn/Pj01uKX+DwCfUGEAP0gtfXqGth/k4yyin+Ds
7ZIAoMbMqW3as5qdQkwiz+ggjWUfTu1C
=dQ7x
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--