4 ms·

With an optimizing compiler to boost its performance, I think PHP would still benefit from two things: 1) A resource like "PHP - The Good Parts", that guided

by smoyer 13y ago

With an optimizing compiler to boost its performance, I think PHP would still benefit from two things: 1) A resource like "PHP - The Good Parts", that guided developers through the dos and don'ts of the language at an early stage. 2) An overlay language (like Coffeescript over Javascript) that effectively hides the bad parts, but that might also be extended to bring some consistency to the library APIs (even a bunch of aliases that used consistent naming rules would help). I'll admit that I have written anything serious in PHP since the late '90s but those are the issues we had bring new developers up to speed.

RossM 13y ago
1) sort of exists in http://phptherightway.com/ http://phptherightway.com/ 2) There's been a couple of these, most recently Mammouth[0], but personally I don't think that's useful - the syntax is more or less OK. I do think that renaming the core functions and then providing an alias/compatibility library would be beneficial however. Personally, the most inviting part of HHVM for me isn't the performance, it's the alternative team that seem willing to develop the language more in-line with what users want. [0]: https://github.com/btwael/mammouth https://github.com/btwael/mammouth
- martinml 13y ago
  Also about 2), haxe: http://haxe.org/doc/start/php http://haxe.org/doc/start/php
- jbeja 13y ago
  For 2) there is https://github.com/runekaagaard/snowscript https://github.com/runekaagaard/snowscript
  - kodablah 13y ago
    I also wrote one for fun at http://cretz.github.io/pratphall http://cretz.github.io/pratphall, but I have come to the conclusion that cross compiling to PHP isn't practical. The whole point is that it's easy to write and see the results right away.
- gedrap 13y ago
  >>> I do think that renaming the core functions and then providing an alias/compatibility library would be beneficial however. Totally agree with that. In the real world, one is normally using some sort of framework which hides most of the language quirks (inconsistent naming, order of parameters, etc). And the cases, when you need to use quirky native functions, are rear enough so that introducing additional layer where bugs might occur is not beneficial enough. So I'd focus more on picking the right framework (both philosophically and technically) rather than on focusing on a new language. Why I mention frameworks that much? Because in the of majority cases, applications are just some CRUD with a bit of logic and going with flat php + some home made libraries is just waste of time.
Schlaefer 13y ago
> 1) A resource like "PHP - The Good Parts" Not exactly the same, but "PHP - The Right Way" [1] is a good starting point. [1]: http://www.phptherightway.com/ http://www.phptherightway.com/
deleted 13y ago
[deleted]
camus2 13y ago
why an overlay ? PHP is a server-side language, it doesnt need an overlays, it needs fixing. It's not like javascript where you dont control the client, you control everything that is running on your servers. HHVM is good for Facebook,though i fail to understand how they could not migrate to any other serverside language given the number of developpers they hire, unless the legacy code is an unmaintainable,unreadble mess. Twitter did it(rails to jvm).
- rsanders 13y ago
  Giant rewrites don't have the best track record of success. Other than language aesthetics, what would be the justification for undertaking that enormous cost and risk? I despise PHP but I wouldn't make that call.
  - heroic 13y ago
    Why can't something like PHP to Java be done? It's been done for everything to Javascript. That way they could simple move PHP to the other language, and write whatever new in the other language?
    - blowski 13y ago
      I'm sure it could be done, but if it's working this way (and it does seem to be working), why bother?
mynames 13y ago
2) In "Taking PHP Seriously" (http://www.infoq.com/presentations/php-history http://www.infoq.com/presentations/php-history) it's discussed a language called "Hack" that seems to be exactly what you are talking about. But the link (http://hacklang.org http://hacklang.org) is redirecting to hhvm page now...
10098 13y ago
Why are we so masochistic? We invent bad languages, they spread everywhere like plague and then we're like "hey, let's create an overlay language to hide the hideousness". It's insane.
- nly 13y ago
  Bodging up old crap is part of the industry. We now use HTTP mostly for asynchronous RPC, TCP streams for reliable datagram protocols that suffer from head-of-line blocking as a result, and a scripting language thrown together for basic form validation as the focus of intense JIT development and back-end work. Oh, and let's not forget NAT and bodging HTTP/2 (which fixes HOL blocking) to, likely, only exist over TLS on TCP port 443. Facebook were forced down the road of supporting PHP because, just like everyone else everywhere else, they found it is several orders of magnitude more expensive to bring good features and lessons learned to a completely new language, stack or framework. Its kind of awful that new projects will see this as a new lease of life for PHP, rather than life support, but that's just inevitable. I guess it's both.
- dspillett 13y ago
  In many cases, PHP very definitely being one of them, what we ended up with wasn't invented at all: it grew organically for a while from something much smaller (or sometimes even something quite different). People use it because it is good enough and additions keep being made with little call for standards until you have a huge pile of stuff that many people are relying on. At this point a proper redesign from the ground up is impractical, you have to make step changes, so fixing the mess takes a long time. PHP was not initially intended to become what it has: it wasn't invented to be what it has turned out to be. But don't complain too much: dealing with that sort of legacy is what keeps some of us in active employment! (not them I'm implying anyone causes these issues on purpose, you'd have to be both a special sort of evil and a special sort of intelligent to create PHP4 (I've not used it since then, things may have improved massively recent years (they were certainly promising to) and I'd be non the wiser) with all its problems on purpose)

by smoyer 13y ago

RossM 13y ago

1) sort of exists in http://phptherightway.com/ http://phptherightway.com/ 2) There's been a couple of these, most recently Mammouth[0], but personally I don't think that's useful - the syntax is more or less OK. I do think that renaming the core functions and then providing an alias/compatibility library would be beneficial however. Personally, the most inviting part of HHVM for me isn't the performance, it's the alternative team that seem willing to develop the language more in-line with what users want. [0]: https://github.com/btwael/mammouth https://github.com/btwael/mammouth

