PHP like any other language has its shortcomings and its strong points.
The market place decides. If you want to get rid of PHP (or 'kill' it) you will have to displace it with something better.
The other alternative is to send in a patch for this bug or simply report it. I've used PHP for many years and while I certainly don't love some of its more subtle problems you can build an amazing amount of stuff in it.
I have personally had good success reporting bugs to the PHP devs.
That's a lot more productive than 'blogging' about it.
In case it isn't clear why the 08 does not print anything, the 8 is an illegal character in an octal string and is discarded.
A suitable error message would be 'invalid character in octal sequence' instead of a silent discard.
That and the ease of deployment, which is possibly the strongest factor. Most hosting companies will provide you with PHP on apache even if you don't ask for it.
I'd say that greatest data structure in all languages is PHP array().
It's actually an ordered dictionary with default implicit natural number keys. Efficient enough to represent concepts such as arrays, sets, queues, stacks, trees, graphs without bothering with hashtables, linked lists, reallocations and other underlying data structures tailored for specific purpose.
Nope. I honestly think that that this is one of the main reasons PHP is popular and is able to power even the most complex websites with ease.
Before PHP I did Basic (Atari), 6502 Assember, Logo, ACTION!, Pascal (Kyan, Turbo), C++ (Turbo, Borland) , Java, C#. After PHP I did JavaScript and Python.
First I've met PHP-like arrays in awk and was astonished with its versatility.
I still believe that data structure that allows person to make a queue, stack, tree, even graph easily without knowing any theory and planning anything is one of the greatest things I've encountered in programming languages.
I am very dissatisfied that python does not have standard ordered dictionary and strongly differentiates between tuple, array, set and dict even though they provide just overlapping subsets of odict functionality.
Mainly because I have to. And I often have to, since many el-cheapo web providers only offer PHP+MySQL. PHP isn't too bad, I don't get bitten often by strange bugs. I see PHP as a common workhorse.
Fixed within 6 days, with an email to my address about where
to get and how to apply the patch, which was a nice touch.
The other one was technically my fault but it would have been nice to see the 'expected' response from a language I've been using for such a long time.
It's not just a bug with an associated patch. It's a language misfeature, in a 15 year old language. You can very probably fix it without breaking existing code.
And since a probable fix without breaking stuff is likely a patch would be all it takes (and a note in the changelog, for the unlikely case that someone did depend on it, not that they'll read the changelog ;) ).
Octal not being the popular thing it once was I doubt it would matter much.
I think more people are 'bitten' by this totally unexpected behaviour of leading 0's suddenly doing wildly interesting things to numbers (what?? there are more numberbases than just decimal???) than there are that expect illegal characters in octal numbers to throw errors.
In a world where you have to eat, sleep, and work, sometimes you have to live with a bit of imperfection. If the code works, and you will never need to modify it, it doesn't matter how clean it is. (This is why I use UNIX. It sucks, but it is pretty easy to paper over the suckage. If I used a properly-designed OS, I wouldn't be able to browse the web, program, etc., etc.)
I think there's a more relevant issue here: can we please stop designing languages that use prefix-zero to signify octal? It's a horrible trap lying in wait for those just learning their first language, and then you have to keep it in mind whenever you learn another one, to see whether it's "supported" in this new one as well.
Perhaps, instead, we can come up with some unified representation of a way to attach a base to a number, such as, say, [base]b[number], e.g. 2b0110001 or 16bFF, and use it in every language? (I'd say something about subscripts and their natural use née mathematics, but I'll hold that comment until the iTablet's soft keyboard layout makes people start rethinking APL-like languages.)
Python 3 has, I believe, done away with the 0 prefix for octal and uses a consistent prefix system for different-base literals: "0x" for hex, "0o" for octal, "0b" for binary.
Printing a warning would be easy enough, you could disable the warning if you want it to work like this. Leave that for one generation with a 'deprecated' attached to it, remove in the major release after that.
Lots of things that were wrong have been changed like that.
The biggest one remaining of the 'old' bugs which I think really would break too much is the strpos return value in case of no match (which is 'false' but 0 is a legal return value as well, -1 would have been a far better choice).
PHP's yacc grammar is a good read, just as an example of how not to implement a yacc grammar. Changing one constant, for example, would make PHP's parse error messages about 1000x easier to understand and resolve. (I sent a patch for this many years ago, but it apparently never made it in.)
The number of things that work by coincidence, like support for octal numbers, is shocking. It's clear that PHP is optimized for something other than correctness.
They could do a lot better still, but as long as nobody comes along and starts to make serious inroads into their user base I doubt this will change much.
What is surprising is not how much is broken, but how far they made it with so much stuff as broken as it is.
I've always thought that if python would have used braces, dropped the whitespace bullshit and came with a ready to go plug-in for apache with a similar ease of deployment that it would have kicked PHPs ass long ago.
PHP appeals to the people that don't really understand programming, so I doubt making the language better in a programming-language-designer way is going to convert users. The next language that's as popular as PHP will be "easier" in some way that's appealing to average users.
Perl was there first; you could "require 'cgi-lib.pl'" and start writing a web application.
Then PHP made that even easier, by making HTML pages valid programs. (You could add code "later"; your scripts didn't have to live in cgi-bin isolated from plain HTML files.)
The average users jumped ship from Perl to PHP pretty quickly, despite Perl having more features, more modules, a better runtime, etc. They wanted to know as little about programming as possible, and PHP got them there. Inexperienced programmers want to micro-optimize for things like deployment or runtime speed, and PHP gives them that.
The next Popular Language will make one of those things even easier.
(Ruby on Rails almost did this, but it went overboard with the advanced programming language concepts, and is now a small niche again. It alienated the experienced programmers, who went with Merb, and the inexperienced programmers, who couldn't wrap their head around concepts like exceptions and just stuck with PHP, which lets you ignore errors if you prefix the line with an @ sign.)
Anyway, what I'm getting at is, "just leave the PHP users alone". Those that want something better will find it. Those that don't, won't.
PHP is used by plenty of people that (at least think they do, looking at myself ;) ) do understand programming, they just use it because they literally got used to it.
The perl community was pretty abrasive when I first looked in to it, the PHP community was the opposite so I ended up programming a large amount of stuff in PHP.
But before that I already coded my way around for about 15 years or so in lots of other languages, projects including cad systems, low level communcations drivers for weird bits of hardware, an OS and a whole slew of other stuff.
Basically my take on it was 'it's good enough for what it's for', web programming and making money.
To this day a good part of http://ww.com/ (possibly nsfw so don't go there if you are on your boss' line) is written in PHP, I've recently gone over the whole thing in order to clean it up readying it for a port to something a little bit more clean.
It was quite amusing to see how many hoops we had to jump through 11 years ago when it was first built compared to how easy you could do some of that today.
For plenty of people it is just a means to earn a living, language aesthetics and purity or expressiveness don't enter in to the equation, it is whatever their boss tells them to use, C#, PHP or Java.
And perl definitely suffered because of the attitude perl aficionados take, both with respect to other languages as well as to those that do not fully grok perl just yet.
Community is a huge part of any programming environment, possibly even more important than the language itself.
Community is important, and that is the main reason why I tolerate Perl's various annoyances. There are simply a lot of Perl programmers that give me excellent code for free (see http://github.com/languages) and that makes it all worthwhile.
The same does not appear to be true of PHP. PHP's community is more talkative ("How to cut-n-paste code to hash passwords"), where Perl's is more programming-oriented ("Authen::Passphrase"). As a programmer, I prefer to stick with the programming-oriented community.
"The perl community was pretty abrasive when I first looked in to it, the PHP community was the opposite so I ended up programming a large amount of stuff in PHP."
I chose to use Haskell instead (I like the "vibe" of its mailing lists and irc and blog posts and so on) and have been feeling a smidgen guilty about dismissing Clojure (which I think is really nice - I admire Rich Hickey's tech skills and design sensibility) for its community's stridency.
This is exactly right. There's a lot of use cases where what's needed are variables, loops, conditional logic, and easy HTML output. In those cases, the winning language is the one that's easiest to learn and to deploy. Problems with handling invalid characters in octal are just not relevant in those cases.
Of course, those cases aren't interesting to HN, but they're common, and PHP legitimately wins in them.
What should die is not PHP but the use of PHP in circumstances where another language would be a better choice.
That is a very good way of sketching it, but even the last part is sometimes not the easiest to do.
I've written a 'media-player-annex-file-sharing-service' ( http://mxchg.com/ ), the thing has a web based front-end written in PHP and a C based back end for audio fingerprinting (so you don't end up storing 10 copies of each possible audio file).
When the time rolled around to write the scripts that glue everything together in the back-end I chose to do it in PHP instead of python for several reasons:
- it reduced the number of dependencies
- it removed the need to rewrite part of the code in yet another language
(mostly library stuff)
- it removed the need for yet another skill in people wishing to modify it
Perl may have had a better runtime, but PHP was effectively faster since it had an easy to use apache module and most perl code was being run as cgi scripts, which is hardly performant. I remember trying to configure mod perl and mason circa 2002, and it was an excercise in poor documentation and pain. PHP was dead simple to setup. That said I still stuck with Perl (eventually moving to Ruby), and I loathe PHP.
But, in general, running app code in the webserver is a bad idea. This is why everyone uses fastcgi in production, and why every web framework (except PHP) ships a standalone dev server for development work.
PHP is the one that's hard to use now, unless you are developing on an already-configured system.
A more interesting discussion would be how more advanced, especially functional, patterns can be used in php. Right now I'm returning in php after many years of java and some time with lisp and clojure, and I'd be very curious to know if any of you managed to apply a more lispish mindset to it.
People make mistakes. Computers don't. So people program computers to catch their mistakes, before those mistakes become problems like "crashing" or "losing money".
If you give the compiler invalid input, a subtly-broken program should not be the output. The output should be an error pointing you to your mistake.
True, but in this case PHP corrected its error (it now returns null for this use case, as it should)... this is why you don't rely on undocumented behaviour as canonical. If it says it should return null, but returns zero instead, check this result always.
The developers of PHP created the most popular language on the web. They built a language that is not only preferred by people with no programming background, but also powers some of the most influential and popular websites (eg, Wikipedia, Facebook). They did all this with zero-or-negative hype around them and while competing in a space that some of the richest companies in the world (Microsoft, Sun, IBM) have poured massive resources into.
So, yeah, they did screw up here and there. But very few projects were remotely as successful as theirs.
The market place decides. If you want to get rid of PHP (or 'kill' it) you will have to displace it with something better.
The other alternative is to send in a patch for this bug or simply report it. I've used PHP for many years and while I certainly don't love some of its more subtle problems you can build an amazing amount of stuff in it.
I have personally had good success reporting bugs to the PHP devs.
That's a lot more productive than 'blogging' about it.
In case it isn't clear why the 08 does not print anything, the 8 is an illegal character in an octal string and is discarded.
A suitable error message would be 'invalid character in octal sequence' instead of a silent discard.