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

PHP: The Right Way

phptherightway.com

Post reply on HN
Print view View original

211–220 of 233 posts

Re: PHP: The Right Way

#211

Post by sharkbrainguy »

dlitz wrote: post #126
simonbrown wrote: post #106

Earlier quoted context omitted.

They do. http://www.joelonsoftware.com/items/2006/08/01.html http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/

Javascript is just Scheme with a C-like syntax and a limited number of bad design decisions (like automatic semicolon insertion and the == operator). PHP is a never-ending fountain of bad design decisions, because its core devs continue to make new ones.

No, Javascript is not "just scheme" with a few bad design decisions. They have significant differences.

Scheme has:

  call-with-current-continuation http://people.csail.mit.edu/jaffer/r4rs_8.html#IDX509
  Tail Call Optimisation
  A numeric tower http://people.csail.mit.edu/jaffer/r4rs_8.html#SEC50
  A Code/Data equivalence and therefore macros
  Ports
Javascript has:

  Prototypal inheritance
  Every 'object' is mutable bag of string indexed properties
There's a pile of differences, even just at the semantic level before you get into the syntax or the equivalence semantics.

I understand that if you take a specific subset of javascript, you can write code as-though it has some scheme semantics (minus call/cc and TCO), but that's true to a similar extent of any language with lexical scope, closures and anonymous functions.

Re: PHP: The Right Way

#212

Post by bjt »

kaolinite wrote: post #156
kaffeinecoma wrote: post #58

Earlier quoted context omitted.

user: kaolinite 20 year old Python/PHP/C developer That font will be just perfect for you in about 15-20 years.

In 15-20 years, I will zoom as required. The issue really is less the font size and more the way the text stretches to the window, so if you zoom out then the sentences become far too long. I ended up having to alter my browser window size. Edit: Just checked, definitely just the stretching, though a bit smaller would be better for me.

