Bayle Shanks's website: notes-computer-programming-programmingLanguageDesign-prosAndCons-php

" here's no good reason for the mess of strFunc, str_func, string_func, funcstr,"

---

ok, this is kind of screwed up i guess:

http://imgur.com/7unV7

note that (0 == "0") == TRUE, (0 == "1") == FALSE, (0 == "php") == TRUE, (0 == NULL) == TRUE, (1 == "php") == FALSE

xd 19 hours ago

link

"It’s a pity some people still build important apps in PHP..."

Getting real tired of seeing these baseless statements from so called software professionals.

Here is an off-the-top-of-my-head list of features of modern day PHP:

yield
event
pthreads - yeap, real threads.
closures (including support for $this)
consistent hashing api
"finally" added to try-catch
empty() now supports expressions, rather than only variables.
array and string literal dereferencing
foreach support for list() - foreach($array as list($var, $var))
array_column
traits
short array syntax
namespaces
json manipulation is second to none.
runkit - all kinds of danger here

" Part of the reason PHP is such a disgusting mess is because it is a raft of haphazardly accumulated features." -- https://news.ycombinator.com/item?id=7029682

---

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

https://news.ycombinator.com/item?id=3820431

http://forums.devshed.com/php-development-5/php-is-a-fractal-of-bad-design-hardly-929746.html

grey-area 17 hours ago

link

 He probably didn't elaborate because he felt the basis for the view was clear - there are clearly areas of PHP which still need work. PHP is often frowned upon because the APIs are a mess of legacy cruft like addslashes, magic_quotes, mysql_escape_string, mysql_real_escape_string, mysqli_real_escape_string versus prepared statements. Efforts are being made to clean it up, but for a language to ever end up in a place with that sort of library functions is a pretty big red flag.

cowsandmilk 11 hours ago

link

mysql_escape_string [1] mysql_real_escape_string [2]

Why is exposing a C library's functions and their names PHP's fault?

[1] http://dev.mysql.com/doc/refman/5.5/en/mysql-escape-string.h... [2] http://dev.mysql.com/doc/refman/5.5/en/mysql-real-escape-str...

Joeri 6 hours ago

link

Because php ends up combining the API consistency of C with the syntactic elegance of visual basic. I say this as someone who programs php professionally, the fact that they still haven't provided a complete set of OO api's very much speaks against the language stewards. PHP could have a sane subset, like javascript, but because there are gaps in the API (like the string and array API's, which are horrible) you can't get a sane subset without adding some extra API wrappers of your own.

And that's why it's impossible to build frameworkless PHP code that is elegant, something that even the designed-in-10-days javascript lets you do.

xd 16 hours ago

link

Check the manual; magic_quotes, mysql_escape_string and mysql_real_escape_string have already been deprecated/removed.

grey-area 16 hours ago

link

I'm aware of that thanks, as noted in the last line:

Efforts are being made to clean it up, but for a language to ever end up in a place with that sort of library functions is a pretty big red flag.

Sanddancer 13 hours ago

link

Yes, php is more checklist complete than it was a few years ago, but there's still quite a bit of ugliness in the language. For example, you mention

closures (including support for $this)

I looked at this a couple days ago, because closures make a lot of problems easier. However, PHP's handling of closures is more than a bit ugly and hackish. Yes, it supports $this, but this was done after the initial release, doesn't give much confidence in how it's handled under the hood. Plus, you have some real syntactic ugliness; in order to scope variables into a closure, you have to declare them again with a now overloaded keyword -- use -- with them passed by value by default. Closures in pretty much any other language, you just put them in the scope of your function and the compiler/interpreter knows how to handle them without any hints from you.

The only PHP inconsistency is with the naming of the built-in functions. Functionality wise, most are solid bindings of respected C libraries. And, really, the needle/haystack thing has been blown out of all proportion. As if that's the biggest challenge one faces when programming.

Joeri 6 hours ago

link

Speaking as someone who has written hundreds of thousands of lines of php over the years, i think php's main problem is not that it lacks features, but rather that it doesn't have a sane subset, a javascript-like 'good parts' if you will. PHP added OO api's for date and database handling in the 4 to 5 transition, but it never got around to doing the same for strings and arrays. So frameworkless php is by necessity a mixture of procedural and OO code (unless you go pure procedural), and always looks ugly. PHP's stewards could solve this by bringing all the API's into the OO fold, and I have experimented [0] with what PHP could look like if strings and arrays were objects, but so far this hasn't happened.

[0] https://github.com/jsebrech/php-o

[1] http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

abvdasker 12 hours ago

link

Call me crazy, but PHP JSON manipulation is maybe second to node.

krapp 5 hours ago

link

Node as javascript does handle the object notation natively, which is an advantage over PHP in terms of handling JSON. Which, coupled with the (recently corrected) awkward syntax for arrays, unfortunately makes PHP's most common pattern (conversion of SQL data into arrays and maybe into JSON) more of a hassle than it should be.

-- " The Case Against PHP: Unexpected behaviors:

$x / 0 => bool(false)
“11abcd” + “1xy” => int(12)
“0123” + “3456” => int(3579)
“0123”

“3456” => string(“3577”)

The Case Against PHP (2) Schizophrenia about value/reference semantics: Probably copy $a into foo’s 0’th param. Unless $a is a user-‐defined object; and unless foo’s definition specifies that arg 0 is by reference:

    foo($a);

The Case Against PHP (3): Reliance on reference-counting

  String, array need O(1) logical copies
  User-defined classes have destructors that run at a deterministic time
  Some programs use the RAII idiom from C++
  Heavily constrains implementation

The Case Against PHP (4): Inconsistent, dangerous standard library

  array_map vs. array_reduce argument orders
  array_merge
  mysql_escape_string vs. (sigh) mysql_real_escape_string

The Case Against PHP: “Guilty”

  It’s all true!
  These are “unforced errors”
  Most other languages do better
  You would want to avoid them in a PHP Reboot

In Defense of PHP: PHP gets three important things really right

  Programmer workflow
  State
  Concurrency

Workflow

  Save, reload-the-page
  Short feedback cycle
  Optimizes most precious resource of all: programmer short-term memory

State

  PHP requests always start with empty heap, namespace
  Cross-request state must be saved explicitly
  Filesystem, memcache, APC
  Affirmative virtue
  Typical FB requests spend 10ms initializing
  Reduces the cost of bugs
  Requests interact in limited ways
  Natural boundary for failure isolation

Concurrency

  PHP requests execute in a single thread
  Concurrency happens via recursive web requests
  shared-nothing
  inputs/outputs copied
  Limits PHP’s applicable domain
  That’s actually good. "

-- http://www.slideshare.net/zerutreck/taking-php-seriously-keith-adams , http://www.infoq.com/presentations/php-history?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013 (that presentation also talks about Hack, a gradual typing system for PHP)

---

an interesting PHP vulnerability:

https://blog.nearlyfreespeech.net/2009/11/05/a-php-include-exploit-explained/

lectrick 3 minutes ago

link

Given a programming task, it will be written faster, easier, and in a more maintainable and less bug-prone fashion if it is not PHP.

The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job.

Let's begin.

1) PHP autocraptastically converts strings that look like numbers, into numbers, resulting in all sorts of weirdness like this: https://eval.in/111886

