Page 1 of 2
PHP vs. ...
Posted: Sun May 06, 2007 10:56 pm
by Theory?
So I've recently started an internship at an internet startup. They've built their back-end on the enterprise level from the start because they expect an enterprise level user-load right off the bat. The project is very media heavy and handles lots of transcoding and streaming media, so they've opted to go with Java EE, JBoss, and some enterprise level Ajaxian technology whose name I can't remember for the life of me.
I understand that PHP is a scripting language and always will be, but it certainly has large-scale potential, I'm just not 100% clear on the extent of it's potential.
Could someone sum up what PHP can't do?
Posted: Sun May 06, 2007 11:30 pm
by feyd
- Most PHP doesn't quite scale in the most efficient of ways.
- There is no shared memory (without special help from extensions) across different user sessions.
- Unless caching is used PHP has to completely parse a script each time it's requested.
Posted: Sun May 06, 2007 11:43 pm
by Theory?
Also, are there ways to integrate both to co-exist properly and peacefully in the same system? I figure there must be some things worth doing in PHP as part of a Java-based application?
Posted: Mon May 07, 2007 3:41 pm
by sasquatch
Posted: Mon May 07, 2007 4:33 pm
by timvw
If you're in a Java environment i don't see why you would want to fall back to php? Everything i've seen in PHP can be done with JSP too... I still have to see the php counterpart for JSF though...
You can invoke java code from within php, and these days you can also run php in your webcontainer (have a look at resin (caucho.com))...
Posted: Mon May 07, 2007 4:58 pm
by Theory?
timvw wrote:If you're in a Java environment i don't see why you would want to fall back to php? Everything i've seen in PHP can be done with JSP too... I still have to see the php counterpart for JSF though...
You can invoke java code from within php, and these days you can also run php in your webcontainer (have a look at resin (caucho.com))...
Well what about just different apps within the same service? I'm going to have things like blogs, forums, private messaging, things like that. It seems like it would be easier to code those in PHP, right? I don't think my Java apps would need to talk to the physical programs, so long as they all access the same databases. Would using PHP in that context be sound? Or would be it a smarter idea to just do the whole thing in one language so if they need to talk sometime down the road, it's all the same stuff?
Did that make ANY sense? I'm really sorry, I do that some times.
Posted: Tue May 08, 2007 12:48 am
by timvw
Theory? wrote:
Well what about just different apps within the same service? I'm going to have things like blogs, forums, private messaging, things like that.
Having two different languages, platforms comes with the cost that you need people that are skilled in php and you need people that are skilled in java..
Theory? wrote:
It seems like it would be easier to code those in PHP, right?
Why does it seems so? Because you are more familiar with it? Generating a bit of html while talking with a database is well supported in *any* environment targetting the web...
Theory? wrote:
I don't think my Java apps would need to talk to the physical programs, so long as they all access the same databases. Would using PHP in that context be sound? Or would be it a smarter idea to just do the whole thing in one language so if they need to talk sometime down the road, it's all the same stuff?
The cost of having codebases in two different languages also means that it's a lot harder to reuse parts.. Now you're going to write data access code in php and in java.. Whereas you could have reused the dac if all was in php (or java).
Posted: Tue May 08, 2007 1:39 am
by stereofrog
timvw wrote:Theory? wrote:
Well what about just different apps within the same service? I'm going to have things like blogs, forums, private messaging, things like that.
Having two different languages, platforms comes with the cost that you need people that are skilled in php and you need people that are skilled in java..
Yes, but the former is far cheaper and easier to find.

Posted: Tue May 08, 2007 4:33 am
by Jenk
Just choose a different language and/or platform like Ruby on Rails or Smalltalk/Seaside which will handle everything you ask of easily, instead of meddling with two (or more) languages/platforms talking to each other.

Posted: Tue May 08, 2007 8:24 am
by Theory?
Jenk wrote:Just choose a different language and/or platform like Ruby on Rails or Smalltalk/Seaside which will handle everything you ask of easily, instead of meddling with two (or more) languages/platforms talking to each other.

Ruby seems to be missing a few of the things I need, like persistence and the ability to handle large media streams over multiple connections.
Perhaps I'm wrong though, that's just my understanding.
From what I've been told, for the largest app in my system, my best bet is either Java or C# and since I have no interest in C# for a number of reasons, it looks like I'm stuck with Java.
I just like PHP, so I was wondering if it would serve me any purpose within the constraints of this app.
Posted: Tue May 08, 2007 8:55 am
by Jenk
Smalltalk/Seaside is very good, if it were not for the not-so-abundant hosting I'd drop php in a flash for it.
Handles persistent data flawlessly and the SqueakVM IDE is second to none.
Posted: Tue May 08, 2007 8:03 pm
by Ambush Commander
I've always been meaning to learn smalltalk, but never got my head around the paradigm (nor how to code anything with the Squeak UI >_<)
Posted: Tue May 08, 2007 9:16 pm
by Theory?
Jenk wrote:Smalltalk/Seaside is very good, if it were not for the not-so-abundant hosting I'd drop php in a flash for it.
Handles persistent data flawlessly and the SqueakVM IDE is second to none.
Just from me looking around the internet, it would appear that Java and C# are both based on Smalltalk. That, and it doesn't seem like Smalltalk is actively developed anymore.
I'm getting confused by lots of things. I'm assuming that for super-high-level data streams, such as simultaneous large format data transfers, media streams, etc. my options are Java EE or C#, and since I have no intention of learning C#, that leaves me with Java.
Am I correct in this assumption?
This is probably the FIRST question I should have asked.
Posted: Tue May 08, 2007 10:33 pm
by Kieran Huggins
in my experience, PHP is the way to go unless you're dealing with a module that requires either shared memory of HEAVY lifting... in which case, write that module in C and compile it for the system. PHP can still do what it does best while outsourcing the specialized functions to a pre-compiled C library. Come to think of it, PECL is exactly that... maybe you should look into writing your own PECL?
Posted: Wed May 09, 2007 3:39 am
by Jenk
Theory? wrote:Jenk wrote:Smalltalk/Seaside is very good, if it were not for the not-so-abundant hosting I'd drop php in a flash for it.
Handles persistent data flawlessly and the SqueakVM IDE is second to none.
Just from me looking around the internet, it would appear that Java and C# are both based on Smalltalk. That, and it doesn't seem like Smalltalk is actively developed anymore.
I'm getting confused by lots of things. I'm assuming that for super-high-level data streams, such as simultaneous large format data transfers, media streams, etc. my options are Java EE or C#, and since I have no intention of learning C#, that leaves me with Java.
Am I correct in this assumption?
This is probably the FIRST question I should have asked.
Smalltalk is still actively developed, Squeak is an open source implementation of Smalltalk-80; which is receiving updates quite frequently. There is also VisualWorks, which is a proprietary implementation of Smalltalk-110 iirc (may also be Smalltalk-80) by Cincom.com.
I like squeak because it is open source, and not only is it open source, it is a system developed in it's own language (apart from a few core C libraries needed to get the ball rolling) so you are free to update just about anything you like about it. There's no compilation, no messy runtime library management, it's all there in one Image file; ready to go.
