Myself, I like this proposal.

And it doesn't make a language 'dynamic'. The language I found with UFCS is both static and compiled.

What's left is [1,2,3]->slice(1,2) versus [1,2,3].slice(1,2)

ps: dynamic can be compiled and compiled can be interpreted, so I understand that it is unrelated.

Which means you will see old function based implementations and new object based implementations.

Image dealing with both implementations within the same code base? Eek.

Yes, things are being improved. But in terms of language usability and consistency, PHP is still miles behind pretty much everything else, especially given the slow deployment of new versions of PHP. As for "unfounded criticism"... some particular inconsistencies have been fixed, but the original criticisms are still valid - they just apply to different things now.

If you look into the way the PHP interpreter actually works internally, you'd rapidly find that suggestions like "methods one can call on the objects themselves" is more or less an impossibility. As far as I'm aware, rather than treating base types as special kinds of objects, PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture.

I'm absolutely not an expert on the internals of PHP - but from the design flaws that leak through at times, it becomes obvious that the PHP internals consist of a lot of hard-to-maintain code bloat, and that code reuse/abstraction is not as common as it should be. One particular example I ran across myself was this: http://www.reddit.com/r/lolphp/comments/1twal5/really_php_re... (the paste no longer exists, sorry for that).

Most platforms treat scalars as entirely different types at some level and then paper over the differences. As for the PHP architecture, I've actually looked into this, and it would take only one small change to the method-call code to add methods to scalars. In fact, the design of PHP makes this surprisingly easy to add.

Criticism doesn't become unfounded because things become better. Things become better because of criticism.

(I'm not going to weigh in on whether any of the criticisms have been resolved in PHPs case specifically, as I've been away from PHP long enough to not be able to talk on any problems with the current language)

Part of that is due to the share amount of code out there doing things bad ways that were almost encouraged years ago, and tutorials still out there teaching people to do things the old less good ways.

Of course a lot of it is people who haven't touched the language for many years (such as myself) who are at this point a lot less informed than they think they are!

Another issue is that the new frameworks seem to get the positive news, not the core. The language use to describe PHP related libs/frameworks is different in my experience which makes a perception difference: PHP frameworks are often referred to as "making PHP behave" or "removing the cruft from your workflow" where frameworks for other platforms would be described as "helping you make the most of <platform>" and "increasing your efficiency".

https://www.youtube.com/watch?v=b5I94bT23cQ&t=1m34s

As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals

For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example:

    $my_anon = function() {};

    function my_named() {}

    // Valid
    array_map($my_anon, []);

    // Invalid
    array_map(my_named, []);

    // Valid
    array_map('my_named', []);

    function smart_replace() {
      $args = func_get_args();
      $func = array_shift($args)? 'str' : 'preg';
      return call_user_func_array("{$func}_replace", $args);
    }

    $foo = "hello";

    $object1->$foo = $object2->$foo;  // Sets $object1's "hello" property to $object2's

    $object3->$foo();  // Calls $object3's "hello" method

    $bar = "foo";
    echo $$bar;  // Outputs hello

    array_map('str_' . $_GET['string_function'], $my_array);

in your final example, you can replace the map with a big case switch of all known functions and an error clause.

That's of course, a lot of work. I'd guess it's just not worth it.

The parent was saying we could swap out all usages of 'old fashioned' functions like str_replace for some 'new fashioned' alternative, like String::replace, using some kind of upgrader tool.

I was pointing out that the PHP's eval-like features make it difficult for any such tool to exist. In particular, with Python or Javascript we might spit out a warning "Eval spotted; this upgrade might not work!". If we did the same in PHP, everyone would get a warning! "String used as function detected; this upgrade might not work!", "Variable variable detected; this upgrade might not work!", and so on.

And that's ok. There's a million things I'd like to see before people start trying to "fix" an stdlib that's been around for so long.

You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're trying to make it sound.

I'm not really sure I follow the logic that if someone has an issue with the state of a programming language then they shouldn't be developing. How does that make any sense?

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.

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

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

    $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

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.

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.

Though who am I kidding, PHP is also confused between numbers and arrays and strings, so I guess at least it's consistent that the language is thoroughly crazy.

Very little about PHP's treatment of functions is easy or clean.

    function foo() { echo "Hello world"; }

    $w = 'foo';
    echo $w;  // foo
    $w();     // Hello world
    'foo'();  // PHP Parse error: syntax error, unexpected '('

    function bar() { return 'foo'; }
    $x = bar();
    echo $x;  // foo
    $x();     // Hello world
    bar()();  // PHP Parse error:  syntax error, unexpected '('

    $o = new stdClass;
    $o->baz = 'foo';
    $y = $o->baz;
    echo $y;  // foo
    $y();     // Hello world
    $o->baz();  // PHP Fatal error:  Call to undefined method stdClass::baz()

    $z = function() {
           echo "Hello world";
         };
    $z();  // Hello world
    (function() {
       echo "Hello world";
     })();  // PHP Parse error:  syntax error, unexpected '('

[1] https://wiki.php.net/rfc/uniform_variable_syntax

There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack.

So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle.

I'm not really commenting on whether one should have to remember this, only that it helps if you need to remember it.

wait, what's the difference?

Have any good examples? I haven't used the language in years, would love to see what "modern" PHP looks like. (Seriously, not trolling at all)

[1] http://laravel.com/

Frameworks and languages are a lot like databases. They all achieve the same thing, they're just all slightly different and good for different purposes. I sometimes use MySQL, other times I'll use PostgreSQL, sometimes I might use a graph database like Neo4j or other times I might even use something like MongoDB.

The Rails community has been around a lot longer than Laravel's community, so you can't even compare them. The only community worthy of being compared to Rails is Codeigniter's and at the peak of Codeigniter's popularity, I would argue Codeigniter had the bigger community. Laravel is a mere couple of years old, the community is already pretty strong. Lets reevaluate soon when the right amount of time has passed and then see where the community is at. You only have to look at the amount of Github stars to see how popular it is.

MySQL vs PostgreSQL vs MongoDB vs Neo4j are all data stores with very different principles and goals. To say they all "achieve the same thing" is like saying an airplane is the same as a speedboat because they both get you from point A to point B.

I certainly believe that frameworks and libraries are tools for different problems and there isn't a one size fits all approach, I just have trouble discerning what problem Laravel is solving better than other frameworks or what makes it advantageous to use.

PHP is ubiquitous on shared hosting platforms, there aren't that many "shared" Rails hosters out there. Morts still use shared hosters.

Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.

Leaving aside the whole "PHP sucks" vs "PHP is great/fine for my purposes" thing, this is really breathtaking. The fact that you can just FTP up your folder does not mean that's a sensible best-practice way to deploy anything, PHP, Ruby, Brainfuck or whatever you like. It isn't. FTP is insecure[0]. If you're balking at 'git push', then presumably you're balking at source control, which involves a lot of that sort of thing. That is just entirely unprofessional.

And 'no replacement'? FTPing a bunch of stuff into a public folder allows you to deploy something quickly and easily. So does the GP's suggested workflow. It is, exactly, a like for like replacement - except that it's a more secure and less fragile workflow.