Tangentially related: Smashing Magazine recently did an outstanding article on readable web typography. (See http://www.smashingmagazine.com/2012/05/02/applying-macrotyp...). They say 8-12 words per line is ideal, though their example exercise seems to average closer to 15.

Re: PHP: The Right Way

#213

Post by countessa »

this is great stuff - I'm a casual php hacker and this is just the sort of thing I need to help me out when I'm working in the language - saves me from having to be deeply embedded in the culture of a language I don't use "all day every day"....so thanks!

Re: PHP: The Right Way

#214

Post by smsm42 »

ufo wrote: post #153
smsm42 wrote: post #142

Earlier quoted context omitted.

You are completely correct - you are being unfairly prejudiced by judging PHP on explanations of people that do not understand it instead of learning it. If you learned it, you would know references work exactly like they supposed to, and do exactly what they are meant to do - just because they are not, as parent assumes, pointers, he misunderstands them and thinks they are weird. Moreover, he thinks since PHP in not…

I think the whole point here is why does PHP even have references like that. Right now the only mainstream language I know that does that is C++ and well, its C++ and mutable references are actually not frequently used in practice. Most other languages stay with pass by value most of the time and PHP references kind of look like a leaky abstraction from the underlying C implementation...

C++ references and PHP references are completely different beasts. PHP references like Unix hardlinks, for example. As for why they exist - they make doing some things easier and some use cases easier to program, without introducing concepts like pointers which are completely foreign to language like PHP. Could we do without them? Yes, probably. That's only one way to solve it, there can be others.

Re: PHP: The Right Way

#215

Post by smsm42 »

LnxPrgr3 wrote: post #189
smsm42 wrote: post #140

Earlier quoted context omitted.

You think PHP is weird because you don't understand references. Reference is not a pointer, PHP doesn't have pointers. Reference is variable binding. $a =& $b is not an assignment. It is a binding - it means $a and $b are now bound to the same variable/value.

No, I do understand references. I'm just trying to explain how references in PHP are very, very different from references or pointers in any other language I'm aware of, and how they could be confusing to people who know other languages well but are less experienced with PHP. Perl does have a similar concept, but it calls it aliasing. Perl references behave more like what you'd expect coming from other languages. I w…

Why PHP references should be like pointers? It is "confusing" only if you have wrong preconception about how PHP references should be. If you let it go and learn what they actually are, there's nothing confusing about it. Just don't let you preconceived notion about what it "should" be block your learning about what it actually is.

Most of "other languages" similar to PHP don't even have concept close to references, except for C++. Similarity with C++ may be briefly confusing, but it's not unheard of that in different languages concepts meant to achieve the same thing work differently. Expecting PHP would match C++ in every detail or would have to invent completely new terminology altogether makes little sense.

>> What's the benefit of doing it this way instead of the way just about every other language ever does it?

"Every other language ever" doesn't do it in any particular way. Perl has pointer-like references and they are nightmarish to work with. Languages like Ruby or Java pass everything by value or by object reference depending on how you look on it, since everything is an object. Some don't have the concept of references all. Low-level languages like C/C++ have pointers. In some languages variables are not mutable, so the whole question is moot. Saying that "every other language ever" does some specific thing in this regard and only PHP does it differently is meaningless - different languages do it completely different, and PHP has its own way. It doesn't match your favorite one - fine, everybody is entitled to have one's favorite ways, but that does not make PHP "weird" or wrong in any way, just as it doesn't make C, Java, Python or Perl wrong.

Re: PHP: The Right Way

#216

Post by smsm42 »

_ikke_ wrote: post #174
smsm42 wrote: post #128

Earlier quoted context omitted.

What's wrong with filtering input? If you expect a number, what's wrong with telling the user "strawberry pie" is not a valid value?

There's a fine line between filtering and validating. What's meant with filtering is things like add_slashes and mysql_real_escape_string, a uniform transformation on the input, regardless of it's destination. Validating on the other hand is checking if the values satisfy the expected requirements. You only want to apply certain filters if you know they apply the current output. (htmlentities if output as html, mysql…

Filtering can't be done "regardless of destination", of course, since kind of filtering depends on the required result. Otherwise, difference between filtering and validation is largely in application semantics - some may prefer one, some another. Output is different things, of course filters can be applied to the output too.

Re: PHP: The Right Way

#217

Post by smsm42 »

mikeash wrote: post #185
smsm42 wrote: post #127

Earlier quoted context omitted.

This illustrates very common problem with people trying to criticize PHP. First you demand some "foundations". But if you look on virtually all existing popular languages, none of them were designed exactly in the form they are now. Java had tons of changes and additions, Python had object model change and now has new version that changed so much that it's not even backwards compatible, etc. etc. Does it mean they la…

That bug is not a big deal by itself, but the circumstances surrounding it are a symptom of severe problems with how PHP is developed.

I don't see any "severe problems with how PHP is developed" that have any relation to this obscure issue, only importance of which is in its use for bashing PHP.

Re: PHP: The Right Way

#218

Post by Morg »

If only the people giving advice knew what they were doing ...

- php's filter functions : useless, you'll end up cooking up some regex anyway ( be it manual or metadata based)

- pdo ? why ? native drivers can be just fine

- binding parameters instead of sanitizing ? want another hammer maybe ? everything looks like a nail to you obviously.

- password hashing. why should it take place in php specifically when it's one of the slowest layers - and when you could ask the dbms to do it - it's a design choice but are you making the right one ?

Once again . don't call it "the right way" if you don't know the right way, mkay.

Re: PHP: The Right Way

#219

Post by adient »

anthonyb wrote: post #141
zdw wrote: post #124

Earlier quoted context omitted.

Seeing as you can remove said code via apt, you'd likely win them over compared to the alternative of being told to install compilers or some other non package managed software bundler like cpan/rvm/npm that can't be canned and easily deployed.

But why would you remove it? Because whatever you've installed has broken. Much better not to be broken in the first place.

It seems you live in an idyllic world far, far away from reality.

Re: PHP: The Right Way

#220

Post by brohee »

zdw wrote: post #42
aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

RVM's installation is similar: https://rvm.io/rvm/install/ A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer. Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.

It's not the nineties anymore, MD5 doesn't protect you from much, and especially not from the author of the original package creating an alternate version.

Viable verification is based on an unbroken hash (preferably SHA-(256|384|512), but SHA1 still not broken even it it's definitely too short nowadays. And the hashes need to be distributed properly, either PGP signed or hosted on a trusted TLS protected site...

Yet many projects still distribute MD5 hashes, thinking it got any value.

Post reply on HN