A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2008 yearNo PHP for large projects? Why not? - page 1
User InfoPosts
No PHP for large projects? Why not?#1
I've read a few posts where people have stated (not suggested, not discussed, not offered) that PHP should not be used for large projects.

Being a primarily PHP developer, I ask two questions:


What defines a "large project"?
Why not? What are the pitfalls of using PHP


I run a small development team and I know from experience the quality construction, organization, documentation, commenting and encapsulation are our highest priority. We are able to develop great projects using our own framework and approach but still, I don't want to invest further if I'm wasting my time.

Thoughts?

posted date: 2008-12-21 15:42:00


Re: No PHP for large projects? Why not?#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2008-12-21 15:42:01


Re: No PHP for large projects? Why not?#3
Our company runs several large-ish web sites using PHP, and have had no problems that were related to the language.

posted date: 2008-12-21 15:47:00


Re: No PHP for large projects? Why not?#4
A lot of people who say not use it are really saying don't use PHP 4. It comes down to thisyou can write good code in any languageandyou can write bad code in any languagePHP can very often lend itself to becoming tangled spaghetti code libraries and make your 'application' really just a series of scripts (see Moodle for a good example of this...) I think a lot of the 'Don't use PHP for large stuff' is coming from PHP being hacked up from it's original purpose: a templating language. Which I can understand, but there are lots of projects that prove you can do it (Drupal, mediawiki, Facebook).

posted date: 2008-12-21 15:58:00


Re: No PHP for large projects? Why not?#5
As the question I linked was deleted, I'll place some of it here:QuestionI made a tongue-in-cheek comment in another question thread calling PHP a terrible language and it got down-voted like crazy. Apparently there are lots of people here who love PHP.So I'm genuinely curious. What am I missing? What makes PHP a good language?Here are my reasons for disliking it:PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design. PHP has inconsistent parameter ordering of built-in functions, eg array_map vs. array_filter which is annoying in the simple cases and raises all sorts of unexpected behaviour or worse.The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!Overly-broad implicit type conversion leads to bugs. I have no problem with implicit conversions of, say, float to integer or back again. But PHP (last I checked) will happily attempt to magically convert an array to an integer.Poor recursion performance. Recursion is a fundamentally important tool for writing in any language; it can make complex algorithms far simpler. Poor support is inexcusable.Functions are case insensitive. I have no idea what they were thinking on this one. A programming language is a way to specify behavior to both a computer and a reader of the code without ambiguity. Case insensitivity introduces much ambiguity.PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.PHP performance is abysmal without caching. Does anyone sell a commercial caching product for PHP? Oh, look, the designers of PHP do.Worst of all, PHP convinces people that designing web applications is easy. And it does indeed make much of the effort involved much easier. But the fact is, designing a web application that is both secure and efficient is a very difficult task.By convincing so many to take up programming, PHP has taught an entire subgroup of programmers bad habits and bad design. It's given them access to capabilities that they lack the understanding to use safely. This has led to PHP's reputation as being insecure.(However, I will readily admit that PHP is no more or less secure than any other web programming language.)What is it that I'm missing about PHP? I'm seeing an organically-grown, poorly-managed mess of a language that's spawning poor programmers.So convince me otherwise!Top Rated AnswerI'll take a stab at responding to each of your bullet pointsPHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design.I both love and hate this topic. Because at its core, this issue is correct. Why are some bi-word function split with an underscore, and some aren't? Why do needle and haystack parameters swap positions in the argument signature sometimes? It's ridiculous. But at the end of the day... does this really matter? My IDE with intellisense and php.net just a browser click away, this is just plain not that big of a deal. Is it a negative against PHP as a language? Yes. Does it hinder my ability to be an effective programmer? No.The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.Personally, I think this is not a good point. Deprecation is necessary to the evolution of a language, especially one that has as much kruft as PHP does. PHP gets a lot of flak for "making it easy to be a bad programmer*" but at the same time, the PHP group also gets in trouble when they try to remove stupid constructs from the language, such as call-time pass-by-reference. Eliminating call-time pass-by-reference was one of the best moves they ever made. There was no easier way for a novice developer to shoot themselves in the foot than with this "feature".A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!I don't think there's a general lack of consideration at all, I think you just got stung by this particular change and have been left with a sour taste in your mouth. Language changes are often known months if not years ahead of time. A migration guide was provided for the move from 4 to 5, and the version differences are documented in the manual. Call-time pass-by-reference was a horrible "feature" and doesn't give the developer any expressive power they can't get by other means. I'm glad it is gone (along with other crap like magic quotes)Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!I have mixed feelings about this. Part of me thinks "who cares, character escaping has no meaning outside of a string anyway", and part of me thinks "surely they could use something better". But could they? I don't know, I'm not a developer for the Zend parser. Is it a huge oversight that until 5.3 PHP never had namespaces at all? Yes, absolutely.Overly-broad implicit type conversion leads to bugs. I have no problem with implicit conversions of, say, float to integer or back again. But PHP (last I checked) will happily attempt to magically convert an array to an integer.I think it's ok to disagree with how PHP does this, but disagree that it makes the language "bad". But ask me how much I want to sit in this topic and argue about weak vs strong typing. (P.S. I don't, at all) For the record: PHP will issue an E_WARNING level error when the type of an argument matters and cannot by solved by coercion. Poor recursion performance. Recursion is a fundamentally important tool for writing in any language; it can make complex algorithms far simpler. Poor support is inexcusable.PHP is a DSL for the web. I've been doing it full-time for 8 years and have maybe used recursion 4 or 5 times, usually for some type of annoying directory or XML traversal. It's just not a pattern that is needed for web development that often. I'm not excusing the slow performance, but this is an academic issue far more than it is a production issue. If you need really powerful recursive performance, PHP is already the wrong language for you.Functions are case insensitive. I have no idea what they were thinking on this one. A programming language is a way to specify behavior to both a computer and a reader of the code without ambiguity. Case insensitivity introduces much ambiguity.I totally 100% agree with this.PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.*Hmmm, this topic sounds desperately familiar...But seriously, I find it remarkable that people will complain about a language that will absolutely 100% let you implement any output system you want (the sheer volume and style of PHP templating systems alone speaks to this) - OR - skip all that overhead and just output directly. This does not make PHP bad at all. It's part of what makes PHP good.PHP performance is abysmal without caching. Does anyone sell a commercial caching product for PHP? Oh, look, the designers of PHP do.Do you mean bytecode caching (like an accelerator), or output caching?If the former, then I don't really know how much I care about this topic. Accelerators are free and easy to run. We could argue about why it isn't part of the language but in the end, I don't think it matters much.If you are talking about output caching then I don't know what to say to you. ANY web project with significant traffic needs caching (seed podcast #27, for example). This is not a PHP-specific issue at all.In summary, I think you consider PHP a "bad" language in a very academic fashion. And in your previous post you were probably voted down by people like me who use PHP to "get things done". Second Top Rated AnswerAll your criticisms (and some more) are valid. You are allowed and even expected to hate PHP. But, then again, it has some benefits:UbiquitousFast (especially using opcode caches)Huge community (and great documentation)WorksFinally, you can overcome many if not all the downsides by writing good code you'd write in any other language. You can write solid, secure and good smelling code in PHP, which many times will run faster and be easier to host and to scale than many alternatives.Third Top Rated AnswerWhat is it that I'm missing about PHP? I'm seeing an organically-grown, poorly-managed mess of a language that's spawning poor programmers.Simple. The fact that poor programmers get very defensive about their language. ;)PHP is easy to learn, much easier than the alternatives, and once you've learned it, it's not exactly obvious 1) what's wrong with PHP, 2) how the alternatives are better, and 3) how to switch to, and learn, one of the alternatives.And perhaps the fact that, well, what alternatives do people have? ASP? That has plenty of problems on its own, from being unable to run on the majority of webservers (Apache), to some ridiculous and overengineered design choices on its own (webforms? Viewstate? AJAX where your asynchronous" requests are intercepted and run sequentially?)Ruby on Rails? Well, perhaps, except how many webservers support it again? It's not exactly easily approachable at the moment. And it's slow.So perhaps PHP's "strength" is really that no good alternative exists.At least this is why I stay away from all web programming when at all possible. PHP sucks, and I'm not too keen on any of the alternatives either.PHP has so many fundamental problems that it's not even funny. From the lack of unicode support, to the many implicit type conversions which often lead to unexpected security holes, to the complete mixing of presentation and... everything else, or to the default database module which doesn't (last I checked) use parametrized queries. We're talking about a language made for two things, database access and generating HTML, and which is terrible at both.It's just a nasty mess, a language designed by people who aren't qualified, or able, to design a language. ;)

posted date: 2008-12-21 16:00:00


Re: No PHP for large projects? Why not?#6
Facebook is kind of a tortured example. Facebook isn't a complex business app. It is a fairly simple that is scaled very highly.

posted date: 2008-12-21 16:05:00


Re: No PHP for large projects? Why not?#7
For me the worst PHP sin is coupling of presentation with business logic. It's not that you can't write it in a better way, but it doesn't encourage you to, and if anything it encourages you not to. A large number of security vulnerabilities are associated with PHP sites, too. I can't prove it is disproportionate (after all a lot of sites are written in PHP), but I suspect it is. If I'm right, then since security vulnerabilities are a class of bug, I suspect PHP sites tend to be more buggy on the whole also.(I don't think that pointing at a few large sites and saying they managed to do it in PHP is any argument against this, by the way. It's a bit like saying that cigarettes don't cause cancer because your next door neighbour smoked and lived to be 100.)

posted date: 2008-12-21 16:07:00


Re: No PHP for large projects? Why not?#8
Facebook's frontend is written in php, if anything at all. I know that Myspace uses .NET but has ".cfm" links for legacy compatibility...

posted date: 2008-12-21 16:10:00


Re: No PHP for large projects? Why not?#9
I would like to upvote this answer twice.

posted date: 2008-12-21 16:15:00


Re: No PHP for large projects? Why not?#10
I really hate it when people say flat out that PHP is a terrible language because you can write code which mixes presentation with logic, or that it lets you allow SQL injection. That's nothing at all to do with the language, that's the developer.PHP has proved itself to be highly scalable: Wikipedia is one of the largest and most popular sites on the Internet and it runs PHP. Enough said?There are a lot of tools/libraries out there that give you a framework to work in, making it less likely that someone will write poor, less-maintainable code: see CakePHP, Symfony, PDO, Smarty, etc etc etc.It has received a bad rap because it's a language which has very low barriers to entry: it's free, you can get very cheap PHP hosting, the documentation is the best there is, there's plenty of tutorials online, plus it makes a lot of things very easy (eg: open a URL and get the contents of the file: file('http://www.google.com');). This means that a lot of newbies picked it up and made a lot of very dodgy sites with it, but that's going to happen with whatever language you choose as your first.Work with a solid ORM framework (there's about 30 questions on SO about which is best), and it will treat you good.

posted date: 2008-12-21 16:21:00


Re: No PHP for large projects? Why not?#11
Check out this similar question - http://www.momige.com/130869/can-php-handle-enterprise-level-sites-as-well-as-javaRecapping - Facebook, Wikipedia, Yahoo.com, Digg, Flickr and many other giant sites are running on PHP. If you ever come close to making something of that caliber, you can still rest assured you can get there with PHP.How maintainable, extendable, reliable, secure and performant your applications will be is entirely up to you and is language-agnostic. In favor of PHP though, it has very convenient tools for building web applications.

posted date: 2008-12-21 16:36:00


Re: No PHP for large projects? Why not?#12
how exactly does that example query make poor use of the query cache?

posted date: 2008-12-21 16:37:00


select page: « 1 2...»
Copyright ©2008-2017 www.momige.com, all rights reserved.