Hacker News Reader

Comment by wvenable | Hacker News Reader

> I wish PHP could start changing in a "let's redesign it" way.

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.

View on HN

There is room for a language that generates HTML by default, compiles every library anyone could ever need into the core, and puts it all in the default namespace. All you need to make that socially acceptable is something like GHC's -XNoImplicitPrelude option. By default, you get what might be considered to be a big mess. But when someone with a clue shows up to turn your prototype into something maintainable, they can turn on "expert mode" and program normally again.

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.

My PHP code looks pretty much identical to my code in other languages. Everything is in namespaces and classes. There is abstractions for database access and other common operations. I don't think PHP needs an expert mode; it just needs to continue to be a better language.

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.

I've used PHP a lot, work at a name-brand startup that uses a fair bit of PHP in the stack, and have an OSS PHP project I'm proud of (https://github.com/shaneharter/PHP-Daemon). That is to say, I'm not a PHP hater. I see many flaws in the language, many many actually, but I'm not a hater.

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.

You don't. Watch:

  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

At this point you should see a pcntl.so in your extension_dir. Add an extension=pcntl.so to your php.ini file and you are good to go.

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

That's no less omplicated than downloading the PHP source and recompiling with the --with-pcntl flag. Now compare that, just for your own wonderment, to how it works in other modern languages..

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.

Easily? I remember having quite some difficulties getting gems with binaries to work on Windows (meaning: lots of wrestling before I even got the MySql driver working). Might be different now though but I have never experienced anything like that when dealing with PHP extensions or Composer packages.

That is only because you picked an internal extension that is usually already built-in. If you install the php-cli package from any major distro it includes pcntl. For normal extensions you either do an apt-get install php-imap (for example) or a pecl install stem if your distro hasn't packaged the extension you need or you just prefer to install it directly.

You don't have to recompile PHP to install anything, PHP has loadable module and had them since forever. As for Easter - why do you care that there's a function for that? How does it hurt you? Somebody needed it, so it was added. Why having function that somebody needs and you do not is a problem?

>There is room for a language that generates HTML by default, compiles every library anyone could ever need into the core, and puts it all in the default namespace.

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.

What I mean for "redesigning" is to do what they are doing now (adding what was clearly missing), but at the same time doing what they are not doing now, that is, removing what was clearly not ok and is now taken inside just for backward compatibility. With a switch to allow for backward compatibility, that is disabled by default.

They can't do that though. PHP is so successful and ubiquitous because it's been backwards compatible for a really long time. Most PHP apps run very well on 5.2 Which was released over 6 years ago.

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).

Reply on news.ycombinator.com