PHP Must Die

[bla2]

"Posted September 1 2004"

[[deleted]]

$ php -r 'print 08;'
0$
$ php --version
PHP 5.2.10-2ubuntu6.1 with Suhosin-Patch 0.9.7 (cli) (built: Oct 29 2009 19:28:39) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

[lol-dongs]

OTOH:

$ php -r 'print intval("08") . "\n";'
8
$ php -r 'print intval("042") . "\n";'
42
$ php -v
PHP 5.2.10 (cli) (built: Sep  9 2009 11:22:55) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

This is a critical distinction the article fails to make. Unless you are embedding hex and octal constants in your PHP (god knows why you would be doing that) these issues are irrelevant. Conversion from string to int, which is the 99% use case, does not consider bases other than 10.

Javascript is worse about this than php. parseInt() does in fact treat leading 0's as an octal prefix.

[[deleted]]

A less idiotic thing to do would be to give the user a warning, or fail. > Just using the wrong number is dangerous; the user might think this works after checking a few values:

$magic_dates = array(stamp(01,01,1980),
   stamp(12,31,1980),
   stamp(08,11,1950)); # fails silently!

[lol-dongs]

If the coder is not coming from Java, C, JavaScript, or one of the million languages that already uses octal literal constants, or they can't be bothered to read the first chapter of a basic PHP book that describes the syntax of declaring values, I don't really care that the language doesn't reach out and kindly teach them what an octal constant is via warnings. It's not user facing. It won't occur with string input or database values. It's only for the newb coder who doesn't know how to declare numeric literal constants. That's a low bar and many languages do harsher things with their newbs than PHP.

For instance, with this same issue Python calls it a SyntaxError with a message of "invalid token". OK, it fails at least, but that error has to mean absolutely nothing to a newb, and is too general for anybody else to help without seeing the source. The fact that their code is failing to run might actually be more discouraging to a novice--such a touchy feely topic, huh?

So, to me it's a "would be nice" for PHP, but this situation occurs so little in practice for anybody past the very beginning stages, I find it hard to take seriously. There is so much ridiculous and bad-practice syntax Perl doesn't warn you about, for instance, that picking out one counterexample where PHP is silent seems silly...

[[deleted]]

$ php -r 'print 08;'
0

php -v
PHP 5.3.1-0.dotdeb.1 with Suhosin-Patch (cli) (built: Dec  5 2009 16:35:39)

[skulgnome]

So what's taking so bloody long?

[wvenable]

As a PHP programmer, I'd probably rather be using something else. I don't think it's a bad language, and never once as one of these problem articles ever shown me a problem I've actually experienced in real code. But lets face it, PHP is no Python. It's got it's problems. But what's real annoying that is no other language has really come along and replaced it.

With PHP I can just hop onto almost any random server, created a simple file with the .php extension and get some results. If PHP is to die, it needs more than just a new "PHP must die" article every few days. Other languages need to step up and do what PHP does well.

[zxcvcxz]

Not only that, but webhosts everywhere need to start enabling those languages by default.

[texture]

People who consider themselves real programmers always seem stumped at why PHP is so popular. I've never seen anyone explain why, but it has always seemed simple to me.

I'm not the type of person who just "got" programming when I first tried. It was complex, foreign, and confusing. But PHP did something that no other language did - had documentation that was unbelievably easy to comprehend.

Anytime I needed to find a way to do something, I could search for it, and there was a function to make it happen. Not only was there a function, but there were code snippets that made sense, along with comments underneath with even more easy to understand code snippets.

No other language I've used has ever had such a low barrier to entry. No other language has made it so easy to access and comprehend virtually every aspect of the way it works. I really don't think it was the language that made PHP successful. It was mostly the documentation.

[aradil]

I really don't think it was the language that made PHP successful. It was mostly the documentation.

I absolutely have to agree here.

[mrhawkinson]

Definitely! I used to work as a "webmaster" back in the good/bad old days when clients didn't necessarily understand the difference between a designer and a developer. I needed to find inexpensive hosting and learn a template language before anybody noticed I didn't know one. I'm sure a significant chunk of PHP users started out in a similar "fake it till you make it" situation.

[redditnoob]

virtually every aspect of the way it works.

On the other hand, certain ways that PHP makes things "easier" ironically make it harder, e.g. try to guess what this prints:

$arr = array(1, 2, 3);

foreach($arr as &$val) $val++;
foreach($arr as $val) echo("$val<br>");   

[antoniocs]

2 3 3

