I'm maintaining a huge web application mostly written in PHP. We (well. back then it was just me) began doing this back in 2004. Back in 2004, PHP was a very s

I'm maintaining a huge web application mostly written in PHP. We (well. back then it was just me) began doing this back in 2004. Back in 2004, PHP was a very sensible solution: It was the language I knew best (we had little time for the project, so going with a language I knew felt sensible), it was easy to deploy and back then, there weren't that many alternatives anyways: Ruby was in its infancy, for Python you had thread safety issues with mod_python or you went CGI, Java was and continues to be just ugly. JavaScript back then was still just a toy language. No Node.js or anything. That would have left me with mod_perl, but looking at where we are today, that would have been an even worse decision it seems. Fast forward 6 years. The application consists of over 100'000 lines of PHP code alone now. It's in production use for many customers which serve tens of thousands of end users. It's not only a traditional web application, it also serves as an API for custom-made tablet pc applications (before we had the iPad), for GPRS-connected barcode scanners and last, but not least, for native Windows Clients (all developed by our company, using various languages). While I really hate some aspects of PHP by now and I would love to have a Ruby or Python codebase to work with instead, rewriting all of this is out of the question. Customers depend on this to work exactly the way it works now (they panic even if a link is two pixels off - welcome to the enterprise). While I might be able to exchange some components with something else, I don't see the benefit it would provide - it would do nothing but make maintenance harder because I'd add another dependency to keep track of. The only thing I could do is rewrite the thing. But by now, there's more than 30 man-years of work that went into this. Sure. Redoing it wouldn't take the same amount of time, but considering it would have to look exactly the same (probably I couldn't even get customers to accept different URLs), where's the point in that? OTOH, despite being done in PHP and tailored to sometimes crazy customer requirements, the code base is sufficiently clean to work with and it's constantly improving. Bad parts get factored out, good parts arrive, so it's not all-bad. We are embracing new technologies as they become available and fit our product. Our CSS is now written in SASS, we moved from pure DOM scripting to Prototype to jQuery, we make use of the latest features of PHP (now Closures and anonymous functions from 5.3) and of our database (constantly running latest Postgres). Even though it's PHP, it can still be fun. Considering recruitment: Granted. It might be harder to convince a good programmer to work on this "ugly" PHP project. But a) we are not just doing PHP (just mainly), b) the code base is, as I said, quite clean and c) even though the code base might be in a language you don't like, the basic concepts of our profession still apply. You can still discuss and solve interesting problems and you can still create great solutions to these problems. If you don't want to take part in this adventure just because you don't like the language this is done in, then, frankly, you are not the person I want to hire. Even though programming is the coolest thing you can do on this world, it's still a job and not everything can always be unicorns and rainbows. If you can't see this, then I don't need you.