Slashdot Mirror
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."
When are they going to fix the insanity of all the string function names?
...a PHP story!
"PHP is a toy language" trolls in 3... 2... 1...
Basilisk Digital
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.
Virtually serving coffee
The sooner you fall behind, the more time you have to catch up.
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 fact that PHP doesn't have namespaces makes for a mess, compounded by the fact that the included functions are often named inconsistently.
Having done hundreds of thousands of lines of code in both languages, I favor perl; but don't hate PHP either. Both have tons of documentation (PHP's being more newbie friendly, but Perl's being more extensive). Both are very fast when coded properly.
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"? Maybe we'll let the statistics speak for themselves.
Any HTML page is a valid PHP page. You can sprinkle some PHP in an existing HTML page for some automation (which can end up in a big mess if you're not careful). As such, if you have an existing website in which you want to add a little bit of automation, PHP is most likely the 'best' option.
In perl it's the other way around- you start out with code and put bits of web page generation in there. As such, if you have an existing program that you want to port to be web-enabled, perl may be a better choice.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Well... there are multiple engines for including Perl in a web page like Mason and Apache::ASP.
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.)
Karma: Excellent (My Karma? I wish...:-( )
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 you have to use an instantiation hack.
But then, I could go on about my gripes with C++, Java, SQL, HTML/CSS, and pretty much every language I've ever coded in.
Don't you just hate it when people reply to your signature?
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.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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
-- B.
This sig does in fact not have the property it claims not to have.
This post explains most of my issues with PHP far more eloquently than I ever could.
haskell!
Did you ever notice that *nix doesn't even cover Linux?
Totally agree 100%. Another example: did you ever use nl2br() 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.
Bogtha Bogtha Bogtha
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. Currently hosting legacy PHP apps on a separate proxied Apache instance, but looking at running them as Python WSGI layers with WPHP.
There's a lot of movement in the Python web development space right now - Turbogears, Django, web.py, Pylons, WSGI... it's unlikely that there's nothing that would appeal to you.
Bogtha Bogtha Bogtha
I'm been using Smarty 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.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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 also doesn't prevent a skilled programmer from using good practices. If you are having so many difficulties with your projects, you may want to take a look at who is writing the code.
I'm not discounting that you have some valid points, but I also think your view is overly harsh. I've worked in many different languages, and they all have their faults. I find myself favoring PHP because it allows me to get good work done efficiently.
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 your script if they hack something up incorrectly).
Or you can roll-your-own. It's a solution, but now you're screwing the guy that comes in behind you and has to figure out what you did. If you designed it well and commented / documented it, then perhaps whoever's next is set... but how many people can you rely on to do that?
Smarty gives you a decent solution compared to each of the others. You don't have raw HTML in the templates. Designers can have pretty much free reign of the templates and you don't have to worry about them much (it's on them to make them work, right!?). You've also got a documented third-party system that's fairly well known. I guess we could argue over whether it's well documented or not, but it suits my needs (the documentation, I mean).
I'm in no way involved with the development of Smarty, btw. Just a happy user.
---John Holmes...
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, though its not F/OSS (there are "free-as-in-beer" versions, and the commercial versions are rather inexpensive.)
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.
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'.
... I'd actually recommend looking at Python aswell (my personal favourite), but that's not what you asked for. ;-)
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 tools aswell) and half of googles database is filled with PHP tutorials and forum threads on common PHP/MySQL gotchas.
If you want to do web stuff and unless you're in on some super complex parsing and data migration problem I'd strongly recommend PHP. If you're doing serial data-migration and plan on heavy use of Regular Expressions to solve your problem or have some other exotic procedural problem to solve that doesn't involve building a webapp, I'd suggest Perl over PHP.
We suffer more in our imagination than in reality. - Seneca
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 ocaml used a readable syntax, like I said. Trying to use C style function call syntax in ocaml gives you ENTIRELY different behaviour, and its not in any way the equivilent of calling the function with seperate args. My complaint is that the syntax for calling functions:
func arg arg arg
is much less readable than the tried and true C style:
func(arg, arg, arg)
Wishing the syntax was nicer is not the same as not knowing the language, next time try using your brain before you use your keyboard. How can you write a reply that actually points out how stupid the reply you're writing is, and yet still click the submit button anyways?
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.
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++?
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
* Arguments and return values are extremely inconsistent
* PHP has separate functions for case insensitive operations
* PHP has inconsistent function naming
* PHP has no lexical scope
* PHP has too many functions in the core
* PHP lacks abstraction and takes TIMTOWTDI to bad extremes
Open Source Java Web Forum with LDAP authentication