Scriptiing The Enterprise With Java And PHP 80
jontr writes "There are many benefits of using PHP together with Java. In an article about JSR 223, Dejan Bosanac looks at origin of each language and describes future benefits for PHP and Java developers."
Re:JSP/PHP Compare and Contrast (Score:4, Informative)
The truth is this:
Business Logic
Java - Good
PHP - Bad
Presentation Layer
Java - Even better
PHP - Good
I used to code in PHP all the time and loved it. But then I learned JSP and realized PHP is a waste of time...after I discovered JSP's tag libraries (both official and open-source ones), amazing amount of templating options, not to mention frameworks like Struts.
The guy who thinks PHP is good for the presentation layer simply hasn't really used anything else...he probably thinks Visual basic is great too.
PHP is cool, but it has so many missing features it's not even funny...and yes, it's SLOW. PHP functions that are built-in are fast (of course...they're written in C/C++), but if you write any of your own complex business logic it falls apart peformance-wise.
I had to write some XML processing in PHP and used the PHP XPath class from sf.net (since my ISP did not enable the built-in XML extensions). In most cases my pages timed out, PHP was not able to complete processing the XML file within 30 seconds (!). Java's JDOM did the same in 3-4 seconds.
but, back to JSP...they're great and make PHP look like a toy. Those who think otherwise have probably never written a real site in JSP. I've written them in both languages and I'm never coming back to PHP again...it's like going back from the full power of Unix to the clunky user-friendliness of Windows 3.11.
Re:JSP/PHP Compare and Contrast (Score:2, Informative)
There are implementations for both:
Re:PHP doesn't scale? (Score:2, Informative)
Yes ;-) and no. PHP provides a bit less control on choosing the appropriate trade-off between size and speed: an issue born with data structures and algorithms, much older than Java.
How is this scalable, say, to multiple computers?
Performance is a matter of software design and not of language or bytecode or whatever. It's like the "don't debug, verify correctness" principle of eXtreme Programming. Here it's: "don't optimize your code, design it to be fast and scalable".
On multiples computers, your design should also reflect the same principle: avoid reprocessing the same things again and again. The difference is only about granularity. Caesar's "divide and conquer" principle is very useful too.
You may specialize some machines on some subsets of data so each can have in memory the data they need most of the time, let each work on it, and finally merge all sub-results. That's how Google manage its huge index for instance.
You may also keep databases but use them through Active Objects [wustl.edu] to "decouple method execution from method invocation to enhance concurrency". I often use a LRU cache [ic.ac.uk] to address the issue of what should be kept in memory and what should not.
Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?
That's a very wide topic covering most of computer science: data structures and algorithms, design patterns, architectures of OS, ... /my-favorite-language/ Programming Bible ;-).
With some experience, I discover OOP and system programming are very similar. Programmers of both worlds often argue although they in fact agree: they simply don't use the same words for the same things!
I therefore suggest you have a look at Design patterns from Gamma and al., Pattern Languages of Program Design from Vlissides and al., read any good book about the architecture of modern OS (paper on I/O aspect [mindshare.com]), and for god sake keep off "The ultimate
IMHO, every programmer should know about design patterns, even if he doesn't consider ever practicing OOP, and about how wonderfully OS are designed, even if he doesn't consider ever leaving Java to write a device driver or an I/O library in C. /.
In addition to improving software around, it would also make a true miracle: terminate the weekly Biggest Di*k Contest about languages on
Re:PHP doesn't scale? (Score:2, Informative)
It is a myth that RDBMS *must* use disk. True, the current implementations were built around a disk-centric approach, but they are slowly evolving to make better use of more memory as the prices drop.
By the way, there seems to be a division forming between relational-centric shops and OO shops. PHP shops are probably more likely to use RDBMSs more extensively, while OO shops tend to kind of do database-like things in code. To me, that is too much hand reinvention of the database, plus does not give you the power of relational theory, but relational-vs-OO debates have already raged on slashdot.
Re:OOGG CONFUSED! (Score:2, Informative)
OOGG may be caveman, but can read API header comment, see what is internal or not. No need to crack OOGG head with private/protected club.