There are many things that are popular or successful that nevertheless I cannot take seriously. Cheech and Chong for example.
"Taking it seriously" implies something more than just recognizing that it exists and is prevalent. In fact, I would go so far as to say that if you are forced to work in PHP, you should never take it seriously for your own safety and sanity. Always assume it will be and act janky, so that it cannot catch you off guard.
Modern PHP with a proper framework isn't really that bad, from a development point of view. You certainly don't have to deal in spaghetti code if you don't have to.
No comment on whether that's due to modern PHP frameworks splitting the difference between pretending to be Ruby or pretending to be Java, though. Of the major server-side languages it seems to be the most adapted to its purpose - churning out web resources with as little effort as possible.
Of course not. It only runs a paltry ~80% of the web. Just ignore it. Maybe it'll go away.
One of the nicest things about Kieth's talk is that he specifically did not make the case that network effect is a reason to take PHP seriously. He mentioned it as a data point that should pique curiosity, and proceeded to discuss concrete strengths at length instead.
I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it. That and people who tried jamming WordPress or some CMS into every use-case 10 years ago are commenting on how they don't like PHP. IMO, PHP has kept it's charm but added a lot of good stuff from other languages like Java. PHP is the language of choice and getting shit done. Oh, and not having to worry about lack of work.
>I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it.
I think JQuery and Coffeescript, have gone a long way to mollify people's opinions about javascript in a similar way to frameworks in PHP. And compared to PHP, some of javascript's syntax (particularly arrays, objects and anonymous functions) are a lot easier to deal with than in PHP, so there's some appreciation of that in the Node community, no doubt. But yeah, it does seem as if PHP and javascript are sort of the black sheep of the web app world.
> I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it.
Javascript used to be clunky due to cross-browser issues. These are mostly resolved now (at the language level).
PHP, on the other hand, has always been clunky. For example, it's often said that parsing is a solved problem. Try telling that to PHP:
$y = new stdClass;
$y->foo = function() { echo "World"; };
$y->foo(); // "No such method 'foo'"??!
I've written quite a few parsers, but still have no idea how PHP's could end up like this. Here are some recent 'features' from PHP 5.4 and 5.5 which every other parser on the planet would have handled from day 1:
- Passing an arbitrary expression instead of a variable to empty() is now supported. (PHP 5.5)
- Function array dereferencing has been added, e.g. foo()[0]. (PHP 5.4)
- Class member access on instantiation has been added, e.g. (new Foo)->bar(). (PHP 5.4)
> I've written quite a few parsers, but still have no idea how PHP's could end up like this.
Have you ever tried to parse code with a set of context sensitive rules (like, not using yacc, but writting your parser case by case at hand) and context free regular expression (don't use look ahead at all, and you also can't look behind)? PHP errors look a lot like this.
Well, kind of. Apparently ~20% of the web is wordpress, ~3% use Joomla, ~2% Drupal, and many other PHP CMS's after that.
So, yes, they are running PHP, but most of the PHP usage is simply running 'standard' software, and if you're not developing within those, (either core, or plugins), then it's a much smaller percent of sites which actually are custom written by programmers which actually run PHP.
So, I guess my point is, that even if a lot of the web is 'running' PHP, how much future development actually will use it? And as 'hackers', people writing new, cutting edge, different websites & apps, does PHP have anything to offer really, beyond easy to set up blogging and CMS systems for non-programmer clients?
As far as I understand it, PHP is used at FB only really because that's what it was originally written in. If Mark Z. had chosen Ruby, would FB now be working on ruby compilers and so on?
Perhaps, but aren't the bulk of today's non-PHP sites running on the standard frameworks for those languages? How many 'hackers' write Android apps without spending the bulk of their time in Eclipse, working with other people's code? There aren't a lot of pgs out there deciding to reinvent every wheel on the train.
I don't think you can necessarily dismiss the impact of 'blogging and CMS' systems when judging the future of a web application language. They may not be sexy, but almost everything everybody wants to do amounts to a CRUD app turning database records into html, and you can do that in any language.
I wouldn't recommend PHP for general purpose scripting though. Right now I like python for that.
I just said that I do take them seriously! What I mean is that their system and the logic embodied within the tax code has about the same amount of sensibility as PHP.
1. PHP's "programmer workflow" is unmatched. The development model is: "modify code, reload page." That's it. Simple and effective-- nearly optimal in fact for rapid development of code.
2. Program State: all PHP programs start as a web request with an empty heap and empty namespace. Cross-request state must always be saved explicitly and this tends to reduce bugs considerably at the cost of 10ms or so additional processing time for each request.
3. Concurrency model that relies on the request/server architecture rather than a specific language feature. PHP's strict enforcement of one thread per program per request forces you to use this model. The downside is that it's not applicable outside of the web server environment. Which, he argues, is fine since you want a tool optimized for the job you're trying to do.
Also:
0. He reviewed a number of PHP weaknesses, accepted that they are legitimate flaws in the language, and that if you had a PHP do-over there's no good reason to make all those mistakes again. But, he'll accept these flaws to benefit from the strengths listed above. He also shared the observation that a wide variety of programmers seem capable of becoming productive in PHP rather quickly, even if they've never used it before.
4. He reviewed tool they are developing, called Hack, to add better typing capability to PHP.
Interestingly, that's pretty much how I feel about writing Python web apps in Flask.
The built in reloading webserver gives (1.), the flask docs are fairly explicit about global/request state, how to share it, etc, giving near as anything (2.), the concurrency is handled by whatever server you use, be it gunicorn, waitress, uwsgi, or whatever, thanks to the wsgi protocol of python, giving (3.).
There's the auto-reloading build in web server, which will crash on any syntax errors in any changed code, so I don't even have to explore every possible path to find them.
Some other big deals, to me in python are the fact that requests, and input/output are all extremely separated. You never get the white-page-of-death-with-no-explanation of PHP. You never get random plugins printing something, and screwing up the headers. You never get issues with forgetting to use the appropriate number of op_cache function calls to keep slightly-less-trusted code under control.
Also, keeping templates, libraries, static files, and caches totally separate always seems like a good idea to me, but PHP doesn't encourage that. I know it's possible, but so many major projects (wordpress, joomla, drupal, etc) don't enforce that, making permissions in deployment a nightmare.
PHP's "reload page" methodology is extremely biased towards producing web pages and is a massive liability in other domains.
This is probably the biggest problem with PHP as it stands. It's so dead-focused on producing web pages that it's super awkward to use outside of that context.
Hack sounds pretty awesome, it's strange I haven't seen mention of that alongside hip hop before - also he mentioned "hacklang.org" but that seems completely different
I tried looking for something by way of an official announcement or release (preview or otherwise), but as Keith Adams joked, it's impossible it Google it, and the http://hacklang.org URL he referenced is not correct.
Someone in the Q&A pointed that out, so he mentioned that there'd be a post about it on the HHVM blog, but there doesn't seem to be anything about it in the last few months (this talk took place in September). Someone asked Keith Adams on Twitter at the end of October, where Adams said there was nothing to announce yet: https://twitter.com/keithmadams/status/395658859722723328
The only other thing I could find about it was another talk by Julien Verlaguet (to whom Adams credits the invention of Hack) from October: https://www.youtube.com/watch?v=gKWNjFagR9k
At my job I maintain some PHP that we are slowly removing (and replacing with Scala for the backend and Angular for the frontend). My total experience with PHP prior was writing a tiny wordpress plugin a decade ago that added some anti-spam stuff to comments.
And you know, PHP, it's not so bad. It gets the job done, it deploys instantly (the rest of our code is mostly Scala. Oh. My. God. Just. Build. Already…). It can be pretty haphazard, you can do some funky stuff with it (the abilty to pass by reference on integers and other 'primitives' caught me by surprise) and I wouldn't pick it for new code, but it's certainly not the steaming heap of evil that people make it out to be.
Krapp's right, but to clarify: PHP that generates HTML that uses jQuery is getting replaced with Angular that talks to the server via a REST interface written in Scala / Spray.
>PHP is a server-side language as you might now, so you are not replacing anything of it with Angular for the frontend, that's just an addition.
Not really. Perhaps you've missed all the "front side templates" thing. You can for example remove all PHP templating code, and just send JSON to be converted to HTML client side.
Besides, your dichotomy is invalid in general too. You can do lots of backend stuff in the front end too, if you want. E.g if you have a PHP script that converts a POST text variable into Markdown, you can opt to do it in the client, with a Javascript Mardkown lib. You can do calculations, you can use the canvas to generate images you used to do with GD, etc.
I too have had to maintain PHP code that I've since replaced with Scala, and our Scala production cycle has gotten quite fast indeed. The thing about Scala is: the compiler is the worst, slowest part of the language by far, and admittedly frustrating. But I've also found it's not a deal-breaker. Particularly, using it with the Play framework gives you request-triggered recompiling, so you can go through the change code-browser reload-change code process just like you do with PHP. And the iteration happens just slightly slower than with PHP. But you get the benefits of static typing which guarantees program correctness unlike PHP. The lack of this guarantee means PHP is actually not as productive as people say. If something compiles at all in Scala it tends to work the way you intended, and you don't have to go through some user flow or interaction in order to find whether or not the change you made works. Obviously, sometimes you do, esp. if you change front-end js. But most of the time I have found I don't, provided that the program compiles.
So I'm not buying this argument from Adams that the PHP iteration is necessasrily faster. It definitely used to be that way, but I think other languages have caught up.
We are churning out complete web services two or three at a time in 6 person shop, every month or so. We weren't as productive in PHP. Maybe that's just us getting better as programmers, but I also think it has a little to do with the bugs and other things caused by the lack of static typing and various language quirks.
Plus, Scala has access to the entire Java ecosystem, which is arguably as or more mature than the PHP ecosystem. So I don't spend a lot of time reinventing the wheel, as the Facebook engineers have done with their custom framework.
I would say that PHP, or any dynamic language for that matter, is going to result in faster iterations just by virtue of never having to wait for the compiler to catch up.
Even with incremental compilation and SBT subprojects (i.e. modules to keep recompiled code to a minimum) there's a compile time hit on _every_ source file change; that adds up over the lifetime of a project.
You guys may be more productive now than you were with PHP, but that's likely due more to the awesome libraries you're using than Scala development being inherently faster than PHP.
Right. But my argument is that the compile hit as at least mostly compensated for by the guarantee of program correctness, which PHP doesn't have. Forcing you to go through a user interaction to see if your change broke anything, which takes time.
Goes both ways. In PHP you can take an arbitrarily complex object graph and marshall it to JSON with a few keystrokes; in Scala, unless you're working with MongoDB or other native JSON speaking backeend, you've got to go through a laborious manual process to do the same...for each complex object.
That's partly why Dynamic came about in Scala, to deal with the case where, shit, you've already got a type safe represention of an object in Scala, and now you have to create a type safe JSON version of the same -- pointless double duty...PHP, Python, Groovy, Ruby, etc. win this particular battle.
I am, BTW, completely playing devil's advocate here ;-), Scala's my daily bread; PHP, wow, I did some horrible things [shudder]
That's true about JSON - it can be quite tedious if you have to write JSON reads and writes for things like JSON validation. But Play can autogenerate the reads/writes combinators for cases where validation isn't needed, so it ends up being as simple as putting a JsonFormatter in your companion object for a case class - 1 line. Play (and Jerkson) usually knows what to do with it, assuming all nested classes have json formatters in their companion objects, too.
In PHP cycles are slightly faster, but Scala lets you do away with lot less cycles. Not only because of awesome library, but also because excellent IDE support with instant type-checking.
> excellent IDE support with instant type-checking
heh, that's a stretch, perhaps compared to 3 years ago the IDE story in Scala is all roses. It's improved with time, but I still get arggghhh inducing moments where a given source file turns into a sea of red Xs despite SBT compiling the code just fine. Often an ./eclipse -clean is the only way to right the ship.
Perhaps IntelliJ provides a different experience (although I've heard there are issues with the Scala plugin there as well).
IntelliJ IDEA provides a different experience. I tried the eclipse plugin a month ago - much better than it was 2 years ago, but still far behind Idea. Also, keep in mind, we're comparing it to PHP and not Java.
PHP, unless it has changed radically since 2009, is pretty horrendous as a language, there are, IMO, far, far better choices on the dynamic side of the fence (e.g. Python, Ruby, Groovy).
It does get the job done, as you say, but being able to patch a running application with oh-just-this-one-quick-fix is not necessarily a good thing as it can encourage one to fall into the opposite of programmer best practices (was the case for me, I completely understand why DHH of Rails fame said [tongue in cheek], "PHP is the devil!")
Scala, on the other hand, basically changes your brain chemistry. Compared to where I was in 2009, floundering in dynamic language hacking with PHP, and later, Groovy, Scala has completely changed my approach to programming.
Obviously the rich Scala ecosystem has something to do with that, but the language itself really just helps guide you to "correct" solutions (FP constructs in particular). At this point I cannot imagine going back to a server-side dynamic language.
I think it really depends on how it's being used. If you just made html pages and shoved php statements all over the place, sure that's a horrible mess. But if you modularize your architecture and use classes, it can be quite maintainable.
I just spent the last week working on a new language that... turns out, is basically Facebook's new language: Hack. Although, it does seem they've not released it to the public, so I suppose I'll keep working on it, heh.
My new language steals PHP's "shared-nothing", "bootstrap from nothing at request" but steals Typescript (and Hack's, apparently) gradual typing system, along with a saner, less ridiculous StdLib.
Have/had you considered using typescript or coffeescript on node.js? Just curious here.. I know there's other options and platforms, just really do like node+npm a lot.
I actually like JS myself.. it's been pretty much my favorite language for a long time (long before the good parts book)... Used it with Netscape's web server, and even in classic asp. There are still a lot of advantages to a single language across your stack. It's also a natural fit with document databases... and even Pg with v8 support. It's not the "best" of all worlds language, but it's definitely the best in terms of coverage.
PHP was my first language when I was starting out professionally, and before I went into university and learned "proper programming". Back in 2007-2008, I remember the mess it was, with the internals list being a permanent struggle to implement anything by consensus (no lambdas or JS array notation because it wasn't easy to google, for example), and it really did look like a dead end. The internal source code of PHP was often a mess of macros everywhere, and the whole PHP6 unicode fiasco really did paint a grim picture of its future.
Facebook seems to have given it a bit of fresh air, implementing some pretty interesting stuff (Hindley-Milner with subclasses, for instance), and it really seems like the "feel" of programming in PHP has changed. I'm not going to say "Screw C++ and Haskell, _this_ is a serious language!", but on the other hand I feel I can say with a straight face to someone who is starting programming, "You could check this language out", without a guilty conscience that I'll be ruining their mind.
I'm unsure of PHP's future - if it'll be tied to Facebook (and thus Facebook's future, which I am equally unsure of), for example - but as of now, it seems to be a reasonable, if idiosyncratic, language.
Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco. PHP is doomed with these guys, trust me, no matter how much effort is put into Doctrine, Laravele ,Symfony or other libs.
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
I couldn't agree more. The PHP internals group struggles still occur to this day as new ideas and fresh thinking run up against the old guard and more often than not are discarded.
I don't necessarily blame the "old guard" - they've been around a long time and they've seen a lot of failed ideas - and it's been them who dealt with the cleanup and had to maintain those broken features long past the founders of those features had moved on.
This isn't a bad thing: PHP is rooted in many businesses both small and enterprise: it will be around for a long time. Projects like HHVM are going to ensure that.
However, I no longer think that PHP is going to "turn it around" and will ever be a model of innovation. It lost it's opportunity to do that.
>Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco.
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
>At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
I think Python 3 offers more than you think it does. I'm not going to try to convince you, but having used it steadily for the last month or so, I really think it does.
It does offer some things, but does it offer a "divide the community, halt the old version and still go nowhere much adoption-wise after 5 whole years" worth of things?
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
The GIL and a JIT are low level implementation issues though, right? E.g., Python 3 can be implemented in PyPy (and it looks like that's in the works).
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
PHP 5.4 broke code. In more ways than documented in the help (where a list of breaking changes exists, but is incomplete). For good codebases that adhere closely to how good PHP code should be written it's probably not much of a problem, but the ancient and horrible code base I had to coax into working with 5.4 had a few places that broke.
I love how often the same people that are those complaining about 5.4 breaking code, throwing deprecated messages etc, and on the other hand still wailing about the weird artifacts and inconsistent function naming.
http://php.net/manual/en/migration54.incompatible.php lists very few removed functions and no renames. One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given. I'm not sure that falls into »We're removing weird artifacts from the language«.
No those changes would be reserved for major releases.
But the removal of the likes of safe_mode, magic quotes and register_globals have been long overdue.
The only reason why they have been in there for so long is because it would break code.
Backwards compatibility has always been this cute silly idiom of PHP. Which has its good parts and bad parts. I'm glad that it has gotten more mature in that sense. 5.3+ have been a statement of such.
> One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping.
But again I must say, It's actually a really great thing, and again long overdue.
The internal source code of PHP was often a mess of macros everywhere
My understanding, from people here that seemed to know what they are talking about, is that generally macros are how these languages are implemented when done in C, for various reasons. So much so in fact, that you are really writing a DSL layered over C. I doubt Python, Ruby or Perl are any different (actually I know Perl relies heavily on macros in the source for its interpreter).
I'm unsure of PHP's future - if it'll be tied to Facebook
I don't think it'll be tied to Facebook at all. What the PHP community has is a huge ecosystem of programmers (good ones and bad ones), frameworks, libraries, etc. That bodes well for PHP's future.
Whoah! Thank you for linking to this video series. Another video from this Strange Loop 2013[0] conference is on Symmetry in Programming Language Design[1]. I am finding it to be way more up my alley.
PHP is a horrible language with great libraries and a few good features. A lot of successfull projects are written in PHP. The execution model is good enough for some types of apps(blogs,e-shops,...).
As a PHP developer , i'm betting on Python and NodeJS for the future, i dont believe PHP has any real future outside a bunch of popular CMSes. While PHP has excellent libraries (Symfony,Doctrine,...) , Python has very good ones too, and it IS trully multipurpose.
When i first came to Python i did not like its OOP model(no interfaces,...),but Python metaprogramming features are unique and very interesting to learn.
The biggest problem with PHP is its core developers, adding some "feature" is not fixing the language. Removing the bad parts should be the focus of the next PHP versions. It is not.
>As a PHP developer , i'm betting on Python and NodeJS for the future, i dont believe PHP has any real future outside a bunch of popular CMSe
Same here, having done very large php projects in the past, nowadays I tend to go for python (or more recently node) unless the client requests it.
One thing I foresee being a good niche in the future is updating/fixing legacy php apps. There's just too many man hours into them. It will be the COBOL of the web centric future.
> One thing I foresee being a good niche in the future is updating/fixing legacy php apps. There's just too many man hours into them. It will be the COBOL of the web centric future.
I've been doing that for the last 3 years. I think it's mostly driven by the recession - firms don't want to rewrite/rebuild their software (rightfully, they don't understand why it can't run for longer than 2-3 years without breaking).
However, updating and fixing symfony 1.0 apps is the most soul-destroying work I have ever done...
That and there's still a "it's easy to find php developers" amongst business people IME. Not that I mind php, I've used it long enough to work around it's issues.
> The biggest problem with PHP is its core developers, adding some "feature" is not fixing the language. Removing the bad parts should be the focus of the next PHP versions. It is not.
I came to PHP after long stint with C, C++, Objective C, Java and Javascript - and I was productive from day 1. I have programmed extensively, and have come across few quirks, but never got stuck, nor is my code spaghetti. I do not use frameworks where they can be avoided and write extremely simple code and avoid OOP for scripting. I would not do OOP with a language without strong typing. My take is for short lived HTTP requests which need to spew out some JSON preferably(favor headless coding for frontend), PHP is the apt tool. For heavy lifting, use a strongly typed language which can easily handle complexity.
Do you have an example of a non-trivial project that was written in PHP that is not spaghetti code that doesn't use OOP as it's foundation for organization?
I want to believe that it's possible. When you start introducing even the most basic complexities of a web app (authentication, access control, database connections, reusable CRUD functionality - all the things that make up a non-trivial application) I find it really hard to stay organized in a procedural style.
I'm not being snarky; I'd love to see a good example of this.
As a PHP zealot, I'm also really interested in this. I drink the OOP Kool-Aid 100% when I code in PHP since it forces at least some level of structure, but I'd love to see a successful procedural approach.
I believe that Drupal 7 qualifies as a non-trivial PHP application that only uses OO in a minimal number of applications in core (ie, when it's appropriate).
Some would definitely argue that Drupal results in spaghetti code, due to a large amount of module functionality being written in hooks that are invoked to change behavior at runtime. It also has an elaborate theming process that yields many opportunities for module or theme code to modify data as it passes through the layers of data generation, processing, theming, etc.
My personal experience on some large Drupal projects is that with an experienced team that knows "the Drupal way" of doing things, you can write some very well organised code that is easy to maintain and extend. However, I doubt this is the norm with Drupal projects.
I also think that Drupal 8 and beyond will move more and more towards an OO-based methodology, as the learning curve for the current system is very high.
As long as you keep your design to short lived HTTP requests in CRUD fashion - and no deep nesting - It is possible (REST is really procedural in its core). In fact, I would suggest the model for any scripting language. That do not mean you cannot use OOP SDKs for which you can make calls within procedural code. I typically use Java for complex logic which is mostly run as cron/long lived process often with multiple threads. My CRUD files rarely exceed 1000 lines of code and do not do any UI heavy lifting (left to HTML/JS). I use AWS and SDKs wherever applicable to remove heavy lifting from my code and keep things stateless as possible.
In the past 2 years we have developed a Mobile Companion Platform for TV which scaled to many hundred thousand users, a scalable appstore for TV, a Middleware Platform for HTML/Android Set Tops, a mobile Live TV platform and a Campaign Management System for TV. I find it exceedingly difficult to manage and scale containers and would not use them for anything other than strict enterprise stuff.
Our platforms typically have 80-100 CRUD APIs and finish within 10000 lines of PHP with heavy lifting delegated to cloud APIs and Java based crons/long lived processes.
Thanks! We should have some code that can be made open source. Will check if it contains any PHP. Mostly because we work with Businesses and host solutions for them on the cloud, our code base is not yet open sourced. Should try to do that in the future. In the mean time, I would be happy to help out if you have some specific requirement.
When I first encountered the fusebox [1] framework for ColdFusion - that was a bit of an eye-opener for me. I still thunk MVC and derivatives for proper object oriented environments like Smalltalk is superior as a general design pattern, but fusebox is a great match for web development with "template oriented" languages like php and cf. It builds sanely on these languages' strenghts and can be rather plesant to work with.
Yes, I've built a couple of large PHP applications handing gnarly business logic that did not turn into spaghetti code. The been easy enough to maintain and extend over the years as well. OOP is used for the persistence code only.
The trick to this has been to have minimal code in the MVC layer, and keep most of the logic in functions which are organized in into per topic files.
So when my application wants to find out the price of something, I'll call price($product, $user) from pricing.php, which will then handle all the voodoo business rules about pricing (does the user get a member discount? what kind of discount do they get? do they own a related product? is it Friday the 13th?) price() depends on other functions like has_active_membership() defined in the file about subscriptions, and on membership_discount_pct() in the pricing file.
This function oriented breakdown applies not just to business logic, but authentication, charging credit cards through stripe, sending emails, course status, editing rights, etc.
I deliberately do not use any hooks or other meta chicanery. It's plain functions calling plain functions all the way down.
PHP is a strong language for the web, but the community is not. I really only see Facebook pushing the language and even though Steve Ballmer has been memed to death about his "Developers" rant, the developer community is really what makes languages like Ruby/Rails and Node.JS more attractive.
I definitely applaud all of the work the Facebook team has done in order to push the limits of PHP and turn it into something that developers are actually comfortable working with. With that being said, I still don't think it's better than I thought it was.
The PHP community is doing quite well these days. The advent of things like Composer, FIG, and PSRs have brought a breath of fresh air into the PHP landscape. There's a bit of a renaissance going on here.
Ah I see. Yeah I haven't kept up with the PHP community really for about 5 years. I'll definitely have to take a look some time in the next coming weeks to see what's been going on.
I think this was a worthwhile talk. The speaker makes some interesting points about the importance of "ergonomic properties" of languages.
He convincingly explains why PHP was so succesful: Workflow (just hot reload), Concurrency (in the sense of "shared nothing" HTTP requests), and State (every request starts from a "clean plate", which reduces long-time statefulness bugs if you know what I mean).
An interesting point he raises is that PHP leaks it's GC mechanism to the API, which makes implementing a fast VM harder for the HHVM team.
Generally a good talk and a good defense, but I didn't quite appreciate his new definitions of "State" and "Concurrency".
And did he really compare a full operating system to Facebook's web apps in terms of complexity? If that's true, there has to be a lot of accidental complexity in FB.
I haven't currently moved on to learning PHP yet, I've been using Python quite regularly for the past few years and a lot of Java Script. PHP could possibly be the next language for me to learn.
This is not about taking PHP seriously. This is about taking Facebooks internal development language _based_ on PHP seriously. By the time you factor in a different run time and the various language extensions they have made you no longer have PHP. In fact everything they have done has been to turn their existing PHP codebase into a better language and to their credit they have added some excellent tools to make that migration smooth. The question is at what point are you no longer writing PHP but writing facebook PHP with a VM that still lacks documentation and in the name of backwards compatibility carried forward the warts of the old PHP.
The point as I understood was that for all of PHP's faults, (almost by accident) it managed to get certain things right, or at least right for the Web in the time in the time of it's heyday.
These being, chiefly, that the much-maligned document-based scripting model turns out to be really easy to package, deploy, and most of all, to learn. And that it also (again by accident) happens to be in some ways easier to program safely in, compared to handler-response based frameworks.
Don't get me wrong -- I don't see these as anywhere close to redeeming strengths for PHP. It's still a crappy language, all the cheerleading and apologetics from the likes of FB and Etsy notwithstanding. But the presentation does make some interesting points.
113 comments
[ 4.7 ms ] story [ 175 ms ] thread"Taking it seriously" implies something more than just recognizing that it exists and is prevalent. In fact, I would go so far as to say that if you are forced to work in PHP, you should never take it seriously for your own safety and sanity. Always assume it will be and act janky, so that it cannot catch you off guard.
No comment on whether that's due to modern PHP frameworks splitting the difference between pretending to be Ruby or pretending to be Java, though. Of the major server-side languages it seems to be the most adapted to its purpose - churning out web resources with as little effort as possible.
One of the nicest things about Kieth's talk is that he specifically did not make the case that network effect is a reason to take PHP seriously. He mentioned it as a data point that should pique curiosity, and proceeded to discuss concrete strengths at length instead.
I think JQuery and Coffeescript, have gone a long way to mollify people's opinions about javascript in a similar way to frameworks in PHP. And compared to PHP, some of javascript's syntax (particularly arrays, objects and anonymous functions) are a lot easier to deal with than in PHP, so there's some appreciation of that in the Node community, no doubt. But yeah, it does seem as if PHP and javascript are sort of the black sheep of the web app world.
Javascript used to be clunky due to cross-browser issues. These are mostly resolved now (at the language level).
PHP, on the other hand, has always been clunky. For example, it's often said that parsing is a solved problem. Try telling that to PHP:
$x = function() { return function() { echo "Hello"; }; }; $x()(); // Syntax error??!
$y = new stdClass; $y->foo = function() { echo "World"; }; $y->foo(); // "No such method 'foo'"??!
I've written quite a few parsers, but still have no idea how PHP's could end up like this. Here are some recent 'features' from PHP 5.4 and 5.5 which every other parser on the planet would have handled from day 1: - Passing an arbitrary expression instead of a variable to empty() is now supported. (PHP 5.5) - Function array dereferencing has been added, e.g. foo()[0]. (PHP 5.4) - Class member access on instantiation has been added, e.g. (new Foo)->bar(). (PHP 5.4)
Have you ever tried to parse code with a set of context sensitive rules (like, not using yacc, but writting your parser case by case at hand) and context free regular expression (don't use look ahead at all, and you also can't look behind)? PHP errors look a lot like this.
So, yes, they are running PHP, but most of the PHP usage is simply running 'standard' software, and if you're not developing within those, (either core, or plugins), then it's a much smaller percent of sites which actually are custom written by programmers which actually run PHP.
So, I guess my point is, that even if a lot of the web is 'running' PHP, how much future development actually will use it? And as 'hackers', people writing new, cutting edge, different websites & apps, does PHP have anything to offer really, beyond easy to set up blogging and CMS systems for non-programmer clients?
As far as I understand it, PHP is used at FB only really because that's what it was originally written in. If Mark Z. had chosen Ruby, would FB now be working on ruby compilers and so on?
I don't think you can necessarily dismiss the impact of 'blogging and CMS' systems when judging the future of a web application language. They may not be sexy, but almost everything everybody wants to do amounts to a CRUD app turning database records into html, and you can do that in any language.
I wouldn't recommend PHP for general purpose scripting though. Right now I like python for that.
1. PHP's "programmer workflow" is unmatched. The development model is: "modify code, reload page." That's it. Simple and effective-- nearly optimal in fact for rapid development of code.
2. Program State: all PHP programs start as a web request with an empty heap and empty namespace. Cross-request state must always be saved explicitly and this tends to reduce bugs considerably at the cost of 10ms or so additional processing time for each request.
3. Concurrency model that relies on the request/server architecture rather than a specific language feature. PHP's strict enforcement of one thread per program per request forces you to use this model. The downside is that it's not applicable outside of the web server environment. Which, he argues, is fine since you want a tool optimized for the job you're trying to do.
Also:
0. He reviewed a number of PHP weaknesses, accepted that they are legitimate flaws in the language, and that if you had a PHP do-over there's no good reason to make all those mistakes again. But, he'll accept these flaws to benefit from the strengths listed above. He also shared the observation that a wide variety of programmers seem capable of becoming productive in PHP rather quickly, even if they've never used it before.
4. He reviewed tool they are developing, called Hack, to add better typing capability to PHP.
The built in reloading webserver gives (1.), the flask docs are fairly explicit about global/request state, how to share it, etc, giving near as anything (2.), the concurrency is handled by whatever server you use, be it gunicorn, waitress, uwsgi, or whatever, thanks to the wsgi protocol of python, giving (3.).
There's the auto-reloading build in web server, which will crash on any syntax errors in any changed code, so I don't even have to explore every possible path to find them.
Some other big deals, to me in python are the fact that requests, and input/output are all extremely separated. You never get the white-page-of-death-with-no-explanation of PHP. You never get random plugins printing something, and screwing up the headers. You never get issues with forgetting to use the appropriate number of op_cache function calls to keep slightly-less-trusted code under control.
Also, keeping templates, libraries, static files, and caches totally separate always seems like a good idea to me, but PHP doesn't encourage that. I know it's possible, but so many major projects (wordpress, joomla, drupal, etc) don't enforce that, making permissions in deployment a nightmare.
This is probably the biggest problem with PHP as it stands. It's so dead-focused on producing web pages that it's super awkward to use outside of that context.
http://www.slideshare.net/zerutreck/taking-php-seriously-kei...
http://files.nikcub.com/mirror/takingphpseriously.mp3
37.8MB
Someone in the Q&A pointed that out, so he mentioned that there'd be a post about it on the HHVM blog, but there doesn't seem to be anything about it in the last few months (this talk took place in September). Someone asked Keith Adams on Twitter at the end of October, where Adams said there was nothing to announce yet: https://twitter.com/keithmadams/status/395658859722723328
The only other thing I could find about it was another talk by Julien Verlaguet (to whom Adams credits the invention of Hack) from October: https://www.youtube.com/watch?v=gKWNjFagR9k
And you know, PHP, it's not so bad. It gets the job done, it deploys instantly (the rest of our code is mostly Scala. Oh. My. God. Just. Build. Already…). It can be pretty haphazard, you can do some funky stuff with it (the abilty to pass by reference on integers and other 'primitives' caught me by surprise) and I wouldn't pick it for new code, but it's certainly not the steaming heap of evil that people make it out to be.
Maybe our code is just awesome, idk.
Not really. Perhaps you've missed all the "front side templates" thing. You can for example remove all PHP templating code, and just send JSON to be converted to HTML client side.
Besides, your dichotomy is invalid in general too. You can do lots of backend stuff in the front end too, if you want. E.g if you have a PHP script that converts a POST text variable into Markdown, you can opt to do it in the client, with a Javascript Mardkown lib. You can do calculations, you can use the canvas to generate images you used to do with GD, etc.
So I'm not buying this argument from Adams that the PHP iteration is necessasrily faster. It definitely used to be that way, but I think other languages have caught up.
We are churning out complete web services two or three at a time in 6 person shop, every month or so. We weren't as productive in PHP. Maybe that's just us getting better as programmers, but I also think it has a little to do with the bugs and other things caused by the lack of static typing and various language quirks.
Plus, Scala has access to the entire Java ecosystem, which is arguably as or more mature than the PHP ecosystem. So I don't spend a lot of time reinventing the wheel, as the Facebook engineers have done with their custom framework.
Even with incremental compilation and SBT subprojects (i.e. modules to keep recompiled code to a minimum) there's a compile time hit on _every_ source file change; that adds up over the lifetime of a project.
You guys may be more productive now than you were with PHP, but that's likely due more to the awesome libraries you're using than Scala development being inherently faster than PHP.
That's partly why Dynamic came about in Scala, to deal with the case where, shit, you've already got a type safe represention of an object in Scala, and now you have to create a type safe JSON version of the same -- pointless double duty...PHP, Python, Groovy, Ruby, etc. win this particular battle.
I am, BTW, completely playing devil's advocate here ;-), Scala's my daily bread; PHP, wow, I did some horrible things [shudder]
I am just glad to be done with PHP.
> I am just glad to be done with PHP
shhhh, this is, you know, a PHP thread ;-)
heh, that's a stretch, perhaps compared to 3 years ago the IDE story in Scala is all roses. It's improved with time, but I still get arggghhh inducing moments where a given source file turns into a sea of red Xs despite SBT compiling the code just fine. Often an ./eclipse -clean is the only way to right the ship.
Perhaps IntelliJ provides a different experience (although I've heard there are issues with the Scala plugin there as well).
It does get the job done, as you say, but being able to patch a running application with oh-just-this-one-quick-fix is not necessarily a good thing as it can encourage one to fall into the opposite of programmer best practices (was the case for me, I completely understand why DHH of Rails fame said [tongue in cheek], "PHP is the devil!")
Scala, on the other hand, basically changes your brain chemistry. Compared to where I was in 2009, floundering in dynamic language hacking with PHP, and later, Groovy, Scala has completely changed my approach to programming.
Obviously the rich Scala ecosystem has something to do with that, but the language itself really just helps guide you to "correct" solutions (FP constructs in particular). At this point I cannot imagine going back to a server-side dynamic language.
I just spent the last week working on a new language that... turns out, is basically Facebook's new language: Hack. Although, it does seem they've not released it to the public, so I suppose I'll keep working on it, heh.
My new language steals PHP's "shared-nothing", "bootstrap from nothing at request" but steals Typescript (and Hack's, apparently) gradual typing system, along with a saner, less ridiculous StdLib.
But, it still lacks PHP's unique architecture, in terms of execution style and focus.
That, and I got bored and wanted to make a JIT interpreter. :)
Get more mileage out of Haskell.
It's not documented, but you can see it in the tests.
E.g., https://github.com/facebook/hhvm/blob/master/hphp/test/quick...
PHP was my first language when I was starting out professionally, and before I went into university and learned "proper programming". Back in 2007-2008, I remember the mess it was, with the internals list being a permanent struggle to implement anything by consensus (no lambdas or JS array notation because it wasn't easy to google, for example), and it really did look like a dead end. The internal source code of PHP was often a mess of macros everywhere, and the whole PHP6 unicode fiasco really did paint a grim picture of its future.
Facebook seems to have given it a bit of fresh air, implementing some pretty interesting stuff (Hindley-Milner with subclasses, for instance), and it really seems like the "feel" of programming in PHP has changed. I'm not going to say "Screw C++ and Haskell, _this_ is a serious language!", but on the other hand I feel I can say with a straight face to someone who is starting programming, "You could check this language out", without a guilty conscience that I'll be ruining their mind.
I'm unsure of PHP's future - if it'll be tied to Facebook (and thus Facebook's future, which I am equally unsure of), for example - but as of now, it seems to be a reasonable, if idiosyncratic, language.
So yeah, good talk :)
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
They did not.
I don't necessarily blame the "old guard" - they've been around a long time and they've seen a lot of failed ideas - and it's been them who dealt with the cleanup and had to maintain those broken features long past the founders of those features had moved on.
This isn't a bad thing: PHP is rooted in many businesses both small and enterprise: it will be around for a long time. Projects like HHVM are going to ensure that.
However, I no longer think that PHP is going to "turn it around" and will ever be a model of innovation. It lost it's opportunity to do that.
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
>At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
For example, Python 3.4 is adding asyncio (http://www.python.org/dev/peps/pep-3156/).
And if you look at the _What's New In Python 3.x pages_, there's a ton of new stuff.
edit: forgot a word
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping. But again I must say, It's actually a really great thing, and again long overdue.
My understanding, from people here that seemed to know what they are talking about, is that generally macros are how these languages are implemented when done in C, for various reasons. So much so in fact, that you are really writing a DSL layered over C. I doubt Python, Ruby or Perl are any different (actually I know Perl relies heavily on macros in the source for its interpreter).
Edit: s/Rudy/Ruby/. duh.
Over a decade later I almost exclusively use PHP, and it has put plenty of bread and wine on the table :) over the years.
It just gets the job done!
I don't think it'll be tied to Facebook at all. What the PHP community has is a huge ecosystem of programmers (good ones and bad ones), frameworks, libraries, etc. That bodes well for PHP's future.
[0]: http://www.infoq.com/strange-loop-2013/
[1]: http://www.infoq.com/presentations/noether
Edit: Posted to https://news.ycombinator.com/item?id=7054815
PHP is a horrible language with great libraries and a few good features. A lot of successfull projects are written in PHP. The execution model is good enough for some types of apps(blogs,e-shops,...).
As a PHP developer , i'm betting on Python and NodeJS for the future, i dont believe PHP has any real future outside a bunch of popular CMSes. While PHP has excellent libraries (Symfony,Doctrine,...) , Python has very good ones too, and it IS trully multipurpose.
When i first came to Python i did not like its OOP model(no interfaces,...),but Python metaprogramming features are unique and very interesting to learn.
The biggest problem with PHP is its core developers, adding some "feature" is not fixing the language. Removing the bad parts should be the focus of the next PHP versions. It is not.
Same here, having done very large php projects in the past, nowadays I tend to go for python (or more recently node) unless the client requests it.
One thing I foresee being a good niche in the future is updating/fixing legacy php apps. There's just too many man hours into them. It will be the COBOL of the web centric future.
I've been doing that for the last 3 years. I think it's mostly driven by the recession - firms don't want to rewrite/rebuild their software (rightfully, they don't understand why it can't run for longer than 2-3 years without breaking).
However, updating and fixing symfony 1.0 apps is the most soul-destroying work I have ever done...
That and there's still a "it's easy to find php developers" amongst business people IME. Not that I mind php, I've used it long enough to work around it's issues.
This. Well said.
I want to believe that it's possible. When you start introducing even the most basic complexities of a web app (authentication, access control, database connections, reusable CRUD functionality - all the things that make up a non-trivial application) I find it really hard to stay organized in a procedural style.
I'm not being snarky; I'd love to see a good example of this.
Some would definitely argue that Drupal results in spaghetti code, due to a large amount of module functionality being written in hooks that are invoked to change behavior at runtime. It also has an elaborate theming process that yields many opportunities for module or theme code to modify data as it passes through the layers of data generation, processing, theming, etc.
My personal experience on some large Drupal projects is that with an experienced team that knows "the Drupal way" of doing things, you can write some very well organised code that is easy to maintain and extend. However, I doubt this is the norm with Drupal projects.
I also think that Drupal 8 and beyond will move more and more towards an OO-based methodology, as the learning curve for the current system is very high.
In the past 2 years we have developed a Mobile Companion Platform for TV which scaled to many hundred thousand users, a scalable appstore for TV, a Middleware Platform for HTML/Android Set Tops, a mobile Live TV platform and a Campaign Management System for TV. I find it exceedingly difficult to manage and scale containers and would not use them for anything other than strict enterprise stuff.
Our platforms typically have 80-100 CRUD APIs and finish within 10000 lines of PHP with heavy lifting delegated to cloud APIs and Java based crons/long lived processes.
1:
http://en.m.wikipedia.org/wiki/Fusebox_(programming)
The trick to this has been to have minimal code in the MVC layer, and keep most of the logic in functions which are organized in into per topic files.
So when my application wants to find out the price of something, I'll call price($product, $user) from pricing.php, which will then handle all the voodoo business rules about pricing (does the user get a member discount? what kind of discount do they get? do they own a related product? is it Friday the 13th?) price() depends on other functions like has_active_membership() defined in the file about subscriptions, and on membership_discount_pct() in the pricing file.
This function oriented breakdown applies not just to business logic, but authentication, charging credit cards through stripe, sending emails, course status, editing rights, etc.
I deliberately do not use any hooks or other meta chicanery. It's plain functions calling plain functions all the way down.
I definitely applaud all of the work the Facebook team has done in order to push the limits of PHP and turn it into something that developers are actually comfortable working with. With that being said, I still don't think it's better than I thought it was.
He convincingly explains why PHP was so succesful: Workflow (just hot reload), Concurrency (in the sense of "shared nothing" HTTP requests), and State (every request starts from a "clean plate", which reduces long-time statefulness bugs if you know what I mean).
An interesting point he raises is that PHP leaks it's GC mechanism to the API, which makes implementing a fast VM harder for the HHVM team.
And did he really compare a full operating system to Facebook's web apps in terms of complexity? If that's true, there has to be a lot of accidental complexity in FB.
https://plus.google.com/118197810020432218051/posts/17fNVWVj...
I could not find what you meant, could you provide a link?
The point as I understood was that for all of PHP's faults, (almost by accident) it managed to get certain things right, or at least right for the Web in the time in the time of it's heyday.
These being, chiefly, that the much-maligned document-based scripting model turns out to be really easy to package, deploy, and most of all, to learn. And that it also (again by accident) happens to be in some ways easier to program safely in, compared to handler-response based frameworks.
Don't get me wrong -- I don't see these as anywhere close to redeeming strengths for PHP. It's still a crappy language, all the cheerleading and apologetics from the likes of FB and Etsy notwithstanding. But the presentation does make some interesting points.
I recommend pure HTML (and call API/CORS). (Same is true of ASP, etc.). Pure HTML!