HN Theater @HNTheaterMonth

I think the points from "Taking PHP Seriously" are still interesting. https://www.infoq.com/presentations/php-history/

The argument is that PHP's strengths are its workflow, its state, and how you work with concurrency. i.e. PHP's execution model (per-request) allows for things like not having to worry about restarting the server when you're developing the files. The complete lack of shared state between requests means you don't get complex footguns.

I was kind of surprised to read this and started to think this was just a copy of a previous speech I've heard before.

I was right it was: https://www.infoq.com/presentations/php-history but the author is the same person.

It is a good speech and I've been developing in php for years, written a blog post (http://sucky.ninja/leaving-php-is-too-expensive/) about it but I do no longer use php for my backends.

I've whole-heartedly switched to ASP.NET since my productivity is increased with it and I can actually use the language (C#) for other things. I would've agreed with the author a couple of years ago but with Azure, AWS and other cloud services it is simply no longer true that php gives developers a quicker feedback loop. I can setup a node server with gulp and start working in 10 minutes or I can start a new ASP.NET project and deploy to production right after the project creation has completed. With php I still have to setup a virtual machine etc etc.

I would not go back, even if it is cheaper.

⬐ kogir

You can deploy PHP to Azure App Services as easily as you can deploy a ASP.Net app.

⬐ staticelf

Yes I know but there is much more of an hassle when setting up the development environment. Even if it wasn't more of an hassle, why use php when the alternatives are as simple?

Even if php has it´s nice things it is still not that great of a language.

⬐ wtetzner

I don't think the point is that PHP isn't as easy to deploy. The point is that PHP doesn't have easy deployment as an advantage over other languages.

So if other languages are just as easy to deploy, what does PHP bring to the table?

I also liked Keith's previous version of this, given at Strangeloop a few years ago [0] and discussed here [1]

[0] https://www.infoq.com/presentations/php-history [1] https://news.ycombinator.com/item?id=7054294

Some informed opinions at: http://www.infoq.com/presentations/php-history and its HN discussion: https://news.ycombinator.com/item?id=7054294

(I remembered seeing some other fb engineering talk on youtube around the release of hhvm on similar themes, a lot of extolling the edit/save/shift-ctl-r workflow and so on, and tried to find that one, but this is what came up.)

⬐ None

None

Taking PHP Seriously is a great presentation that talks about why FB is using PHP: http://www.infoq.com/presentations/php-history

> I am baffled as to why you'd build your castle atop a crumbling foundation.

> I have wondered why FB didn't use a proper language with proper typing to begin with.

I would suggest watching Keith Adams's talk, "Taking PHP Seriously": http://www.infoq.com/presentations/php-history

He goes through why Facebook uses PHP and decided to build upon it to create Hack. I highly recommend watching the whole thing, but the main three things he points to are:

1. Frictionless programmer workflow with a short feedback cycle

2. All PHP requests start out with the same consistent state by default

3. Rigid style of concurrency

⬐ eevee

Which is nonsense, because:

1. I have never seen a framework that didn't go to great lengths to update to new changes quickly in development

2. Which means you lose resources between requests, unless you stuff them into the interpreter/httpd itself. And anyway this is only a problem for PHP, where by default everything runs in the top-level namespace, versus in separate functions.

3. That's a funny way to spin "no concurrency", but you can get that in any language by just not deploying it threaded.

⬐ m3mnoch

blink blink

um. have you used java?

⬐ eloisant

Well, even in Play Framework 1.0 in 2009 there was hot reloading. Edit a file, refresh your browser => it's there.

⬐ Moru

On the Atari ST you didn't even have to hit reload, the webpage reloaded automatically as soon as you saved your file. No need to alt-tab even, just keep webpage open next to your editor. Now get off my lawn.

⬐ eevee

nope

⬐ Terr_

What, you mean with "hot deployment" of your changes?

"Taking PHP Seriously" by Keith Adams (Facebook): http://www.infoq.com/presentations/php-history

Usage of server-side programming languages for websites: http://w3techs.com/technologies/overview/programming_languag...

Facebook is doing something similar, but instead of annotations they are breaking syntax compatibility (for the better, I think). This talk is unfortunately the only reference i can find: http://www.infoq.com/presentations/php-history relevant part starts around minute 22.

⬐ NigelTufnel

Going JIT seems to be the common way of the scripting/bytecode-compiled languages.