2) PHP 5.4's OWN TEST SUITE has 91 failures and only 70% coverage. There is NOTHING more "WTF" than that! Why even bother having a test suite?? http://gcov.php.net/viewer.php?version=PHP_5_4

3) Why the fuck are all of these different things equal, and how does this NOT result in problems?

4) String increment is dumb to begin with, but why does it not even match the behavior of string decrement? https://eval.in/60631

5) Why the hell can you jump back into a try block from a catch block? Recipe for disaster: http://phpmanualmasterpieces.tumblr.com/post/33091353115/the...

6) PHP comparison operators. I'm sorry, but this level of complexity might make you feel smart once you master all its idiotsyncrasies [sic], but it's actually dumb: http://stackoverflow.com/questions/15813490/php-type-jugglin...

That's a small fraction of not-thought-out PHP language features that result in REAL bugs and security holes. Which consume large swathes of programmer time. Which, apparently, Facebook can afford to swallow.

I'm sorry, but your position, as valiant as you are defending it, is literally indefensible.

---

" And, closures in Python -- and to be fair, just about any language that isn't PHP -- close over variables in the scope they're defined automatically, without having to use PHP's strange "use ($a, $b, $c)" construct. Yes, that's a small thing, but PHP's way is a little bonkers."

https://wiki.php.net/phpng-int

---

donatj 17 hours ago

link

Despite peoples grumblings about parameter order the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack. Once you know that its not that difficult.

Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, whereas on map you can map a list of arrays.

chriswarbo 13 hours ago

link

Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right:

    $asBools = partial_apply('array_map', 'boolval');

    $asBools(['hello', '', 'world']) === [true, false, true]
    $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true]

array_filter and array_reduce get this wrong, requiring awkward argument-shuffling:

    $inverseFilter = partial_apply(flip('filter'), 'boolNot');

    $inverseFilter([-2, -1, 0, 1, 2]) === [2 => 0]
    array_keys($inverseFilter(['foo' => true, 'bar' => false])) === ['bar']

    $allTrue = partial_apply(flip(partial_apply(flip('array_reduce'), 'boolAnd')), true);

    $allTrue(['hello', 'world']) === true
    $allTrue([true, true, 0, true]) === false

Note that a) if specialisation was easy, there would be no need for default arguments and b) having default arguments at the end is exactly the wrong way around for making specialisation not suck.

We could sweep this under the rug by saying it's awkward because it's not idiomatic PHP; but one reason why it's not idiomatic is that it's awkward!

Just look at Javascript, where functions are slightly less awkward; there are lots of functional APIs in wide use, eg. Underscore.

jules 9 hours ago

link

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

donatj 6 hours ago

link

I feel like its callable system is simple, easy to use, and frankly awesome.

I can do $func = ['object', 'staticMethodName'];

$func = [$instance, 'publicMethodName'];

$func = 'functionName';

$func = '\namespaced\functionName';

$func = function(){ ... };

$func = $callableObject; ( http://php.net/manual/en/language.oop5.overloading.php#objec... )

I can execute any of the above by calling `$func('doIt');`

Moreover all of those will all pass a `callable` typehint on a method call as well as the is_callable if they exist and are callable. Its quite powerful.

wvenable 6 hours ago

link

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.