Reasons for success
- PHP has huge and really good library.
It’s perfect for integrating other services and databases.
It’s also far easier to port a C-based library to another functional
language than it is to an object-oriented one: notice that the PHP
calling convention is much like the C one.
The standard library grew -really- fast in the last few years, something
Ruby can do too. The difference is that PHPs is ingrown, part of the
standard distribution, and all it takes to turn it on is install the
code it depends on for the function you need, and add --with-foo to the
configure commandline, and you get a dynamically loadable library for
PHP.
- PHP has perfect documentation.
For Ruby there is nothing like this. We don’t have any written
language reference. Buying the O’Reilly “Ruby in a Nutshell” was a
waste of time and money, because this is not a reference.
It does not even mention that a ! or ? following the identifier in a
“def” belongs to the name, it doesn’t contain a BNF Grammer or something
like this.
This is something that hindered me when I started to learn Ruby,
particularly before I realized that the language wasn’t out to surprise
me like PHP. (I learned Ruby as my nineteenth programming language, so
the lack of docs didn’t hinder me that much at the “Hello World” level,
but it would certainly help where I am now – I’ve had to delve into the
code to about half the modules I’ve used, since the code is complete and
the docs tend to lag…)
One other thing is that there are many, many resource sites out there
for Ruby, but they cross-link very little, and they all miss vital
pieces of information. I didn’t know about the Pickaxe book, I
suspected that O’Reilly had the Nutshell book, wasn’t sure if there was
a complimentary reference by them or not, found only one reference to
Matz’s book, and the language references I find online (Rubycentral and
the old 1.4 ref) all seem to be incomplete.
One thing PHP has that every other langauge doesn’t: It’s features are
documented on the web before they are released. The manual notes which
features are in the up-and-coming release from CVS, and what’s in each
released version, and it documents the differences, usually. This has
been a driving force in development. People download the new release
when it comes out – the features seem to come out as a post-beta,
because in everyone’s minds, it’s been out a while in the docs, anyway.
The other thing about PHP is that it is trivial to package. In the PLD
distribution (Which I highly reccomend, by the way), each PHP module is
a separate package, which contains a .so and a script to activate it in
the interpreter configuration, and restart apache if needed. mod_php is
just one file plus the .ini plus an http config shard. The command-line
interpreter is one file plus another .ini. Ease of packaging means
that distributions will carry more up-to-date versions of packages, and
more of them will carry it at all.
The dependencies are also isolated in PHP’s extensions – since they are
dynamically loaded, binary packages can suppport mysql, but if the user
does not have it nor it’s libraries installed, one can just omit mysql
support in PHP without recompiling.
Now, be aware that there’s also a “native” library of functions, the
PEAR. It is far less used than the C extensions, probably by an order
of magnitude because it was distributed as a second package, and few of
the linux distributions carry it. This has changed recently, so it’s
something to be aware of: how many distributions carry, and how many
PHP apps will depend on PEAR in the future, now that it’s bundled?
- PHP has good and easy to use tools for professional development.
Decent ones, anyway. It tends to be managable with a text editor more
than other languages. Ruby’s pretty good this way, too, and it’s easy
to /design/ tools for Ruby. This one I think will take care of itself,
more than it has for PHP.
- PHP was designed to do one job and is great with this. Ruby is a
general purpose language, that is good in a lot of places and
unperfect in all.
PHP is also buggier than a swamp in the midwest US.
It took two and a half years to make pass-by-reference not crash the
interpreter randomly. Memory usage is high for long running scripts
(it’s Garbage Collection is very poor).
PHP was less designed than just kludged together.
- Ruby don’t have a good Web Tool. Amrita is okay, ERuby is okay, but
if you enter the professional level they fail. For example streaming
output into memory and postprocess the output in the same script (for
PHP users: obstack)
This is one way that Ruby could, with just a few new libraries, totally
destroy PHP.
PHP cannot make modular HTML easily. None of the application frameworks
make it easy to include another application or script’s output in a sane
way. I’ve written such a framework (as yet unreleased, though it’s
heavily used and the code is almost clean enough) – and the
modularisation is the biggest task to accomplish. In my case, I’m using
scripts that spit out basic but complete XHTML documents, and using XSL
to transform them into something one can just include in the output of
another module. I use XSL yet again to add style at the end. It’s a
messy, messy thing to do, because at it’s core, PHP is not Object
oriented.
Ruby could take over quite easily in the web-framework arena. Since
mod_ruby isn’t just a parse-this-file module, but instead an entry point
for an entire framework, Ruby can compete with Zope, and can be easier
to install. It also scales smaller than Zope, so it could go almost as
low as PHP’s my-HTML-is-valid-PHP approach.
- Rubies OO functionallity is not so important in CGI like scripts
(this means scripts that start with no internal variables other then
session variables). This would only be an important point if you use
an application server, but there is none.
An application server would be a killer app.
- PHP is available everywhere.
This is partly due to “release often”, and partly that it’s easy to
package.
- Everyone can learn PHP in a week, because it is much simpler Even
designer and low paid students, which is commercially important.
That’s just the docs – people plateau in PHP pretty quickly afterward.
Not many people who manage to use PHP+MySQL+Apache really understand
what’s going on – few learn relational database theory, few generate
valid HTML, but they manage to code simple but messy apps.
- There is not this Perlish like line noise (source code) you find in
a lot of otherwise not documented ruby libraries (and in the standart
library).
True.
Ruby also has one place where it shines: large application interfaces
where “object fronting” is useful – whether to hide a distributed
system behind a frontend, to simplify an API, to hide an ugly data
format based in XML. The ability to make such powerful proxy classes is
an asset that few other languages can manage.
Ruby has the potential to be an incredible glue language: now it just
needs language bindings for all the parts to glue together. Powerful
GUI libraries, and perhaps a standard abstraction for them, graphics
libraries (RubyMagick? Ruby-gd?), network libs (we have these), a web
app server, a generic app server, drb-based perhaps? Simple ways to
implement Model-View-Controller in both a web and a more gui-app
frontend with the same model would be very useful.
Building a ruby “Standard Library” of all this is, I think, the way to
go. A very bazaar approach would work, I think: let the “reigning”
module developers maintain their modules as part of the library – I
would love to see REXML included, along with Ruby-Mysql, Ruby-Postgres,
DBI would be a must, and at least one graphics processing library.
Aredridel
···
On Tue, May 06, 2003 at 12:42:04AM +0900, Lothar Scholz wrote:
