Ask HN: Learning PHP, reluctantly, for a lisp hacker
My closest point of reference is Django/Python, and professionally I've spent the most time in C# and personally in Common Lisp (of course recently exploring Clojure).
I enjoyed Cal Henderson's book Building Scalable Web Sites, which is PHP-based but not too PHP-specific.
With that background, let me ask for the community's judgment and experience:
Is there a recommended experienced programmer's guide to PHP with limitations, gotchas, and quirks?
Hacker preferences on IDE's, free or not?
Tools like remote debuggers? Lint equivalent?
Maps of the community, libraries, and available resources?
Tradeoffs of Modern frameworks, especially on the ORM side - what's the closest thing to Hibernate?
Security, testing, performance best practices guides?
Possibilities and limits for integration with C, JVM, .Net, and dynamic languages' existing libraries?
Also, using HaXe and compiling to PHP - is it a mature technology and the cure-all it appears? Are there gotchas?
6 comments
[ 3.6 ms ] story [ 28.2 ms ] threadFor a person with C# background it offers the advantage of extending the language if you need to. For IDE I use Netbeans. For frameworks I use CodeIgniter and CakePHP. For ORM I use Doctrine. For CMS I use Drupal. For one two night projects I use Wordpress.
There is so much in PHP in the web that it would be hard to keep yourself from re-discovering the wheel!
There are three reasons to use PHP. One is that it's very simple to deploy because there aren't a lot of layers between you and Apache's C code, and those layers have been exhaustively tested.
The second is that it is very easy to learn and there are lots of people who can tinker with it. It's generally easy for another PHP programmer to get your code running. It's generally easy for them to read and understand your code. It's a standard, and it's a simple standard. (A bit too simple, for problems far outside its sweet spot -- but that's what other platforms are for.)
The third is that you want to integrate closely with one of the toolkits or frameworks that have already been written in PHP.
HaXe breaks all of these features. I see no reason to use it on a production project. If your problem is truly unsuitable for PHP you should use something else. (You have a choice; this is server-side code.) If you can't bring yourself to write code without fancy language features that are missing from PHP you should find another project or another job. You are doing yourself no favors by trying to paper over the issue, whatever it is.
I'm wondering about HaXe because I still want the people on the team who can appreciate it to get a high productivity language with snob appeal, but without fracturing the project into two code bases that need to cross type system barriers to call into each other, as would be the case if the "language snob components" were in, say, a JVM language.
The price is that the PHP-only people won't be able to read the cross-language group's code effectively; but frankly I don't think they'd do much of that anyway.
One hypothetical setup would be:
1. Doctrine ORM
2. HaXe-to-PHP business logic and harder UI logic, calling the ORM and referring to the PHP-only pieces by links only
3. PHP pieced together by tinkerers from lots of CRM-like components for simpler front end stuff, occasionally calling the ORM and the HaXe-to-PHP classes
Separately, being able to cross-compile to JavaScript/Flash for the client - and doing I/O without breaking the type system - looks exciting.
So, I'm considering HaXe to keep a fraction of the second and third PHP benefit you list.
...so why not just go ahead and make it impossibly difficult for the junior people to read your code? That should really encourage them to enjoy working with you.
You are missing the forest for the trees. Let me outline the problems I foresee:
You are going to create a huge political and management problem -- deliberately driving a palpable wedge down the middle of your team -- by implementing the "harder" parts of the app in a language that the PHP developers not only can't understand but aren't expected to understand, a language that they will have very little incentive to learn. (I know plenty of PHP devs who are curious about Rails or Django; I've met plenty who use PHP frameworks; I've never heard the word HaXe pronounced. It is not worth having on one's resume.)
Why not just force the PHP devs to wear little dunce caps when they're in the office? Perhaps you can have a ritual where you throw eggs at them at every morning meeting. Surely that will help your team to gel.
Meanwhile, be very careful about referring to your non-standard compiled extension to PHP as a "high-productivity language". Eternal optimism is the occupational hazard of software engineers. I bet you'll find that any gain in expressive power will be more than offset by: Waiting for the compiler; remembering to run the compiler; writing makefiles that remember to run the compiler for you; fixing bugs in the compiler; adding missing features to the compiler; justifying the need for the compiler to the PHP devs; justifying the need for the compiler to your boss; explaining your architecture to every new engineer that comes on board; trying to guess which bug is in which portion of the code (is it the HaXe, the PHP, the compiler, the PHP runtime... or perhaps even the language that the compiler is implemented in?) so that you can assign an engineer from the appropriate language background to fix that bug; spending your own valuable time finding and fixing simple bugs that an intern could fix, except that the interns can't read your code...
Meanwhile the rest of your colleagues will conclude that you're just some sort of language crank. All this grief, because you're unable to bring yourself to write code in a language without closures.
Just build it all in PHP and try to enjoy your (perhaps temporary) journey into another culture. Or make the case to build it in Rails or Django and tell the PHP developers that they're going to enjoy their journey into another culture. ;) Or make the case that the architecture divides cleanly into two components, one that is best built in Django and the other built in PHP. (If you find that the inability to call PHP routines from Django, or vice versa, is a liability, it's a sign that the architecture doesn't actually divide cleanly and you've got to pick one platform or the other.) Or find a different job.
(And forget this crazy notion of cross-compiling your code into JavaScript. YAGNI. It's like claiming that it's going to be easy to cross-compile your pickup truck into a Honda Accord -- after all, they're both made of steel and auto parts, and steel is malleable, and auto parts are interchangeable. And that isn't exactly false -- I have a fun book called Build Your Own Sports Car which literally tells you how to turn an old pickup truck into a Lotus Seven replica -- but it's only for hobbyists, and it's very inefficient because you have to optimize the process by hand, particularly when it comes time to fix bugs.)
And hey, apparently there's closures in PHP 5.3 anyway...