Hacker News Reader

Comment by AlexanderDhoore | Hacker News Reader

I wonder how hard it would be (for me) to take php and change all function names to be consistent. All PascalCase and spelled out (no awful abbreviations). Then download the documentation and change it there as well.

View on HN

Ahh yes, take the most criticized aspect of Java -- the obscene verbosity -- and cram it into PHP. Sounds wonderful.

I'll take a long function name over an incomprehensible one any day.

Given that many of PHP's method names are that way due to mirroring C (and others due to the hash table hackery), I think you'd just be much happier in a different language.

Expanding abbreviations doesn't improve clarity.

E.g. XMLHttpRequest vs ExtensibleMarkupLanguageHypertextTransferProtocolRequest

and ftp_ssl_connect vs FileTransferProtocol_SecureSocketLayer_Connect

or if you want to get really ridiculous:

MysqlndUhConnection::sslSet becomes MyStructuredQueryLanguageNativeDriverUserHandlerConnection::SecureSocketLayerSet

You're misrepresenting his position pretty badly. XMLHttpRequest is a comprehensible name. "MysqlndUhConnection" much less so.

Not being very familiar with PHP, I don't have any pet examples of inconsistent names to offer corrections for that might correspond with what he's actually talking about.

yeah , some people think it's easy to understand what strstr does...

...like everyone who has learned C or its derivatives. It's just part of the vocabulary of the language. You could as well ask "what's a list comprehension" in Python, for example.

Set comprehension is a standard mathematical term (http://en.wikipedia.org/wiki/Set-builder_notation). List comprehension is a fairly natural name given that.

While you're at it why don't you fix: (needle, haystack), (haystack, needle)? :P

With array functions, the needle is first. With string functions, the haystack is first.

https://gist.github.com/salathe/1672543

Are you sure it's that consistent? I just feel like there's some function hiding somewhere that breaks this rule.

This still doesn't convince me it was ever a beneficial design.

I didn't claim it was beneficial, just consistent.

Or even use a proper IDE to code other than gedit/notepad !!

The function names come mostly from C, so it's not really PHP's fault.

It _is_ their fault, for repeating the stupid mistakes that Kernighan, Ritchie, et al made when designing Unix and C.

Short names weren't really a mistake when K&R made them.

Yes, for some time (the dark ages I like to think) programmers had to sacrifice productivity to make things faster, or to make them fit in memory. The original C compiler had a 6 character limit on variable names, leading to abominations like `strstr()`.

Fortunately, by the Pentium era, which was when PHP was designed, those times were long gone.

"X made this design decision before us" is never a good justification for any design decision unless the decision is truly arbitrary (i.e., are arrays 0 or 1 indexed?) -- then it might be better to stick to what's more familiar. If it was a good design decision then, then there must have been some reason at the time that should be true now to give a good case for repeating a design decision.

I find the juxtaposition between PHP's short function names taken from C, and things like T_PAAMAYIM_NEKUDOTAYIM to be rather funny.

recently(not quite) there was a talk in php internals about changing that.

read this:

http://philsturgeon.co.uk/blog/2013/09/t-paamayim-nekudotayi...

Well, so long as they don't fix the parsing of octal int literals that is okay. Loosing both of my favourite offhand complaints would be rather disappointing. ;)

Never seen that one, but I think it's cute.

The verbosity of Java has nothing to do with long function names.

The verbosity is not only comprised of long method names.

Ironically, the obscene verbosity it is also a common trait of "not very smart" people.)

First you'd have to make sure your string hash function isn't strlen.

I thought this was a joke at first....

You can write wrapper functions in a PHP script and include it your index.php.

e.g.

  function findFirst ($haystack, $needle, $before_needle=false, case_sensitive=false) {
    if (case_sensitive) {
      return stristr($haystack, $needle, $before_needle);
    }
    return strstr($haystack, $needle, $before_needle); 
  }

You can submit them as RFC to https://wiki.php.net/rfc and maybe your suggestion end up in a future version of PHP. As PHP code in HHVM is almost as fast as C++ code, your wrapper functions will be still useful for you in the meantime.

On paper the lack of consistency is a problem. In reality your editor will autocomplete the function name and tell you its arguments, so it's really not that big of a deal. I mostly hear non-PHP programmers complain about it.

Seriously, it's not that big of a deal.

It wouldn't be that hard if you did it in userland (i.e. pure PHP). But you also need to switch around inconsistent parameter orders (e.g. haystack vs needle) and disable the use of the old ones (which can't really be done w/ the pure PHP aliases). The docs are just docbook, but have had a ton of work, you'd be best to PHPDoc your new methods.

The problem is speed and compatibility. If you did it natively you'd have to do it twice, once for HHVM and once for the Zend engine. If you did it in pure PHP it would cause performance issues since the interpreter isn't smart enough to inline (maybe HHVM is, but even it will take a trace or two to realize the JIT need probably).

While you're at it, convert intrinsic types to objects too, while retaining backwards compatibility:

    $foo = 'bar';
    echo $foo->length(); // 3
    echo strlen($foo); // 3

This would get rid of a lot of the confusion around string function names.

This was making the rounds recently: http://news.php.net/php.internals/70691

Basically, if you use PHP you're part of the largest computer joke in history.

"PHP you're part of the largest computer joke in history" <-- Good Luck with Scaling Ruby/Python

Python scales quite fine actually (Disqus and YouTube use it for a majority of core development). It's all about the tech behind the scenes (uWSGI, Tornado, Ngnix, memcache/redis, etc), not the language itself (just as it is with PHP). Try scaling PHP if only using Apache Prefork instead of mod worker + php-fpm or Ngnix + php-fpm and you'll see what I mean.

I have no problem with using either PHP or Python on a particular project, depending on what is involved. I wish PHP threads would show a bit more maturity/pragmatism on both sides of the aisle sometimes.

http://yougov.github.io/pycon/slides/

http://highscalability.com/blog/2012/3/26/7-years-of-youtube...

http://www.slideshare.net/jinaljhaveri/scaling-python-webapp...

http://blog.disqus.com/post/62187806135/scaling-django-to-8-...

Reply on news.ycombinator.com