Slashdot Log In
PHP Usage in the Enterprise
Posted by
michael
on Sat Sep 20, 2003 12:42 AM
from the snorting-php dept.
from the snorting-php dept.
acostin writes "Some open survey results were published about PHP usage in the enterprise on the InterAKT site. An alternative survey on the PHP open source mouvement can be found on Zend site. See how we've evaluated the PHP market size($$$), what people think about PHP as an alternative to Java and .NET, and what should be done in order to have your large clients adopt open source solutions."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Hack-away (Score:3, Funny)
Re:Hack-away (Score:2)
Stupid bastards... they give it away.
Re:Hack-away (Score:5, Insightful)
I know that you're somewhat joking, but I would have liked the market share questions from InterAKT to have included not just .NET, J2EE, or ColdFusion, but have also included other languages like Perl and Python (although Python is indeed the base language for Zope). There are still a very large amount of websites built in Perl these days, with Slashdot being one of the most famous. Zend's survey does a bit more to explore the languages that programmers "are familiar with," but does little to see how the competition for PHP is doing.
PHP's great to use for me because it's simple, powerful, and readily available in cheap hosting environments. If Zope, ColdFusion, or J2EE had more availability or less cost, then I would try those as well, but there's something to be said for being able to sign up for a $9/month account and downloading Apache, PHP, and MySQL all without paying for anything other than bandwidth costs. You still can't really compare PHP to the enterprise level of .NET or JSP at this point though, since many features like persistent objects in shared memory really can't be done well in PHP, and I haven't heard anything else about PHP 5 other than further enhancements to the objects and reference systems. PHP-Accelerator gives a great boost to the speed, but I'd really like to see native compilation built into the distribution rather than downloaded separatedly.
All in all though, PHP's a great language for quick development of small to medium sized websites. As the old caveat reads though, use the right tool for the job.
Parent
Re:Hack-away (Score:3, Interesting)
As a PHP-developer who maintains a fairly large site and intranet I've come to both love and hate PHP. Love it for it's development speed and ease. Hate it for its lack of static analysis, I mean yes the language is dynamically type-checked but that doesn't mean the interpreter couldn't check whether some code calls undefined functions or defined functions with
php in a microsoft shop? (Score:5, Interesting)
What problems have people had in trying to migrate their applications to php, and how did you overcome them? How would you sell php to your boss? Bearing in mind most of our applications aren't simple database-driven (and I used that word hesitantly!) ones like Slashdot - hint: banking and insurance sector.
Re:php in a microsoft shop? (Score:2)
Perhaps a good point to start would be asking: why was ASP chosen in the first place? And how would PHP provide a better solution?
hint: banking and insurance sector
I wouldn't expect financial companies to jump on the latest and greatest, though. If they have something that already works, I imagine it would be hard to make them change. Then again, if you can save them money..
Re:php in a microsoft shop? (Score:2, Insightful)
If it saves you time that translates into money saved for him, as well as, more time for his work force to focus on other issues. If
Re:php in a microsoft shop? (Score:5, Interesting)
It's security record is horrible.
It's security model is a joke.
It's object model is worthless compared to real OOP languages.
It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.
It's developers regularly break POLA on minor version increments.
It's database support is mediocre at best: third party classes are currently the best (but not only) DB interface PHP has.
Stick with
Parent
J2EE is not slow (Score:4, Interesting)
I can understand why people think that Java is slow, taking that Java GUI widgets are usually slower than native widgets on the desktop. But J2EE is not inheritably slow.
Though there are clunkly J2EE apps out there, I'd wager on a hunch, that the average J2EE app would out-perform a same sized PHP app. If we add a PHP accelerator to the mix, like Turck MMCache [turcksoft.com], then PHP may have a fighting chance.
But remember, J2EE compiles the web application only *once* at startup, and can also ( and probably does ) optimize for the specific processor that it's running on. PHP, without an accelerator compiles on every hit, and PHP can't optimize for the specific processor unless you have a good sysadmin.
Parent
Re:J2EE is not slow (Score:3, Insightful)
I've used PHP without an accelerator in all "real projects" and never had any performance problems on the PHP-side. For web-applications the bottleneck is mostly the database so most "PHP is slow" vs "Java is slow" arguments are fairly pointless. The real issues are more often development speed and robustness. Of course if you're going to implement some nifty algorithms Java might be a better choice, b
Re:J2EE is not slow (Score:5, Informative)
Perl, baby.
I don't want to turn things religious, so here are concrete reasons why we use perl in almost all cases (we're a small development/business consulting firm):
- Rapid development
We can bang out the shell of a new web application in an afternoon, including (depending on what the app actually is) session handling, security model, shopping cart, workflow, revision history, etc. This includes the interface.
- Speed
mod_perl rocks. In the rare case when something is actually slow in perl, we either (depending on what's appropriate) write a database extension in a procedural language (if the issue is speed, usually C), or a perl XS extension. But this rarely happens.
- CPAN
The mistake I make the most when coding is rewriting something that is already on CPAN. Enough said.
- Text processing
I know of no other language that supports text processing more naturally than Perl. The way regexes are an inherent part of the language rather than a bolted-on extension makes me want to chew my arm off when I am using them in another language. And what is web programming, other than overglorified text processing?
- HTML::Mason
The nicest web application framework I've ever worked with. The development model and application flow is incredibly well thought out. The little "gotchas" wherein one has to do something strange are orders of magnitude fewer than every other framework I've worked with.
Downsides:
- Business doesn't afford Perl the same respect that it does Java.
True, to some extent. We do Java work as well, and have converted some customers to Perl when they approach large transitions, once they see the cost savings and the fact that there's no real downside. And small business is extremely receptive, especially to the cost factor.
- Many people don't like Perl.
Religious issue. Sure, it is possible to write unmaintainable perl. [insert I can do that in any language here.] My personal opinion, when looking at a lot of PHP out there, is that the slightly lower barrier to entry causes a lot of truly horrible PHP to be distributed - the ugly code factor is as easy to get in PHP as it is in Perl. And don't get me started on some of the JSP I've seen... I can't speak for other shops, but we keep a clean separation between library code and interface code, and come back to projects we did years ago when someone wants a change with little difficulty.
- Market share
Perl isn't the front runner. So what? It has a strong, vibrant and helpful community, there's plenty of documentation, and it sure as hell isn't dying. If other people don't get the faith, that's a market advantage for me...
- Doesn't enforce large development environment practices
Correct. It certainly does support them, but they are not enforced to the extent they are in other languages. For some, this is a downside. For me, this just means the language scales from a two minute script to save repetitive labor up through massive projects. If a coder can't follow architectural practices defined by the company, that's not the language's fault. And PHP certainly doesn't, either.
In any case, this rant went longer than I intended. I say, use whatever you like. Different minds work in different ways. Remember that paper (I forget who wrote it) about the huge market advantage web programming in Lisp gave his company?
Parent
Re:php in a microsoft shop? (Score:5, Insightful)
The PHBs here view php as something "geeky" that isn't suited for business. I'm sure they'd lap it up in a second if it were called MS Visual php Studio, however.
One thing you should keep in mind about programs from MS is that although they are crap, they offer someone you can speak to on the phone 24/7 as opposed to us geeks chopping things up or finding a forum, or jumping on irc to fix things up or create something. Microsoft is pretty and CTO's, CEO's, CFP's etc., need to be able to understand a product somewhat. I've used PHP for some time, and from my perspective is, there are too many hands in the pot spoiling the food.
Seems like every other month some new and improved programming language comes along and becomes the standard or some future standard. From a business point of view, I would rather go with what is established as opposed to what is promising. Promising isn't going to speak to a CTO through some task should his IT department walk out. Aside from that, standards already around are accompanied by people who get certified to perform these tasks. Now we know not all certs mean squat, but it's easier to find people who follow standards than those who follow promise.
Parent
You would think (Score:5, Funny)
that by the 23rd century they would have left PHP behind.
Or maybe it just shows the durability of opens source software.
Love PHP! (Score:5, Interesting)
One of the big reasons I chose PHP was the availability of "LAMP": Linux, Apache, MySQL, PHP. I know these technologies have been around for years and will be around for many more years, so it's an easy sell to management. There's plenty of talk on the newgroups if you ever get stuck and PHP's online documentation with user comments is priceless. I think more documentation should follow this example.
That aside, the pure performance and reliability of the above is excellent. These technologies were made to work together, and from what I hear the teams even collaborate to make sure their stuff stays working together. It really shows.
Years ago I worked on ASP/SQL Server solutions and where you had to go with native code for high-performance with ASP, I find that with PHP it is high performance on its own.
Great job to everyone who has helped put together these technology solutions. A shining example of the high quality that can come out of the collaborative efforts of many.
Re:Love PHP! (Score:2, Interesting)
ASP is commendable for its exposure of certain classes to all "ASP-bridged languages," making available such interfaces as those that handle state data (such as sessions),
I've used it in the Enterprise (Score:4, Insightful)
(P.S. Lots of programmers in the Enterprise. Data and me were always slapping together code for that clunky thing. Cloaked Romulans? Yeah right--just software bugs in the sensory system. "Uh, Captain, they've gone cloaked again." "Damn! Those ships have that capability!?!" Works every time.)
[? fire(phasers) ?] (Score:2)
Guess it could be worse. If the Enterprise used PERL, the show wouldn't make any sense to anyone except the people who made it... oh, wait. Isn't that how it is right now under B&B?
I'm so confused...
These surveys are lacking (Score:4, Insightful)
Of course, this is a cheap and easy way to conduct a survey (multiple-choice), but the results are almost meaningless if they can't be put into context. I would have preferred to have seen a hundred randomly-selected PHP developers interviewed, essay-style, about why they are using PHP, their thoughts on PHP versus other technologies, etc., and then have the results compiled into a journal-quality article supported by graphs and raw numbers. The important information isn't in those graphs; it cannot be enumerated and broken down into clean categories.
Personally, I develop PHP sites because it's the fastest and simplest way I've found yet to publish dynamic web content. I've tried making sites with Java and
Spoiler ahead! (Score:2)
The beautiful power of PHP never fails to impress me.
Entrepreneurs (Score:2, Funny)
huh? (Score:5, Insightful)
PHP is ok but... (Score:5, Insightful)
I have seen huge cumbersome application servers built around PHP that are a nightmare to maintain without having intimate familiarity with the code of the application server, such as Ampoliros or Ariadne, something which defeats the purpose of using such a large system in the first place. Such things really do work better with a OO by design language such as Java or ASP.Net (I assume, don't know
My guess is that PHP needs a better OO design (and no, PHP5 is not it, yet) and better seperation of logic and presentation for larger systems.
But for smaller stuff, well it's hard to beat in terms of price and speed.
AxKit, XML based sites even worse (Score:5, Interesting)
I want to believe in the XML's mission, but when I recently took up a migration of someone else's AxKit driven site, I haven't been able to get much sleep (it's 2:28am on a Friday night and I'm rebuilding a server to accomodate this goofy setup).
Parent
Re:PHP is ok but... (Score:2)
We trashed it, and started over with a Java-based webapp using Struts, and trust me, it is magnitudes better.
Smarty + PHP5 (Score:5, Informative)
This problem doesn't discriminate by language.
My guess is that PHP needs a better OO design (and no, PHP5 is not it, yet)
I think you could argue PHP5's OO design is good enough, or just as easily argue that it's not. I'm curious, though, what your main complaints wants with it are.
better seperation of logic and presentation for larger systems
I was looking for this for quite a while and then found Smarty [php.net]. At first, it seemed so simple that I disregarded it as being glorified search-and-replace templates. The temptation is to think "I can just do that by echo variables inline." But truth is, there's much more to it than that. After giving it a fair shake, I've discovered that it's an incredible useful, clever design. It's much more functional than it seems on the surface. It made PHP substantially more useful to me.
Between PHP5 and Smarty, I think there's a pretty good basic core toolset to work with. I actually think Java tries too hard in certain areas -- too many features, too much syntax, too heavy-handed typing system, too much complication. But no question it has its merits.
- Scott
Parent
Yahoo (Score:5, Informative)
I worked in a small shop, the web app isn't mission critical stuff like banking, but it wasn't "brainless dump data from Mysql". I was lucky that my boss was totally not picky about languages, as long as it gets the job done. But if I have anyone I work with that doubts the power and simplicity of PHP, Yahoo would be my example.
And so far, developing on the so called LAMP platform, I love PHP and would use it for any and all web development. It can be used as a quick hack (an argument always used against PHP btw, that it's only good for a quick hack and not for professional use), OR you can code it like a pro with objects et al. I was not impressed by Mysql however, it is by no means stable (this is v 4.0.13), but that's another topic.
My sig is my personal pet project using PHP
The real comparison is against Cold Fusion (Score:5, Insightful)
The last time I compared the two (admitedly a while ago) PHP had many more features and was the much better choice. (Even if they were priced the same, which they are not.)
Even more telling is the amount of books available for each. There are seven Cold Fusion books still in print according to Amazon. (Most the same book for different versions of Cold Fusion.) A search for PHP gets 112 hits. (I am not certain how many are still in print. Much more than seven.)
Comparing Java (a general purpose language) to PHP (a web scripting language) seems to be a bad comparison. Comparing it to
PHP in the Enterprise? (Score:2, Redundant)
Coolest language (Score:4, Informative)
why it will have trouble (Score:3, Insightful)
that being established, it will have trouble being accepted as an enterprise tool because it is not backed by a company. java backed by sun,
This discussion is like so 1999 (Score:5, Insightful)
If you are interested in the scripting language comparison, see Server-Side Scripting Shootout [lycos.com].
Backend for PHP webapp? (Score:4, Insightful)
SST & edrugtrader (nice combo, btw) (Score:5, Interesting)
When I joined the IT department at SST (a fabless chip manufacturer), they were 100% MS. I said I would be using PHP or they would be hiring someone else. They hired me, so I went hog-wild. I hired on the guy who built edrugtrader.com, the guy who built beerotopia, and one of the developers of Yube (which is/was a primarily Java shop). We've built up a massive intranet product in PHP. It's modular, with 196 files all interoperating nicely. Thanks to our Yube guy, it's object-oriented in the most-reused parts. It has areas for file management, posting news, creating new Web pages with a built-in GUI editor (thanks HTMLArea!), org charts, a task management system, a budgeting tool, employee evaluation systems, a signoff system with escalations & delegates, a form builder, and a lot more. On a day when we post earnings, the intranet can see just as much traffic as the public site. We've sustained over 100 requests/second in a few spots, and done just fine. I know that's not Yahoo-size numbers, but it's not "small" either, I don't think. If it is small, I know that edrugtrader sees many times more traffic and performs well. So no qualms there.
The problems we've had with PHP were small in number and quickly resolved. First, 4.3.2 had a bug that resulted in blank pages displaying intermittently to our users. That sucked, but 4.3.3 fixed it. And way back about 3 years ago as we started the site, we had to increase the memory allotment for just about everything -- we had some big processes with hundreds of queries getting read into PHP arrays, and we hit the default memory limits pretty quick. Other than that, no problems. Development is quick, often easy, usually fun. If we need to go OOP, that's fine. If we need to do simple templating, that's fine too. And increasingly, we're using it outside of the Web. We have a dozen cron jobs now that are all PHP scripts. Some things, especially screen scraping and working with mailboxes, still need to be done in Perl. But lots of server management stuff -- filesystem work, data dumps, monitoring -- seems to be going along fine with PHP nowadays. I'm pretty happy to have bet my career on PHP so far.
My experience (Score:3, Interesting)
1. It is more concise - java even _less_ compact than C++ with a good set of libraries - whereas PHP has loads of very forgiving high-level functions builtin.
2. It is more lightwight - java is just _still_ too bloated and slow even after all these years of promises from Sun.
3. The Java VM's for Linux really suck, they 'officially support' only RedHat and are unstable as hell running on Debian.
That said I really miss the J2EE ability to cache persistent data between requests in memory simply by declaring a variable as static. It's the only feature I miss in PHP.
As far as
PHP == Best pure SSI Technology ever. Period. (Score:3, Insightful)
After all these years I've had my perception of things confirmed day in and day out:
The best existing webapp technology ever concieved to this very day is the Zope Application Server together with it's intergrated Object-Relational Database, it's PL Python and the SSI solution TAL (Template Attribute Language). It will take _everything__else_ in the industry something like 5 years at least to catch up.
Apart from that, anything that strives to go the pure SSI approach with a separated DB eiher uses PHP or most certainly is crap. It's really that simple. I've evaluated CF (Nice dynamic flash with a poor mans PHP for 10000$. No thanks.) and ASP, finally moving into usable regions with
JSP is a nice substitute if you've got a Java Enviroment there allready. But then again, who would want one if you get allmost everthing (apart from maybe banking applications) ready or done faster in PHP.
Bottom Line: If you've got a standalone Server for your project, use Zope and all the goodies that come with it. On the other hand, if Apache is a must, mod_php is present and/or you need a finished OSS solution *now* you use PHP. PHP has the largest dev-community, and for good reasons too.
I really can't take CF or
Presentation on PHP Adoption (Score:4, Interesting)
Macromedia, IBM, Oracle, Sun, Apple, Symantec, Novell, Microsoft, MySQL
http://php.ist.unomaha.edu/presentations/second
I think the biggest news is that Oracle is putting the PHP module into their 9i Application Server.
Best part of PHP is the growing support code (Score:3, Insightful)
To me, the biggest strength of PHP going forward is the huge number of people that are improving the PHP experience every day.
1) New features? There are free extensions and modules for templating, database abstraction, compiled script caching, and more.
2) Sample code. I'll bet that there are more free as in speech snippets and full applications of code available for PHP that any other web language.
2) Community. There are lots of sites and other online resources where PHP developers can find help with debugging code when they need it.
Once you toss in great cross-platform support - PHP runs on just about any web server of interest - and a good price ($0), PHP is very competitive.
No, I wouldn't want a bank running on PHP, but for MANY other uses inside companies, PHP is good and getting better. I liken it somewhat to Linux a couple years ago with respect to corporate acceptance. The foundation is more or less built, what's left is some time to mature and gain credibility.
I'm still slightly annoyed... (Score:3, Interesting)
...that so many people assume PHP is "only for web pages". The entire first report linked above seems predicated on the notion that "PHP is for companies to make money setting up websites for other people, and other uses are 'fringe' or irrelevant."
PHP is definitely good for web-pages, but I've increasingly found it to be very useful for a lot of command-line programs and system administration, much as Perl is.
PHP-GTK has also already been mentioned in other postings, and the increasing interoperability with Java means you can implement a variety of parts of your PHP projects in "native Java" if you want to...and that's not just "Java for web pages" code, either.
Re:On the Enterprise? (Score:2)
I don't get it. Are you saying that the Enterprise was Slashdotted?
Re:The code is the data! (Score:5, Insightful)
To write clean, well structured PHP, you really need to do some good design, use OOP, seperate content/formatting/logic/etc, and basically at that point, you're left with a half-ass OOP implementation, annoying pass by value, messy syntax, no exception handling, etc.
PHP was meant for making relatively minor webpage hacks, and it shows. This still remains PHP's strong point; building enterprise applications (that are designed well) does NOT.
Here's my list of bitches about PHP:
* No class attributes, only instance attributes
* No namespaces (and they were dropped from PHP 5). include()/require()'ing a file just dumps its namespace into the big happy global namespace, and it's a freaking nightmare.
* OOP sucks. You have to litter &'s everywhere to get references, and lots of other problems that I'll refrain from typing out. Ok here's one -- how do you pass an instance method for use as a callback? Something like array($object, "method_name_in_a_string"). Good god.
* No exception handling. Want to "handle" an error? Toss a @ in front of it, then you'll never see it. How helpful.
* Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.
And that's the root of the whole issue, I think. Things that bend over backwards to cater to newbies end up doing a shitty job for people who have a clue.
Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them. I looked at a tiny bit of PHPMyAdmin's code just for kicks and was horrified. But that's not a valid judgement by any means. Again, I'm just interested to see if there are any out there (and have a look at them).
And a last thing, I might be biased by knowing Python (but I knew PHP first!). Python tends to flow very naturally for me, and even big complex things just end up being big and complex, instead of big and complex and A COMPLETE FREAKING NIGHTMARE like big things in PHP tend to wind up (for me).
Go Python! Death to PHP!
Parent
Re:The code is the data! (Score:4, Informative)
No class attributes, only instance attributes
Not a big deal. Just constants or globals that are prefixed with the class name (seriously, it works fine in practice).
No namespaces (and they were dropped from PHP 5).
See above.
OOP sucks.
Yes, parts of PHP do stink, I'd love to never see a "&" again, though I think I've mostly figured it out. Also inheritance and constructors is a bit ugly. That will be fixed in PHP5.
No exception handling.
This is a big problem. Actually the only "real" problem on your list, imo. What I usually do is just die() right then and there.
Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.
I actually like the way it converts strings and numbers. Just be sure not to test them as booleans and you won't run into too many problems. Since your data is usually coming from outside, you better have pages of disgusting checks to begin with!
Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them.
PEAR (pear.php.net) is a nice library for PHP. I enjoyed looking through the source code for inspiration. Sure, it's not Python (or Ruby, my fav) but it's readable and uses good practices for php.
Also, there is a site with patterns in PHP, google for it.
Also also, there is PHPUnit framework for unit testing. Not exactly JUnit (no exception handling!!) but I have been using it with "test-first" development, and churning out very nice PHP code.
I used to hate PHP because of the lax security, but I think it has a lot of potential as a "lite" language that can handle big projects. My boss loves it because he understands it, I like it because of the objects.
Parent
Re:The code is the data! (Score:5, Interesting)
I'm not saying this is some ultimate solution, I've also missed exceptions badly, but if the application needs exception handling only in a few places it's quite simple to simulate them:
Far from beautiful, but you know a lot of "enterprise applications" have been written in COBOL, Fortran or C which none of them has exception handling AFAIK (if gotos don't count).
Parent
Re:The code is the data! (Score:3, Insightful)
I don't think that they're required, look at perl & C.
PHP definitely has some issues.
* By the time you're done coding it right, it's as long as similar C code
* Exceptions are a very nice way to handle things properly and concisely, and die() is certainly not a solution.
* Not easy to contrain variables to a type (type contraints are essential for any good database, why not for a language?), i.e. you can't cast a variable without doing someth
Re:The code is the data! (Score:4, Insightful)
It's like a lot of things: not bad, but grossly misused. Flash is not a bad technology. PDFs are not a bad technology. Javascript is not a bad technology. The problem is that people use them for all kinds of stuff that they shouldn't, and it winds up working like crap and annoying people.
Parent
Re:The code is the data! (Score:5, Interesting)
Parent
The code is the data in FP, not in PHP (Score:3, Interesting)
IN FP languages, like Lisp, the code is the data: there is very well defined reflection, I can construct new functions and manipulate existing ones as they are first class objects. Same/similar situation is in ML and Haskell.
Well, among traditionally imperative programming languages there are more a
Re:The code is the data! (Score:5, Insightful)
IMHO the good parts about PHP are also the bad parts. ie, * you don't have to say what type a variable is, but that means you can't specify a type of parameter to a function. * you don't have to specify scope, but then you can't protect functions that should be private etc.
I looked at a lot of Java code for ideas on what I could do with PHP to clean it up . The main things that I did were: set up a 3 or 4 tier architecture.
- database abstraction layer
- business layer
- presentation layer (preferably using templates)
(I modeled a lot of this on Enhydra - www.enhydra.org)never use globals. Wrap up the HTTP_GET_VARS, HTTP_POST_VARS etc in a class (ie Request). Create classes to wrap the server vars and whatever else.
Use classes for everything. This gives you a reasonable amount of namespace control.
Never access variables directly in classes. Create accessor methods for them.
I think that if you are feeling the need to structure your PHP, you will probably need to move towards Java or some other more structured language. It can definitely be more challenging to write, but as your applications get bigger, the compiler-enforced type checking, programatticaly enforced/supported interfaces etc will save you a lot of time in the long run.
Parent
Re:heh (Score:4, Interesting)
Parent
Re:Apples to Oranges (Score:3, Insightful)
I don't see why not. They are both technologies designed to provide dynamic content via the web. Just because they require different methodologies, doesn't mean they are incomparable.
PHP is not a true object-oriented programming environment.
Where I work, we favor Microsoft technologies. I use ASP.NET and I love using it. But the object-oriented stuff gets in my way more than it helps me. OO is not the best paradigm for web development. HTTP is a stateless pro
Re:PHP on the Enterprise? (Score:3, Funny)