PHP 5.2.0 Released

ShaunC writes "The PHP Group and Zend have released PHP 5.2.0, and upgrades are encouraged. The 5.2.0 update offers several security fixes, including patches for a couple recently announced buffer overflows in input parsing. This release also includes a number of library upgrades, bug fixes, and default bundling of the popular JSON extension to help with AJAX development. See the full changelog for more details."

That's nice but...

[Ant P.]

When are they going to fix the insanity of all the string function names?

Re:

[Ant P.]

They didn't delete mysql when mysqli was released, so I see no reason why they can't do the same here.

Insanity? Fix?

[smittyoneeach]

One man's insanity is another man's business opportunity.
Verily, it is far better to maintain the insanity, at a reasonable price, than to set about fixing it.

Re:

[mattwarden]

Attitudes like yours are why people end up bitching about outsourcing/offshoring. If you're going to try to make money of poorly designed products, then you're going to end up whining that your job got shipped off to India.

Oh look...

[urbanradar]

...a PHP story!

"PHP is a toy language" trolls in 3... 2... 1...

Re:

[phase_9]

Toy language it may well be in your opinion, but it helps put food on my table!

Re:

[urbanradar]

Toy language it may well be in your opinion, but it helps put food on my table!

I'm not sure whether you're replying to my post seriously or in jest, but just to make it clear: I don't consider PHP to be a toy language either.

It's not the most beautiful of languages, it's often inconsistent, and it's very very easy to do very very stupid things in PHP. Also, there are a lot of very bad programming practices that are so frequent among the majority of PHP coders that you'll even find them in most tutoria

Re:

[OakDragon]

One of the reasons it has such a bad reputation is that is installed on 99% of those $5.00/month hosts. Well, that's the reason I know PHP. :)

Re:

[mrjb]

In my not so humble opinion, PHP does not deserve the reputation of being a toy language- I've found it stable and functional enough for very serious stuff (here in Holland, the eBay company "Marktplaats.nl" runs on PHP).

Yes, it has backwards compatibility issues. Most any upgrade path does. I personally deal with this by wrapping core functionality into a library. I've written sites that are insensitive to PHP versioning- they work equally well on PHP 3, 4 and 5. Programmers that require a specific PHP ver

Re:

[Builder]

There's one very good reason to NOT offer PHP as a hosting company though.

Far too often you are forced to upgrade because of security issues, but that upgrade breaks functionality. So as a hosting provider, you either have to have insecure servers or angry customers, and dealing with those angry customers takes time and costs money.

Re:

[LordSnooty]

There's one very good reason to NOT offer PHP as a hosting company though.

Conversely there's one very good reason to offer PHP, because your customers demand it.

Re:

[dkf]

Conversely there's one very good reason to offer PHP, because your customers demand it.

In that case, get better customers.

Re:

[AndroidCat]

A toy language? Excellent! I just got a small Linux board with limited* resources and I wasn't sure if PHP would fit. Are there many commercial toys programmed with PHP? :)

* Mind you, "limited" is relative. A 200MHz ARM9 chip with 32M ram [photobucket.com], 4GB flash drive, 2.4 kernel and Busybox beats the 486/25, 16M ram, 200M hard drive with Slackware 2.1 that I used to run my multi-user BBS on, while playing nethack, quite nicely. (Kids these days...)

Re:

[JabberWokky]

Or my 1Mhz 6502 with two 100K floppy drives that I used to run my BBS on. Yes, toy is relative. Later I upgraded to 8086 Corona luggables for each node. Nice and speedy.

--
Evan

Argh.

[Balinares]

Urbanradar,

Your comment pisses me off, but there's something I want to say all the same: I think you are, essentially, right. Whatever one's woes with PHP might be, they don't justify trolling and unsubstantiated mouthing off. Besides, "toy language" is a purely inflammatory statement that doesn't even have any factual content.

However.

However, the implicit underlying assumption I think I perceive in your comment -- that PHP criticism must be trolling -- annoys me a lot. Please allow me to expand on this.

You see, one constant characteristic of the Internet in general is the noise. Look here on Slashdot: do you read all the comments on any given story?

The noise is a bigger problem than you'd think. The noise means that it's hard to get heard. It means that to be heard, unless you're a remarkable writer (which I, and most people, aren't), you have to exaggerate your message. "PHP is a toy language" is one such exaggeration; and perhaps even actually worthy of being modded up if followed with factual information to support it. And much likelier to catch a moderator's attention with its use of strong language.

