I wouldn't complain if a better server-side language came around (not a big fan of Ruby's syntax, but Google's Go looks enticing), but until then, I've built incredibly complex apps in PHP, and rarely do I run into a limitation of the language. My biggest issue in the past was the lack of namespaces, and 5.3 has those.

I think the best thing you could do to get a new language as popular as PHP isn't to evangelize, or even to make the language dead simple, but make it dead simple for administrators to add support to a typical shared hosting environment.

I'm pretty much in the same place as you with regards to PHP: I know it like the back of my hand and everything and everybody works with it. But the code is ugly compared to other languages and I really want method chaining, dammit. Plus, of course, I don't want to have to write an MVC framework every time I want to do something.

  $object->doThis()->doThat()->doTheOther();

  $string->preg_replace("/[^A-Za-z]+/","_")->trim()->upper();

$string = preg_replace("/[^A-Za-z]+/","_", trim(upper($string)));

Or am I missing your point?

What? We've been doing code like:

    filter('user')
        ->first_name->like('bob')
        ->age->equals('22')
        ->order_by->created->desc
        ->find();

I keep happening upon projects with their own craptacular homebrew MVC framework, and their own abysmal homebrew caching.

Fix is a swap for yii and memcached -- feel free to choose your faves.

Stockholm Syndrome?

Seriously, when you've been programming long enough, you really stop caring about programming languages. I could build a huge project in VB.Net or ColdFusion if I had to at this point. If there's good reasons for why a language should be used (and PHP has plenty of them that are external to the language itself), then it's immaterial to me.

namespace my\name;

$c = new \my\name\MyClass;

Ruby is very easy to run: puts "Hello World"

As is perl: print "Hello World";

Php? <?php echo "Hello World"; ?> (wtf is all that crap, says the new programmer)

The point the OP is trying to make is the "stupid simple with the web" side of the equation. Of course the PHP side isn't as simple as "the language runs on the web". PHP runs on Apache because of the tons of work put into mod_php to integrated it and make it work as easy as possible.

You can't "just run" php on nginx, lighty, etc. Then you need to setup FastCGI instances, and now you're no different from Rails land with mongrels or thins.

apt-get install php5

Usually you don't even need that.

You are confusing Ruby for Ruby on Rails.

Ruby is easy to run. Ruby on Rails, not as much(relatively).

When people just want something nice and simple, PHP works beautifully. There's nothing wrong with the parts of the language that people who don't know programming are using to glue pieces of their website together. It's really only once you start using it for more than that when you start hating the terrible design choices and language constructs.

Leave PHP as the ubiquitous solution for simple glue, it does it quite well. When people want to do web development beyond the glue they can turn to any other number of great languages/frameworks.

That's actually a good example for why it should die (embedding code in html).

confusing language and platform/framework - "the language now requires modification by a framework to do what you need." and "I want a language that assumes everything I will be building is an MVC web app, and builds that right into the core language, not just a library.". yikes.

Not sure what else to believe in this article after spotting basic errors (not to mention terrible cliches, assumptions, no background or references etc. and statements like this - "nowadays it doesn't feel like you're doing it properly these days")

Many of PHP's basic functions do not return objects, therefore method chaining frequently doesn't work. It would have been more correct to say that I want "everything is an object" to be a feature of the language.