Java -> HotSpot, Python -> PyPy, Javascript -> V8 and friends, PHP -> HHVM

⬐ pjmlp

Lisp and Smalltalk were the first ones.

⬐ lispm

McCarthy is mentioned for that, but I guess more work on that was done in the Smalltalk and Self context.

Since quite some time most Lisp systems don't use a JIT. They compile the code ahead of time or explicitly incrementally.

⬐ pjmlp

> Since quite some time most Lisp systems don't use a JIT. They compile the code ahead of time or explicitly incrementally.

I am aware of type hints, but given Lisp's dynamic nature, wouldn't a JIT provide more optimized code than AOT?

⬐ Xdes

It would be nice if they just reinvented PHP. Get the top 20 major frameworks behind them and fork it.

⬐ test1235

That would probably result in the same situation as what we have with Python 2 and 3.

⬐ None

None

⬐ acdha

They're proposing essentially that: start at the 24th slide http://www.slideshare.net/zerutreck/taking-php-seriously-kei...

The smart part is that it's opt-in so you could gradually migrate a large project in-place. The only question would be whether they've broken compatibility with standard PHP or if it's simply stricter — it'd be really easy to get major projects to switch if it was like JavaScript's "use strict" where you can develop in strict mode but run on a legacy runtime.

⬐ Xdes

I'll have to take a look at the Hack language. I've always wanted to try PHP, but I've always been deterred by the cruft (same reason I avoid Java).

⬐ Kiro

Previous discussion:

https://news.ycombinator.com/item?id=7054294

⬐ untilHellbanned

Is there a "how to" in using this with PHP framework X?

Perhaps HHVM just need to be installed and then a change to your Nginx/Apache config needs to happen?

Serious kudos to FB and the developers who are making this happen!

⬐ riffraff

if you are discounting this discussion on account of not being interested in the VM consider it's also quite interesting for the way they changed the language.

E.g. gradual typing with type inference, generics, closures, nullable types, generators and a lot of static checks and removals of "arguably dumb" php features.

⬐ mjohan

What is different from the intermediate code HHVM generates and the code that OPcache/apc stores? Is HHVM always faster compared to code that is cached in OPcache/APC?

⬐ martinml

An opcache code just stores the bytecode so you just avoid the parsing step in each request. It does not inherently optimizes anything, although it has been tried with APC in the past (but finally abandoned). I don't know what's the status with the new official opcache and optimization.

⬐ Nilzor

tl;dr what is HHVM and why should I care as a PHP developer?

⬐ thejosh

Unless you are running something custom/unsupported, if you are using nginx/php-fpm you can just replace it with the HHVM FastCGI and get it to run your code really really fast.

It's great as it makes everything run a lot quicker for clients who use PHP, especially if you have code that needs to be run in PHP on the command line.

Just run it and see :).

⬐ madsushi

Well, it doesn't support mysqli_, which is a very common family of functions, especially since mysql_ is being deprecated. But a lot of stuff does run, as long as it doesn't need mysqli_.

⬐ philo23

HipHop Virtual Machine, it "compiles" PHP into C++. Though it needs to be written in a certain way to work correctly as I understand it.

⬐ unfunco

It doesn't need to be written in a certain way, there may be new features in recent releases of PHP that don't work on HHVM but the HHVM folks are pretty quick to add in support for those features. Here is a little library[0] I wrote in PHP and this is tested on HHVM using Travis (see .travis.yml). I haven't had to write the PHP any differently, it just works (although it's an incredibly small library).

Edit: The speaker in the video also mentions that they have taken the test suites from the top twenty PHP projects and they test them against new releases of HHVM, further confirming that the syntax requires no special attention except for new language constructs.

[0] https://github.com/unfunco/bijective

⬐ tscherno