I repeat - this has no bearing on the pro/anti-PHP holy war (I lean towards anti, but there's good PHP code out there, whatever. Hopefully a proper language spec will shove things in the right direction). If your argument for PHP is that it allows you to easily evade responsible working practices in software development, however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer.

[0] http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security

Really [0]?

>however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer

I think you're getting dangerously close to coming off as condescending and insulting.

Despite what you may think, plain old fully managed shared hosting is still massively popular, especially here in the UK.

Our client base are design and development houses who want a reliable, tinker-free fully managed, predictable and secure environment. These folks aren't as backwards as you think, they already have a development workflow that works just fine. They push their stuff to their htdocs folder (via FTPS) and it just works. We even support WebDeploy (also secure) on the Windows platform so they can build MS deploy packages and push them up.

Most of our clients do use source control, they're not that naive but not all of them have drank the Github Koolade. They're happy with their own private source control arrangements.

It's an environment and process that's tried and tested so they can get on with building apps that pay the rent and keep the lights on without futzing about with dynos and droplets and the like. Not only that they can pick up the phone and within two rings get access to an experience frontline engineer who will fix a problem or answer a question within a couple of hours.

I can speak about this from experience as an engineer who works for a UK shared hoster. Admittedly we're not a bulk shared-hoster like GoDaddy, our services are tailored towards the needs of business clients, not someone's granny deploying a Wordpress site with pictures of cats.

[0]: http://en.wikipedia.org/wiki/File_Transfer_Protocol#FTPS

Even if I can configure it down to two clicks it still comes with the cost of having to worry about maintaining a VPS.

traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that.

You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid workflow for a lot of people who don't want to be sysadmins in addition to developers

Kiro quotes two items from the parent, and says he doesn't want to be bothered with "those" things.

Kinda implies he doesn't use git, since that was one of the two items quoted.

... using mostly 3rd party components, the majority from Symfony. So no, it's not "built by one guy".

It would be in the best interests of Laravel for Symfony to succeed, but you have to realise they're targeting two different subsets of users. I think what makes Laravel more appealing to me as a developer is it takes the good from the likes of Symfony, takes the great documentation and accessibility aspect from Codeigniter all while remaining a relatively soft opinionated framework, it provides you with a structure but the IoC container means you can structure it however you want. The Blade templating system is fantastic, the ORM is feature-rich and very powerful and the addition of database migrations right out of the box.

There isn't a lot of different between Laravel and Symfony considering they share similar components and the unique selling points of Laravel are components that can be used within a Symfony 2 application. I think Laravel gives you a little more out-of-the-box, whereas Symfony makes you add what you need and I can see the benefits from both sides of the fence. If you want to compare frameworks, a real comparison would be Laravel and Silex.

One aspect I like about Symfony is the ability to define routes 4 different ways; YAML, PHP, XML and Annotations in a controller. Compared to Laravel's routes.php file. If you're a developer that wants to customise absolutely every single aspect Symfony is probably a better choice, if you're happy with the guiding hand Laravel gives you out-of-the-box and don't care what format your configuration files and routes are written in (amongst other aspects), Laravel is the better choice. The learning curve of Symfony is far higher than Laravel due to the amount of configuration it allows you to do and the fact it is completely unopinionated.

So, while Taylor didn't build every aspect of the framework (a very well-known fact), there are certain aspects he did build specifically for Laravel. He also took the time to piece all of the components together from Symfony and other authors to create what is arguably one of the most developer friendly PHP frameworks since Codeigniter hit the scene in 2007. Before Laravel came along, I can't recall anyone else attempting to make a consumer friendly framework, can you?

Laravel on the other hand is exactly where Codeiginiter was: easy to pick up, and easy to write crap code in. The whole Facade nonsense is already being abused to no end, not to mention the ORM, Eloquent. Similarly to CI, if you want to do something remotely advanced with it, you end up reading the code constantly, because the "great" 10 page documentation is only for absolute beginners.

The best example has to be the templating languages used. Blade is a weird port of ASP.NET MVC's Razor syntax and I've never understood why anyone would use it over Twig (or even just raw PHP).

It's weird that a framework so self-consciously dedicated to 'best practices' would ignore what's considered one of, if not the, best templating systems in PHP. Particularly given the extra benefits twig provides out of the box (automatic escaping, a function sandbox, hooks for writing your own plugins and parsers, etc.)

http://www.phptherightway.com/

Sometimes I feel we're getting too close to Java territory in terms of abstraction and reliance on libraries, but that would also be a sign of maturity.

I just came back to PHP myself after 4 years away and have been pleasantly surprised. A lot of it has been community driven with things like the PHP-PSR standards and Composer, in additional to all the language features that have hit since 5.3

[1] http://blog.vjeux.com/2014/javascript/hack-is-to-php-what-es...

http://php.net/manual/en/migration54.classes.php

http://php.net/manual/en/migration53.classes.php

http://php.net/manual/en/migration53.new-extensions.php

In 5.5 they didn't add a bunch of new extensions or classes, but they did add generators and finally.

http://php.net/manual/en/migration55.new-features.php

They haven't taken to packaging up arrays or strings yet, but I wouldn't doubt you'd see it over time.

Not a big deal.

EDIT: i totally agree that the standard functions are a complete mess in PHP. But they have to stay around for backwards compatibility. Have a look at the SPL classes: http://php.net/manual/en/book.spl-types.php

For example, how would I make a string abstraction? Create a class? Ok, so we have:

$str = new String("foo") $str->replace(...)

over

$str = "foo" str_replace($str, ...)

This is fine, if we ignore the fact it's much slower.

Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do

$str->concat($str2)->concat(new String(" "))->concat($str3)

instead of

$str . $str2 . " " . $str3

There's things you can do to make the API a little bit more convenient (i.e. allow it accept PHP strings, etc.), but ultimately it becomes a huge pain, especially if you want to start interoperating with other libraries that are using a different abstraction or, more likely, using the regular PHP types and functions.

    "foo".replace('oo', 'ood') + " tasty"

> $str->concat($str2)->concat(new String(" "))->concat($str3)

> instead of

> $str . $str2 . " " . $str3

Erm, no you wouldn't. What's wrong with either of these?

    String::implode($str1, $str2, new String(" "), $str3);
    String::sprintf("%s%s %s", $str1, $str2, $str3);

Personally, I'd prefer operators to have function equivalents, so your example could be written:

    array_reduce([$str1, $str2, " ", $str3], '.', "");

This is not PHP, this will never be PHP. Some people need to remember the purpose for which PHP was started and what it still is great at: making websites.

You guys are stuck in high brow academic debate on the semantic of a language that was born before many of us started coding, and that helped the web become what it is today. And that has come a long way.

I'm not saying to stop improving the language, but as someone who has used PHP for 15 years, all the issues I see come up constantly in threads like this are non issues, never encountered them in any web situation, you have to seek these "bugs"/annoyance, or be seriously inexperienced with PHP, or as I've been saying for years any time I do conferences: you are using PHP wrong.

So please, keep your verbose syntax in other languages that "need" it, while there are improvement to be made on PHP, this is not an area that needs one.

Also, looking at your bug submission/request, I share krakjoe sentiment: what the F are you trying to achieve? Seriously, I am curious. To me it screams wrongly used PHP.

Of course it's wrongly used, since it doesn't work (hence my request to make it work).

The issue is not whether we should write such code now (we obviously shouldn't, since we'll hit all kinds of language problems); it's whether we'd like to write such code in the future (in which case we need to fix those problems now). Personally, I would like to avoid redefining built-in capabilities over and over.

As for what I'm trying to achieve, the same as everyone else: clean, understandable, maintainable code.

Here's something I ran across this week. I'm instantiating a class $class (read from a config file) and need to inject dependencies ($dep_classes, read from a config file) into the constructor. How to do it?

    $deps = [];
    foreach ($dep_classes as $dep_class) {
      $deps[] = new $dep_class;
    }
    $instance = new $class(...$deps);

    $deps = array_map(function($dep_class) { return new $dep_class; }, $dep_classes);
    $instance = new $class(...$deps);

However, it's clear that, again, we're reinventing the wheel. array_map passes the class names to its callback, so why are we passing them to "new" ourselves?

    $deps = array_map('new', $dep_classes);
    $instance = new $class(...$deps);

- Use a foreach loop to duplicate the functionality of array_map. - Define a new function which behaves exactly like "new".

Perhaps 15 years with PHP has given you a "gut feeling" to avoid programming styles which will inevitably run into problems; I've certainly got such a feeling after 4 years. While avoiding those problems is useful to get a job done today, it would be even better if we didn't have to worry about them tomorrow.

There's no point adding features like array_map, anonymous functions, etc. to the language if we all have to learn to avoid them to avoid parser errors.

You'll be giving PHP devs a loaded gun by allowing them to register primitive types (as proposed by nikic). Most frameworks would add to them, but I know some people would change default behaviour to 'fix' issues such as db character encoding issues which would make debugging hell.

In your examples I am not seeing the issue? Am I missing something here? Your examples work exactly as I would have expected them to, as they would in other similar languages like Java and C++. Lets stop the hate for the sake of hating PHP, it definitely has its quirks in relation to methods and order of parameters in particular, but things are getting better and they're not deal-breakers for getting things done.

If you want to see how great things are in PHP, I would checkout the Laravel PHP framework. It is a very well built and robust framework that uses the best parts of PHP and abstracts some of the worse parts to make the experience of developing in PHP fun again.

PHP and JavaScript, however, have unjustifiable quirks with some of their most basic functionality. We're talking about stuff as basic as their comparison operators being quite broken, for example. That's where the problem is. Furthermore, the fact that these issues have been around for well over a decade or more without being properly addressed just makes the situation even worse.

Compared to other mainstream languages like C, C++, Java, C#, Python, Ruby and even Perl, both PHP and JavaScript are quite inferior in many critical ways. Perhaps things will improve over time, but we really haven't seen that happen so far.

So let's not pretend that they're "good" just to be politically correct or to try to avoid offending anyone. PHP and JavaScript aren't good languages, and they won't really improve until their communities admit that there are some very serious issues, and then commit to getting them resolved properly and rapidly.

It is a very weird argument that often comes up when discussing programming languages - "Lang X is weird/stupid in some ways, but no language is perfect, so it's fine and there is no reason to call it out."

So, because nothing is perfect (almost by definition), it apparently isn't a big deal that some things are weird/dumb/broken. And let's also just muddy the waters by implying that, since all languages have imperfections, talking about some other language's imperfections is just being pointlessly selective (even though one of the languages imperfections are much more horrible).

It's just overall a non-argument. Maybe the point is to come off as being "above" the opposite camp (which are: mindless language bashers). But it's about as intellectually stimulating as mindless language bashing: it doesn't take much intellectual curiosity or rigour to bash a language, and neither does being perfectly neutral and non-offensive by throwing around platitudes like "no language is perfect", "choose the right tool for the job", etc.

Agreed. These are just a few quirks in PHP I find amusing.

http://www.phpwtf.org/

Last I checked, it wasn't quite as good as wtfjs, but it looks like quite a few new surprises have been added rather recently.

Edit: Correction, there's only one new entry as of this year, which is a shame. :)

The other thing to consider (looking at it again, particularly at the second example) is that there are some surprising side effects that can snag newcomers, depending on their background and whatever other languages they know.

Perhaps one of the drawbacks with programming PHP is that you become so desensitized to weirdly inconsistent/surprising behavior that there's almost nothing left to be surprised about.

Most other entries involve doing something bizarre with obviously undefined consequences and then marveling that PHP does it different than they expect. Or failing to understand PHP's basic rules and then again, on edge cases, marveling at weirdness of the perfectly logical result.

The "PHP protected and an assault" entry just fails to comprehend how access modifiers actually work with the classes.

There are real PHP WTF's but honestly they were all discovered 10 years ago. Probably 50% of all entries on the site are people misunderstanding how references work over and over and over.

On the other hand, had you written "perfectly logical result (within the confines of PHP's idea of what's logical)," then I might be inclined to agree.

But yes, I made the mistake of linking the site without re-examining it. I recall seeing it first from HN some time ago (probably 2010ish) and thought it might have improved. I do believe I may have indicated its quality isn't on par with wtfjs.org, however. Take it as you will.