Lambdas only recently turned up in PHP (though I'm pleased to see them!). My point is that in PHP these features are being shoehorned in late in life, and it seems like a language which was designed with the expectation of these features would be a better choice at this point.

And finally, yes, I want a language that assumes everything I will be building is an MVC web app, and builds the necessary infrastructure at the language level, with the performance and stability gains that implies, rather than having it built as a framework on top of the language. It seems weird, I realize, but no more weird than PHP seemed in 1995, with its assumption that everything you'd be writing was a web page.

I have more than a passing familiarity with C and Perl. References and pointers are very different. For example, you have to know where you allocated the memory pointed to to work with pointers effectively. You can also lie to the compiler about the type of pointer. You can also do math with pointers.

These are very useful things to do in C (or assembly or C++ or whichever languages give you access to raw memory), but you don't have to do any of those things in Perl because you don't have access to raw memory.

Similarly you can get into a circular reference situation with references that you won't normally find in C unless you have a specific type of garbage collector.

disputing the naming seems like nit-picking

Accuracy is important in programming. The difference between lightning and lightning bugs is not merely degree.

You seriously need to edit this post, or just take it down.

I'm starting to think that "confusion" can defined as "repeatedly expecting people will do what you think they should do after seeing they don't"

In this sense, thinking language and platform can be glibly separated is the approach that looks confused given the present era. Languages live or die today based on their default platform, their example code, their default programming style, etc..

Part of this is that large changes in group behavior are actually easier than small changes. Will we improve our Perl/C++/VB style - heck no, we're used to doing it our way. Will we learn a whole language with a whole new style? Maybe, especially if it can be sold as the sexy-secret-source. So talking about the whole package is realist if not literally accurate.

Perl has real arrays as well as hashes, though. PHP only has one object which acts as both.

> PHP has both lambda's

create_function() isn't really a lambda: the created function isn't bound to the local variable namespace that it was defined in.

Also, how does Perl not have associative arrays? Oh, you mean that vectors and dictionaries are separate types, whereas PHP has one type that does both poorly? Yeah, I'm sure that's why PHP is so popular.

(What is it with people writing about Perl as though they are experts without ever having written a Perl program?)

I've long believed that some sort of rigorous comparative linguistics education would only benefit programmers. Certainly it could have squelched some of the howlers in this article.

In Perl, you can pass only one kind of argument to a subroutine: a scalar. To pass any other kind of argument, you need to convert it to a scalar. You do that by passing a reference to it. A reference to anything is a scalar. If you're a C programmer you can think of a reference as a pointer (sort of).

That's from

http://www.troubleshooters.com/codecorn/littperl/perlsub.htm

... which I found because I, unlike the OP, happen to remember that the thing-which-is-sort-of-like-a-pointer-only-not-really in Perl is called a reference.

So let me help the original author: What he meant to say is that "Perl has things that remind me of pointers, but have a different name, and that aren't exactly pointers, but are nearly as confusing as real pointers, especially to someone who just wants to put up a simple web page in five minutes."

    foo("bar", "baz", "quux")

    foo(array("bar", "baz", "quux"))

I guess if you don't know anything about programming and never hope to, "Oh, well, uh..." is good enough.

This makes me sad.

Thus you can't compare something like Rails to PHP, but rather would need to compare Rails to the many frameworks out there. There are many frameworks out there that make working with PHP a joy, some like NOLOH (which I'm a co-founder of) feels like it's own thing completely allowing you to work in a single language that shields you from having to deal with the craziness that is client-server interaction, AJAX, Comet, SEO, etc, something which the author alludes to wanting to have.

If you don't want to use a framework, PHP can be very useful by itself to write quick scripts, just like many other languages. Furthermore, the release of PHP 5.3 last year has moved PHP forward considerably and makes the frameworks and libraries available for it even cleaner, and more powerful than before.

Personally, I'm an advocate of using the best tools for the job, but first it's important to understand what in fact that tool is and what it's capable of.

Ultimately, any blanket statement that suggests something that's being used by millions of developers and some of the largest companies out there should die just doesn't sit right with me.

I've noticed that it's in vogue to bash PHP, but frankly, with the current state of the language, along with its frameworks and libraries, there's no better time to work with PHP. It reminds me of a recent exchange I had with an associate of mine, we were talking about writing a script and when the mention of PHP came up, he bashed it without reason. He hadn't used PHP in years, but just had this impression in his mind that it was bad. Several days later I showed him the completed script in PHP and how clean, clear and concise it was. He was amazed.

I would hope that we could move beyond such statements and take pride in what we produce, instead of second guessing yourself when the tool you're using is getting the job done, lets explore some of the amazing tools, frameworks and libraries that are pushing PHP forward.

I've noticed that, too, I think a lot of people who bash PHP may have used it at one point, switched to something like Rails or Django, and assumed that PHP stood still, which just wasn't the case. In fact, while I may not use rails, I'm very glad it came about, because it was a very necessary kick-in-the-ass to other language communities to address common and necessary development concerns.

