Disclaimer: I'm a big fan of PHP, not because I like the language, but because I like the pragmatic approach.

I think that's foolish. Redesigning a language is making a new language -- and there are lots of other new languages to choose from. What features of PHP would you want to keep that aren't possible in other languages?

Radically changing the language also leads to heavily splitting the community like with PHP4/PHP5 or Perl5/Perl6 or Python2/Python3 and nobody wants that. Backwards compatibility doesn't have to be fully maintained but it does have to be respected.

The biggest issue right now with PHP is that there isn't a clear direction on where to go. Nobody wants to "fix" some of the old problems because the gains don't seem to outweigh the costs.

That's what PHP is missing: expert mode. As it stands now it's very difficult to turn off all the traps, so experienced programmers are forced to switch to other languages. Compare this to Perl, where it has silly behavior by default, but you can turn it off with "use strict" at the top of the file.

However, I agree, all languages should have the ability to turn off the backwards compatibility crud with some kind of statement. In PHP, it would be great to do that at the namespace level -- allowing different libraries to operate at different levels of support/strictness in the same project.

But I wonder if maybe you're blind to the ways your PHP is different. Dozens of modules and hundreds of functions come directly with the language core. And very very esoteric stuff. Why does my programming language have a function to tell me specifically what day Easter is? Whaa? Why do I have to recompile my programming language to install new libraries? (PCNTL, for example).

If PHP is a salad bar, Python (for example) is prix fixe.

  wget http://www.php.net/get/php-5.3.16.tar.gz/from/us2.php.net/mirror -O php-5.3.16.tar.gz
  tar zxvf php-5.3.16.tar.gz
  cd php-5.3.16/ext/pcntl
  phpize
  ./configure
  make
  sudo make install

Of course with non-bundled extensions from pecl or github you can skip the tarball step.

pip install package_name or gem install package_name

not to mention, with bundler and virtualenv you can easily, easily keep multiple versions of different packages for different projects without any juggling and hacking your way through.

When I have time for side projects again, I'm going to make this happen for CoffeeScript running under v8cgi or node. The code for the "HTML by default" is trivial enough that I could write it in fifteen minutes. The code for the global namespace (I'd prefer a short namespace actually) stuff is a bit more tedious, and the parts with making it run a server under node and automatically parse and cache the files are the boring details that I might get stuck on and cause the project to languish. Ideally, I'd want to make it flexible regarding frontends, so that if you could get it running in any environment that accepted JS code and could wrap the built in module behavior.

The frustrating thing is that until we see more widespread support for server-side JS on reasonably cheap hosts, or at least some well-implemented JS transpilers/interpreters for commonly installed languages like Python and PHP, making this work for Joe Everydev is going to be virtually impossible.

I'd be interested in doing something similar for Python (mod_python supports something close in PSP, but nobody seems to use mod_python anymore), but while I'm capable with Python, I've never really been interested in learning the ins and outs of the "Pythonic" style, and that makes me reluctant to put any code out where the Python community can see it.

