Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new PHP

programming.oreilly.com

Post reply on HN
Print view View original

21–30 of 203 posts

Re: The new PHP

#21

Post by orf »

maratd wrote: post #5
d23 wrote: post #2

> It contains powerful new features and helpful developer tools, such as a built-in web server I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. How long until we start having security releases for the PHP web server, because so many clueless devs decid…

The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…

No its like saying Home Depot shouldn't sell power tools to children who don't know how to safely use them.

Unless the web server displays a huge red message every time it is run saying "Don't even think about using this in production" you can bet that it will be.

Re: The new PHP

#22

Post by Karunamon »

mehwoot wrote: post #16
maratd wrote: post #5

Earlier quoted context omitted.

The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…

Just because a tool can be misused is not an argument against it nor its inclusion. I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make. I'd rather a builder use a seco…

>People can and do misuse things all the bloody time, and the more you enable them to do that

This is an excuse for educating people, not an excuse for kneecapping the majority due to an ignorant minority. This is the kind of thinking that plagues the GNOME3 devs and gets ridiculed so often around here. The user is an idiot so let's remove features.

I don't see many people harshing on Rails for the inclusion of WEBrick.

Re: The new PHP

#23

Post by Jgrubb »

I'm a Drupal dev by trade, and I consider any day that I don't have to get into the guts of Drupal and write PHP a good day.

Recently, however, I had to get in there. This was a few days after I upgraded my local environment from 5.3 to 5.5. I've been writing Ruby for fun for a while now, and I love how I almost never have to look API related questions up, at least in comparison to PHP API questions. So I just wrote some PHP without looking up whether it was going to work, and it worked, first try. That rarely happens. Then I pushed it to dev, which is still on 5.3, and took the (dev) site down. Turns out the feature "array function dereferencing" is not available in 5.3, so I had to rewrite my code a little bit.

Point being, I could see myself liking PHP more when we move to 5.5 in all our environments.

Re: The new PHP

#24

Post by alien3d »

awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

I prefer dual world. array_x = less memory $object->array->getElement[0] = i prefer not.. Just to get element you need to declare object ?

Re: The new PHP

#25

Post by aviraldg »

awestroke wrote: post #8
Gigablah wrote: post #6

Earlier quoted context omitted.

> == should work like === Then why not use === ?

I know enough to use === when I program in PHP (even though I oftentimes forget) but newbies don't.

>> but newbies don't

... and sadly constitute a large majority of PHP users.

Re: The new PHP

#26

Post by nikic »

While the gist behind this post is right, the article contains a number of factual errors. E.g. the version numbers in the "language features" section are pretty messed up:

* Namespaces, closures and FPM were already in PHP 5.3

* The built-in web server was already in PHP 5.4

* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.

Re: The new PHP

#27

Post by eugene-d »

rubiquity wrote: post #17

> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style. "The new Java" It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I th…

Cleaning up main API or similar vast changes may and probably will be a disaster for PHP. We all know a bunch of examples from other languages.

Re: The new PHP

#29

Post by TeMPOraL »

mehwoot wrote: post #16
maratd wrote: post #5

Earlier quoted context omitted.

The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…

Just because a tool can be misused is not an argument against it nor its inclusion. I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make. I'd rather a builder use a seco…

> People can and do misuse things all the bloody time and the more you enable them to do that, the worse your tool is.

In terms of avoiding accidents I agree, but in general, I don't like this kind of thinking.

One man's misuse is another man's hack. The flipside here is that the more you limit and subdivide a tool, the worse your tool becomes.

I'd also rather see builder using something else than a jackhammer to nail stuff, but then I also want him to have access to one if he needs it, and I strongly want people to stop shouting "omg you can't use X to do Y, because X was not meant to do Y". First principle of hacking: tools do not have inherent purpose, they can be used to do whatever we want; they only can be better or worse at a particular task. The world didn't collapse into logical contradiction the last time I cut pizza with a sound card, because of lack of any other sharp tool nearby.

Re: The new PHP

#30

Post by mordae »

alien3d wrote: post #24
awestroke wrote: post #3

I sometimes ponder what I'd fix, given the chance, about PHP: * Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT. * Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes…

I prefer dual world. array_x = less memory $object->array->getElement[0] = i prefer not.. Just to get element you need to declare object ?

Wat?

He meant `$arr->length()` and such. Array access like `$arr[42]` is proper.

Post reply on HN