The thing about new technologies, is that they rarely replace the old technologies, usually they just provide new ideas to make the old technologies better.

Whatever eventually replaces PHP will have to be easy for beginners to get going with. I assume it will not be a compiled language. I think that rules out most of the languages on the JVM, even the really easy ones, because it is on the JVM, and dealing with compiling is one more hoop that beginners won't necessarily want to jump through. CLASSPATH is not friendly. Likewise, I'd rule out .NET languages.

New languages tend to gain a foothold when people change contexts, so I assume cell phones offer a starting point. A light weight script language that works on cell phones? I am not sure what that will be.

One thing that must surely die, is PHP 4. Please stop making your PHP projects backwards compatible from PHP 4.2 and up. PHP 5 is a lot more palatable and 5.3 even more so.

We have to kill PHP version 4. With fire.

It would be a service to all PHP users, as well as the PHP developers who still have to maintain the 4.2 branch. And it would move PHP 6 one step closer to reality, from the pipe dream it seems like today.

http://www.indeed.com/jobtrends?q=perl,+php,+rails,+ruby&...

edit:

Which is to say, I think javascript is a great language, has the benefit of being the de-facto language of UI development on the browser (and on a lot of embedded apps now as well). Nodejs alone is much too low-level and evented for normal humans to use for throwing together a web site without callback mindfucks, but its a great base to build something on.

I guess nobody here is calling for a new language to rule them all, or for a champion framework. I guess as hackers the least we can do is DO NOT assume that what we have today is what we'll need tomorrow.

I don't know if there's an easy answer to the dilemma (or if your arguments are solid enough) but it makes me think. Thanks for bringing this up.

A language isn't done until it's documented. Parts of the language available that aren't documented simply don't count.

A competitor has to beat PHP on both the lingual and documentation fronts to win.

True programmers aren't stuck to a language. They switch to whatever's best for what they're doing. Often, that means sticking with the language they know best to minimize issues and speed development. But often, they know multiple anyhow and have more choice available.

True programmers make a point to learn about the new languages and their strengths and weaknesses. If a new language came out and was worth looking at, they would. They may not learn enough to actually use the language yet, but always enough to know when that language might be the best solution.

This isn't entirely true. According to the two languages' Wikipedia pages, development on PHP started a year after Ruby. The first public version of PHP came out six months before Ruby.

http://en.wikipedia.org/wiki/Ruby_language and http://en.wikipedia.org/wiki/Php have more.

Here are the salient dates:

- Ruby conceived of in December 1993

- PHP development started in 1994

- PHP/FI 1.0 released in June 1995

- Ruby 0.95 released in December 1995

- PHP 3.0 released in 1997

Also, I'm not sure comparing languages by when somebody started toying with the first prototypes is very meaningful. You could say Clojure is decades old by viewing Lisp as a prototype.

The implication in the article, as I read it, was 'Ruby is a wizbangy new language that sprouted into being only recently' whereas the truth is that it and PHP are just about the same age.

The dates you posted show that this is almost certainly not the case, though they do indeed disprove the idea that "Ruby is a wizbangy new language that sprouted into being only recently".

It is likely this code predates that date given that there is no reference to the 0.95 release or anything before that.

update: the earliest release I can find is Ruby 0.49 from http://eigenclass.org/hiki/ruby+0.95 (direct link: ftp://ftp.ruby-lang.org/pub/ruby/1.0/ruby-0.49.tar.gz)

The earliest date mentioned in the CVS entries file is March 17, 1994.

To me, the point of this whole thing is that the author's statement of "Ruby is a newer...language" is inaccurate. You're absolutely correct that I cannot definitely prove that "development on PHP started a year after Ruby."

And language age comparisons are entirely meaningful in this case, given that the OA specifically describes Ruby as a newer language than PHP. Ruby is definitely clearer and cleaner. But it is certainly not newer.

creating a new language is not the answer. that will work up until the day you need to do something beyond tying a database to an html form, like process images or encrypt files or talk to a weird database that isn't mysql. php, ruby, and python have a ton of modules and 3rd party libraries that can be tossed in to accomplish a lot of things.