

Ask HN: Learning PHP, reluctantly, for a lisp hacker - waldrews

I hear awful things about PHP as a language and have barely touched it, but it looks like I might need to get my hands dirty and learn it in enough detail to make architectural choices that will haunt my team for a while.<p>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).<p>I enjoyed Cal Henderson's book Building Scalable Web Sites, which is PHP-based but not too PHP-specific.<p>With that background, let me ask for the community's judgment and experience:<p>Is there a recommended experienced programmer's guide to PHP with limitations, gotchas, and quirks?<p>Hacker preferences on IDE's, free or not?<p>Tools like remote debuggers?  Lint equivalent?<p>Maps of the community, libraries, and available resources?<p>Tradeoffs of Modern frameworks, especially on the ORM side - what's the closest thing to Hibernate?<p>Security, testing, performance best practices guides?<p>Possibilities and limits for integration with C, JVM, .Net, and dynamic languages' existing libraries?<p>Also, using HaXe and compiling to PHP - is it a mature technology and the cure-all it appears?  Are there gotchas?
======
mechanical_fish
_using HaXe and compiling to PHP - is it a mature technology and the cure-all
it appears?_

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.

~~~
waldrews
I appreciate the candor. The reason for PHP over my first choice of Django is
that this project has a lot of junior people with PHP-only skills.

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.

~~~
mechanical_fish
_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._

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

~~~
waldrews
Ok. Point well taken. Thank you. I'm being both over-optimistic and arrogant.

And hey, apparently there's closures in PHP 5.3 anyway...

------
yannis
Beauty is in the eye of the beholder and if one considers that PHP started as
a templating language and has evolved in what it is to-day the 'awfulness'
goes away.

For 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!

------
rits
docs.php.net is exhaustive, especially for a lisp hacker.

