4 ms·

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

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 17y ago
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 17y ago
  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...

mechanical_fish 17y ago

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 17y ago
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...