[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Friday 17 October 2008 20:41, Simon Waters wrote: > Aaron Trevena wrote: > > PHP isn't exactly the nicest language to develop large applications with > > I'm not sure since the advent of PHP5 that it is particular good or bad > in terms of scaling projects. > > There is a lot of bad PHP out there, and this I found a major issue for > learning PHP, because a lot of the examples are either poor, or incomplete. > > Certainly I've seen a few PHP projects, we host one, where a number of > standard PHP5 object libraries were loaded up, and the meat of the > application done in just a few lines. So I've seen good clean PHP code > that could easily form the basis of big projects, I just don't know > enough to write it. > > I thought the failings of PHP were mostly security related, vagaries > over how different servers do escaping/global variables/retrofitting new > security, and the odd naming convention for functions (str_replace > becomes str_ireplace, ereg_replace becomes eregi_replace etc). I don't > think these are scalability issues; indeed if you control the > environment PHP runs in, and the standards to which PHP is written, in a > project the security and hosting vagaries disappear, and you are mostly > left with the weird naming convention, but otherwise perfectly > serviceable language. Indeed some of the security tools for PHP mean you > can set quite detailed checks to stop PHP apps grabbing resource or > doing risky things, which many more secure languages never bothered > implementing. Kind of like why Windows has all the best personal > firewall products, because in Windows XP it needed them. > > This document: > > http://www.tnx.nl/php.html > > reminded me of Larry Wall's statement about not comparing Perl to a real > language (Only they are comparing PHP to Perl). > > I think there is a strong case if you have an open choice of language > for such projects looking for languages with established libraries in > the area you need. Here Perl with CPAN are simply amazing, and much as I > detest Perl (Larry was right about real languages), you'd be mad to > reinvent a lot of CPAN just because you really wanted to use language X > instead. > > It would have to be a very big project indeed to justify much wheel > reinventing. That said I'm not sure how extensive Java libraries are, I > don't think java.net is anything like CPAN, but there are a lot of > commercially relevant Java libraries, so it may depend on the project > domain. Theres not a lot of reinventing the wheel to be done - there is however a lot of regrouping to do. A look at CRUDs and blahOnRails and ASP.NET tutorials tends to show the lack of real system design experience in all these setups. They are all nice for prototyping but tend to lead you down paths of least resistance that lead to much more complicated systems than necessary in the long run: Its easy to knock up a form so you knock up lots of forms rather than make one decent dynamic form generator a working from that. Good Object Oriented design and correct partitioning and distribution of work load across systems helps enormously: I worked on one project where I didn't have control over the db and the customers liked to come on line and check their old orders (to rebuild new ones) and asked for the billing to be added to the db. I was told that was not how one used a relational database so the cost had to be worked out every time, and of course once prices changed or the customer got new rates the problem of regenerating correct BOS for old orders became horrendous - and you have to keep them for 6 years for tax purposes - with 300,000 products and 30,000 customers that was a real doozy! It shouldn't really matter if your using compiled or interpreted code on the web server - your pages shouldn't be doing anything complicated: Check security Get/Put data into db VIA STORED PROCEDURES* Get new Data and let the browser use CSS/AJAX for presentation. Get javascript to do any form processing/entry checking so you never have to send a page back if you can avoid it. Send data back to server * get the db to do triggers (and external procedures) if anything fancy is required so the page returns in the users life time and you can use prefix or suffices to returned column names for automatic form handling. So if you use the bits of the available system for what they're best suited to you wont have to go out and pay M$ several tens of thousands of pounds for the dubious benefit of quickly creating an high-maintenance system which wont go together any faster than a well thought out one. And do you know that the EU seems to be creaking on software patents so MS may be able to demand extra money in the future for you having used .NET technology in your product?? Tom te tom te tom -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html