martinml 13y ago
Also about 2), haxe: http://haxe.org/doc/start/php http://haxe.org/doc/start/php
jbeja 13y ago
For 2) there is https://github.com/runekaagaard/snowscript https://github.com/runekaagaard/snowscript
- kodablah 13y ago
  I also wrote one for fun at http://cretz.github.io/pratphall http://cretz.github.io/pratphall, but I have come to the conclusion that cross compiling to PHP isn't practical. The whole point is that it's easy to write and see the results right away.
gedrap 13y ago
>>> I do think that renaming the core functions and then providing an alias/compatibility library would be beneficial however. Totally agree with that. In the real world, one is normally using some sort of framework which hides most of the language quirks (inconsistent naming, order of parameters, etc). And the cases, when you need to use quirky native functions, are rear enough so that introducing additional layer where bugs might occur is not beneficial enough. So I'd focus more on picking the right framework (both philosophically and technically) rather than on focusing on a new language. Why I mention frameworks that much? Because in the of majority cases, applications are just some CRUD with a bit of logic and going with flat php + some home made libraries is just waste of time.

Schlaefer 13y ago

> 1) A resource like "PHP - The Good Parts" Not exactly the same, but "PHP - The Right Way" [1] is a good starting point. [1]: http://www.phptherightway.com/ http://www.phptherightway.com/

deleted 13y ago

[deleted]

camus2 13y ago

why an overlay ? PHP is a server-side language, it doesnt need an overlays, it needs fixing. It's not like javascript where you dont control the client, you control everything that is running on your servers. HHVM is good for Facebook,though i fail to understand how they could not migrate to any other serverside language given the number of developpers they hire, unless the legacy code is an unmaintainable,unreadble mess. Twitter did it(rails to jvm).

rsanders 13y ago
Giant rewrites don't have the best track record of success. Other than language aesthetics, what would be the justification for undertaking that enormous cost and risk? I despise PHP but I wouldn't make that call.
- heroic 13y ago
  Why can't something like PHP to Java be done? It's been done for everything to Javascript. That way they could simple move PHP to the other language, and write whatever new in the other language?
  - blowski 13y ago
    I'm sure it could be done, but if it's working this way (and it does seem to be working), why bother?

mynames 13y ago

2) In "Taking PHP Seriously" (http://www.infoq.com/presentations/php-history http://www.infoq.com/presentations/php-history) it's discussed a language called "Hack" that seems to be exactly what you are talking about. But the link (http://hacklang.org http://hacklang.org) is redirecting to hhvm page now...

10098 13y ago

Why are we so masochistic? We invent bad languages, they spread everywhere like plague and then we're like "hey, let's create an overlay language to hide the hideousness". It's insane.

nly 13y ago
Bodging up old crap is part of the industry. We now use HTTP mostly for asynchronous RPC, TCP streams for reliable datagram protocols that suffer from head-of-line blocking as a result, and a scripting language thrown together for basic form validation as the focus of intense JIT development and back-end work. Oh, and let's not forget NAT and bodging HTTP/2 (which fixes HOL blocking) to, likely, only exist over TLS on TCP port 443. Facebook were forced down the road of supporting PHP because, just like everyone else everywhere else, they found it is several orders of magnitude more expensive to bring good features and lessons learned to a completely new language, stack or framework. Its kind of awful that new projects will see this as a new lease of life for PHP, rather than life support, but that's just inevitable. I guess it's both.
dspillett 13y ago
In many cases, PHP very definitely being one of them, what we ended up with wasn't invented at all: it grew organically for a while from something much smaller (or sometimes even something quite different). People use it because it is good enough and additions keep being made with little call for standards until you have a huge pile of stuff that many people are relying on. At this point a proper redesign from the ground up is impractical, you have to make step changes, so fixing the mess takes a long time. PHP was not initially intended to become what it has: it wasn't invented to be what it has turned out to be. But don't complain too much: dealing with that sort of legacy is what keeps some of us in active employment! (not them I'm implying anyone causes these issues on purpose, you'd have to be both a special sort of evil and a special sort of intelligent to create PHP4 (I've not used it since then, things may have improved massively recent years (they were certainly promising to) and I'd be non the wiser) with all its problems on purpose)