Which you would, undoubtedly, consider a troll all the same, wouldn't you?

As you can probably guess by now, I have crates of such information against PHP. (In my defense, I do try hard to gather evidence against my own tools of choice as well, for two reasons. One, being aware of their own idiosyncrasies allows me to work better with them. Two, it's a simple matter of intellectual honesty.)

The vagaries of life have landed me into a managerial-ish position in a small company that develops and hosts large-scale PHP websites. My responsibility here is twofold: ensuring that the sites work, and ensuring that they keep working.

I didn't know PHP before joining this company; I had a generally positive opinion of it beforehand, from reading Slashdot. So I got to discover it through that new role.

Let us just say, to put it mildly, that my opinion of PHP has quickly become very poor.

I think that managing a language's design and development is one of those jobs that's freaking damn hard. It takes a LOT of experience, critical thinking, introspection, knowing to prioritize issues, knowing to tap into the decades of experience in language design to understand what works and what doesn't, why, and in what context. And different people with different backgrounds and objectives are more or less successful with it.

And I don't feel the people behind PHP -- I'm sorry, guys, I don't know how to put it nicely... -- are doing the best possible job of it.

More precisely, my primary issue with PHP is its culture as a project. Cultures are inherently difficult to describe, but if I had to put it in a few words, I'd call it the "Works for me" culture.

Simply put, the sort of attitude that PHP seems to encourage -- by which I mean, the shortest-path-to-arrival approach to doing most things in PHP -- work fine for the developper producing the code, but are formally broken in a way that WILL come back to bite the ass of whomever poor dude is in charge of keeping the thing working.

For instance: I understand PHP uses a function based on the tolower() C call to make method calls case insensitive, and leaves it at it. It works for them, doesn't it? Except that in the real world, it breaks. Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it? No, it isn't: PHP's gettext functions for dynamic translation require the locale to be set appropriately (unlike that of other languages). And I have my Turkish clients on the phone a lot.

Until recently, before the introduction of PDO, the canonical native way of addressing databases was to use PHP functions named after the database itself (mysql_*, etc, making the process of migrating databases, or creating a site that may have to be deployed client-side on varying database backends, an utte

Mod Parent Up!

[Builder]

This post explains most of my issues with PHP far more eloquently than I ever could.

Re:

[Directrix1]

So what software do you think actually meets your criteria (preferably FLOSS).

Re:

[Balinares]

All of my criteria? None. That's my point. There is no technology that doesn't deserve its share of criticism.

(Actually, asking people what their preferred tools' most important drawbacks are is generally a good litmus test for their competence. If they can't tell you what the pitfalls are and how to work around them, or why they don't affect the task at hand, watch out.)

Simply, some tools are a better match than others for any given task.

For instance, I think that PHP makes for a good, simple and effective

Re:

[itsari]

Python.

It has deep-rooted support for meta-programming and introspection. Namespaces are simple and straight forward. The re-occurring interfaces in Python shave down development time and encorage uniformity.

Using Python is actually a pleasure. Mind, it does have its flaws: Performance (which is about on par with PHP), populatity (not deployed as much as PHP), and some OOP querks (but still better than PHP's).

Arghmen

[Bogtha]

I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice.

Totally agree 100%. Another example: did you ever use nl2br() [php.net] to convert newlines into <br> elements? It's an extremely common thing to do. In a minor patch release, they changed the function to generate XHTML instead of HTML. In one stroke, everybody who thought they were generating valid HTML had errors in their code. This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain. You end up having to go back and change all your code to use generic string replacement functions.

Now, maybe you might say that it's a sensible thing to change (I disagree, there should be different functions for HTML and XHTML), but at the very least, they should have put a change in semantics in a major version update, not sneaked it in between 4.0.4 and 4.0.5.

It's not really the design of the language that's the real problem (although it's not pretty), it's the cavalier attitude from people who don't seem to take a professional attitude to their work that really grates.

Re:Arghmen

[nuzak]

Amen to the cavalier attitude. You know about PHP's Javascript-esque === operator? (that's the one with three equals signs). That got designed on the spot in an IRC session with Zeev and some other devs. Because I actually had to explain to these folks what the concept of "object identity" was, i.e. what lisp does with 'eq', python does with 'is', and Javascript does with ===. Yes, because PHP's is different. Not only does === fail to do object identity testing, it's simply '==', does all the "deep comparison" of ==, but also bothers to compare the type.

In other words, I was unsuccessful in explaining this rather basic concept. They got it blisteringly wrong, and hacked this wrongness into the language for all time. I attempted to explain (much more patiently than here) that no, this is not what === is supposed to do, but I wasn't heard. Not by Zeev, not by anyone else on channel. No one got it at all.

I passionately hated PHP for a long time after that, but it's just not relevant enough to my work anymore to hate. I have choices, I don't have outside clients demanding I use PHP anymore, and my choice of languages is respected where I work. I've chosen python for some projects, perl for another, C++ for another (the C++ one was of course not web). I could probably write my next project in Haskell and no one would bat an eye (though I will be stuck with maintaining it for all eternity). I'm even eying Prado -- a PHP library -- for an upcoming project, though I've still no desire whatsoever to write actual business logic in PHP, so it'll have to be solely at the view end of things.

Re:

[merreborn]

In PHP's defense, it is desperately in need of the current functionality of ===, because 0 == false, and there are core PHP functions that return *both* 0 and false (which mean entirely different things, in context). As such, you're left in a situation where you must use PHP's === to tell which one exactly the function gave you.

An object identity comperator is all good and fine, but PHP needed this functionality much more desperately.

At any rate, I can't disagree with the perception of ineptitude on the pa

Re:

[nuzak]

I looked at the bug, and it appears that it's gc'ing as expected, but doesn't let the OS reclaim the extra heap. This is pretty much to be expected, almost all language runtimes behave this way. Heck, most virtual machines like Java or Smalltalk allocate a fixed heap right off the bat.

Perl also has the batty notion of "scalars" and as a result believes that a zero in a string is false, and makes string comparisons really hell with its own insanity around 'eq' ... though Perl's also not in the habit of pas

Re:

[TheLink]

Question: what's wrong with string comparisons and eq in perl? Examples please if possible.

Re:

[nuzak]

Strings are only comparable for string equality with 'eq'. The == operator compares only numeric equality, and the numeric value of any string that doesn't look like a number is, in fact, zero.

$ perl -le 'print "matches" if "foo" == "bar"'
matches


If you use -w or "use warnings", which any sane person should do, you get a warning about it. That perl's scalar type lets you play fast and loose with strings and ints with is fine for one-offs, but there's no flag or pragma that actually separates strings and in

Re:

[TheLink]

But that's not a problem, that is a correct way to do things. Perl is intentionally weakly typed.

If you want to have weak typing and compare stuff then when you want to compare different types of stuff with each other, you need different operators/functions depending on what sort of comparisons you want to do. The alternative is to be verbose and convert stuff before comparing.

Maybe not the only correct way, but definitely better than PHP's way - where they didn't seem to think about the implications of wea

Re:

[HaydnH]

"This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain."

If you had a decent QA process in place you wouldn't upgrade all of your prod servers in one go without testing the upgrade in dev first.

Re:

[Balinares]

HaydnH,

I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulner

Re:

[Abcd1234]

Wow, it's amazing how easily you missed the point. Let me rephrase:

In a minor release, they significantly changed the semantics of a commonly-used function. And they did so with little warning. This is unacceptable. Period.

Re:

[larry bagina]

A lot of php functions are idiotic/redundant. nl2br -- because it's so hard to use str_replace?

One of my complaints is that they add these half-assed functions and then add new parameters, change the semantics, etc. etc.

Consider http_build_query -- a useful function (but it would only take 3-5 lines of php code to write it yourself). Only available in php 5+. Except they added a new parameter in PHP 5.1.2 (making it actually useful), so you'll probably have to rewrite the function yourself.

It would

Re:

[masklinn]

Python's "import from future" is a good approach here, IMO. Language features can get kicked around, have the bugs shaken out of them, without becoming part of The Official Language. If they pass the test, they make it in. In the mean-time, it's pretty clear you shouldn't be relying on them.

Actually, "from __future__" is more about letting users get a feel of the soon-to-come core changes of the language (also called "incompatible language changes" in __future__'s DOCSTRING). And about rooting bugs out i

Re:

[odujosh]

Umm PHP does not make good egineering practice. You hit walls as you code. Naming conventions are not standardized throughout the frame work. Modulazation in PHP is what duct tape is to home repair.

Biggest hit:
PHP is interpretted not compiled and there is no other option besides third party wrapping of compiled code.

In ASP.NET for example I can precompile my site in DLLs to whatever degree I am comfortable with. So if I want my Data Access layer locked down after a certain phase I can keep my junior develop

Re:

[abradsn]

I've noticed that most open source projects are the way that you describe, with the culture you describe.

If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.

While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.

Maybe you used to

Re:

[uss_valiant]

Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it?

Yeah, we couldn't understand that issue either. While our project has been translated into Turkish, it will never work on PHP 5.x with that locale. From http://codex.gallery2.org/index.php/Gallery2:Known _Issues [gallery2.org]:

Turkish locale with PHP 5.x - PHP 5.x has a bug that will not be fixed [php.net] that prevents G2 from working in Turkish. Workaround: use PHP 4.x

I'd have h

Re:

[Megaweapon]

"PHP is a toy language" trolls in 3... 2... 1...

It's not trolling when it's true.

What backwards compatibility has it broken?

[melonman]

Our company does web hosting, and every single time we get an enquiry involving PHP it comes with a caveat along the lines of "but I need version 4.x.y with version z of the q module and safe mode turned off". The best one yet was someone who wanted us to promise never to upgrade PHP because his XSLT module needs pre-version 4.4 - a bit of googling revealed that there's a whole section of the PHP community hunting for servers that will never upgrade for that reason. We never ever get this with perl, because backwards compatibility works over decades.

Re:

[TrueKonrads]

Amen brother! Cue the differences between behavoir for PHP on windows and PHP on Linux. The ocasional memory corruption (I've expirienced it myself), the no namespaces, the.... Whatever, as long as people don't kill each other.

Re:

[NoMaster]

To be fair, this is primarily because PHP allows any clothead to write some POS code without respect for logic, security, or sanity - at which point it suddenly becomes the most popular module / mailing script / CMS / message board ever.

I happen to like PHP, but I can also appreciate what a fecked-up language it is. Anybody who isn't coding with safe mode on and register_globals off in this day and age should be taken out and shot - it's been recommended practice since 4.1, and I wished 5.0 had bitten the b

Re:

[suv4x4]

Anybody who isn't coding with safe mode on...should be taken out and shot

Are you sure this is what you wanted to say? Safe mode was a terrible hack since day one, and it's considered to be removed from future editions of PHP

Re:

[melonman]

Anybody who isn't coding with safe mode on and register_globals off in this day and age should be taken out and shot

Yes, but

1. A lot of webmasters using PHP grab the nearest free PHP library that claims to do what they want, and then shop around for someone mad enough to host it. The worst one we've seen was a "manage your mailing list via your webserver" system (why?!) which, by default, tried to open 65k local SMTP connections at once. I was quite impressed that our server didn't just roll over and die

Re:

[Hynee]

To be fair, this is primarily because PHP allows any clothead to write some POS code without respect for logic, security, or sanity - at which point it suddenly becomes the most popular module / mailing script / CMS / message board ever.

I see you've modded PHP-Nuke before!

As for register_globals, I don't feel it is a problem, if you allow variables to be injected into your code from outside then you haven't programmed properly. I always initalize them first, at the very least to NULL, to make it a kind

Re:

[cerberusss]

So sell these people a Xen solution.

Re:

[tehshen]

Naah, we never get this with Perl because PHP has a brilliant php.ini, which means that scripts aren't guaranteed to run on any two different hosts, depending on the options set.

Re:

[a.d.trick]

I'm not so bothered by the fact that they break backwards compatibility, but that they are rather inconsistent about when they do it. In a perfect world, they would change their majorversion number whenever they did it. Of course we would probably have php 30.something if they followed that standard, but at least people would know when to watch out. As for XSLT and the XML stuff in general, the break was inevitable. The old iterfaces were pretty bad. I wish they would have saved their changes to version 5.0

Re:

[foniksonik]

Those people need to get a dedicated server.... if it's so important to them they won't mind paying a little extra to get what they require.

Re:

[mattwarden]

Amen. PHP is notorious for breaking crap with little point releases. Remember when they just turned off register_globals and broke 90% of PHP applications? Was this a major release? Was it highlighted in huge blinking bold red text with scary background music on the download page? No. It was one small note in the changelog of a minor point release. I love PHP, but the maintainers are idiots when it comes to this stuff. They don't understand their users at all.

Re:

[CopaceticOpus]

First of all, it's trivial to run two versions of PHP on the same server, and to use one version or the other on a per-directory or per-file basis. So there's no reason old code needs to stop being run if it's still useful.

Secondofly, the changes from back around 4.0 to where we are now with 5.2 are fundamentally huge, and they move PHP to a much more serious, professional class. Breaking backwards compatibility was worth it. It's sad that there has been so much resistance to change. Personally, these chang

Re:

[edxwelch]

That buffer overflow error would be another reason why you would want an older version, becuase it didn't exist in PHP4

Re:

[garaged]

I wonder why I have this friend that haven't been able to upgrade to mod_perl2 for ages :)

Re:

[ImustDIE]

Perl is stable -- Perl 5 has been out what... 10 years now? CPAN is also an amazing module repository and makes installing modules a breeze. Perl is also more powerful than php, and the syntax allows for certain things to be done more succinctly.

The best thing about PHP is that it's easy. The syntax is simpler than Perl, so it is easier to pick up. It also has a ton of built-in functionality so you don't have to go looking for modules as often, but that mass of bundled functionality combined with the fa

Re:

[DarthChris]

when coded properly

This is an absolute key point that the 'toy language' crowd often miss out on. PHP is a good language, when used correctly, and when coded properly - i.e. the same as any other language/tool/whatever.

I do have a couple of gripes with PHP however. Firstly, as the parent (and a myriad and one other people) pointed out, inconsistent function names. Secondly, the presence of objects in the language - IMHO OOP is a bit overrated - and if you try to take PHP V4 objects to PHP V5 objects y

Re:

[mrjb]

If you want to be fair, you should compare modperl with the modular version of php.

Syntactically, they're relatively similar. Obviously the PHP/Zend folks knew perl before they started on PHP.

Perl was originally intended for string handling, but is also quite suitable for general-purpose programming. Perl has CPAN- almost any module you'll ever need is probably already there.

PHP was originally intended as HTML Preprocessor - so it is specifically targeted at web programming. Which of the two is "better"? Ma

Ever heard of Mason, etc, etc

[BerntB]

Any HTML page is a valid PHP page. You can sprinkle some PHP in an existing HTML page for some automation

Well... there are multiple engines for including Perl in a web page like Mason [masonhq.com] and Apache::ASP [apache-asp.org].

But the Perl world is moving away from code-in-html. Generally, it is considered a better idea to isolate UI and logic from each other. The web frameworks for Perl, like e.g. Catalyst and Jifty, generally use Template engines like HTML::Template and Template Toolkit (Google/cpan yourself.)

Re:

[budgenator]

I'm been using Smarty [php.net] templateing engine recently and I have to say that the break even point for using templates Vs. "sprinkling some PHP in HTML" has almost hit bottom! Getting the code out of the page lets the programmer actually see what he's doing and think more about doing things the right way.

Re:

[Sepodati]

Smarty is pretty useful, imo. I'll agree that it's bloated a little and I'd love to see a "Smarty-Lite" version that gets rid of the fat, though.

No matter what, you have to come up with a templating solution. You can use PHP, of course. Regardless of project size, it's useful, but you end up with raw PHP code in the template. If you're the programmer for each, that's fine, but you don't want to be handing over templates to your designers where they can enter any PHP code and have it executed (or error out y

Re:

[Qbertino]

PHP is a descendent of Perl - it was originally programmed in Perl to extend Perl with templating functionality. That's long ago, but it still shows in the overall quirkyness of PHP wich is of a simular 'flavour'.

That been said, PHP has by far the largest set of available tools to help you do big projects of any web-oriented PL. Tons of commercial and/or OSS IDEs (PHPEclipse - especially the easyeclipse distribution - is awesome for a free tool), Debuggers, etc. It's pratically maried to MySQL (tons of too

Lemme guess:

[tonigonenstein]

char buf[1024];
scanf("%s", buf); /* oups */

When you could do

std::string buf;
cin >> buf;

This is 2006 people, buffer overflows are so 1970.

Re:

[LizardKing]

Or even:

BufferedReader in = new BufferedReader(new FileReader("foo.in"));
for (String s = in.readLine(); s != null; s = in.readLine()) {
// do stuff ...
}

Re:

[everphilski]

Because I'm lazy and that is way too much typing. C++ FTW.

Re:

[elFarto the 2nd]

char buf[1024];
scanf("%1024s", buf);

Fixed!

Regards
elFarto

Re:

[LizardKing]

Nope, the string format field width should be at least one byte less than the array to allow for a null. See the description of the 's' format in the scanf(3) manpage [openbsd.org].

iostream bloats your binary

[tepples]

Thing is, familiar implementations of C++ (including GCC on Windows) will bloat your executable by 200 KB if you use std::cin and std::cout of <iostream>, even if you strip it (gcc -s). It's especially a problem when trying to make a web server on a custom embedded OS that runs on a machine with 4 MB of RAM. Is this a problem peculiar to GNU C++?

Re:

[TheSunborn]

I tried to compile the following program, on my fedora core 5 using
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Generating 64bit code.

#include <iostream>
#include <string>
using namespace std;

int main() {
std::string buf;
cin >> buf;
cout << buf;
return 0;
}

And the size of a.out after strip vas 7016 bytes. That is using dynamic linking. If I static link it insted, it grow to 1 MB.

Re:

[tepples]

And the size of a.out after strip vas 7016 bytes. That is using dynamic linking. If I static link it insted, it grow to 1 MB.

On Windows, using latest stable MinGW package (they're stuck at gcc 3.4.2), I do

g++ -Wall -O -s bighello.cpp -o bighello.exe

and get 275,456 bytes for the same program. I guess it's static linking at least part of the C++ standard library. Most notably on embedded systems, you have to either static link or load the C++ library into RAM.

Re:

[gbjbaanb]

and, for those interested, using MS Visual C++ v8 with all the default options it comes out as 6656 bytes. Obviously, statically linked it'll grow somewhat (to 114k strangely enough. I was expecting more)

Re:

[illuminatedwax]

haskell!

Re:

[Bogtha]

Perl, Python and Ruby zealots need not respond!

Good thing, I'm only pro-Python, not a zealot then. I switched a while back, and got a big productivity boost. mod_python+PostgreSQL+Kid for templating works nicely. Just moving over to Apache 2.2 now, and considering replacing Kid with Genshi [edgewall.org]. Currently hosting legacy PHP apps on a separate proxied Apache instance, but looking at running them as Python WSGI layers with WPHP [pythonpaste.org].

There's a lot of movement in the Python web development space right now -

Re:

[DragonWriter]

What language/runtime combination are other PHP users looking to switch to?

I'm not really much of a PHP user, though I've toyed with it, and I'm not really looking to switch, but you may want to look at REBOL [rebol.com], though its not F/OSS (there are "free-as-in-beer" versions, and the commercial versions are rather inexpensive.)

Already switched to.

[Generic Player]

I'm using pike right now. I actually started writing a web framework for pike. If you don't mind having to write statically typed code, but getting run time type errors anyways, then pike is a good choice. If you need strong typing though, then keep looking. Ocaml is nice if you can tolerate its syntax, but I personally find:
function arg1 arg2 arg3;
to be a terrible mistake, as
function(arg1, arg2, arg3);
is much clearer.

Are you on drugs?

[Generic Player]

Your post is complete and utter nonsense. Did you even bother to read my post? Yes, I do know ocaml. No, you cannot use a C style syntax for function calls (unless you work some camlp4 magic). Passing a single argument that happens to be a tuple is not the same as passing 3 args. You even pointed out how dumb your response is in your response! If you define all your functions to take tuples, currying is gone.

I don't want to pass my functions tuples, I want to pass it the seperate args. I just wish oc

Ok, you got me on the first one.

[Generic Player]

I try to give ACs the benefit of the doubt, and the first reply was just barely sane enough to get me to bite, well done. But you can't just go jumping way overboard like that, its WAY too obvious you are trolling now. Try to stay subtle, or at least turn up the crazy a little more gradually.

PHP

[CopaceticOpus]

I agree that PHP can encourage a quick-and-dirty approach, and that the language is not perfect. The function naming and lack of namespaces are poor, and internationalization has a long way to go.

That being said, I believe it is possible to create high quality, professional, maintainable code with PHP. If it wasn't the case, large companies such as Yahoo wouldn't be adopting it. PHP has an emphasis on productivity, and it doesn't attempt to enforce good practices in the language structure itself. But it als

My wish

[Espectr0]

Since every version of php breaks compatibility somewhere, how hard would it be to rename all functions to maintain consistency in php6 or 7?

PHP has got to be the most inconsistent language out there. Check out this list [tnx.nl]

* Arguments and return values are extremely inconsistent
* PHP has separate functions for case insensitive operations
* PHP has inconsistent function naming
* PHP has no lexical s