On Tuesday 08 December 2009 12:36:01 am Marnen Laibow-Koser wrote:
[Warning: no Ruby content whatsoever.]
Nice disclaimer!
Generally so. But Perl is awful for writing Web applications.
How so?
Because I’d definitely disagree here. I think Perl is generally useful
– and
I think Ruby is also generally useful. I just think Ruby is prettier and
much
easier to work with than Perl.
Second, just look at the number of global functions in PHP. I’m not
talking
about the ones you’ll write yourself, but the ones that are built into
the
language. Even Perl is better about this, and Javascript certainly is.
I’m not sure I understand your point. PHP was obviously designed
primarily as a procedural language, so it’s sort of appropriate for
there to be lots of global functions.
Even supposing it was… Erlang is designed as a pseudo-functional
language,
and it still has the concept of namespaces. I realize PHP has
namespaces, but
I wasn’t seeing them actually used, and there’s still a bunch of cruft
that
seems to be from before PHP realized namespaces were a good idea.
Everything I ever did in PHP used the Pear DB or
MDB2 library, both of which support prepared statements. I learned that
trick back in my ColdFusion days, and wouldn’t have given it up in PHP.
I’ll grant this point – I guess it had to be solved at some point.
So the language itself doesn’t lend itself to particularly high quality
in the
first place.
WTF? Just because the standard DB library has problems, you make this
sweeping conclusion? Isn’t that kind of like concluding that Ruby sucks
because TMail and REXML are awkward?
I actually kind of like TMail, though REXML has been improved on.
No, the point is that in a default PHP setup, there’s tons of this
stuff.
Again, from the global function count alone… It wouldn’t be so bad if
there
was some kind of convention to them, but there isn’t.
There was a much better thought out rant against PHP, by a Perl guy, who
made
this point very well:
http://www.tnx.nl/php.html
To summarize it:
- Arguments and return values are extremely inconsistent. That’s with
standard PHP libraries.
- PHP has separate functions for case insensitive operations – and
these are
inconsistently named. (Contrast to Ruby, where I can add /i to a regex,
or I
can just downcase the string.)
- Continuing on that theme, functions are inconsistently named.
- Scoping. Seriously.
- Too many functions.
Wow, I’d forgotten most of the reasons I hate PHP!
For what it’s worth, though, the “modularity” section may not apply –
PEAR
may have solved that.
He updates it for php5 here:
http://www.tnx.nl/php5.html
This didn’t really fix anything in the above list, but added classes, so
he
criticizes the PHP object model. But then, you agreed that the object
model
wasn’t that good, so I won’t care.
It did, however, add exceptions. But since they were added after the
fact,
they’re probably about as useful as they are in Perl. In Ruby, nothing
(except
ActiveRecord, apparently) ever just returns an error, it raises an
exception
if something’s wrong. This means no silent errors. Noisy errors are a
Good
Thing.
In Perl, while there is a strange way to deal with exceptions, nothing
uses
them. Perl objects tend to return a false value when something goes
wrong.
have to use it that way. It’s possible – and recommended – to write
entire PHP files without any HTML in them.
I realize this. My point is that many of the design decisions of a
template
language – very simple syntax, just sprinkle some global functions, the
assumption that no one will ever write anything huge in this – all of
this
leaves a lot to be desired when you want to use it for something else.
Perl started out as a report language, but it’s at least extracted the
“format” concept into a separate module.
To make it even more perverse, even PHP people tend to use other
template
languages (like Liquid) instead of PHP, to do their templating in PHP.
This is
profoundly ironic to me. I suppose next thing you know, Liquid will
become
Turing-complete, people will be writing Liquid apps, and we’ll need a
safe/better template language for Liquid?
People who learn PHP usually start as designers, who learn a
bit
of HTML and CSS, and need a tiny bit of server-side logic in their HTML
page,
so they learn a bit of PHP or paste a bit of code in…
You could say the same about JavaScript – people learn to write a line
or two at a time, so they never really learn to use the language. Both
JavaScript and PHP are pretty good languages if you allow them to be
rather than considering them extensions of HTML.
Oh, I agree. And just because some people learn Rails because it’s easy,
and
never bother to learn Ruby the language, isn’t really a point against
Ruby or
Rails. But then…
Javascript is a FAR better language than PHP.
Javascript has first-class functions (which are also closures), a decent
object system including prototypal inheritance, and the unification of
objects
and hashes (combined with that prototypal inheritance) means you can
build
your own inheritance system, or use classical inheritance…
It could almost be called multi-paradigm.
Frankly, the only reason I use Ruby instead of Javascript (where I do)
is I
like Ruby syntax better, and Ruby actually has bindings to native stuff
I can
use (there’s no Javascript filesystem API that I know of). I mean, with
v8,
Javascript is even faster than Ruby.
So, scratch the surface of Javascript, and it becomes a truly elegant
language. A lisp in disguise.
Scratch the surface of PHP, and it’s… more PHP. The next step in the
evolution of a PHP coder is probably to learn another language.
For that matter, I’d guess the better developers would see that there
are
better languages, and would migrate away from PHP, in the long run.
That’s what happened to me – but it wasn’t PHP’s language features that
did it. It was the fact that TDD was more feasible in Rails than in any
PHP framework I could find.
Now look at BDD, and at rspec. Or maybe rake.
Can you imagine building anything like that in PHP?
Maybe things have changed
since I
last used it.
Maybe you never really learned what you could do with it – as witness
your ignorance of DB library options.
Probably – I was mostly working with Wordpress and Drupal.
Good for you. Hey, I’ve seen Drupal. I was amazed – there are things I
strongly dislike about it, but here was object-orientation, modules,
mixins,
all kinds of good stuff. Sure, it was completely hacked together, and
not at
all supported by the standard, but it was decent.
That must have been Drupal 6. Drupal 5 was horrible – basically
reinventing OO in a fragile procedural way.
It actually might have been Drupal 5.
Drupal 6 was a complete rewrite, and I believe it does use PHP OO.
Yeah, so it would’ve been Drupal 5 that I was using.
VB is brain-dead. PHP is not, at least if you don’t try to use its OO
features to any great extent.
Or its reflection. Or the features it doesn’t have…
I’m sorry, but it’s obvious that you don’t know what you’re talking
about with respect to PHP.
I have a feeling I should be glad of that.
But just a quick test to see if it’s worth learning more again:
Does PHP have closures yet? Or even anonymous functions?
I’ll give you this: Languages evolve. It’s possible I don’t know what
I’m
talking about. It’s possible the tnx.nl guy no longer knows what he’s
talking
about. It’s possible that PHP will one day evolve into a beautiful
language,
or at least a decent one, leaving me only able to grumble about syntax
and
snipe at the <? at the top of each file.
On the other hand, from what I do know of PHP, I can still name four
or five
better languages off the top of my head. Why would we want to evolve PHP
into
a good language when we have so many good languages already?
