Hacker News Reader

Comment by pkkk | Hacker News Reader

Java and JVM as reliable platform +1 just go whatever language you want Scala, Haskell, Ruby... here language doesn't matter. If you want to create custom web based application (not RIA one ofc) go django or rails, now it's more matter of taste both choices will give you a lot benefits, and ofc you can run it ontop of JVM. But if you considering building anything today on PHP (when you have sooooooooo fucking many better platforms) you are incompetent and plain stupid, because it will be a big technical debpt for the whole project.

View on HN

I could live with sun+java but oracle+java? no thanks... it can be technically perfect, i really don't care...

> But if you considering building anything today on PHP (when you have sooooooooo fucking many better platforms) you are incompetent and plain stupid, because it will be a big technical debpt for the whole project.

I think we have a bunch of stupids like facebook and mailchimp... Php or any other programming language is a tool, a proven one. So if you can do some amazing things go for it.

"You use X then you are an idiot. Y is for masters !" approach is childish and proves that you can only use Y technology.

From the CTO perspective choosing a niche language is considered a much bigger risk because when your lead developer gets bored and quits you then have to scramble to find another lead dev who can quickly grab the reigns and continue. I've talked to many a CTO who have mandated PHP for exactly this reason, because you can throw a rock and hit a dev who knows PHP.

Sure, but what's the chance you hit a good dev ?

Still better than finding a good Haskell dev.

Oh, a snide question deserves an equally snide answer. =)

Probably better than finding a good dev in other languages for web development considering all the good PHP developers are still using PHP, and all the ones that couldn't cut it went on to learn the next LotM.

Honest answer: The same chance of hitting a good dev regardless of the language.

Unless you're Werner Vogels, in which case you mandate whatever the implementation team feels like using, as long as it scales and adheres to the service interface specifications.

I've heard Werner Vogels talk about this subject before. He chose Ruby for one of their projects specifically because they wanted very fast iterations, even though they new it wouldn't scale and they would have technical debt down the line. I don't think you are accurately describing how Amazon does things.

I don't know about the more technical debt stuff, sure if you go off and use all the parts of the language any old way it will let you make a mess but there is no reason you can't apply some of the same practices that something like rails enforces on you.

Agreed. Symfony2 is an excellent base for this reason--Fabien Potencier and friends are, as far as I'm concerned, the guys to look at for writing clear, maintainable, excellent PHP code.

Agreed!

It's not only Symfony2, PHP has a lot of high-quality projects going on: Zend Framework, Doctrine, Solar/Aura, Twig, Lithium, Jackalope, FLOW3 and probably much, much more.

While some of your other listed projects are okay (as it happens, Doctrine and Twig are both used as part of Symfony2), Zend is generally considered about as ancient as CakePHP today, and I don't really know anyone who recommends using it for new projects. Most of the "big-name" PHP projects out there are creeping horrors (I'm looking at you, Wordpress), and Zend kinda falls into that bucket.

Personally I'd be very wary of Lithium as the code looks pretty slipshod internally from a brief scan into it, but Solar and FLOW3 are solid projects.

ZF is from a totally different league than CakePHP or Wordpress. Yes, a bit ancient today but in many parts it's a solid, well-written, flexible and extensible code well-suited for more "enterprise" needs. Probably more "production-ready" than Symfony2 is at the moment. Plus: ZF2, which will require PHP5.3, is in the works so it should make the project more "relevant" again.

Didn't dwell too much into Lithium's code but saw they have some interesting ideas also based on 5.3 features, e.g. they use a sort of aspect-oriented programming based on closures and lambdas. Sounds cool, even if only for experimenting with different programming approaches.

ZF2 may fix a lot of the complaints I (and other folks) have with Zend, but right now it's really hard to recommend it.

It's actually pretty much in the same league as CakePHP: old and slow. Not much to recommend it right now. (Symfony2 actually can pull in Zend-based libraries on its own without a problem, which is why among the more sarcastic of us I've heard Symfony2 described as "Zend 2 but actually here".)

Well, Symfony2 itself only until very recently was using some of the ZendFramework libraries internally (and Fabien often praised ZF), which I would say comes as a proof that it is a solid code, even if it's obviously lacking in some parts comparing to younger alternatives. In many cases it's still the best thing in the market though (Zend_Search_Lucene, Zend_Pdf, Zend_Amf, Zend_Gdata come to mind).

Well-written code can still be old and slow. ;)

A big shout out to Yii Framework - its really fast!

check benchmark: http://www.yiiframework.com/performance/

Don't forget about Kohana. It's an excellent, well designed, framework for those using PHP.

Don't know why this was awarded the downvotes. For some types of applications, Kohana is perfectly fine.

Strongly disagree. Kohana is, IMO, rather poorly designed (while rewritten, it's still fundamentally all too similar to CodeIgniter for my liking). There is not a strong focus on security[1], there is not a strong focus on modernity--it's inexcusable to not be on PHP 5.3 today, and while Kohana will run there it does not understand PHP 5.3 idioms and features--and the code quality, after auditing, is not all that impressive.

Symfony2, on the other hand, puts a fairly strong emphasis on security, is fully based around PHP 5.3 idioms, and is written with sparkling code.

[1] - http://dev.kohanaframework.org/issues/2766 comes immediately to mind; forget the resolution of the bug (such as it wasn't), the behavior of the developers is not good. I get the feeling from those who've used Kohana that this isn't a unique situation.

Reply on news.ycombinator.com