I think the way PHP is evolving is how it has always evolved. No one's thinking 5 years into the future. But I argue that they don't have to. PHP doesn't win on it's big design advantage, it wins on all of the small parts that it haphazardly releases (I don't mean that in a bad way).

This "redesign" thing you talk about would never happen. Or it happened already dozens of times, if you want. It's just called other languages, not PHP. PHP is something that it is, and it develops and gets better, but if you think the whole premise is wrong - fine, there are tons of other approaches around. That doesn't mean every topic on PHP should be accompanied by good old "yeah, that's nice, but you have to redesign it". What's the point of it?

All of PHP4's syntax is still valid in PHP5 even if it does raise a deprecated notice.

The only real thing that broke in the upgrade is if you had a LOC that was expecting an object to be passed by value. Theoretically possible but practically very very rare.

And of course config settings like register globals being changed, but that's just that: a config change.

PHP5 changed the semantics of objects entirely. Before they were value types.

Still, yes, not enough has changed IMO.

You're implying it was an implementation detail. They fundamentally changed how objects worked, the semantics, that made it completely impossible to move any of my PHP4 code over in a reasonable way.

It is possible to make code, that uses objects, work in both PHP4 and PHP5 but you have to restrict yourself to a subset of both versions.

None of the PHP4 frameworks moved over to PHP5 without a lot of re-writing.

My code simply assumed value assignment semantics and changing that everywhere was just too much work. At this moment, I still have sites running PHP4.

Were you passing around objects and mutating them while expecting the existing object to be unchanged? For example:

  $o = new MyObject()
  $o->important_data = 'clean';
  function foo($give_me_o) {
    $o->important_data = 'dirty';
  }

  foo($o);
  echo $o; // Need this to say "clean"

Frameworks chose to upgrade because you get MUCH better memory management and cleaner syntax from PHP5. But many, many people run PHP4 code in a PHP5 runtime. It works just fine. Because that example I used above -- while it is totally possible you have code like that, that's in practice pretty rare.

The potential for subtle bugs with this change is massive.

Your example is very simple. I've got objects with other objects as properties (composition), collections of objects, hierarchies of object references, as well as methods that take objects by reference or by value. Not using references everywhere is so much easier in PHP4 that whenever possible, I did just that.

It seems like one way for them to fix a lot of the old stuff while maintaining backwards compatibility would be to add new string and array (and dictionary?) classes with sensibly-defined interfaces. I imagine there are a fair number of less-obvious issues around that that make not as easy as that sounds, though.

The idea that the code flow is now no longer linear, and that the programmer now has to understand perfectly the odd rules by which the execution of code now just jumps around… boggles the mind.

A closure-based approach would have been much more semantically sane; if a little syntactically ugly. But then again, how hard would it have been to add a nicer closure syntax to PHP, instead of creating this mess of a feature?

Take this:

    def each_line_in_file
      f = File.open('hello.txt', 'r')
      while line = f.gets
        yield line
      end
      f.close
    end
    
    each_line_in_file do |l|
      puts l
    end

The same can even be implemented in PHP as it stands today, although the syntax is quite unsightly:

    function each_line_in_file($callback) {
        $f = fopen('hello.txt', 'r');
        while (null !== ($line = fgets($f))) {
            $callback($line);
        }
        fclose(f);
    }
    
    each_line_in_file(function ($l) {
      echo $l."\n";
    });

Generators and coroutines are a well-known concept implemented in many languages, in particular Python and C#. It is also part of ECMAScript Harmony as far as I know. Other languages implement the more generalized concept of continuation passing (usually providing generators implemented on top of them).

Callbacks can be used to implement some of the use cases of generators. To be more precise they can be used if the callback is stateless (as in your above case). If the callback had to handle state, you would have manually implement a state machine, making the code hard to understand and adding a lot of boilerplate.

Generally PHP does not make extensive use of callback-y programming, but does make extensive use of iteration. That's why generators integrate much better than callback based producers. The same applies to Python, that's why they too have generators.

You need to understand that Ruby has a different underlying philosophy, which is not directly transferred to other languages. What might be nice in Ruby will be considered really ugly in Python or PHP and vice-versa.

That's way too late, PHP is an imperatively styled and statements-based language, it uses iterables and external iteration, not internal. That's what the language is.

> The semantics here are clear

There's nothing unclear about generator semantics, regardless of your refusal to understand them.

> The same can even be implemented in PHP as it stands today

Not quite, PHP doesn't have non-local returns, so you soon get into annoying issues of not being able to break away from an iteration (or of having an utterly terrible API to do so, as in [NSArray enumerateObjectsUsingBlock:]

> Ruby allows the programmer to use the yield keyword to avoid having to declare the closure as an argument (`def each_line(&block)`).

So you dislike one magic but you like an other for pretty much no reason at all beyond knowing one and not the other? Consistency not your style?

The thing I love about Ruby's magic is that it's not really magic, it's an abstraction of solid fundamentals.

There's nothing really magic about ruby's yield, because it's a shortcut for explicitly declaring a closure and calling it. These are real language concepts that are well understood. PHP's yield, however, is a completely new construct. The jumping around does not follow well-understood rules (like calling a function). In ruby's case, that's what it does. It simply executes the function, and calls a closure.

In PHP now when you define a function, and then call that function; it may or may not execute the code inside that function, depending on whether later on in the function there's a `yield` keyword. That's insane!

Say you can see this in your code editor:

    public function hello() {
        // a lot of important code
        $myvar = $this->other_cool_function();
        // more code
    }
    public function other_cool_function() {
        echo "Hello, world!\n";
    . . .

It's exactly how it works in C# and Python. When you call a function, you don't care how it does what it does -- only that it returns a result. The syntax and design works this way in all sorts of languages because it's easier to reason about. I've only used generators in C# but it's amazingly simple to use. The point of an abstraction is that it hides the details. You're overly concerned with the details that are neatly and logically hidden away.

  >>> def other_cool_function():
  ...     print "Hello, world!\n"
  ...     yield 7
  ... 
  >>> other_cool_function()
  <generator object other_cool_function at 0x10081b140>

Wait, what? Numerous languages implement it in exactly the same way? Are they called "Ruby"? No? Then who cares, it's not Ruby so it must be wrong. Not just wrong, it's insane - nobody sane would implement a language that doesn't work exactly like Ruby!

  >>> the_list = [1,2,4,7]
  >>> def ruby_generator(f): 
  ...   for x in the_list: 
  ...     f(x) 
  ...     
  >>> def print_it(x): 
  ...   print x 
  ...   
  >>> ruby_generator(print_it)
  1
  2
  4
  7

I think you might be confused. I'm referring to the GP post that has the example with the yield call in it, the ruby example.

You could write code like that in PHP, and the GP post with the ruby example does so, but PHP generators do not work like that.

> I think you might be confused. I'm referring to the GP post that has the example with the yield call in it, the ruby example.

The Ruby example doesn't have the problem you mentioned because Ruby doesn't have generators at all. In Python and PHP, yield means "Suspend execution of this function and return a value to the caller, who can later call this function again to resume its execution." In Ruby, yield means "Call the block that was passed to this function with the values after yield," or exactly what I've written in Python without using the yield keyword. Ruby's "yeild line" is Python's "f(x)".

Edited: I think I understand what you mean after reading once more. If you mistook the function containing yield in Ruby for a function that does not contain yield you would still have a problem, but not the same problem you would have in PHP or Python. It would raise an exception, while PHP and Python's would just return an iterable.

  def each_line_in_file 
  ..   yield 1 
  .. end
  => nil
  each_line_in_file
  (eval):2: (eval):2:in `each_line_in_file': no block given (LocalJumpError)
      from (eval):3

Thanks for taking the time to understand. My apologies for not being clear from the outset.

They aren't odd rules. It's just a coroutine. It executes, yields a value to the calling function and yields back control, the calling function does stuff, and yields back control, and this repeats. It's quite simple.

Also, don't argue against it here. Argue with the Python and C# folks, they did it first.

  require 'enumerator'

  def each_line_from_file file_name
    Enumerator.new do |yielder|
      File.open(file_name) do |file|
        while line = file.gets
          yielder << line
          ## or, alternatively:
          # yielder.yield(line)
        end
      end
    end
  end

  each_line_from_file('test.txt').each do |l|
    puts l
  end

That's really the most important thing for developers to notice - whether you use the feature often or not, you must be aware that foreach() might throw, not just emit an E_WARNING.

____________________

1. https://wiki.php.net/rfc/generators#rewinding_a_generator

I'm happy to see the feature, but this is one of those quirks that, in another five years, will end up in the next "A Fractal Of Bad Design" blog post.

Then it comes to vote and >90% vote for it, usually :)

You'd understand what I was on about if you read the PHP internals mailing list - the same points are argued to death; instead of a good discussion, it becomes a huge argument.

Which is why this doesn't work: (actual intended production code)

  self::$views[$path]();

But this works:

  $x = self::$views[$path];
  $x();

PHP is a dynamic(ally typed) language, and closures have nothing to do with static/dynamic.

> at its core it's a very strange dynamic/static hybrid

No, at its core it's completely dynamically typed, it got static features when it decided to base its OO on Java's.

> Which is why this doesn't work:

This doesn't work because PHP uses a shitty ad-hoc parser for a shitty ad-hoc syntax, much like closures it's completely orthogonal to the language being dynamic or static.

Also, this piece of code doesn't involve any closure. It looks like you don't know what a closure is.

Yes it does, it executes what PHP calls a "Closure": http://php.net/manual/en/class.closure.php

Your code breaks on any PHP "callable" http://php.net/manual/en/language.types.callable.php of which Closures are just one.

Although it seems PHP tried to treat it as a string callable IIRC.

PHP has much more in common with Java/C# than Python and Ruby. If you took Java and added dynamic typing and compiled it fresh on each request you'd get something very close to PHP.

One PhD students tried to make a PHP compiler, hair loss ensued.

For the curious, here's the talk (1 hour) about ahead of time compilation of PHP:

http://www.youtube.com/watch?v=kKySEUrP7LA

It parses, then does "bytecode" generation, then fiddles with the bytecodes a bit. So it does multiple passes.

And everyone I've spoken to refers to it as single-pass.

    the/worst/php/travesti/is/namespaces

And honestly, it's really not bad.