Live data from Hacker News

PHP needs to die. What will replace it?

seldo.com

121–130 of 160 posts

Re: PHP needs to die. What will replace it?

#121
post #99
post #84

Earlier quoted context omitted.

No, I'm saying that the stuff built into PHP is weird and inconsistent. I should change it to "sane default library" from "sane API". My current favorite example of this (ignoring the naming scheme for string functions entirely) is that in_array and strpos are functions that perform (almost) the same task, on two different types. They take their arguments in the opposite order. strpos($haystack, $needle) vs in_array(…

> No, I'm saying that the stuff built into PHP is weird and inconsistent. You never asked yourself WHY. See, that's the important question, isn't it. WHY. I'll tell you WHY. Because two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time. But, eventually, someone noticed it. And then they did something really crazy. They didn't fix it. Because tha…

But it can (and should be) fixed. It's not that difficult.

Choose a convention (ie: always $haystack before $needle), find the methods that don't conform, and print deprecation messages for them, add their replacements.

Then in the next major release, remove the deprecated methods. Hell, you could even put the deprecations in in a module so that those who can't/won't update their code won't have to be left behind.

It may be impossible to write a good language from the start, but that shouldn't deter from fixing those mistakes.

Re: PHP needs to die. What will replace it?

#122

Earlier quoted context omitted.

One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to. For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code. O…

Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.

You can (and people do) use Capistrano to deploy php code.

Re: PHP needs to die. What will replace it?

#123
post #99
post #84

Earlier quoted context omitted.

No, I'm saying that the stuff built into PHP is weird and inconsistent. I should change it to "sane default library" from "sane API". My current favorite example of this (ignoring the naming scheme for string functions entirely) is that in_array and strpos are functions that perform (almost) the same task, on two different types. They take their arguments in the opposite order. strpos($haystack, $needle) vs in_array(…

> No, I'm saying that the stuff built into PHP is weird and inconsistent. You never asked yourself WHY. See, that's the important question, isn't it. WHY. I'll tell you WHY. Because two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time. But, eventually, someone noticed it. And then they did something really crazy. They didn't fix it. Because tha…

The problem is not that "two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time". Is is that it was allowed to be added to the core library without it being questioned and fixed before it was too late to fix for compatibility reasons. That is the ultimate problem. I would rather a language or framework or library move slowly and correctly than add things haphazardly.

Re: PHP needs to die. What will replace it?

#124
post #91
post #77

Earlier quoted context omitted.

Yeah, exactly. This headline could have been written with the same justification in 1999. Yet PHP refuses to die. Clearly us hackers are missing something important.

Having not used php for 12 years, I recently accepted a freelance job for a client who had been left in the lurch by his php developer who seemingly abandoned the project because she was out of her depth. I have to say that I was pleasantly surprised by some of the new language features that php has borrowed from elsewhere... eg: closures, anonymous functions, docstrings. IMHO php is held back primarily by messy, inc…

Major PHP versions are the evolutionary jumps for the language. They don't tend to worry as much about backwards-compatibility when going from PHP3 to PHP4 to PHP5. I've read that PHP6 was supposed to take it further and outright remove a lot of deprecated and insecure aspects of the language, but I don't know if or when PHP6 will be released.

I agree that they should take things even further and really clean up the language before releasing the next major version. Fix the needle-haystack vs. haystack-needle inconsistencies, function naming conventions, and so forth.

The adoption rate of a new major version on shared hosting providers is relatively slow, so it'd be a perfect time to really shake things up and clean it up.

Re: PHP needs to die. What will replace it?

#125

Earlier quoted context omitted.

Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.

You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from. Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to t…

After having battled a PHP (mod_php) deployment system and having to hack the hell out of capistrano to get a usable one... Amen to your comment.

Re: PHP needs to die. What will replace it?

#127
post #99

Earlier quoted context omitted.

> No, I'm saying that the stuff built into PHP is weird and inconsistent. You never asked yourself WHY. See, that's the important question, isn't it. WHY. I'll tell you WHY. Because two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time. But, eventually, someone noticed it. And then they did something really crazy. They didn't fix it. Because tha…

The problem is not that "two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time". Is is that it was allowed to be added to the core library without it being questioned and fixed before it was too late to fix for compatibility reasons. That is the ultimate problem. I would rather a language or framework or library move slowly and correctly than ad…

The thing is, these functions were added a long time ago when the language and the project itself was in it's infancy. It's purpose and audience was different. I doubt anyone developing at the time expected it to last this long and be used by this many people. The goal was to put in as much functionality as possible to be useful. It was web scripting for C programmers.

The problem with a language that moves slowly is that if there's an opportunity, it might just miss it. I was working in PHP in the early days and every release brought features you wanted to use yesterday. Perhaps if PHP didn't have the huge rate of change it did then maybe it would have never caught on. Python is several years older than PHP and yet it didn't come to web until long after.

Re: PHP needs to die. What will replace it?

#128
post #82
post #68

Earlier quoted context omitted.

When I read >> the critical thing Perl was lacking was PHP's wonderfully flexible "associative arrays" I grabbed my copy of "Learning Perl" from 1997. Chapter 5's topic? Hashes.

Perl hashes don't preserve order. PHP's almost always do. i.e., the order you insert keys is the order in which you will receive them back when you iterate over the array. It's similar to a LinkedHashMap in Java. CS types might recoil at the mixture of behaviors that are baked into PHP's workhorse data structure, but most of them turn out to be quite useful. (And it makes it easier for the beginner programmer to deci…

Perl hashes don't preserve order. PHP's almost always do.

This is the point at which serious students of language design point out that, if you look at it from a certain angle, PHP doesn't have arrays built into the language. As it turns out, treating two distinctly different data structures with different semantics and performance characteristics as the same thing multiplies edge cases and bugs.

Re: PHP needs to die. What will replace it?

#129

Roughly a decade ago, PHP killed Perl. Not completely, of course; it still clings on in some environments, it has a sizable legion of die-hard fans, and legacy apps will need to be maintained in it for decades to come. But as a language for newcomers, and especially for web developers, it was already dying in 1999 and was mostly dead by sometime around 2005. Uh. http://www.indeed.com/jobtrends?q=perl%2C+php%2C+ruby I…

I think newbies just found easier languages to work with...

Change that infinitive to "to deploy", and you're spot on.

Re: PHP needs to die. What will replace it?

#130
post #99

Earlier quoted context omitted.

> No, I'm saying that the stuff built into PHP is weird and inconsistent. You never asked yourself WHY. See, that's the important question, isn't it. WHY. I'll tell you WHY. Because two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time. But, eventually, someone noticed it. And then they did something really crazy. They didn't fix it. Because tha…

The problem is not that "two different dudes implemented it. At different times. Probably, from different continents. They didn't notice it at the time". Is is that it was allowed to be added to the core library without it being questioned and fixed before it was too late to fix for compatibility reasons. That is the ultimate problem. I would rather a language or framework or library move slowly and correctly than ad…

You're not getting what I'm saying. Even if you are super careful, mistakes will be made. What's important is how you deal will them once they're there.

PHP chooses to be ugly, over shafting its user-base by deprecating shit left and right. I like that. It tells me I can use it in a production setting.

Post reply on HN