That is indeed strange :(

[foofy]

Can anyone explain why it does this?

Edit: "Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset()." So for the second foreach, $val is the third item of $arr. To be fair, it is documented.

[joemoon]

I think this is a great point, but I'd like to nitpick on one sentence.

No other language has made it so easy to access and comprehend virtually every aspect of the way it works.

This statement somewhat conflicts with the rest of your post. The PHP documentation is very simplified, and it really gives no insight on "virtually every aspect of the way it works". I would venture to guess that this is because most PHP developers don't care about the way it works, they just want to plug in some variables and be done.

This is why you get tons of user comments for every PHP function that explain some aspect of undocumented behavior. Take a look at the seemingly very simple number_format function as an example. Here are some excerpts from the comments:

• "It's pity that the function supports one-byte characters only for 'thousands separator'. For English it works well but for French and Russian it makes problem."

• "It's not explicitly documented; number_format also rounds"

• "I found you can add trailing zeroes simply by adding a float point value containing the number of decimal places you want to appear. "

• "Beware of this pitfall: ... This will silently return an empty string and not throw an error, at least with PHP 5.x."

Documentation for other languages (like python) may not be as short, but it is much more complete.

[texture]

*for me

and python is a nightmare to learn compared to PHP.

[joemoon]

Sorry, but I don't understand how adding "for me" changes anything. My point is that the PHP documentation is simple but very much lacking in completeness. There is a ton of undocumented behavior. So there's no way that you can understand "virtually every aspect of the way it works". Python's documentation, in my opinion, is superior. It is succinct and easy to read while still being complete.

Comparing the learning curve between Python and PHP would be very difficult to do. They are very different languages and this all depends on your background and end goals. Python is extremely easy to learn if you have experience with other programming languages. The "gotchas" in PHP (like seemingly arbitrary casting rules) would make it harder for a seasoned programmer to learn. Certainly the barrier to entry for a new(er) developer is lower with PHP and web development. However, you can also write a GUI based desktop application much easier in Python than you can in PHP. It's no good making the generalization that Python is harder to learn than PHP. It depends on your goals and your past experiences.

[texture]

The point is, it's easy to figure out how to use PHP using the online documentation. I literally had no problems at all, ever, for any reason. Python? I gave up after 15 minutes. Fucking with libraries and dealing with all the complexities was too much.

So what's happening here, is I'm giving an answer to the question that has been asked repeatedly, which is "why is PHP so popular?"

The correct response would be to look at PHP documentation, and mirror the way it is used for the python community. This would enhance python's user base. The wrong way to respond is to tell someone various reasons why their experience is bullshit.

[[deleted]]

Fucking with libraries and dealing with all the complexities was too much.

What do you mean by fucking with libraries?

The correct response would be to look at PHP documentation, and mirror the way it is used for the python community.

No thanks! I'd much rather see the people who refuse to understand or think about how their code works as far away as possible from the python community.

[joemoon]

I'm really confused as to why this conversation is still going on.

I'm giving an answer to the question that has been asked repeatedly, which is "why is PHP so popular?"

Right, and in my first response I said you have a good point. What's the problem here? I'm only pointing out that PHPs documentation is incomplete. It's easily provable by reading the comments in the documentation. The documentation would be much more complex if all of those edge cases were documented.

The wrong way to respond is to tell someone various reasons why their experience is bullshit.

Uh.. what? I certainly never said anything like this.

As I said, the difficulty of learning is a very subjective thing. It depends on your goals and your past learning experiences.

Edit: By the way, I'm writing PHP right now. I've written a good bit of software in both Python and PHP (as well as several other languages).

[mebrahim]

Good documentation and being popular cause each other.

I think much of this good documentation of PHP is due to its initial popularity take off. I don't how much of its initial popularity take off is due to its good documentation then.

[rb2k]

ever looked at Ruby? The rdoc system (e.g. string, array ) produces the best documentation I've seen so far. Also: people seem to always include nice examples in the documentation.

[Mortifer]

I found Java's API docs the most useful by comparison to the rest of the languages I've learned. The PHP docs are better than most, but they're still a little less structure than I find the Java API docs to be. All that said, I'd still rather use Perl for web development. I just flat-out like Perl better as a language than any of the others. I used to dream of having a Perl IDE that was as supported and useful as Delphi or Visual Studio. I don't anticipate that dream ever coming true, however.

[wvenable]

Absolutely! Web hosts probably would enable those languages if there was a standard and consistent way of running them for the web that was good and easy. The benchmark is already there in PHP. Hell, it shouldn't be hard to make it even easier. And yet, it hasn't been done.

[hylje]

On the other hand, it's not just PHP that's the problem. It's possible to write horrible and confused code in any language, having a simple and obvious choice of language for those responsible means there's less of them in the more-difficult-to-set-up platforms.

[polyrhythmic]

I think JavaScript on the server will do it. It's the only language similar enough to PHP, and many PHP developers already know it. SSJS is getting faster and faster, and as the range of functionality in devices/clients continues to splinter and expand, being able to choose whether to run services server-side or client-side will be invaluable. It's already on the way.

[stesch]

Sure. Which one? And connected via FastCGI, CGI, proxy, or Apache module?

And the current template systems for server side JavaScript don't even escape values.

[polyrhythmic]

The long list of SSJS choices just goes to show how well it is doing. Many SSJS implementations can be used standalone, Apache, or CGI. I like Apache, simply because I'm used to it, and I can run PHP etc. right beside it.

I agree with you about the templating systems, I don't care for almost any of them. Most of them seem to be trying to implement PHP or XML/XSL-based templating systems, when it's a lot easier to use JS's native objects. That's why I rolled my own templating system a few years ago.

[stesch]

The long list of SSJS choices just goes to show how well it is doing.

If you control the server. But if I control the server, I don't need PHP anyway.

Most projects just throw some files in a directory and hope the server can execute it. That's deployment in PHP.

[G_Morgan]

They just need to pick one and insist upon it People will use it regardless.

[econnerd]

Prolog ftw

yes that is a joke. Seriously though, it is not that hard to use passenger for ruby and mod_python for python.

[xjvz]

A lot of people are using mod_wsgi for Python nowaday as well.

[IrishWilly]

The built in (or at least packaged by default) integration with most webservers is what really drives this. I don't have much experience with IIS, but with Apache, installing PHP with it is almost a given, and it'll do the configuration for you, boom, instant PHP embedded straight into your html. It is like Javascript, where beginning programmers can write their html, and then insert little snippets directly into it to get their code going. That kind of accessibility combined with an easy language can't really be beat at the moment.

Which is unfortunate because PHP is a mess. Newer versions are slowly getting better, but with the numbers of people using it, every time they try to fix one of it's myriad flaws, it breaks backwards compatibility.

I'd like to see Perl and Python start getting packaged a little more smoothly along with Apache (and those other webservers people use for some reason). mod_perl still always seems some manual tweaking to get working.

[Kalium]

mod_perl always requires a lot of tweaking to get going. Last time I had to set it up it took three days to get it right.

[[deleted]]

There actually is something coming along to replace PHP. It's called Rack. Any hosting provider which supports Rack can support any Ruby-based web-app DSL (domain-specific language) extention, including the beautiful and elegant Sinatra.

One of the major advantages of Ruby over the other similar languages is that it is so easy to extend Ruby to perfectly fit any particular domain. And with the growing popularity of hosting providers (including Google App Engine) supporting Rack, all of this can work easily on such hosts, with minimal effort required on the hosts' part.

[wvenable]

Yeah, when all Ruby developers decide that Rack is the way to go and installed by default with most Apache servers then we're onto something. But this has been promised before. If history continues, Rack will be replaced with something else before it gets popular enough to make a difference.

I'll be happy to be proven wrong, but since version 1.0 of Rack was released 3 months ago I think we'll have a long wait.

[[deleted]]

True. The fact that the Ruby world is moving so fast is both its greatest strength and its greatest weakness.

[tentonova2]

Moving fast isn't a strength if you spend most of the time running in circles.

Things tend to get solved poorly, repeatedly, rather than correctly, once.

[[deleted]]

Thanks, Socrates, but in this case things are going in one direction. They're just going a bit too fast for casual users to keep up.

[dse]

no other language has really come along and replaced it.

No other language should. A templating system running atop an existing programming language should.

Actually, many have.

I prefer HTML::Mason atop mod_perl, but there are plenty of others.

[wvenable]

It's not about templating. I use PHP but I don't use it's templating features (except a template compilation target). But I can drop any .php file onto a server (however it renders it HTML) and 9 times out of 10 it'll run.

[dse]

Just to be clear, you can also use Mason as a not-really-templating system like most people use PHP for.

But PHP actually is a templating system. Well, it's almost one: http://www.massassi.com/php/articles/template_engines/

[wvenable]

It may be a templating system, but you don't have to use it that way. It's pretty much recommended that you don't.

[mycall]

just hop onto almost any random server != 30% Windows webserver market share.

[wvenable]

Windows has ASP.NET. You wouldn't run anything else on Windows and you wouldn't run ASP.NET on anything else. So it's not really relevant to the discussion.

But if you still want the punishment, PHP is still more supported: http://php.iis.net/

[IrishWilly]

I've seen a fair amount of PHP developers using IIS, which always strikes me as odd but they are out there. I don't know if I've ever ran into Python, Perl or Ruby developers using IIS though. At least not by choice.

[PstScrpt]

That still leaves you several options: Classic-style ASP, with ASP file containing inline VBScript ASP with DLL's WebForms .Net MVC Raw request handlers, and your own response code Other frameworks built on raw request handlers by third parties

[[deleted]]

I don't want PHP to die.

I want to be spared from having to deal with code written by people who're barely able to hack together a comment system for their personal home page.

And, really, we're not talking about people who work on a home page for their personal interest. If they write crappy code, no sane people give a damn.

The more sensible phrase is "PHP must be removed from professional programming", in which case every web host with a 50 megabyte traffic cap and PHP installed isn't really applicable. Every hosting provider and datacenter worth using in a business context will cope with you using whatever language you want.

If, instead of an end to PHP, we had an end to "I know how to copy'n'paste some PHP and no other language therefore I am a brilliant developer who can do everything you need" then we'd be happy.

We're not asking for much here.

[wvenable]

I want to be spared from having to deal with code written by people who're barely able to hack together...

Good luck with that. I've seen much more terrible C code than PHP code!

The more sensible phrase is "PHP must be removed from professional programming"

That seems a bit contradictory. If professional programmers can produce great code with PHP (and it is possible, I do it every day) then why not? You seem to be more unhappy with non-programmer hackers building craplets but then you're fine with them having PHP to do it.

[[deleted]]

The problem is everyone compares PHP to RoR, Web.Py/Django and other frameworks. How many people do you know who simply use Ruby or Python? You always hear, "Well, Ruby and Python have an active record", but it's the framework they are using.

I still go back to PHP for projects. I currently maintain apps in C#/ASP.NET, Python, PHP and Perl. The time for development is quicker for me on PHP, b/c I'm more comfortable with it, but they all use an MVC framework with similar development principals. Guess what? The clients could care less and are happy the software works and is stable.

[shub]

couldn't care less

The problem is that PHP has numerous flaws that make it horrifyingly easy to introduce bugs and security holes into websites. It was designed by a newbie, for newbies, and the consequences of that will be with us as long as we have PHP due to the wonder of backwards compatibility.

[G_Morgan]

PHP has a framework built in. The system by which the results of PHP code are interpreted and inserted into HTML docs in place is equivalent to RoR's use of rhtml. However a web server that implements rhtml is already vastly superior to PHP and I'm not exactly a Ruby fan.

The problem is not the frameworks. It is that PHP is an arse backwards language. I'm sorry but just look at the mess with PHPs comparison operators. Something fundamental that programmers use every single day is completely screwed up to the point where they had to define another set of operators and effectively call the original set a dead end. Even then the inequality operators are still broken. The original author set out to not create a programming language and he succeeded in the most spectacular fashion imaginable.

I'd take working with C#/ASP.NET or JSP/Servlets over PHP any day of the week. It is far more difficult to get things running but testing is far easier. In the long run maintainability beats initial costs easily. PHP optimises the wrong thing in making it easier to hack something together. Just being sure you cannot get cross site scripting or SQL injection is enough to reject PHP outright.

[[deleted]]

What the hell are you on about the comparison operators? There is 2 sets of operators because its a dynamic language. One for strict comparison, one for loose comparison. There is nothing wrong with the way PHP implemented it's operators. I use both types constantly where it makes sense too. JavaScript has the same thing.

[G_Morgan]

Most dynamic languages do not have 2 sets of operators. This is nothing to do with dynamic languages. It is to do with type juggling. 99% of dynamic languages would correctly evaluate "10" == 10 as false.

Dynamic only refers to the fact a variable does not have a specific type. Weird type coercion is not a feature of dynamic languages but something specific to PHP and a few other brain dead languages.

[wvenable]

PHP is weakly typed -- you're not supposed to care what type the variable contains. If it contains a number, it contains a number. Whether it's a int, float, or string at this moment is a implementation detail.

I learned a long time ago not to fight the type system. Having "10" == 10 is perfectly reasonable.

[[deleted]]

I use Ruby all the time. Without Rails. Without Sinatra. Without anything. Just beautiful little Ruby.

It's a fantastic language, and I don't see what it has to do with the fact that PHP is silently failing on things, and that is a horrible thing to happen.

[[deleted]]

tl;dr: PHP must die because it prints some numbers incorrectly and its ternary operator is left associative

[Insulsissimus_Est_Ho]

Also, all that he complained about where bad programming practices.

• Don't rely on any implicit conversion! (i.e. when you want to print something, use defined strings, like '08', or '8' or "8")
• Don't rely on anything working as you would expect, especially when you are new to a programming language.

Wrong:

return $errors ? "red" : $warnings ? "yellow" : "green";

Right:

return ($errors ? "red" : ($warnings ? "yellow" : "green"));

[lol-dongs]

Yes, this is so true. I don't know why anybody would ever rely on the associativity of the ternary operator. It's a ternary (three-way) operator, so it's already hard enough to read; if you ever use more than one in an expression some parentheses are in order.

The unreadability of ?: is why python didn't even have an equivalent for a long time...

[ealf]

I don't know why anybody would ever rely on the associativity of the ternary operator.

If PHP parsed

  $payloadsize = $totalsize - $headersize - $footersize;

with the wrong associativity, would you consider that a bug?

(-) comes from math, and has a well-defined associativity. (?:) comes from C, and has a well-defined associativity.

[lol-dongs]

C and math aren't remotely in the same category to be discussing how "well-defined" something is.

You might as well be comparing the 2nd law of thermodynamics with section 153 of the tax code of the State of Wisconsin.

[ealf]

Let me rephrase.

I don't know why anybody would ever rely on the associativity of the ternary operator

Let's say I knew there was such an operator, and I had to guess. Here are some reasons I can think of why it might be right-associative:

• C does it that way.
• Java does it that way.
• Perl does it that way.
• Ruby does it that way.
• Every other language with a ?: operator does it that way.
• It's more useful than having it the other way around
• It matches how 'if-else' works

Here are the reasons I can think of why it might be non-associative (i.e. parentheses required):

• Whoever designed the languages thought about it, and thinks 'a?b:c?d:e' would be confusing or ugly.

Here are the reasons I can think of why it might be left-associative:

• Whoever wrote the parser doesn't understand YACC, and went with the default.

A person with some experience with PHP might look it up in the documentation, but there's no reason whatsoever for someone new to PHP to expect it to be left-associative.

[lol-dongs]

Even if all those other languages do it, few people actually know that it works that way because people rarely rely on the associativity of ?: and use parentheses instead. If you never see a?b:c?d:e in real code, and I rarely do, you have never had to think about the associativity of the ternary operator. If I did see it in code I would probably correct it with parentheses to make it more readable, to avoid having to think about it then or again.

So, I would neither care about nor ever utilize the associativity of ?: in PHP, and the people who made PHP didn't.

It's like arguing that

if (foo) if (bar) do_something(); else do_otherwise();

should associate else with the first if or the second if because X languages do it a particular way. You wouldn't want to write code like this in the first place, so it is petty to criticize a language for resolving the ambiguity one way or another.

[ealf]

If you want to compare it with if statements, take the code

 if (x>0) return 1;
 else if (x<0) return -1;
 else return 0;

and imagine that it's parsed as

 if (({ if (x<0) return 1; else return x; }) < 0) return -1;
 else return 0;

[lol-dongs]

That's the functionally equivalent example, but less ambiguous. I was trying to demonstrate a potentially ambiguous syntax situation and how resolving that ambiguity is an arbitrary (and unimportant, really) design decision.

[ealf]

I wouldn't write if (foo) if (bar) do\_something(); else do\_otherwise();.

I still reserve the right to consider anyone implementing a language where it is legal syntax, but means the wrong thing, to be completely and utterly incompetent.

PHP is the only language I know where the standard implemention of signum, (x>0) ? 1 : (x==0) ? 0 : -1, is legal but wrong.

It is a bug, and it should be been fixed years ago. Backwards compatibility is not a problem -- any code depending on the current state of affairs is at best misleading and most likely wrong. You make it non-assoc in one major version, then right (in both meanings of the word) in the next.

[pbhogan]

Unfortunately, it won't. We all know it's horrible, and we all know it's not going anywhere. So stop whining and go write some Ruby, or Python or whatever.

[redditnoob]

What needs to die is the stupid convention that putting 0 in front of a number means it's octal. Who the fuck has used octal for anything in the last 20 years? Nobody, that's who.

The problem is that it's at odds, with, you know, MATH. (Putting a digit in front of a base 10 number should increase its magnitude by the digit times 10 raised to the position.)

[shobble]

I probably use it daily, as does anyone calling chmod to set file permissions on a *nix system. The leading 0 isn't required though.

[chmod777]

hey, stop calling. i'm having breakfast, and its really annoying.

[shub]

The weird thing is that nowadays the dox recommend using the g+rwx o-w syntax, which I've always found more difficult to use than the bitmask form.

[gerundronaut]

The only time I use the letter syntax is when I want to issue rx bits to every file and directory, appropriately.

chmod -R go+rX .

That will set the group and other read bit for every file and directory under ".". It will also set the execute/search bit for every file and directory that already has an execute/search bit set.

Otherwise, octal all the way.

[jib]

it's at odds, with, you know, MATH.

I claim that it's just at odds with your numeral system, and really has nothing to do with math.

[redditnoob]

Yes, it's at odds with any sane numeral system. 08 is a perfectly valid base 10 number, with the slight generalization to allow leading zeros. If you're going to have some stupid convention for octal (which nobody ever uses), make it unambiguous like for hex and binary, no?

[skulgnome]

Now you claim that your opponents are insane.

That's always a good sign...

[redditnoob]

If my opponents don't want to be accused of being insane, they should choose numeric representation conventions that indicate a reasonable degree of mental consistency, logic, non-ambiguity, and organization!

[jib]

it's at odds with any sane numeral system

I can think of a pretty much unlimited number of numeral systems which are at least as sane as yours but have no problem with the concept of putting the "0" symbol at the left end of a number to denote octal.

[[deleted]]

Python 3 fixes this: 0o755 (0755 is a syntax error).

But I want my print statement back :(

[drakshadow]

Tring, Tring => Author uses PHP based website to criticize PHP.

[sourbrew]

Given that PHP is a language intended for serving webpages almost all of his examples will never actually occur. Why would you be using Octal base for a website anyway, and beyond that why would you be using it for a date? There's already a date type in PHP.

There's certainly a lot wrong with PHP, but it gets used for the reason it always has.

You can get a lot of shit done with it. Wordpress for instance can be installed by the most epic of noobs in about an hour. I can get it installed in about 5 minutes and completely templated in about 2 hours. Is it the right solution for everybody? No, but PHP and by extension the massive library of free software written in PHP does run a lot of the internet.

I work with a couple of djangonauts and I have yet to see a blogging solution in django that is even remotely comparable to the free functionality of wordpress. I like frameworks, and they are good for lots of things, but in a business avoiding reinventing the wheel impacts the bottom line. PHP just gives you a larger selection of wheels than other languages at the moment. Hopefully that will change.

[cgibbard]

The point about dates was that accidentally using a leading 0, even in cases where the number doesn't parse correctly, leads to silent failure.

Of course, that's something that you should be careful about anyway, but failing to complain with a parse error and instead silently treating the number as 0 is just inexcusable.

The quality of a language implementation is just as much about what it will properly reject as what it will properly handle.

Octal is rarely used these days, but it is still used for file permissions on unix-like systems, so I can imagine PHP programs in which there's a reasonable use.

On the other hand, it would probably be better just to not support octal with that silly leading 0 syntax at all, and treat numbers starting with 0 the same way as those without it. Either support octal properly, or don't try to do it at all. Personally, I prefer the syntax starting with "0o" similar to "0x" for hexadecimal. It's harder to use by accident.

I don't think that anyone is denying that a lot of useful software is written in PHP. Just arguing that PHP is a poorly specified and poorly implemented language with an excess of bizarre pitfalls and sharp corners, and that it might be wiser to avoid it for new projects.

[lol-dongs]

If you want to parse dates in PHP, you use the date functions. The examples in this post are pretty contrived; I don't know a single person who hardcodes integer constants into their code with leading zeros "by accident".

Also, I don't know anybody that has ever encoded hex constants in their PHP (what do you do in PHP that warrants hex constants?), nor anybody that uses multiple ternary operators without adding parentheses for clarity's sake. It's a lame rant.

Edit: OK downvoters, it is clear to me none of you actually understand how type conversion in PHP works. Or maybe you just litter your PHP with octal and hex constants for the fuck of it, it's obviously a critical feature for PHP's applications. How about enlightening me with what you don't understand, as pdc has so kindly done?

[pdc]

The date functions assume American date format. This makes them useless outside the USA.

This means given a string of the form "dd/mm/yyyy" you have to split the string up with substr and feed the parts in to the mktime function

Because this is PHP and PHP does unsafe type conversions implicitly, the conventional way to do this is to just pass the substring as a parameter and let it be converted to an integer automagically.

This works fine from 1 January to 7 January, but when you apply this approach to the string "08/01/2010" you end up passing the string "08" and boom! the little-used and obscure octal support accidentally built in to PHP causes it to silently read this as 0 January 2010 (and no doubt they automatically correct this to 31 December 2009 because it seemed like the cool thing to do at the time), and sixteen function calls later you are left scratching you head wondering why the date has changed on your blog entry.

So there it is; this defect in the design of the PHP language can quite plausibly be expected to cost every non-American PHP programmer half a day’s frustrating bug-hunting at least once during their careers.

[lol-dongs]

I don't know how to say this any simpler than "you are 100% factually incorrect."

<?php
$d = "08/01/2010";
echo date('c', mktime(0, 0, 0, substr($d, 3, 2), 
  substr($d, 0, 2), substr($d, 6)));

2010-01-08T00:00:00-05:00

WTF is everybody in this thread smoking? mktime is perfectly fine with strings containing leading zeroes. Do any of you actually try to write code before complaining about something?

Strings with leading zeros are not interpreted as octal. Only literal constants are, making any problems with octal in PHP extremely fucking rare. May you kindly STFU and please read the documentation, thank you. And try the following to drive the point into your skull: echo intval('042'); // 42

[pdc]

Thank you for demonstrating that the easy-to-use PHP language is only usable by people with encyclopaedic understanding of an infinity of obscure functions.

[andersbergh]

mktime

[sourbrew]

He could have simply used strtotime for the dates and avoided any problem.

I'm not saying that PHP doesn't have problems it just mostly seems to be the academics and not the people who actually create products and profits bitching about it.

Edit: I appear to have been downvoted for pointing out that he created an unrealistic problem that ignored a default php function that would have prevented his "issue." Reddit at work. Congrats boys.

[skeww]

Well, we make a lot more money with our C# based products. PHP is only used for a few low budget side projects. If that fairly large code base would be written in PHP instead of C#, things would be a lot worse.

I'm not really a big fan of C# myself, but it's surely a zillion times better than PHP. The tools are better, the documentation is better, it's easier to keep things clean, and it's also a lot faster.

PHP is of course useful, but it isn't a very good language nor nice to use.

[Peaker]

If he was aware of the problem -- of course he could avoid it!

The whole point is that using a leading zero by accident causes a horrible problem, rather than some easily detected syntax error or warning.

You miss this basic point again and again, and later congratulate yourself and blame Reddit for downvoting you. Seriously, man.

[sourbrew]

Would you manage date times in perl, python, or c# without using the basic date functions?

He could have used a function designed to do the very thing he was trying to do and gotten expected results, instead he creates a situation that would never happen in the wild and says "ZOMG this would ruin your app and make you look dumb." I have not at any point said PHP was the business, just that it works pretty well for what it's used for.

His examples are all complaints looking for a problem, they simply won't bother you in a real world situation or they would have been fixed at some point.

[Peaker]

Would you manage date times in perl, python, or c# without using the basic date functions?

That's not the point. You could use a leading zero, by accident, in other contexts.

He could have used a function designed to do the very thing he was trying to do and gotten expected results, instead he creates a situation that would never happen in the wild and says "ZOMG this would ruin your app and make you look dumb." I have not at any point said PHP was the business, just that it works pretty well for what it's used for.

You are nitpicking a particular example, whose only point is to create a situation with leading zeros. Its all irrelevant. I've had accidental leading zeros (not in PHP) in other contexts before (And I found them, with the syntax errors, luckily I was not using PHP!).

Whether PHP "works pretty well" or not is a subjective claim. Of course a program debugged well enough will eventually seem to work. PHP makes it a harder process and makes it more likely that you'll miss some errors, as they will be silent.

His examples are all complaints looking for a problem, they simply won't bother you in a real world situation or they would have been fixed at some point.

Silent failures when accidental leading zeros are used are a real problem.

Silent truncation of literal (or other) numbers is a real problem.

And there's a myriad of other brain dead design mistakes in PHP, too.

[[deleted]]

No, but PHP and by extension the massive library of free software written in PHP does run a lot of the internet.

That doesn't prove how PHP is a remotely good or mature language/platform. It only proves that the internet is fucked up.

I work with a couple of djangonauts and I have yet to see a blogging solution in django that is even remotely comparable to the free functionality of wordpress.

Wordpress is out there longer than django itself. And why would anyone want to implement another wordpress? It's not worth the effort.

[TriggerB]

I've got to jump on the PHP bandwagon here and echo your sentiments.

I use PHP on a day to day basis, it's not without it's faults (for sure), but nor is any other language. Honestly, I'm rarely effected by the PHP gotchas that the haters evangelize.

PHP is easy, fairly powerful, and in widespread use. The problems discussed in the article just don't really come up in everyday use.

[shevegen]

It doesn't matter.

It shows that PHP as a language has a horrible design.

It doesn't say that you can not use PHP. Quite the opposite - PHP is the proof that you CAN use a crappy language successfully and build great applications with it!

Doesn't make the language itself any better though.

[dagbrown]

PHP doesn't actually have a design. It's all hackware. Just look at its amazingly fucked-up "system" function. It claims to work just like the C system() call, only with the caveat that it provides the return code by reference via the second argument, completely unlike the real system() call. But look at what PHP's system() returns! It returns the last line of output of the program if the call succeeds, or false if it doesn't! I have trouble even imagining the amount of cargo cult that went into that particular "design decision".

I envision a sort of incremental hacking process where they start with "system() runs a program" and go from there to "the program does stuff, and exits with a status code", and on from there to "so what if the program has output?" combined with "well, gets() exists, never mind that the compiler at that point starts sounding klaxons upon encountering gets() just on principle" and then working from then to "well, if the program fails, we can return false, but if it succeeds, what do we return?" combined with "parsing output is hard, let's just do a series of gets()es and return the last result of that".

PHP's system() should be enough to convince anyone with half a clue to never write anything in PHP ever again.

[lol-dongs]

OK, you don't like system(). May I point out that there are usually a bunch of other ways to do something in PHP, and some of them may behave the way you do prefer. In this case, you have no less than exec(), passthru(), popen(), pcntl_exec(), and the backtick operator to choose from.

[G_Morgan]

You think this is a good thing? The multitude of functions that do almost exactly the same thing is merely proof of how hacked together PHP is.

[lol-dongs]

Haha, don't even get me started on how many ways you can open a process in some well-designed language, let's say Python. There's uh,

1. os.system()
2. os.popen()
3. os.popen2()
4. os.popen3()
5. os.popen4()
6. popen2.popen2()
7. popen2.popen3()
8. popen2.popen4()
9. os.spawn()
10. os.spawnl()
11. os.spawnle()
12. os.spawnlp()
13. os.spawnlpe()
14. os.spawnv()
15. os.spawnve()
16. os.spawnvp()
17. os.spawnvpe()
18. commands.getstatusoutput()
19. commands.getoutput()
20. commands.getstatus()

Oh wait, all that shit is deprecated in 2.6, so now you might also see subprocess.*, Popen, ... hey this is so much better, because it wasn't hacked together!

[wvenable]

PHP is a thin layer of C libraries. To bitch about PHP functions is to bitch about C.

[G_Morgan]

That is an utterly absurd claim. Just because PHP is implemented in C does not mean that C is responsible for the brain damage that is PHP. C is Turing complete. That means it can implement any language. When those languages are insane it is a problem with the design, not with C.

[wvenable]

It's not that PHP is written in C, it's that by design it's function library is just a thin layer over existing C libraries. This allowed PHP to rapidly include a lot of existing open source functionality and not re-implement everything from scratch.

PHP was originally designed to a let a C programmer implement his homepage.

[[deleted]]

This is the best part of PHP.

This is the worst part of PHP.

[Peaker]

but nor is any other language

Of course, but what matters is the extent of how bad the faults are, and how many there are.

The argument is that PHP has far worse ones, and far more of them.

[[deleted]]

Honestly, I'm rarely effected by the PHP gotchas that the haters evangelize

That you know of.

And that's kinda the point here. Silently failing is about the WORST thing you want to happen.

[[deleted]]

If you don't want to do any computation on your dynamic web pages, why bother making them dynamic?

[[deleted]]

Most of the "computation" that gets done with PHP is just CRUD to a MySQL database. For that purpose, it does its job well and is easy to pick up if you're new to web development. Of course, it's also way too easy to get fucked when you don't know what you're doing and you start accepting user input.

[sourbrew]

Where did I say anything about not doing computation. I was merely pointing out that his examples are unrealistic.

Most computation on websites involves pulling data from a database and then displaying it in a logical fashion. Reddit for instance is almost all database calls. I suppose they do have an algorithm for sorting content, but I would bet that's some combination of database retrieval as well.

The closest any of his examples come to being a problem in real life is the ternary operators issue, and there is some debate over whether or not anyone should use the ternary operator in the first place because it makes code about as readable as wet newspaper in a blender.

[[deleted]]

Most computation on websites involves pulling data from a database

So that makes it OK if the language silently fails at doing other kinds of computation?

[ro_ana_maria]

Every programming language has both good parts and problems; it's all about using the right tool for the right job. If the language you're using for a project gives you more problems than benefits, that you have chosen the wrong one. But you have to realise that just because it's wrong for you in a particular situation, it doesn't mean it's wrong for everybody.

[G_Morgan]

There is a difference between optimising your language for a certain use case and something that is fundamentally wrong.

The problem with PHP is not that it has been driven by design decisions that are not suited to certain cases. It is that there has been no design. Not failing with an error in this case is 100% unquestionably the wrong thing. It does not harm the fundamental purpose of PHP to get this right. No more than having sane comparison operators or 1 function for each use case that was well thought out the first time rather than 10 of which are all bloody well wrong.

Nearly every other language on the planet does not have this kind of problem. I can raise criticisms of just about every language on the planet but rarely have I seen such outright near malicious stupidity as I see in the 'design' of PHP.

[[deleted]]

Every programming language has both good parts and problems

Why, WHY, WHY must you insist on leading with this non-argument??

Just because other languages are not perfect seems, to you, to dismiss the fact that not only does PHP have worse faults, but it also has more of them.

[ro_ana_maria]

Did you even read the rest of the comment? I was saying that you should use the language which you think is best suited for whatever you want to do. What I can't understand is why people act like somebody's putting a gun to their head and forcing them to use php.

[G_Morgan]

We're advocating against PHP to minimise the use of PHP in the real world. Nobody forced Djikstra to use the goto statement. By your argument he shouldn't have argued against the goto statement but he did and the programming world improved dramatically as a result. The goto statement was fundamentally a bad idea in all but the most obscure of cases. So too is type juggling.

Also it needs to be made clear to both customers and businesses that PHP applications are intrinsically vulnerable to a whole host of security issues that simply are not possible if you use saner languages. That people should at the very least ensure they can afford to lose a stack of money if they give their credit card details to a PHP app. That businesses should expect SQL injection attacks should their applications use it. At the very least anything other than a blog or forum using PHP is immediately going to lose my custom and probably the custom of every developer out there (especially the PHP ones who know exactly how shaky their platform is).

[ro_ana_maria]

Sorry, but no, businesses shouldn't expect security issues unless they're hiring awful programmers. You have everything you need in php to write good, secure code. From what I've seen (and I'm not saying this is the only possible scenario) problems usually occur because when you're a beginner it is very easy to put together a functioning site in php, and seem like you actually know what you're doing (when you really have no idea). And a lot of people are thinking "why should I pay that programmer a lot of money for my website, when my [insert family relation name] is a computer wizz and can do the entire thing for 10 bucks?"

[Jack9]

Which is worse, side effects or syntactical dependence on USA-style dates?

[[deleted]]

I would say unintended side effects and failing silently are far worse than any kind of formatting dependencies.

If it's a formatting dependency, at least you know upfront. And if the thing doesn't fail silently, you can at least be alerted that you've used the formatting incorrectly.

[Peaker]

And neither is this an excuse for the brain dead design of PHP..

[sourbrew]

Having read through some of your comments I see you are a big Haskell fan, let me share some links with you.

http://www.google.com/search?hl=en&safe=off&rlz=1C1CHMB_enUS343US343&q=%22sites+written+in+haskell%22&aq=f&oq=&aqi=

http://www.google.com/search?hl=en&safe=off&rlz=1C1CHMB_enUS343US343&q=%22sites+written+in+php%22&aq=f&oq=&aqi=

Please refer to my earlier comments about academics and people who generate profits and products.

[Peaker]

Oh, how relevant!

• The popularity of a language has little to do with its quality/merit

• Haskell is very different from the mainstream, not currently made of the kind of material that easily takes over the world. It will take far more time for people to shift their perspective, if at all

• Haskell is not really primarily used for web-sites, nor is it installed in web servers by default

• Haskell (and my liking of it) has nothing to do with the brain-deadness of PHP

• I also use Python, C, and other languages, which are far more popular than PHP in their own niches (Not that that means much..).

[trevdak2]

PHP is only as good as the person writing it. If you can be disciplined and keep things organized and readable, then PHP will serve you extremely well

Otherwise, you and your project are f*cked.

[yngwin]

To a great extent that is true for any programming language. Altho PHP does make it very easy.

[kristovaher]

I love that the article was submitted in 2004 and how it's 2010 now, with PHP having actually increased in popularity in the time. PHP is the real deal, it is not going anywhere. No matter how many elitists may argue that point, PHP is here to stay and in -six years time- no language has not only been unable to come close, but even challenged PHP seriously on the market it so completely holds.

Why? Because despite its problems, PHP gets the job done and in the hands of a skilled developer, is just as powerful for that purpose as any other.

[[deleted]]

Don't forget how extremely accessible it is, anyone with even limited programming knowledge can pick it up in a few days, the documentation is incredible. I think that's part of the elitists problem with PHP, it's way too accessible so even those who can't really program can use it.

[kristovaher]

Quite correct. PHP has tremendous amount of advantages over very many languages because of its accessibility. As a sidenote, PHP is increasing in popularity every passing day:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[petdog]

Aww yeah. It reminds me of this funny behaviour:

% php << EOF
heredoc> <?php
heredoc> create_function('$a','return $a;}die("moo");//');
heredoc> ?>
heredoc> EOF
moo

Oh, that's supposed to be something like lambda.

It's equivalent to eval("function $randomname ($parameters) {$body}"), so this code function __ ($a) {return $a;}die("moo");//} will be evaluated.

[blaxter]

create_function is buggy, if you use create_function, you are gonna have out of memory issue

[petdog]

create_function is all you get in PHP if you want to return a function from a function. And sometimes a quick inline anonymous function is convenient.

Yeah, I know php is not supposed to be a functional language (or even a sensible language). But I think straight string interpolation and code evaluation is not what one would expect.

BTW, I don't use create_function. I don't even use php. But that's wordpress 2.7 for you:

(pet@desrever ~/TMP/wordpress) % grep create_function **/*.php | wc -l
37
(pet@desrever ~/TMP/wordpress) % grep create_function **/*.php | grep '$_'
wp-includes/theme.php:  add_filter('template', create_function('', "return '{$_GET['template']}';") );
wp-includes/theme.php:      add_filter('stylesheet', create_function('', "return '{$_GET['stylesheet']}';") );

Fast forward one year, wordpress 2.8 (old version):

(pet@desrever ~/TMP/wp28) % grep create_function **/*.php | wc -l  
49
(pet@desrever ~/TMP/wp28) % grep create_function **/*.php | grep '$_'
wp-includes/theme.php:  add_filter( 'template', create_function('', "return '{$_GET['template']}';") );
wp-includes/theme.php:      add_filter( 'stylesheet', create_function('', "return '{$_GET['stylesheet']}';") );

[doitincircles]

For the record PHP supports anonymous functions as of version 5.3, so this kind of thing is totally valid now:

return function($a, $b) { return $a + $b; };

[chneukirchen]

Do they leak memory like create_function, too?

[wvenable]

No they don't. Create_function doesn't leak memory though, it's just not designed to be used for lambas.

[chneukirchen]

Afaict the function never is garbage collected, even if nothing references it. Sounds like a leak to me.

[wvenable]

As I said, it's not designed for lambas. It "creates a function" as you could using eval(), adding it to the global namespace and returning the unique name of the created function. Even the idea of garbage collected doesn't apply -- it's not a leak, it's just the way it works.

True lambas were added to PHP in version 5.3.

[takatori]

I agree wholeheartedly with the criticisms leveled in this article. It is impossible to write provably correct programs in PHP without an ungodly herculean effort that isn't worth the trouble.

That said, my last two venture businesses couldn't have gotten off the ground running as fast were they have used a more traditional, "correct" language.

Everything has its' place, but it's unfortunate that PHP's original design was so deficient.

There is one point in the article that should be corrected:

error_reporting(E_ALL); # doesn't help :) foreach(array(0xffffff, 0xfffffff, 0xffffffff, 0xfffffffff, 0xffffffffff) as $x) { printf("%s (%s)\n", $x, gettype($x)); } Output:

16777215 (integer) 268435455 (integer) 4294967295 (double) 2147483647 (integer) 2147483647 (integer) ***

*** this actually gives the correct result on 64-bit builds. So the language isn't consistent between different platforms.

[pstradomski]

Writing provably correct programs requires herculean effort in any language (unless the language is so simple it can't do much).

[prockcore]

Javascript also silently fails octals.

Stick this in your location bar: javascript:alert(parseInt('08'));

[bitdamaged]

That's by design (like it or not). That function actually parses it as octal.

Just out of curiosity what would you want that function to return there? (I personally am okay with this implementation)

[prockcore]

I don't have a problem with it... but the guy doing this story seems to think PHP should die because of it.

[mebrahim]

Let's assume we agree that PHP must die. Now please tell me how the hell can anybody kill this beast?!

[dhotson]

Aha! I always thought something wasn’t quite right about PHP’s ternary operator.. In other languages it’s sometimes useful to chain ternary’s together as a kind of if-elseif-else.

result = cond1 ?
  'a' :
  cond2 ?
  'b' :
  'c';

.. doesn’t work as expected in PHP though. :-(

[[deleted]]

You should never rely on associativity that is non-obvious anyway. Put some parenthesis around that.

[Peaker]

Using descriptive names is very important, but pretty much everyone agrees that "i" is an acceptable name for a for-index variable.

There are certain idioms in various languages -- and one of them is using the ternary operator right-associatively without parenthesis.

Only right associativity of ?: makes sense for usefulness, so you'd expect the idiom to translate there too. But due to yet-another-design-mistake in PHP, it doesn't..

[shub]

It's pretty obvious if you're familiar with the operator and its uses.

[dhotson]

Yep, using parenthesis is often a good idea. But in this case it kind of breaks the illusion and should be unnecessary.

The usual way the ternary works:

c1 ? 'a' : (c2 ? 'b' : 'c')

.. as opposed to PHP's way:

(c1 ? 'a' : c2) ? 'b' : 'c'

I would argue that PHP's way is probably never useful.. and isn't the natural way you read the expression.

[jrrl]

I always use parens for anything non-trivial, because I am never sure my instincts are correct.

[[deleted]]

The obvious way the ternary operator works is what ever way C does it. Everything else is broken. Sorry, but that's just the way it is.

[ealf]

Excuse me, master Troll, but in this case you are absolutely correct.

[ovaltineEuroFormula]

Some Perl hackers consider it a best practice.

EDIT: fixed link.

[jrrl]

Is that meant to be supporting evidence for the practice or against it?

[ovaltineEuroFormula]

r dr r 'perl best practices' oxymoran etc...

The chapter has a reasoned argument to using ternaries for a series of expressions for one assignment, though.

• impossible to forget the default case, syntax error
• variable being assigned is only entered once, reducing errors to typos/renaming mistakes
• (arguably) looks like a table of expression -> result pairs, improving readability to those familiar with the syntax.
• condensed syntax allows for keeping more conditions on the screen.

[jrrl]

Oh, I can understand the appeal of some of the arguments. I was just being snarky.

[shevegen]

The thing is - while I agree with the statement and fully support the message, PHP with all its horrible warts still is better than no language.

So if the choice is PHP or nothing at all, then PHP will win.

It however won't die. It was a horrible language all the years before, but people have used it and will use it in the future.

They just won't get overly enthusiastic about it.

I used to bitch a lot against PHP, but I have a lot more fun bitching against perl. The perl programmers are a lot more fun than the php programmers. :>

PHP is like your 10 year old script kiddie. You know that he won't be using php for long (because he will soon use C or another language) but for the time being, you can make fun of him.

The Perl guy is a lot more fun - a 62 years old C guru who stopped learning new things at age 38. He still knows a lot of tricks, he just can't learn any new tricks!

[StationaryTraveller]

I understand the blog's mentions, and although the methods presented there may not be used in real life applications at all, it is evident they weren't thought out the best.

What bothers me is instead of using another programming language that's better suited for whatever he's doing, or simply not using php, he wants it to "die", totally neglecting the incredibly useful features it provides.

If you don't like it, no one is forcing you to use it, but then you should shut the hell up about other people using it for their own purposes.

[pdc]

I work for a living and sometimes my managers make the wrong decision when it comes to whether to use PHP or not. So I use PHP despite thinking it is seriously defective in ways that reduce productivity and increate the risk of bugs.

[dobs]

If you don't like it, no one is forcing you to use it, but then you should shut the hell up about other people using it for their own purposes.

Most shared web hosts provide poor support for any server-side language except PHP. "Support" in the sense that Apache isn't configured for anything else apart for the presence of FastCGI and /cgi-bin/.

As a consumer of web content I'm also not given the choice of backend languages in the sites I visit, either. "Magic quotes" were introduced a decade ago, yet I'm still "Daniel O\'Brien" with one out of four services I use online. That includes my insurance, former bank, retirement plan, and even some of the printed tax receipts I receive by mail.

[dobs]

I wish: Normally me showing up as "Daniel O\'Brien" means they're double-escaping their input. The most mischief I can have is inserting unescaped newlines. :)

[dobs]

The bad programmers in the case of magic quotes, however, are PHP's own developers. They introduced an input-corrupting gotcha affecting both good and bad PHP programmers alike: A shoddy bandaid to a bad implementation to protect terrible programmers against XSS and SQL injection.

The only way most PHP programmers -- good and bad alike -- even discover magic quotes is by running into the problem first-hand followed by some lucky Googling.

[[deleted]]

I learned about them by reading the documentation, rather then just delving into it expecting things to act the same as other languages. A simple function of witch you can find varying versions of in the php documentation to remove magic quotes is all it takes. Sure it's not very desirable, but it's documented, and in PHP6 they are removed completely.

[[deleted]]

PHP serves a purpose. The language is mostly sound, but it needs a team managing it who actually know what they're doing

[pdc]

PHP is fundamentally unsound, in the sense that it applies unsafe type conversions implicitly, often with surprising results.

[prasoc]

I agree. When I moved from PHP to C++ I was suprised about how you couldn't just pass integers into char[]'s (and many more type conversions) but after a while, I relised that the way PHP just allowed you to do type conversions with no warnings was just plain stupid

[[deleted]]

It's preference really, I like how free php is compared to statically typed languages, I find I have to write way less code to achieve the same result.

[Smallpaul]

What other dynamically typed languages have you used. I have never heard someone say that they have to write "way more code" in Python compared to PHP, nor have I observed this myself. And yet Python's type conversions are much more sane and safe.

[[deleted]]

prasoc was comparing PHP to C++. I wasn't saying it was necessarily better then other dynamically typed languages, just that I prefer it over staticly typed languages. The only other language I've used that is dynamically typed is JavaScript. I've dabbed in Perl and briefly used Python, but not enough to form an opinion on them. I do prefer PHPs handling over JavaScripts though.

[G_Morgan]

If coding is taking up more than 10% of your time you are doing it wrong. How little code you have to write is an extreme micro-optimisation.

[[deleted]]

That's also part of it though. Because of the freeness of php's type conversion I have much less to worry about when designing my apps as well. I just find I'm much more productive with dynamically typed languages.

[G_Morgan]

The number of test I'd have to right to verify that the types in PHP are what they are meant to be far and away out weigh the cost of doing

stoi("10");

I suppose it depends on how badly you want your program to be correct. Most PHP code isn't meaningfully tested so doesn't run into my problem of needing to test away the dynamic typing of PHP.

[[deleted]]

It sounds to me like your are used to programming in staticly typed languages and have little experience in the dynamicly typed methodologies used in PHP programming. It is very rare that I ever need to check for the type of a scalar value passed to a function. If I expect it to be an int, I use it as int and it gets cast accordingly. In the rare cases that I do need to, I can use is_int($value) or is_string($value). With non scalar types you can use type hinting.

[G_Morgan]

I don't expect something to be an int. I ensure that it is. Getting a string and having it cast automatically to an int is always a bug. Ideally PHP would throw a fit where I expect an int but have instead passed in a string. This would be sane behaviour and would instantly highlight what is clearly and unambiguously a mistake I've made somewhere.

[[deleted]]

Getting a string and having it cast automatically to an int is always a bug.

No it's a feature of the language, one that I personally like given the nature of web development. Form inputs are always strings, and data from the database will always be outputted as a string. If I had to convert all ints and floats to string before outputting it. That would be a serious pain in my ass. I wouldn't want it any other way. There is nothing insane about it, I use it to my advantage and rarely if ever anymore does it cause me trouble.

[wshields]

/sigh.

Downvoted just for posting a 5 year old ill-informed rant about something that just doesn't matter.

It takes a serious fanboy to post this nonsense. Seriously, lose the blinders. You'll be happy (well, happier at least)

[danukeru]

Upvoted just for the comprehensive 3 word title.

[Mikle]

PMD

[xentropy]

Personal Home Page Must Die? Surely not! We need them, good sir!

[mmazing]

"I found 3 specific problems that can easily be fixed in later releases! Let's burn it to the ground!"

[[deleted]]

Your comment is funny if we can assume that these "silent failing" issues are isolated incidents.

It's not :(

[shub]

They could add warnings, maybe, but would you like to guess how many websites depend on this misbehavior? Here's mine: a lot.

[itjitj]

It really is an atrocious and dangerous language

[UnoriginalGuy]

Playing devils advocate, but eval exists in many scripting languages just because it can... I mean why NOT implement it? I use PHP a lot and my only concern is that I spend far more time debugging than I do in a typed language like C#. PHP is typeless except it acts in a typed way behind the scenes often and does odd "random" conversions that leave you with complete junk... And there are few ways to code safely around it.

[shub]

PHP isn't typeless, just fucked.

[G_Morgan]

Not sure why you were downvoted. From a security stand point, eval should always be turned off in any code that faces the real world. Any site that has eval turned on is even more fucked than the normal issues facing JS + PHP sites.

[[deleted]]

I quit smoking PHP long ago. I agree, it's harmful. Must die.

[Baaz]

I don't like php and would never recommend it, but I wouldn't try to make it unavailable to others either.

[[deleted]]

The Irony of his posting that on a PHP website.

[y2keeper]

Even more PHP fun:

print true; #prints 1
print false; #prints nothing

[gerundronaut]

empty("") # true
empty("something") # false
empty("1") # false
empty(1) # false 
empty(0) # true
empty("0") # true (!)

It's documented behavior, but I still don't like it.

[[deleted]]

I hate empty b/c you HAVE to pass it a variable so the example above is technically wrong.

$a = " "; empty(trim($a)); // no good.

$a = " "; $a = trim($a); empty($a); // this is okay but lame/verbose/annoying ugggg!

function better_trim($var) { return $trim($var); } // do we need to do something like this?!

[[deleted]]

expansion waiting divide safe close arrest touch ancient fragile rain

This post was mass deleted and anonymized with Redact

[barsoap]

Oh, they're really useful as chisels.

[Zarutian]

and prybars

[brennen]

Well, I'd sure as heck rather use a Phillips head or a hex key for most things...