Changes In Store For PHP V6

An anonymous reader sends in an IBM DeveloperWorks article detailing the changes coming in PHP V6 — from namespaces, to Web 2.0 built-ins, to a few features that are being removed.

Comments

Is this really news?

[Adam Zweimiller]

I know it's mother's day and all, but there's got to be something somewhat interesting going on in the "nerd" world, right? Just sayin', a week old report on the PHP6 *planned* features isn't exactly frontpage news. It's so boring in fact, I felt the need to reply and bash the post just to alleviate my boredom. Neurotic, eh?

Re:Is this really news?

[truthsearch]

Especially since most of the "new" features are either already available or will be included in v5.3. There's literally nothing new here except better Unicode support.

Re:Is this really news?

[moteyalpha]

I just came here to help support open source. The articles may not always be winners, but the tag lines and comments make up for that.

Re:Is this really news?

[truthsearch]

The articles may not always be winners, but the tag lines and comments make up for that. Exactly. (Warning: blatant plug.)

Re:Is this really news?

[bcat24]

There's literally nothing new here except better Unicode support.

True, but better Unicode support is a very major feature in and of itself. Let's face it, writing a Unicode-enabled Web application with PHP 5 is like hunting wildebeests with a BB gun. It's possible, but it sure ain't easy.

Re:Is this really news?

[MightyMartian]

I simply can't wait for an even bigger php.ini file to support disabling and re-enabling of deprecated functionality. I've spent several evenings over the last few weeks on a contract to clean up some really bad PHP code, and a good fraction of that time has been spent actually getting a test bed up and running, trying to match the Win32 PHP 5 install I'm forced to work with the Linux PHP4 install on the production server. More than ever before I'm convinced that PHP is the worst major language ever invented, and I'll wager PHP6 only makes it worse.

Re:Is this really news?

[Linker3000]

You moan - yet you took the contract.

Biting the hand that feeds you just a tad!?

Re:Is this really news?

[Anonymous Coward]

People USE Unicode?! Back when I was a youngin' we used ASCII and LIKED IT!

Re:Is this really news?

[Enleth]

Well... Don't take contacts when you're not familiar enough with the technology it requires so that you don't need to struggle with it at all?

Re:Is this really news?

[SanityInAnarchy]

s/unicode/$foo/gi

I suspect this will be modded troll, and that would be fair. Go ahead. Has to be said, though.

Some languages, I see the point of. I understand why Visual Basic still exists, even if I despise it. I understand why C exists, and even why Java exists.

PHP, I just don't get. Why bother? It's Perl, minus a bunch of features, in a templating language. As soon as you discover that other languages can be embedded into a webpage, too, I cannot think of a single thing that PHP does better than just about anything short of C intended for developing web apps.

The one thing that I can appreciate about PHP is the massive amount of stuff that's already written in it -- like COBOL, it will remain popular and used for that reason alone. But unlike COBOL, it continues to be actively developed, and used for new projects. Why?

Were it just about anything else, people might come to me with code samples, showing at least one niche thing that their pet language does beautifully, or at least, that they believe shows it lacks a weakness of some other language. Prove me wrong -- show me some beautiful PHP code.

Re:Is this really news?

[NamShubCMX]

Unicode support is reported to become available for 5.3+ later as a module.

What I've heard the developers say, basically, is that there is no real roadmap for 6.0, since 5.3 has most of the planned features and unicode (the big new thing) will be available sometimes, although not built-in.

Re:Is this really news?

[dgatwood]

What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language. Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.)

PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be. There's no having to manually re-indent dozens of lines of code because you needed to add another nesting level and whitespace is part of the language, etc. It's just a really clean, lightweight OO language that's exceptionally easy to learn and happens to integrate very well with HTML.

Don't get me wrong, PHP has plenty of weak points when it comes to performance (particularly when dealing with massive complex data structures), availability of modules to do various obscure things, etc., but as a language, it is pretty nice, IMHO---mainly because it isn't a kitchen sink like Perl.... :-)

Re:Is this really news?

[Anonymous Coward]

1. They don't just USE Unicode: they put it into XML by the megabyte!
2. Then they came out with a functional programming language called XSLT on top of that.
3. ...
4. Profit!!1!

Re:Is this really news?

[pembo13]

That's pretty unfair circumstances under which to judge any language.

Re:Is this really news?

[lambent]

Wait, you're going from Linux php4 to win32 php5? or is it the other way around? Either way, that's atroscious. Why did you think you /wouldn't/ have a horrible time with it?

Nothing inherently wrong with PHP in this scenario; you've been forced to inherit somebody else's disaster. THAT'S your problem.

Re:Is this really news?

[moderatorrater]

and happens to integrate very well with HTML Yes, like regular expressions happen to be good at finding string patterns. PHP is good because it is first, foremost, and almost exclusively a web scripting language, which means you get really like features like super globals, HTML embedding, loose typing, great escaping functions, etc. Most other languages try to be all things to all people, but PHP has a focus and it does it pretty well.

Re:Is this really news?

[chromatic]

PHP doesn't have any weird syntax... It's just a really clean, lightweight OO language.... as a language, it ... isn't a kitchen sink like Perl.

Did you have to shower after writing this? Did you at least burn the keyboard?

Re:Is this really news?

[Anonymous Coward]

echo "hello world";

Re:Is this really news?

[Anonymous Coward]

<?php
while (true)
  mail("ninja@slaphack.com", "Programming question",
    "What language should we be using and why?", null);

Re:Is this really news?

[mini me]

What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language.

That's the problem with PHP. It requires all the hard work of writing C-like code, without any of the benefits that one might chose C for.

Re:Is this really news?

[larry bagina]

PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be.

Interesting example of PHP superiority. Perl regular expressions are delimited with / (or another character) because it's part of the language syntax. But if your regular expression is encapsulated in a string, there's no longer a need for it (which would simplify things since you don't need to escape it). Yet the pcre functions use a delimiter. Monkey see, monkey do. Without knowing why.

Re:Is this really news?

[natrius]

There's no having to manually re-indent dozens of lines of code because you needed to add another nesting level and whitespace is part of the language, etc.

First of all, if you don't re-indent your after adding another nesting level, you are making your code hard to read, and if I have to work on it after you, I will hate you for it. This is one of the reasons that Python is so pleasant. It forces people to write decent code.

Secondly, if you're manually indenting each line of code, you should start using a modern text editor.

Re:Is this really news?

[ewanm89]

"What language should we be using and why?", null);
+ }
+ ?>

#P

Re:Is this really news?

[Anonymous Coward]

That's because PCRE syntax is more baroque than most people can remember. /(?i)foo/ is more general but all the code I've ever seen uses /foo/i, so the trailing delim is needed, and the leading delim is there to match it because you could use something other than /.

Re:Is this really news?

[dgatwood]

Not really. Ever try to do lots of string concatenation in C? The realloc function is not anybody's friend.... PHP is like C without its most obnoxious flaw.... :-)

Re:Is this really news?

[dgatwood]

Depends on how significant the change is and the probability that you're going to reverse the change in five minutes. I can't tell you how many times I've added an "if (0)" around a giant block of code temporarily to test something.

And yes, I'm manually indenting. I vi, therefore I am....

Re:Is this really news?

[encoderer]

...You have to... burn the keyboard?

Re:Is this really news?

[encoderer]

Really?

Like what?

Really, can you give me one example of the "hard work" you're talking about?

Re:Is this really news?

[encoderer]

First of all, if you don't re-indent your after adding another nesting level, you are making your code hard to read, and if I have to work on it after you, I will hate you for it. This is one of the reasons that Python is so pleasant. It forces people to write decent code.

Secondly, if you're manually indenting each line of code, you should start using a modern text editor.

Aren't you contradicting yourself here?

More pointedly: If poorly-indented code is so troublesome that you'd "hate" the offending developer, you should start using a modern IDE.

Re:Is this really news?

[SanityInAnarchy]

And yes, I'm manually indenting. I vi, therefore I am.... Vim can auto-indent. It shouldn't be too hard to find a command, or a script, to indent/unindent large chunks of text.

I use Kate. Click & drag to select a large chunk of text, then tab/shift+tab to indent/unindent it. Trivial.

Re:Is this really news?

[SanityInAnarchy]

More pointedly: If poorly-indented code is so troublesome that you'd "hate" the offending developer, you should start using a modern IDE. I prefer a modern editor to a modern IDE.

I do want a certain amount of control over the structure of my code, even if a lot of it will be by convention. Having any automated tool try to "fix" someone else's code is likely to screw up things like comments which are cleverly indented and aligned with some code, or similarly interesting code.

And an IDE is overkill in many other ways, yet they still often find ways to miss some functionality I want. That, and I tend to be much more easily able to switch text editors than switch IDEs.

Disclaimer: I'm not GP, and I use Ruby.

Re:Is this really news?

[mini me]

Ever try to do lots of string concatenation in C?

Sure. PHP is simpler, but it's not like it's hard.

GString *s = g_string_new("Hello");
g_string_append(s, ",");
g_string_append(s, " ");
g_string_append(s, "World!");
g_string_free(s);

The fact remains, for a scripting language, PHP requires you to do far too much work. More work leads to less maintainable code. At least in the case of C, the extra work is justified.

Re:Is this really news?

[chromatic]

It's the only way to be sure.

Re:Is this really news?

[SanityInAnarchy]

Actually, I don't care, as long as you're not writing spambots in that language.

Re:Is this really news?

[dgatwood]

What the heck is g_string_append? It sure isn't part of the standard C libraries in most OSes. Without custom, nonstandard string libraries, in standard C, that looks like this:

char *s = malloc(strlen("Hello")+1);
strcpy(s, "hello");
s = realloc(s, strlen(s) + 2);
if (!s) { return -1;}
strcat(s, ",");
s = realloc(s, strlen(s) + 2);
if (!s) { return -1;}
strcat(s, " ");
s = realloc(s, strlen(s) + 1 + strlen("World!");
if (!s) { return -1;}
strcat(s, "World!");
free(s);

See why "$s = 'Hello' + ',' + ' ' + 'world';" seems so nice by comparison? :-)

Re:Is this really news?

[SanityInAnarchy]

PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be. Regex is never really going to be readable without a separate course learning that. By the time you know regex syntax, a little extra syntax in your language isn't that bad.

There's no having to manually re-indent dozens of lines of code because you needed to add another nesting level and whitespace is part of the language, etc. And there's no need to do so in any modern programming environment, either. Most text editors these days have ways to re-indent code, uncomment/comment keyboard shortcuts, etc.

It's just a really clean, lightweight OO language that's exceptionally easy to learn Easy to learn if you already know HTML, I suppose. But where's my actual, interactive PHP shell that I can play with while I'm learning the language?

OO? Only recently.

Clean? Not even close, not when you've used a real OO language.

and happens to integrate very well with HTML. So does everything else, now. I'd argue Ruby is actually better at this than PHP.

Don't get me wrong, PHP has plenty of weak points when it comes to performance My language of choice right now is Ruby, so I don't really care about that.

availability of modules to do various obscure things Considering the amount of crap built-in to the language, I doubt that's a huge stumbling block, either. I like CPAN, but it does help when the language itself is clean enough that I'll happily write a library of my own. But most that I'd need to do with a C library has bindings everywhere I really want to do it.

mainly because it isn't a kitchen sink like Perl I think Perl has too many built-in functions, available everywhere, completely un-namespaced, compared to Ruby.

But you know what? Perl has a little over two hundred functions in the main namespace. PHP has a little over three thousand, according to this page.

So, it may not have the kitchen sink in the syntax, but it has the kitchen sink, the bathtub, the plumbing, and the neighbor's shower in the core library.

Finally, I call BS on this:

Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.) Is there a language, other than Python, that this isn't true of, for very simple, "Hello World" or "My first HMAC implementation" examples? Sure, the rules would be different, but dropping all the type declarations (swapping for "var") and adding dollar signs is significant.

Oh, and does PHP support structs? What about function pointers? I doubt it's "almost any code". It's easy when you understand both C and PHP, but again, I assert that's true for many languages, particularly popular web scripting languages.

Re:Is this really news?

[mini me]

Ruby:

class Foo
  %w(one two).each do |method_name|
    define_method(method_name) { method_name }
  end
end

PHP:

<?php
class Foo
{
// Respond to method one and two, returning the method name
    function __call($method, $args)
    {
        if (in_array($method, array('one', 'two')) {
            return $method;
        } else {
// The documentation is not clear how to notify
// the caller that the method does not exist
        }
    }
}
?>

It's a silly example, but it highlights a shortcoming of PHP that does make for more work when the concept is extended into the real world. Furthermore, the Ruby code is fairly self-documenting. The PHP, not so much.

Re:Is this really news?

[encoderer]

Honestly, any IDE worth it's salt has by now solved the auto-formatter problem.

It's a by-demand feature so it's not like Word AutoCorrect. And you should be able to use a nice WYSIWYG editor to build the rules.

This is what you get, for example, in Eclipse and Visual Studio.

Personally, I like things like integrated FTP, integrated subversion, integrated unit testing, and, most of all, an integrated server-side debugger w/ all expected function: breakpoint/play/step control, stack and heap manipulation, etc.

All of these are possible using a text editor, but you need 5 different applications and none of it works together.

Not to mention: INTELLISENSE and DATA TYPE DISCOVERY! (on a loosely typed language that's a big help).

Instead of having to basically memorize or manually lookup class names, method names, and method arguments, I just begin typing the class name, use some arrow keys, and be done w/ it.

Anybody using an IDE w/out these features is fine by me, but for good measure they really should bill a customer less than those of us do that are using these tools.

You're deliberately handicapping your productivity. The customer shouldn't pay for that.

Re:Is this really news?

[kylehase]

While I agree with your point let's not forget that it can be all things to all people. M0n0wall (and forks like PFsense and FreeNAS) uses PHP for shell scripting like startup and configuration scripts which I thought was pretty cool.

Re:Is this really news?

[RazzleDazzle]

Something like *Tidy is all you need if you don't feel like using some fancy text editor or are too lazy to configure your editor.

http://perltidy.sourceforge.net/
http://rubyforge.org/projects/tidy
http://tidy.sourceforge.net/
etc

Re:Is this really news?

[shutdown -p now]

Can you be more specific about how PHP "has a focus" on Web scripting? Everything you've listed is available in other scripting languages, and they also offer a lot more. It is also not at all clear why e.g. loose typing is a feature relevant to Web development in particular.

Re:Is this really news?

[encoderer]

First, the PHP code doesn't really make sense. Why are you passing in the $args parameter?

All this code is doing is accepting a method name, validating it as valid (yes, an Enum dt would help here), and returning it if it is.

In which case, this is much better:

if (is_callable($method)) {
    return method;
}

Or, more on point, you'd never even call the __call() method, you'd just call is_callable().

I think the point is to show a plausible example of PHP being "hard work like C."

I'm not a PHP apologist. It's got a lot of problems. Chief among them a glaring inconsistency that just makes an elegence-loving guy like myself cry my eyes out. But to say that it's "hard work like C" just because it retained a syntax and offers up some thin wrappers around C functions is, I believe, disingenuous.

Re:Is this really news?

[mini me]

It's from Glib. But it's not like writing your own string library is any monumental task.

typedef struct string
{
  char *data;
  int length;
}
 
string * string_new(const char *str)
{
// Initialize string
}
 
string * string_append(string *s, const char *str)
{
// Append string
}
 
void string_free(string *s)
{
// Free string
}

There's no denying that PHP has easier string handling. But it's a scripting language, it makes no sense to resemble C in any respect.

Re:Is this really news?

[moderatorrater]

Can you be more specific about how PHP "has a focus" on Web scripting PHP was made originally to program web pages and, while it's been expanded to other uses, its main focus is still web pages. $_GET, $_POST, $_SESSION, $_COOKIE, and $_REQUEST are (as far as I know) unique to PHP in being built into the core of the language. As frustrating as it sometimes is, PHP files are considered standard output unless they have tags enclosing them, whereas in perl everything is considered code unless stated otherwise.

Loose typing and non-strict syntax in general is particularly well suited to the internet because each request generates a completely new environment. Something that was wrong with the previous request, unless specifically stored, doesn't affect the next request. Strictness in programming stems from the need to keep far flung parts from affecting each other; the web is modular by nature and thus resistant to wide spread bugs. Thus, loose typing and other, less strict forms of programming that make life easier at the expense of fragility is counterbalanced by the modular nature.

Many won't agree with that analysis, and that's fine. Sloppy coding has gotten more than one web project in trouble, and more than one feature of PHP's that was intended to make life easier ended up going to far and introducing security holes. But that doesn't change the simple fact that PHP was made for the web and has conveniences built into the core that other languages either don't have or require an add on for.

Re:Is this really news?

[VValdo]

Back when I was a youngin' we used ASCII and LIKED IT!

I see your ASCII and raise you an EBCDIC.

W

Would you believe... MouseText? PETSCII?

Re:Is this really news?

[badran]

I think you would like to see netbeans:

http://php.netbeans.org/

Re:Is this really news?

[SanityInAnarchy]

Personally, I like things like integrated FTP, integrated subversion, integrated unit testing, and, most of all, an integrated server-side debugger w/ all expected function: breakpoint/play/step control, stack and heap manipulation, etc.

The debugger is the only thing I miss from a "real" IDE.

Subversion is garbage, of the "at least it's not CVS" variety. There are at least some ten or twenty distributed version control systems out there, at least one of which has got to work well for you.

FTP is garbage. Use anything else. Yes, anything else.

These are actually related. I don't really like most of the stuff you mentioned "integrated", as that usually means things like "I have a keyboard shortcut to run unit tests!" Great, but I'm comfortable on the commandline. Let me switch between my editor and terminal easily, and I'll run unit tests, run a development server, and anything else I feel like.

The other reason is that I can then switch to pretty much anything else without having to switch IDEs. I know just about everything is supported on Eclipse, but "just about" isn't everything. I don't have to choose between Git and Subversion -- I can use bzr, hg, darcs, or really whatever the fsck I want. I don't have to use FTP because it's got the prettiest interface -- I'm just as comfortable with scp -- or, when it makes sense, Capistrano -- I can even use things like KDE's fish GUI for ssh.

All of these are possible using a text editor, but you need 5 different applications

Yes, that's the Unix Way.

and none of it works together.

Wrong, wrong, WRONG!

All of it works very well together. On the occasions where it doesn't, I can hack together the glue require reasonably quickly, and be back to being as productive as I was before -- but these cases are also times when an IDE wouldn't be able to work with them at all, and I know a lot more about hacking together scripts (shell and similar) than I do about writing Eclipse plugins.

Not to mention: INTELLISENSE

Useless, unless it's linked to documentation. And then, still useless, compared to flipping over to my browser and asking Google, since I probably don't actually know what I want there.

Not that I would be against having it, but I'm not willing to fire up Eclipse (and burn all my RAM, and still have it be sloppy and inaccurate due to being a dynamic language) just for Intellisense.

And then there's workspace management, and keeping plugins in sync, and dealing with when plugins go bad -- can't start Eclipse until I figure out which plugin is making it crash, or, more likely, wipe it and reinstall from scratch -- and it'll autodetect the file as the wrong type, so now I have to go fuck with its filetype associations, and set keyboard shortcuts -- whoops, the shortcuts I want aren't there...

There's a whole new level of bullshit I'd have to deal with if I was using an IDE. I know, I was for awhile.

and DATA TYPE DISCOVERY! (on a loosely typed language that's a big help).

If I understand this, it might be a help if I had functions so massive I can actually lose track of a variable, or if you're talking about the whole built-in debugger feature.

Instead of having to basically memorize or manually lookup class names, method names, and method arguments, I just begin typing the class name, use some arrow keys, and be done w/ it.

Except that by the time I'm doing that, I probably want to know more about it. For example: Is this indexed from zero, or one? How do I create a has_many relationship with an order clause? Does that have to be a string, or can it also be some other cool data structure?

Let me know if you find an IDE that can handle Intellisense in Ruby and actually make me more productive.

Oh, also, a fair amount of what you're doing probably should fit in your head. If you're not doing PHP and needing to know things like mysql_real_

Re:Is this really news?

[Wiseman1024]

Better Unicode support, which is a major, desirable feature, as others pointed out, and as far as I know, magic_quotes won't be deprecated in 5.3. Just deprecating magic_quotes, the last piece of shit to get rid of (the other two were register_globals and safe_mode) justifies a new major version giving PHP a refreshed image. They finally got rid of three of the worst features ever thought in a programming language other than COBOL, FORTRAN, BASIC, RPG and similar crap.

Now they need to get rid of the fatal error on function redefinition or function not found stupidity (that was REALLY retarded, probably the single worst feature after the three I mentioned), lexical scoping, syntax for lambda-expressions, first-class functions, better garbage collection, true object-orientation, a decent class system (i.e. one that's not modelled after Java's), operator overloading, associative arrays with support for non-string keys, decent iterators which don't require you to define 235789051 methods - just one (next) as a minimum, generators, coroutines, threads, a decent eval without the return insanity, and functional programming tools. Oh, wait, they need Python!

On top of that, I'd get rid of statements (make all of them expressions), add guaranteed tail-call elimination and get rid of the dollar sign.

Re:Is this really news?

[LS]

How exactly is this insightful?

How about rebutting his points? They are actually quite valid in contrast with the the sea of PHP haters.

PHP has it's problems but it's quite well suited for a certain set of tasks.

Re:Is this really news?

[Wiseman1024]

2/10

If you think PHP is like C for the web, you haven't understood it correctly, and you're not using it to its potential, or even close. (And don't even get me started on porting real C/C++ code to PHP.)

Perl's native syntax for regex is the least of my concern with Perl's insane syntax. Reindentation is something you do in every language, regardless of if it's Perl or PHP, and you never reindent lines one by one, but use a decent editor that will allow you to select multiple lines and indent. PHP is not a real OOP language, and it has a poor class system modelled after Java's.

Re:Is this really news?

[Wiseman1024]

One would thus wonder why the slashes are required, possibly messing up with variable regex.

Re:Is this really news?

[Wiseman1024]

10/10 10/10 10/10, listen to this man, he knows what he's talking about.

You're the kind of person I like to work with.

Re:Is this really news?

[hostyle]

They indicate where the regex starts and ends, since regexes can contain pretty much any character.

Re:Is this really news?

[hostyle]

There is no opening { so a closing } is also unnecessary. PHP doesn't require a closing ?> tag as this is assumed when the file ends. Not specifying a closing ?> helps prevent additional whitespace which can cause initialization problems eg. "headers already sent" warnings.

Re:Is this really news?

[The_reformant]

What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language. Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.)

You know php doesn't have pointers right?

Re:Is this really news?

[makomk]

The cleaner way to handle that is to have a second, separate parameter for flags. (For example, that's what Python does.)

Re:Is this really news?

[Wiseman1024]

Well, of course. But they're useless. There's no need to indicate that if they can just start at the beginning of the string and end at the end of the string, since options can be specified inside the regex, or in a separate parameter. That's what I meant when I said I wonder why they're required - more like that I wonder why they made it so.

Re:Is this really news?

[onida]

I really despise this kind of post, where each sentence is torn apart and commented on separately; usually with a sarcastic and snotty tone to it. In my opinion, it's just high brow trolling and makes the poster look like a right dick.

Re:Is this really news?

[Dogtanian]

it's not like writing your own string library is any monumental task. Your string library still looks somewhat clumsy, particularly for small projects. And I note that your functions only concatenate two strings; what if you want to stick a few together at once? (Yes, you could use var-args, but what's the checking like on that)

What if you want to append a number to a string? Given that standard C doesn't support overloading, would you have to write a new *differently-named* method? It'd be a nuisance to have to keep track of all the different methods when (e.g.) PHP can simply do the whole lot using the '+' operator.

it's a scripting language, it makes no sense to resemble C in any respect. Wrong; it makes perfect sense to use C-style syntax. That's almost certainly the most common syntax by far, used as it is in C++, Java, JavaScript, C# and many other languages.

Visual Basic's syntax is different, and I had to learn this all over again when I used it for the first time, because I'm used to C-influenced languages. The mental context switch required and my tendency to keep inadvertantly using C-style syntax (leading to syntax errors) is a PITA.

I wouldn't mind if the VB syntax was nice to begin with, but it's not. It's inelegant and clunky; probably not bad considering it was derived from BASIC, but still inelegant and clunky. It probably got that way because it mutated from BASICs MS-DOS/PC programmers were familiar with, carrying them along with it. However, if (like me) you're not already used to that flavour of BASIC and haven't even used BASIC for years, it's not easy to use at all. It's not even that much like the old BASICs I used to use. Though this is getting away from the main point...

There may be valid reasons for using a different syntax, but those should reflect underlying differences in the structure/approach of the language (even Perl syntax is somewhat C-flavoured in various respects). However, using a fundamentally different syntax just for the sake of it is a Bad Idea. PHP is easier to use because it has a C-derived syntax.

Re:Is this really news?

[hostyle]

Eh. You'd advocate replacing: if (/something/) { ... } with: if (something) { ... } ?

Similarly replacing: s/this/that/; with: sthisthat; Ok, that ones a bit obvious :)

Just to be clear, I'm referring to PCRE wrt perl, not PHP, so I guess this is off-topic.

Re:Is this really news?

[hostyle]

My bad. You were referring to PHP in particular, not PCRE in general. Sorry about that. Please ignore.

Re:Is this really news?

[Anonymous Coward]

I thought you were describing Javascript. Or perl. Isn't it funny how almost every modern scripting language has those features while PHP is a steaming turd?

Re:Is this really news?

[POWRSURG]

What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language. Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.)

PHP5 can actually handle exceptions, and has your normal public, private, etc. modifiers available for class properties. The var syntax is only necessary in PHP4 and has only been retained for compatibility reasons. I would be in support of removing var in PHP6 if the developers so chose.

Re:Is this really news?

[Just Some Guy]

Let me know if you find an IDE that can handle Intellisense in Ruby and actually make me more productive.

If Emacs's Ruby mode is anything like it's Python mode, then: Emacs.

1. Open a new file, /tmp/foo.py
2. Type import time
3. Type print ti then alt-/ to complete it to print time. OK, that's a weak example of symbol completion, but it'll serve for now.
4. Type a period to make that print time., then hit meta-tab. That brings up a list of completions of all the attributes of the time module. Type g and meta-tab again to complete it to time.gmtime.
5. Hit control-c control-f to get the "Describe symbol" prompt, which will default to whatever's under the cursor - time.gmtime in this case - and hit enter. Now you're reading the documentation for that function.

At some point, hit control-c control-c to run your program inside an embedded Python session. If it throws an error, hit control-x ` to go to the line in your program where the error occured.

OK, the keybindings probably aren't what you're used to (although they can be easily changed). Other than that, it supports every other feature you described.

Emacs isn't for everyone, but you owe it to yourself to at least try it.

Re:Is this really news?

[bondjamesbond]

From what I understand, this is typical of the Ruby elitist assholes. They are the shittiest of the shitty "communities". They make the OBSD guys look like Care Bears. Sure, they may know what they are talking about and might even be pretty smart and great with Ruby, but the dickishness is really uncalled for.

Re:Is this really news?

[Anonymous Coward]

PHP has it's problems but it's quite well suited for a certain set of tasks.

Magic apostrophes?

Re:Is this really news?

[Hognoxious]

I really despise this kind of post, where each sentence is torn apart and commented on separately;

That would be a lot easier if you actually wrote proper sentences.

usually with a sarcastic and snotty tone to it.

See what I mean?

In my opinion,

Which we all totally care about.

it's just high brow trolling

I find it quite amusing.

and makes the poster look like a right dick.

I know you are but what am I?

Re:Is this really news?

[Hognoxious]

Better Unicode support, which is a major, desirable feature, as others pointed out

One day, people will look back to the times before we could write Klingon and High Futharkian and wonder how the hell we managed.

Re:Is this really news?

[ukyoCE]

Give us a break. I don't know what your grudge is against PHP but statements like

"OO? Only recently."

betray your extreme bias. Php 5 has been out since 2004 with "all" OO features, while PHP4 (out since 2000) had "most" OO features. You really have no clue what you're talking about.

Re:Is this really news?

[DavidTC]

Slashes are not required. PHP regexps can be contained within any character. '~blah~' is a valid regexp. I regularly use something over than /, simply because / makes it hell to work with pathnames and URLs. With PHP, you can pick whatever character isn't in your regexp. How do Perl people handle that? Repeated escaping?

As for why it needs any container, it's because '~blah~i' is a legal regexp also. Yes, that *could* be another parameter, but then what do you do with functions that take arrays of regexps?

Re:Is this really news?

[DavidTC]

Then how do you handle something like preg_replace, which takes, optionally, an array of regexps, and you want some to be case insensitive, some to be greedy, etc?

Re:Is this really news?

[Anonymous Coward]

Well, I think he's talking about "OO" stuff like reflection, which is basically O"Oh shit, I did all this OO crap and polymorphism and all that jazz, and now I really wish I hadn't!"O.

Re:Is this really news?

[Wiseman1024]

Of course, again, not my point. My point (albeit poorly expressed) is that it shouldn't have been necessary to wrap your regexes in characters which then you can't use without backslashing, because it bites when you try to use dynamically generated regexes. It's an example of unbright design, since it only exists "cuz Perl had it" and to specify options which you could easily and far more cleanly provide in a separate parameter (also easier to introspect), and also had a way to set from within the regex. It's unwise to develop, maintain, document, teach and have to learn many different ways to do the same thing, especially if some of these ways only cause trouble.

As for what to do if a function needs an array of regex? Well, the natural answer would be to use the language's means for pairing or grouping elements, be it a LISP cons cell, a Python tuple, or a PHP array(). Failing that, there's the ability to change options from within regexes, too.

Re:Is this really news?

[Wiseman1024]

Or Lua, or Ruby, or perhaps Smalltalk. And most definitely Scheme, which is a LISP born in the freaking 70s, over 30 years ago, from which most of these new languages are borrowing their most impressive features. (Some of these came from even older LISPs, of course.)

Re:Is this really news?

[Anonymous Coward]

Magic apostrophes? I see you didn't read TFA. Magic Quotes are one of the things finally being removed, due to "having been a bad idea to begin with"

Re:Is this really news?

[nuzak]

> mainly because it isn't a kitchen sink like Perl....

Perl on the other hand doesn't litter the global namespace with hundreds of functions. Most of perl's builtins, furthermore, follow a consistent naming convention and argument order, neither of which is true in PHP.

Re:Is this really news?

[Monkeys with Guns]

I vi, therefore I am. Interesting. So you type, "if (0){esc", find the end of the block, and type, "i}esc" to end it. Wouldn't it be nearly equally complex but more readable to type, "esc : startline, endline s/^/\/\//" and comment the section? You can easily uncomment it again later by using s/\/\///.

Re:Is this really news?

[Monkeys with Guns]

I forgot to point out the problem with manually indenting. Use this to auto-indent a block:

:start,finish s/^/\t/

Re:Is this really news?

[chromatic]

How about rebutting his points?

His points had the barest, most tenuous connection with reality. The proper responses are either shunning or mockery. I did not choose shunning.

Re:Is this really news?

[Anonymous Coward]

I'll be happy when we can reliably use English, which includes words like "façade". I still get followups from recruiters who want to talk about my résumé. Isn't it the 21st century yet?

Re:Is this really news?

[shutdown -p now]

$_GET, $_POST, $_SESSION, $_COOKIE, and $_REQUEST are (as far as I know) unique to PHP in being built into the core of the language.

They may be unique in a sense of having some special language support, but what makes them any different then e.g. Request, Session etc properties of ASP.NET Page class? As far as developer is concerned, he accesses them in precisely the same way - Request["foo"] etc.

As frustrating as it sometimes is, PHP files are considered standard output unless they have tags enclosing them, whereas in perl everything is considered code unless stated otherwise.

Since PHP is really a language and a framework blended into one, it makes sense to compare it to other language/framework combos. All Web development tools these days offer some way to mix code and data, though templating engines have traditionally been more powerful in non-PHP land.

Loose typing and non-strict syntax in general is particularly well suited to the internet because each request generates a completely new environment. Something that was wrong with the previous request, unless specifically stored, doesn't affect the next request. Strictness in programming stems from the need to keep far flung parts from affecting each other; the web is modular by nature and thus resistant to wide spread bugs.

Sorry, but this is just bollocks, plain and simple. There is nothing about the nature of Web requests that somehow makes loose typing preferrable; and, guess what, if your ASP.NET page throws an exception while processing a request, it does not affect other requests either. "Strictness" in programming stems from the need to keep the code clean and understandable, and Web applications are not particularly different in that regard (if anything, it is easier and more straightforward to apply MVC to them due to the nature of Web requests), and not any more "modular" either - unless by that you mean something very different from what is commonly understood by the term.

Re:Is this really news?

[Chysn]

> With PHP, you can pick whatever character isn't in your regexp. How do Perl people handle that? Repeated escaping?

No, they handle it the same way that PHP people do; picking a character (or matching set) other than /

Re:Is this really news?

[Spudds]

Thats GLib not C.
In your example GLib is doing all the work for you, so it's not a apples-to-apples comparison.

Try actually writing real C code yourself and see if you like realloc.
THEN try php and tell me it's "too much work".

Re:Is this really news?

[Anonymous Coward]

OO? Only recently. For what values of recently? PHP4 supported basic, but workable OO in 2000. PHP5's improved OO was available in 2004.

But you know what? Perl has a little over two hundred functions in the main namespace. PHP has a little over three thousand And that's supposed to adversely affect my coding how? Maybe I'll have to think about it next time I want to write a function called 'strcmp' or 'md5', otherwise it hasn't been an issue. Not to mention TFA is about new features of PHP6 / 5.3, including namespaces. Maybe you can offer some proof that putting these functions in the core library adversely affects PHP's performance?

Oh, and does PHP support structs? 1) Is there any reason I should care?
2) A PHP4-style class is functionally a struct. A PHP5 class is a struct if you don't specifically set any members to private/protected. Assuming your struct doesn't have any private/protected members, which you can do in C++.

What about function pointers? Yup, they're called 'callbacks' in PHP. http://www.php.net/manual/en/language.pseudo-types.php#language.types.callback

How about you try a touch of research before publicly whinging about PHP's supposed faults?

Re:Is this really news?

[Anonymous Coward]

It's not checking that those methods exist, it's *defining* them dynamically.

Re:Is this really news?

[whimmel]

s = sprintf("%s%s%s%s%s",
      string1,
      string2,
      string3,
      string4,
      string5);

What's so hard about that? ;-)

Re:Is this really news?

[Haeleth]

I can't tell you how many times I've added an "if (0)" around a giant block of code temporarily to test something.

There's your mistake, then. Better by far to comment it out: not only does it mean you don't need to worry about indentation at all (even in Python), but you also get a much more visible indication that the code in question has been disabled.

Re:Is this really news?

[Haeleth]

I don't know what your grudge is against PHP but statements like

"OO? Only recently."

betray your extreme bias. Php 5 has been out since 2004 with "all" OO features

Um, except that 2004 is "only recently", by comparison with other scripting languages like Ruby and Python that have supported OO since the 1990s.

Re:Is this really news?

[Haeleth]

Now they need ... lexical scoping ... Oh, wait, they need Python!

Maybe they should wait until Python gets proper lexical scoping, then. :P

Re:Is this really news?

[Hognoxious]

Neither of those words is English, and if you spoke English properly you'd call the second one a curriculum vitae. Er, wait...

Re:Is this really news?

[tholomyes]

Subversion is garbage, of the "at least it's not CVS" variety. There are at least some ten or twenty distributed version control systems out there, at least one of which has got to work well for you. If you're working on a project with a lot of other people, having your merge diffs available right in your editor is pretty handy.

"I have a keyboard shortcut to run unit tests!" Great, but I'm comfortable on the commandline. Let me switch between my editor and terminal easily, and I'll run unit tests, run a development server, and anything else I feel like. Working with a tool like EMMA integrated with IDEA, you can actually see on a line-by-line basis what lines of code are actually being tested by your unit tests, and see a breakdown in your file listing of what your test coverage is. Pretty useful, if you ask me.

Re:Is this really news?

[dgatwood]

Yup. That's the first thing I make darn sure is disabled when I set up a server.... And I've even been known to write code that explicitly tests for this being in use and refuses to run if it is just to avoid the bizarre user experience problems that invariably occur if you quote something that is already quoted.

Re:Is this really news?

[dgatwood]

When you compile that code or when you run it?

Compile:
Incorrect pointer type in function call (argument 1).
Argument 1 discards qualifier (const) from pointer type.
Assignment makes pointer from integer without a cast.

This is from memory, so wording of error messages may be inexact.

Run:
Segmentation fault. Core dumped.

sprintf in C requires a variable of sufficient length to hold the printed content, e.g.

char str[2048];
sprintf(str, "%s%s%s...", ...);

Perhaps you meant asprintf? Even still, your usage is wrong. It's:

char *str;
saprintf(&str, "%s%s%s...", ...);

Re:Is this really news?

[Wiseman1024]

Python has proper lexical scoping, only you don't understand it. In Python, = is used to rebind variables. It's not Scheme's set!. If you use it, you obviously create local variables. And it works that way because = is also used to define a new variable. There's no Scheme's define, or JavaScript's var.

However, lexical scoping works as expected and defined in holy book SICP section 3.2, "The Environment Model of Evaluation". You can access variables defined in any lexically enclosing scopes anytime, and they can be shadowed. As in Scheme, these variables are bound to objects which can be modified, so you could, for example, mutate a list from an enclosing scope.

Whenever I need to reassign values to outer scopes, I box them with a list, creating them with box = [value] and setting them with box[0] = new_value, exactly like box and set-box! in Scheme. And if I need multiple values, a class to contain your arbitrary properties is an elegant solution.

Python 3000 will introduce the nonlocal declaration so that = works as a rebinder in the corresponding outer scope, much like Scheme's set!, and it'll come in handy, but you don't really need it to work.

Re:Is this really news?

[whimmel]

Funny that you're being pedantic about declaring the destination variable but not my assumptions about the source string1..5 variables.

and yeah, I used the PHP syntax for sprintf ironically. Sorry.

Still, it's not so hard to do "lots of concatenation" in C

btw, you mistyped asprintf in your 2nd example. you're welcome.

Re:Is this really news?

[SanityInAnarchy]

If you're working on a project with a lot of other people, having your merge diffs available right in your editor is pretty handy. Fair enough -- but better than "SVN integration" would be "use ANYTHING other than SVN" so that your merges make sense.

you can actually see on a line-by-line basis what lines of code are actually being tested by your unit tests I wonder if there's similar integration for things like Heckle, a tool for Ruby unit tests which munges the code being tested in various ways -- the theory being that if it still passes the unit tests after that, you're not testing everything.

An IDE is not entirely useless. It's not impossible to make the perfect IDE. But for most projects, the IDE simply isn't worth the hassle that it brings.

Re:Is this really news?

[SanityInAnarchy]

Not going to work as well for Ruby, I think.

For one thing, there's just entirely too much in the way of syntax hacks. Take the "keyword arguments" which are actually hashes.

As far as I know, it's actually impossible for any editor to be able to complete this statement, without actually knowing how Rails works:

has_many :comments, :through => :stories, :order => 'id ASC'

Ok, sure, intellisense is nice if, for some strange reason, I forget what has_many is called.

But for the rest of it, you'd have to know that the second argument, :comments, is meant to be the plural of another model class. If that Comment class already existed, in theory, a Rails-specific IDE could tab-complete that to :comments. Maybe.

And then there's the rest of it, which is part of the options hash -- which means that it would have to know all the options which has_many can receive. But has_many is actually receiving a hash as an argument, and then doing something with it. As it happens, Rails has some fairly standard ways for a function to specify what it accepts as "keyword arguments", but again, you'd have to design that specifically for Rails.

Even given that, you'd have to know that :stories corresponds to the Story class, found in app/models/story.rb. Not impossible, but very Rails-specific.

The one feature you've described that might be useful is a shortcut for getting to the documentation -- because we really would need a lot of documentation here. But that's not worth learning Emacs for, when I already have a keystroke to take me to my browser, where the Rails documentation is, and search "methods" for "has_many" -- which is probably already up anyway.

Oh, one more thing, while I'm at it -- Ruby lets you override method_missing, which is called when you try to call a nonexistent method. Rails uses this to pretend to have a lot of convenience methods on its associations. I've used it in some programs of my own -- creating a wrapper around an object, for instance.

I'm not sure if having intellisense which sort of works, sometimes, is better than not having it at all.

Maybe one day, there will be better Ruby editing tools. In the meantime, I find that the tradeoff is worth it -- that extra time spent looking up documentation is more than made up for by how quickly I can actually get things done once I know those methods.

And finally, just a nit -- meta is often mapped to alt, right? Meaning that meta-tab means alt-tab, which usually means something quite different in most window managers.

Re:Is this really news?

[SanityInAnarchy]

The other thing to keep in mind is that the OO was tacked on, badly.

Contrast this with Perl OO, which was tacked on fairly well, and done in a Perl-ish way, so that if you already knew Perl, the OO would make sense to you.

Or with Python or Ruby -- Python was OO since the beginning, and Ruby is pervasively OO, in that absolutely everything can be coerced into some kind of an object, and you can call methods on it, or add some of your own.

Example: nil (null, really) is an object, and you can define your own methods on it. So are integers, and you can subclass Integer if you like. (The one drawback is that a lot of this expressive power can let you do evil, twisted things, that might make the interpreter crash badly, like attempting to define true as false and false as true.

My new favorite way of describing PHP is "training wheels without the bike."

Re:Is this really news?

[Just Some Guy]

The one feature you've described that might be useful is a shortcut for getting to the documentation -- because we really would need a lot of documentation here. But that's not worth learning Emacs for, when I already have a keystroke to take me to my browser, where the Rails documentation is, and search "methods" for "has_many" -- which is probably already up anyway.

Well, the one advantage there is that it opens it inside Emacs, so you can copy-and-paste code samples without moving your hands. To each his own; it just works well for me.

Anyway, here's a screencast showing someone using Emacs with Ruby. I don't know Ruby enough to know if this is cool or pointless, but you're probably in a better-position to judge it.

And finally, just a nit -- meta is often mapped to alt, right? Meaning that meta-tab means alt-tab, which usually means something quite different in most window managers.

That depends. I have it mapped to the Windows key on one keyboard, but escape-foo is exactly equal to metakey-foo in Emacs, so you can always get to those functions without hitting alt-tab. At any rate, you can remap any keybindings you want - that's just the default.

Re:Is this really news?

[SanityInAnarchy]

For what values of recently? PHP has existed since 1995. "Basic, but workable OO" was added five years later, so of course it was tacked on, compared to a language designed from the ground up for OO -- like, oh, Python or Ruby, both of which existed before PHP had its first OO.

And that's supposed to adversely affect my coding how? Good question. This was in response to a criticism of Perl having more syntax than PHP...

Maybe I'll have to think about it next time I want to write a function called 'strcmp' or 'md5' Or maybe 'mail'?

Remember, three thousand reserved words. If you never hit them, you're lucky -- I'd rather not take my chances. I'd rather go with a language that has good, solid namespace support, baked into the standard library, from the beginning, so I never need to keep more than maybe twenty words in my head at a time.

Not to mention TFA is about new features of PHP6 / 5.3, including namespaces. Yay! After 13 fucking years, you finally get namespaces!

Do any of PHP's competitors lack namespaces? Have they ever? Even Javascript has namespaces, or at least the constructs needed to build them. And PHP is finally getting them in 2008.

Who wants to bet how much of the core library is still going to be crapped over the global namespace?

Maybe you can offer some proof that putting these functions in the core library adversely affects PHP's performance? It increases RAM usage, and is necessarily going to take more time to compile -- compile your program, that is -- at the very least. That's a given -- suggesting otherwise is like saying "Maybe you can offer some proof that putting a call to factorial(5000) in the middle of our view adversely affects our app's performance?"

Now, maybe if you said "significantly adversely affects performance"...

Oh, and does PHP support structs? 1) Is there any reason I should care? This was in response to someone claiming a strength of PHP as being that you can copy/paste C code and only tweak it a little bit. If you don't support structs, that makes it a bit difficult.

What about function pointers? Yup, they're called 'callbacks' in PHP. Ok... So you can create a function, given a name, and then pass that name around. And you pretend that's a function pointer? What?

So... That's going to add a lot of complexity for things like this:

some_array = ['one', 'two', 'three']
some_array.each do |item|
  puts (item + 's')
end

Admittedly, you can do this with a for loop -- provided you know it's actually an array you're dealing with. Iterators like 'each' are a lot more flexible.

It's also going to make some things actually impossible. How would you do this:

def generate_add(first)
  Proc.new do |second|
    first + second
  end
end
 
add_two = generate_add(2)
 
add_two.call(2) # 4
add_two.call(5) # 7
 
generate_add(5).call(5) # 10

I admit that, as written, these are contrived examples. That's because they're examples. This kind of stuff is useful in practice, and even JavaScript supports it.

But... you know what, never mind. Lack of support for closure scope means you could never do something like the above anyway.

Re:Is this really news?

[Ant P.]

Oh, and does PHP support structs? What about function pointers? It can't really do structs (unless you count nested arrayhashobjslop as structured data), but you can do soft references of functions with $string(). Or you can assign an actual function to a variable with create_function() and call it the same way, but it's best to avoid going down that path if you want to keep what's left of your sanity.

Re:Is this really news?

[dgatwood]

btw, you mistyped asprintf in your 2nd example. you're welcome.

D'oh! I got asprintf and snprintf mixed in a bad way.... :-)

Re:Is this really news?

[MisterBlueSky]

Thanks for the link. Bookmarked.

Re:Is this really news?

[encoderer]

That's not what the PHP code does, though... so he's not comparing apples == apples.

Perhaps he's a better Ruby developer than PHP developer.

That's understandable, but it means that maybe he isn't qualified to issue judgment on PHP.

Re:Is this really news?

[SanityInAnarchy]

Fair enough, but take away Zed Shaw and we make the OBSD guys look like Teletubbies. Take away DHH and we're actually a downright loving community.

Re:Is this really news?

[SanityInAnarchy]

A dick who got modded +5 insightful.

If you actually have a counterpoint, go ahead. If you think I took something out of context, show me where.

I really despise this kind of post, where no comment is actually made about the substance of a post, only about the way in which it was presented.

As a regular PHP user, I've gotta say...

[Ethan Allison]

This looks pretty awesome.

Re:As a regular PHP user, I've gotta say...

[Anonymous Coward]

you are setting off my gaydar, son

PHP 6

[Anonymous Coward]

Poop in my Hand, Please, 6 times the usual amount. Thanks!

Content free summary

[mrbluze]

Crikey, I can't believe I have to RTFA to come up with something funny to say about this short-ass summary!

Re:Content free summary

[ed.mps]

you only need to read the 1st paragrahp:

PHP is already popular, used in millions of domains (according to Netcraft)

Re:Content free summary

[truthsearch]

On /. Netcraft can only be used to confirm that things are dead, not alive.

Magic Quotes Removed

[iamhigh]

Citing portability, performance, and inconvenience, the PHP documentation discourages the use of magic_quotes. It's so discouraged that it's being removed from PHP V6 altogether, ... ... If you're using magic_quotes to escape strings for database calls, use your database implementation's parameterized queries, if they're supported. If not, use your database implementation's escape function, such as mysql_escape_string for MySQL or pg_escape_string for PostgreSQL. This was discussed just a few days ago in the some what wrongly titled 500 Thousand MS Web Servers Hacked

Re:Magic Quotes Removed

[robo_mojo]

So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack? Wow, I'd consider that to be a major regression, then.

Re:Magic Quotes Removed

[jacksonj04]

And even more irritatingly, mysql_escape_string() has been deprecated as well. You should use mysql_real_escape_string().

Re:Magic Quotes Removed

[dabooda]

You obviously wouldn't upgrade until you've stopped using magic quotes.

Re:Magic Quotes Removed

[Anonymous Coward]

Pleeeeeease tell me you do not actually do any programming. If you do, please stop. People like you who know absolutely nothing about development are what makes our industry so horrible. I have a coworker like you, and it's frustrating beyond any possible belief.

Anybody who thinks that magic quotes is the correct and/or only way to prevent sql injection should not be capable of making money in this industry. Seriously. Fuck I need to find a job in another industry not full of incompetent fools.

Re:Magic Quotes Removed

[The MAZZTer]

I hope they have some sort of protection against that; specifically, if you have magic_quotes turned on in php.ini (or whatever the linux equivilant is) PHP should refuse to start, perhaps logging an error message which explicitly tells the webmaster magic_quotes is no longer supported, and that it must be turned off, and the possible consequences of using old scripts designed to work with magic_quotes on. This forces the webmaster to actually go into the config file and turn magic_quotes off, and if they didn't fix their scripts or tell their clients to do so it's their own fault. And of course if they have badly configured security, this could mean even bigger consequences, but this is possible even with magic_quotes, depending on the scripts and holes in them. A separate message for safe_mode (also scrapped for 6) would also put the consequences of not properly setting up user permissions and the permissions of the account running the web server in big bold letters.

If they do something like that, no-one can really say they weren't warned, since a webmaster would actually have to go in and turn it off, and would be told exactly what could happen if they don't take the proper steps.

A friend of mine is happy these two settings are being killed, as am I. It can be tough to code with the restrictions put in place by safe_mode and magic_quotes, which as I understand are just to cater to lazy irresponsible server admins and lazy irresponsible programmers, respectively. Although safe_mode does serve a legitimate purpose since currently all scripts, regardless of which user owns it, are run under the permissions of the webserver user. This strikes me as more fo a webserver problem than a PHP problem, though. Not sure how much the PHP team could do... except for maybe safe_mode.

To end my little rant, here's a helpful bit of code pulled from the pastebin source (GPL) to combat magic_quotes in _GET and _POST and _COOKIE:

// magic quotes are anything but magic - lose them!
//
if (get_magic_quotes_gpc())
{
function callback_stripslashes(&$val, $name)
{
if (get_magic_quotes_gpc())
$val=stripslashes($val);
}


if (count($_GET))
array_walk ($_GET, 'callback_stripslashes');
if (count($_POST))
array_walk ($_POST, 'callback_stripslashes');
if (count($_COOKIE))
array_walk ($_COOKIE, 'callback_stripslashes');
}

Re:Magic Quotes Removed

[Just Some Guy]

So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack?

Of course not! Since no one has been stupid enough to directly insert submitted strings into SQL before sending it to the server for at least 5 years now, this won't affect any modern code in the slightest.

Re:Magic Quotes Removed

[Quietust]

So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack?

It would probably be more accurate to say that you will become more vulnerable to SQL injection attacks, since magic_quotes was never 100% foolproof to begin with.

Re:Magic Quotes Removed

[encoderer]

Well, most users should be saved just by coincidence.

Using the example in the article:

<?php // Assuming magic_quotes is on...
$sql = "INSERT INTO USERS (USERNAME) VALUES $_GET['username']";
?>

If magic quotes is, indeed, on, the database will see a query that looks like this: /* Let $_GET['username'] = testUser */

INSERT INTO USERS (USERNAME) VALUES 'testUser' ...now...

if magic quotes is turned off, sure, an injection attack is possible, as the query will become:

INSERT INTO USERS (USERNAME) VALUES testUser

And as long as a dev tests their code after upgrading to v6.0 they'd notice that the DBMS has thrown a 'testUser is not a column/udf/sproc' error.

Re:Magic Quotes Removed

[larry bagina]

you should use PDO and prepared statements.

Re:Magic Quotes Removed

[shutdown -p now]

If you're still using magic quotes in 2008, you are likely to be vulnerable to some form of attack via your PHP code no matter what you do. It has been officially strongly discouraged (in the manual and elsewhere) for years now.

Re:Magic Quotes Removed

[TheLink]

But shouldn't you be using mysql_genuine_advantage_escape_string() instead ;).

It's stupid stuff like that and "Magic Quotes" that make PHP a sad joke.

Magic Quotes = mixing input layer filtering with output layer filtering = bad. You tend to get data corruption amongst other things.

Then there's addslashes and friends.

PHP: "Making The Wrong Ways Easy, and The Right Ways Hard".

Oh well, I guess php6 is where they are finally trying to do things right now.

All the pain is because php coders were doing things terribly wrong in the first place. Don't forget the PHP devs were encouraging them to do things wrong for years.

Re:Magic Quotes Removed

[Gavagai80]

The example is wrong. magic_quotes simply escapes quotes with backslashes, it doesn't add quotes around terms.

Re:Magic Quotes Removed

[robo_mojo]

Normally I do not bother to reply to trolling AC's but I will reply to you (congrats!). Yes I program, but I don't rely on magic quotes (I have used it against my will on one adopted project where another developer used it, though).

The problem is that someone unwittingly upgrades to PHP6 and suddenly becomes vulnerable to injections that they were not vulnerable to in PHP<=5. Software upgrades should not do this to users.

Another poster in this thread suggested that PHP could refuse to start if magic quotes are turned on in the config, and crazy messages could be printed at the user. That'd be the correct thing to do, I think. Then at least the user would know to stick with 5 until he can change his code.

Re:Magic Quotes Removed

[WWWWolf]

So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack?

"The Management would like to announce that we're switching to slot-loading CD-ROM drives next week. We will be reserving more burn ointments in the first aid room for the next week or so and the janitor has been instructed to stock extra tissues in the bathrooms, but people who have been using CD-ROM drives as coffee cup holders should seriously stop using them as coffee cup holders ASAP."

Magic quotes did the wrong fix that incidentally happened to work for some people. The problem was that people had been concatenating (unprocessed) parameters to SQL queries; the right solution would have been to process the quoting in the place where it's supposed to be processed (query parametrisation, right before the query actually goes to the DB, automagically using the method that works appropriately for the DBMS in question), but instead, the developers just said "well, we're letting you continue your dangerous way of coding, here's a band-aid fix".

I've viewed magic quotes as a feature for legacy code that seriously needs to be fixed: "people used to code completely freaking headlessly back in the day because we didn't have real security back then and this was the ONLY way to do things - this feature is a temporary security feature so that they have time to port their utterly reeking PHP3-era string concatenation crap to use DB-specific quote calls or, far better yet, PDO and prepared statements." Using prepared statements makes the code look more manageable and more in line with the stuff you see in other programming languages, which have used prepared statements for a long time now - porting old code over is more than entirely justifiable.

Re:Magic Quotes Removed

[random0xff]

Oh well, I guess php6 is where they are finally trying to do things right now. At which point it will be kind of like Java 1.2 Apart from the amazing amount of PHP code(rs) out there, it seems that PHP is destined to be old skool. With all the buzz around Ruby, Python 3, JavaScript, C# 3, how is PHP going to be a good choice for new projects in the future? Waiting for years to get namespace support while a C# coder now has generics, lambdas, a query dsl and a proper base class library. How is that cool, why be a PHP programmer? So you can have generics by 2012?

Re:Magic Quotes Removed

[makomk]

According to TFA, they're removing the get_magic_quotes_gpc function in PHP 6 as well. This is of course fairly idiotic, since it's going to break a lot of existing code without any good reason. (It should just return 0 in PHP 6.)

Re:Magic Quotes Removed

[Anonymous Coward]

Hey, I resemble that statement. Don't worry tho' I've recently taken up Python programming, so I'm working day and night to make as much un-Pythonic, unmaintainable crud imaginable. I love this job!

Re:Magic Quotes Removed

[DiLLeMaN]

Apart from that, if you shove $_GET into SQL queries without checking them, you're a complete retard.

Re:Magic Quotes Removed

[Anonymous Brave Guy]

Since no one has been stupid enough to directly insert submitted strings into SQL before sending it to the server for at least 5 years now

Don't mock: some of us still have to maintain systems running on PHP4, using things like the old-style MySQL interface, where in-line SQL is basically the only way to do things.

When our systems are upgraded to PHP5 — which is out of my hands — I'd love to rewrite the relevant parts of the system to banish in-line SQL and use a proper ORM, but this requires someone else to make the upgrade and someone to write a production-quality ORM for PHP. So far, Doctrine is the best I've found, but everything I've looked at has significant shortcomings, usually including an unhealthy obsessions with rewriting most of SQL in a not-quite-similar way to provide not-quite-full support for object persistence. You'= would think we would have learned from the whole proprietary standard, vendor lock-in debate and we ought to have a standard object-based query language by now, but alas, we aren't there yet. Until then, for some purposes, it's still easiest just to use prepared SQL statements, which are better than in-line SQL, it's true, but only one step removed in terms of power and vulnerability.

Re:Magic Quotes Removed

[SatanicPuppy]

It's easier just to turn off the function using an .htaccess override parameter. I've been doing that for years, though, admittedly, I've also had at least enough admin control over my deployment servers to make that possible, so that may not be an option for everyone.

Re:Magic Quotes Removed

[Just Some Guy]

This is of course fairly idiotic, since it's going to break a lot of existing code without any good reason.

Since pretty much every piece of PHP I've ever seen has something like include('localstuff.php'); at the top, just define your own get_magic_quotes_gpc_wtf_bbq function there, and preferably make it log the filename and line number of each page that calls it so you can delete all of that junk.

Re:Magic Quotes Removed

[ukyoCE]

You're exaggerating more than a little bit. Magic quotes and register globals (the "worst" offenders) have always been optional, and since PHP 5 (2004) have been disabled by default. In PHP 6 they're completely unavailable.

Everyone agrees these were bad ideas, but they can't remove the features from the language overnight without massively breaking many applications. The PHP devs have been doing the "right thing", at the very least since 2004.

Re:Magic Quotes Removed

[DavidTC]

The problem here, and this is an actual problem with PHP as opposed to the imaginary problems that haters have with it, is that there have been a lot of really stupid 'features' in PHP. Many of them making things less secure, like register globals, but, perhaps just as damaging, many of them making things 'more secure', like magic quotes and safe mode...but only if you were a complete idiot that didn't know how to code.

As a result, there's a lot of PHP code out there with really stupid security issues that no one's noticed because the language made them unexploitatable. The problem is that the idiotic little 'security hacks' caused all sorts of other problems and were pretty stupid. (Escaping all incoming data so you can use it in SQL queries is about the dumbest possible choice ever.)

At this point, everyone's realized how stupid those decisions are, but undoing those decisions all at once would break quite a lot of code, and it's taking time to depreciate them all out of the language. Meanwhile, it's made the 'platform' rather inconsistent, cause you don't know how it's been set up unless you test for it.

There are still a lot of very stupid features that haven't been deprecated out yet, either, like zlib.output_compression, but I'm assuming they're getting all the security stuff first.

Re:Magic Quotes Removed

[LDoggg_]

So maybe now is time for PHP to change the syntax for things like concatenation and "->" for accessing object members.

It would be safer to break backwards compatibility. Try to keep the old code from running until it's ported to PHP6.

Re:Magic Quotes Removed

[615]

Actually, undoing magic_quotes is quite a bit more involved. Some things to consider:

• - magic_quotes affects more than just GET, POST and cookie data
• - GPC data may contain arrays
• - magic_quotes doesn't process the keys of top-level arrays

Here's an excerpt from my personal library that addresses these issues and more. It works in PHP 4+ (I forget which minor version). Just give me some credit if you use it!

// magic_quotes_runtime is _like_ magic_quotes_gpc/sybase, except that it
// applies to return data (from functions)
ini_set('magic_quotes_runtime', '0');

// magic_quotes_gpc/sybase cannot be preempted like magic_quotes_runtime; if
// either is enabled, the damage is already done
if (ini_get('magic_quotes_gpc') === '1' || ini_get('magic_quotes_sybase') === '1') {
/**
* @author Adam Siler <amsiler@icglp.com>
* @param mixed $value
* @param bool $top
* @return mixed
*/
function undo_magic_quotes($value, $top = true) {
// unescape strings
if (is_string($value)) {
// stripslashes is magic_quotes_sybase-aware
return stripslashes($value);
}
// recurse into arrays
elseif (is_array($value)) {
// as described here: <http://us.php.net/manual/en/security.magicquotes.disabling.php#71817>,
// magic_quotes_gpc (sybase?) does not escape the keys of top-level
// arrays

$unescaped_array = array();

foreach ($value as $key => $array_value) {
if (!$top) {
$key = stripslashes($key);
}

$unescaped_array[$key] = undo_magic_quotes($array_value, false);
}

return $unescaped_array;
}
// return other values unaltered
else {
return $value;
}
}

$_GET = undo_magic_quotes($_GET);
$_POST = undo_magic_quotes($_POST);
$_COOKIE = undo_magic_quotes($_COOKIE);
$_REQUEST = undo_magic_quotes($_REQUEST);
$_ENV = undo_magic_quotes($_ENV);
// etc.

// other scripts may check the value of magic_quotes_gpc or
// magic_quotes_sybase and conclude, incorrectly, that GPC data is escaped.
// this should fix that
ini_set('magic_quotes_gpc', '0');
ini_set('magic_quotes_sybase', '0');
}

Re:Magic Quotes Removed

[Kingrames]

oh, oh crap. When you posted that, my whole web page got ruined. thanks a bunch.

Re:Magic Quotes Removed

[Anonymous Coward]

That's not actually what magic_quotes does: "When on, all ' (single-quote), " (double quote), \ (backslash) and NULL characters are escaped with a backslash automatically." (magic_quotes). The IBM example is bad; even with magic_quotes on, that query would fail.

PHP provides some protection against SQL injection by disallowing multiple statements in a single mysql_query call. However, here's a fairly realistic exploit example:

INSERT INTO USERS (username, admin) VALUES ("$_POST['username']", 0)

With magic_quotes on, this would be secure. If magic quotes are off, however, an attacker can enter the username haxx0r", 1)-- to be registered as an admin.

Magic Quotes

[Anonymous Coward]

No more magic quotes makes AC a very happy coder.

Major version?

[tomtomtom777]

I don't see why this is a major update (5 => 6).

Soap & XML was already implemented which leaves namespaces and unicode support as new features, and a bunch of stuff removed

Re:Major version?

[eebra82]

I don't see why this is a major update (5 => 6). If I had a software development business, I would do this if I wanted to push a release a little extra. People don't care as much about decimals as much as they care about entirely new release numbers.

Re:Major version?

[Dragonslicer]

I don't see why this is a major update (5 => 6). I believe it's because the Unicode support involved a significant amount of work in the engine. I vaguely remember that this means extensions will need to be modified to work correctly, but I'm not certain about that.

Re:Major version?

[Anonymous Coward]

Adding Unicode support to a language is a big deal, it's basically a win but it also typically introduces some backward incompatibilities with existing code, and lots of head-scratching about how things are supposed to work. When do strings get converted to/from Unicode, and from what character set? Be prepared to spend some time looking at output from od, or similar, when the data has characters that are outside of 7 bit ASCII.

Re:Major version?

[Splab]

"and a bunch of stuff removed"

The stuff addressed are some of the widest security holes. On top of that the old way of programming PHP and most guides out there encouraged the usage of these bad functions, getting them totally removed is a huge step forward.

Re:Major version?

[Anonymous Coward]

Adding Unicode support to a language is a big deal, yay and it only took a few years longer to get there than other web programming languages.

Re:Major version?

[WK2]

They are removing some things. According to Splab, above, removing these things is a huge step forward. More importantly, removing things should always be a major release. They are breaking backwards compatibility with everything that uses the things that they are removing.

Re:Major version?

[Anonymous Coward]

You'd fit in great with Sun's marketing division.

Re:Major version?

[Anonymous Coward]

More importantly, removing things should always be a major release. Remember, this is PHP. I still remember the headache of the 4.* 'minor releases'.

Re:Major version?

[SanityInAnarchy]

Depends.

Linux 2.4 -> 2.6.

Better example: Anything after OS X. We're up to 10.5 now, but everyone's drooling over it. Why? No numbers at all -- it's just "Leopard."

If they called it "PHP 5.5 -- the version that doesn't suck" or "PHP 5.5 (Quail)" or... put any kind of marketing spin on it at all... it might have as much or more impact than simply calling it 6.0.

Re:Major version?

[SanityInAnarchy]

I don't know, I think Ruby is even worse -- given that it was invented by a Japanese guy, so you'd think it'd be the first to have Unicode out of the box.

Re:Major version?

[adamchou]

actually, the summary says "to a few features that are being removed"

clearly register global and magic quotes are "features"

Re:Major version?

[Anonymous Coward]

Racist.

Re:Major version?

[SanityInAnarchy]

In the unlikely event you're not joking, I was referring to the fact that I'd expect someone using a Japanese character set to appreciate Unicode even more.

Re:Major version?

[Splab]

and you are telling me this because what?

A feature can easily be a security issue in the hands of the wrong person. Getting rid of these features removes some of the most common attack vectors on PHP sites.

Re:Major version?

[eebra82]

Linux and OSX releases are hyped regardless of the version number because every piece of such release is a major one. And since a lot of OSX users follow these releases, and since Linux techies do the same, it's no wonder that they don't need it.

PHP is obviously a strong product but sure as hell not of the same importance as Linux and OSX.

Re:Major version?

[Haeleth]

There was actually a lot of resistance to Unicode in Japan: there were some unfortunate misunderstandings early on that led a lot of Japanese people to believe that Unicode was trying to force them to use Chinese conventions for character shapes. It also doesn't help that all the various UTFs appear to be less efficient at encoding Japanese than their various legacy encoding systems. (Of course, neither of these things is really an issue in practice, but we're talking about popular perception here!)

I don't know if Matz was among those who held those incorrect beliefs, but even if he wasn't, there still won't have been any compelling reason for him to adopt Unicode. Multilingual character sets are only a big win if you're mixing multiple languages. If Matz didn't originally expect Ruby to take off in a big way internationally, then for the sorts of uses he probably envisaged, just Japanese and English would be fine, and you can handle that combination perfectly well using any of the legacy Japanese systems.

Re:Major version?

[SanityInAnarchy]

Remember, OSX is for the "It Just Works(TM)" crowd.

I realize there is a group of users who will absolutely hang on everything Steve Jobs does. But I'd assumed there were that many, or more, who have absolutely no clue -- who will actually believe them when they do things like brag about the G5's "Intel-crushing performance", right before they announce the switch to Intel -- assuming they even know what Intel is.

There are certainly people out there -- exactly the kind of people who need Time Machine, and need it to be shiny and 3D just to get them to do their backups -- and these people need to be sold on 10.5. I mean Leopard, which has Time Machine, and Spaces, and... You see?

The reason Apple doesn't need version numbers is that they're geniuses of marketing -- they have other reasons to upgrade than a new number.

Quick summary

[Anonymous Coward]

... for those too lazy to RTFA:
Additions:
Better Unicode support
Namespaces! (this is being backported to PHP 5.3)
SOAP and the XML Writer/Reader modules compiled in and enabled by default (also in PHP 5.3)
Removals:
magic_quotes, register_globals, register_long_arrays, safe_mode
ASP-style short tags ()
Freetype1/GD1 support
ereg (use of preg encouraged instead).

Re:Quick summary

[kestasjk]

Too bad the backwards-compatibility is going to make migration very slow.. PHP5 is very backwards compatible with PHP4, and the move to PHP5 is still going on, PHP6 will take a long time.

Re:Quick summary

[encoderer]

I'd opine that it's only VERY backwards compatible if the PHP4 that you're upgrading isn't primarily OO.

I mean, to get it to compile all you need is run the code thru a simple pre-processor to turn (basically) this:

class stdClass {
  var someVar;

  function stdClass() { ... }

  function someFunc() { ... }

  function _privateFunc() { ... }

  function m_otherPrivateFunc() { ... }
}

Into this:

class stdClass {
  public someVar;

  function __constructor() { ... }

  public function someFunc() { ... }

  private function _privateFunc() { ... }

  private function m_otherPrivateFunc() { ... }
}

And even of that the change to the constructor isn't necessary.

Basically just add access modifiers.

HOWEVER.. that doesn't mean backwards compatibility.

If you're writing real OOD PHP applications, and not just using some "helper objects" (like for DB access, error handling, etc) then there's a good chance that you'll find at least one bug.

See, they added destructors, interfaces, and access modifiers. But there wasn't many CHANGES.

There was a big one though: In PHP4 objects are COPIED when passed unless otherwise specified.

In PHP5 objects are REFERENCED when passed unless otherwise specified.

So imagine code like this:

function processObject($obj) { // Process the object in some fashion and returned a slightly modified object.
}

$obj = new someClass();
$objCopy = processObject($obj);

In PHP4, a copy is made when passing to processObject.

Any modification to the object inside processobject happens on the copy. $obj remains untouched.

However, after upgrading, that's changed now to implicitly pass by reference.

This can make some subtle bugs.

Usually pass-by-value is a mistake and a waste of resources.

But it's easy for devs (especially not those familiar w/ OOD in another language) to write code that relies on implicit byval without realizing it.

That code will all still compile. They'll just be some funny behavior reported that doesn't make sense and is eventually tracked down to an errant byval call that's now an implicit byref.

But you'll be so lovin' the interfaces and class variables and access modifiers that you'll forgive it.

Re:Quick summary

[kestasjk]

There was a big one though: In PHP4 objects are COPIED when passed unless otherwise specified.

In PHP5 objects are REFERENCED when passed unless otherwise specified. True that was a big change, but I don't think people are likely to get bugs by assuming CoW, because requiring CoW is pretty rare. (Most of the time the bugs are the other way around; assuming it's not CoW, because CoW is so counter-intuitive with objects and arrays)

In fact the only ZE1-ZE2 mistake I made was when I was developing PHP4 on ZE2 and assumed that CoW wasn't happening by mistake, then when I deployed it in a ZE1 environment it messed up.

Re:Quick summary

[encoderer]

True enough. In fact, I had a helluva time trying to come up with a good example.

I couldn't think of one, which I suppose is a good thing.

When a bug like this does occur, tho, it can be a bitch. When it happened to me I think I ran that code under the debugger a dozen times before I found the error. It's hard to notice small changes in a complex, nested data structure.

Re:Quick summary

[kestasjk]

Ah yeah they are a nightmare to track down when you're not sure what the problem is. It gets even hairier when you're compensating for it on PHP4 by using &$references, I must admit I couldn't get my head around it in the end, even the PHP-mods at freenode's ##php couldn't agree on what the referencing differences are w.r.t objects across ZE1/2

PHP and other interpreted languages suck! Use C!

[Anonymous Coward]

I make good money on RentACoder coding up web sites that use binary executables and CGI!

Long live C and character arrays!

Lose the M in LAMP?

[mrbluze]

Better XML support. That's a biggie. Might it mean we can, for a whole heap of projects, discard mysql? Would it make things run faster?

Re:Lose the M in LAMP?

[i.of.the.storm]

I would think swapping mysql for XML would make things run slower on the whole, especially large databases, but I'm not an expert in that field. XML and mysql really serve different purposes, and I don't think replacing mysql with XML would be a good idea for the vast majority of use cases.

Oh, and what happened to the spiffy discussion2 stuff? Now comments open in new pages again and I can't reply inline. What's up with that?

Re:Lose the M in LAMP?

[Anonymous Coward]

I personally use PDO with SQLite as a backend. Prepared statements are exceptionally useful. For my usage (a webcomic site schedule) it works great. YMMV of course.

Re:Lose the M in LAMP?

[mrbluze]

Oh, and what happened to the spiffy discussion2 stuff? Now comments open in new pages again and I can't reply inline. What's up with that? You have to enable XML on your browser ;) .. err.. Javascript and cookies I mean.

Re:Lose the M in LAMP?

[i.of.the.storm]

Hmm, everything should be enabled properly. Seems like discussion2 is randomly changing?

Re:Lose the M in LAMP?

[cheater512]

No.
XML is a format designed to transmit data between machines, not for data storage.

Imagine a 50 gigabyte database. I have one.
Now imagine the same database in XML.
The size would explode and you suddenly have to seek the entire db for a simple select.

Re:Lose the M in LAMP?

[truthsearch]

XML is also designed for small amounts of hierarchical data, e.g. OpenOffice documents.

Re:Lose the M in LAMP?

[maxume]

XML was designed to make it easier to work with structured data by making tools more reusable. In situations where it doesn't make sense, it's just as terrible a wire format as it is a data format.

Re:Lose the M in LAMP?

[LiquidCoooled]

I noticed this as well, the comment titles also used to collapse so i could cull the stuff I've read.
the first time i did it this evening it opened the comment thread from that location.

Re:Lose the M in LAMP?

[Foofoobar]

This actually is a very good observation believe it or not. Most MVC frameworks use XML to load the structure for the site and PHP's XML parser is extraordinariraly subpar so I created an MVC framework whose structure was loaded and cached from MySQL; as a result, it scales better, has a faster page load and blows Zend and others out of the water for speed as a result.

Its not the best approach for all intents and purposes (only 95% SEO compliant) but it has also enable a siwplistic approach for adding an all in one ajax approach and XUL compatibility really easily. Still I wish they would focus on improving XML parsing.

Re:Lose the M in LAMP?

[SanityInAnarchy]

XML is not a database. MySQL is not a format.

Suggesting that XML can replace MySQL is like suggesting that power steering can replace fossil fuels. Power steering may be good, and fossil fuels may be bad, but they're also completely orthogonal.

Now, if you were talking about an XML database, or a document-oriented database, your comment might make a bit more sense. But for a single machine, MySQL probably beats both of those -- it's only really going to be a benefit if you start scaling to large clusters.

Re:Lose the M in LAMP?

[Firehed]

True, but making an XML-based document sort of makes sense, especially given how XML and well-formed XHTML are basically identical and simple documents generally equate to a couple h1/h2 tags and a bunch of paragraphs with a very basic stylesheet. As such, storing it in a very accessible XML format makes quite a lot of sense.

On the other hand, look at the XML version of an iTunes Library. Every track has about 22 pairs of XML nodes ([key]Node Name[/key][string]Node Value[/string] type stuff for every piece of metadata, when they could have at least used [key name="Name"]Value[/key] or just [name]Value[/name]), which is creating a TON of file size bloat (a given for any format as verbose as XML, but the [integer]1[/integer] thing gets pretty damn redundant after 5000 tracks). It would make much more sense as a basic relational database in SQLite or something, especially given the nature of the application - I don't see why I have to set the number of tracks per disc on EVERY TRACK ON THE DISC when that obviously won't change from track to track in an album, etc.

Maybe when iTunes was first conceived using XML as a data storage medium made sense, but it seems terrible the way it's being used today. To be fair, it's the binary file that's actually getting used, but it's probably just a gzipped version with the extension changed. Back to Office documents and such, it does make a reasonable amount of sense as compared to a database, but XML is (in my experience) most frequently used to transfer data in a very accessible format, and it's absolutely ideal for that but not a whole lot else.

Re:Lose the M in LAMP?

[CaseyB]

You just failed programming. Please return your license and get in line for septic tank maintenance training.

Re:Lose the M in LAMP?

[Anonymous Brave Guy]

Please tell me that really was meant to be a clever troll! I assumed so, but a few of the responders seem to think you were being serious...

Re:Lose the M in LAMP?

[tholomyes]

Relatedly, there was a good article from Coding Horror yesterday about the proper uses for XML.

Re:Lose the M in LAMP?

[Ant P.]

Depends what you mean by "making things faster".

If you want the development to go faster, dump MySQL and use Postgres.
If you want the webserver to go faster, keep MySQL and use the mysqlnd php driver.
If you're paid by the hour, use XML.

register_globals

[Anonymous Coward]

Yay! Finally not just having register_globals defaulted to off, but removed altogether.

Backwards compatibility is very important

[unity100]

i am servicing around 350+ clients in a small fish web host. even at that small web host, there are a phletora of different scripts, programs that clients are using to conduct their everyday business, their estores, their livelihood. some of them are dependent and locked-in to the software they are using like a small business company that extensively uses ms products is locked into microsoft.

regardless, backwards compatibility is important for those people. for starters, these are the people who have chosen php as the platform to conduct their business on, making php a de facto dominant language for the web instead of being a small time web language that was used on web savvy, webmasters. the financial impact of this is going to be huge for them, to adopt to that many changes php dev group started to introduce in the span of 1 to 2 years. this is too much.

you gotta slow down. or you are going to alienate the small business community from using php with what you are doing. if you break a small estore owner's store script every 1.5 years for 'upgrading', the second time you do it they will jump the language ship.

do not start to become an elitist group out of touch with the people, increasingly caring for nifty programming issues rather than what would the users think.

Re:Backwards compatibility is very important

[Anonymous Coward]

And forward innovation is not important? Besides, you wouldn't upgrade all 350+ clients at once and in place? Perhaps having two host accounts, one for php5 apps and one for php6? Just a thought.

Re:Backwards compatibility is very important

[MROD]

Many commercial PHP-based systems are only now just changing over to PHP5 from PHP4. (Yes, I know...)

That's the way life is, I'm afraid. Most people who are depending upon these sites and software have no control over the vendors and definitely don't have the ability of fixing the code themselves.

Changing the API so greatly and so often in a non-backwardly compatible fashion does cause genuine problems.. and hosting sites can't afford to support multiple versions. Well, not unless they charge their customers too higher price for hosting their pages.

Re:Backwards compatibility is very important

[Anonymous Coward]

..and that's how it started with windows..and is one of the primary reasons it's so bloated and broken today. Hey, no one's forcing you to upgrade right away.

Re:Backwards compatibility is very important

[truthsearch]

Just like PHP 4 was supported for a very long time with security updates, so will PHP 5. Your clients won't be obligated to upgrade for many years.

One major issue with PHP is old cruft, such as magic quotes, that were terrible feature additions in the first place. These are so bad it's really in everyone's best interest to remove them. I think features like POSIX regex, however, should remain because they don't do any harm.

Re:Backwards compatibility is very important

[Anonymous Coward]

Then don't upgrade to the latest version until you are ready?

PHP maintains the 4 lineage of php at the moment, and I suspect the same will happen with the 5 lineage.

PHP should not keep backwards functionality where it is limiting the language, and PHP as it is now needs to lose some of the obscure and legacy code.

Re:Backwards compatibility is very important

[thetoadwarrior]

Who says you have to upgrade to version 6? If you are renting hosting then your host if shit if they don't offer multiple versions of PHP. For instance www.prohosting.com allows you to use either v4 or 5 and will likely offer at least v5 and 6 if not all 3.

Secondly and decent host probably already has registered_globals off and as far as $HTTP_GET_VARS and the like go, do you not have a decent program to find and replace text?

Re:Backwards compatibility is very important

[njcoder]

Sounds like you're using mod_php. That's a very insecure way to run php in a shared hosting environment and also doesn't give you the ability to run more than one version of php.

May not seem like a big deal until some idiot doesn't update his scripts and some script kiddie comes along and you get 350 calls from your clients asking you why there's some terrorist propaganda on their website.

Re:Backwards compatibility is very important

[MindStalker]

Realistically its not a huge change, just removal of some insecure features. If you must keep these features stay with PHP4, no big deal really.

Re:Backwards compatibility is very important

[dmsuperman]

The magic of a new version: You don't have to upgrade. My company is still using PHP 4 on a couple servers, and will continue to do so until the clients decide they want to go with a full site upgrade which requires a rewrite.

Re:Backwards compatibility is very important

[unity100]

read my post again.

Re:Backwards compatibility is very important

[unity100]

the catch is that, quite a many of the prominent scripts that are popular had been using some of those insecure features since some time ago, and there are a lot of people still using those old versions.

Re:Backwards compatibility is very important

[unity100]

your ears are weak.

also you should note that, the same customers would make much more stampede when they are asked to pay for development work for their running estores, because php team had decided to deprecate some features, for the second time in 1.5 years.

Re:Backwards compatibility is very important

[Anonymous Coward]

Many commercial PHP-based systems are only now just changing over to PHP5 from PHP4. (Yes, I know...)

Yes you know what? That's completely reasonable. If you have a system doing exactly what you want, going in to change things just to use a new version is downright stupid.

Re:Backwards compatibility is very important

[njcoder]

sucks to be them

Re:Backwards compatibility is very important

[njcoder]

By the way, you do realize that you don't have to upgrade your server right? You can leave the current version of PHP and everyone will be happy. There are tons of hosts still only offernig php4.

The part where I said there are ways to run different versions of php for different users didn't seem to register for you either.

Re:Backwards compatibility is very important

[Anonymous Coward]

Yes, but who in their right mind would blame php for breaking "many of the prominent scripts"? If widely used scripts are using idiotic constructs like magic quotes, I would herald the introduction of a new php version that will hopefully force these prominent scripts to be rewritten properly.

Re:Backwards compatibility is very important

[fimbulvetr]

Yes, actually very soon you will need to update your server. PHP4 is no longer being updated - this means security and all types of other bugs, including data loss/critical bugs. From now on, security updates will NOT be official and subject to people's whim. It's absolutely retarded that you suggest one can stick with PHP4 and be happy. The happiness will only last until there's no fix for their dataloss bug or their system has been hacked.

Re:Backwards compatibility is very important

[fyoder]

Where I work we have a couple of shared hosting servers which run two apaches, one for php4 and one for php5. It's a bit of a pita, but it works, and for us is easier than forcing clients at gunpoint to upgrade their php4 applications.

Unless there is a really compelling reason to add a third apache/php, I don't think we'll be quick to adopt this version. The better OO support in php5 made it something we wanted just for the stuff we write, but there doesn't seem to be much in php6 that is that exciting.

Re:Backwards compatibility is very important

[njcoder]

Yes, actually very soon you will need to update your server. PHP4 is no longer being updated - this means security and all types of other bugs, including data loss/critical bugs. Yes, if only they thought to write it under an open source license so that the many people that stayed with php4 and will continue to do so could write their own fixes for any major bugs that have not already been discovered.

Re:Backwards compatibility is very important

[unity100]

this is not about blames. this is not about 'idiocy' either. this is about reality.

world is not a programmers' haven. there are a lot of people apart from us programmers. regardless of what we may see as 'idiotic', people may need to use them at a given point in time, and they may use them, and they may have to stick with them. you cant go jacobin on issues like this.

Re:Backwards compatibility is very important

[unity100]

add it to that the fact that clients do not know, or give a damn about oop, and we get the complete picture.

Re:Backwards compatibility is very important

[Anonymous Coward]

regardless, backwards compatibility is important for those people. for starters, these are the people who have chosen php as the platform to conduct their business on, making php a de facto dominant language for the web instead of being a small time web language that was used on web savvy, webmasters. the financial impact of this is going to be huge for them, to adopt to that many changes php dev group started to introduce in the span of 1 to 2 years. this is too much.

The additional features aren't required for use of the new version. Everything that's being removed either has an included, easy to adopt replacement (eg. GD1 -> GD2; ereg -> preg), or has been strongly discouraged for at least the last 5 years (eg. magic_quotes, register_globals).

you gotta slow down. or you are going to alienate the small business community from using php with what you are doing. if you break a small estore owner's store script every 1.5 years for 'upgrading', the second time you do it they will jump the language ship.

For real? If the code is even half decent, the bulk of the changes should require a handful of global find/replaces. You really think the people who don't fall into that category, who couldn't be arsed to write good PHP, are going to spend the orders of magnitude more time learning another language and finding a host that will accommodate their poor practices, than troubleshooting existing code? And so what if they do? Good riddance, and I think the folks behind PHP would agree. After all, the language has such a negative reputation not for becoming a modern language with features real developers expect it to have, but from having major issues related to past encouragement of bad habits (such as the magic_quotes and register_globals nonsense). If PHP is going to continue to grow into a viable, scalable, respectable language that can be trusted for serious web applications, I don't think we need to worry about coddling the folks who can't be bothered to write decent code in the first place.

do not start to become an elitist group out of touch with the people, increasingly caring for nifty programming issues rather than what would the users think.

What does that even mean? It's elitist to add features people don't even need to use, or it's elitist to fix security problems? What do users think?

Besides all of that, I think the majority of people who wouldn't bother to fix their problem code for PHP 6 are probably still on PHP 4 on shared hosts that accommodate that, and I suspect they'll stay there until those hosts stop providing that, which won't be until they've migrated away en masse anyway.

Re:Backwards compatibility is very important

[Anonymous Coward]

You sound so very bitter, and your only argument seems to be "you'll break hosting providers". Any hosting provider that can't handle this change does not deserve to remain in business. Honestly, this is a very small change that should not be difficult to incorporate into an existing hosting service.

As a provider, you'll either support multiple versions of php, or you provide the versions you want to provide and say "tough luck" to customers who want anything else. It's not exactly an overwhelming task to install multiple versions of php on the same server. Provide a /usr/bin/php5 and /usr/bin/php6, no biggie.

Bitching and complaining because your job just became slightly more involved is a lame excuse for bashing new software releases. If this is too much for you to handle, maybe a change in careers is in your near future.

Re:Backwards compatibility is very important

[unity100]

For real? If the code is even half decent, the bulk of the changes should require a handful of global find/replaces. You really think the people who don't fall into that category, who couldn't be arsed to write good PHP, are going to spend the orders of magnitude more time learning another language and finding a host that will accommodate their poor practices, than troubleshooting existing code? And so what if they do? Good riddance, and I think the folks behind PHP would agree. After all, the language has such a negative reputation not for becoming a modern language with features real developers expect it to have, but from having major issues related to past encouragement of bad habits (such as the magic_quotes and register_globals nonsense). If PHP is going to continue to grow into a viable, scalable, respectable language that can be trusted for serious web applications, I don't think we need to worry about coddling the folks who can't be bothered to write decent code in the first place. thats the attitude im campaigning against. this is pure elitism, even if it is for the good.

masses of small businesses do not give a damn about 'good php', 'poor practices', heck, even the nifty words we use to hype software like 'scalability' or anything. they dont care about any opinions like 'the nonsense that are magic_quotes and register_globals' either. these doesnt mean anything for a 55 year old estore owner from Pennsylvania.

we cant write down such people. regardless of what kind of software they use, regardless of how their softwares' creators were using 'bad' practices, (at any given point in time during the lifetime of a popular script), these people are mainly the ones who are fueling the money making side of the language. if they were to jump ship, great deal of incentive for people to go into php, or stay in php (for the ones who are already in the language) would be lost, because less demand, more competition signals an exit from a market.

its about users. its not about aggrandizing some stubborn people resistant to change in a small company that we are working as i.t. manager in. you can go to your boss and have him make the accounting guys accept the changes, but you cant force end software users of a language to anything. if they get annoyed, they jump ship, if they alternatives. and php has alternatives, that we all know, for the good or for worse.

this is what its all about. we cant go elitist and say 'good riddance' here. EVEN if, it may seem right to do so, for purity and from a programmers' viewpoint.

Re:Backwards compatibility is very important

[unity100]

You sound so very bitter u.s. people tend to use this a lot, and i really dont see that it fits any situation, leave aside this one.

and your only argument seems to be "you'll break hosting providers". you missed the core of what i posted then. you should read again.

Any hosting provider that can't handle this change does not deserve to remain in business. Honestly, this is a very small change that should not be difficult to incorporate into an existing hosting service. its not about providers, pal. its about users. if you go up to php 5, 6 and clients have their estores broken, only to learn that they have to spend considerable bucks on having their stores upgraded, recoded, or anything during the course of the same 1.5-2 years, AND therefore decide that they should change their software and jump to some other language, it will be php language, not the web hosts that are going to hurt.

im a php developer. i make my living from this. if, such elitism like 'good riddance', snubbing of end users like this, even for a good cause, causes demand on the market to fall because store owners, script users move to other languages, most of us who make our livings on this platform will have to jump ship also, even if we dont like to do.

Re:Backwards compatibility is very important

[CastrTroy]

I'm with dreamhost, and I still have the option to switch my domain over to 4.4.x, although I'm currently running on 5.2.x. I don't see why a webhost with a large number of customers, couldn't support multiple versions of PHP, especially if there was a large number of customers (at least 10-15%) using that particular version.

Re:Backwards compatibility is very important

[hendridm]

My web host lets me choose which version of PHP to use for a given site/virtual directory.

Re:Backwards compatibility is very important

[Firehed]

Just curious, can you specify any specific scripts? I tend to write most of my stuff from scratch.

Also curious, are they issues along the lines of "INSERT INTO `people` (`name`, `email`) VALUES ('$_GET["name"]', '$_GET["email"]')" or stuff that's specific to the language rather than stupid coders? In my experience, most of the bugs and holes I've come across are due to laziness or stupidity on the coder's part, like failing to sanitize user input as above rather than someone overriding an internal variable with a querystring parameter because register_globals was turned on.

Re:Backwards compatibility is very important

[The End Of Days]

And when idiots use stoves, sometimes they get burned. Life is like that. Too bad for them.

Re:Backwards compatibility is very important

[shutdown -p now]

Clients do care (sometimes, perhaps, indirectly) about how fast it takes to write something, and how costly it is to maintain it afterwards, though.

Re:Backwards compatibility is very important

[shutdown -p now]

if they get annoyed, they jump ship, if they alternatives. and php has alternatives, that we all know, for the good or for worse.

Yes, PHP has plenty of alternatives. And all of them promote good development practices. That's why PHP is trying to catch up now - if it doesn't, it risks being made irrelevant in a few more years.

Re:Backwards compatibility is very important

[Anonymous Coward]

A willingness to break backward compatibility for good reasons is one reason PHP is the well-refined language it is today.

Yet, options have always existed to maintain backward compatibility for individual programs until they update.

Re:Backwards compatibility is very important

[Gavagai80]

Any host can afford to support multiple versions, which is why such a large percentage do support both PHP 4 and PHP 5 and let the user switch between them with an .htaccess line. It's not difficult. The trouble comes when the last PHP4 security updates cease.

Re:Backwards compatibility is very important

[MROD]

Yes, I know it's been a couple of years since PHP5 came out and PHP told everyone to port their code 'cos PHP4 would be disappearing. It's also 5 months since PHP stopped supporting PHP4.

i.e. Some commercial operations have only now started porting their applications because they've been forced to.

This is very similar to Adobe and their porting of their applications to Apple's Cocao framework from the old, depreciated, Carbon on MacOS X.

Re:Backwards compatibility is very important

[MROD]

By support I mean such things as helpdesk and front-line support.

Maintaining two versions of PHP means extra resources are required to keep them up to date. It probably also means two servers (or at least VMs) to run and the problems of moving users from one to the other once their applications are compatible with the new version. This costs money.

Re:Backwards compatibility is very important

[Crimsonjade]

So leave them on php4 then. If they are writing bad code then they are writing bad code. Leaving the backwards compatibility in php6 is not going to make a difference. Part of owning something is maintaining it.

Re:Backwards compatibility is very important

[moderatorrater]

hosting sites can't afford to support multiple versions Well, I'm no expert, but I can support two versions on my desktop, and I can create a virtual machine that runs a different version, and I can even buy another server and have them supporting two different version (although I have no reason to do this). I guess what I'm trying to say is, hosting sites certainly can and many do. Smaller hosting companies may have more of a problem with it, but they can still do it.

Changing the API so greatly and so often in a non-backwardly compatible fashion does cause genuine problems And not closing security holes and letting the language stagnate is a sure road to obscurity. Hosting companies can choose to support one or the other or both, however they wish, but moving forward it will be the same as it was when switching from 4 to 5: already-written software and pre-packaged solutions will migrate slowly if at all, and enthusiasts and serious programmers will move as soon as they can.

PHP started as an incomplete language that didn't support most object oriented features we've come to expect and had pitfalls that were crippling for people who didn't know how to avoid them. It was exceptionally good for small projects and increasingly hard for larger projects. Now it's moving towards better support for serious development techniques, and those of us who work with it every day on large projects are thankful it's moving in that direction. The old versions will always be around, but large projects are increasingly being built in PHP, and if the language doesn't support this, then it's going to die in obscurity. Besides, if those programs depended on the shitty features they're removing, then they deserve to be broken. It's been years since magic quotes or register globals wasn't considered bad practice; let them die from lack of backwards compatibility if they care so little that they won't implement basic procedures in 3 years time.

Re:Backwards compatibility is very important

[ins0m]

You know, I'd really love to know where you're getting this 1-2 year figure.

They began switching off register_globals() as of PHP 4.2.0, which has been out for just over 6 years. You had to manually go in and enable it in your php.ini, and there were many exclamation marks in the docblocks warning you about how this would be going away and you were damning yourself to deprecation purgatory if you relied on it.

Hell, they discontinued support on PHP4 at the beginning of the year.

Features like safe_mode, magic_quotes_*, register_globals, and open_basedir have long been known to be security issues and have been kept in BC for almost 7 years now. To state that this was a premature deprecation is fairly insulting.

Re:Backwards compatibility is very important

[FictionPimp]

Are you mad!!! How would they ever make any money!

Re:Backwards compatibility is very important

[FictionPimp]

When MS changes something that breaks hundreds of things. We say "Think of the jobs this will create".

PHP does it, we say "Oh no!!!"

I think people will fix their code or move on. Either way, its a good thing for everyone.

Re:Backwards compatibility is very important

[Anonymous Brave Guy]

And not closing security holes and letting the language stagnate is a sure road to obscurity.

Don't tell that to the C guys. :-)

Re:Backwards compatibility is very important

[unity100]

its not about web host. its about hordes of people still using heavily modified, modded oscommerce or similar scripts with register globals on and etc.

Re:Backwards compatibility is very important

[unity100]

yea. and when idiots switch to some other stove, the stove brand gets burned. life is like that. bad for such stove manufacturers.

Re:Backwards compatibility is very important

[unity100]

jesus.

its not my stuff. people are automatically assuming that if one gives a heads up about something, s/he has to be IN that something.

ill give you a specific example. there are loads of heavily modified oscommerce stores that are still going with register globals on, and like that.

Re:Backwards compatibility is very important

[unity100]

talking about stuff like heavily modified old oscommerce versions still running with register globals on, etc.

Re:Backwards compatibility is very important

[unity100]

its kinda like linux vs windows. we are following excellent practices in linux as far as we can, and we still havent caught up with windows yet.

which should be more weighted ? having a large user base, and proceeding from that base, or alienating that base with strict programming practices and then trying to catch up again ?

get_magic_quotes_gpc

[Dachannien]

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false?

Re:get_magic_quotes_gpc

[eneville]

Unfortunately a lot of people shove things into a PHP script in an ad-hoc manner. It's time the general people realise what their scripts are doing. I just wish people would pay attention to how mail() works...

Re:get_magic_quotes_gpc

[Dragonslicer]

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false? I thought that's what they were doing. I know there was some discussion about it on the internals mailing list, but I thought sanity prevailed in that one.

Re:get_magic_quotes_gpc

[psyron]

I agree, it's just gonna make more work for people who check get_magic_quotes_gpc() to remove magic quotes in the first place.

Re:get_magic_quotes_gpc

[xSander]

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false? Because there should be a limit on what can be backwards compatible? magic_quotes_gpc is available in two major versions already, and PHP 6 won't be officially released anytime soon (as far as I know -- plus, upgrading to PHP 5 is going slowly.) Besides, PHP programming should be as independent as possible to PHP settings.

Re:get_magic_quotes_gpc

[Dachannien]

Besides, PHP programming should be as independent as possible to PHP settings. Fine, that's great. Going forward, people writing for PHP 6 can forget that magic quotes ever existed.

But there is still a lot of code out there written in contemplation that a PHP 4/5 system wasn't installed by the person writing or installing the scripts (such as shared server environments), meaning that the magic quotes setting is immutable for practical purposes. That means that the script author has to check whether the system is using magic quotes and handle the affected input strings accordingly.

In PHP 6 (and 7, 8, 5000, etc.), since magic quotes no longer work, the return value "false" is still the correct answer to a call to get_magic_quotes_gpc. By implementing that function to always return false, there are tons of legacy scripts out there that won't break - scripts that are already correctly written to handle input strings appropriately when magic quotes are off (or nonexistent).

False sense of correctness

[Anonymous Coward]

If they just leave it, people will go on thinking things are good, until they're hacked. By throwing up a hard error, people will be aware there is a problem. If it's really such a problem, don't upgrade immediately, or write your own replacement function.

Too Little Too Late

[Penguin Programmer]

Unfortunately, everyone has already realized that PHP is an insecure, featureless piece of crap. Real web developers have moved onto other platforms, or stuck with Perl.

Re:Too Little Too Late

[Anonymous Coward]

Absolutely. It's not like anyone still uses PHP.

Re:Too Little Too Late

[thetoadwarrior]

Um, no it's not. It's only downfall is that it's too easy to do powerful things so idiots make dangerous code.

That is not the language's fault. Not everyone wants or needs a JBoss server or something equally silly for their website. PHP is still very good. Safe programming in PHP just needs to be preached more to the new users of PHP and some of the self taught people who perhaps learned off the net from someone else with little experience rather than a book since all books I've seen cover the basics on safety.

The only thing that annoys me is the fact it's function naming methods aren't consistent. It shows that it's had input from various places without any thought into standardizing things.

Re:Too Little Too Late

[Falesh]

Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.

Re:Too Little Too Late

[Spatial]

As opposed to fake ones?

Re:Too Little Too Late

[FooAtWFU]

That's not its only downfall. Its other downfalls include some miserable organization and bloated core, though much of this may be attributed to lack of namespace support - which is being remedied, but it's a bit late. There's still a lot of package_name_prefix_with_function_name functions, and I don't see them going away soon.

Beyond that, and the pervasive "make it easy to do the WRONG thing" un-philosophy, I still haven't heard about it getting lexical scope, closures, and anonymous functions. Of course, this only matters if you're a good programmer (as opposed to merely a Decently Adequate one).

Re:Too Little Too Late

[Anonymous Coward]

You sir live in a dream world.

Re:Too Little Too Late

[Anonymous Coward]

Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.

Don't be daft! PHP is a poor language, I needed unsigned ints and native utf8 string handling 8 years ago. My problem is that much as I malign PHP and have tried all the alternatives, I've not really found anything better.

But the developers aren't really helping at this point. Why they can't sanely rename the inconsistent global functions and have a secondary alias table for backwards compat I'll never know.

Re:Too Little Too Late

[njcoder]

Um, no it's not. It's only downfall is that it's too easy to do powerful things so idiots make dangerous code. Most people don't write their own php scripts, they use what other's have written. And if one big vulnerability gets discovered in a script and you start seeing a bunch of websites getting defaced or worse. Most people are using some sort of shared hosting, so your site may get affected even if you don't have any php.

Since it takes less resources and performs better, most hosting companies run all php scripts as the same user. Yeah there are ways to jail it to a certain directory per user but that's not very secure. PHP's stance has pretty much been it shouldn't be the languages responsibility to come up with the security.

Re:Too Little Too Late

[KnightMB]

Unfortunately, everyone has already realized that PHP is an insecure, featureless piece of crap. Real web developers have moved onto other platforms, or stuck with Perl. I think I hear this every time someone has been hurt by a buddy who was able to code circles around them in PHP while they struggled in Perl. Real web developers use every tool at their disposal, not just Perl or PHP only. Your statement alone shows the conceit you have about your own skills as compared to everyone else that makes a living doing web development, apparently much more successfully than you.

Re:Too Little Too Late

[larry bagina]

Would you really expect the same people that fucked up the language as bad as they did to suddenly fix it?

Re:Too Little Too Late

[zuperduperman]

> but that doesn't magically make the language crap in the hands of more experienced developers.

No, it makes the language total crap.

* In the hands of inexperienced developers, (it's primary user base), it's horrible because almost everything you do the default way is insecure.
* In the hands of experienced developers it's missing all kinds features that nearly any serious application needs.

The segment of people for which the language is not crap is really very small.

Re:Too Little Too Late

[njcoder]

Absolutely. It's not like anyone still uses PHP. Yeah. What happened in 2005 to make it plateau like that?

Re:Too Little Too Late

[CastrTroy]

Name a language that can be used for web development that isn't dangerous in the hands of inexperienced developers.

Re:Too Little Too Late

[Anonymous Coward]

Maybe they just ran out of people to use it.

Re:Too Little Too Late

[zuperduperman]

> Name a language that can be used for web development that isn't dangerous in the hands of inexperienced developers.

Why? Nothing I said assumes or even implies there is such a language.

Can you name a car that's not dangerous in the hands of an inexperienced driver? Does that mean you would recommend inexperienced drivers learn to drive in Ford Pintos?

Re:Too Little Too Late

[CastrTroy]

When driven safely, there's nothing wrong with a ford pinto. Sure it's not the best car out there, but it will get you from A to B. And what do you even mean by "doing things the default way", in reference to PHP. Is mysql_query("SELECT * FROM Users WHERE UserID='" . GET["USERID"] . "'") the default way of running a query. Because that's the way most beginner PHP tutorials teach it. Or is the default way to use mysql_real_escape_quote. Or is the default way to use a prepared statement, using PDO. If you think the default is the first way, then I would blame the problem more on badly written tutorials than on any problems with the language itself.

Re:Too Little Too Late

[Anonymous Coward]

Way to turn a non sequitur into a red herring, faggot.

YOU HATE PHP SO YOU MUST SUCK AT WEB DEVELOPMENT! HURRRFFFFF PHP PAYS FOR MY CIVIC.

He's right, by the way. Compare the number of security flaws in Perl or Python to the number in PHP. Use NIST's handy website to do it. You'll find that perl and python have language-level security flaws in the low teens while PHP has them in the triple digits.

Basically, fuck you for hiding behind some fake egalitarian front. PHP sucks dick, and so do you for defending it.

Re:Too Little Too Late

[zuperduperman]

> When driven safely, there's nothing wrong with a ford pinto.

That's exactly my point. The inexperienced driver is unable to drive safely. Therefore it is especially important that they do not drive a vehicle which explodes on impact.

Re: your note about 'default' - yes, in the context I was writing I consider the first to be the "default". I understand that wouldn't apply to all contexts. But I don't think you can so readily separate the language and the community. Yes the tutorials could teach one of the more correct ways to do it - but it's much harder. It means people have to know all about what escaping is and when to apply it, or they have to install and grok PDO which their hosting provider might not even have. So they start with the easiest way. In other languages the easiest way is likely to be the (more) secure way.

NB: I assume you meant mysql_real_escape_string rather than mysql_real_escape_quote, but in case not ... make sure you're escaping much more than quote's in your database input ;-)

Cheers,

Simon.

Re:Too Little Too Late

[Justus]

PHP actually does have anonymous functions, although they're implemented in a somewhat clunky fashion.

Re:Too Little Too Late

[rtconner]

I just can't believe they are not implementing named params for functions. I am in just total shock. That is one of the biggest things that python/ruby have over php and they are not implementing it?

Why why why? This boggles my mind.

Re:Too Little Too Late

[LS]

...faggot.... Fuck you .... PHP sucks dick

Unlike the grandparent poster, you have clearly made the point that indeed it is YOU who are the clear and rational one.

Re:Too Little Too Late

[ins0m]

although they're implemented in a somewhat clunky fashion. Yeah, and last I checked, they don't fall out of scope for GC until end of script execution. That's a pretty big memory hole for any serious usage, so while they're available, they're not practical.

Re:Too Little Too Late

[Anonymous Coward]

I think I hear this every time someone has been hurt by a buddy who was able to code circles around them in PHP while they struggled in Perl. What on earth does this even mean? How does crap like this get modded up?

Re:Too Little Too Late

[Anonymous Coward]

This is silly. Yes, web developers use whatever they need to use. I _can_ use PHP if I have no other choice. But I _avoid_ it as often as I can. I've been programming in PHP for more than 10 years now and the size of the projects i've worked on vary from very trivial to monumental. PHP is _easy_. But only for easy stuff. Once your project starts to grow PHP becomes a horrifying mess.

Re:Too Little Too Late

[CastrTroy]

I think that putting code out on the web is something only for experienced developers. Sure, everybody and their brother wants to do it, but that doesn't mean it's a good idea. Putting out an application on the internet, where anybody else can access it is inherently complex. Especially when you have server side code that accesses a database. You can kind of think about programming as chemistry. Anybody can buy a little chemistry kit in the mall, that has been verified to not contain anything that will explode or corrode, but that doesn't mean that people we would assume they are safe using high concentration sulfuric acid. The same for programming. If you are just programming little desktop apps that will be used by a single person then that's not so bad. It's much harder to cause a problem with a program on somebody else's machine if that program isn't accessing the internet. Once the app moves online, everybody is affected when a vulnerability is found. You wouldn't want an amateur making gun powder, you wouldn't want an amateur putting code out on the web.

And yes, I did mean mysql_real_escape_string. I only use PHP for personal development, and haven't used that function for so long that I forgot what it was called. Much easier and less risky to use PDO with prepared queries. You can't accidentally forget to clean a string using that method.

Re:Too Little Too Late

[larry bagina]

somewhat clunky? The only thing less clunky would be writing out function code to a temporary file and then including it. Yet another example of PHP developers adding a "feature" without putting any thought into it or understanding why.

Re:Too Little Too Late

[thetoadwarrior]

True but it still stands that a lot of is down to the coder and not the language. I'd hope most hosts monitor people's PHP usage to some extent. I know ages ago I got booted off a host for using someone's script which was deemed harmful which is probably why I took the time to learn a bit of the language myself shortly afterwards.

The language is by no means perfect and I prefer working with Java but it's still a nice quick to learn powerful language.

Re:Too Little Too Late

[Ant P.]

Market saturation?

Re:Too Little Too Late

[Anonymous Coward]

Real web developers use every tool at their disposal Just because a tool is there doesn't mean you have to use it.

I would PHP into that category and move on. A lot of people have. There are much more pleasant environments to develop in, and you don't need all that much to generate 99.9% of the dynamic Web pages out there. (And heck, for that other 0.1% a better language is going to make it easier, even if it's not quite as turn-key.)

Re:Too Little Too Late

[Anonymous Coward]

There's a load of security concerns when developing in PHP, but you can't tell me that's not the case with every language out there.

Who programs without security in mind in any language?

Re:Too Little Too Late

[jtcm]

Yeah. What happened in 2005 to make it plateau like that?

That's really interesting. I wonder if it has anything to do with the release of ASP.NET v2.0?

After avoiding Microsoft web platforms like the plague for a decade, I recently took a new job and left the LAMP and Java/JSP world behind for ASP.NET and C#; and I'm amazingly productive on the new platform. I never used ASP.NET v1, but it looks like it was missing a lot of things that were added in version 2. I'd be willing to bet that with the release of v2.0 in 2005, Microsoft stole a big chunk of what would have been PHPs market share.

Magic Quotes was never a security function.

[gandhi_2]

It was to protect you from the O'Malleys and O'Connors. The PHP framers were obviously fans of Mel Brooks' film, Blazing Saddles: "We'll take the niggers and the chinks but we don't want the Irish". Or I'm missing something.

Re:Magic Quotes was never a security function.

[senor_burt]

Having just imported a .csv into a DB with PHP for my first time (10K records into 4 tables in less than 8 seconds), I laughed my ass off at this (my worst was an O'Malley, Jr.). Now, I HAVE to rent that movie again, too. Thanks!

Real change

[Anonymous Coward]

Make it like a modern language.

Change . (string concat) to +

Change -> (pointer-to-member operator) to .

Done. Huge productivity increases.

Thank you.

Re:Real change

[Anonymous Coward]

Change . (string concat) to +

And introduce typed variables? Or should they just make it like javascript where you have to multiply everything by 1 if you want to add a number to it?

Re:Real change

[Tablizer]

Change . (string concat) to +

Nooooooo. That makes code confusing to read IMO.

Change -> (pointer-to-member operator) to .

Do what some other scriptish languages do: use "." for both objects and maps (associative arrays) because they are (or can be) pretty much the same thing. Then use something like "&" for strong concatenation.

I suppose nobody will agree on syntax matters.

Re:Real change

[Anonymous Coward]

They really should fix this C++-lineage. It makes for really ugly PHP code.

Re:Real change

[Anonymous Coward]

The perl argument against + is that 3 + 5 isn't different to 5 + 3 but "3" + "5" is different to "5" + "3". Perhaps they could use & instead of + then?

Re:Real change

[Anonymous Coward]

Lineage implies it's a descendant language - it's not - it's a fabrication and a whole 'new' language with hints of many others.

Re:Real change

[Anonymous Coward]

& is already the reference operator and that makes sense. The only language I'm aware of which uses & for string concat is VB - no need to be pulling bad ideas from a bad language. I coded in VB for many years and hated the & - almost as much as I hate the . operator. A period is not a natural - it's almost always an ending.

Re:Real change

[SanityInAnarchy]

...Wow.

I can think of a dozen things off the top of my head that would make PHP a better language, or at least make it suck less.

And this is what you came up with?

Even of all the syntax tweaks -- and there's so much more that's wrong with PHP than syntax -- I can think of so many more useful things to do than that. In fact, having concatenation be different than addition is a feature, not a bug -- if you add 2 and 2, you always get 4. If you concatenate 2 and 2, you always get 22. With + meaning both, you have to know a lot more than that you're '+'-ing 2 and 2; you have to know things like types.

Re:Real change

[Anonymous Coward]

& is also used by ColdFusion... which uses #variables# (and that really ends up annoying when mixing with HTML/CSS).

Re:Real change

[eggnet]

A variable should not be both a string and integer at the same time. I hate that about both PHP and JavaScript.

Python and Ruby do it the right way, a variable can be anything like PHP and JavaScript but at any point in time, it is either a string or an int. If you have a string you would like to convert to an int, you have to explicitly convert it.

Re:Real change

[Wiseman1024]

What the heck is parent modded insightful?

If they change . to + without fixing the shitty way values are automatically converted from one type to another in PHP, we'll end up in the same error-prone, insane crap that JavaScript has.

Of course, if he had added that weak typing needed to go (note: NOT DYNAMIC TYPING), then I'll agree. Then agree to get rid of ->.

But huge productivity increases, because of that? Using three neurons to decide whether you want numeric addition or string concatenation, and typing + instead of .? Give me a break.

Real productivity (and readability) increases come from features such as first-class functions, lexical scoping or list comprehensions.

Re:Real change

[jyurkiw]

Ever wondered why they picked the '.' for a concatenation operator over the trusty '+'?

PHP is a loosely-typed language.

The '+' is also the arithmetic operator.

Is a line of code reading
$c = $a + $b
adding $a and $b? or is it concatenating them?

What if $a = 513 and $b = 4201?
Are we talking about a phone number? Or am I trying to come up with $c = 4714?

There was a very good reason for having '.' as the concatenation operator.

Re:Real change

[Anonymous Coward]

If all you can think of to suggest to the PHP team is these few minor syntax changes, you're the one who's doing something wrong.

Re:Real change

[Anonymous Coward]

Huh? You called this meeting on improvements to PHP, and all you can ask for is a *change* in concatenation and accessor operators?

Perhaps you should become acquainted with a real object-oriented language before drawing the line at '.' vs '->'. I can think of many other features I'd love to see in PHP's object model, before I arrive at wanting to change '->', puleeze. Static initializers, for one. Or, threads for another. Persistent globals, a VM?

Probably what I really want is Java, or Smalltalk... but instead, I'm stuck in PHPland at work ... language of the lowest-common-denominator, when it comes to hiring programmers. "Everyone can learn PHP!" But not everyone can design reusable software with it. Often, it seems colleagues are just getting work done, few ever think of fitting their program's functionality into reusable classes, even though it's possible.

Re:Real change

[Anonymous Coward]

Add one more change to your list:

Make the use of dollar signs (on var names) optional if they appear outside of quoted strings.

This one change would cause the single biggest increase in programmer productivity.

Re:Real change

[Tetsujin]

There was a very good reason for having '.' as the concatenation operator. The "very good reason" is that PHP doesn't distinguish between a string containing digits and a numeric value...? I am seriously not convinced that's a good thing.

I mean, OK, it's a convenient thing to have in a language that primarily deals with textual I/O (such as HTML, XML, HTTP form submissions, etc.) - I am familiar with the idea from languages like Perl. But lately I've felt like that convenience isn't worth the muddled type identity it results in... It's better, IMO, to clearly establish that $a contains numerical data or $b contains textual data - and if somebody tries to add $a to $b, reject it for the nonsensical operation it is.

Re:Real change

[nuzak]

> Ever wondered why they picked the '.' for a concatenation operator over the trusty '+'?

Because perl did. Don't imagine any more thought than that went into it.

A language with only one sigil and they keep the sigils anyway. Facepalm.

Re:Real change

[Rysc]

The "very good reason" is that PHP gets its concatenation operator from Perl. As such if it were going to use another one it would make sense to use _, from Perl 6, not &, from fucking VB.

As much as all of my OOP friends might like to pretend otherwise, concatenation is not addition for strings. "str1" + "str2" is nonsensical. If you read the code as "the sum of str1 and str2" you get nonsense, or you make assumptions and sum equivalent ascii values.

It is far, far better to do concatenation explicitly rather than by implication; that is, to *say* when you're concatenating and when you're summing. I would prefer a concat() or cat() function by far above overloading + to do concatenation on strings. I think that foo = concat(bar,baz); is easier to read than foo = bar + baz;, especially if you consider this from the perspective of someone who is (a) unfamiliar with the code he is reading and what it is supposed to do, or (b) unfamiliar with the *language* he is reading. Why should I need to know the type of the variables to be able to figure out the new value of foo?

While I'm talking, the change from -> to . is entirely immaterial. The only advantage is in reduced keystrokes (3 vs 1).

Re:Real change

[chromatic]

String concatenation in Perl 6 is now infix ~, just like string conversion is always prefix ~.

Re:Real change

[renoX]

>>Change . (string concat) to +
>Nooooooo. That makes code confusing to read IMO.

In D, concatenation (of string, list..) is made with ~ which is nice I think.

Re:Real change

[renoX]

>Huh? You called this meeting on improvements to PHP, and all you can ask for is a *change* in concatenation and accessor operators?

You shouldn't underestimate the power of syntax..
A language's syntax is like the color/appearance of a GUI: people are hugely sensitive about it, even if in theory it shouldn't matter, it does in practice!

Why PHP sucks

[rootpassbird]

They've fixed a lot of things that were being complained about under the terms "why php sucks" http://www.google.com/search?q=why+php+sucks .
Related news is that PHP runs much better now on Windows Server 2008, as per the official Zend statement. But I doubt we will see too many people switch to WISP. This is flambait, agreed.
Also if you now have a PHP-fed brain with no place for anything else, with the new namespaces-on-steroids (http://www.php.net/manual/en/language.namespaces.using.php) change, you'll likely port slashcode to ::\/\.
And otherwise refer to <things like="this" /> :-)

Re:Why PHP sucks

[shutdown -p now]

They've fixed a lot of things that were being complained about under the terms "why php sucks"

Well, yes. The problem is that, when you fix all of the stuff that makes PHP suck, you eventually end up with something eerily similar to Python, albeit with half-Perlish syntax. Why bother?

Won't change a thing

[cortana]

PHP scripts will still manually implement it, and each one will do it in a slightly different but still broken way, generating hundreds more security vulnerabilities...

Still a long way to go before it's fit for purpose

[Anonymous Coward]

So, if you're a developer or architect using a different language, such as the Java programming language, because it has better internationalization (i18n) support than PHP, it'll be time to take another look at PHP when the support improves.

Err, no we're using Java because it's a coherently designed programming language and set of libraries, not just because it's got Unicode support throughout. At least they're removing som of the horrific hacks like "magic_quotes" and "register_globals".

what's with the 'phpsucks' tag?

[sneakyimp]

I've noticed that every single article here mentioning PHP is immediately tagged 'phpsucks'. I find PHP incredibly expressive and am always surprised by the incredible variety of libraries/modules/plugins to manipulate graphics, flash, pdfs, to support protocols like SOAP, JSON, etc.

Perhaps we need an article on 'why php sucks' ?

Re:what's with the 'phpsucks' tag?

[FooAtWFU]

You mean like this?

It's not the lack of modules that people complain about. PHP is excessively convenient, if nothing else. :)

Re:what's with the 'phpsucks' tag?

[hardburn]

People have written that article, and it's generally responded to by a lot of jumping up and down.

At this point, I'm content to leave PHP as a way to vacuum the dreck out of the Perl community.

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

I find PHP incredibly expressive

You will benefit greatly from learning another language. Pretty much every modern language is more expressive than PHP. Even VBScript*.

* Little known fact: a lost appendix to the Bible mentions that VBScript is actually the fifth horseman of the apocalypse.

Re:what's with the 'phpsucks' tag?

[sneakyimp]

In addition to PHP, I have programmed in assembler, Basic, C, C++, VB, VBScript, WordBasic, Java, Javascript (and Jscript), Actionscript (1, 2, and 3), Lisp, and Pascal. I disagree that any of these are more expressive than PHP. Also, to assume it's all I know is *really* irritating.

Re:what's with the 'phpsucks' tag?

[diskofish]

PHP just makes it really easy to write sloppy code. I switched to doing primarily .NET few years back, and I prefer the more structured environment and compiled code. The only time I touch PHP now is to maintain existing code.

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

I have programmed in assembler, Basic, C, C++, VB, VBScript, WordBasic, Java, Javascript (and Jscript), Actionscript (1, 2, and 3), Lisp, and Pascal. I disagree that any of these are more expressive than PHP.

Then please describe what you mean when you say "expressive", because you and I seem to have wildly differing definitions.

Also, to assume it's all I know is *really* irritating.

The only likely explanation I could think of for you considering PHP to be expressive is that you had not been exposed to any other language. My next hypothesis is that you didn't actually mean expressive. If that also proves to be false, I will look for another explanation, because the idea that somebody might actually consider PHP to be more expressive than other languages is extremely unlikely. I rank you blatantly lying as more likely than you genuinely considering PHP to be expressive while having knowledge of other languages.

This is not mindless PHP bashing. I have used PHP for years myself. It has its good points and its bad points. But it is simply not expressive compared with other languages. Even most die-hard PHP advocates recognise that. Hell, ask the guys at Zend, and even they will probably tell you that PHP's strengths lie elsewhere.

Re:what's with the 'phpsucks' tag?

[CastrTroy]

As a fellow .Net developer, I really have to agree. I use PHP for my hobby projects, because it's easy to find a cheap webhost that has it, but I really don't like the unstructured mess that is PHP. Despite the fact that I like to use open source software wherever possible, I have to say that .Net really is quite a bit better than PHP.

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

In PHP you used to have to live with reset() and next(). foreach() simply didn't exist until the language designers finally noticed their oversight at version four. In Lisp you could have added it to the language yourself. That's what the rest of us mean by "expressive".

Re:what's with the 'phpsucks' tag?

[dotancohen]

Googling "why php sucks" gives this informative article as the first result:
http://www.bitstorm.org/edwin/en/php/

Re:what's with the 'phpsucks' tag?

[Anonymous Brave Guy]

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” — Bjarne Stroustrup, creator of C++

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

As evidenced by FooAtWFU's link, there really are no reasons that PHP sucks. It's just a lot of awnry Perl mongers with sour grapes because PHP has been far more successful than Perl (for many, many reasons).

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

I have always wondered where this hatered about php comes from. Reading your linked page quickly shows, that this must have been written for php 3.

Most of the issues have been adressed in php 4 just with default config changes and are ironed out with 5. Php 6 brings now namespaces so whats left? inconsistent function naming and return values for some functions (many have been changed as well).

-S

Re:what's with the 'phpsucks' tag?

[sneakyimp]

You have only succeeded in making yourself more irritating. By 'expressiveness,' I mean the ability to express my end result in code with the least amount of effort (i.e., the least amount of lines, files, and code).

For C or C++ or any other stricly typed language, you are tasked with type conversion and casting. This adds lines.

For Javascript, Actionscript, VBScript, or any other sandboxed, client-side scripting language you can't manipulate the file system or talk to a database without any intermediary. These language require more effort to write the intermediary.

And LISP can be extended? Great! enjoy that will ya? LISP is easily the most unreadable langugage that I have ever seen beyond binary and assembler. Also, the need to extend the language itself requires more effort.

Don't trouble yourself writing another retort. I can tell this isn't going to lead to anything productive.

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

I really don't like the unstructured mess that is PHP But.. Isn't that your fault as a coder? Aren't you basically vocalizing a character flaw that YOU have? You're basically saying "I simply don't have the self-discipline to code in an organized and structured way unless the language forces me to."

That's a problem with you sir, not PHP.

Re:what's with the 'phpsucks' tag?

[Hognoxious]

I find PHP incredibly expressive

I find watercolours expressive, but I wouldn't want to program with them.

Re:what's with the 'phpsucks' tag?

[sneakyimp]

I find American English expressive. We save bytes by typing 'watercolors' instead of 'watercolours'.

Re:what's with the 'phpsucks' tag?

[Anonymous Coward]

By 'expressiveness,' I mean the ability to express my end result in code with the least amount of effort (i.e., the least amount of lines, files, and code).

Back when I did PHP for a living, I was constantly coming up against brain-dead misfeatures and shortcomings of the language that forced me to write more code. From boilerplate to fix magic quotes, to temporary variables only necessary because you couldn't dereference the result of a function call, the language just got in the way, all the time.

For Javascript, Actionscript, VBScript, or any other sandboxed, client-side scripting language you can't manipulate the file system or talk to a database without any intermediary. These language require more effort to write the intermediary.

This is nonsense. You don't need to write any "intermediary" to manipulate the filesystem or talk to a database with JavaScript or VBScript, you just use the host objects provided. The only time this would ever be an issue is if you are talking about running them inside a browser, but if that's the case, you aren't comparing like for like, as PHP would fare no better in that situation.

Perhaps you are ignorant of this (I see you referred to them as "client-side scripting languages"), but JavaScript and VBScript are not just used in the browser. They are used on the server and desktop as well. The only difference is in which host objects are provided. The language (and remember, that's what we are discussing here) stays the same.

Your argument boils down to "PHP is more expressive than anything you stick in a browser because it isn't subject to browser restrictions". Well yes, but you aren't comparing languages there at all, are you, you're just pointing out that doing dangerous things in a browser is harder than doing dangerous things on the server. The languages involved aren't relevant.

Re:what's with the 'phpsucks' tag?

[Hognoxious]

Do you bake bread out of dogh that's made from flor? If yo're going to spell things wrong, at least try to be consistent.

Short tags

[Anonymous Coward]

Are short tags being removed, or deprecated? I remember reading that the devs had decided to leave short tags in.

No offence php, but <?php echo "Hi!"; ?> does not even *begin* to compare to <?= "Hi!"; ?>. Hiding behind "it breaks open xml tags", or that "default configuration has them disabled, so using them is not immediately portable across hosts" is bullshit. If I'm coding for my own environment, *I* will choose which format I use, and I should not be expected to use ugly syntax to make things "portable".

Re:Short tags

[Anonymous Coward]

ONLY ASP Tags are being removed (<% %>)

I'm New Here

[New Here]

I'm New Here

Re:I'm New Here

[Anonymous Coward]

I see that.

New PHP features are great and all but....

[FilthCatcher]

My biggest issue with new PHP changes is fact that the sheer size of the PHP libraries mean that these new features don't bubble through to the whole core.

For exmaple take the newish try / catch exception features. On first glance you think "finally I can write decent exception handling into my own code" - which is great for your own exceptions but too many of the core functions used by your code or by a framework you're using don't throw exceptions - they indicate an error codition in the function's result.

So now we're seeing loads of code out there by people trying to do things "The right way (tm)" but it's full of bugs as there's exception conditions being raised by core functions that don't get caught by the catch blocks.

The line from TFA that concerns me is "Much improved for PHP V6 is support for Unicode strings in many of the core functions"

Many? That will means developers will start using unicode only to find scattered lines of code throughout the app doesn't work as the core function it uses doesn't support unicode. The overhead of keeping track of which functions do and don't support unicode will be a nightmare.

Re:New PHP features are great and all but....

[CastrTroy]

That's the big problem with PHP. They get all these great new features, but since they weren't there in the first place, you can't really take full advantage of them. Take namespaces for example. It's great that they have namespaces now, but it doesn't help when the entire PHP API is completely devoid of namespaces. You mentioned exception handling, where it's nice that they finally have it, but it sucks, because the current API doesn't employ it. Even things like object oriented programming are only half supported by the API. Certain things are possible to do using objects, but large parts of the PHP API don't even use objects, just functions.

Re:New PHP features are great and all but....

[Anthony Boyd]

That will means developers will start using unicode only to find scattered lines of code throughout the app doesn't work as the core function it uses doesn't support unicode. The overhead of keeping track of which functions do and don't support unicode will be a nightmare.

Dude, it's already a nightmare. For my employer, I had to move from MySQL 4.0 to 4.1 or higher, as well as move into UTF-8 land with PHP. Anyone who has done this knows that's a double-whammy, as MySQL had a huge shift regarding this stuff with the move to 4.1. Going to PHP's page on which functions need to be replaced is woefully incomplete. You cannot just substitute the functions they mention. There are dozens of others that have problems with multibyte text, and they're not flagged at all. I took it upon myself to create a Greasemonkey script that will flag the dangerous functions in PHP's online manual. But even still, a lot of it is educated guesswork because I can't program at the level they do, so reviewing their source code is grueling for me.

To be honest, this is one thing that the Perl team got right. I don't know how painful it was for them, but for me, UTF-8 just worked in Perl. I wish PHP could reproduce that, but it's already too late. The best we can hope for is that they keep working hard and work well.

Re:New PHP features are great and all but....

[Anonymous Coward]

You can call set_error_handler('nameOfYourFunctionThatThrowsException'); if you want to have everthing throw exceptions instead of errors (except parse, fatal, etc.)

Re:New PHP features are great and all but....

[Ant P.]

The line from TFA that concerns me is "Much improved for PHP V6 is support for Unicode strings in many of the core functions" Maybe they're hinting that something's going to be done about this particular disaster. How many different naming conventions can you count in that list?

IBM: Low quality as usual

[porneL]

Apparently writing about PHP automatically allows using dumb code in examples:

function is_authorized() {
        if ($expression_that_returns_boolean) {
                return true;
        } else {
                return false;
        }
}

and

echo "Welcome, $_GET['cross_site_scripting_attack']!";

I guess PHP needs magic_entities ;)

Re:IBM: Low quality as usual

[Anonymous Coward]

For those IBM applicants wondering...

function is_authorized() {
        return ($expression_that_returns_boolean);
}
 
echo 'Welcome ',(ctype_alnum($_GET['noxss']))? $_GET['noxss']: 'lamer';

I've not read TFA but some of the IBM dev articles are downright embarrassing. I'm self taught and probably wouldn't get a job with them, neither have I used PHP on more than a couple of small projects. Stop the suckage guys, try flower arranging or something!

actually not

[unity100]

php's success compared to other languages like asp, which tried to compete with it and came out about the same time into prominence is due to php becoming more than a small nifty toolset for doing knickknacks on hobby sites and forums. php started to be used for business, and this created a demand for php programmers, and this in turn fueled more entry into language. same did not happen for asp. go check elance. youll see zillions of php projects that are put up, and equally many php developers. search for asp and .net stuff. see how many.

the scripts which have a lot of old versions still being used out in the web today were a major cause for this. hell, even many simple forums that were started as hobbies turned into big community forums that do a lot of advertising and generate business, leave aside estores.

its not wise to go trigger happy.

Re:actually not

[CastrTroy]

Try doing a search on Dice.com, where they post jobs. ASP.Net Developer returns 3626, while PHP developer only returns 1514 jobs. That's less than half. So while PHP may be used by tons of hobbyist coders (I use it myself), ASP.Net is used much more in the business world.

Re:actually not

[DuranDuran]

That's not a good indicator. Maybe ASP applications have more problems or require greater upkeep. Maybe PHP applications can get by with occasional free updates from open source projects. Maybe ASP-using firms are larger and employ more people. Maybe PHP-related jobs are solved more quickly.

Re:actually not

[unity100]

dice is a place that caters to corporate culture companies. which are generally bound to be running on ms stuff.

go elance. go rentacoder. go scriptlance. go getafreelancer.

the amount of php requests are staggering, even compared to the amount of the php developers. asp ? like nonexistent.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Exception support only half works in PHP5

[bigtrike]

Hopefully they can fix exception support in PHP 6. Currently it breaks in a lot of weird ways which can be nearly impossible to debug. For example, the following code:
function a() { new DateTime("2007-02-32"); } register_shutdown_function("a");
Generates:
Fatal error: Exception thrown without a stack frame in Unknown on line 0
Tracking down such an error in PHP 5 can be quite time consuming since current debugging solutions only work in very limited situations.

Re:

[clint999]

Depends. Linux 2.4 -> 2.6. Better example: Anything after OS X. We're up to 10.5 now, but everyone's drooling over it. Why? No numbers at all

Almost..

[encoderer]

...He took the "contract." Nobody was forced.

But his post is inane.

Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon?

If he had done that, all he'd have needed to do was get a copy of the binary as compiled for use on the production server, and their php.ini. Install, copy in the php.ini, and he's up and running in an environment identical to the Prod server.

Barring that, if he'd had gotten their php.ini anyone w/ any PHP experience would be able to see what non-std components were included, and the version everything is running at. Download it, compile it, install, and copy-in the php.ini.

If he's spending a "good fraction" to get a "test bed" then he really should stick to tech support or network administration or whatever he's done over the past few years full time for a living.

Re:Almost..

[cayenne8]

"Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon? "

You're still in school or new to the real world, arent' you?

:-)

Of course it should be that way...but, often out there, you run into just this situation. The mgmt. wants a change or something done, but, they don't wanna buy new hardware, etc....

It sucks, but, I've run into systems where the dev. and prod. are on different platforms...and this isnt' just because of cheapness, in the govt. contracts...sometimes one company wins the dev. part of the contract and a different company has the prod. I've seen this where the system is developed and tested in a win environment, but, is to be deployed to a unix environment, yet, they can't understand the inevitable problems that have to be ironed out, but, no time for this was scheduled. And this is on multi-million/billion dollar systems.

This isn't something that is all that rare.

Re:Almost..

[njcoder]

"Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon? "

You're still in school or new to the real world, arent' you?

I do most of my Java web development on either win2k or winXP. (For other reasons I need certain windows apps).

I use netbeans to develop and I generally deploy to RedHat, CentOS or Solaris using different servlet engines. Mainly Tomcat and Resin. I don't remember the last time I had problems deploying a WAR file from Windows to Linux or Solaris, other than what's in Context.xml, which is what that file is for. Sometimes people put things in web.xml that are related to the context and run into issues.

Usually, if I have a problem it is when going from one servlet container to another or between versions of the same container. These are problems have been with stuff the stuff that's configured in the container such as JDBC DataPools, Environment Variables and other external resources.

I've used all sorts of different libraries (jar files) that get included in the war file and haven't run into any issues.

I've done some stuff in PHP and haven't been too impressed. One thing I really hate is that connections to mysql and postgresql require different code. In Java it's all JDBC. The few times I've had to switch between databases in Java the only changes necessary to the code were in the actual SQL if some advanced query options were necessary.

There's just not enough consistency in PHP and you get some really odd method names that don't match up too well with similar functions in other libraries. I know some people have been critical over Sun for how much control they seem to want over the platform, but it has really helped developers in most cases. Having a well defined specification means and a verification of that specification before you can call your product java-something-compatible is nice.

One thing I do like about php is that you don't have to wait as long as you do for a jsp to compile. When you're developing this can be a pain. Since Java5 this seems to have gotten better, Java6 improved it even more. PHP still has the edge here, but not as much as it did before especially with a decent processor. The JSP only needs to compile once though, after that there's really no noticable difference. In personal benchmarks I've done, I've had Tomcat put PHP to shame for code that was basically the same, except that the Java code was doing slightly more.

I think PHP 4 was good for what it was. I remember a lot of past debates over Java vs PHP where people were trying to argue that you could do anything you can in Java in PHP except it is easier and faster. You couldn't. I'd be surprised if that was even true now. Although PHP does seem to be moving more towards features that Java has. OO, exceptions, namespaces, and more. To me that's a mistake. PHP was popular because it was easy. OO concepts and some of the other new features aren't that easy. In my opinion, PHP would have been better off sticking to what it started out as with better integration with Java, C maybe even .Net instead of trying to rewrite the features available in other languages. At the time PHP was gaining momentum, JSP wasn't that great. Because of PHP the JSP spec has made great strides to compete.

Memory wise, if you're using mod_php, you'll probably use less memory between similar apps. In a shared environment though, using mod_php isn't very secure and the hacks to try and make it more secure are far from perfect. So if you're using fastcgi or something like that, so you can run a separate php engine per user, you will use more memory overall, and lose out on the performance of mod_php. Default Tomcat 6 on JDK6 takes up 30M of memory for me with no apps deployed and no tuning. Big apps like Drupal can have memory and performance issues. It all depends on how you code your app.

I think people that a

Re:Almost..

[SatanicPuppy]

The problem with JDBC is always on the server end. All too often I have to resort to the JDBC->ODBC bridge to get anything done.

Having the code be different for every database is annoying, but if you abstract your database logic, you can make the application portable without too much extra work. Even better, that work will only have to be done once and you can reuse the code until hell freezes over. If nothing else it makes your security a bit more robust, because you know what's in your database code, and you can update your entire implementation without going into individual apps.

Re:Almost..

[Just Some Guy]

Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon?

That's a pretty bad practice, actually. At work, we develop Python apps that will run on Windows and Unix. Each developer's machine is a little (or a lot) different from the others. Some of the programs will run on Python 2.3 on FreeBSD, and others will be deployed on Python 2.5 on Windows XP. And yet, everything works on all of those machines. Know why? Because we know that each line of code will be deployed in several dissimilar places. Therefore, we take steps to make sure the differences are handled by abstraction libraries (either built-in ones or locally written stuff), or at the very least encapsulated in tiny blocks at the top of each module ("if os.name == 'posix' ...").

This stuff takes very little extra work. I mean, 99.9% of code is going to be inherently cross-platform anyway, until you start dealing with file paths and stuff like that. The payoff is that your code actually will be portable, and that has advantages too numerous to go into.

A final thought: isn't it about as basic as it gets that HTML should be developed on the same platform that it will ultimately be deployed upon? If you disagree with that statement for HTML, then you should disagree concerning programming in general for the same reasons.

Re:Almost..

[encoderer]

I ask you the same I asked downthread:

Do you not have a staging environment? Are you seriously taking code from your local box and deploying it to production machines without a staging environment?

Of course you don't need to be literally typing the code into a PC running the same OS/Stack as the production server. My production servers are mostly all Linux and I develop on an XP machine or my macbook.

But I'm not trying to RUN the code locally. I build the project to my staging sever to test. ...And as far as I'm concerned, this is a non-negotiable step and there's NO excuse to skip it. You don't need "new hardware." A VM Instance would work perfectly.

I worked for companies of all sizes, start-ups in 99/2000/2001, couple fourtune 500's, etc, and in 2003 I bootstrapped my own software company with a couple good friends. I've been a professional software developer for half my life.

Testing your software on its target platform before being deployed isn't an academic exercise as you eluded to w/ the "still in school." comment. There's a lot of academic theory that does not translate well to real world constraints. Methods with no more than 25 lines, single return points in functions, nearly everything involving UML, complete normalization, etc. But this isn't one of them.

Re:Almost..

[encoderer]

So you're developing on, say, XP, and deploying directly to the production server without ANY staging environment?

Seriously?

You just cross your fingers and hope everything works right?

If that's the case, you really must not be working on any high-availability systems.

Furthermore, your HTML comment was a little inane. HTML is not a programming language. It's not even, generally, procedural markup. It's descriptive markup. In other words: HTML has far more in common with a data format than a programming language.

Re:Almost..

[Just Some Guy]

So you're developing on, say, XP, and deploying directly to the production server without ANY staging environment?

Yep.

Seriously?

Yep.

You just cross your fingers and hope everything works right?

Nope. We've never had crossplatform code suddenly become not-crossplatform. Not once. Ever. Once a new module is vetted as working on each of the platforms it's ever going to run on, it just keeps running. Why shouldn't it?

That's not to say we don't ever accidentally push buggy code into production (although I'd like to think we're pretty good at not doing that), but those bugs are of the logic variety where we've made general mistakes that would affect the code no matter where it was running.

If that's the case, you really must not be working on any high-availability systems.

My boss seems to think so, and so far we've not proved him wrong. :-)

Furthermore, your HTML comment was a little inane. HTML is not a programming language. It's not even, generally, procedural markup. It's descriptive markup. In other words: HTML has far more in common with a data format than a programming language.

Analogy, meet encoderer. encoderer, Analogy. There! Now you're acquainted!

Re:Almost..

[encoderer]

"Once a new module is vetted"

So you're implying, then, that you ARE testing each "module" in a staging environment as its developed?

And, then, I assume that if/when that module is modified, it's retested, perhaps automatically, in a staging environment for "each of the platforms it's ever going to run on."

In other words, the code that's doing all the work actually is being tested in a staging environment.

And, as it sounds, you're doing more high-level work that uses these libraries and you're committing right from dev to production.

Even that would never fly if you worked for me -- nor just about anywhere else -- but you're representing yourself as "what? testing on a stage? No reason for THAT?" even though that's precisely what the developers of the modules have done for you.

"Analogy, meet encoderer. encoderer, Analogy."

Actually, you made a metaphor. Not an analogy. And it was a bad metaphor, because HTML is not code.

Re:Almost..

[cayenne8]

"Do you not have a staging environment? Are you seriously taking code from your local box and deploying it to production machines without a staging environment?"

I've seen it done quite often before....yes. Not always, not the best, but, yes, I've seen it done more than once, and on MAJOR big projects, major bucks involved, but, not always spent in the best way. Hey, I'm just contracted in....I do what they tell me and collect a check. Usually, they don't want my input or suggestions, as that that has been made long before I get there.

Clearly and expert consultant

[NetCow]

Well, at least the sample code has clearly been written by a PHP expert. For example, a newbie would write something like

function is_authorized() {
return isset($_SESSION['user']);
}

and get paid for just three measly lines of code.

Thank $deity Nathan A. Good (mail@nathanagood.com), Senior Information Engineer, Consultant stepped in and corrected this to

function is_authorized() {
if (isset($_SESSION['user'])) {
return true;
} else {
return false;
}
}

Go, consultant-written code, go!

Why PHP does NOT suck

[mcrbids]

I've worked with PHP professionally, building a healthy, heavily profitable, and rapidly growing company providing information management services to schools.

From the simple standpoint of "concept to implementation" - PHP ROCKS. It's very, very fast, requiring little in the way of "planning" and "structuring" while letting the features come out... FAST. It is, bar none, the best RAD environment I've yet worked with. Not that it's the best in every area, but that it clearly has the best balance between features and "gotchas". It has its weaknesses, such as lousy error reporting, but even that can be largely mitigated with a little intelligence in advance. But it really does have a number of key strengths that I leverage to the hilt:

1) Stability. It just doesn't die. Ever. I've never, ever, ever had a problem with PHP "not working". I don't troubleshoot it. It's there, it works, and I don't sweat it.

2) Scalability. It's "share nothing" approach makes clusting and random-host selection boil all the way down to a simple session manager. Having 1 or 10 application servers running side-by-side is almost trivial!

3) Code density = excellent! It's a fairly dense language, meaning that lots can get done in a few lines. Just for giggles, I've written a self-forking, multi-process daemon with a process manager and hundreds of managed children forks performing a deep-level network scan in like 50 lines!

4) Security. Yes, you heard me correctly. Although you can certainly use PHP "wrong", you can also use it "right". Once you do, you discover that PHP has a number of features that make things like SQL injection and shell parameter expansion a thing of the past. Really. Learn your tools!

5) Flexibility. You can run it as a module inside Apache. You can run it as a standalone executable. With tools like Ion Cube and PHP-GTK, you can create a cross-platform GUI application without revealing source.

6) Availability. Any $5/month web hosting company supports PHP, and there are many free ones, as well. You can download a CD, install Linux, and have PHP/Apache up and running in under 10 minutes. There are batrillzions of apps available A LA SourceForge for free. PHP is the most commonly available web development language. And, by no means is it a web-only development language!

Sorry you can't handle a few quirks in the function names. (so write out a file of wrapper functions - DUH!) Sorry that it's attempts to simplify variable management weren't perfect. Geez. Just code in c and be done with it, why don't you?

In short, PHP is everything that VB and .NET wished to be, only cross-platform. It's an excellent tool for developing information-processing applications, very, very rapidly. Yes, it has its weaknesses, and nobody's forcing you to use it, and the devs are working on the weaknesses, too. Go use Ruby if it makes you feel good. But PHP works well on Windows, Mac, Linux, BSD, and many others. Seriously: you really can't go too wrong betting on PHP unless you need 3D graphics!

Re:Why PHP does NOT suck

[Wiseman1024]

Do you know Python or Ruby? I cannot take your opinion seriously until you do.

Re:Why PHP does NOT suck

[Anonymous Coward]

I have long stopped working as a web developer, but I find that PHP is also great as a command line language. I use it almost exclusively. Perl is needlessly more complicated than PHP imho. There's really nothing I use Perl for anymore, unless there happens to be a cpan module that does what I need to do.

A lot of the crap that makes PHP suck as a web language (magic quotes, register_globals, etc.) doesn't apply at the command line anyway. The inconsistencies between, for example, function arguments is minor - most languages have their own annoyances.

For real software development, I don't know if I'd use PHP - but for small to medium scripting jobs I think it's quite good.

Re:Why PHP does NOT suck

[Anonymous Coward]

Do you use Front-Ahead Design? I am almost certain that you do.

http://thedailywtf.com/Articles/FrontAhead-Design.aspx

The options in any serious environment are Java (enterprise) and PHP (any small to medium size web development shop, or large if you know what you're doing). Immature fad languages have no place in a real company.

Re:Why PHP does NOT suck

[bigtrike]

I've used PHP for about 7 years now and I've had the entirely opposite experience.

1. Stability isn't that great. I've run into many glitches over the years and had my share of segmentation faults fixed. Ever run make test on a build? I've never once had PHP pass all of its own unit tests.

2. PHP is so inefficient with memory that anything but the most simple application can take tens to hundreds of megabytes. This isn't a huge deal though, because gigs of ram are pretty cheap these days.

3. PHP seems similar to most anything else, as a lot of the code space is taken up by comments. It seems to require more comments than most languages, as a lot of effort has to be taken to deal with quirks in automatic type conversion and the lack of a fixed point data type. (example: when the quoted string '1' is used as an array key, it's automatically converted numeric, but when the quoted string '1000000000' is used, its left as a string rather converted to a float).

4. This is only true as of PHP 5, because prior to the introduction of PDO there was no portable way to use parameters in queries. PDO creates its own set of headaches however, because it does not properly support many data types such as bool in all supported databases.

5. This flexibility has a lot of quirks. Certain functions behave differently on different platforms (strtothime handles dates prior to 1970 return different results on a redhat system than they do on a debian system due to different LIBC patch sets, although this may have been fixed in 5.2), some functions are only available.

6. My experience with cheap web hosts is limited so I can't comment here.

As far as the suggestion to simply use another language, it's unfortunately not an option.

Re:Why PHP does NOT suck

[Wiseman1024]

Please, don't make public your ignorance, even if you're an Anonymous Coward.

For starters, replying with a buzzword instead of a point, even if a satiric one, is often quite stupid.

Second, no. Starting with the interface is a terribly stupid thing to do. The people you claim to be doing this, i.e. those who come from languages such as Python, are exactly the ones who are polar opposites with this tendency, being much more prone to formal design and analysis as well as correctness before all in the best style from MIT.

Third, PHP is one of these newer languages. In fact, both Python and Ruby are older than PHP. And they are far more mature as languages, especially Python, but it's not just because of their age.

Fourth, Python will scale much better than PHP and Java will. PHP is grossly limited due to its lack of lexical scoping or namespaces, and Java has some issues which turn the whole thing into an ugly mess much sooner than it would on Python.

Fifth, "real companies" who follow "enterprise scalable professional multi-tier best-practices for mission-critical enterprise-grade XML-based turnkey business applications that optimize cash flows and provide for lower TCO" are the ones failing it every time, producing butt ugly lumps of unmaintainable, horrendous code for as much as 20 times the cost of smarter development with much fewer, smarter developers using a smarter, better featured language. Productivity of dynamic, functional and truly object-oriented languages such as Smalltalk, Ruby or Python ranges from 5 to 30 times higher than Java (counting each environment's standard libraries as well), also increasing maintainability, and reusability is much higher because they have proper type systems.

You seem to be utterly ignorant about the features of these languages, and think the only thing you know is the only good way to do things, just because most companies are ran by retards who are as ignorant as you.

We'll talk about PHP and Java the day you can do this with them:

sorted(((i, j) for i in xrange(1, 21) for j in xrange(1, 21) if i % j and j i), key=lambda x: -x[1])

That single Python one-line expression going to be some 30-40 lines of Java, and perhaps some 10-20 lines of PHP.

It obtains (lazily evaluating if possible) a sequence of couples of numbers i and j, for all i so that 1 = i 21, for all j so that 1 = j 21, if j is not a divisor of i and it's strictly lesser than i, then sorts it given a key function, passed by a named parameter, which is a lambda-expression (anonymous closure) defined inline for a one-time use.

It exhibits an amusing number of features Java and even PHP lack. Look, no stupid new classes, no stupid interfaces to inherit, no stupid factory classes, no "design pattern" wankery, no error-prone imperative programming, no error-prone effects, and takes no effort to write. It only requires knowledge, which you obviously lack.

tl;dr version: read/watch SICP and STFU.

Re:Why PHP does NOT suck

[Wiseman1024]

Oh, my less-than signs were screwed up. Let me redo the last part of the post:

sorted(((i, j) for i in xrange(1, 21) for j in xrange(1, 21) if i % j and j < i), key=lambda x: -x[1])

That single Python one-line expression going to be some 30-40 lines of Java, and perhaps some 10-20 lines of PHP.

It obtains (lazily evaluating if possible) a sequence of couples of numbers i and j, for all i so that 1 <= i < 21, for all j so that 1 <= j < 21, if j is not a divisor of i and it's strictly lesser than i, then sorts it given a key function, passed by a named parameter, which is a lambda-expression (anonymous closure) defined inline for a one-time use.

It exhibits an amusing number of features Java and even PHP lack. Look, no stupid new classes, no stupid interfaces to inherit, no stupid factory classes, no "design pattern" wankery, no error-prone imperative programming, no error-prone effects, and takes no effort to write. It only requires knowledge, which you obviously lack.

tl;dr version: read/watch SICP and STFU.

Re:Why PHP does NOT suck

[rtconner]

Also, it's really easy to learn (training new employees in PHP is much easier than trying to get them to learn Python or Ruby)

.... now dangit PHP where are my named parameters?

Re:Why PHP does NOT suck

[Anonymous Coward]

"But PHP works well on Windows, Mac, Linux, BSD, and many others. Seriously: you really can't go too wrong betting on PHP unless you need 3D graphics!"

hear, hear!! I recently wrote a PHP application using Apache/MySQL as the server platform. Half way through the project, they decided to switch to IIS/MSSQL, the only thing I had to change was the function calls in my DB Object, from e.g. - mysql_query to mssql_query, and addslashes to str_replace...took all of 2 minutes to do. If they had stayed with MySQL, I wouldn't have had to change a thing.

I loaded it up on the IIS machine and it.. just.. worked... period.

Re:Why PHP does NOT suck

[mcrbids]

Front-Ahead Design? Pretty damned funny, if you ask me. I've been lurking at TheDailyWTF for years, but I don't remember seeing this one before! (BTW: What's with that guy's fascination with renaming his website? Why doesn't he like the success of TheDailyWTF.com?)

But it sounds like a satire of what we actually do, namely, a variation of Agile Software development. Our application is very structured and layered, with strong database abstraction, SQL-injection protection using prepared statements, abstracted management of security, output templates, etc.

But even with that overhead, PHP allows us to get started and simply make it work, rather than waste time on type checking, memory manglement, garbage collection, variable definition, etc.

It's so quick!

Re:Why PHP does NOT suck

[tholomyes]

Actually, all that I've read on mod_php indicates that it scales linearly with Apache (which scales pretty damn well). In any case, it's always about using the best tool for the job. PHP has great strengths in general string manipulation, an amazing little date/time conversion library, and solid session and database support. That encompasses a lot of what web apps need without any design pattern wankery.

Re:Why PHP does NOT suck

[Anonymous Coward]

In short, PHP is everything that VB and .NET wished to be, only cross-platform.

If that's so, where are PHP's equivalents of WCF and WPF?

Maybe for small web apps PHP is thier equal, but that's hardly everything.

Re:Why PHP does NOT suck

[Wiseman1024]

We weren't (or at least I wasn't) talking about performance scaling, but about coding scaling. How does it get when the project keeps growing up. PHP has a problem, because all functions and all classes and all globals share unique, global namespaces, so clashing gets far more likely, you need ugly prefixing, you don't have hierarchical namespaces for variables, classes and functions, can't define a class as a property of a class (which would have provided a workaround), and so on.

I agree that PHP has strengths in string manipulation, but have you seen Python's? It has Perl-compatible regular expressions as well, but much better built-in string handling, and better Unicode support. For example, slicing (which you currently can't do in PHP if you want Unicode support): you can do things such as 'hello Slashdot'[2:-4:2], which illustrates several things PHP cannot do: slice an expression (lame), slice a chunk (not just a single item), step slide. Strings are sequences, so operations such as filter(lambda x: x in 'aeiou', 'vowels only, please') are possible (it returns 'oeoeae', the vowels fom that string). As you can see, Python's string manipulation is terrific.

IMO, date and time functions from the standard library suck in both PHP and Python; PHP's and Python's time are based on the C library (insta-fail), and Python's newer one looks incomplete and complicated to me.

Session support in PHP is great, though many Python frameworks do the same for you.

Database support in PHP, prior to PDO, was wide but sucky, requiring a DB abstraction layer because they language didn't provide one. Python provides one, albeit a flawed one because the variable mark in SQL is allowed to differ (astonishingly stupid decision coming from the Python community, quite unusual).

You can work in Python without any of the design pattern wankery either; in fact, Python is able to generalize and abstract patterns of code better than PHP does (and immensely better than Java). The idea is that the "ABC" design pattern shouldn't be about copypasting chunks code and changing variable names as they do in Java; it should be about calling a function or macro ABC that will do what's needed (generate the required classes or functions, modify existing ones, whatever). Python's support for metaprogramming is far beyond that of PHP (and Java's is null, and before Java people reply: no, their ugly hack for better typing which they call something like generic programming is not metaprogramming, not what I'm talking about).

PHP is a good tool for small to medium web applications, and an excellent tool for quick web hacks. Python is a much worse tool for quick web hacks, but, in my opinion, an even better tool for small to medium web applications. (And Java is an excellent tool for selling crap for buckets of money to idios, for ensuring you'll have work for years, and for ENTERPRISE SCALABLE PROFESSIONAL BUSINESS SOLUTIONS, but a sub-par tool for getting anything done, small or large.)

Re:Why PHP does NOT suck

[Anonymous Coward]

"Seriously: you really can't go too wrong betting on PHP unless you need 3D graphics!"

Maybe for PHP7?

Careful with the lamers!

[porneL]

echo htmlspecialchars($_GET['ekhm!']);

Re:Stop calling it PHP

[Frekko]

This is complete rubbish. Changing major versions often notifies of backwards incompatibility. Examples:
qt1 -> qt2 -> qt3 -> qt4
gtk1 -> gtk2
linux kernel v1 vs v2.

One can go on forever here...

safe mode hurray!

[remmelt]

Each time I read that they're ditching safe_mode, I do a little happy dance and shed a tear of delight.

All the other stuff is great as well, but safemode has made the quality of my life significantly worse in the past.

Web 2.0 builtins?

[chrysalis]

Sorry but... what are the "Web 2.0 builtins"? I saw none... or is it "goto"?

Re:Web 2.0 builtins?

[dave420]

IBM thinks SOAP is Web2.0. The fact anyone thinks anything is Web2.0 is beyond me. I feel dirty for writing Web2.0. Ugh.

I'm torn

[sherriw]

As an experienced PHP developer, who has many websites that I take care of - some of them are ecom sites I manage for relatives- but I didn't write them... this news is kind of a two edged sword for me.

While I'm glad to see some of the more blatant security problems being closed up, and the things that encourage sloppy programming being removed.... I'm not excited about having to go through many hundreds of files of code written by OTHER people, to fix some of these things. Really, what's so wrong about the short php tags? *sigh*

I know it has to be done though. But I just finished cleaning up these sites for PHP5 and mySQL5. Yes, I'm wining.

From the "What Is Unicode" inset in TFA...

[Tetsujin]

"Unicode is an industry-standard set of characters, character encoding, and encoding methodologies primarily aimed at enabling i18n and localization (i10n)."

Ha ha... Everybody knows that i10n is shorthand for "intoxication", not "localization"...

Re:Stop calling it PHP

[Tetsujin]

This attitude - that new versions of the language should always support everything the old versions supported - only makes sense if you assume that the initial design was perfectly sound to begin with.

Had PHP4 been perfectly designed, and perfectly well-suited to what people are now using PHP for, there wouldn't be any need to change it at all. But PHP isn't perfect. They've found ways to make it better. They could fork off a new project containing those changes - but PHP6 is more like PHP5 than not - and if they had to fork off every time they changed things around they'd have a lot of extraneous extra names for basically the same thing.

Also consider - how much time and effort might they have to put in to augmenting PHP6 to be fully backward-compatible, and to maintain that awkwardness - even in the face of new features that may flat-out contradict older policies in the language? How much work would have to be wasted just to make PHP6 a better PHP4 than PHP4 is?

If you wrote your code for PHP4, just keep running it on PHP4 until you're ready to port it.

Don't underestimate the value of ease-of-use

[RexDevious]

There are a lot of valid points about the short comings of PHP, and how even it's design encourages bad programming practice. The same could be (and was) said about Basic, and Visual Basic (pre .net).

And while I certainly agree that there are "better" languages out there, the one area I strongly believe PHP excels in is ease of use. Why is that important, compared to things like elegance, speed, and security?

Well, because by the time need some of the things PHP lacks - you've already learned how to do quite a bit of programming and are well prepared to address it's short comings, or switch to a more appropriate language.

We *need* a language that can be picked up in a matter of hours to attract casual programmers. Not every program needs to be great, many just need barely work.

I teach "Introduction to PHP" at FIT, and the first thing I tell the students is that should not be such a course; because anyone who knows enough to have a need for PHP should also be comfortable enough to learn PHP through an online tutorial or book. But these students know barely anything - I have to teach them how to write HTML forms, and all about databases (including what databases are) before they can PHP to do any of the things they want it to do. It's only a four session class; but PHP is still easy enough that I can teach them everything they need to know to get started.

Most of them will use it to write little guest book type apps for their personal websites, that run slowly and have huge security holes. But they have neither the traffic to make performance an issue, nor valuable enough information to make hacking their sites remotely worth it. If they like doing that, they can either make use of pre-built PHP modules, or learn how to code things better. But they've started, and I believe that's a good thing.

Programmers used to bash Visual Basic all the time when I was coding in that, but it's tiny learning curve got an awful lot of companies started down the path of in house development that Visual C++ wouldn't have. And that created an awful lot of work for programmers.

It's great that Zend is addressing some of the PHP issues; but I'm glad they're not trying to turn it into Perl. We already have Perl, we don't need another.

Ereg vs. Preg

[ittybad]

I had heard that ereg has better portability. Why would they ax ereg?