It`s a jit-compiler for PHP. Code is compiled once to an intermediate representation (like Java) which makes execution faster on subsequent request.

Code does not have to be written in a certain way most of the time because hhvm is 98% compatible to all major PHP-Frameworks[1]. It also features a built-in webserver alltough static performance is lower than nginx.

[1] http://www.hhvm.com/blog/2813/we-are-the-98-5-and-the-16

⬐ plextoria

No, it does not compile to C++, but to bytecode. HHVM's predecessor converted PHP to C++, though.

⬐ blowski

What's the difference between that and APC? The performance, or is there something else?

Confession: I haven't listened to the OP yet.

⬐ agumonkey

Somehow an asm.php

⬐ drdaeman

You're mistaking HHVM with HPHPc.

They're both Facebook projects and one grew inspired by another, but they use different approaches.

⬐ RossM

It's an alternative PHP runtime. It no longer compiles PHP to C++ (it's predecessor hphpc), instead it uses a JIT compiler which gives it better performance over standard PHP, without requiring a compilation step. It's mostly compatible with the standard PHP syntax/stdlib.

It offers an alternative syntax that allows you to give return types of functions, which can give you further speed improvements. There's also a few additional features (for example, it supports similar hinting to the recent ArrayOf RFC).

It's worth checking out, but probably not worth using in production yet - they're working on getting the top 20 frameworks to pass their unit tests in HHVM[0], so there's a good chance your existing apps will run.

[0]: http://www.hhvm.com/blog/2813/we-are-the-98-5-and-the-16

⬐ bovermyer

Phalcon is noticeably absent from that list. Do they have any intention of supporting that, too?

⬐ smoyer

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.

⬐ camus2

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

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

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

I'm sure it could be done, but if it's working this way (and it does seem to be working), why bother?

⬐ Schlaefer

> 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/

⬐ 10098

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.

⬐ dspillett

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)

⬐ nly

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.

⬐ mynames

2) In "Taking PHP Seriously" (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) is redirecting to hhvm page now...

⬐ None

None

⬐ RossM

1) sort of exists in 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

⬐ martinml

Also about 2), haxe: http://haxe.org/doc/start/php

⬐ jbeja

For 2) there is https://github.com/runekaagaard/snowscript

⬐ kodablah

I also wrote one for fun at 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

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

⬐ SCdF

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.

Maybe our code is just awesome, idk.

⬐ virtualwhys

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.

⬐ farinasa

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.

⬐ lxt

It's worth noting that yes, it's changed pretty radically since 2009. There is some amazing stuff going on in the PHP ecosystem these days.

⬐ jafaku

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.

⬐ krapp

Angular can replace much of the MVC work typically done by a backend framework and template engine, by having it be done in the browser.

⬐ coldtea

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

⬐ SCdF

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.

⬐ Aqueous

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.

⬐ virtualwhys

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.

⬐ pkolaczk

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.

⬐ virtualwhys

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

⬐ pkolaczk

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.

⬐ Aqueous

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.

⬐ virtualwhys

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]

⬐ Aqueous

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.

I am just glad to be done with PHP.

⬐ virtualwhys

Agreed, Scala JSON libs are taking the a lot of the boilerplate pain away, but still not quite at the foo.toJson stage.

> I am just glad to be done with PHP

shhhh, this is, you know, a PHP thread ;-)

⬐ camus2

Interesting talk , curious about Hack.

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.

⬐ annnnd

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

This. Well said.

⬐ ciclista

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

⬐ porker

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

⬐ ciclista

>I think it's mostly driven by the recession

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.

⬐ nikcub

slideshare link, for those who want to avoid the InfoQ marketing signup maze:

http://www.slideshare.net/zerutreck/taking-php-seriously-kei...

⬐ gonzo

thank you

⬐ nikcub

I just realized that the MP3 is also behind a login wall, here is a mirror:

http://files.nikcub.com/mirror/takingphpseriously.mp3

37.8MB

⬐ anuraj

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.

⬐ debaserab2

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.

⬐ rmrfrmrf

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.

⬐ aethr

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.

⬐ anuraj

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.

⬐ debaserab2

Sounds really interesting. If you have anything open source you can share, I'd love to see it!

⬐ anuraj

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.

⬐ danielvf

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.

⬐ e12e

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.

1:

http://en.m.wikipedia.org/wiki/Fusebox_(programming)

⬐ girvo

God-damn.

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.

⬐ tracker1

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.

⬐ coolsunglasses

Typescript has a pretty broken type system. Subtyping done wrong (and usually is).

Get more mileage out of Haskell.

⬐ tracker1

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.

⬐ girvo

Node.js is pretty fantastic, and yeah using TypeScript on it is a cool idea too.

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

⬐ tveita

I think it's mostly in HHVM, which is publicly available.

It's not documented, but you can see it in the tests.

E.g., https://github.com/facebook/hhvm/blob/master/hphp/test/quick...

⬐ jimmytidey

I love that he says "if you are a person like me, who is a c++ compiler, I mean c++ person" (16.20)

⬐ elwell

Facebook hires c++ compilers, good to know...

⬐ None

None

⬐ jbeja

LOL!

⬐ bstamour

After years of long build times, we C++ programmers basically have to become mental compilers in order to keep our productivity high.

⬐ joeblau

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.

⬐ bilalq

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.

⬐ joeblau

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.

⬐ dkhenry

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.

⬐ bonemachine

This is not about taking PHP seriously.

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.

⬐ martin_

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

⬐ itafroma

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

⬐ datr

There's a more recent tweet now saying the same thing as well: https://twitter.com/keithmadams/status/422945745528819712

⬐ mitchtbaum

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.

[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

⬐ jhh

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.

⬐ dscrd

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.

⬐ None

None

⬐ apanonymous

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.

⬐ dogweather

Does it attempt to refute John Siracusa's _dissertation_ on 5by5? That's the first hurdle for any pro-php article.

⬐ iends

I tried to find what you are talking about by goolging, and by searching directly at http://5by5.tv/search/results?utf8=%E2%9C%93&q=dissertation&...

I could not find what you meant, could you provide a link?

⬐ nicwolff

http://5by5.tv/hypercritical/17

⬐ pknerd

A post I just made about what PHP has become now.

https://plus.google.com/118197810020432218051/posts/17fNVWVj...

⬐ astrodust

That's a pretty weak post. You really should add some clarification and examples.

⬐ sefk

Nice talk Keith. Honest, clear, and informative. Thanks.

⬐ puppetmaster3

If you use PHP, you can't CDN your HTML. If you use PHP, you can't PhoneGap build your HTML.

I recommend pure HTML (and call API/CORS). (Same is true of ASP, etc.). Pure HTML!

⬐ alien3d

i'm waiting for other language as flexible as php.. write code without thinking error message.

⬐ MichaelGG

Visual Basic has On Error Resume Next. This is generally considered a bad thing.

⬐ chronomex

Is such a thing even possible?

⬐ krapp

Of course not. It only runs a paltry ~80% of the web. Just ignore it. Maybe it'll go away.

⬐ Goladus

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.

⬐ exclusiv

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.

⬐ krapp

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

⬐ chriswarbo

> 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:

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

⬐ marcosdumay

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

⬐ deckiedan

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?

⬐ krapp

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.

⬐ Crito

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.

⬐ krapp

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.

⬐ code_duck

I take it seriously in the same way I have conceded to take Windows and the IRS seriously.

⬐ dubcanada

You may want to take the IRS seriously...

⬐ code_duck

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.

⬐ PavlovsCat

Watch the talk to find out.

⬐ Goladus

The speaker makes the following case:

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.

⬐ astrodust

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.

⬐ deckiedan

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.

⬐ jbeja

Yes, more PHP please!.

⬐ sudy

I am a PHP developer and I like it

⬐ flebron

I really liked this talk.

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

⬐ dcc1

I went university, learned and used C for years, then Java in final years, then .NET on first job

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!

⬐ kbenson

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

Edit: s/Rudy/Ruby/. duh.

⬐ iagooar

The Ruby source code is also a DSL build on top of a bunch of macros.

⬐ justincormack

Lua is proper C code, and readable too. Macros are not necessary.

⬐ seabee

Lua has a much smaller codebase and is simpler than PHP, so I'm not sure the comparison is apt.

⬐ workhere-io

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.

⬐ camus2

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.

They did not.

⬐ tibbon

I'd agree with you, except for Python... that whole Python 3 mess just seems to have been a terribly turn of events when stared at from Ruby-land.

⬐ rev_null

Yes. Waiting for a major release number to break everything is a terrible design strategy.

⬐ debaserab2

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.

⬐ coldtea

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

⬐ ygra

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.

⬐ easy_rider

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.

⬐ ygra

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

⬐ easy_rider

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

⬐ easy_rider

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.

⬐ wylee

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.

⬐ coldtea

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.

⬐ CptCodeMonkey

I am starting to hope for a PyPy 2.8 or a PyPy 3000 that removes the GIL. Will have to wait and see how STM plays out.

⬐ wylee

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

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

⬐ codygman

I thought the perl 6 implementation was actually complete.

⬐ chromatic

It isn't.

⬐ dogweather

Ouch. Sorry to hear it. But good to hear you weigh in.

⬐ coldtea

When an implementation is complete in the forest, and nobody cares and even fewer use it for production code, is it complete?

⬐ annnnd

> Did it break anybody's code? No.

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

Define 'better'. Personally I think Clojure has a lot going for it, and it's better than a lot of languages in a many ways. However, for the kind of application I work on PHP is significantly better fit than Clojure. Most of the points made in this talk apply to my situation. http://www.infoq.com/presentations/php-history

⬐ lmm

The main "better" I care about is "fewer gotchas and special cases to memorize"; that's not the only thing that matters about programming languages, but it's a big factor. I don't have time to watch a 40-minute video; arguments I remember hearing from something similar are the very fast coding feedback cycle (easy with modern-day rails/django/etc.), "it's better than it used to be" (not really an argument), availability of frameworks (but I've never seen an actual example of the advantages that you don't get in other languages/frameworks), large standard library (again, present in other languages), dependency management (which seems more like php catching up with other languages than overtaking them), deployment (may have been a good argument in the pre-wsgi days and when Apache was the only webserver around, but not true any more IMO). What is it you see PHP as better than ruby/python at?

⬐ justinhj

Well firstly the gotchas very rarely get me. I found the same with Javascript. The inconsistent and odd data conversions make fun slides to denigrate the language, but in practise they seem to be easily avoided.

I realize posting a 40 minute video to support my point is a bit lazy and unfair but you seem aware of some of the key points fortunately.

First let me admit that we have a php legacy codebase, so porting that to another language, even if we had a strong desire too would probably be prohibitive.

I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5. It's very easy to write code fast, and then come back and refactor it later. Using PHP Storm as an IDE with a very good debugger and PHPUnit to build a suite of tests for everything we do means that gotchas are always eliminated before production, and with PHP I find things are either working or completely broken with not much in-between.

I guess having a strong unit test suite, or really it's more of an acceptance test suite, is something you can do in most languages, but the assurance it gives us enables us to share large code bases between teams, doing frequent merges of features. You can have large numbers of programmers with varying abilities and even programming styles hitting the code without too much headache.

The talk also mentions state. Not sharing state between requests except explicitly. You don't have to worry about complicated background threads, resource leaks, memory leaks. Even crashes are less of a big deal since you just lose one request to it, not the whole server like with Java et al.

PHP's array is a swiss army knife with lot's of useful functions for transforming data, which is a lot of what we do on the server. I can map, reduce and filter data. I can dynamically handle arrays or single objects in the same function, or handle arrays of different kinds of data without any fuss. In short going from what I want to happen to having it happen is very fast.

Background tasks are queued and run on other systems including some written as bash scripts or in Python, Go and node.js. These languages are a better fit for these jobs and so we ditch PHP for those.

What Facebook is doing with HHVM (run faster) and Hack (add type safety as needed) is pretty interested and we've adopted the first but not yet the latter.

Hopefully that's flavour of what I like about using PHP. I have not written more than a few lines of Ruby so I cannot comment on that. I have done some maintenance work on a Python server but not with a modern framework. I'm not sure Python with a modern web framework offers all of the advantages I've mentioned above but I am open to being enlightened on that.

⬐ lmm

> the gotchas very rarely get me. I found the same with Javascript. The inconsistent and odd data conversions make fun slides to denigrate the language, but in practise they seem to be easily avoided.

They don't tend to actually "get" me, but I feel like they're always there in the back of my mind, taking up space that could be used for something more useful. It's not a huge difference, but it's there.

> I definitely feel super productive in PHP. I've been able to knock out a new app feature in 1 day, which to build the equivalent in Java would have been at least 5.

Well sure, we're talking about a very different style of language. But I think Ruby or Python get you the same thing. Certainly you have map/reduce/filter (and Python's for comprehensions go one step further), and dynamic typing.

> with PHP I find things are either working or completely broken with not much in-between.

Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's hard to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.

⬐ justinhj

> Interesting; what bothers me the most when using PHP is that it feels easier to introduce security flaws than other languages. Not that it's hard to code safely, but sometimes the most obvious way to e.g. access a database is the unsafe way (which is partly just because there're a lot of old libraries and bad advice floating around). Charset handling is a similar area; I've seen lots of PHP code that appears to work fine but goes wrong when given non-ascii characters. It wouldn't surprise me if there were similar issues with timezones, though I haven't dealt with them enough in PHP to be sure.

Well in my case we work on mobile apps so the client doesn't do anything unexpected with respect to character sets and time zones. Probably that's harder when working with random web browsers. Security wise I agree with you it's easy to do wrongly, especially with the simple DB API's that can be used naively.