4 ms·

There are two things that strike me as odd in this report: 1) Why would you go through the process of switching the language. There are perfectly suitable fram

by caillou 16y ago

There are two things that strike me as odd in this report: 1) Why would you go through the process of switching the language. There are perfectly suitable frameworks in PHP, e.g. Symfony, that have the exact same approaches than Django and ROR. MVC, ORM and configuration over Convention over Configuration. Once you have a team that is good at a Language, you'll loose a lot in switching... and this leads me to the second question: 2) How can it take 22 month to rewrite this kind of application? A bit of CRUD and workflow should not take so much time. WDYT?

weswinham 16y ago
1) When evaluating the options (mid 2007), Django and Ruby on Rails were the two projects with the most community momentum, and I personally put a lot of weight on that. I had used and was a fan of CakePHP, but the reality was that porting the mess that we had to either CakePHP or Symfony (the two we look most closely at) would have taken a significant amount of work. Since we knew that it wasn't possible to place development on hold, the main requirement was that whatever we did would need to live side by side with the existing code, and it was only a little bit more difficult to do that with another language and framework than another framework written in PHP. I don't at all mean to say CakePHP or Sympfony would have been bad choices, but our technical team was such that switching languages wasn't a hurdle. I think the number of startups that have chosen Django or RoR as their platform of choice since mid 2007 in part validates our decision, but that doesn't mean other choices would have been bad. 2) It took 22 months to eliminate the last bit of PHP, but that was by no means the focus of development. During that time we made very large changes to the application based on things we learned from our customers. The reality is that no matter what technology we would have chosen, basically every single line of code would have been rewritten over the next two years. There was a little bit of us embracing technical debt in spreading the full port over 22 months: http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html http://www.startuplessonslearned.com/2009/07/embrace-technic... Thanks for the questions -wes
variety 16y ago
Why would you go through the process of switching the language? Well, if you want to know the truth of it: If that language just so happens to be PHP, then they might have a whole bunch of reasons. A lot of people just don't like PHP; don't consider it to be a very fun or interesting language to program in, and in particular, don't consider it long-term viable for large, multi-faceted projects.
- caillou 16y ago
  I've heard a lot of that. Yet, mostly from people who've never or hardly ever used the language. By reputation, PHP is a bit like JavaScript. JavaScript was this language nobody liked. It wasn't even considered a real language by most programmers. Some of it's design errors made it a language with low barrier to entry. Hence a lot of mediocre programmers made it unpopular with code that does not deserved to be called code. This changed with people like Crockford and his 'JavaScript the good parts'... It's pretty much the same with PHP. It gets the job done very easily... And once you know what you do, you can rely on it for large projects too. Especially with the changes that were introduced in the latest release: Namespaces, Closures, ...

by caillou 16y ago

weswinham 16y ago

1) When evaluating the options (mid 2007), Django and Ruby on Rails were the two projects with the most community momentum, and I personally put a lot of weight on that. I had used and was a fan of CakePHP, but the reality was that porting the mess that we had to either CakePHP or Symfony (the two we look most closely at) would have taken a significant amount of work. Since we knew that it wasn't possible to place development on hold, the main requirement was that whatever we did would need to live side by side with the existing code, and it was only a little bit more difficult to do that with another language and framework than another framework written in PHP. I don't at all mean to say CakePHP or Sympfony would have been bad choices, but our technical team was such that switching languages wasn't a hurdle. I think the number of startups that have chosen Django or RoR as their platform of choice since mid 2007 in part validates our decision, but that doesn't mean other choices would have been bad. 2) It took 22 months to eliminate the last bit of PHP, but that was by no means the focus of development. During that time we made very large changes to the application based on things we learned from our customers. The reality is that no matter what technology we would have chosen, basically every single line of code would have been rewritten over the next two years. There was a little bit of us embracing technical debt in spreading the full port over 22 months: http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html http://www.startuplessonslearned.com/2009/07/embrace-technic... Thanks for the questions -wes

variety 16y ago

Why would you go through the process of switching the language? Well, if you want to know the truth of it: If that language just so happens to be PHP, then they might have a whole bunch of reasons. A lot of people just don't like PHP; don't consider it to be a very fun or interesting language to program in, and in particular, don't consider it long-term viable for large, multi-faceted projects.

caillou 16y ago
I've heard a lot of that. Yet, mostly from people who've never or hardly ever used the language. By reputation, PHP is a bit like JavaScript. JavaScript was this language nobody liked. It wasn't even considered a real language by most programmers. Some of it's design errors made it a language with low barrier to entry. Hence a lot of mediocre programmers made it unpopular with code that does not deserved to be called code. This changed with people like Crockford and his 'JavaScript the good parts'... It's pretty much the same with PHP. It gets the job done very easily... And once you know what you do, you can rely on it for large projects too. Especially with the changes that were introduced in the latest release: Namespaces, Closures, ...