PHP Scales As Well As Java

mactari writes "Jack Herrington at the O'Reilly Network has had the audacity to claim that both PHP and J2EE architecture... are converging on the same design [regarding scalability]. Can it be that he's disproven the idea that 'Java scales and scripting languages don't' when he says, 'The idea that PHP does not scale is clearly false at the performance level'? Even if a little oversimplified (ignores horizontal scaling), it's an interesting comparison that takes a peek at the architecture beneath both hypes."

Comments

What's the PHP equivalent to Java NIO?

[Anonymous Coward]

And the other recent additions that add to the scalability of Java?

Re:What's the PHP equivalent to Java NIO?

[bigjocker]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.

PHP is perfect for small projects, but when you have huge requerements and a ton of lines to mantain, that's when the real scalability shows off. You can build a 1,000,000+ lines project in PHP and run it on a distrubuted server and whatnot. But who the hell is going to mantain it??

Re:What's the PHP equivalent to Java NIO?

[Waffle Iron]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.

Maybe with dynamic typing, that would only be a 30,000 line project.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

You can't do it without strict typing? At work, I have a 200,000+ line application we're running that has been in production for a year and a half, and is constantly being developed, adding new features and integrating it with other business systems. The API and the UI layers are written with Perl.

"strict typing" is not some magical feature that will allow crappy developers to manage a large code base. Languages with strict typing, and languages with weak typing, each have their strengths and their weaknesses, and those need to be understood and managed. Nothing is a magic bullet.

Re:What's the PHP equivalent to Java NIO?

[TekZen]

I am the sole developer of just such a project.
I have just hired a second developer. So we solidly fall under the 1-2 developers. We have about 100,000 lines of PHP code (+/- a few thousand).

What's more is that we have been scaling this app not only to handle heavier load over more distributed systems, but doing it really fast under the gun.

Emma.

- jackson (a php developer in Nashville)

Re:What's the PHP equivalent to Java NIO?

[FiggyBottom]

Just a note: PHP is not a weak typed language, it is a dynamic typed language. It doesn't ignore the types, it converts them. Which is sometimes useful to look at an object as an array.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

I'm doing that right now. My application is hardly small and it manages a database of 20GB(and growing). In fact, what's nice is PHP is small enough of a foot print for system caching to do what is is supposed to vs Java bloat.

OH, and BTW, try finding fixes to real bugs in the JRun environments. We had Macromedia send in an expert who was clueless. They didn't help and the app still has performance problems where JRun falls over. nice

Re:What's the PHP equivalent to Java NIO?

[Frymaster]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers.

find . -name "*.p" -o -name "*.htmp" -o -name "*.html" -o -name "*.php" | xargs wc -l
91564 total

current staff: two php developers. two flash developers.

close enough?

(nb: .p and .htmp are php pages... it's a legacy requirement.)

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

pet peeve: your designers only need to use the "registered trademark" symbol ONCE on the first appearence of your mark.

When you say "Emma(R)" all over the place, it reminds me of anal retentive children who write their names on all their possessions or something.

Just a little pet peeve of mine, along with credit card fields that 1) don't allow more than 16 chars (can't edit by inserting, then deleting) and 2) don't allow spaces or dashes, as if computers are incapable of filtering them out.

Thank you, have a nice day. :-)

Re:What's the PHP equivalent to Java NIO?

[kix]

You would like to see it? ok, fine. loot at sites like

www.ut.ee
www.hitechestonia.com

I won't plug the application here, but right now it has
188092 lines 489080 words 5012353 bytes of *php code* and I don't mean with html mixed in, that's all in templates. about 320 classes total.

and it was written by 2 guys over 3.5 years. and it is being mantained and actively developed. with 2 guys. I'm one of them, so I would know.

Language has nothing to do with mantainability. Architecture does.

Re:What's the PHP equivalent to Java NIO?

[frodo from middle ea]

The scalability and maintainability of a project ove r a period of time most importantly depends on the quality of code and documentation within code (Comments).

I have seen so much java code, so badly written that the developer who wrote it 6 months ago, was also hesitant to touch it.

While on the other hand, I have seen hugh shell scripts being maintained over a period of 10 years.

If the code to be maintained is poorly written and ill documented , then no matter wheather you use strict type checking or not, it will be a nightmare to maintain.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

Not really, if you didn't write the entire project, after the first few bugs you WILL get paranoid and start to cast everything in sight. Been there, done that.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers.

Well, if it were in PHP it wouldn't need to be 100,000 lines. It would be more like 5,000. *smirk*

Re:What's the PHP equivalent to Java NIO?

[Qzukk]

We do this quite well here. We survive by naming variables in a way that makes sense "$first_name" and using common sense "gee $first_name must be a string" and by using functions we wrote to "protect" the database backend from accidentially inserting a string in place of a number "makeNumeric($zipcode)" (which, what do you know, protects us from sql insertion attacks as well as clearing up whether that should be "55555-5555" or "555555555". And yes, our software is limited to the US by design).

We have two developers. Progress may not be as snappy as my boss would like, but it beats struggling with the various servers trying to get them to all fit together and work together and run continuously to get j2ee or whatever the latest java-as-a-CGI buzzword is these days.

Re:What's the PHP equivalent to Java NIO?

[aled]

No. You still have less than 100.000 and you are counting html files.

Re:What's the PHP equivalent to Java NIO?

[Anthony Boyd]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers.

At SST, our intranet is now about 250,000 lines of PHP code. It has budgeting tools, dynamic org charts, a tasking system with delegates and escalations, a signoff/CMS-lite tool, an automated form-building wizard with db backend that has been used to kill off about 300 paper-based forms, and a few other goodies. At any given time during the workday, there are about 100 simultaneous users logged in and accessing data. We have 3 developers to maintain it. One of our developers has a Java background, and has revised the most frequently-reused code to be more object-oriented, but 90% of our site still uses function calls. So far, everything has been fine. It has been in use since January or February of 2001.

Re:What's the PHP equivalent to Java NIO?

[Ender Ryan]

Yup, can you say, "Duh!" I can't believe I still hear this bullshit about strict typing all the time like it's some kind of fuckin' magic bullet that makes everything maintainable. What a load of shit, there are so many more design decisions that affect the maintainability of a project than whether the language is strictly typed of not.

Does strict typing help? Sure, it can, but it's not going to make or break the maintainability of a project.

I write code that's just as shitty and unmaintainable in C/C++ and Java as my Perl code. I have also, on occasion and when necessary, written Perl code that is elegant and maintainable.

Re:What's the PHP equivalent to Java NIO?

[aurumaeus]

Maybe with dynamic typing, it wouldn't work. Strict typing is only part of the equation, but the issue at stake is reliable and predictable interfaces, particularly to complex functionality, and that's what separates enterprise languages from scripting languages.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

How do you handle encoding issues? Aren't all characters in PHP 8 bits? What about internationalization? Japanese for example?

Re:What's the PHP equivalent to Java NIO?

[SunBug]

I just ran the same thing on the website and got:

89970 total

I've actually been reducing code size recently. I'm sure we were over 95k at one point.

And then I ran the same thing on my intranet and got:

8679 total

for a grand total of 98,649 loc.

I was the sole developer for about a year, and we now have two developers. The project is about 5 years old.

The database is about 7gb if you include all of the archived data. We have about 5000 logins per day (you have to login to use the system), and serve up 10 000 000 hits/month; 3 600 000 pages/month; 120gb/month.

The site is running on a Dell 2450 running two 733mhz PIIIs with 768mb of ram. The database is a 2650 with dual 2.2 Xenons and 2gb of ram.

CPU usage never goes above 60% on either server. The key to PHP speed is to use an accelerator, we use phpa. That in itself was worth about 2x increase in performance.

PHP works great for us.

Re:What's the PHP equivalent to Java NIO?

[stanmann]

Well, Regardless of typing issues shouldn't your coding convention distinguish strings from numbers...

And flame me if you must, but Microsoft's hungarian notation is fairly good at that.

Re:What's the PHP equivalent to Java NIO?

[TheTomcat]

Just did a WC on our PHP modules: 103510 lines.

It's being maintained by 2 guys. (including new development). Yes, this is hearsay, but I can't really talk details.

S

Re:What's the PHP equivalent to Java NIO?

[mvonballmo]

When I read your comment, I thought I would quickly download a SLOC counter and write back that I had such an application. Sadly, I cannot do that. Over the last couple of years, I've slowly built a library in PHP to drive my web-site. It is almost exclusively composed of classes and follows OO typing rules in a fairly disciplined way.

I thought it was a big library, but it's only 22,000 lines of code. The change request/bug tracker I built on top of the core library can only add a paltry 10,000 more.

That's not even close to 100,000 lines, but perhaps that's also because I get a *lot* of re-use out of my class hierarchy.

Check it out at earthli Webcore if you're interested ... it's GPLd. The documentation was generated with PHPDoc.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

What exactly is an "enterprise language"?

Re:What's the PHP equivalent to Java NIO?

[Sh0t]

Which matters not at all.
I can name my php scripts goat.farm if I so desire.
The parser will prase any extension you tell it to.

Re:What's the PHP equivalent to Java NIO?

[amithv]

While its not 1 or 2 developers, the Horde Project has a group of 4 core developers (who I see regularly contribute) and on my Horde installation there are 163k lines of php code. And that does not include the static HTML which has been split into .inc files. And I dont' even have all the applications installed so this number is more like 200k (or more)

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

I'm the webmaster for sheriff.org. It's just me and no one else coding this site and adding applications to it every single month. It consists of 433 cfm templates, and 9.4 mb of text (you do the math to figure out how many lines that is) and growing. The whole site is done in ColdFusion. I think it is safe to say that it can be done.

Re:What's the PHP equivalent to Java NIO?

[mcrbids]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.

I think the point of a scripting language like PHP is that you don't need as many lines to get the same amount done.

I see PHP operating an average of perhaps 2-5 times as dense as similar C code, meaning you just don't have to write as much to get the same amount done.

As the sole developer of a report generator targeting schools in California, I count (at present) a total of 35,883 lines of code. (Thanks wc!) Interesting enough is the actual breakdown of the code:

1. 4,637 lines for the website and related administration tools.
   
2. 6,073 lines for the server side data accumulation system. (not web-based)
   
3. 25,173 lines for the PHP-GTK client application and GUI.
   

In production for now just under 2 months, (since the beginning of this school year) we're tracking just short of 4,000 students, and anticipate this at least doubling and probably tripling or more by the end of the school year.

All this without quitting my day-job.

From where I sit, PHP scales pretty nicely.

Re:What's the PHP equivalent to Java NIO?

[flibuste]

Counting lines or number of files sounds pretty useless to me when comparing languages.... A BAD developer will write 10 times the needed code for one feature where a GOOD developer will make sure inflation doesn't happen. A GOOD Java developer will easily create thousands of files with 2 lines of code. A BAD Java developer will write 1 class with 2000 lines of code. A BAD Ada programmer will create LOTS of files with LOTS of lines. A GOOD Ada programmer has no choice but to create LOTS of files with LOTS of lines anyway. (ADA's so verbosic...) So, see? This java vs Php number of lines debate is pointless...

Re:What's the PHP equivalent to Java NIO?

[IA-Outdoors]

The notion that PHP can't be used in a large project is absolutely ridiculous. Having written some large PHP applications I can attest to that. "Huge requirements"? That's awfully vague. I have a PHP application will over 1500 detail requirements, all of which have been met, all of which were implemented using a PHP MVC implementation all of which are manageable and most of which are easily regression tested. This argument is too much an all or nothing debate. Java does have some scaling advantages over PHP (compiled code, threading and EJB's to name the biggies). Java also, typcially, has a more more significant price tag, higher ramp-up for developers and requires sometimes expensive application server administrators. So, while scaling is the main topic we are on, cost should also be a factor. How much are you willing to pay for your scalability? Being a manager of Java developers and a long time PHP coder I can tell you there is a large middle ground as to when you can use PHP or Java. The question will always be can you make the right decision for the right reasons.

Re:What's the PHP equivalent to Java NIO?

[platypus]

Yup, can you say, "Duh!" I can't believe I still hear this bullshit about strict typing all the time like it's some kind of fuckin' magic bullet that makes everything maintainable.

Especially if the people touting it are in reality talking about static typing (and not strong, or strict, as you call it).

Re:What's the PHP equivalent to Java NIO?

[Bishop923]

With all of the replies on the thread about strict -vs- loose typing, I'd like to point out that PHP 5 will begin to solve the major problem that makes strict typing so darn useful: Making sure you are passing the right type of data around.

PHP 5 will provide optional "type hinting" for objects, so you can do something like

function Bar(Foo $obj)

and the parser will check to make sure that when you pass an object to baz, it must be of type Foo or derived from Foo. If not, you get a parse error. Doesn't work yet for the base types, but it may come in a future version.

Re:What's the PHP equivalent to Java NIO?

[domninus.DDR]

How do you ensure your program is not used for spam?

Re:What's the PHP equivalent to Java NIO?

[TekZen]

Our sales and support develops a personal relationship with each of our clients. That, and I keep a very close watch on things. A few have slipped out, but the consequences are swift and fierce. -Jackson

Re:What's the PHP equivalent to Java NIO?

[penguin7of9]

PHP has shared memory and similar features built in. Also, running as part of Apache, the primary use for NIO in a web server (dealing with lots of connections) is already taken care of in Apache anyway.

Think about it: PHP is used extensively in web programming, that's the only thing it's used for, and it's easy to add native code; it is going to have everything people need for writing efficient web apps.

Re:What's the PHP equivalent to Java NIO?

[SunBug]

You are absolutely correct. I break up my day into 3 pieces:

1. Cleaning up/refactoring code. This includes removing redundant/inefficient code and moving our site towards XHTML 1.0 transitional compliance. Most of the code base is HTML 4.0, and very table-oriented. Like I said in my last post, I've probably weeded out some 5 000 loc over the past year or so. I know there is at least 10 000 loc that can be removed, given enough time.

2. Bug fixes. Because the site is fairly mature, this is usually the least of my worries. Right now, I only have about 4 open bugs. On a bad day, I'll get 4-5 bug reports for very minor things that are fixed within minutes.

3. Adding features. This, of course, takes up most of my day.

The question was whether or not PHP could be managed when it approaches 100 000 loc. I posted that it could. It's manageable even though there are hacks and there is some pretty nasty spaghetti code.

Good vs Bad programming kinda takes a backseat to Just Getting Things Done when you are under pressure and behind schedule.

Re:What's the PHP equivalent to Java NIO?

[tkwoof]

But who the hell is going to mantain it??
I do..
To quote Yoda "Control, You must learn Control..
Any language can give rise to large, unmanageable projects. If you discipline yourself, and your co-developers, you can keep it all in check. If you are so sure that 1,000,000+ lines of code will be exceedingly difficult to maintine, you can always create a code management system ;->. I did. Point being, size doesn't matter.... At least that's what I was told.

Re:What's the PHP equivalent to Java NIO?

[jrumney]

It's unreadable shite. Why add useless crap to a variable name when your compiler and editor are perfectly capable of preventing type errors.

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

But how much of your "code" is actually non-executable HTML? Those parts don't really count, as the worst that can happen with them is that they won't look right.

Re:What's the PHP equivalent to Java NIO?

[Qzukk]

Like I said before, the software is strictly US-centric. If I even thought that some other country might be able to use the software I'd either require input to be provided in UTF-8 (which, with the exception of string manipulation (ie, substr(), str_replace(), word wrapping, etc. is handled quite well, assuming the input is valid, the output will always be valid.) or not use PHP.

We actually used PHP for the purpose of rapid development and user-interface prototyping, and ran afoul of the #1 Stupid Project Mistake: Never show your boss a project that appears to work if you intend to rewrite it completely. "Why re-write it? It works just fine like it is". Our final goal was to have everything converted over to perl once the UI was stable enough (nice thing about PHP is that the person doing web development can load it up in a web-editor and edit the webpage without knowing or messing with the PHP. Try that with perl.)

Re:What's the PHP equivalent to Java NIO?

[spektr]

Cheyenne: It's being maintained by 2 guys. This surprises you?

Harmonica: Yeah.

[silence]

Harmonica: You know PHP.
Harmonica: And you can count.
Harmonica: Up to two.

Cheyenne: [looking at his tty] Up to 103510 if I have to.
Cheyenne: [looking at Harmonica's project schedule] And faster than you!

[Harmonica smiles and applies Extract Method]

Cheyenne: Yeah go on. Refactor, Harmonica. Refactor, so you can't bullshit.
Cheyenne: Only watch those false types.

Harmonica: int x = new Double(42); Like so?

Cheyenne: [shrugs, nods and leaves]

Re:What's the PHP equivalent to Java NIO?

[Anonymous Coward]

Why add useless crap to a variable name when your compiler and editor are perfectly capable of preventing type errors.

and just keep guessing until the compiler stops flagging it up?

Re:What's the PHP equivalent to Java NIO?

[harikiri]

What does strict typing have to do with maintenance of a large body of code?

Re:What's the PHP equivalent to Java NIO?

[th4tGuy()]

I'm not a microsoft apologist, but hungarian notation helps prevents stupid programmer mistakes... eliminating the need for the compiler to tell the programmer they made a stupid mistake. This reduces the need for the compile - fix - compile fix again cycle.
Most professional programmers (worth their weight) will tell you that a longer more descriptive name will save you lots of time, and the time of the programmers who have to maintain your code after you're fired for making stupid coding mistakes and delivering behind schedule trying to fix those stupid mistakes.
I use hungarian notation in all of my sql, java, and c++ code... And it helps!

Re:What's the PHP equivalent to Java NIO?

[jrumney]

I'm sorry, but hungarian notation does not prevent stupid programmer mistakes. Typos creep in regardless of any conventions you use, the only thing that can catch them before the compile cycle is on the fly spell checking, which is rendered useless by hungarian notation. And as for type info, modern editors are perfectly capable of giving you the information without silly prefixes on every variable.

Re:What's the PHP equivalent to Java NIO?

[lahi]

A GOOD Java developer will easily create thousands of files with 2 lines of code

With common indentation, that would amount to thousands of empty classes of the form:

class X {
}

(Count'em, two lines.)

Which is why comparisons between Java and Perl (and probably Php, as discussed here) should factor out the boilerplate ratio, which, in the trivial worst case is:

import java.io.*;

class Hello {
public static void main(string args[]) {
System.out.println("Hello, World");
}
}

compared to:
print "Hello, World\n";

ie. a 7:1 ratio. Let's reduce that arbitrarily to 4:1 for non-worst, non-trivial. If that's the right ratio, a 100K line Java app compares to a 25K line Perl app.

-Lasse

Scaling

[stanmann]

Java and PHP Scale equally well... Well that isn't a big surprise since Java as I understand it doesn't scale very well..

Re:Scaling

[Frymaster]

Java and PHP Scale equally well.

as a corollory, it is much easier in php to write code that itself does not scale well. contrary to popular belief, php is not a language for sloppy or new programmers - to write a robust, secure, scalable app in it you have to know what you are doing!

Re:Scaling

[letxa2000]

to write a robust, secure, scalable app in it you have to know what you are doing!

That's the case in any language, not just PHP.

Re:Scaling

[Anonymous Coward]

Java as I understand it doesn't scale very well

So either Java, a technology used in production applications by enterprises of all sizes the world over, doesn't scale, or your understanding is flawed. Let's guess which.

Re:Scaling

[Anonymous Coward]

Java and PHP Scale equally well... Well that isn't a big surprise since Java as I understand it doesn't scale very well..

I think a better subject to study would be how the languages scale (as I'm sure there are plenty of scalability articles already). Java scales well as a language, but I really only know basic PHP. An in depth discussion on how the language scales to complex requirements and applications would be great. Can PHP be utilized to create robust backends? How hard is this process? How consise is the code to do this? Scaling in terms of being able to compute is important, but scaling in tems of being able to write the computation is just as important.

Re:Scaling

[Anonymous Coward]

The two are not mutually exclusive.

Re:Scaling

[drauh]

to write a robust, secure, scalable app in it you have to know what you are doing!

Is that not true for all languages?

Re:Scaling

[Anonymous Coward]

Yes, and those of us in enterprise environments who have to deal with java cringe every time it breaks. Java is a shit lanaguage that Sun's convinced universities to push on students. Surprisingly, they've successfully brainwashed many individuals.

Re:Scaling

[duffbeer703]

Real enterprise environments code web apps in Assembler. C is just a stupid hack and I can implement an operating system better anyway.

Re:Scaling

[Anonymous Coward]

The reason why PHP does not scale well is because the people at Zend who make PHP make you buy a PHP accelerator for a few thousand dollars if you want your web application to compete at the level of Java. If PHP came with the PHP accelerator by default then PHP would be scalable.

Of course....

[IonPanel]

Of course PHP scales as well as Java. Don't listen to those who don't like PHP. End of story.

Re:Of course....

[fussman]

to be fair, don't listen to those who like PHP.
Abuse of PHP.

Re:Of course....

[boomgopher]

Look, trust me, I've been on both sides of the fence, - we had a complex enterprise app that was originally written in PHP (and reasonably well), and it was difficult to maintain, debug, extend, etc. and it did not scale. The newer version is Java based, and it is mangitudes better in performance, robustness, etc.

Yeah PHP is quick and easy, but it's not for big projects.

Re:Of course....

[Sh0t]

Sounds like bad programming instead of a problem with PHP itself.

Did you ever consider that as a possibility?

And in other news..

[Keck]

pudding is as good of a building material as tofu..

Re:And in other news..

[Anonymous Coward]

Modpoints modpoints, my kingdom for modpoints.

Re:And in other news..

[Anonymous Coward]

The parent succinctly captures the essence of the article - very well put!

Re:And in other news..

[GoRK]

YOU ARE WRONG!

Tofu has more substance and will harden into a solid more readily than pudding! Your argument only holds water in very cold climates!

Re:And in other news..

[nocomment]

but nowhere near as good as fakeshake

Re:And in other news..

[proj_2501]

Make sure not to use the microwave instructions.

Re:And in other news..

[Anonymous Coward]

for the pudding, that is.

Re:And in other news..

[slimak]

I disagree, I can purchase extra-firm tofu but have yet to see any pudding that can stand on its own. Plug, tofu is often formed into the convient "brick" shape - its perfect replacement to regular bricks.

Re:And in other news..

[el pedro]

As a person who has been on several 100,000(+) block projects composed entirely of Tofu, I shudder to think that people still consider pudding to be as effecient, experssive or maintainable. Tofu is more portable (especially to Vegan OS's) Tofu is more stable (can you imagine implementing a shiesh-kabob with pudding?) it is more expressive (have you tried carving a bust of your boss in pudding?) more adaptive (ever tried making pudding a main dish?) and is more effecient (relying on a vegatable codebase as opposed to an animal one.)

The only reasons pudding is still used in modern systems are legacy systems (those people who haven't yet seen the Tofu light) and the fact that pudding's interface is more palatable to some users.

And my last (and most convincing) point: do YOU want to be coding everything in M$ Visual Pudding?

Props to PHP

[w3weasel]

Why do 'serious' programmers poo-poo PHP? And why are programmers filled with such zeal for their preferred language and disgust for all others? For people who are supposed to work logically, you'd think they would see that (nearly) all languages have their good and bad points.

Re:Props to PHP

[marmoset]

PHP is certainly cool, but there are some fairly major gaps to be filled.

Re:Props to PHP

[Pfhreakaz0id]

In my experience, there is a large portion of programmers who "poo-poo" anything that is a "slam it out" langugage because they have been left to try to maintain it and/or scale it up. (to be fair often times it is the WAY it is written, not the language that determines scalability. It is certainly poossible to write a classic ASP app that scales with MTS and COM objects to allow clustering/load balancing for instance, but most aren't written that way).

The problem is, there is a place for this technology. Not everything needs the features of Enterprise Java Beans, for instance. Some projects have such changing business requirements that spending months investigating them and designing object models is fruitless. Bang out a demo and if you need to fix it later, fix it.

I can't tell you how many times I have been given two weeks to write an application and/or add major functionality to an app, but I can sure count the number of times I've been given what I consider a deep enough spec that I would consider actually give serious thought to the object model: once.

Re:Props to PHP

[Anonymous Coward]

You're right, there are. Here's another gap that needs filled.

Re:Props to PHP

[Anonymous Coward]

because perl is just as good, and its general purpose. but that doesn't matter to some PHB dumbass: he wants his thing done in PHP or ASP or some kindof .NET crap, so IF I can even get my foot in the door, I've got to waste my time learning how to do things in a dumbed down inferior way.

I don't care if somebody else wants to do something in PHP -- actually think its pretty reasonable, I'm just sick of having the tools specified for me as part of the job, when I know I could do it faster,cheaper and better if I were allowed to choose my own platform. Repeat this a couple of times and you get mad at the tools.

Re:Props to PHP

[yintercept]

Programmers like other professionals need to establish a sense of professional elitism. PHP is a language that just about anyone can use, and when you have something that just about anyone can do, then you won't get the big bucks.

Programmers, doctors, lawyers need to fortify their salaries with an impenetrable layer of jargon. Java has the jargon.

The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.

Re:Props to PHP

[Malc]

Because having to learn a new language and a new way to do things makes them look ignorant and takes away the experience advantage they have from investing many years in what they already know. They're intimidated but would never admit it. That's hard for many prima donnas and their egos. Other than that, it's just intellectual snobbery, which as always is misplaced and misguided.

Re:Props to PHP

[Anonymous Coward]

"Why do 'serious' programmers poo-poo PHP?"

2 words "spaghetti code"

Re:Props to PHP

[letxa2000]

I'm just sick of having the tools specified for me as part of the job, when I know I could do it faster,cheaper and better if I were allowed to choose my own platform. Repeat this a couple of times and you get mad at the tools.

Then start your own company, or become an independent consultant and take the contracts you are interested in.

There is more at stake in any given project then what YOU can do faster since there are probably other people that can do it faster with the tools they want to use. If you are in a company and have an opportunity to promote the technology or language you think is best, do it--but don't make "because I can do it faster" one of your arguments. Unless you *ARE* the development team it really doesn't matter what you can do faster. Maybe you're not the right person for this job.

I'm an independent consultant and I often peruse job sites to see if there are any interesting consulting jobs out there. I've actually never found one using those sites, but I often see lots of entries for ASP work, etc. I obviously don't bother contacting them and try to convince them, "No, I don't do ASP. But what you REALLY want to do is..." That won't work. I just move on and find a company that coincides with what I agree is the better solution. Fighting the powers-that-be to use a different language is a high-stress, tiring proposition and what I want to do is develop, not campaign.

Re:Props to PHP

[gray_eminence]

I would say that the zeal and disgust is partially a marketing tactic. It's partially a way to differentiate between someone who has dabbled with and actually lives the zen of the job.

You might see a similar zeal within print-graphic designers against kids and small-business with immature corporate identity. We all know traditional printers have been hurt by the availability of cheap grapic ap's and ink-jets. We all poo-poo a bad web design when it has the hallmarks of someone who doesn't know what they are doing. When anyone and their dog can build an HTML page, you can't be indifferent about bad design when you are an experienced developer. Clients will learn there is no benefit to paying you, and they will realize that useless websites have to be the norm

We have to make those comments though, because otherwise most clients wouldn't know the difference between good work and bad work unless you point it out. And not every manager will immediately connect the dots (even with a presentation) of concepts like lowering cost by reducing bandwidth.

So you have to train yourself to stand up for what you've committed yourself to. More importantly you have to SELL what you believe. If you treat your own skills with indifference, then others will consider your skills as such. They will also put more trust in the programmer who is not just convinced, but *knows beyond a shadow of a doubt* that rolling with a particular language is the right thing to do. What else does a non-programmer have to go on? (Besides, do you expect a programmer so say... "I only work with slow, awkward languages")

Re:Props to PHP

[FuzzyBad-Mofo]

So where do you get your jobs from? Just asking, because I'm kinda in the same situation. Got lucky this spring and got a contract to build some PHP web apps, also did some Perl/CGI and C# there, but now I'm back on the bench and not seeing much action on the job boards. :(

Re:Props to PHP

[pHDNgell]

Programmers like other professionals need to establish a sense of professional elitism. PHP is a language that just about anyone can use, and when you have something that just about anyone can do, then you won't get the big bucks.

It's not so much elitism as it is experience. I work on project lifetimes these days. I want most of the work up-front so I can move on to other things. Whatever little savings PHP might get me up-front is of little value over the lifetime of the project.

The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.

That sounds like consultant mentality. It makes sense if your goal is to produce a working model that will look good at the end of a contract, after which you will never see it again...and who cares if it is difficult to maintain?

I just don't work that way.

Re:Props to PHP

[pyrrho]

> The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to build a career.

damn near perfect!!! damn near... but it would ring the point better if it was this.

The end result, PHP/MySQL is what people use when they want to get a job done, Java/XML is what you use if you want to get a job.

Re:Props to PHP

[Anonymous Coward]

I've moved from C to PHP over the last two years. The C code to do the same as the PHP code is about twice/thrice as long.

The advantage of C is strong typing and having to compile the code. Error catching is much easier in C. But PHP saves me bundles of time.

of course it does...

[joeldg]

we use PHP here for huge web applications.. we have six servers pumping out one website and it connects to a redundant database server.

The same system in java probably would not work, and if so would take up so many resources as to be no efficient.

If you are interested in more examples of some somewhat crazy things you can do in PHP check here to see examples of using it on the commandline for ncurses (which I wrote the primary tutorials on zend.com for) and for handling sysv shared memory.

Cheers

Re:of course it does...

[Fweeky]

The same system in java probably would not work, and if so would take up so many resources as to be no efficient.

Um, why not? A JIT compiled Java application server with the ability to perform object pooling and the like should outscale PHP in it's sleep, and probably be significantly faster at all levels to boot. If it does anything else, you did something wrong.

(Personally, however, I'm really favouring Ruby/FastCGI over both at the moment)

Re:of course it does...

[richarst1414]

we use PHP here for huge web applications.. we have six servers pumping out one website and it connects to a redundant database server.


Uhm ok.... only 6 we've had over 20 servers running our site using java, jsp and servlet tech's.

The systems works quite well...

Re:of course it does...

[joeldg]

our one java server at present that is running jacarta and tomcat is a huge resource hog and is slow on top of that, we are actually porting java code to PHP left and right because of issues with it being slow.

saying that it is actually a much faster box than the php boxes we have, and that those php boxes can outperform the java ones (at every turn, the benchmarks are ridiculous) we are not considering java at all.

Re:of course it does...

[joeldg]

what site?

we are a large domain name registrar (not the largest, but close).

Re:of course it does...

[FattMattP]

Tomcat is pretty slow in general. Why don't you try Resin?

Re:of course it does...

[Fweeky]

Well, that fits in to the "doing something wrong" category :)

Have you looked at Ruby? It's great for application server stuff, pretty fast, is far more elegant a language than PHP, and is much easier to extend in C/++ if you need to optimize a performance-critical hotspot.

Re:of course it does...

[Anonymous Coward]

The funny thing is, they probably do more traffic on those 6 PHP servers than your 20 java boxes.

PHP is ridiculously fast, especially wih a good compiler. Java is, well, not.

Re:of course it does...

[Anonymous Coward]

Maybe you need 20 because java can't carry the load on 6

Re:of course it does...

[ElGuapoGolf]

Tomcat is a reference implementation of a servlet engine....

If you want performance, use something like Resin (free). It will blow the socks off Tomcat.

People who complain that their java server app is too slow and then go on to mention that it's running on tomcat have no clue what they're doing.

Re:of course it does...

[PurpleWizard]

Except many people like to use Free/Libre Software and not act as unpaid devlopers for commercial enterprises.

Re:of course it does...

[stesch]

Why don't you try Resin?

Maybe he doesn't want to spend lots of hours to change his code every time a minor release of Resin comes out. And then discovering new problems many weeks later.

Re:of course it does...

[FattMattP]

I've never had that problem with Resin before and I've been using it for over two years. Then again, I have enough self control not to upgrade ever time a minor release comes out.

Re:of course it does...

[ChannelX]

Since when is Resin free? Its free for development use. Last time I checked they charged (only $500 per server) for it for commercial use.

Re:of course it does...

[angel'o'sphere]

Probably you should investigate why you have performance issues with your Java app.
I see you having the same and more issues after you have ported everything :D
E.G. we once had a modem connected to a unix machine which was used as file server only. Suddenly the performnce went down to 10% or less of its usuall one. The reason was a defect in the serial line causing noise on the serial port where the modem was connected.
angel'o'sphere

Re:of course it does...

[ElGuapoGolf]

Depends on what you're doing...

If you're running a personal website or hobby site, or something like that, you can get a license waiver.

If you're running it in a business, they expect a license fee. Fair enough, really.

Re:of course it does...

[Eric Savage]

I think you are confusing Java with applets. JSP (especially under Resin) is so fast and so efficient that I still have a hard time believing that some of the servers I work with can keep up. One is running a data-driven applicatino on a PPRO180 handling 8-10000 sessions a day, thats just crazy.

PHP has it's place, its great for multi-user web hosting companies where Java's architecture is a poor choice. It's not great for enterprise development, and every time someone who is fresh off writing their forum site suggests it I just have to pull out the long list of security problems PHP has/does have and the discussion ends immediately.

Why do PHP people feel the need to get into enterprise development? Java people aren't out there pushing for fansites and homepages to switch over, because they know its a bad choice.

Re:of course it does...

[Citizen of Earth]

If you put a big enough engine on it, even a brick would fly.

Re:of course it does...

[Anonymous Coward]

I think the point was that PHP is free.. Apache is free too.. and you can get a free PHP cache to remove the compile-time bottleneck.. voila, PHP smokes the crap out of anything Java has to offer.. for free!

Re:of course it does...

[Jetifi]

running jacarta and tomcat is a huge resource hog

Let me guess: is it a 3-series version? TC 4.1 and up don't have too many problems with resources, from what I've seen.

Re:of course it does...

[Anonymous Coward]

you need 20 servers and you probably don't get nearly as much traffic as directNIC

Re:of course it does...

[Elbows]

Not to bash ruby (it's actually my favorite language), but I wouldn't describe it as "pretty fast".
In all the benchmarks I've seen it is slower even than other interpreted scripting languages like Perl/Python.

Re:of course it does...

[Fweeky]

Well, PHP isn't exactly a speed demon either. Ruby has the advantage of being a far more flexible language, as well as being easier to extend in C and having more features which tend to reduce the size of applications written in it. Certainly, I've found it to be at *least* on par with PHP in most cases. And we can look forward to it getting more than 3 times faster, rawr :)

Re:of course it does...

[Anonymous Coward]

I work at a decent size hosting company, and our automation, billing, diagnostics and full stats system handles 500 servers one one puny dual 550 running PHP and MySQL.

Re:of course it does...

[IA-Outdoors]

Please don't use the language itself as a security issue. While each language has it set of security concerns, poor design and poor programming account for over 95% of the security issues I have seen. Some languages make it easier to code insecurely but it is still the responsibility of the developer to have a clue.

Re:of course it does...

[Anonymous Coward]

While Tomcat is still a tad behind with regard to performance compared to its proprietary counterparts, it's pretty widely recognized that the 5.x versions are a lot faster than the slower 3.x and 4.x revisions. Certainly fast enough to run a production platform on.

Re:of course it does...

[Anonymous Coward]

we are a large domain name registrar (not the largest, but close).

The largest registrar does use Java.

Re:of course it does...

[Anonymous Coward]

I just have to pull out the long list of security problems PHP has/does have and the discussion ends immediately.

Which list would this be then?

Why do PHP people feel the need to get into enterprise development?

The same reason "Java people" do. To get the job done.

Re:of course it does...

[Anonymous Coward]

Not really of you to say that it is free without qualifying though.

Re:of course it does...

[butane_bob2003]

I had to get off tomcat cause of the bugs. Last release was sooo buggy! I've used Tomcat for a long time, Resin is more predictable. When something does go wrong, the error messages are much more comprehensible. Jetty is decent too.

Re:of course it does...

[Anonymous Coward]

Yeah, and everyone hates them...

yeah whatever

[TedCheshireAcad]

I call bullshit.

PHP is a useful language, and it certainly has its place. But for large enterprise applications, it can't hold a candle to J2EE, in terms of speed and scalability. If you drop some serious bank on an application server, you'll know what you're paying for.

Moderators, have mercy.

Re:yeah whatever

[Foofoobar]

Yeah... I LOVE PHP but I have to agree. Without a web server, PHP is still pretty good but it just doesn't scale. Now if he said PERL was as scaleable, Id say he was a bit closer.

Re:yeah whatever

[Prowl]

Agreed. We use mod_perl, and all our logic is implemented as Perl Modules. Web sites are just wrappers around the logic.

We chose this because it eliminated the requirement for the web site. We could quite easily interface in Perl/Tk, command line, or curses etc...and because Perl is just cool.

Obviously Java can be used standalone, not sure about PHP. Can it operate with the presence of a web server?

Re:yeah whatever

[Prowl]

ooops

s/with/without/

Re:yeah whatever

[consumer]

See? This is the kind of FUD people have been complaining about. You have zero information here about what would make Java scale better, but you still insist that it does.

Re:yeah whatever

[Foofoobar]

Yeah I get you. Yes it can (though few people realize this). You simply install it as a CGI and call the binary as such: /usr/bin/php your_script.php

and POOF! your_script.php executes :)

Though few people install PHP as a binary; most install it as a PHP module.

Re:yeah whatever

[Anonymous Coward]

We dropped serious bank on a Java application server. Couple hundred Gs. In the end it was a complete fucking waste of money, and dog slow. Oh well.

Re:yeah whatever

[Foofoobar]

Hmmm... testing this out but so far it seems with some minor adjustments, I can run php scripts with it installed as an apache module too. I just have to make sure the system knows where to find the necessary files :)

Learn something new every day. :)

Re:yeah whatever

[LetterJ]

It can absolutely work without a web server. I use it for a lot of utility-type work with it on the commandline. Using our own PriadoBlender, I get EXE's from my PHP. The way we blend PHP is technically possible on UNIX as well.

Re:yeah whatever

[jasondlee]

With PHP 4.3 (?), the module and CLI versions are both compiled and installed by default. For scripts, you can aslo set the executable bit and put #!/usr/bin/php on the first line, and run it like anything else. You can also create GUI apps with php-gtk. I use it for quite a bit, and find it pretty useful from the command-line.

jason

Re:yeah whatever

[IA-Outdoors]

The test of whether PHP can handle enterprise applications has nothing to do with Java. With requirements, the right design and and eye to details (all required regardless of language) you can build a scalable, enterprise level PHP application. Can Java do it better? Could be, can it do it cheaper? On average the cost of a Java application is higher than the same application in PHP. I'm not implying you can't do quality Java implementation on a budget I'm just saying that is the trend I see on a daily basis.

Re:yeah whatever

[aschlemm]

Geeze who spends money on a J2EE application server environment up front these days. You can get both the JDK and JBoss for free and work with that first. About the only thing really needed with the JBoss through is that's worth paying for a 1 year subscription to their documentation which I got for $99.00. That was a great deal given the number of developer hours that would be wasted trying to figure stuff out without any documentation.

We had two learning curves in that we were figuring out how to setup JBoss and also we were learning XDoclet on the fly. In the end though we've got JSP, and EJB code that isn't really tied to a given application server. With the doclet tags embedded into our EJB code we have XDoclet generating all of the boiler plate things like interfaces and XML deployment descriptors. If we wanted to deploy to Weblogic we'd just change our ANT build.xml file to tell XDoclet we want support for Weblogic rather than JBoss.

We use the embedded Tomcat servlet engine in JBoss and it is rather slow when it does the initial compilation from JSP ==> Servlets ==> bytecodes but that's only the first time a JSP page is accessed. The next time the same page is accessed it loads very quickly.

They got it backwards

[defile]

I thought the shocking revelation would have been "Java scales as well as PHP" under pathologically slanted circumstances.

Yes but can it...

[inteller]

..scale Mt. Everest. ...when it does .NET will be waiting at the top.

wonderful comment

[Anonymous Coward]

Especially since you have no first hand experience with Java, making you qualified to have an opinion.

Wonderful.

Re:wonderful comment

[stanmann]

And you are an Anonymous Retard making you qualified to fling your feces...

Re:wonderful comment

[Anonymous Coward]

HAHA YHBT dickhead

Re:It may scale

[twoslice]

But does it run java?

Yes, but does it run PHP?

Java owns PHP

[JavaLord]

Real programmers use Java. PHP is total garbage, as is every other programming langauge. Ok, maybe I'm a little biased.

Re:Java owns PHP

[odyrithm]

Real programmers use Java ey? Real programmers use Java?! the fact Java is not a "real" programming language anyway begs the question.. are you a retard?

At least come up with something constructive against PHP instead of making one of the most insulting comments Ive ever heard against "real" programmers.

Anyway anything PHP is slow at can be fixed simply by codeing up a C module to handle what ever it is thats taking to long.. not many people have bothered to mention this have they.. no its not PHP anymore but PHP gives you that option atleast.

Re:Java owns PHP

[mvonballmo]

"... as is every other programming langauge."

As is the English "langauge", eh?

Re:Java owns PHP

[crazyphilman]

Yeah... Perl lets you do C modules too, it's one of the nicer features of the scripting languages. Another cool thing is you can run external programs you've developed elsewhere to offload parts of your task. So let's say you've got something really horrible and complicated, which could best be done using OOP techniques. No problem; use the Perl or PHP script as a frontend, and call an object oriented program from within the script, passing in the data in one of a few ways. Then you get all the benefit of object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language, etc, but you also get to work with scripting. I'm pretty sure doing something like that is at best nontrivial in Java. If it's possible at all.

Although I lean towards Perl, personally, I've heard only good things about PHP. Looks interesting!

Re:Java owns PHP

[Anonymous Coward]

"the fact Java is not a "real" programming language anyway begs the question.. are you a retard?"

At least come up with something constructive against Java
At least come up with something constructive against Java
At least come up with something constructive against Java
At least come up with something constructive against Java
At least come up with something constructive against JavaAt least come up with something constructive against JavaAt least come up with something constructive against JavaAt least come up with something constructive against JavaAt least come up with something constructive against Java

Re:Java owns PHP

[lycono]

Not to jump into your guys' troll fest here but I thought I would point out for info that passing off processing to other langauges/runtimes/etc is pretty easy in Java.

You can simply use native calls or invoke another process (you can call any executable from within Java). Native calls allow you to directly call into other compiled languages (I've usually seen C as that other compiled language). Additionally, you can invoke any executable, passing input just like a command line and reading output just like a command line.

Although I will say that I think your point is rather moot since you argue that you can pass off processing to get the benefits of "object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language" from a scripting language, but you pretty much have all that in Java already, so there would be no need to do so from Java. You would need another compelling reason to pass of processing in order to make your argument. So the fact that you could or could not invoke other processes or hand off processing doesn't really matter from Java.

Anyway, please continue, sorry for the intrusion.... :-)

Re:Java owns PHP

[crazyphilman]

I beg your pardon, but I'm not trolling. I was making a totally serious comment. I know it's traditional slashdot etiquette to label all opinions you disagree with as "trolling" but let's keep a civil conversation civil, ok?

Ok, having said that, I was under the impression that you had to take a couple of extra steps in Java to run an external program, mostly due to its sandbox approach to security. I.E. that it was doable, but slightly more complicated than it is in a scripting language.

Why you might want to do it in a scripting language is obvious; compiled code is very fast, features you might want are supplied in your compiled language but not your scripting language, and you might want to do something complex which would be helped by an OOP approach. Also, if you build your external apps well, you can access them from code you'll write in the future, not just from the script you're writing right now (kinda like web services, eh?).

Since you mentioned it, you might want to do it from Java because you might want to benefit from using REALLY compiled code rather than JIT compiled code. A JIT compiler compiles each class as it hits it. So unless you have a prep app which touches each class at least once, your stuff is going to be compiled on the fly for at least some of your users. Thus slower than a completely precompiled app. Of course, you won't find this compelling, because is it? I don't know. Maybe not. But it's a possible reason for using external modules, etc...

ANYWAY, my point was that scripts can get a performance and development benefit from using external modules, and that I think that's kinda neat. Useful. Not really related to script vs. Java, but sort of interesting in a tangential way.

Re:Java owns PHP

[JavaLord]

for everyone who replied like I was serious (which I'm not), and the mods who modded me "flamebait" it was a joke, check my user name...:P

Re:Java owns PHP

[Anonymous Coward]

"... as is every other programming langauge." As is the English "langauge", eh?

Oh my god, you are so witty and elite! You are so smart! You pointed out a TYPO on Slashdot. Wow, that guy must be a real moron for typing too fast and mixing up the u and the a in a post that is a joke. If only everyone was as bright as you, and said eh! all the time. I bet the original poster was a stupid American! I'm sure you are truly a genius posting from some third world eurotrash country also!

Re:Java owns PHP

[Anonymous Coward]

Whatever, Java owns PHP and you know it.

No..

[sporty]

W/o fine grain controls such as managing the persistent connection pool to resources...

No, it's not.

That's not to mention all the other architectual mishaps within the language. You thought perl was bad..

Re:No..

[ElGuapoGolf]

Bingo....

Until PHP has some sort of pooling built in (does it? Last I used was PHP4), it's not going to be as robust or scalable as Java for enterprise server applications. Period.

Re:No..

[sporty]

Let's not forget things like RMI/SOAP/XML-RPC. As a server technology, not client only.

Given a choice

[jniver]

But given a choice which would you prefer to use.

I've used both, and for database access I would prefer PHP.

New pole option?

Re:Given a choice

[bmedwar]

I have used PHP for MySQL-driven websites, and it has been nothing short of wonderful. I am currently writing a stand-alone GUI app. I chose J2SE/Eclipse/JFace/SWT over VC++/MFC. I chose Java because of the fact that I can use gcj to compile a native executable for various platforms with an unmodified code base. I don't know of any way to compile PHP code to a native executable.

Re:Given a choice

[tkwoof]

I don't know of any way to compile PHP code to a native executable. No me either, however, PHP is so similar to Perl that if you are going to write an app in the former, you might as well do it in Perl and it does compile quite nicely.... Perl2exe is just awesome. There are however, several options available, and they are FREE!

PHP Vs. Java

[mattboy99]

PHP by itself is a superfast scripting engine, both in installation and use. Java on the otherhand requires a lot of setup and maintainance, and usually requires one machine dedicated to hosting its applications. Now tell me how they equally scale?

Re:PHP Vs. Java

[blogboy]

Java on the otherhand requires a lot of setup and maintainance... Read: "What's a classpath?" Give me Java or give me a life!

Re:PHP Vs. Java

[Frymaster]

Java on the otherhand requires a lot of setup and maintainance

java also requires a lot of development time! writing php is so damn fast that you can shave some serious time off your development and debugging cycles. for anecdotal evidence witness two dot coms. i work for one. my friend worked for another. we both started our more-or-less equally-sized apps at the same time. my dot com went to market. his went bankrupt at the 90% mark three weeks after we were done.

Re:PHP Vs. Java

[poot_rootbeer]

Why should "easier to install" be a factor in choosing PHP over Java? If you do it right, you'll only have to do the installation once during the life of the server.

You should be more concerned with which platform is more powerful and scaleable once the installation is complete.

Re:PHP Vs. Java

[odyrithm]

no I think the point that was trying to be made is Java is just to much hassle in all areas; installation being one of them.

Re:PHP Vs. Java

[Anonymous Coward]

Hrm ...

# mkdir /usr/java
# cd /usr/java
# tar xzf /root/packages/j2sdk1.4.2_01.tar.gz
# cd /usr/local
# tar xzf root/packages/jakarta-tomcat-4.1.27.tar.gz

Does n't seem all that hard to me ...

Re:PHP Vs. Java

[Politburo]

PHP by itself is a superfast scripting engine, both in installation and use. Java on the otherhand requires a lot of setup and maintainance, and usually requires one machine dedicated to hosting its applications. Now tell me how they equally scale?

Wow, is *that* what they changed the definition of 'scale' to?

Re:PHP Vs. Java

[odyrithm]

forgot about PATH settings for one.

Re:PHP Vs. Java

[Wonko42]

Superfast? In what sense? Fast in terms of development time, perhaps, but certainly not execution time. PHP is one of the slowest programming languages there is.

Re:PHP Vs. Java

[Samus]

You could probably argue both ways. I spent a while trying to get the tomcat connector(mod_jk) to work right in apache and after much thrashing got it right. I also spent a lot of time having to recompile php b/c the distro I just loaded (Slack 9.1) doesn't have php with postgresql support built into it. So in order to get that I had to recompile from scratch. I also needed imap support but I use Courier and it only supports compiling with UWImap or cyrus. So I had to compile UWImap before I could compile php. It took a little while to get the build settings for that right enough to compile too. At least I didn't have to worry too much about the options on that one. I only needed the c-client libraries. Then after that ordeal phpgroupware still wouldn't work. It turns out that in 4.3 or so if IMAP with ssl is installed php defaults to using that. Nevermind that it breaks old code that ran just fine on servers not doing ssl. Sure all of this would have been unecessary if I didn't need anything outside of what my distro provided. Hell it would have even been preinstalled. But if you have to go outside the bounds of whats given you then things get hairy. Anyway they can both be a pain in the ass.

Re:PHP Vs. Java

[tedgyz]

Yay! Now you have an unmaintainable pile of poop sitting on top of a language with enough holes to drive a truck through.

Re:PHP Vs. Java

[Anonymous Coward]

Holes in PHP aside, you have no way of knowing whether his app is maintainable until you've seen the code, and that is a FACT.

Re:PHP Vs. Java

[tkwoof]

PHP by itself is a superfast scripting engine, both in installation and use
Amen brother! Add to the speed of PHP the ability to switch gears intermingle other languages and pretty much go nuts with the development of a project, and PHP becomes an awesome tool for any web development job out there... Unless ofcourse you want to simulate slow, hard to write, expensive coding, PHP doesn't do that so well..... ;->

Re:PHP Vs. Java

[Anonymous Coward]

You are correct on that point. But it is not at all difficult to set a path, or the JAVA_HOME environment variable. It's certainly not /harder/ than figuring out how to compile PHP with all the options you would like, or setting up your Apache server to play nice with PHP, and things of that nature. And, on the flip side, it's certainly easier setting up Tomcat to work with Oracle than it is for PHP. My point being, I'm familiar enough with both, and I don't regard either as significantly more difficult to set up.

Kiss and say goodbye to Java language!!

[Anonymous Coward]

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

Re:Kiss and say goodbye to Java language!!

[quadelirus]

I already wrote one post in favor of PHP. So here is my post in favor of Java. Don't dismiss Java too easily, it has a lot of libraries for doing things that are more difficult to do in Scripting languages... Anyway I like Java for client side apps, not for applets. I write code on my linux box, and it runs on my MS Laptop and on my Apple Titanium, end of story... The performance boost from C is really neglegable on the client side with computers running as fast as they do today.

Re:Kiss and say goodbye to Java language!!

[mannionh]

Actually they both run on virtual machines. You might know this if you read the article.

Re:Kiss and say goodbye to Java language!!

[Anonymous Coward]

"The performance boost from C is really neglegable on the client side with computers running as fast as they do today."

Bull shit. C and even C++ blow away Java in any performance critique even on high end machines. Facts is, Java requires a virtual machine to interpret the bytecode. C executables run natively without the help of any VM, hence the wide performance gap.

Java was not designed client apps; using it as such is as pointless as using xml as a file system.

Re:Kiss and say goodbye to Java language!!

[quadelirus]

do you use Java applications or are you speaking from what youve read, since everything on the internet is true? I actually use a lot of Java apps.

Re:Kiss and say goodbye to Java language!!

[eakerin]

I'll bite,

Modern Java Runtime Engines (eg: Sun JRE 1.3, and 1.4) do not interpret most of the program. it Compiles the bytecode to machine code, and then executes it.

Some of the lesser used functions, and classes are interpreted. but if a function is used often, it is left in machine code, and never re-compiled again as long as the program is running. giving you code that is just as fast as C.

Look up information on the Sun Hotspot Virtual machine, and then respond.

Re:Kiss and say goodbye to Java language!!

[quadelirus]

hey! thats cool. I did not know that. does that mean a function as in a function() as part of a class or by function do you mean like more generic like an entire class file or large chunks of an application?

Re:Kiss and say goodbye to Java language!!

[Anonymous Coward]

Bull shit. C and even C++ blow away Java in any performance critique even on high end machines. Facts is, Java requires a virtual machine to interpret the bytecode. C executables run natively without the help of any VM, hence the wide performance gap.

You should update your Java knowledge. This was true 5 years ago, but not true today.

Re:Kiss and say goodbye to Java language!!

[j3110]

This exact post is in every PHP/JAVA story on /., all the links are usually broken, and the writer is an idiot.

Java was written in C as well. Java compiles directly to machine byte-code on load (which happens once per class, which means only once per jsp file just like PHP).

My real question is how does this troll keep getting modded up?

Just for your information, I had to switch from PHP to Java because PHP was impossible to maintain.

Re:Kiss and say goodbye to Java language!!

[chundo]

Heh. I'm not even sure where to start critiquing this one. But I'll give it a shot.

First off, PHP is an interpreted language. JSP is compiled on the first request. It doesn't matter that the PHP interpreter is written in C, it's still interpreted. JSP classes, after compilation, run as native Java classes, which as another poster noted, are often compiled to machine code in modern JVMs. PHP has no advantage here, at least not based on your argument.

Your benchmark links are all broken, so I can't evaluate your claims on that front.

And of course Java is just another language. So is PHP. So is C. What makes Java so useful is the included libraries that make it incredibly simple to rapidly develop network-aware applications. They've all got their place. And it usually comes down to a matter of preference, not performance.

The development world would be a better place without opinions like yours. I'm a professional Java developer, but I choose to use PHP in my own side businesses. They both have their place, and I like them both. Performance is fast on both technologies, regardless of your ill-informed claims. I strongly suspect that you are basing your comments on your experience with only one of the two technologies you're trying to compare, supplemented by unsubstantiated claims you've heard about Java. Use both languages extensively for awhile and you won't be as uninformed.

-j

Re:Kiss and say goodbye to Java language!!

[Anonymous Coward]

The string manipulation in php is extremely fast and in java it is extremely slow.

Java apps themself run much faster than php apps but for websites where spewing html is all you do php keeps up because the string code in java bogs down jsp.

Re:Kiss and say goodbye to Java language!!

[mios]

Sorry, suckah ... As a disclaimer, I am a big fan of PHP, but PHP is as much of an object oriented language as C is ... which it's not. It pretends to be and is wrapped up to be convincingly well enough (and quite usefully) in some regards, but really .. it's not ... Java isn't even completely Object Oriented ... with chars and ints and what not ... now SmallTalk .. that's pure baby ..

Best typo ever

[thaddjuice]

"...a peek at the architecture beneath both hypes."

Assuming this is a typo, it's the most appropriate one I've ever seen.

PHP

[grub]

print "0wn5 j00";
?>

Get out the Zell Gel

[w3weasel]

Here comes the flame war

Meaning? It doesn't scale at all...

[Anonymous Coward]

Right, right, that makes sense. It's only after hearing horror stories coming from the telecom
industry that you realize how much Java scales. Around 50 servers to run a network for a
pool of about 1 mil customers ISN'T what i call scaling!

You can compare PHP to Java all you want, both of those technologies have serious flaws
and aren't that interresting. You want to create another .com bubble, sure why not. Don't
come in afterwards complaining that the market went down again. I'd like the market to
evolve a little bit and for this to happen, the suits will have to listen to the jeans.

Re:Meaning? It doesn't scale at all...

[quadelirus]

so what exactly would you say DOES scale? ASP.NET? Perl maybe?

Re:Pathetic Heap of Poop

[Foofoobar]

ASP = Ass Sandwich Provider

Take your FUD elsewhere Microsoftie.

OFFTOPIC

[Anonymous Coward]

Hey what has happened to moderating??

Usually ~5% of the messages get five points, 10% get four points and so on.. Recently ONLY 0.5% of the posts get five points and couple of percents four points. I used to read only 4-5 point messages but nowadays there are only few of them!!!

It seems that users don't get five-point-moderator status anymore so often. Why?!?!?

perl

[SCHecklerX]

I'll stick with mod_perl and HTML::Embperl, thanks.

Re:Perl

[ProtonMotiveForce]

Uhh, right... Ever tried to maintain half a million lines of Perl? 3 million lines?

The overhead of maintenance for Perl rises exponentially with the number of lines.

Re:Perl

[Anonymous Coward]

> Perl seems to scale as well--it runs a very busy site I frequent with few problems.

You obviously haven't been getting all the 500 Server Errors recently, then.

Re:perl

[BestNicksRTaken]

Gotta agree with you there.

I used to love PHP, but I've found it way too slow for things that Perl is good at - regex and array manipulation.

Don't even get me started on the crappy XML-RPC implementations for PHP!

Re:Perl

[tshak]

/.'s gotten a LOT better in the past few months, but it's history of uptime is horrible when compared to the other sites that I visit. Granted, a lot of the problems were DB problems (mySql).

Re:perl

[arth1]

I'll stick with mod_perl and HTML::Embperl, thanks.

In most situations, even that is overkill. A combination of a perl script and HTML template files will usually do just fine:

sub printfile {
my $filename = shift;
open(INFILE,"<$filename") or die "System error for file $filename: $!";
while(<INFILE>) {
if (/[\$]/) {
s/(["\\@])/\\$1/g;
print eval qq/"$_"/;
} else {
print;
}
}
}

For larger projects, there's still usually no need for heavy middleware or obfuscoware -- a well-written design including flowcharts, algorithms and an API will do much more for a design than any amount of middleware can.
Maintaining other people's code? You shouldn't HAVE to scrutinize the code -- you should be able to see what should be done (and where) from the design. If a module doesn't work, redesign and replace it. What it's written in *should* be irrelevant, as long as it has a well-defined and working API.

Regards,
--
*Art

Re:Perl

[rmohr02]

Depends on who wrote it. Perl can be hard to maintain, but if you follow some coding practices it isn't that bad.

Re:Perl

[pHDNgell]

Perl seems to scale as well--it runs a very busy site [slashdot] I frequent with few problems.

I've been having a great deal of broken pages lately.

I also have been having a lot of problems with the RSS feeds lately.

Overall, I like using slashdot as an example of why mySQL and perl are bad ideas for busy sites.

Any language can be used to write bad code, but I've rewritten really perl projects (2M line range) that were impossible to maintain into java (for example) applications that were not only easier to manage, but performed better.

Whether raw perl is faster than raw java, who knows or cares? When I want raw speed, I write apps in ocaml (or C if I need slightly more speed). When I want to prototype something quickly, I write apps in python. When I want to build a large scale application, I use java (and python for parts). With a proper design, going from one application server to two doesn't double the strain on my database server (not even close), but usually doubles my capacity. It also doesn't require a rewrite of the app.

Then I start making things happen asynchronously with threads and message queues. These days, my apps are looking more like mainframe apps from performance monitors. We maintain a pretty high load here, and I watched it triple during some event for a few minutes. Processing speed was constant due to surge protection I was able to make using a simple thread and a linked list. For our most common type of database work, there is no more than one insert/update occuring per application server instance. That makes such a huge difference.

Re:Perl

[WNight]

Only if you're a sloppy coder.

I've seen some code from a friend's company and their Java is quite nice to look at but their Perl didn't even have warnings and strict turned on, and they used every ugly hack the language supports. They couldn't maintain a hundred lines of code. They'd all been told that Perl was ugly so much that they never even tried to do it properly.

But, I've seen really messy C++ before where all the warnings were supressed and nobody followed a consistent style. There was some hungarian notation mixed in with 'i' and 'ptr' (to what?), and some more verbose but just as useless 'loopCounter', etc. Some people used braces for every code block, other people only used them if required (ie, not for one-line blocks), some people left out semicolons on the last statement in a block.

You can still get ugnly code, Even in languages like Python with enforced syntax you still get ugly code - useless variable names, no input checking, no error handling, 500+ line functions, etc - if you don't do it well. No language can produce decent code.

It all depends on what the people you work with are like and what the bosses let you get away with. I code in perl at work for all of our web stuff and I turn out very nice perl that my co-workers have commented positively on before.

Perl also produces much shorter code than most other languages, meaning that what would be 500 lines of C, or 200 of C++, or 150 of Java, is 25-50 of Perl. That three-million line project wouldn't be that long because you'd be using a high-level language in which things like regexes are first-class functions.

Re:Perl

[consumer]

Amazon.com and Ticketmaster.com run significant parts of their sites on Perl. It's fast. Slashdot's code is not very elegant. This is not Perl's fault.

Re:Perl

[iantri]

As you say, you've been having problems lately. If you'll note in CmdrTaco's Journal, Slashdot is having server issues right now.

Re:Perl

[pHDNgell]

Slashdot's code is not very elegant. This is not Perl's fault.

I disagree here to a degree. Languages have cultures and idioms that are built around them. If a language makes it easier to do something in a bad way, then it's most likely to be done in a bad way (or it'll be hard to work with).

For example: Perl, like C requires you to check results of most things you do to verify they worked. That's a ridiculous way to write anything of any complexity. If I say something should happen, it should just happen. If it can't happen, *then* let me know about it. Good code in a language that uses exceptions natively looks like ``bad'' code in a language that requires you to do the work yourself...meaning the programmer will likely express what he wants to happen and then move on. If exceptions are a core part of the language, the application will go to an exception handler as soon as something ``goes wrong.'' You have to specifically prevent this from happening.

Compared to having to specifically validate every operation you do and plan a path out even for really unlikely cases, it's a lot easier to write reliable applications in langauges like python, java, ocaml, etc...

Re:Perl

[consumer]

My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.

Re:Perl

[pHDNgell]

My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.

Perl's file IO, DBI, etc... make no use of exceptions. You have to build your own abstractions to do this. Python, ruby, java, ocaml, (etc...) use exceptions at the lowest level available to the programmer.

That's my point.

Re:Perl

[consumer]

You're misinformed. I use exceptions with DBI. Just pass it the RaiseError parameter.

Re:Perl

[pHDNgell]

You're misinformed. I use exceptions with DBI. Just pass it the RaiseError parameter.

Behind is probably more accurate. :)

Is there a RaiseError parameter for open(), read(), write(), etc... ?

Re:Perl

[consumer]

There's a really handy module called "Fatal" which you can use to make any existing function throw an exception if it returns a false value. For example:

use Fatal qw(open close);

Re:Perl

[pHDNgell]

There's a really handy module called "Fatal" which you can use to make any existing function throw an exception if it returns a false value. For example:

use Fatal qw(open close);


This is very informative and something every perl programmer should know and use.

I, however, will be sticking to languages that don't require me to remember to mark every function that might fail as something that should throw an exception on failure and will just do it by the way stuff in the language is designed. I don't want to have to remember the way to get DBI throwing exceptions, IO stuff throwing exceptions, etc...

Re:Perl

[Anonymous Coward]

Proofread your friggin sig, please.

Re:Perl

[pHDNgell]

As you say, you've been having problems lately.

My RSS feeds have broken randomly for as long as I've had the thing up. It's given me the opportunity to come up with a really robust design for it, though. :)

Could someone explain instead of just flaming?

[Faramir]

Okay, talk about asking for a flaming! I'm a PHP developer whose done a bit of Java but knows nothing about J2EE. Can someone explain how this is relevant to me, as I start looking at larger applications with hundreds, perhaps thousands of users?

Re: Could someone explain instead of just flaming?

[Anonymous Coward]

Basically, if you want any sort of decent database access (connection pooling, caching, etc) with PHP you are going to have to use some mysterious 3rd party products.

If you need isolated transactions that involve multiple resources, you are shit out of luck with PHP.

If your code design is at all complex, or you have a large team, you probably want to go with Java.

On the other hand, if you just have some simple data that you want to splat onto a web page, PHP has the potential of being much faster under a large user load. J2EE doesn't really help you there.

Re: Could someone explain instead of just flaming?

[Quarters]

Easy, this article is your ticket to fame. You don't even need to read the article or understand it. You just need to remember that PHP = Good and Java = suck.

Now march right into your CTO, CEO, CFO, C*O's office(s) and proclaim, "PHP is good, Java is for suck!" You'll have a corner office and a company car in no time!

And don't think for a minute that that cute secretary won't start talking to you at the next birthday-cake gathering. She WILL! She'll recognize an intellectual. She'll want to be with a man who knows his place in a stupid adovcacy war. She'll be all over you man!!

Repeat it one more time, "PHP R0xx0rz, Java is for Suck"!

Re: Could someone explain instead of just flaming?

[jsse]

I'll try.

Performance-wise, J2EE decouples major components which would otherwise become bottleneck of overall performance. E.g. most popular architecture decouples frontend(e.g. load-balancer, apache), business logics(e.g. servlets, EJB-containers) and database(e.g. Oracle, Sybase) such that optimization could be done on individual components. Optimization can be ranged from adding CPU/RAM, disk stripping to clustering. Experience told us that this architecture can be very sucessful in improving performance and scalability.

I can't really disgree on the critism on the raw speed of Java, but as you may see J2EE successfully spreads the loading among entire framework, which lead to huge gain in overall performance.

I'm not going too deep into design and implementation issues here, as they might be off-topic this time. However, as you can see, design and implementation can be done seperately on each components as listed above.

Frankly, I'm not so sure if PHP has gone that far.

Re: Could someone explain instead of just flaming?

[crazyphilman]

I think you're mixing two concepts here. First, there's Java/J2EE. You can do Java without doing J2EE. J2EE is a whole set of additional tools and ideas which are java-based. My impression of it is that it's more useful to huge organizations like banks, where you've got different servers in different buildings which have to interoperate (hence things like javabeans and servlets). It's not a scalability thing, it's a distributed application thing, you know? Although I'm sure J2EE has scalability features built into it, I don't think scalability is the whole point of J2EE.

On the other hand, if you're talking about just scaling to larger numbers of users, you're probably talking about load balancing more than anything else. One server will basically be handing off requests to other servers based on how busy they are. That has nothing to do with Java Vs. PHP. You can use either with that. The only gotcha is you should make your pages stateless (no session variables, etc). If you pass data from one page to the next, do it the old-school way using hidden form elements, because then no matter which server gets handed the current request, you'll have the passed-along data and you don't have to futz around with the session.

My thinking is, as long as your scalability has to do with load, just worry about load-balancing, make your pages stateless (there IS state, but you're passing it along on form posts rather than trying to store it on the server), and use whichever language has been working for you up until now. Don't touch J2EE (or .Net, or any other buzzword) unless you actually *need* it, like for example, if your app is distributed and very complex.

Re: Could someone explain instead of just flaming?

[digidave]

Java application servers like Websphere and Weblogic will handle sessions accross multiple servers. The major advantage of Java for web apps is that there is a nice app server working in the background to handle stuff like that.

In PHP you can use cross-server session variables by having PHP store the session data in a database. While non-default, it is easily supported with a simple config change.

Re: Could someone explain instead of just flaming?

[crazyphilman]

Websphere and Weblogic I can understand; it makes sense to use session variables if you've got a server setup that takes care of sessions across different servers and it's transparent to you. I can see the utility in that.

As far as putting sessions in a database, boy oh boy, I don't like that idea much at all. Calling out to a database (on a different server, since we're talking about cross-server sessions) every time you load a page and have to check the session adds in a nice little speed bump -- no thanks.

If I really must have sessions and load balancing at the same time, I'll use one of the servers you mentioned, Websphere or Weblogic. But I can't really envision being too stubborn about wanting both.

I'd rather use hidden form elements, myself. I know it's old fashioned, but it takes up fewer resources, causes fewer headaches, doesn't require app servers or databases (cheaper!), and is easier to debug. Just my opinion -- I don't have a problem with people who like session variables, state, etc. But I don't personally see much use for 'em.

Re: Could someone explain instead of just flaming?

[Slime-dogg]

Don't forget the true reason! Scaling each part is all nice and stuff, but the really great part abount decoupling is the ability to update different portions at any time without having to break the application while integrating. If you update the database, then all you have to do is update the associated Javabean, without having to break the pages that use that bean.

Re: Could someone explain instead of just flaming?

[Slime-dogg]

Eh, don't knock .NET unless you know what you are talking about. Most everything in .NET is stateless, unless you actually use it. If you use Visual Studio .NET to design your ASP.NET apps, it will generate the page state as a hidden form element that gets posted. That is how it preserves state.

You have the option of using a state server, with it either being the web server, a separate web server, or the database itself, but sessions are typically minimized (unless you fill them up with garbage yourself.)

I don't mean to be harsh or anything, but I am familiar with both Java and .NET, and I'm not much of a fan of people making suggestions based on their own misconceptions.

Re: Could someone explain instead of just flaming?

[gregmac]

As far as putting sessions in a database, boy oh boy, I don't like that idea much at all. Calling out to a database (on a different server, since we're talking about cross-server sessions) every time you load a page and have to check the session adds in a nice little speed bump -- no thanks.

One query that returns one row. Total of maybe 2k transferred. Any page that uses sessions and is setup on clustered servers probably makes a bunch of other database calls already anyways. What's one more for a proper pattern-friendly solution?

If I really must have sessions and load balancing at the same time, I'll use one of the servers you mentioned, Websphere or Weblogic. But I can't really envision being too stubborn about wanting both.

I've never used either of these myself, but I would imagine that an entire server architecture (as basically a fancy abstraction layer) adds more overhead than makine one database call.

I'd rather use hidden form elements, myself. I know it's old fashioned, but it takes up fewer resources, causes fewer headaches, doesn't require app servers or databases (cheaper!), and is easier to debug.

Ok, let me make up a list of why NOT to use hidden form elements:

• Takes up bandwidth (sending the form elements with data, and the user sending the results back)
• Requires that every page be submitted as a form, which in turn means you have no "friendly" URLs, or all your pages are POSTs and the back button is uselss
• The back button, for that matter, will log you back in, or restore an old state
• Tons of possibly sensitive data could be cached
• The user has access and can change values, this can sometimes be a major security problem

Perhaps the database point is ok - but on modern computers, mysql doesn't really add that much overhead. If you're at the point where the server is loaded up, then it should justify the cost of buying a second server (or cluster of them) anyways. Espessially when we're talking about free servers like mysql or postgres, which have both proven they hold ground against the big 3 in most situations.

I'm not even sure I agree it's easier to debug. I usually just dump out values at the bottom of the page when debugging; don't even have to click View Source and wade through a bunch of html.

Re: Could someone explain instead of just flaming?

[crazyphilman]

Hey, hey, come on, be cool. All day, every day, I do VB.Net and web services, so I'm not anti-.Net. Actually I like .Net a lot. All I was saying was that the original poster shouldn't pick up on any buzz-word (like Java, .Net, PHP, or anything else) unless it'll actually help him code his application. If what he's been using is working out for him, my thinking went, he should stick with it and formulate a load-balancing strategy around it. Load balancing isn't going to force him to change his platform at all.

Let's all remain calm, ok? No disrespect intended to .Net, Java, or anything else.

Anyway, I barely even mentioned .Net in my post. Where did all this come from???

Re: Could someone explain instead of just flaming?

[crazyphilman]

Well, now, hang on a second. Some of your points are red herrings. For example:

* Most of your points seem to revolve around using session data for user sign-in to a services site. This is a pretty small use of session vars, and ok, I'll buy that that isn't going to hurt things much. But once people start using session vars, they start using them in all their user interfaces as well, including forms for collecting data. Which is where I was coming from with the hidden form posts. Setting that aside, if you want to handle user signin without sessions, what's wrong with a session cookie? It's not a third party cookie. It's not spyware. It's not persistant. What's the big deal? You think it's insecure? That's up to the programmer, isn't it?

* Using form posts doesn't have any effect on the back button -- PROVIDED you're not doing database inserts or updates on each page (which you really shouldn't be anyway, but if you feel the need to, you can handle this issue in a variety of ways).

* Using form posts doesn't kill "friendly URLs" (whatever those are) because any link can have an onclick method which sets the form's action and submits it. But if you're collecting user data, then you shouldn't have multiple ways off the page -- you should be in tight control of the way in which the user uses your app. Again, if you're just doing the sign-in thing, use a session cookie and you don't have to do form posts at all.

* If you're using a session cookie, the back button won't log you back in, because you'll have killed it in your code, right? So it won't be there when the user goes "back"...

* you can set up your pages so they won't be cached. Of course.

* You should ALWAYS doublecheck the user data, not only on the client side but on the user side as well. This is simply standard practice. So it's not an issue with what I'm saying.

* As far as overhead goes, I would agree with you that using an app server would involve more overhead than a single database call IF that database call was just a userid thing as you're saying. But we're talking about a broader subject, i.e. the use of session variables. This involves a whole lot more than sign-on; a lot of people put way too much in their session vars. Plus, you're mixing apples and oranges. The overhead of running a bigger server is one thing, thousands and thousands of hits to a database is another, no matter how little data you're fetching. On one hand, you're talking about RAM, on the other you're talking about RAM AND sockets AND bandwidth AND Ram on a database server, etc.

And, what's up with that comment about the form post data taking up bandwidth? What, a couple of kilobytes of plaintext in the extreme case? Gimme a break. Most will be a few hundred bytes. Relax...

Not to be shrill, but boy are people giving me a hard time about this one suggestion. Jeez, everyone's so in love with their session vars...

Re: Could someone explain instead of just flaming?

[budgenator]

As far as putting sessions in a database, boy oh boy, I don't like that idea much at all. Calling out to a database

There is not to much you can do without calling out to a database these days anyways, Java, PHP, Perl ect. all pretty much are all good at connecting to databases to the point we don't even think of it as unusal anymore. My guess is that having your servers properly configured and tuned, is going to make a bigger difference than language, database connection, or any other single factor.

Re: Could someone explain instead of just flaming?

[gregmac]

But once people start using session vars, they start using them in all their user interfaces as well, including forms for collecting data.

This sounds like you're talking about inexperienced progarmmers misusing session variables.. :p

but regardless, you're complaining about adding extra data? A 'small' query, for keeping user login information is ok, but anything else isn't?

* Using form posts doesn't kill "friendly URLs" (whatever those are)

Well, you were refering to using hidden fields to pass information. Not ALL page loads are POSTS.. which is what I was refering to. If you want to use a hyperlink to get to another page, and still maintain whatever information you're trying to maintain, you have to pass it in the url. What I meant by 'friendly url' was simply not having it full of variables. I think this is of particular importance on, let's say, a front-end catalog site (where you can browse around and have a shopping cart before you've logged in). If your URL is full of variables, then it (usually) can't be bookmarked, or sent to someone else.

* If you're using a session cookie, the back button won't log you back in, because you'll have killed it in your code, right? So it won't be there when the user goes "back"...

Well, no, I disagree. Now you're getting into what I meant by "security issues'. If your 'session' is controlled soley by the use of a cookie, sure, you can delete that cookie. But the user could also recreate that cookie (particularly easy using mozilla/firebird with the live headers extension). They could also modify it to do other things. perhaps change the userid and give themself access of another user.

To be fair, those are really all program design issues, and you did mention checking all user data. In my design, I never trust user data, and it's always checked. A good goal is being unhackable, even when you have the source and know all the values (this really goes without saying though.. so i shouldn't have bothered saying it really :) ). My solution to that problem is typically storing sensitive data on the server-side, using sessions. It's impossible for the user to modify them without using the interface, and the interface doesn't trust user data to begin with, so it makes it impossible to modify sensitive data in a way that's harmful. Perhaps there's a better solution, but I'm unaware of it.

You also complain about putting 'too much' in session variables, then chastize me for mentioning bandwith issues with storing data on the client-side. Bandwidth of the private 100mbit (or faster) network between the web and database server is precious, but the smaller pipe between the client and server, where you pay based on traffic, isn't?

Granted, it also adds overhead of requiring more RAM, resources, etc. But for the last few years, I've had the opinion that hardware is cheaper than programming time. I'd rather use the solution that is best suited to the job, than sarifice security or robustness just to save buying a stick of RAM. Of course, that can be taken to the extreme - You can put thousands of layers of abstraction and require huge arrays of computers to run it, and consider it 'good' design - but you have to rationalize where the line falls. And it usually follows the money. If you can make this great solution that reduces the load on the database server by storing things on client side (ignoring the fact that it costs more in bandwidth), but requires that you add in tons of extra security checks (programming time), instead of just using server-side variables and adding a bit more power to your db server (maybe you won't even need to do that initially), I don't think it's a good solution, since it ended up costing more money.

Re: Could someone explain instead of just flaming?

[crazyphilman]

Well, those are pretty good points, and I definitely see what you're saying. However, some shops can't afford to buy more hardware every time they roll something out, and we have to squeeze a little more out of what we already have. Even if we didn't, though, throwing tons of money and hardware on a problem goes against my grain; I tend to favor thrift whenever possible, and lean towards a more efficient solution that uses the hardware I've already got. This probably comes from the fact I work for the government, and we have more constraints than people do in private industry (especially budgetary constraints).

Form posts tend to keep all that user data on the browser side, which is a good thing; if you use SSL, the data is just on the user's machine, and relatively safe. You set your pages up so they can't be cached, and you're ok. The nice thing about this is that you have very little overhead on your side. It's not about the transfer, with text data it's not going to use up much bandwidth. It's about resources. As you agreed, when you're hitting a backend database for data that the user already "knows" (and should have in his browser) you're throwing away processor cycles and ram on two of your own internal machines (DB and web servers), and internal bandwidth as well. The form post trick only adds a little additional bandwidth to a request the user would already be making, and in my view this is much more efficient.

As far as logins go, well, you can put a login and password in the session without eating up all your RAM, probably, which would probably be secure. But I like the idea of a session cookie; it's true that you as the user can probably try to fiddle with your cookie, but I as the programmer can assume you're going to do that and do things to annoy and frustrate you. For example, I can concatenate your userid and password fields, add some garbage data to mess up the field lengths, then encrypt them before I put them in your session cookie. After several pages of form posts, during which I'm just checking to see if the cookie is there and hasn't expired, you might submit all your data. At that time, I decrypt and parse out the session cookie and check your login a second time. If your login doesn't work, sorry, no ticket to ride. I kick you out to an error message and let you start over. That's not bad, is it? And it's not that much programming... No resources are consumed on the server until you actually submit your data (where we're going to be using resources anyway). Kinda clean.

This is actually something I'm working on in one of my apps right now. I generally go on the assumption that my users would love to escalate priviledge, so one of my goals is to stymie them. It feels like playing checkers. I don't want to get jumped, so I double up on everything (like checking logins at beginning and end). I don't want anyone to be able to DOS me by loading up my server with session vars, so I don't use them (my pages tend to be mostly stateless aside from form posts). I don't want to slow down other people's apps (a lot of us share the same servers) so I keep my processing to an absolute minimum... Of course I'm under more constraints than you probably are, but no matter how much horsepower you have, faster is better, right?

Anyway, I do see your points. But you can understand why I'd lean towards my approach...

Yahoo!

[nocomment]

Well seeing as Yahoo is switching over to php, from C no less! Plus if you want to, you could use slashdot as an example of scripted sites. Of course slashdot at random interval won't load for about 10 or 15 minutes (rarely longer).

Re:Yahoo!

[kevin_conaway]

If you read the article, they mention the only reason they arent using Java is because FreeBSD doesnt have decent threads support. Perhaps if the major bulk of their systems ran a different OS, they might use j2ee?

Re:Yahoo!

[nocomment]

I read that, it doesn't _exactly_ say they aren't using it because of the threads but more like, they aren't considering it because of threads. It wasn't even an option to be included in the benchmark tests. Although if they weren't so stuck on FreeBSD they _might_ choose j2ee. That would be a big boon for Sun if they did :-)

Re:Yahoo!

[Elote]

Nope, yahoo is not currently serving with C, but a proprietary language written in C.

"We'll explore a case study of one company (Yahoo!) that is making the transition to PHP from a proprietary server-side page language written in C/C++."

from your own link

Re:Yahoo!

[vrai]

So basically Yahoo! are moving from an interpreted language written in C, to an interpreted language written in C. Woo hoo.

Re:Yahoo!

[tshak]

Plus if you want to, you could use slashdot as an example of scripted sites.

Funny you mention it, because while /. is reasonably well designed in most areas, I used it as a case study as to why applications should NOT use a scripting language. Yahoo was using an archaic language, so switching to a more modern scripting language will definitely benefit them. I just think that Java or C# would have been a better route for maintainability as their codebase grows.

Re:Yahoo!

[Anonymous Coward]

There's is absolutely no substance in your post.

None.

Zero.

Re:Yahoo!

[yomahz]

Well seeing as Yahoo is switching over to php, from C no less!

Well, changing from C to PHP is a big step in the right direction as far as scalability goes (I'm speaking of code maintentance, fault tolerance, resource pooling, etc) is concerned.

They are obviously going to have an easier time writting PHP webapps and services than C but I still think that J2EE would have been a much better choice in the longrun.

Their only reason for not going with J2EE was the poor threading performance in FreeBSD.

Re:Yahoo!

[Laconian]

They are not switching from C; they are switching from YScript!, a proprietary Yahoo language.

I think that the most highly evolved languages are the languages that are most likely to succeed. Check this article out, it describes how programmers at Viaweb leveraged Lisp as their secret weapon in the bidding wars for Yahoo. Lisp can be considered a scripting language, but it conquered all other forms of compiled competition in this case.

Anyways, I think that PHP's approach towards the integration of generated and static content smacks of previous-generation languages (namely ASP.) ASP.NET and JSP have evolved the paradigm, with their clear distinctions between compiled code and html. I find ASP.NET with C# to be SO much easier to maintain than the legacy ASP scripts at my company.

Also, it's nice being able to hand pages to the graphics design department without worrying about them deleting important chunks of code. It's a problem when they see the page icon in Dreamweaver and mistake it for a graphic. They hit "delete". There goes Important Function #3! Arrgh!

Re:Yahoo!

[bill_mcgonigle]

while /. is reasonably well designed in most areas, I used it as a case study as to why applications should NOT use a scripting language

Care to elaborate? Do you have some data to back your assertion?

Re:Yahoo!

[sporty]

Uh, yahoo creates cached pages. They dont' run php all the time. That'd be sick.

Re:Yahoo!

[edrugtrader]

uhh... no.

yahoo is switching over to php for SOME things, but the author of php (a yahoo employee) told me personally that the stuff that requires heavy crunching or that needs to be executed more frequently and can not be cached will still be done in a C or C++ layer.

Re:Yahoo!

[edrugtrader]

who the fuck moderated that as troll?! that is 100% truth you morons.

More importantly...

[CooCooCaChoo]

People compare PHP to Java. That isn't PHP's main competitor. The main competitor is ASP and so there fore, a better comparision would actually be between ASP/ASPX and PHP in regards to scalability. Once Mono is feature complete, then compare MS ASPX to Mono, then compare the two to PHP.

Once those comparisons are made, one can then decide whether the superior one is due to either the design/architecture or simply because one is better implemented than the other.

Personally, I find that both have a place depending on what you want to do. That is why there is diversity, because there isn't one product out there that is everything to everyone. Toasters for example all pretty much all the same. There is no difference between the taste of toast cooked in an elcheapo tiffany toaster vs and expensive Sunbeam, it is simply personal taste that dictates what is bought.

We can continue arguing which is superior but deep down inside every person here, things aren't done on technical superiority, it is done because the PHB got his creative juices following when he heard a marketer promote their "solution" over another.

Re:More importantly...

[boatboy]

You're half right, but confused on the .NET side. Mono implements .NET. ASPX uses .NET. .NET is not a scripting laguage, but is compiled to IL code either directly (in the case of code-behind) or by the web server on the first request (when code-behind is not used). ASPX, then, is more similar to Java than to PHP. PHP is, however, similar to ASP in that both are scripting languages. Thus a more accurate comparison would be ASP to PHP and .NET to Java.

I think the point of the article though, is that the lines blur somewhat. PHP may not be the same architecture as Java, but well-written can scale as well. I suppose you could make the same case for ASP compared to ASPX. Before ASPX, there were already people compiling ASP to dlls or writing data-access code in C to be used from ASP. What ASPX and Java do, though, is help you to use this good architecture. With PHP and ASP, you can completely ignore any notion of n-tier architechture. With Java and .NET, I suppose it's possible, but less likely that you would combine business, data, and presentation into one layer.

there is convergence

[Anonymous Coward]

PHP is a simple language complicating with every release and moving towards a scalable compiled architecture.

Java is a complex compiled language that scales well with J2EE and is moving towards a simpler design with technologies such as JSP 2.0 and JSF.

Which is better just depends on your viewpoint.

Perl

[rmohr02]

Perl seems to scale as well--it runs a very busy site I frequent with few problems.

Not exactly... [Re:Java owns PHP]

[quadelirus]

Have you used PHP?

I program a number of different languages. Java is my first love, and I know it better than any other, but both PHP and ColdFusion do an excellent job at writing very dynamic web sites. I'm not much of a PHP programmer, only becuase its something I do on my spare time, and not for work (we are a macromedia/windows shop unfortunately :'( ) but at least with CF its much easier to connect to a database than with Java, and I've heard argument that PHP is even better than CF.

Of course in CF, you write custom tags in Java...

Anyway, why write 50 lines of Java when 5 lines of PHP will do?

Re:Not exactly... [Re:Java owns PHP]

[Anonymous Coward]

Anyway, why write 50 lines of Java when 5 lines of PHP will do? Scalability!

Re:Not exactly... [Re:Java owns PHP]

[Captain Nitpick]

Have you used PHP?

Anyway, why write 50 lines of Java when 5 lines of PHP will do?

YHBT. YHL. HAND.

Re:Not exactly... [Re:Java owns PHP]

[mark_lybarger]

i've used PHP, and it's a bitch to debug and to understand in general. it's nice for script kiddies, but outside of that, i'd leave it alone. java isn't really a good tool for websites either though, at least not java's jsp. There's many nice templating engines available under java which are VERY nice for dynamic sites (velocity, freemaker, etc). Let java handle your business logic, and let templates run your user interface.

Re:Not exactly... [Re:Java owns PHP]

[Anonymous Coward]

Idiot.

Re:Not exactly... [Re:Java owns PHP]

[orionware]

Best tool for the job.. However, most folks are finding that jsp/ejb is rarely the best tool for 95% of apps..

The nice things about coldfusion:

1) It's java - stoopid...
2) First time thru the entire page gets compiled into bytecode
3) The quickest and easiest way to manipulate tables for a dynamic site:
4) Can write custom tags in CF/Java/C++
5) Can use existing java apps/code and invoke it in the page 2 lines of code...

<cfquery datasource="x" name="getStuff">
select * from table
</cfquery>

What happens is when a new tech comes along that is easy to use and easy to learn, we folks who toiled for years to become good progammers with Java and C++ get edgey that the noobs are taking jobs without paying the price..

Personally,programming is just a means to an end.. Learn whatever technology gets you paid...

Re:Not exactly... [Re:Java owns PHP]

[agwis]

"but at least with CF its much easier to connect to a database than with Java, and I've heard argument that PHP is even better than CF."

Class.forName("the driver").newInstance();
Connection con = DriverManager.getConnection("jdbc:database://host/ databaseName?user=username&password=password);

2 lines for Java, what's so hard about that?

-Pat

Re:Not exactly... [Re:Java owns PHP]

[quadelirus]

First let me say: i was playing devils advocate. I love Java, I don't use PHP. I'm new to Java Databases. I ran the installation stuff for MySQL to Java, it didn't throw any errors, I added the .jar files to my classpath and my IDE's classpath, I ran the above code, and it threw an error that Mysql drivers could not be found. Now I understand that this is because I am ignorant of the process and have probably done something wrong, however I was equally ignorant of the CF process and had no trouble configuring it. Again, I realize that this is because Java is a better/lower-level language than a cute little scripting language like CF (which actually compiles to JSP I think...), but the fact remains that with no experience in either I was able to get CF up in a matter of seconds whereas I now have to go do some reading to figure out how to get Java to connect to the mysql drivers.

Again, I am not trying to step on toes with any of my comments, I just find it interesting to see different sides of the issues, and sometimes that means playing devils advocate. I'm not a fan of PHP, I don't use PHP other than a script or two I wrote to test it. Java is my first love (well ok it somewhat conflicts with C++ but still...) and I choose to program in Java whenever I can (meaning convince those in charge to allow me to, or any time I need something done at home...)

Some facts

[vlad_petric]

1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem ... last time I checked, Java did considerably better than PHP in terms of both.

3. As PHP was not designed as a multipurpose language, sometimes a PHP-only solution is simply a kludge. PHP's power is in writing webpages quickly, if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy. Yeah, you can do that in C, but what's the point ?

Re:Some facts

[Anonymous Coward]

> Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

That'd be the definition of linear scaling. Scaling can apply to n, .5n, or other rates. So, saying X and Y scale at the same rate could they both scale at 0 (ie, adding machines have no effect).

Re:Some facts

[consumer]

PHP provides persistent connections, so the system does not need to reconnect to the database on each hit. It also provides various caching tools, like memcached. Charts and graphs are typically handled with third-party libraries. It's not exactly hard.

Re:Some facts

[vlad_petric]

But connection pooling scales much, much better than persistent connections ... Especially when each user makes only a couple of requests.

Re:Some facts

[Anonymous Coward]

if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy.

Huh? I keep seeing this claim, where did it come from? PHP has had native image processing for years. PEAR also has an imagemagick module. Nothing messy involving C at all.

Re:Some facts

[consumer]

Connection pooling only scales better if most of the time in your application is spent doing calculations or something without the database. If your app mostly is about accessing a database, then the connection will be constantly in use and there will be no benefit from pooling.

Re:Some facts

[Ian Bicking]

Besides the ability to inline PHP in static text, PHP isn't particularly bound to HTML output. It's not a specialized language -- ironically, it's a rather crappy language for generating HTML. It's quoting and substitution rules suck, it's regular expressions are a pain to work with (more quoting problems), and stuff like magic quotes are both insecure and unpredictable. PHP as a language sucks in lots of other ways, it was designed by people for which it was their first programming language implementation -- it's naively designed and it shows. But it sucks in a surprisingly multipurpose way, even for HTML generation.

PHP's runtime environment is tied closely to mod_php and the Apache environment. Mostly no one cares enough to change that, I suppose, because it's not that fundamental of a design.

Re:Some facts

[Frostalicious]

Connection pooling only scales better if most of the time in your application is spent doing calculations

In the majority of applications, most of the time is spent idle waiting for the user to do something. If you are holding a DB connection during this period, that is extremely wasteful.

Re:Some facts

[namespan]

1. Scaling != performance. Scaling simply means that if you multiply the hardware by n you should be getting (ideally) close to throughput *n.

Isn't this just the same as saying "scaling" means that the software uses the hardware efficiently -- which would then be true for both PHP and Java to similar degrees?

2. DB is the bottleneck for most websites. A good connection pooling and caching system are critical. Ahem ... last time I checked, Java did considerably better than PHP in terms of both.

You know, I was going to respond to this, but then I realized I didn't know what connection pooling actually means....

Re:Some facts

[Anonymous Coward]

You know, I was going to respond to this, but then I realized I didn't know what connection pooling actually means....

Thanks for that insightful tidbit.

Re:Some facts

[djcatnip]

if you want to do, for instance, something more complex like charting in a web page (well, in a .PNG), things can get messy.

You must not have tried very hard to look for anything.

go check out jpgraph.

Re:Some facts

[Anonymous Coward]

memcached was written originally for Perl. It was designed for LiveJournal.com, and that's written in Perl. It has a PHP API true, but to credit it to the PHP community is a falsehood.

Re:Some facts

[crazyphilman]

Connection pooling means, basically, that the server sets up a pool of already open connections to a database, and your app can borrow a connection from the pool when it needs to interact with the database, then release the connection back to the pool. It's a performance trick, because opening a connection and closing it eats up resources, so you open up all the connections at once and leave them open, and they just handle requests which is less resource-intensive. I haven't had much need for it myself, but I've read about it...

Re:Some facts

[Thrakkerzog]

100 connections == 100 connections with persistant connections.

If you were pooling, you could limit it to 25 connections and have each of the requests which actually use the database grab a connection from the connection pool. If you reach the limit, you can have the method which grabs the connection block (with a timeout for when bad things happen).

It is much more efficient than persistant connections. You can't flood the database with queries, either.

Re:Some facts

[pmz]

connection pooling and caching system

For a team of inexperienced programmers, pooling and caching are debugging nightmares. I've seen first hand where a pooling problem surfaces, does not get understood for what it is, and the programmers either go off on some witch hunt among themselves or start implementing terrible band-aid solutions everywhere.

Pooling and caching should probably not be included at the beginning of a project. If the database abstractions are properly implemented, adding pooling should be trivial later on if performance studies warrant it.

Pooling is an optimization and _not_ an architecture.

Re:Some facts

[Anonymous Coward]

Wow...you are so wrong. You want to hold a db connection while a user reads a web page, fills out a form, goes to the bathroom or goes away and never comes back.

Every web application that accesses a database needs a connection pool. DB connections are expensive and should not be wasted.

Re:Some facts

[consumer]

The amount of load when the application is idle doesn't seem like a terribly important issue. It's the maximum load that the application can handle which is under discussion here.

Re:Some facts

[markus_baertschi]

Just take a look at the error message of the typiccal slashdotted PHP-website. It's all about some DB-connection error. Java with good connection pooling handles this much more graceful - the site gets slow, but it still works.

Markus

Re:Some facts

[namespan]

It was actually a question, with which I hoped to be (and was) rewarded with an explanation.... and maybe mocking. Lots of mocking.

Re:Some facts

[MikeFM]

I use Python for the application logic and PHP for the display logic to set up a three-tier system. I use load balancing between the client and the display logic machines and another between the display logic machines and the application logic machines. I let the layers talk to each other with requests passed with HTTP. You can drop in as many machines at those levels as needed which IMO indicates good scalability. You can even use normal web caching methods between layers.

The DB is the bottleneck but I don't see there being any problem with connection pooling or caching if you set things up well. Usually I use MySQL as the DB anyway so it's pretty quick. As needed I also use other DB's and they seem to work well also. I've yet to run into a situation where the DB was a major problem on performance unless somebody used a really bad query.

PHP can produce graphics fairly easily as can Python. Both use libaries written in C to get the job done. You'd have to be doing something really special to need to resort to homegrown C. What's that have to do with scalability anyway?

Re:Some facts

[consumer]

Again, this is only useful if you have a lot of requests that don't use the database at all. In most web apps, the time spent outside the database is very short.

Re:Some facts

[Anonymous Coward]

Um, memcache is language-generic, and has a java api available.

Re:Some facts

[Wraithlyn]

This article is just way too simplistic. Saying "PHP scales" doesn't mean anything at all.

Sure, I believe it CAN scale well, if implemented efficiently, for certain purposes, like serving web pages. Go to town.

However, when it comes to things like high load networking, Java (with NIO) has it beat handily.

I recently worked on a system that had PHP scripts polling thousands of Internet servers. This is NOT something you want to use PHP for. It was choking to death on their production dual 2.4 Xeon. I rewrote the polling engine in Java, and now it runs on a PII400 test box with 30% load, and I haven't even gotten to any memory optimizations. (ie object pooling)

The moral of this story boys and girls, as always, is that no one tool is going to fit every need.

Re:Some facts

[Frostalicious]

The amount of load when the application is idle doesn't seem like a terribly important issue

OK are we talking about a multi-user application? I am.

We must understand the difference between one user being idle and the whole application and DB being idle. When one user is idle, if that user holds an open DB connection, that needlessly ties up resources that other users could be using. Surely this is quite evident.

Re:Some facts

[consumer]

When one user is idle, if that user holds an open DB connection, that needlessly ties up resources that other users could be using.

Again, we are talking about the MAXIMUM that the application can handle, not whether resources are "wasted" when the application is not being used at full capacity. And we're not talking about users either. Users don't get their own db connections, but server theads/processes do. In an application at maximum load I would not expect there to be idle threads.

Re:Some facts

[Frostalicious]

Again, we are talking about the MAXIMUM that the application can handle

Let me quote the original post that you replied to, in order to determine what we are talking about

But connection pooling scales much, much better than persistent connections ... Especially when each user makes only a couple of requests.

We are talking about scaling in a multi user environment. This concept which you refer to "MAXIMUM the application can handle" seems to assume that every single user performs some function simultaneously. Such a scenario, in a typical application, simply does not occur. When designing a high performance multi user application, you must consider the resources tied up by users who are not currently active.

If you are referring to a specific and unusual kind of software where these principles don't apply, please tell me what kind of application you work on where users are never idle.

Re:Some facts

[consumer]

This concept which you refer to "MAXIMUM the application can handle" seems to assume that every single user performs some function simultaneously.

The simultaneous function here is making a request to the web application. Most web apps will need to contact the database somewhere here, and most of the time spent handling the request will be spent talking to the database. If some threads/processes are not being used (and thus not needing a db connection) then the app is not being pushed to it's maximum. In other words, relinquishing a database connection is only a win when you have idle threads/processes, or your app does time-consuming things that don't involve a database connection. You won't have any idle threads if the app is being pushed to the limit of its scalability.

Re:Some facts

[weatherboy]

What? You have Python and you're not using Cheetah Templates for your display logic?

Simplify, man, simplify.

Re:Some facts

[Frostalicious]

relinquishing a database connection is only a win when you have idle threads/processes

Right, and since in between page requests, the user is idle staring at their screen, and considering your original assertion "PHP provides persistent connections, so the system does not need to reconnect to the database on each hit", then there will be persisted idle database connections in between requests, which could be allocated to something useful.

Re:Some facts

[MikeFM]

Why would I do that? PHP is a good templating language and is cleaner than any template library I've seen. Probably the most flexible too. Might as well pick the ebst tool for the job. Python is better for application logic and PHP is better for templating. Using different languages also makes it easier to keep template and logic sepperate as there is no easy way for them to gradually merge. Finally the major benefit of using PHP for templating is that lots of people know PHP. I'd much rather let someone else deal with layout issues and communicating with the browser so it helps if I use a template language that is well known.

Re:Some facts

[Anonymous Coward]

Disagree. I've seen a lot of inexperienced ASP programmers over the years, and not a single one has any huge conceptual problem with connection pooling (which is built-in and automatic in the ASP environment). The biggest problem tends to be that they don't know that the pooling exists and try to build their own with a session object or something.

Re:Some facts

[Anonymous Coward]

Are you that dumb or are you a troll? Which is it? The way you carry-on with that horrible misunderstanding shows that one or the other is true.

> there will be persisted idle database connections in between requests

Other connections from other users will use those connections. The connections aren't tied to any particular user. Why in the hell are you claiming PHP has processes sitting around doing nothing waiting on output from a particular user? On the next hit, the already open connection will be used.

Besides, this is a non-issue. The number of connections used isn't important when you use a fast SQL server like MySQL. You can hold hundreds of idle connections without causing any performance problems even on modest servers. Our C GUI programs often hold close to a thousand open connections to our main MySQL server at 4 PM each day without problem. The programs are separate processes and often on different systems and usually using different db logins so there is no way to pool connections.

Re:Some facts

[xneilj]

Indeed. I had to have a quick scan to make sure somebody was going to at least mention JPGraph, if only because its existance reduces that particular argument to nothing. JPGraph is extremely powerful and very flexible. It's also easy to learn/use.

Re:Some facts

[Frostalicious]

Why in the hell are you claiming PHP has processes sitting around doing nothing waiting on output from a particular user?

Because you said so. I know nothing of PHP but was relying on you saying that (and I quote) "PHP provides persistent connections, so the system does not need to reconnect to the database on each hit". I see now that you mean database hits, not webserver hits. Apparently you know what you are talking about technically, but you have piss poor English skills, so goodbye.

Re:Some facts

[Anonymous Coward]

> Because you said so.

I never said that. Why would you say that I did?

> I know nothing of PHP...

Then why are you making such wild claims? If you don't understand how it works, then why are you ranting on and on about how it doesn't work? PHP topics on /. always seem to bring-out a lot of trolls.

> you saying that (and I quote)...

I never said that. In my PHP3 book, I said "PHP provides persisten connections, so the script does not need to reconnect to the database on each execution." Close, but not quite what you claimed I said.

> you have piss poor English skills, so goodbye.

What are you upset about? I didn't see anything in my post that you could have complained about wrt to English.

Re:Some facts

[Frostalicious]

Holy crap, I need to pry myself away from this shit . I'll give it one more post because you have really pissed me off with your refusal to see what I am saying, and your inability to see what even you have said.

> Because you said so. I never said that. Why would you say that I did?

Because you did, in this post which I quote in it's entirety.

Re:Some facts (Score:3, Informative) by consumer (9588) on Friday October 17, @12:24PM (#7240637) PHP provides persistent connections, so the system does not need to reconnect to the database on each hit. It also provides various caching tools, like memcached [danga.com]. Charts and graphs are typically handled with third-party libraries. It's not exactly hard.

I'm arguing with Bagdhad Bob here. What you should have said, which would have produced a much more intelligent conversation was "PHP persists database connections over the life of the page execution."

I never said that. In my PHP3 book

Nobody mentioned your book. If this is a tactic to gain some kind of credibility, it should fail as most books are crap.

> I know nothing of PHP... Then why are you making such wild claims?

I have made ZERO claims regarding PHP. You just made this up, pulled out of your ass if you will. I only responded to your claim of persisting database connections. That is not a language specific issue. My posts assert one thing and one thing only, persisting database connections in session scope (over several page views) is a waste of resources. I don't see how language choice can change that fundamental concept.

> you have piss poor English skills, so goodbye. What are you upset about?

I'm pissed because you made a vague claim about persisting database connections (see quote above). I misunderstood your claim because of the vague wording. You quickly realized I misunderstood, but instead of clarifying, you turned this into a flame fest. All you had to say was "persist over the life of the page execution". When you say "persist" you have to qualify that. You can persist to disk, you can persist to application scope, you can persist over function calls etc...It took me 5 seconds to come up with that more specific phrase. Surely you could have mentined it once in your last 5 posts.

You can reply, but I wont. Please understand a priori, that I consider any replies to this misguided due to your inattention, and I stand by every one of my statements in this post.

Re:Some facts

[consumer]

No, when the user is idle nothing is being tied up. The process goes on to handle another user's request, with the same database connection. The only time a process is idle is when the application is not being fully used. It has nothing to do with what an individual is doing, and everything to do with the total number of requests being sent in at once. And, it has nothing to do with scalability. Scalability is about how many simultaneous requests can be handled in a period of time, not about how the application behaves when half of its processes are sitting there idle.

Re:Some facts

[gutu]

PHP's best asset is it's integrability to the HTML, however Java and Webmacro are a superior combination if system is not purely web-based, like a discussion forum.

Re:Some facts

[Anonymous Coward]

I rewrote the polling engine in Java
And why did you see a need to rewrite? Because of a bad algorithm? A bad algorithm is a bad algorithm no matter what language you are using!

Rewriting one piece of code in another language doesn't proof anything. I can show you code written in Delphi that outperforms Java. Does that make Delphi superior?

The moral of this story boys and girls, as always, is that no one tool is going to fit every need.
I totally agree.

Re:Some facts

[clare-ents]

Okay, so we have persistent connections so that each apache process holds on to a database connection to speed up database queries.

a: Why does an apache process serving an image/pdf/whatever need to hold on to a database connection?

b: What happens when the number of apache processes becomes larger than the number of database connections?

c: Why are neither of these a problem with connection pools?

Re:Some facts

[consumer]

In a high-traffic environment, you typically send requests for static files to a separate server or use a reverse proxy setup. There is no point in having more apache processes than you can have database connections, since a process without a connection can't actually handle a request. You tune this with MaxClients and let the OS queue up any requests that go over that. There's nothing wrong with connection pools, but you are overestimating the real need for them, as opposed to just persistent connections.

Re:Some facts

[Betcour]

Actually it is too powerful, whenever I use I feel guilty for not taking advantage of all the options and settings :(

Re:Some facts

[Betcour]

Rewriting one piece of code in another language doesn't proof anything. I can show you code written in Delphi that outperforms Java. Does that make Delphi superior?

Err, considering Delphi is compiled and use the same compiler-backend as C++, it really should perform a lot faster than any Java solution when using the same algorithms.

Re:Some facts

[Anonymous Coward]

> Because you did, in this post which I quote in it's entirety.

Learn how to read. I did not post the quote you claimed I did. Again, why are you claiming I said that? I didn't. Do you really have that much trouble reading the difference between different users?

> I'm pissed because you made a vague claim about persisting database connections

Again, why are you claiming that I made that claim? I didn't.

> Surely you could have mentined it once in your last 5 posts.

I haven't made 5 posts under this topic. Where do you come-up with this stuff?

> instead of clarifying, you turned this into a flame fest

Why would I be responsible for clarifying someone else's post?

Re:Some facts

[Wraithlyn]

Geez.. my point was simply that SOME tools are better than others at SOME things.

I'm not trying to "prove" that Java is superior to PHP. But in my experience, Java handles high load network IO and multithreading better. And I'm sure there's things that PHP is better suited to than Java.

I only included an example for context, it was never intended as "proof" of anything.

Re:Some facts

[edrugtrader]

i have a function in php that i pass in values, names and a few parameters for the chart (scale, color, type, etc) and it generates and spits back the path to a brand new .PNG (or .GIF or .JPG or .BMP....)

is one line of code too "kludgey" for you?

if you do anything in C, there is a speed increase. THATS THE POINT.

No way Jose

[Anonymous Coward]

What a load of crap...
PHP is an awesome and very useful language...but when it comes to scaling...no way.
Want facts? Go look at PHP Nuke vs JBoss' Nukes. Nukes was a Java rewrite of PHP Nuke. They did it because PHP didn't scale very well at all.
Read about it here: JBoss Nukes
and here
O'Rielly Article on Nukes

Here's why...

[jbottero]

Programmers generally pooh-pooh languages that common folk can understand and use. VB is a very powerful language that many people use to build enterprise class applications, but an idiot can understand and use it as well. The result? "VB SUX". And as an example, a C programmer is essentially a God, and don't even think about reminding people here at Slashdot that Perl has been dead for a few years. But show off something better and easier? Sacrilege.

Re:Here's why...

[sporty]

no.. perl is really really easy to program in. same w/ pyton and ruby. basic as well. Problem with VB and php are they were badly designed yet widley used as an all purpose solution.

For instance, I worked on a company that shunned java thinking it'd never get big, and promoted php. When things started to go awry because php didn't scale w/o some obtuse compiler. Then there were things like the error messages you got back. Once, php had a problem with number of includes (not memory size, just # of includes).

Same thing with VB. There were little quirks in it that made it so dog slow, but "commercial apps" were written in it.

Now lets step back and look at java. Java only has a slow startup time, just like netscape. It has it's set of issues. But you can easily work around them by using different methods. SWT is (I think) based off of JINI so you that IBM created it's own native widget set. If I didn't like swing? I could create my own widget set with the language.

PHP and VB didn't create languages first. They created solutions first and then tried to backport to everything.

Re:Here's why...

[sporty]

When things started to go awry because php didn't scale w/o some obtuse compiler.

They had to use some obtuse compiler.

Mental blip.

Re:Here's why...

[jbottero]

"Problem with VB and php are they were badly designed yet widley used as an all purpose solution."

All words, no substance. Back it up, bro.

"php didn't scale w/o some obtuse compiler"

The Zend compiler is obtuse? Get a grip. GCC is obtuse.

You ramble on and on without making any point. PLEASE HAVE ANOTHER TOKE AND GO BACK TO BED.

Re:Here's why...

[AstroDrabb]

VB is a very powerful language that many people use to build enterprise class applications

Oh my gosh, my side is splitting from laughing so hard. You have no clue what enterprise class means. I am a developer for a fortune 500 company with 110,000+ employees. VB does not scale. VB does not even do true threads. It only supports apartment threading. VB does not support one ounce of object oriented programming. A class in VB is NOT a real class. It does not support polymorphism, inheritence, etc. Try to write an large enterprise class application with many developers in VB and then you will know what I am talking about. Once an applications gets to so many thousands of lines of code, OO techniques become invaluable. VB is procedural and just doesn't cut it. VB is for kiddies or as Billy boy would say, "hobby" programmers. Can I create a class and inherit from it? No. Writting an application with a few thousand lines of code with maybe five developers does not make it enterprise class. The file handling is a joke. The syntax is joke. VB came in handy for a quick way to plan out a GUI. Plain and simple. Please tell us what "Enterprise" grade applications you have made with VB? Hell, name one "enterprise" grade application available in VB? Is SQL Server written in VB? Is Oracle?

and don't even think about reminding people here at Slashdot that Perl has been dead for a few years.

Are you even a developer? Comments like this make me doubt it. Look at the URL when you are in /. See that nice .pl on the end? That is perl. It is pretty funny that /. running perl can handle the load that many other sites out there just crock on, hence the term ./ing. There are still tons of perl sites out there. Perl is also indespensible when it comes to text processing or admin related tasks. Just because you don't have the ability to learn any language other then VB, doesn't me the rest of the world can't.

But show off something better and easier? Sacrilege.

Thats part of the problem right there. If you dumb down a language too much such as VB, you loose all the power features that comes with a language such as C, C++. It also contributes to all the headaches in the world of IT when you have tons of piss poor code written by sup-par "programmers" that cannont grasp anything harder then VB. Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make.

Re:Here's why...

[sporty]

Ah, the old attack and make invalid points scheme. I see how it is.

Well, if you didn't know, VB and PHP are programming languages written by MS and Rasmus themselves. Over the years, they've gotten quite popular, so popular, that yahoo, blackplanet.com, asianavenue.com use for instance.

The php compiler is obtuse. It requires a quirky recompile that taps into the internals. It's not built in a way that you can upgrade one or another.

So in closing, you are a friggin moron, and.. uh.. you smell like pubes. There, I think i've evened out to the age level of your post.

Re:Here's why...

[Anonymous Coward]

Ah, yes, the old trolls:
"If you can't write Oracle in it, it sucks!"
"Slashdot is written in Perl therefore Perl is great!"
"VB is the downfall of IT!"

Seriously, you have some good points, try not to sink them by being a ridiculous clown.

Re:Here's why...

[epfreed]

Speaking of slashdotting, I've often wondered if slashdot itself can survive the effect due to design, server size, or something else. Now as a Perl fan (though I am a sysadmin, not a programmer per say), what about Perl do you think allows it to handle the slashdot loads--and that is an honest question.

Re:Here's why...

[Anonymous Coward]

VB does not scale. VB does not even do true threads. It only supports apartment threading. VB does not support one ounce of object oriented programming.

um... have you heard of this new ".Net" thing Microsoft has been pushing? VB.Net is actually objected oriented. You can derive from other classes (even ones not written in VB.Net), and all that other good stuff. Does threading too. Not saying I'm the worlds biggest VB fan. Just get the facts straight before you sound off like a dick.

Re:Here's why...

[mikeg22]

We have a 500,000+ line VB project that is very GUI intensive and it works/scale quite well. OO is good for some applications, but its more work than its worth for others. There are places in our project where having inheritence would be very helpful, but we have designed around this limitation. Threading for would have limited use as well. The ease of the GUI building more than makes up for the threading and OO limitations, at least in our project.

I'm not sure if your post was a troll or not, but it is pretty arrogant to assume any one language, especially one as widely used as VB, is for "kiddies."

Re:Here's why...

[Deacon Jones]

I am a developer for a fortune 500 company with 110,000+ employees
and

Can I create a class and inherit from it?
So your Fortune 500 company obviously hasn't heard of VB.Net, I take it?
I have no dog in the language semantics fight here, but most of your points are valid pre-.Net days, which means your points are invalid.

Re:Here's why...

[Deacon Jones]

and i can't close an italics tag, apparently.
Sigh.

Point is, you're wrong. Thank you.

Re:Here's why...

[Slime-dogg]

500,000+ lines, eh? If you had written that same application in Java or VB.NET, how many lines would you have saved?

The GUI builder for VB is severely lacking too. The only option you have of building components is to embed an existing component, and then write some VB glue around it. The other choice you have is to write an ActiveX control in VC++ or Delphi. I bet a majority of that code is spent setting sizes upon a form resize event, making up for form scaling that is standard in every other IDE package, setting on/off values in a grid, binding data to grids, yada yada yada.

If you were working with an OO language with a decent IDE, that program would probably have been cut to around 200,000 lines of code, if not less. Inheritance is a very powerful tool, but it is something that is not understood very well by your standard VB programmer.

Another portion that springs massive amounts of code to life is VB's lack of good error handling. In order to catch errors, you have to use a fricken GOTO statement. Who the heck uses GOTO statements in higher level languages anymore? It's considered bad style for God's sake. The error handling is so bad that once an exception is handled, there's no going back to regular execution within the same function/procedure unless you write it all over again in the handler, or you call the function/procedure recursively.

Yet another problem with VB is the lack of run-time designing. Another is the limit on the number of controls that go on a form. Another is the shitty menu editor. Another is .... You get the picture? VB is not meant to be used in any sort of enterprise environment, but it is sold as such by MS because they make money off of it. There are plenty of PHB suckers out there who glom on to buzzwords. VB was one of the buzzwords.

Fortunately, VB has been put to sleep.

Re:Here's why...

[kilimangaro]

Are you even a developer? Comments like this make me doubt it. Look at the URL when you are in /. See that nice .pl on the end?

Huh... ? I see a .shtml. Sure that this file was generated by some perl script, but i can do the same with almost any other language...

That is perl. It is pretty funny that /. running perl can handle the load that many other sites out there just crock on, hence the term ./ing.

There is no link with perl or VB or any other programming language. Its just mean that there is some very good hardware behind /. and many other sites dont have server farm or was designed for handling over 100 request per second.

Re:Here's why...

[cjjjer]

hence the term ./ing.
Dot-Slashing?

It does not support polymorphism, inheritence, etc.
You must mean it does not support implementation inheritance right?

Re:Here's why...

[Anonymous Coward]

> hence the term ./ing

Dude, ./ing happens to Perl sites too. Language is a small part of scalabitility. Software design and hardware are the other 90%. Just because you're saddled with a raft of VB crap doesn't mean the language bites...sounds also like you're using VB4 or something.

Re:Here's why...

[Blob Pet]

I see a .pl.

http://developers.slashdot.org/comments.pl?sid=8 26 22&threshold=1&commentsort=0&tid=169&mode=thread&p id=7240837#7241482

Re:Here's why...

[shaitand]

Someone else replied to you with alot of the technical reasons. But if you remember vb was meant for home user scripting of the GUI. It was initially released as a counterpart to Applescript... not to real enterprise and systems level languages.

VB was the followup to qbasic. vb is just a gui upgrade to qbasic and let's not forget what basic stands for "Beginners All purpose Symbolic Instruction Code". Basic is a language designed to be used by those wanting to learn programming concepts, it was NEVER intended for production use. The only reason vb started being touted as a REAL programming language is because lots of lazy programmers and wanna programmers who couldn't figure out C started writting applications in it.

Re:Here's why...

[shaitand]

"Huh... ? I see a .shtml. Sure that this file was generated by some perl script, but i can do the same with almost any other language..."

not I, I see http://developers.slashdot.org/comments.pl?(lots of crap being passed to the script)

Not sure what url your looking at.

Re:Here's why...

[shaitand]

Do you think if you REALLY told your boss that you were an expert at programming in "Visual BEGINNER'S All-purpose Symbolic Instruction Code", that he'd consider you an expert for long?

Re:Here's why...

[mikeg22]

500,000+ lines, eh? If you had written that same application in Java or VB.NET, how many lines would you have saved?

We are soon going to be porting it to VB.NET. I don't know how many lines it would take to write this application in Java, but when this project was started, Java was out of the question. The GUI aspect of Java was simply not mature enough for our needs, and finding good/seasoned Java developers was much harder than finding good/seasoned VB developers, at least in this area. The VB IDE is also very functional, and takes a lot of the pain out of the process for our developers.

If we were to rewrite this project from scratch, VB.NET would most likely be the language we would do it in, with Java coming in a close second...but that is not going to happen.

I don't understand this blind hatred of VB. It certainly has its uses and its limitations. Is it that its a Microsoft language? All I can tell you is that, yes, we have a very well written 500,000 line project currently in production at a mid-sized (500 employees) company. Yes, it works fine.

Re:Here's why...

[kilimangaro]

I see a .shtml when im not logged (delete cookies) http://developers.slashdot.org/developers/03/10/17 /1423241.shtml?tid=108&tid=126&tid=156&tid=169

Once logged, we got a .pl
This is logical since the majority of ./ visitor are anonymous users, the CPU time is saved for logged user

Re:Here's why...

[Anonymous Coward]

um...VB.Net is closer to Java than it is to VB.

Re:Here's why...

[Anonymous Coward]

The only thing that VB and VB.Net have in common is the name. Exageration maybe, but there is a lot of truth in it.

Re:Here's why...

[Anonymous Coward]

> such as VB, you loose all the power features

Huh? What's the difference between loose features and tight features? I sounds like you're just making stuff up as you go along. How about going somewhere else you troll.

Re:Here's why...

[Anonymous Coward]

What kind of a fool are you? VB is a dead language that no one other than hobbists use. Using VB in an enterprise setting is like pouring gasoline on you and lighting a match. VB is syntactically ugly, inherantly type unsafe and anything you do in VB can be done easier in other languages like Perl.

Re:Here's why...

[sheldon]

I work for a Fortune 500 company as well, and one of our major web apps is written in a combination of ASP, VB and C++.

It's not clear to me that object oriented programming is a criteria for enterprise applications. Many of our big enterprise apps still use COBOL.

This all depends on how you define scalability, and what the app does. On our app, the web, business logic and data tier is all in VB, the calculation engine is in C++. We use Oracle as a back end. It handles the volume, for now.

Does it scale? Well, that all depends on your definition. Right now we have like 36 two-proc servers handling the load. It scales horizontally, just like PHP in this example.

For the past year they've been rewriting the whole app using C#, and it's almost done. During testing they've been able to handle the same load on four 8-proc servers, which is a bit easier to manage than 36.

"Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make."

It depends. The C++ part of our app costs 4 times more to maintain than the VB part. It may be worth it, it's hard to say. I'm just glad we now have options like Java and C# out there, so I don't have to beat my head against the C++ wall.

Re:Here's why...

[nighty5]

maybe its just me, but theres a possibility he was joking...... :)

Re:Here's why...

[AstroDrabb]

You can make just about any web app in just about any language scale. You can by Cisco content switches that load balance between many servers. If you have 100 webservers, even an old CGI could scale. Most big sites are not scaled out by choice of language, but by choice of the architecture.

Re:Here's why...

[AstroDrabb]

How does the app run? Does it run on individual desktops? If so, then how is that scaling? Just about any language and app can "scale" if you throw enough hardware at it.

I'm not sure if your post was a troll or not, but it is pretty arrogant to assume any one language, especially one as widely used as VB, is for "kiddies."

Yes, that was a little trollish and I do appologize. However, I have met and worked with too many people that only know VB and or VBScript and the majority of them have had very limited knowlege of how to really program outside of that realm. The majority also had no clues how to design a large scale application, and would just code in a procedural fashion. I am thankful that I don't have to touch VB again. I just personally think that C, C++ and Java are superior, well rounded languages.

Re:Here's why...

[AstroDrabb]

Yes we have heard of VB.Net. We just finished a very expensive evalution of Java/J2EE and .Net. We did our own evalution and had 3 independent evalutions done. One was by MS. Everyone selected Java as the superior platform (except for MS of course) for security, scalabilty, roubustness. Java has been around longer and has stood the test of time and proven to be a great choice while, .Net has not. Also, .Net would have locked us into just MS which would have been a bad choice.

Re:Here's why...

[AstroDrabb]

Here is the URL for your comment that I am replying to. http://slashdot.org/comments.pl?sid=82622 The .shtml is a HTML file with some server side includes. Not every page needs to be dynamically generated by mod_perl, hence the .shtml.

There is no link with perl or VB or any other programming language. Its just mean that there is some very good hardware behind /. and many other sites dont have server farm or was designed for handling over 100 request per second.

I agree with this. Just about any language and any application can be made to "scale" if you throw enough hardware at it.

Re:Here's why...

[AstroDrabb]

Dot-Slashing?

That is called a typo.

You must mean it does not support implementation inheritance right?

You know as in a C++ or Java class inheriting a base class such as:

class foo {
public void bar() { System.out.println("bar"); }
}

class foo2 extends foo {
public static void main(String[] args)
{
foo2 f = new foo2();
f.bar();
}
}

What are you a spelling Nazi? Or just anal?

Re:Here's why...

[Anonymous Coward]

"Enterprise" quality software (what a fucking buzzword..) has been around long before your precious Java, Perl, and OO languages. It's the shitty programmer who complains when you take away the one tool or methodology he knows. A decent programmer could program something decent in VB. The language isn't complete shit, you know.

Perl is for hack stuff. It's a nice tool to get a quick job done or something simple that's fairly portable. Was Oracle written in Perl? Was SQL Server written in Perl? Was an OS written in Perl?

Re:Here's why...

[AstroDrabb]

I work for a Fortune 500 company as well, and one of our major web apps is written in a combination of ASP, VB and C++.

Thankfully where I am we have a mixed environment with Solaris, Linux and Windows servers so we are not stuck in the MS only nightmare, though it still shows its ugly head.

It's not clear to me that object oriented programming is a criteria for enterprise applications. Many of our big enterprise apps still use COBOL.

I worked on a COBOL app once about 6 years ago. That was the last time I would ever touch anything done in COBOL : ). I guess I would work with COBOL if it was to port to newer techonolgy.

I'm just glad we now have options like Java and C# out there, so I don't have to beat my head against the C++ wall.

So am I. It does take away some of the ugly aspects of C++. Though I personally would not want to touch .Net since it locks you into one platform.

Re:Here's why...

[pyrrho]

>Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make.

I see you've been the the Sears Auto Center.

Re:Here's why...

[Doctor Faustus]

Another portion that springs massive amounts of code to life is VB's lack of good error handling. In order to catch errors, you have to use a fricken GOTO statement. Who the heck uses GOTO statements in higher level languages anymore? It's considered bad style for God's sake.

It uses the GOTO keyword, not a GOTO statement. The choice of keyword was unfortunate, but they really don't have much in common. "On Error Goto Handler" is really more like an event-driven GoSub.

The error handling is so bad that once an exception is handled, there's no going back to regular execution within the same function/procedure unless you write it all over again in the handler, or you call the function/procedure recursively.

That's just plain not true. "Resume 0" will take you back to the line that failed, or "Resume Next" will take you to the line after it.

Speaking of that, is there a way to resume normal execution in a Java try-catch-finally group? I've never figured out how to do it.

Re:Here's why...

[Doctor Faustus]

Java has been around longer and has stood the test of time

Not really. MS denies it, but .Net is basically Java with six years of hindsight included in the first version.

As for standing the test of time, from my experience, Java seems to have more backward compatibility kludges in the libraries (where they ought to be avoidable) than VB (6 and prior) does throughout the language, and Java is only supporting back to 1994, while VB is supporting back to 1975. I do have a lot more VB experience than Java, but I don't think you're going to find many people who can comment expertly on both.

Also, .Net would have locked us into just MS which would have been a bad choice.
Yes, there you have a point. If Sun goes under, you still have IBM, and I think a couple of others.

Re:Here's why...

[L1TH10N]

Porting a VB app to VB.NET hey... Good luck! I think that when Microsoft was developing .NET they focused on the ASP.NET stuff and forgot about window app development. There are many bugs and here are some examples:

The Grid control is extremely buggy and cumbersome to use if you want to do anything fancy like highlight a column. If you want you application to use a grid then buy third part software.

Try doing stuff using the combo boxes or list boxes. They do not work properly if you are using "DataMember" and "ValueMember" properties.

Try duplicating a DataTable with a column that has an expression. I believe this was fixed in Framework 1.1 but in the Framework 1.1 try using an MDI window with more than 4 child windows.

Try loading data from an XML file into a dataset which has expressions. This again was meant to be fixed in Framework 1.1 but again the MDI problem.

These are some that I have come across, but I bet there are an incalculatable amout out there. This is typical of Microsoft, develop for the most profitable market segment and make a half-arsed attempt at covering other market segments. Do something that they design the product for you spend x effort. Try to do something different or innovative spend 100x effort. For all intents and purposes you might as well move your windows app to ASP.NET because you will have a heck of a time using the windows .NET stuff.

Re:Here's why...

[Doctor Faustus]

No, there actually was a point in there, even if he or she was a bit too cryptic about it. I was about to say the same thing, so I'll elaborate here:

Java has two kinds of inheritance: full inheritance including implementation, like in C++, using the "extends" keyword, and interfaces, which support polymorphism but require you to write the implemention code anew.

VB 5.0 and 6.0 (maybe 4.0; I don't know) include interface support, so polymorphism actually is supported.

Re:Here's why...

[Doctor Faustus]

Considering that it's the language I'm required to use for most client-side work, yes, absolutely. I'd rather use Delphi, but there are hardly any jobs, and what there are pay $5-10k less than VB jobs.

VB doesn't bear much resemblance to Dartmouth BASIC, and Kemmeny and Kurtz would tell you the same thing.

Re:Here's why...

[Anonymous Coward]

Bump into any ATMs lately?

Re:Here's why...

[Doctor Faustus]

Sorry, I don't get it.

Hmmmmm

[Ranma]

We just had an ask slashdot discussion about this a while ago. Its kinda weird when you read an article posted on a site about a discussion on the same site... I got nothing....

They scale differently

[digidave]

Java scales up very well, PHP scales down better.

If you're trying to run on a budget where you can't add a ton of servers and are limited to aging technology, Java will not scale to that environment very well. PHP can do quite well there.

Sun isn't interested in that market, which is a shame because there are a lot of companies still cutting budgets. I'd love to buy a server newer than a P2 1ghz, but it's not going to happen until at least next fiscal and even then, unlikely. We don't all work for technology companies who understand or care.

Re:They scale differently

[Anonymous Coward]

P2 1ghz

No wonder you don't get server funding for that. Fabbing your own chip is damn expensive.

Re:They scale differently

[digidave]

Alright, who was the brilliant fuck who put the 2 and the 3 so damn close to each other? I don't see any of the letters doing that.

Re:They scale differently

[buttahead]

No wonder you don't get the alphabet. Flouting your numbers is damn expensive.

Re:They scale differently

[icoloma]

I know of a PIII 600Mhz running with JBoss 3 (started with 2.4) entity beans with cache activated and postgres that works like a charm.

Right... Like E-Bay/Amazon!

[Anonymous Coward]

I have nothing against PHP, but don't claim things about Java when you just don't understand neither the language or its platform.

In websites PHP is reasonable but when talking about enterprise application and transaction management then it doesn't cut it and the article author was obviously completely ignorant of features like that not to mention a deep and unified component environment and API that is unmatched in the field!

IF you accept the underlying assumptions...

[Dr. Bent]

...then yes, it does. However:

"PHP can use the database as the back-end session store."

and

"The ideal multi-server model is a pod architecture, where the router round-robins each of the machines and there is only a minimal session store in the database."

are pretty tough assumptions to swallow. Storing session state in a database only works when you have a small amount of session state to store. Otherwise the database quickly becomes the bottleneck for any operation you need to perform. The alternative is that you have to have your session state distribuited in a cluster, which is something that, AFAIK, you cannot do in PHP. You can, however, do it Java. In fact, some of things that JBoss is trying to do will make session replication across a cluster fairly easy.

PHP can be very useful. I think PHP as a view layer sitting on top of a a J2EE controller and object model would be a wonderful idea. But to say "PHP scales as well as Java" is a huge oversimplification of the extremely complex problem that is enterprise computing.

Re:IF you accept the underlying assumptions...

[consumer]

All of the Java "best practices" stuff is full of warnings about how storing anything significant in the session will kill your performance. It's a huge mistake. Only truly transient data belongs in the session, regardless of language. And yes, PHP has various ways of doing distributed sessions, but frankly this sort of thing is overrated. It's VERY hard to go faster than MySQL with MyISAM tables for this kind of simple shared data.

Re:IF you accept the underlying assumptions...

[pHDNgell]

It's VERY hard to go faster than MySQL with MyISAM tables for this kind of simple shared data.

Sure, for small numbers of servers sessions and requests. My application server farm contains eight systems. Intelligent routing means that you're most likely going to go to the server that has your session state in a Map in memory. When it's a single map lookup to find your session, and then a map lookup for anything out of your session, that's pretty much as fast as you can theoretically get.

Replication of the session involves the container serializing the Map and passing it to one server in the cluster that is defined as its secondary. This means your session is replicated once so that if your master server fails, the session routing will take you to the secondary server (and if it fails, you lose your session).

Sometimes, you need large sessions, though. My application has a search which can return, at most, 200 results. My search UI allows you to page through those results (randomly or sequentially), change the sort order, etc... Any operation (after the initial search) is nearly instant. It's also consistent. You don't hit the next page and suddenly see duplicate results, or miss results because the source data changed.

In this example, a larger session makes everything better. Hitting a DB every time someone wants to go to page 2, or sort by last name or whatever would be slower, regardless of what type of table you use in your mySQL DB.

(OT: upon trying to submit this message:

500 Internal Server Error

An internal server error occurred. Please try again later.
)

Re:IF you accept the underlying assumptions...

[consumer]

I would say that caching search results in the session is a big mistake. First, what if the user opens multiple browser windows? They will get crazy results if they try to run multiple searches and page through them, and this is a fairly common scenario for most sites. I think you'd be much better off using a file-based search results cache with the search criteria as the key (rather than the session ID).

There are plenty of other approaches than MySQL for sharing sessions. I just wanted to point out that MySQL is extremely fast at this sort of thing, and many people underestimate it. Remember, MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket. The overhead is very low.

Re:IF you accept the underlying assumptions...

[pHDNgell]

I would say that caching search results in the session is a big mistake. First, what if the user opens multiple browser windows? They will get crazy results if they try to run multiple searches and page through them, and this is a fairly common scenario for most sites. I think you'd be much better off using a file-based search results cache with the search criteria as the key (rather than the session ID).

Well, likewise, I could pass the search ID around through all the pages if I wanted to deal with that scenario. There's no file IO required for every re-sort.

MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket.

UNIX domain socket means the machine with the app server has to be running the database. It also means that there's no failover for the session. A DBM would be better at this point (map key to structure, read and write structure at request/response time).

Scripting not scalable?

[Anonymous Coward]

You mean scripts are composed of a special class of dancing angels so unlike other languages?

Scripting has benefited me and my clients with languages as lowly as vbscript. There are things you can do with these languages that are scalable and not scalable. There are architectures that are better for scaling than others, but it has nothing to do with the scripting language itself. This is not news.

PC vs Mac

[Anonymous Coward]

the whole article should be modded down -1 flamebait

oh and ALL computers suck, now let me get back to my 1.2gb word processor and listen to my mp3's on my 80mb player

Oh, so that's why he said that...

[DrEldarion]

When I read the story above, I saw "Jack Herrington at the O'Reilly Network has had the audacity to claim that ..." and thought to myself, "why would the person who submitted this write it like that?".

Then I read the comments, and it seems that people actually get seriously OFFENDED by statements like that! You're reacting almost as if the guy insulted your mom! Calm down... breathe...

-- Dr. Eldarion --

Re:Oh, so that's why he said that...

[huckda]

Actually Jack was their Dad...

They're still trying to figure out who could have given birth to tech-heads whose main social outlet is http://slashdot.org/

Thus the witty banter we are constantly bombarded with.

Re:Oh, so that's why he said that...

[icoloma]

It's not that. There are TONS (and I really mean TONS) of documents explaining dozens of ways to make Java scale. They have put lots of stress in making it work well under heavy load. So, when someone argues that a framework as PHP with considerable less work on the subject scales better, he DARES.

Re:Oh, so that's why he said that...

[mactari]

Yeah, that or the guy who submitted the story wrote it just a touch tongue in cheek. Not sure which. ;^)

(Americans love smilies like dogs love trucks.)

where I stopped reading

[BigGerman]

"A page showing ten fields from twenty objects would make two hundred RMI calls before it was completed."
Sure if it was coded by former vb guy w/o a clue.
Even naive J2EE applications I saw would be smart enough to use a view object (containing all twenty business objects and their fields) to come back from the buisness layer in one call.
A person to use argument like this about J2EE scalability has no credibility whatsoever.

Re:where I stopped reading

[tmhsiao]

Sure if it was coded by former vb guy w/o a clue.

Welcome to the Real World.

Re:where I stopped reading

[consumer]

Even naive J2EE applications I saw would be smart enough to use a view object (containing all twenty business objects and their fields) to come back from the buisness layer in one call.

Doesn't this just illustrate how absurd it is to use RMI for this kind of thing in the first place? It forces you into workarounds likes this, and makes you use ugly coarse-grained interfaces instead of standard OO practices.

Re:where I stopped reading

[Anonymous Coward]

>Sure if it was coded by former vb guy w/o a clue.

I suppose you probably think there has never been a clueless J2EE or, dare I say, PHP programmer. Everyone who would chose to use one of those tools is clearly incapable of ever writing sloppy or less than perfectly efficient code.

Of course I'm not saying that all VB programmers are good, I'll admit there are some terrible ones around. But I get sick of the VB=Moron attitude displayed here sometimes.

I suppose just vocalize my own prejudices and say that someone who posts as often as you do on slashdot has never been laid... but that would be trolling, I wouldn't want to do that.

Re:where I stopped reading

[podperson]

As pointed out by another, if you kept reading you'd see that he makes your point and in fact uses it as part of his argument:

A page showing ten fields from twenty objects would make two hundred RMI calls before it was completed. This overhead was removed with the EJB 2.0 standard, which introduced local interfaces. This topology is shown below:

(diagram omitted)

This is logical three-tier architecture. The web server box has been removed because more recent web servers are not separated from the servlet code (e.g. Tomcat, Apache 2.0, etc.). As you will see when we compare this model to the PHP model, EJB 2.0 moved Java web application server development closer to the successful, and scalable, PHP model.

Re:where I stopped reading

[BigGerman]

I suppose I need to apologize to VB programmers of the world. I simply used popular "VB=Moron attitude displayed here" to deliver my point.
Your not-trolling comment of course is much more appropriate for this discussion.

Re:where I stopped reading

[lokedhs]

Very true. Also, the guy who wrote the article seems to have no knowledge of local interfaces. But, I guess I can't demand that magazine writers follow the latest developments, they've only been around for a couple of years.

Re:where I stopped reading

[cheeser]

Let me guess. You're a VB guy.

Re:where I stopped reading

[BigGerman]

I hoped the previous guy pointing this out was sarcastic and did not respond to him.
O well. Local interfaces have nothing to do with this - just another clueless statement by the author. Local interfaces allow you to call an EJB without RMI overhead. But if you need to separate tiers (having Tomcat/whatever serving JSPs on one server(s) and having Jboss/whatever running the business logic on the other server(s)) you are going to have to make that RMI call.
Minimizing the remote calls is the cheap, textbook way to optimize your J2EE app.
Also as it was pointed out before, EJB != J2EE and you can partition the application any way you want including running everything on the same box (JVM).
I developed PHP apps as early as 1998 and "graduated" to Java/J2EE and I can testify that the whole breadth of tools and approaches offered by Java (especially the open-source tools) make it a prime candidate for developing anything serious today.

Re:where I stopped reading

[Anonymous Coward]

What the fuck is a "business object"?

Re:where I stopped reading

[ajs]

And here you see why language (toolkit, OS, etc) comparisons are usually useless.

It's not that tool A lacks the facilities of tool B, but that there are very few people well versed enough in tool A *and* tool B to give you any kind of reasonable comparison, and when they do, their voices are usually drowned out by the ignorant masses who are all too willing to compare their pet tool to a tool they've heard a bit about and/or used a few times.

Perl suffers from this a great deal, as does every language. For example, I've heard PHP users complain that Perl is terrible for constructing Web apps. I find this confusing until I hear that they think Perl Web apps should be written using mod_perl for server interaction and the CGI module for display... And they're right or would have been long ago. Circa 1998 those were the only tools at your disposal. Now of course, there are FAR higher level tools (Mason, bricolage, etc). I only use this as an example.

The point here is not a PHP vs Perl one or a PHP vs Java one. It's simply that you have to know your toolsets well in order to compare them meaningfully.

Re:where I stopped reading

[kleinux]

Sure if it was coded by former vb guy w/o a clue.

Welcome to the Real World.

The dot com age is over. At my company most of those coders have been let go or moved out of programming.

My biggest complaint with PHP is the language is not strongly typed. When I want an int to be an int I want it to stay that way, always! For making complex sites I find that PHP becomes to sloppy because it is so much more difficult to define what goes into and out of a class. Perhaps PHP 5 will improve on this short coming (from what I have read it will help), but in the business world new is over two years old and younger than that is still in infancy.

Re:where I stopped reading

[Anonymous Coward]

If a VB programmer can make comprable money to a Java programmer and know much less about programming, who is the idiot?

Re:where I stopped reading

[tmhsiao]

The dot com age is over. At my company most of those coders have been let go or moved out of programming.

According to Sturgeon's Law, 90% of everything is crap. That goes for television shows, books, usenet posts and computer programs. It also goes for programmers, both employed and unemployed.

Even with the crumble of the dot-com era, companies are still interested in using Internet and Internet technologies for business, which means a lot of "interactive design" firms (and yes, they're still around) have the opportunity to sell websites and applications. I could show you code from currently employed programmers that would make your inner coder vomit (check my latest Slashdot journal entry for one example).

Re:where I stopped reading

[Cederic]

Erm. No. When writing distributed systems (i.e. many of the current business systems being developed today) you need to use data somewhere it's not stored.

Whether you use RMI, Oracle OCI calls, a custom TCP/IP protocol, small children carrying bits of paper, a distributed system will work best by minimising the number of remote calls required. What you call a 'workaround' is what I (and half the industry) call a sensible implementation of a known design pattern.

For distributed systems, coarse grained interfaces are ideal. I don't want access to a Customer object, I want access to Customer data, and I'd far rather have to make one call to retrieve it than 30 calls to get the customer's name, house number, address, zip code, phone number, mother's maiden name, etc.

So finally, to answer your question: No, it doesn't illustrate a deficiency in RMI. It indicates an awareness of good programming practice in a distributed environment.

~Cederic

Re:where I stopped reading

[Anonymous Coward]

Regarding the my_array_unique function from your journal, check out the second user comment on this page:

http://www.php.net/array_unique

Re:where I stopped reading

[consumer]

When writing distributed systems (i.e. many of the current business systems being developed today) you need to use data somewhere it's not stored.

The kind of additional remote layer that is added by this splitting of the business objects into a separate physical tier is very different from a remote database protocol like Oracle OCI in that it's artificial and unnecessary. You can't run an Oracle database in-process, and since it's a shared resource with all the other machines in the cluster, you probably wouldn't want to. On the other hand, you can run the business logic that is being shipped off into an EJB as an in-process object without losing any of the abstraction benefits.

If there was no performance concern, would it make sense to use coarse-grained calls instead of fine-grained ones? I doubt many experienced developers would say yes. Corase-grained calls make things harder to maintain and debug. Martin Fowler has a good discussion of this in his book about enterprise architecture.

I didn't say that there was never any place for remote access protocols, since obviously there is, but I do think that designing web applications in a way that requires remote calls to access the business objects is usually a bad idea.

Re:where I stopped reading

[Cederic]

If you can optimise by running things in-process, then more traditional OO techniques are going to apply. I was discussing the usual distributed environment (which is where you'd be using EJBs).

I haven't read Fowler's Enterprise Architecture book yet - it's sat on my coffee table waiting for me to finish another first..

~Cederic

Re:where I stopped reading

[Anonymous Coward]

f a VB programmer can make comprable money to a Java programmer and know much less about programming, who is the idiot?

The person hiring them.

The framework is not the problem

[heironymouscoward]

Scaling is not a language or framework issue.

Both Java and PHP scale because they run on scalable hardware, and this is the real key. Can you create instant resource pools using stuff like OpenMosix, or do you have to glue your servers painfully together following the "standard" clustering models?

If you can scale your hardware, and if your framework follows suit (by nicely splitting work over many processes and handling the database correctly) then of course you can scale the application.

It's not magic: the more portable your underlying framework, the more you can scale.

Again, this is not a language or framework issue except insofar as they hamper portability. Like, yes, .NET.

Web stuff again

[mccalli]

From the article: "Yet another area of efficiency concern is in the connection between the language and the web server. "

Only for web applications. If the argument is that PHP can serve up HTML as fast as Java can, then I imagine he's right. But there's a lot more to the world of programming than shoving out HTML.

Cheers,
Ian

Is this a JOKE? PHP doesn't even support UNICODE!

[sproketboy]

From the PHP manual

Is that good?

[Pan T. Hose]

PHP Scales As Well As Java -- is that a good thing? I'm not sure how well Java scales. How does it compare to Perl or Smalltalk?

No numbers?

[Anonymous Coward]

Ugh, that article contains only theoretical arguments for why PHP might or might not scale as well as Java. The problem with those purely theoretical arguments is that more often than not they go wrong...

I have assumeed the "Java scales, PHP doesn't" rumors to be talk from the field, where people tried both and found Java to work better than PHP for them. I'm happy to believe that, and would be happy to change my mind, given supporting evidence.

The article should have contained at least some kind of measurements, e.g. telling us how many hits/minutes a simple sample application in PHP and Java could sustain on a given platform. I don't see how the author expects to be taken seriously, when he theoretizes on measurable quantities, but doesn't bother to measure them.

P.S.: First law of optimization: Measure!

What is your point?

[jbottero]

I'm not sure what your point is or how you got there. How is maintaining 100,000 libes of PHP any different than 100,000 lines of any other code? The fact that PHP has very much in common with C syntax should make it even easier. But really, what are you, a VB programmer?

Re:What is your point?

[Anonymous Coward]

How is maintaining 100,000 libes of PHP any different than 100,000 lines of any other code?

PHP doesn't have strict typing, so it's harder to maintain.

Re:What is your point?

[Anonymous Coward]

Sun is considering removing strict typing from Java as a language requirement, since it was one of the Top 10 things that developers suggested to Sun to make the language more useful.

Strong typing is not necessary. Even Sun believes that. Sorry to disappoint you.

Re:What is your point?

[bloo9298]

Sun is considering removing strict typing from Java as a language requirement, since it was one of the Top 10 things that developers suggested to Sun to make the language more useful. Strong typing is not necessary. Even Sun believes that. Sorry to disappoint you.

This seems extremely unlikely. Do you have any evidence to support your claim?

Re:What is your point?

[TheCrazyFinn]

Neither does C, but Linus manages somehow.

And PHP can check types, so if you're worried, program defensively.

Re:What is your point?

[Anonymous Coward]

If they do this, I highly doubt they would remove the requirement of strong typing for interfaces, which is the biggest source of errors with weak/dynamic typed languages.

Re:What is your point?

[AKAImBatman]

> Neither does C, but Linus manages somehow.

Since when was C loosely typed?! That's not what my compiler tells me when I try to assign a char array to an INT. Now I'll grant you that pointers allow for some major fsck-ups, but the compiler *does* warn you. Besides, this is a stupid argument anyway. Linus has hundreds of people helping him. Most companies can't afford that kind of manpower.

Re:What is your point?

[Anonymous Coward]

No I think he is just talking about GENERICS which won't replace the strong typing but just used as another language contstruct to make things a little easier....

Re:What is your point?

[flibuste]

That's the most ridiculous thing I've heard in a while on Slashdot (and gee, there ARE a lot!). First, you CANNOT remove strong typing from Java. It's an object oriented language. Tell me how you do one without the other.. Then you say removing strong typing is on the top 10 list. As mentionned previously on another post, you must be talking about the templates being introduced in Java with JDK 1.5, which is NOT removal of strong typing, but adding features such as templates in C++. That is actually making the typing even more restrictive since you can now declare (as an example) Collection(s) of ONE object type, making sure no other object type will be stored in that collection ( thus removing needs for instanceof when iterating them) So definitely, you don't understand and don't know what you are talking about. Trouble is you are spreading your false statements to the world... OK, admit it, you are a Visual Basic programmer, right?

Re:What is your point?

[Anonymous Coward]

First of all, the number of lines that can be mainatained depends on the language alot. Strict typing helps to avoid the misunderstanding between several programmers, apart from potential security holes.
And why are you bringing up the "similarity of C and PHP syntax" anyway? That's about the only thing in PHP that's somewhat similar to C. Also, if you had ever seen Java, you would know, that it has alot more common with C(++), than PHP.

What are you, a PHP programmer?

Re:What is your point?

[Idolatre]

...which will make typing even stronger

a Vector can contain anything, which means type errors that can't be catched at runtime but with a Vector, the compiler will make sure that the Vector will never contain anything else than strings.

Re:What is your point?

[Idolatre]

I meant a Vector<String> will never contain anything else than strings, but it was interpreted as an html tag even if I was in plain old text mode.

Re:What is your point?

[SlightOverdose]

Python, Perl, PHP, Ruby... Thats four object orientated languages without strong typing, all of which have an extremely happy and loyal fanbase, and theres a lot more.

Just for once, I'd like to see someone explain why strong typing is so important. I develop most of my code in Python, and I have yet to see any problems. Hell, I find strong typing restrictive as it prevents me from doing things I otherwise should do. I'm currently working on a project of (according to cat | wc -l) 320812 lines, an god knows how many classes. I've yet to have one bug related to the lack of strong typing.

So heres my challange to all you strong typed zealots. Explain why it's so important!

Re:What is your point?

[whereiswaldo]

Strong typing turns a lot of would-be logic errors into syntax errors that can be caught at compiletime, not runtime. Runtime errors are much more expensive to locate and fix.

Strong typing forces you to think harder about what you are doing, someone like how Java's exception handling makes you think about what exceptions you are generating or what you should be catching.

I would argue that there is a place for strong typing and also for "variants", so both serve as very useful features of their respective languages. Since each language is based on the fact that it does or does not require strong typing, I don't see how changing that trait would be beneficial.

Re:What is your point?

[Anonymous Coward]

I've yet to have one bug related to the lack of strong typing.

I know both java and python. Java documentation is much easier to read because you know types of both the input output paramaters of the methods. In python, you have to guess, look at examples, search the web to figure out what the type of input parameters are.

def foo(name, port, path):
If i want to call foo, how do I create name, port, path without knowing their types. It's a real pain.

While I love python for quick and dirty tasks where it is quite elegant, it is quite unsuitable for really large projects due to lack of strong typing.
And yes, I get quite a few errors in python progs a few thousand lines large such as:
* bug caused by typo in a variable name
* wrong type parameter passed to func, but
parameter is used rarely so errors are
not caught immediately

Re:What is your point?

[jadavis]

Python, Perl, PHP, Ruby... Thats four object orientated languages without strong typing

Python is a strongly typed language with extremely late binding.

Variables can change type at runtime, which means it's late binding.

Strong typing just means that variables definately do have a type (even if it can be easily changed) and you can't apply an illegal operator. For example:

>>> one = '1'
>>> two = '2'
>>> two / one
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unsupported operand type(s) for /: 'str' and 'str'
>>> one = int(one)
>>> two = int(two)
>>> two / one
2
>>>

so, you can change a variable's type, but it still does have a type, and as long as it has that type it's enforced strictly.

Re:What is your point?

[sapporo]

First, you CANNOT remove strong typing from Java. It's an object oriented language. Tell me how you do one without the other.

While I agree that you cannot remove strong typing from Java, strong typing is not at all a necessity for object-oriented languages (think Smalltalk, Ruby, Obj-C). You might wanna check out Bruce Eckel's web log or a conversation between Bill Venners and Bruce Eckel for some enlightening opinions on stong typing vs. weak typing.

Re:What is your point?

[Jellybob]

That looks much like PHP to, where the same rules apply.

Maybe their less stringent with some of the more abstract types, but that applies

The same code in PHP:
$one = '1';
$two = '2';
echo $two/$one;
[Syntax error]

$one = (int)$one;
$two = (int)$two;
echo $two/$one;
[2]

Re:What is your point?

[Anonymous Coward]

How is maintaining 100,000 libes of PHP any different than 100,000 lines of any other code?

The difference is quite significant for complex projects. When I started our current project I was using PHP. The codebase numbered close to 10,000 lines before we switched to Java (and is now numbering close to 25,000 lines, and will likely end up in the 100-150 Kloc neighborhood). Our software is required to collect, process, compare, and display graphically (over the web) large quantities of information. The most pressing reason that we switched to Java, second only to performance, is that PHP is very costly to develop, debug, and maintain (at least within the scope of our application). PHP is great for simple, and purely web-based applications; but, not ones that involve intensive computations, and complex handing of data. In this regard, strict typing is absolutely essential when it comes to managing complexity, and tracking down problems before deployment.

Re:What is your point?

[trouser]

Python, Smalltalk & Objective-C are three OOP languages that I use that are not statically typed. It's one of the enourmous strengths of the languages that you're not constantly type casting to get around the ludicrous restrictions imposed by a statically typed language.

Dynamic resolution at runtime does present performance problems, but we are talking about Java here so performance is obviously not an issue.

I'd say the real problem with PHP is that, to the best of my knowledge, it doesn't support exceptions so the user is occassionally confronted by baffling error messages in place of the page they requested. Shabby.

They each have their purpose

[Anonymous Coward]

As a Java developer:
PHP is good enough for a website, if you know it then either stick with it or learn Java but I think its best to stick to what you know.

However if your project is enterprise level requireing things like distributed transactions complex authentication integration with mainframes and ERM then your only "real" choice is J2EE where the alternative is a huge stack of propriatery technologies that don't play nice together.

Performance vs. Scalability

[shmert]

This article doesn't talk about scaling, but about performance. As one poster commented on the article, performance measures how long it takes to process a single request. Scaling is how well it handles many concurrent requests.

Also, the lack of any solid numbers is annoying. The author basically points to various levels of abstraction in the Java model and says "See! This is slowing things down" without any concrete comparison to PHP.

I use both Java (WebObjects) and PHP, and I actually really like both of them. As has been said many times before by sensible people, use the right tool for the right job. For a low-traffic website with a lot of static content and a couple dynamic forms, I'd much rather use PHP. For a huge app with a very large database, I'd rather do something in WebObjects.

PHP performs well, except for the fact that each page hit re-parses the script into executable php "bytecode". Using Zend Optimizer can make this much less of an issue.

However, the other big downside to PHP is that it's difficult to share data at the application level. Session-level storage works well, using $_SESSION variables, but if you want to have some application-wide information, your choices are to either:
* Store it in the database
* Use the filesystem
* Use some 3rd party application-level cache, or roll your own.

The first option leads to, you guessed it, NONSCALABILITY. By making the database the bottleneck, it makes it much more difficult to add extra servers to handle the load.

The second or third option would probably work O.K. but it's not quite as self-contained (or speedy) as using shared Java objects. Also, tacking on 3rd party shared-memory solutions to handle what should be a very simple thing seems, well, tacky.

Disclaimer: I've not used J2EE or JSP, nor do I want to. I'm a WebObjects programmer. Which uses Java. I think a lot of confusion results in people who say "Java" and really mean "JSP".

if Linux can make it,

[Anonymous Coward]

why can't PHP

Oh dear..

[ProtonMotiveForce]

I didn't read the article (too lazy), but the synopsys is sadly confused.

Java scales well in the design side - it's a cleaner language and it's easier to develop large systems without losing yourself in a shitload of unmanageable code. PHP, umm, doesn't.

Which scales better in terms of performance depends, of course, on what you're doing. I'm sure there are areas where PHP scales much better than Java. Conversely, in most real-world areas Java probably scales better.

mod parent +5 informative

[jasonbowen]

nuff said

Re:Pathetic Heap of Poop

[KDan]

The article repeats that it just scales as well as Java quite a bit. Maybe it does. At runtime. But it sure doesn't at maintenance time!!!

Daniel

Pointless

[ymenager]

This is pointless discussion.

You only really have to worry about scaling if you have a HUGE project.

Now if you do have a huge project, PHP doesn't even hold a candle to J2EE due to lack of features like JTA ( distributed transactions ), and all the rack of clustering capabilities of J2EE .... But even more importantly, PHP is nowhere as MAINTAINABLE as Java, which is just as important ( if not *more* )

Re:Pointless

[Bromrrrrr]

PHP is nowhere as MAINTAINABLE as Java

How is that? (seriously)

Hrm

[Etriaph]

The issue with PHP is not whether or not it scales as well as Java, but whether or not it's useful in a real-world application. In my opinion, it isn't that useful.

PHP offers us no way to build an application server (unless you write one in C or C++ and send commands to it via a cli or directly through sockets). If you embed Tomcat in your application server, you can simply create contexts and mount them with mod_jk. Quite simply, you can take any server that you've written in Java and web enbale it fairly quickly. PHP lacks persistence, and I'm not talking about sessions.

Let's say that we want to add a request to our application from the web. With Java I can toss the request on a queue which a thread picks up and balances to several other worker threads who interpret the request and works with it. With PHP I would have to enter data into a flat file, or a database, and have a cronjob setup to run every minute or so and do something with data in the database. Even then, at that point, I can only have one thread unless I want to mix and match several cronjobs to run at seperate times (or unless I want to fork the process off very uncleanly using exec() or system()). In any case, does PHP scale as well as Java? Maybe, I'd need to do more tests. Is it nearly as useful? No, not right now, probably not ever. Unless you are willing to write your own custom PHP module in C and play with PHP that way, I think big jobs should be left to the heavyweight in this discussion.

Re:Hrm

[Space cowboy]

"If you embed Tomcat in your application server, you can simply create contexts and mount them with mod_jk."

If you embed xmlrpc_c in your application server, you can simply send xml-rpc requests from your PHP script or pages.

We do. Works great, and you get communication from java/perl/python/whatever thrown in for free.

Personally, I think its harder work to make a PHP system scale at the enterprise level than in Java - I've done both, but I've written PHP code that thousands of people use, handling vast quantities of data flowing through it (I work in the film industry where a single frame is 20Mbytes. Clips are big!) and it copes well.

Redundancy, Load balancing and insightful design all play their part. A-priori knowledge of the likely problem areas helps too :-)

I've never had to resort to writing PHP modules in C. I have had to do a lot of JNI though for CPU-intensive tasks, which is a royal pain when you have to be cross-platform. Win32, OSX, Linux and Irix, all with different C++ compilers and requirements. Yuk. Don't get me started on how [random deity]-AWFUL Java is for reliable Runtime.exec() in a cross-platform manner. With PHP it's $status = `command`; ...

OTOH, Horses for courses, we do a lot of Java work as well. Generally we do cross-platform gui in Java, servers prototyped in Java and ported to C++, and web interfaces in PHP, as thin-clients to the servers. That's generally ...

Simon

Re:Hrm

[tcopeland]

> Let's say that we want to add a request
> to our application from the web.

You can do that using SOAP. Set up a SOAP service using NuSOAP that exports whatever operations you want, then use a Java Swing client that uses Axis to talk to the server. Or you can just use a Ruby command line script on the client. You can use complex types, faults, whatever.

We do this on GForge; it's not a problem.

Re:Hrm

[Ogerman]

If you embed xmlrpc_c in your application server, you can simply send xml-rpc requests from your PHP script or pages.

I'm currently planning to transition the software I develop to a more robust 3-tier architecture. PHP will definitely be used for the standard web client and I am planning alternative clients written in Qt and also perhaps for handhelds. What do you think about writing that xmlrpc-capable application server in PHP? Is PHP up to the task or should I look elsewhere. As this is for a free software project, proprietary Java-based solutions are not an option.

What'd be really nice is if there was some sort of existing framework for building this application server.. but alas, everyone in the OSS community seems hung-up on crappy 2-tier design. Hopefully I'm just missing something! (:

Re:Hrm

[Zefram]

I think you're missing the point of PHP, and it's usefulness depends on what you mean by a real-world application. I must assume that you mean a standalone application, to which I must say you're insane if you try to use PHP.

PHP is a web-based programming language. It has been extended to do other things (which I haven't tried yet, so I can attest to their usefulness), but it is primarily developed to be used in web applications... not stand alone applications.

Perhaps this is the primary reason for the division between Java and PHP coders. While Java is a general purpose language, PHP is specialized; as it has been said before. I write large web applications in PHP, but I would not think of writing any kind of application that wasn't web based in PHP. I think you should be aware of a language's strong points, and then decide what to use based on the project's requirements. The Java thought process seems to be that Java should be used everywhere, because it can... that's something I fundamentally don't believe in.

As an aside in reply to other threads, it's been said that PHP is unmanageable and lacks session variables. PHP is just as unmanageable as Java, I'll say that I've seen horrible nightmares in PHP, due more to poor code design and overuse of the embedability of PHP. If written properly, it's as straightforward as any language. And, as anyone who knows PHP knows, PHP does have session variables. What it lacks is state variables shared amongst a cluster, and to this I refer back to the purpose of PHP. PHP isn't about re-inventing the horse. There are many other ways to share data amongst servers, and it would be pointless to include just one way within PHP itself. It's something better left to the system administrators and developers to decide the best mechanism between themselves.

John

Re:Hrm

[Space cowboy]

Quoth Ogerman

"What do you think about writing that xmlrpc-capable application server in PHP? Is PHP up to the task or should I look elsewhere."

The only question would be performance, and you'd have to test that yourself - we use C++ on the server end, frankly because we started off with it, it works well, and we see noreason to change it :-) Most of the bottlenecks are in the datastore (DB, shared mem, whatever) rather than network or parsing anyway, so perhaps performance isn't a problem either, especially if you use Turck or Zend optimiser...

Actually implementing the server in PHP is trivial - 3 or 4 lines of code instantiating one of the public implementations, and working within the xml-rpc framework is pretty simple in PHP, just as it is in Java.

I'd say give it a whirl - can't tell you I've done it and it's all fine, but I'd certainly expect it to be good enough, modulo your throughput requirements, of course.

Simon.

Re:Hrm

[Fnkmaster]

This makes no sense. PHP is very useful in many real world applications. I would say it's great for low and moderate volume web-based ordering/purchasing/content systems. The key is these had better be systems with relative low per-transaction value. I would definitely use PHP to build a system that 1000s to 10s of thousands of users a day used casually, and bought and sold stuff on, assuming the basic needs of sticking orders in databases, sending them off for credit card processing, and doing stuff with return results.

Now, if a system needs to do more complex things, like a financial order processing system with complex transactional logic and the need to integrate with lots of other systems and be responsive, scaleable, and have very well defined behavior in all failure modes because the per-transaction value is potentially hundreds of thousands of dollars, then I would (and have) definitely use something based on Java (though I don't think there's enough money to get me to touch J2EE again).

But that doesn't by any means imply that PHP is useless. The applications just happen to be different.

Re:Hrm

[Anonymous Coward]

php is the application server ..... it is a scripting language ... there is no need for an application server ... duh ;-)

Pathetic Heap of Poop YOU ARE BRAIN DEAD

[jbottero]

So, what you are REALLY saying is that you have not taken the time to learn the language?

Re:Pathetic Heap of Poop YOU ARE BRAIN DEAD

[Foofoobar]

Forget it. He's just a Microsoftie that can't support his argument with anything intelligent. Flush him along with the rest of the floaters.

Re:Pathetic Heap of Poop YOU ARE BRAIN DEAD

[jbottero]

It's too bad the Slash Mods have such God damn THIN SKIN, they can't see a reasonable comment when it is not consistent with their own myopic opinion. I'll take the "flamebait" as a badge of honor.

Performance scalability? Can that be right?

[brlewis]

Back when I was concerned about whether BRL had decent performance, I did a simple benchmark on a 586 Debian box with Apache/php3 vs Apache/Jserv/BRL. PHP could beat BRL if BRL used Sun's JRE, but BRL beat PHP using IBM's JRE. When I switched from Apache/JServ to a Jetty server, BRL totally blew PHP away. I tried again when PHP4 made it into Debian, and surprisingly saw no significant difference.

BRL's architecture is much like JSP, except BRL may be faster on the first request as it compiles a simpler language with no intermediate Java source. I would expect JSP to perform as well against PHP as BRL did, if not better.

horizontal scaling

[BubbaFett]

The article doesn't ignore horizontal scaling. It scales to over twice the width of my browser.

Re:horizontal scaling

[Anonymous Coward]

amen

The Truth

[TheLastUser]

You can make really big sites with PHP and you can make really big sites with Java, that's the fact. Each has advantages and disadvantages. Use what you want. Personally I use Java and while PHP lacks many facilities that Java has, Java also lacks things that PHP has. I would never look down on someone who uses PHP or any other language, because every language has trade offs. One thing that you get with PHP is a platform that is more tolerant of shitty code, when Java will blow, the PHP server will keep chugging along. With Java you have to use a more rigorous build and testing process, while with PHP you can deploy individual files here and there without too much worry. To me these sorts of consideration are as important, or even more important than distributed transactions, and session sharing. Not every site needs distributed transactions, or CMP or any of the other cool Java things. They are nice to have but they may not be required to make a specific site.

Re:The Truth

[poot_rootbeer]

One thing that you get with PHP is a platform that is more tolerant of shitty code, when Java will blow, the PHP server will keep chugging along.

This is a Bad Thing.

Shitty code doesn't belong in your application. If something fails because it's designed poorly, you NEED TO KNOW about it even if it results in
an ugly fault message to your users.

It's one of the fundamental tenets of programming: if you allow error conditions to go untrapped, things start getting secretly corrupted and you won't even notice it until it's too late to fix.

Re:The Truth

[tkwoof]

if you allow error conditions to go untrapped....
True!
However, All programming languages have this exact flaw ... The programmer!!
Any programmer worth his salt learns how to code to control error conditions. I am very experienced in Perl, PHP, C, Java, Javascript, etc.... They are all excelent languages, and give the programmer a plethora of debugging, and error handling choices.
Further, This whole argument is like two almost identical twins fighting over who works better at laying bricks. Java and PHP are both in my opinion languages that exist for the good of the IT world ... unlike c# or MS .NET languages (no offense, but I hate having to pay little limp to program).... anyway my two cents....

Scripting Languages _can_ scale

[randall_burns]

A good example of a scripting language designed specifically for fault tolerant, real-time, distributed systems is mozart-oz.org The research team there(SICS) did a lot of work to make the networking layer very transparent.

Now, Mozart-oz hasn't had the trial by fire that PHP or Java have had--you won't see it used in a lot of commercial sites-but Mozart does show how the type of applications that folks think could only be done in Java, C# or C++, using an army of programmers can be done by a smaller team. Can it be done? Sure. Will it be done? Well, that depends on the will of the community ultimately.

I personally think this is the type of thing that is key to reducing the complexity of large software systems, but it is a _hard_ problem and will take a while to sort out.

There have been requests for getting some of the key features of Mozart-Oz, namely logic variables, into Python. I include this to show some of the difficulties in the discussion here(i.e. we get a lot of really smart folks that don't come to an obvious consensus on how to proceed here). I'm sure that there are some things that you can do in Java that PHP can't do yet-and some of these deal with needs of key markets like banks. Can those features be added? Well, that seems to be contention of some serious researchers in the field.

Python Logic SIG

Applying Logic Variables to Conventional Languages

The infamous Logic Variable PEP

I'm pleased to see this.

[Morologous]

I like PHP, I'd like to work more with PHP in the future. But until the IBM products that I make my living on are built on PHP, I don't have much choice. Which is not to say that I don't like the Java that IBM is using -- I'm *very* pleased with the course and result of the Java development that we've done in relation to the IBM products that we deal with.

Re:The Superiority of PHP over Perl

[PhuCknuT]

Excellent troll, you manage to sound almost convincing while spouting nothing but lies. In fact in most of your points if you swap perl and php they will be much closer to reality.

I find it interesting

[generationxyu]

That there are no replies above my current threshold (4).

Apples to Oranges.

[SatanicPuppy]

Php and Java aren't the same kind of language, so why do people insist on trying to compare them? Php works great for a lot of applications, but expanding its function base is a fricking nightmare, and you're dealing with a certain amount of compile time overhead on every page view.

With Java you have easy access to a lot of OOP features that are very difficult to implement in Php, and the function base is simple to expand. Yea it's big and beefy, but that's what you need sometimes.

They're both just tools. Use the one that's appropriate. People scream about Java being bad for small pages. What kind of idiot is using Java on a small page? Conversely I've never even heard the Java vs Php agrument for a big site--it's always Java vs VB, and that's another no brainer.

Just my opinion.

Re:Apples to Oranges.

[stanmann]

Because people think that all web is equal. If its good for my enterprise web site, then it should be good for my personal web site and vice versa.

Re:Apples to Oranges.

[jdogg_11]

exactly!

Re:Apples to Oranges.

[Slime-dogg]

In the workforce of today, when it comes to tools, you are usually given a choice of one or the other. If you go with one tool for a particular project, you will not be able to go with a different tool for a different project. Standardization is a part of a structured and organized operation, and programming languages is one of those things that get standardized.

I would go with Java, if I had to, just because you have a lot more uses for it. Not only can you write web applications using JSP, EJB, Applets, etc, but you also are allowed to write full blown applications. PHP doesn't give you that option.

Re:Apples to Oranges.

[Micah]

> With Java you have easy access to a lot of OOP features that are very difficult to implement in Php, and the function base is simple to expand. Yea it's big and beefy, but that's what you need sometimes.

Right. Take a heavily OOP PHP program, which has everything in a class, neatly designed into a great architecture. Now, for EVERY SINGLE FREEKING HTTP REQUEST, it has to parse a boatload of OOP code, then run it, creating all the objects. PHP objects cannot persist between page requests. (I don't know if Java objects can or not, but at least they wouldn't have to be recompiled each time.)

I saw one project die a horrible death for exactly that reason. Each HTTP request took quite a few seconds.

And I'm afraid Xaraya, which looks like a very slick new CMS, is going to follow suit. I've tried it, played with it, looked at the code. And it's parsing quite a bit with each request, and on my server each request took at LEAST two seconds, sometimes quite a bit longer.

Re:Apples to Oranges.

[Flopper]

For real projects you do use a cache like Turck MMCache.
Real projects could also cope with a huge OOP tree, the overhead isn't that much as you would think of. You additionally get a nice set of RAD tools (GUI-Controls) if you code a good framework with OOP, the debugging is easier, the code isn't redundant, the code is reuseable etc. pp
I never saw somebody hosting big PHP projects on a server without cache.

Re:Apples to Oranges.

[IA-Outdoors]

Hrm, ever heard of PHP-GTK? With it you now have a desktop GUI, ability to write web applications and, if you design your app right, you can get the same level of reuse you get from Java. Again, the EJB, Applets and Compiled Code will always be good arguments against PHP. However, typcially, the price tag for those things is higher. You have to, on a project-by-project basis ask "Is it worth it?"

Re:Apples to Oranges.

[icoloma]

They're comparing only the performance. It's a valid comparison. If I had a project where performance is #1 priority, I would check PHP if I thought it was faster than Java, and wouldn't mind if it's narrower in scope.

After seeing this article, I think I should stick with Java + Webwork + Velocity, given that constraint. IfY(S, JSP is just fine.

Re:Apples to Oranges.

[Tablizer]

With Java you have easy access to a lot of OOP features that are very difficult to implement in Php

Well, it is true that Java caters more toward OOP fans than PHP. So, if you think OO is the cats meow, you would probably prefer Java. I personally don't think too highly of OO.

But on the flip side, the dynamic nature of PHP makes some things easier that might be more difficult in Java. For example, you could store math expressions and/or function calls in database tables, and execute them in PHP after looking up the appropriate item(s).

Re:Apples to Oranges.

[stanmann]

And this is where programmers need to educate management. You don't expect your mechanic to use a screwdriver to remove your tires for changing, or a torque wrench to change your spark plugs... We as programmers should be able to select the appropriate tool for the job as well....

Re:Apples to Oranges.

[prockcore]

and you're dealing with a certain amount of compile time overhead on every page view.

That's why there's things like the Zend Accellerator, which caches the compiled scripts.

I worked with That Guy

[beavis88]

Someone at a company we partner with wrote a web service, part of which made 400+ RMI calls to validate the input on a single (enumerated) field. Yeah, he probably was a former vb guy,and certainly had no clue, but this was in the "Real World", and it made it all the way to release before they noticed it (the staging tiers we all on the same server, the prod tiers were not...)

His definition of scalability

[yomahz]

There are a number of different aspects of scalability. It always starts with performance, which is what we will cover in this article. But it also covers issues such as code maintainability, fault tolerance, and the availability of programming staff.

These are all reasonable issues, and should be covered whenever you are choosing the development platform for any large project. But in order to convey a convincing argument in this small space, I need to reduce the term scalability to its core concern: performance.

I think he's chosen the shittiest option here. Sure, any technology will scale if you throw enough resources behind it. Just keep load balancing and you can make almost anything scale performance-wise.

I think there are a lot of other factors that are much more important. Code maintenance, fault taulerance, etc. are much more important because those can't be fixed by throwing more hardware at it.

J2EE application servers come with transactions, security, resource pooling, and concurrency right out of the box. That's a lot more than I can say for PHP.

Now another thing... he's got his J2EE Architecture completely wrong when it comes to EJB's. With EJB 2.0 (which has been around since 2001), there is no RMI overhead for servlets communicating with Local EJBs. You'd only use a remote EJB if the bean resides on another server.

Clearly not true

[Anonymous Coward]

Where can I run my java code?

• Client
• Web server
• Application Server
• Database

Where can I run my php code?

• Web server

I like PHP and have used it for a number of project, but it's simply not an application infrastructure like java.

see JBOSS

[b17bmbr]

apparently, the folks at JBOSS do think php scales as well as java. of course they have a product to push, but they did use php and found it wouldn't hold up.

Good grief!

[Anonymous Coward]

First he says:

PHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.

Then he says:

There are a number of different aspects of scalability. It always starts with performance, which is what we will cover in this article.

It DOESN'T ALWAYS start with performance. The only reason relates performance and scalability is because performance is ALL he talks about in this article. His conclusions (first quote) are COMPLETELY UNJUSTIFIED.

Jeez...

Session state

[JMZero]

Storing session state in a database only works when you have a small amount of session state to store

I think developers need to commit to smaller session footprints on servers anyway. Our goal here is to have nothing but security information stored on the server - and I think that's very reasonable. Make everything else come on the request.

We see a lot fewer bugs this way, and everything becomes easier to maintain. The database can handle the login information fine (thus far at least - our applications are all very data intensive to begin with), and being in the database means session info is easy to manage.

To me, having another a session quasi-database replicated around the cluster seems like an ill-fated enterprise.

Web development, though, is like that I guess. It's always difficult to picture what works for applications different than your own. The 100,000 lookers at site A call for a different setup than 10,000 workers at site B might need.

Java-PHP interoperability

[pajama]

For your information the JCP is working in an interoperability API to script web pages in J2EE using PHP as a language.

This will be available with PHP as a working example, but it will be possible to use qny other scripting language instead.

The scalability/security/transactionality/etc stuff could be handled by the J2EE back-end. It will be just another way of scripting webpages, using PHP instead of JSP.

Check JSR-223 for more information.

Ricardo

strict typing

[Camel Pilot]

In my experience strict typing has little to do with maintenance issues.

I would rate design, proper partitioning, data packaging, code quality, etc. way above strict typing. In fact strict typing typically adds 10% to 20% code bloat to your application. Besides script typing is more for the benefit of the compiler and not the human developer.

Re:strict typing

[el pedro]

Strict typing helps devlopers not use wrong variable names, etc. rather than using the wrong variable on the fly. Also, for a person reading the code I would say that strict typing is qutie a benefit.

Maybe I've just had too much "good style" drilled into me though...

Re:strict typing

[Camel Pilot]

We rely on a crutch (variable name completion) inside our editors to insure (at least to 99% confidence) correct variable naming.

Good style is good as I have struggled with too many messes because people/teams viewed style as secondary consideration.

Re:Strict Typing

[Anonymous Coward]

Sure, you must be one of these real programmers with a built-in compiler from sirius cybernetics then. Strong typing is for wimps !

Re:strict typing

[Anonymous Coward]

Having a compiler to double check your work is an invaluable tool. The more you can have a rigorous compilation process running over your feeble human code, the better. The more information you can feed your compiler to give it some kind of clue on what you're trying to do, the better.

Prefer compile time checks to run time.

Go back to your CS 101 class, please.

it's not hard to be scalable

[penguin7of9]

Computers are so fast that even very inefficient systems can easily saturate any network connection you could possibly have. All of Microsoft could probably be served from a single laptop by PHP or Java (not so sure about IIS/.NET--there are limits :-) if it was just a question of how quickly scripts get invoked and can pump out data.

What makes web applications slow is database and file system access. So, no matter what language you use, you primarily have to worry about the scalability of your storage and database component.

The major difference between PHP and Java is how they scale in terms of programming effort and complexity. PHP is great for projects of small to medium sized complexity, but not so good for anything really large. Java, on the other hand, is equally bad for everything: it's tedious to use for small projects and it's better than PHP for large projects, but that isn't saying much.

ah hell

[b17bmbr]

s/do think/don't think/

Apples and Oranges

[nekosej]

Compare JSP and PHP if you want, but to compare a platform to a scripting language is pointless.

The sad reality is that so few developers know enough to fully exploit J2EE that they wind up doing little more than what PHP does better in the first place.

"ignores horizontal scaling"

[Wolfier]

In a lot of applications horizontal scaling is much more important than vertical scaling.

I cannot believe an article that talks about scalability simply just "ignores" horizontal scaling.

Re:Pathetic Heap of Poop

[Foofoobar]

LOL. More FUD from an Anonymous loser... I'm so hurt :)

PHP is better at some things

[Anonymous Coward]

In my experience, it's definatly better at making spagetti.

J2EE != EJB

[shaper]

In the article, the author assumes that the J2EE application includes EJB's and from this assumption he builds in additional layers of overhead, especially with RMI calls to the EJB layer. His assumption is incorrect.

If you really want performance in a J2EE app, you can stick to JSP's and servlets and limit the usage of EJB's. Still keep the presentation in the JSP layer and isolate the business logic in servlets. This approach is quite lean and scales hugely.

When and how to use EJB's is just one part of J2EE application design.

Re:J2EE != EJB

[tedgyz]

Well said! I was going to post a reply saying the same thing. Personally, I think EJBs are evil and should be purged from the face of the planet. IMHO, they offer very little value, yet introduce a tremendous performance penalty. The article mentions that EJB 2.0 introduced local interfaces. I thought the whole reason for using EJBs was to allow for seamless remote access.

I have been happily coding J2EE apps sans EJBs with great success.

The article got one thing right. The greatest impact on performance is a good application design.

Re:J2EE != EJB

[aschlemm]

The EJB 2.0 spec introduced a "Local Interface" which is used to allow EJBs co-located in the sam EJB container to communicate efficiently without the overhead of RMI. If one is writing a local interface for an EJB, the methods are not declared as throwing a RemoteException.

ohh ... all you just wait ...

[Anonymous Coward]

...just wait until php5 appears and some decent progammers convert. An easily scriped OO web language? (no offense perl)

Its like asking God what language he programmed th earth in , and he answeres 'OO cobolt, you FOOL!! Muah ha ha !

Re:The Superiority of PHP over Perl

[chanceH]

Wow man. that was a very good troll.

I had a whole big flame reply written and had the mouse pointer over the submit button, and was previewing one last time before I realized that it had to be a troll.

If you hadn't talked about writing Doom in VB, I think you had me, although the thing about the regexes should have been an instant give away

You've hit the nail on the head.

[tshak]

I used to code in Perl, Cold Fusion, and VBScript (ASP) back in the days that scripting was all the craze. I used to love (believe it or not) working with Cold Fusion. I could create a web application so quickly, and it had features like connection pooling, session management, and application management right out of the box (and this was 5 years ago).

Once clients started demanding "web applications", as opposed to basically static web pages with a little DB interaction, I quickly realized how no scripting solution would scale elegantly. Most people (at the time) would scoff at the idea of writing even a 10K line of code app with Perl/TK, why did we do the same with web apps?

I think the number one reason that scripting sucks for application development of any sort is it's lack of strict typing. This makes it difficult to implement a clean OO design, and it also makes it harder to code IMHO. Sure, there's the extra step of compiling, but that actually helps me track bugs in my code down quicker. Even for small projects I hesitate to use a scripting language because you never know what part of that project you'll want to reuse, or if that project will grow in the future.

So, while most of my resume contains scripting experience, I would have to say that my life as a "web developer" is much better now that I'm working with C# and Java.

Re:You've hit the nail on the head.

[Anonymous Coward]

Indeed, without the compile time check by a machine early in the development cycle a human has to deal with a run-time error somewhere later in the cycle, maybe even after the product is released.

Guess what's going to cost you the most money...

Re:You've hit the nail on the head.

[Anonymous Coward]

Test early, test often. We have the CPU. It doesn't take 40 minutes to compile a program just so we can run-time test it. Even C/C++ will compile in only a few minutes for run-time testing.

If run-time variable testing is not part of your development cycle, you have more problems than whether or not to use Java or PHP I think.

Guess what would cost you the most money?

Re:You've hit the nail on the head.

[ichimunki]

I'd say it sounds like you might want to look at Ruby and then reconsider some of your statements. It is extremely dynamic-- but it's probably one of the cleanest OO languages out there. And your comments about compiling are confusing. You make it sound like Perl doesn't go through a "compile" step when you start a script. Of course it does. The only difference to Java is the Perl virtual machine is not a separate component and the object code is not extractable into something like jar files (although it would seem that Perl 6 won't have this flaw).

Re:You've hit the nail on the head.

[aled]

Most people (at the time) would scoff at the idea of writing even a 10K line of code app with Perl/TK

That's because most people can't read their own 100 lines Perl scripts after a while, myself included.

Re:You've hit the nail on the head.

[Anonymous Coward]

Runtime testing is NOT a replacement for the compile time checks. You use it in addition to compile time checks.

There's no practical way to perform all the permutations runtime that a compile time check will catch, even if you try to use some coverage tool.

So the chance is very real that you'll end up with some runtime error because you passed the wrong type of parameter in a corner case that your runtime test didn't check. If that happens after your app is deployed you have to involve a lot of people to get that piece of code fixed and that costs al lot more money.

So have fun with your perl, php and python scripts. Just don't fool yourself into thinking that you can build big apps cheaper with these things than with e.g. java. When you add everything up you'll see that the overall cost might actually be a lot higher.

Confusion of terms

[iamacat]

The problem is not Java's or PHP's scalability in terms of performance. If there is a problem, people write a better compiler, a better database, buy a faster server or buy more servers. Pocket change for web sites with millions of transactions per day.

The problem is that Java, being a general-purpose, modern programming language, can be used to write understandable and secure code for very complex problems. And PHP, well, is not. Maybe you don't have an application that can be most cleanly implemented as a 5-tier architecture. But if you think you might in future, you don't want to start writting it in PHP. Not the logic portion at least.

A lot of technologies - OO, EJB, relational data design - can seem useless and overcomplicated until one encounters a problem that is complicated. Maybe one of these days I will understand what inspires people to use XML, with schema and style sheets to communicate between their own client and server. Rather than using a nice binary RPC implementation, for example. But then maybe this is one example of a bad technology.

On the other hand, you can still open database connections directly from JSP and combine ease of use of PHP with security of PHP. At least you can still call functions from your class library for connection pooling and input validation.

senseless rant

[eadint]

This is not flaimbait, really . i was playing around with dreamweaver, and php on a mac and i couldnt get a working connection to a postgresql database. this really frustrated me. why. i dont know why anyone in their right mind would use mysql thats just stupid. postgresql is far superior and its opensource. this frustrated me and i guess this is much more of a dreamweaver rant. i like php, its simple elegant. and i guess you can mod it. java is just plain ugly. but why would an opensource app suport mysql, its not opensource. anyways rant over.

strict/loose dynamic/static explicit/inferred

[brlewis]

The problem with PHP isn't dynamic typing, it's loose typing.

Scheme has strict dynamic typing. You get more concise code, but not so error prone as PHP.

Java has strict static typing, possibly somewhat less error prone, but less convenient.

Languages like ML have strict static typing, but type inference makes the code more concise.

The difference for me...

[temojen]

I code PHP at work & Java Servlets at home. The reason I'm useing Servlets for my at home project is that I can leave a thread running in the background to do any database writes after the page is returned. It may not actually be any faster, but it sure seems that way to the user.

Re:The difference for me...

[Anonymous Coward]

he reason I'm useing Servlets for my at home project is that I can leave a thread running in the background to do any database writes after the page is returned. It may not actually be any faster, but it sure seems that way to the user.

I guess your information is not very important since it can be wiped out by a power down or crash between the confirmation and the asynchronous background write.

Re:The difference for me...

[temojen]

I guess your information is not very important as it can be wiped out by a power-down between the database query returning and the page being flushed from the cache, or by a head crash between backups, or by a fire that destroys your site before the backup tapes are transferred, or by a meteor.

No, my information is not so important that I need more than stable hardware and software, a UPS, and regular backups.

Re:The difference for me...

[pHDNgell]

I guess your information is not very important since it can be wiped out by a power down or crash between the confirmation and the asynchronous background write.

In my app, I've got somewhere over a half a million clients that come talk to me every day and tell me how things are, ask what's new, etc... I track various aspects of this information in a couple different databases. If I don't save information for a guy today, I will tomorrow. In cases like this, async transactions get the user back on his way very quickly and I rarely miss a save. If I do, big deal.

I also do asynchronous saves in my photo album app (photoservlet.sf.net), but I do it a different way. In that application, there is a cache of structured image data that is used for putting up the pictures, but the image data also gets stored in the database. When a new picture comes in, I immediately structure the data and cache it for viewing, and then write a couple of records indicating the data has arrived. Within a few seconds, a thread will notice the changes and begin storing the image data into the DB (which takes too long to make a user wait).

This is an example of asynchronous transactions done safely while still giving the appearance of a faster application.

Re:The difference for me...

[Joseph Vigneau]

I guess your information is not very important since it can be wiped out by a power down or crash between the confirmation and the asynchronous background write.

Not if you use JMS. His code can emit a message within a transaction, commit it and immediately return. If the commit is successful, this means JMS is bound to deliver that message at some point in the future, no matter what the circumstance, even if the JMS server itself crashes.

Re:The difference for me...

[optime]

You can do that with php also.

a) http://www.php.net/manual/en/features.connection-h andling.php

or

b) http://www.php.net/manual/en/ref.sem.php

Re:The difference for me...

[temojen]

Actually, no, the connection handling only works if the client aborts the script, you can't close the connection yourself untill the script exits, without aborting the script, even if you set ignore user user aborts (I tried with PHP 4.1.2). Also the sem & shm don't help much as you can't leave a thread runnning to recieve the IPC info, unless you write the recieving program in some environment (ie perl | C/C++ | Java) that is not request-run-response-exit-oriented. You might be able to write & run a php based server program at the command line, but this is not really what php was designed for, or what it's good at.

Re:The difference for me...

[optime]

First of all you don't want to close the connection because you want to the user to see page you are generating. You can do database writes after the client disconnects. That is what he wanted to do.
Second you can leave instances running as long as you wish: http://www.php.net/manual/en/function.set-time-lim it.php. That requires tweaking of httpd.conf though.

Then what IS weak typing?

[brlewis]

Automatic conversion is weak typing in my book. Do you know some "everything is a string" language out there that doesn't internally convert strings to numbers when doing math? Just leaves everything the same type? If PHP isn't weak typed, what is?

Re:Then what IS weak typing?

[FiggyBottom]

maybe you are right. Maybe what you see as a weakness, I see as strength. But, I'm sure you agree that bad code can be written in any language. "It's not the size of the boat, it's the motion of the ocean."

Re:Then what IS weak typing?

[Anonymous Coward]

"weak typing" is a technical term, not a critique of the type system. you dolt.

Re:Is THIS a JOKE? Nobody cares about UNICODE!

[Anonymous Coward]

Unicode is dead. R.I.P.

Show me the money!

[BeerMilkshake]

Articles like this are totally subjective and always boil down to what one person likes or how much they know about their pet technology.

What I don't see here is an objective comparison of how many $$ or how many lines of code it takes in one or the other. You can wave your hands around all you want in a passionate argument about architectural 'grace', but I remain unconvinced until I see the code, and the person-hours.

It all drives me crazy, because our clients see these little religious wars and it drives down their level of confidence in us as professionals. I build something in Java/PHP, and some other contractor says 'I could do that better (faster,stronger) in PHP/Java'. In the eyes of our clients, we're both idiots when we do that.

At least in Civil Engineering they can do hardness and durability tests on different recipes of concrete. Maybe I should have done that.

Re:The Superiority of PHP over Perl

[BestNicksRTaken]

Really good joke that one, you almost got me up until point #3 where I realised you were being sarcastic. The data structures thing really took it too far though dude....

Umm, hello... Yahoo!

[Anonymous Coward]

How is that for scaling?

Hmm, PHP runs the biggest website *ever*.

Why would you try to argue against it scaling?

Re:Umm, hello... Yahoo!

[Micah]

where does Yahoo run PHP? I believe they use Python quite a bit.

And Python, with mod_python or maybe Twisted, can probably scale much better than PHP.

Re:Umm, hello... Yahoo!

[one4nine4two]

http://www.google.com/search?q=php+yahoo

well finally

[alexborges]

.... Someone Had to Say It:

Your application's Scalability is directly proportional to the number of well used neurons by the application's programmer and the sysadmin.

Java has nothing to do with you being stupid or smart, neither does php.

On the other hand, Sun has a lot to do with the fact that most ITManagers are brain dead trolls that drool over whatever the um... 'leaders' of the technology revolution of the 'Internet' tell then.

Debunking ...

[angel'o'sphere]

The PHP Scalability Myth
The author should focus on PHP and what got improved there over the last years and not take an inocent other language into the dispute.

Comparing PHP with Java is not like comparing Apples and Oranges, as both are fruits, but like comparing Cheese with Bread ... two only slightly related topics.

What is Scalability?
I dissagree with the author. Scaleability means: if I have a solution, and throw twice the problem (more requests, more data) on it, does it *only* need 100% more resources? Can I extend that by throwing 3 times, 4 times and so on the solution? Where is the point where the solution breaks? When I have it working on a problem ten times the original size? Or can it take 100 times the original size?

Language and Database Performance
Java performs as nice and well as a compiled language like C++. At least under Windows it beats both borland C++ and Visual C++, sometimes by a rather hughe factor. Hint: www.heise.de/ct latest articels about .Net/C# and Java/C++ performance.

Database connectivity is not really an issue if you compare "languages".

Comparing Architectures
The way you define an architecture is not the problem in a PHP vs. Java comparision. In PHP you can not keep objects in memory between different web acesses. You have to save the context allways in the DB. In Java you could use a prevalent system, or files, and cash all objects in memory.

The claimed RMI overhead in a Java N-Tier application only exists if you have each Tier on a different server. And then you have the SAME problem in PHP as well. The author points that out a bit late.

Stateful and Stateless Architecture
Nothing much to say here. IMHO an external session store is no real issue. The issue is keeping INTERNAL session state over several requests. To be able not to relly on the DB.

The Convergence of Web Application Architecture
I dont see the convergence. Where does PHP have something similar to container managed persistance for entity beans?
Where does PHP have something similar to container managed transactions and container managed access rights and role managemnt on method level for clients interacting with session beans?
Not at all.

If PHP on top of Java is scalable, then why isn't PHP on top of C?
Because PHP on C ... or PHP in a typical PHP engine, lacks the JVM :-) In a Servlet engine every request knows about all request made by the same session before. So all objects ever created by the same session reside side by side in memory until the session times out or they get removed.

In PHP my previous requests need to know which requests likel will come later. And they have to prepare that by storing all relevant data further requests might need in a DB. Basicly: all PHP applications are only DB frontends used via the web. The simply contain only out of three kinds of statements: html formatting, sql select and sql update statements.

True business logic is impossible in PHP ... as you can not reliable isolate parallel requests, except via the DB.

You can hardly reuse PHP on the business logic level as you are far to strong tied to the DB you had in your initial design.

You can not deploy "components" on different servers with differnt back ends and different configurations for the accessing front ends.

Sure: there is a class of applications for which PHP perfectly suits. But the classes of applications for which Java suits and PHP not, is much bigger.

PHP is only suiteable if you can write the application very monolitic. Java suits well when you can divide the Application up into individual components which get assembled and deployed later to form the application.

Regards,
angel'o'sphere

All your web pages are db-driven?

[brlewis]

At least with the Apache 1 model, every process is going to have a connection open whether it's serving a page that will use it or not, so it's essentially wasted. You don't have this problem with connection pools.

How do PHP persistent connections work in the Apache 2 model, I'd like to know? Hopefully it's a connection pool behind the scenes.

PHP scales extremely well

[Anonymous Coward]

Well I think I run the biggest PHP web site out there (neopets.com) (>270,000,000 pageviews per day), if anybody has a bigger one Id like to hear how you have managed to scale it up so high.

We use PHP accelerator, our own custom-written connection pooling software, and have over 110 web servers doing about 980 megabits of traffic at peak, and yeah the bottleneck is our database not PHP.

The thought of using any other scripting language makes me rather ill!

Adam

too bad you stopped.

[temojen]

The next sentence reads

This overhead was removed with the EJB 2.0 standard,

Faster free-software servlet engine

[brlewis]

Then use Jetty.

I maintain my challenge for PHP.

[markv242]

Show me a PHP site that does completely transparent load balancing and failover of session data without hitting a database to re-load your session data on every request.

Show me a PHP application that uses session data that can scale to more than one machine, without hitting a database to re-load your session data on every request.

Any half-decent Java app server will do that sort of thing without requiring any supporting code.

Re:PHP Secrets In The Light!

[loginx]

very clever

How about 90k?

[Synn]

Just ran a quick line count on our dev server and got back 87,501 lines of code. Up until a month ago I was the sole developer for 3 years.

Oh, and I'm our senior Linux admin as well. So I got to do those duties as well. Joy joy.

I don't think strict typing has anything to do with it. Java development scales well because of projects like struts which let you seperate the layers of the project across different departments.

In PHP and Python I'm absolutely certain a single developer can handle more lines of code than in Java. The languages are just so much easier to work with. But Java's design does make it easier to have multiple people working on the same project.

Re:How about 90k?

[Anonymous Coward]

Just ran a quick line count on our dev server and got back 87,501 lines of code. Up until a month ago I was the sole developer for 3 years.

Being the sole developer is probably what saved you ... :-)

JSP vs PHP vs ASP.NET vs mod_perl vs whatever

[Art_XIV]

Scalability, maintainability, and performance are derived from a factor much more important than the choice of language/platform, and that is the developers who are creating the site/application.

PHP, mod_perl and ASP projects can turn into unmaintainable morasses quite easily if the coders aren't careful, but Guess What? So can JSP and ASP.NET!!!

The most royal piece of sh*t intranet site I've ever seen was a JSP-based one done by a series of contractors. It was nice'n OO, alright, but this didn't help at all. There was absolutely no consistency in the 'design', they were failing to close recordsets, they weren't using stringbuffers appropriately, business rules in page-level code, etc. It wasn't unusual for users to have to wait 30+ seconds for responses. Thank Buddha that they weren't using EJBs! Happily, it was salvagable w/ many corrections and much refactoring.

This isn't a slam against JSP. JSP can be beautiful and offers great performance when done well. But so can PHP, classic ASP, ASP.NET and mod_perl! Well, maybe not classic ASP! ;)

What really counts is the developers who are working on the project. The knowledge, experience and self-discipline of the developers will always count for far more than choice of platform.

If a company wants a fast and reliable website/web-app then the choice of using JSP, PHP, ASP.NET or mod_perl is pretty much a no-brainer... just go w/ whatever will most closely fit with the technologies you are already using and/or the tech that the company would most like to support/have supported and make damned sure that the developers are up to speed. Using the cheapest generic clods that you can find is a sure recipie for failure.

Will we still be derided for saying PHP is fast?

[Anthony Boyd]

Whew. Some of us have been experiencing this. It's nice to see some data to back up what I've been living through.

We already knew that

[Slime-dogg]

PHP is great! It serves up pages even during a /. attack... It even serves up the "MySQL died" type pages rather well.

Meh.

[JMZero]

Scaling != performance

That's why he spends a lot of the article talking about architectures rather than individual machine performance - it's architecture that's key to scalability. The article is right on in this regard.

DB is the bottleneck for most websites... Java did considerably better than PHP in terms of both

This may well be true (though I haven't looked at benchmarks lately). Still, it isn't a problem inherent to script languages - just something to be fixed. ...like charting in a web page (well, in a .PNG), things can get messy. Yeah, you can do that in C, but what's the point ?

The point of doing it in C is to do it well (and it's really not hard, I do this fairly regularly). Neither Java nor PHP is a good language to do image processing in. Either may perform acceptibly, but they're just not as good at it as C. And there is nothing wrong with mixing languages in this fashion when the relative strengths are so disparate.

In any case, most developers are going to be using an opaque third party tool for charts, and the calling language (if it's even being called by something on the server at all) is going to be irrelevant.

Using a tool for web development doesn't mean it needs to be the only tool in the process. If my PHP database connector is written in C, it's not like the system suffers some horrible everything-is-not-the-same meltdown.

Basically, the article was on target: in the architecture shown, the differences between a scripting language, Java, or even CGI needn't affect horizontal scalability - and this (and database scalability of course) are the only things that matter in the end.

In terms of server counts required, we're back to a straight performance question - and that's another article.

Get the most out of that aging single server

[brlewis]

Jetty running on that single aging server will blow the doors off of PHP. That's what I saw when I did some BRL benchmarking some time ago. Presumably you'll get similar results with JSP.

you are wrong

[Ender Ryan]

You do not need strict typing for large projects, that is the mantra of people who do not know Perl, PHP, Python, etc. well enough to have a valid opinion about the matter.

I have never found that lack of strict typing damages maintainability.

Besides, 100,000 lines of PHP, Perl, or Python probably does the equivalent of 1,000,000 lines of Java, so it's not a good comparison in the first place.

PHP Code Maintenance?

[droolfool]

Many people just keep saying "Java scales better". However, for small (and even mid-sized) projects, Java's overhead is just unacceptable, and you end up using a BFG-9000 to kill an ant.
I may agree that PHP code is sometimes terrible to maintain, but one has to understand that Java can be a PITA too. Many PHP coders don't even try to make their code at least well-organized, embedding whole queries and stuff like that inside the HTML code. That could be easily replaced by a template system, but it takes more time, so they just do things the fastest (and dirtiest) way.

Look at Javalobby.org for a comparison

[Anonymous Coward]

It crawls under a small fraction of the load of Slashdot. Surely such a site would employ Java "best practises".

Systems Administration Scaleability

[FuryG3]

I oversee a team of web developers and administer a production and development linux network for them, and there is no question that we use php over jsp. Anytime they're designing from scratch and we know something will need scalability, they go with php. I can only provide insight from a systems administration point of view. For small projects, it really doesn't matter, but every JSP project I've seen go from small to big has ended up running slowly and poorly.

JSP is what has always forced me to get bigger hardware, never php. We have some php guys, and some jsp guys, and many that do both. Obviously it's hard to get a good reading as to which is easier to scale, as everyone is biased... but from what I gather, JSP is slightly easier to scale from a coding perspective. With only a marginal difference, I (and my development team) favor PHP for new projects as JSP tends to give us headaches while php runs quickly and quietly.

I'm sure others agree, I'd love to talk to a linux admin for Friendster and see how much he likes JSP....

Re:Systems Administration Scaleability

[martser]

jsp, php, asp if it just scriptlets without middleware then apps will be slow as they grow

trademarks

[TekZen]

When we recieved our trademark we were told that it needs to be everywhere we say Emma. So it was actually our lawyers. Luckily for me the whole thing is templated and branded, so I didn't have to do anything to make the change and our designer only made the change in one place. -Jackson

Re:trademarks

[nicomen]

heh, gee:

perl -i -pe 's/\sEmma\s/Emma(R)/g;' *.php

Re:trademarks

[TekZen]

That is not q very good solution for an enterprise codebase.

Re:Pathetic Heap of Poop

[Anonymous Coward]

Okay, please explain how calling you a jackass is Fear, Uncertainty, Doubt?

Missing the point, again, and again...

[aurumaeus]

People seem to forget that it's not scalability, or even performance in general, that limits the reach of PHP-type languages compared to Java. It's the enterprise libraries, programming conventions and built-in features of Java (security features, strict implementation of OO style and type checking) that make it enterprise. PHP does NOT have the architecture, design patterns and frameworks to support complex, MAINTAINABLE design for big apps. I use both, Java in the office and PHP for my own web programming.

Frankly, I wouldn't dream of trying to write the banking software I build in PHP... what a nightmare! People need to learn that the issue isn't one of quality, but of targeted useability. PHP and Perl have their uses, it's just not enterprise software. I mean, hate it as I might, C#/.NET is an actual competitor to Java in that area, but PHP/Perl will never be.

Re:Missing the point, again, and again...

[chromatic]

PHP does NOT have the architecture, design patterns

Do you mean that PHP does not provide class libraries with names of Decorator and Factory or that a good developer cannot use design patterns in PHP?

strict implementation of OO style and type checking) that make it enterprise

Do you mean that languages such as Smalltalk should never have been used for "enterprise applications"?

PHP is too sloppy

[Anonymous Coward]

I've been programming in PHP professionally for 3 years, and I can say that it is one of the sloppiest languages I've ever used. Don't get me wrong, it's otherwise a wonderful compromise between C and Perl, but it is too prone to bugs.

1) It has only a variant type, which causes confusion when NULL, "", 0 and "0" need to mean different things.

2) The lint check does not pick up obvious typos.

3) Most bugs are not found until the code in question is run.

4) If you miss a quotation mark, you get strange errors hundreds of lines away (very hard to track down).

I love writing in PHP, but until they have a strict option like Perl, and the ability to declare types other than variant, I would hesitate to use it for another large project.

How to get "rep on the street"

[Anonymous Coward]

Step 1. Decide you want to be a big shit.
Step 2. State something obvious but hype it up
so it sounds profound.
Step 3. Get rich on the book circuit.

Here is my planned article "PHP can scale just as poorly as Java".

Well no shit.

Re:Pathetic Heap of Poop

[Anonymous Coward]

Maybe his potential mate is reading slashdot right now.

Re:Pathetic Heap of Poop

[Foofoobar]

If I have to explain how an insult creates FUD in a social network then you are more stupid than I originally thought.

Never under estimate the LOW IQ of an anonymous bastard.

And you are talking about

[Anonymous Coward]

Java, right?

PHP scales as well as java

[Lac]

... Java scales?

huh?

[Ender Ryan]

If you are using the db a lot, pooling isn't going to be terribly helpful compared to persistent connections. Also, I can't imagine it would be too difficult to write code in PHP to handle pooling db connections, I started doing that in Perl a few years ago and dropped it because it wasn't beneficial. But it's not too hard...

Re:huh?

[vlad_petric]

Assuming you're using a real DB like PG (not mysql, I mean), with persistent connections you're gonna create a new connection for each user ... that just sucks big time ... For PG it implies spawning a new DB process.

Two words...

[Anonymous Coward]

Yahoo

Glad to hear this report for "scripting languages" in-general. Java managed to avoid getting branded as a scripting language by having a compiler, even though it runs in a VM just like a scripting language. The VM of a scripting language, the compiler of a low-level language, and all the disadvantages of both...

'wish there was something like this for Python.

How much is per the programmer...

[Coplan]

I've been working a lot lately with PHP, and I realize that my stuff isn't nearly as scalable as it could be. But I don't consider myself not understanding the language...jsut not as much experience.

My point is, however, that the ease-of-use directly affects scalability. Assuming that both Java and PHP were equally scalable....the issue then falls to how easy it is to get there. Does it become an education thing? Or does it become an ease-of-use thing?

I'll admit, I know nothing of Java. Never tried. So I can't honestly say that one language is easier than the other. Maybe Java is easier than PHP? If so....maybe that's why Java seems more scalable.

What the Jboss guys have to say about this

[TheNarrator]

Here's what Bill Burke of the Jboss group has to say about all this:
Over at the ServerSide

Posted By: Bill Burke on October 17, 2003 @ 10:51 AM in response to Message #98961.
First, let me say that PostNuke is an excellent framework. Very early this year, we ported the JBoss website to PHP PostNuke because we loved the functionality. Unfortunately, it didn't scale one bit, even a little bit. The main culprit, I believe, was that PHP PostNuke made SQL queries for every part of the webpage on every single HTTP call. No caching what-so-ever. It brought www.jboss.org to its knees and our community was upset for a few days until we brought back the old JBoss driven website.

Since we liked Postnuke so much, we decided to start Nukes on JBoss. Which is built upon J2EE and JBoss and is now running www.jboss.org since May thanks to Nukes creator Julien Viet.

Is Java more scalable than PHP? I don't know. But Nukes on JBoss is definately orders of magnitude more scaleable than PHP PostNuke. We know from experience.

Bill

Strict Typing

[jbottero]

"PHP doesn't have strict typing, so it's harder to maintain."

That's not a language issue, it's a programmer issue. Learn good habbits.

Too bad PHP can't handle sessions properly.

[Anonymous Coward]

PHP might be good for somethings, however, it is only for single tasks as I have yet to see a PHP enabled website be able to interlingo with multiple sessions without corrupting data between 2 browsers.

Java sucks

[HazMathew]

Java sucks. SUN is dying, McNealy is driving it straight into hell. Its too bad really.

Re:Java sucks

[Anonymous Coward]

Yeah, i'm sure Java won't live on without Sun, considering the sheer amount of large companies that have ported all of their mainframe coding over to Java.

sheesh.

PHP and security

[Anonymous Coward]

php is a piece of bullshit :)

Re:Is this a JOKE? PHP doesn't even support UNICOD

[lokedhs]

As a person who has the need to write text in more than one language, it pisses me off to no end every time I see that a site doesn't use UTF-8.

At least in Java, it's very simple to set a whole site up to use UTF-8 all over once and for all, and thanks to the native support for unicode throughout the language everything just works, automatically.

I can't remember seeing a single PHP app that handled multiple languages in any was even closely resembling sane.

I'm not a programmer but...

[Beavis!]

...From the end user experience, I'll be the first to say Java is a festering piece of shit. Every time I've had to run a Java based applet in a browser or (god forbid) over an X session, it's been ungodly slow! Java DOESN'T scale well if you are talking performance. And now the company I work for is moving to a Java based client application for a big database we have. The bandwidth alone is going to gobble up our network when our 2000+ users all come in in the morning an launch the app. Java Sucks. If you can keep this shit all on the backend with PHP, more power to you.

CGI model vs. in-process model

[stu42j]

I hate it when people talk about "CGI model vs. in-process model" or whatever. Even if your interpreter (PHP, Perl, JSP, etc) is running "in-process", you're still using CGI (assuming that the user is sending data).

CGI is not about how the web server interacts with your program - it is how the web browser sends data to the server.

If you've got something like: http://mysite.org/foo.php?key=value

You are using CGI! Sorry, just one of my pet peeves.

Any want to banner/mention Jython?

[Anonymous Coward]

I understand in raw power python with java really whips a llamas ass or something...

in other news yet again...

[Paul d'Aoust]

I had a serious case of PHP scales once; I thought it was a rare disease, but now I see it's being given exposure in respected news sites like Slashdot. Word to the wise: cortisone cream gets rid of it. Worked for me!

True, but linear and near 1.0 factor implied

[Morgaine]

That'd be the definition of linear scaling. Scaling can apply to n, .5n, or other rates. So, saying X and Y scale at the same rate could they both scale at 0 (ie, adding machines have no effect).

You are of course right.

However, everyone uses the phrase "it scales" without further adornment to mean "it scales linearly and with a factor of not much less than 1.0". That's just us humans taking sensible linguistic shortcuts. :-)

On a more academic front, there are two separate issues to consider, the first being linearity (the scaling factor not dropping off as you increase N, ie. overall throughput remaining on the straight line), and the second being the value of the scaling factor, as you point out. They're both important in practice, simply because in the real world it's not just scalability that matters but also absolute performance and efficient resource utilitization as well.

Developer vs. the tools

[HotButteredHampster]

I think that you make an excellent point, but with a caveat: the tools do not make the developer.

I am in the midst of rewriting a PHP app. Why am I rewriting it? Because you are absolutely right: the original PHP app was impossible to maintain. However, the new app is being written based on the lessons learned in the first and is being built using OO principles from the authentication to the page output to the form input. This new app will be maintainable and also extendible.

They are both PHP apps, it's just that one was written well and the other wasn't.

You can write good C code and bad C code, good Java code and bad Java code. PHP deserves special recognition though: it's really tempting to write unmaintainable code.

HBH

Re:Developer vs. the tools

[KDan]

On the other hand I have to admit that the quality of code written in Java can be quite abysmal. I am right now working on this project and man, it's so coupled between all the layers that it's a complete pita to work with, let alone work on... Definitely I'd rather have to work on a well designed PHP app than a badly designed Java app.

Daniel

Opinions and assholes...

[dasspunk]

There's a lot of both in here...

After reading all the comments, it's clear that everyone thinks they know the right way to do things... and I thought it was only guitar players.

C has always been loosely typed

[Anonymous Coward]

...because you could always break the type abstraction. A warning does not a type system make.

Re:C has always been loosely typed

[yerricde]

because you could always break the type abstraction.

You can do so in the Java language as well: serialize an object to a byte array, modify the byte array, and deserialize the objects.

A warning does not a type system make.

-Werror anybody? (-Werror is a GCC flag that treats C warnings as errors.)

Re:C has always been loosely typed

[AKAImBatman]

Actually, a forced cast will let you do that in most circumstances. Of course, that's exactly why you don't cast if you don't need to. People who ignore their compilers generally make life hard for the rest of us.

Different Animals

[Anonymous Coward]

It seems that many of the comments here seem to focus on a small range of issues. Though many of them have valid points, I believe that most are missing a fundamental piece of information: PHP's way of doing things is not the same as Java's.

Take, for example, connection pools. A large number of the posts here keep harping on how important they are to scaling a database. This is true; having one connection per process is relatively inefficient. On the other hand, I view this as a mixed blessing, as having every single web page hit the database is most often a bad design. By having this inefficiency, I am forced into doing things the right way, rather than the "cool" way. In the web sites that I've worked on, the database connections were not an issue, due to the fact that most page hits got a cached version of the page rather than a "live" version, thus reducing the number of database hits to once every several hundred hits rather than on every hit. Though they would still be useful in several types of applications, I don't personally need connection pools.

Of course, there is also a fundamental reason why PHP likely won't support connection pools soon. As far as I know, the limiting factor is the forked-model that Apache uses, which prevents the implementation of the neat tricks that Tomcat has. Though it would be nice to have many of Tomcat's features, the one that I don't care for is a seg fault to take down the whole web server. Apache's model generally prevents that from happening. I view this additional stability as an "enterprise" feature which Java does not sport.

A futher example would be that of object-oriented programming. Though I love doing some things in Java, there is something to be said for PHP and C's style of programming. Do people realize that the Linux kernel, as well as most of the FSF's projects (GCC included) are procedural programs, not OO programs? Some people seem to think that a large to huge application is a maintenance nightmare unless there are five levels of interfaces and abstract classes. I've found it to be quite the opposite; OOP has diminishing returns after a certain point. Though OOP is still a great way of doing things, it is hardly a panacea. The recent interview with Bjarne Stroustrup is quite enlightening on the whole topic, for those interested.

PHP has a funamentally different way of viewing things than Java, and I've found it to be incredibly fast. My company serves a few dozen midsize websites off of our load balanced cluster of 4 servers, all connecting to a single backend database, and we've found that we could ditch two (or maybe even 3) of the clustered servers and still get the same overall performance from PHP.

Well yes, actually.

[autechre]

Almost all (if not all) of freshmeat.net's pages rely on the database, as that is where all of the project content is stored. It's written in PHP. I believe there may be some sort of cache in between at least some of the public pages and the Internet, but I'm not sure. We get a few hits now and then.

This is especially true for applications like a search engine, where it's difficult to implement them without hitting the database multiple times.

What broken ass load balencer...

[T-Ranger]

are you using that it dosent have Persistence, (Affinity in cisco-speak)...

Especially when you can get it for free linux virtual server. Yes you could pass along all your values in hidden form fields. But then you could also write a C++ compiler in cobol.

Re:What broken ass load balencer...

[crazyphilman]

Sigh... You know... Aside from the load balancing issue, it wasn't so long ago that people were advised not to use session variables at all because under heavy load, they use up too much RAM on your server. Methinks you read too many vendor brochures... But, I'll be nice and explain why using hidden form fields is NOT like trying to code a C++ compiler in Cobol (god, what a weirdo analogy -- you think that one up all by yourself?).

Putting values in hidden form fields means you don't have to keep them in your server's memory. Because they're in form elements, they're not even in client memory. They only exist in memory during the actual HTTP post, and then only while the page is being loaded. This is a Good Thing. Because when your site is being hit by tens of thousands of people, and you're processing, say, seventy five pieces of data each, you're going to be using a whole lot of ram if you go with session variables instead of form posts. And, session variables are PERSISTENT. Let me say that again. They're PERSISTENT. This means that they're held in memory as long as that person has a session open unless you null 'em out. If you have a bunch of dropped sessions, or sessions where the user just went out for coffee in the middle of things, that's memory that's dead for all extents and purposes until the session times out. Which could be set to hours, depending on how smart your webmaster is. SO SESSIONS SUCK. They suck RAM, and they suck processor power. Don't even get me started on the idiocy of using a database for session management -- who the fuck thought it was a good idea to put a call to an external database in every page load??? That's even slower than file access for fuck's sake. Talk about speedbumps...

See, you'd know that if you were the kind of developer who looks into different ways of doing things, instead of just doing whatever the SAMS book tells you to do. Let me guess: you got a book on web development, it told you all about session variables, and you were sold on the idea. No critical thought, no consideration of what using session variables MEANS, just "Ok, it says to do it, I'll do it and that's the way everyone must do it".

Ugh. People like you... Arrogant, closed-minded recipe followers. Bark at someone else, my little chihuahua.

Re:What broken ass load balencer...

[Anonymous Coward]

The overhead of using a session is nothing compared to the overhead required when using hidden fields to keep track of state. The re-validation of all the hidden field data and the recreation of all the user objects for each and every request is totally inefficient.

10 000 users with 100kb of data in the session (that's a lot of data), is only 1 gb of memory. So just throw an extra GB of memory in the machine.

Using sessions will be more secure, easier to code, easier to maintain, and faster. And for most applications, the amount of memory for each user in the session will be far less than 100kb.

I cannot imagine a serious web application being coded using only form data to keep track of the state. Simple apps no problem, but for complex apps it would be a detriment to performance and a pain to deal with. So I'm not sure if you are just trolling, or merely misinformed.

Re:What broken ass load balencer...

[Arthur Dent]

First: have a gander over here.
See?, there's no way to be sure that the data in the hidden form element you're getting back is the same stuff you sent. Which means you have to check the data thus <quote>sucking up RAM and processor power</quote>

. As for databases being slower than file access, have you ever heard of In Memory Databases?

Sheesh. Talk about arrogant, closed-minded recipe followers!

Re:What broken ass load balencer...

[T-Ranger]

I have only ever once read a SAMS book. That was enough.

You say pass session information around in forms. Ok, what about the other 95% of the time when users click on links and not POST a form? Where do you get your state-on-the-client data from then?

Webmasters can set session timeout limites to stupid values so sessions suck? WTF? With state-on-the-client your trusing the client for all your data arn't you? Security risk much. Your coffee buddy gets up and then someone else sits down and has his session. State-on-the-client NEVER times out. You want to be paranoid about security then timeout sessions at 30 seconds. Leave it up to the client and your fucked.

Session information should be fairly small. I would rather have 100k in cheep and getting cheeper memory then have 100k POSTed to me accross the expensive and staying the same network.

See, your the kind of developer that learnt how do to something in 1994 and has never looked at anything since. No thinking about the evolving state of the art, just "Thats the way I learnt to do it and thats all I care about. Good enough for Berners-Lee, good enough for me."

Re:What broken ass load balencer...

[jamesmrankinjr]

So, let's say there can be twenty pieces of information for each user session. That means you need to push 20 hidden fields into EVERY PAGE GENERATED IN YOUR APP. Also, EVERY ACTION BY THE USER HAS TO BE A FORM SUBMIT, OR THE HIDDEN FIELD VALUES ARE LOST.

Now let's say you have a new requirement and you need 21 pieces of user information for each user session. You need to go to the template for every page in your site and add another hidden form field! Good thing you don't charge much as a developer, otherwise the time you spend doing this busy work would cost more than just buying some more RAM or another pizza box.

Also, pushing all the data into every page and fetching it back on every user action increases your network utilization. But we don't need to worry about that, right, because the only things that cost money are processors and RAM.

I'm sure I must be missing something here, so please enlighten me.

Peace be with you,
-jimbo

Re:What broken ass load balencer...

[Anonymous Coward]

> it dosent have Persistence, (Affinity in cisco-speak)

Uhh, HTTP is stateless. If your connection dies mid-request, the user presses Refresh and all is well. You don't WANT TCP persistence.

Re:What broken ass load balencer...

[crazyphilman]

You can't EVER assume you've got good data from the user. You ALWAYS have to check it. And re-check it. And check it again. If you're not doing this, you're way too trusting...

As far as main memory databases go, well, that's all well and good, but *what if my shop doesn't have one*? And, what if we're constrained to only use approved vendors, thus can't get one? And, what if the people managing databases are in one department, and the people managing the web servers and network are in another, and the programmers are in another again, so that you get the database that is provided for you, period. So you can't just order up whatever you want, even if it would be perfect for you.

YES, there are solutions that would address some of the things I mentioned. But, NO, not everyone can use them. I know it's stupid, but it's life.

And, I only called him that because he was rude to me.

Re:What broken ass load balencer...

[crazyphilman]

Harsh, buddy, harsh.

First off, ok, I was rude to you but you were rude to me first. I guess we're even.

Now let me defend my position.

When you're programming in a large enough institution (like, say, the government where I work) your webmasters are in one department, your network admins are in another, your database guys are in another, and YOU are in applications development. You can "ask" your webmaster to set up sessions in a certain way, but he may or may not agree with you. He might have his own way of setting up sessions, and he might not be interested in your opinion. Things get complicated. Another thing is, sometimes you have to share your server with as many as hundreds of other applications, so depending on how good the other programmers were, resources might be extremely thin. And you can't just order up more RAM or processing power, because now you're asking another department to screw up their budget for YOUR sake. They're going to say "Tough luck, guy; maybe you should make that app a little more lightweight". What then?

Here's something: when you're serving up static content, you're not going to have any state on the client, period. The only time you're going to be passing state (even with a form post) is when the client is in the middle of performing some task. In other words, the client has begun some process, and you're walking him through it. Form posts are a natural approach for this sort of thing. It's what they were designed for. I don't see why you're having such a problem with them.

If you're worried about something like a login, that can be put in the session without impacting RAM too heavily. But you could also take the userid and password the user supplied, concatenate them, encrypt it, and stick it in a session cookie, too, couldn't you? Then, every time the user does something that touches your database, you fetch the cookie and doublecheck the user's login. Since all the encryption is done on your server, you're not going to have to worry too much about the cookie getting hacked, and you can embed a timestamp and expire the thing easily enough. THEN, you're only using resources when the user actually DOES something, instead of using them up continuously. Is your problem with this approach because it's too old? Not shiny enough? I don't think that's a fair way to assess an idea. Arithmatic is thousands of years old, but without it, you're not balancing that checkbook, now are you?

And, let me point out that you're ALWAYS getting data from the client, even if you put it in a session. You ALWAYS have to doublecheck it. So that's hardly a fair criticism.

1994, eh? Yeah, I was programming back then. So what? I had my first website in '95, before any of this crap hit the mainstream. What's your point? Old = bad? Ha, that's rich... If that's true, better not use Linux/BSD, because it's thirty years old! Oooh, better use Windows Server 2003, it's shiny and new!

Or... Not!

Re:What broken ass load balencer...

[crazyphilman]

Ok, I'll "enlighten you". You ARE missing a lot.

First of all, I thought your point about going from twenty points to twenty one was hilarious. What, do you think you're not going to have to add code when using the session? You have to recode your app whether you use session variables or form posts. It comes out to about the same amount of code, too. See, if you're smart, all those hidden variables are tucked into the page by your server side code in one fell swoop -- so you don't have to recode the HTML, just the server-side scripting. And, it takes the same amount of coding as fetching from a session. So that's a great big fat red herring you threw out there. Besides, how are you coding your pages, if you have to update every page on your site when you change your code? Why aren't you building your code into a single module you can include throughout your site via SSI, if you're using it everywhere? Are you statically embedding your code EVERYWHERE??? Why? Isn't that like jabbing yourself in the eyes to make them water, instead of using Visine?

Here's another red herring: You think you can't mix form posts and regular links on a page, because it'll ruin the form posting? If you're walking the user through some process in which he needs to pass state forward, you shouldn't be building in ways out of the process anyway! Any additional links on the page should generate a new window, leaving the current page alone. Remember, a REQUESTED popup window is generally okay. For instance, during a set of signup pages, you might want to offer a popup "help" app. Right? But you wouldn't want it to take the user out of his task, now, would you? And, that would be a problem whether you're using sessions or form posts. It's about workflow.

And, network utilization? What, for a few hundred bytes of plain text form post? Give me a break. YOUR way still uses the network, but it also uses processor, and ram, and doesn't scale (unless you waste a lot of bread)... MY way leaves the data out of the system most of the time. The only time it gets transferred is when the user is actually submitting a page as part of a process, which is a tiny, tiny fraction of the time (and would never happen for static pages). YOUR way keeps it in RAM continuously, as long as the user is online. Which takes up a LOT more resources than MY way. Maybe I'm old fashioned, but Jesus, keeping all that in server RAM just seems nutso to me. Distributed processing is not a bad thing!

Anyway, these are the things you're "missing". I totally get that there are shops that use sessions to the hilt. But those shops spend way more money and have to acquire way more equipment than shops which do things the "old way". Sure, both methods work. But mine is not invalid just because it's old. And, mine is a whole lot more lightweight than yours (which is DEFINITELY an issue in some shops).

Re:Pathetic Heap of Poop

[Anonymous Coward]

I've always thought of Slashdot as more of an anti-social network...

file this one under 'clueless'

[Kunta Kinte]

With gems like...

Still not convinced? Consider JSR 223, the effort to turn PHP into the front end for J2EE by porting it to Java. If PHP on top of Java is scalable, then why isn't PHP on top of C?

...I had a hard time figuring out if this was a joke article or not.

Language syntax does not count for much, nowadays since everyone has everyone elses best features. Library and runtime is what really counts. That's the point behind JSR223, and even .NET to a large extent. They've realized that in the end, it's all bytecode anyway. If the author doesn't understand that, well I dunno.

It has absolutely nothing to do with scaling.

you're a jackass

[Anonymous Coward]

Your reply constituted 4 sentences: 1 to concede, and 3 inane platitudes.

Try to find something worth saying.

Re:you're a jackass

[FiggyBottom]

at least this jackass puts her name to the comments.

Re:Pathetic Heap of Poop

[Foofoobar]

Progress always seems anti-social to those being passed. :)

What's wrong with assembly?

[theolein]

This whole PHP/Java fight is getting simply ridiculous. Isn't it about time that it stopped? If you think PHP will do the job then use PHP, if you think Java will do the job the use Java. You'll see soon enough if you were right in your conclusions.

Both have their strong points and weaknesses, just like assembly, which makes for some extremely fast code and is good for stuff like drivers but tends to take a bit longer when you're writing your webserver in it.

Re:Pathetic Heap of Poop

[Anonymous Coward]

No please, explain. At least try. Maybe you can make mi a little bit wiser.

My conclusion....

[IA-Outdoors]

Having read a lot of the posts with their information and misinformation on this topic I think it is safe to say that there are idiots on both sides of the fence. A buddy of mine mentioned that maybe someone should implement the infamous pet store application in an attempt to show that PHP can scale to a large degree. That has been the best idea I have heard.

Re:Pathetic Heap of Poop

[Foofoobar]

Sorry but I can't perform miracles. Try reading a book on it. You can find them at your local library. :)

AMEN BROTHER!

[galacticdruid]

Couldn't have said it better msyelf. Very well stated, :-)

Anything can scale with enough effort

[l0ungeb0y]

I'm a fairly advanced PHP developer and use things like Open Mosix to afford SMP to apache and my php-daemons.
I have used PHP to create stand alone services utlizing TCP/IP over SSH tunnels to create distributed networks, multi-user environments, supply real-time XML data and provide database synching across networks as well.

It comes down to the coding I think.
Out of the box, PHP is probably not as scalable as Java for several things beyond a simple web-store or blog.

But, if you go the route I did and spend several months creating a custom object architecture, you'll find many ways to pull the proverbial rabbit out of the hat and afford enterprise class solutions with a lowly scripting language.

Java is great, and I intend to use it more due to market demand. But, I get lots of interest in my library and have used it in production in 3 services so far in the year since it hit 1.0. Perhaps it's time I did a code review and posted to sourceforge, an object architecture that supported portals and daemons out of the box could be useful even in th face of PEAR and PHPNuke.

Re:The Superiority of PHP over Perl

[Make]

wow, that was really an entertaining read!

PHP i18n mailing list

[yerricde]

Aren't all characters in PHP 8 bits? What about internationalization?

Ask Google and you shall receive. PHP seems to support UTF-8, and the developers hope to have more extensive internationalization ready by version 5.0.

Re:Pathetic Heap of Poop

[Anonymous Coward]

You call that trying?

The web isn't everything....

[Anonymous Coward]

Let me preface this by saying at first I was a _big_ PHP skeptic due to the bad experiences i've had with PHP coders (not necessarily the language).

While I could pump out a Java/JSP site quicker than many could pump out a PHP site (due to my knowledge of Java, and the many frameworks (Struts, Hibernate, etc) that exist for it, I have no doubt that a mid-range programmer who has equal experience in both could probably rattle out a PHP site quicker.

PHP is great for:
- small webapps
- mid-size standalone webapps

J2EE is great for:
- mid-size webapps
- large webapps

Much of the reason behind this is that many of the large webapps in the real world need to leverage legacy systems (AS/400...etc). To make a PHP app seamless with existing systems is difficult, and sometimes impossible.

Much of the idea in Java is to abstract away anything to do with the web as far out as possible, so that the application logic can be re-used by webapps, client apps, mobile apps, and whatever the next big or little trend may be.

I rely on PHP apps (phpmyadmin, forum software, web mail software) for much of my development, and I consider them invaluable tools. They're written in PHP, and for what they do, they're absolutely wonderful.

I'm not sure if many of the "Java sucks" crowd have been employed by larger companies where the apps they create need to be maintain and understood by large, revolving teams.... but things like Design patterns allow fresh faces to quickly understand. Layers of abstraction allow different teams to work concurrently better.

If I was a contractor working on a standalone medium size webapp, it would probably be cheaper to do it with PHP. But in my situation, I don't know the scope of the project ahead of time. Requirements change often, and I can't know if my software needs to be extensible, and if other apps will need to re-use my business logic down the road. I'd rather play it safe than sorry, and build something that can play away from the web as much as possible.

Re:The web isn't everything....

[Anonymous Coward]

Forgive me for saying that you sound like a brainwashed corporate drone.

Is this 'legacy' system AS400 you mention the same that went 64bit in 1995 without applications needing a recompile and can now run many instances of Linux in a serparate virtual machine partitions?

Also mid-range does not refer to someone with mid-ability, but someone who codes on an IBM iSeries/AS400, in contrast with a mainframe coder on an IBM mainframe or a PC programmer on a commodity platform.

Re:Pathetic Heap of Poop

[Foofoobar]

Nope. I call that telling you to educate yourself.

301 comments on which is platform scales better

[martser]

i have seen unmaintable perl, php, asp and yes jsp code ... where do i do my GOF work with php?

Re:Pathetic Heap of Poop

[Anonymous Coward]

Come on, humor me.

Re:Pathetic Heap of Poop

[Foofoobar]

Heh. Now you beg? This is getting amusing. :)

Re:Pathetic Heap of Poop

[Anonymous Coward]

No, I'm just pretty sure you can't explain how calling you a jackass is FUD.

Look at the perl guy flame microsoft..wow.

[Anonymous Coward]

What a unique opinion..anyway you wrote..

You have no clue what enterprise class means. I am a developer for a fortune 500 company with 110,000+ employees.

I work for an Ivy league medical college, and the application that is used to track all of the medical students in the US is written in VB. Plus the hospital we are affilliated with writes some apps in VB also. Maybe you don't use VB for large apps, but that doesn't mean no one does.

Personally, I like VB but I work with Java. It is a waste of bandwith to write posts flaming away at people and personally attacking them based on your own personal preferences. Yet that is half the posts on slashdot. Yes I know, I must be new here. (here comes the guy with the "new here" handle).

Re:Pathetic Heap of Poop

[Foofoobar]

or can't comprehend...

Heh. This is hilarious. What 3rd grade tactic are you going to use next?

Re:Pathetic Heap of Poop

[Anonymous Coward]

I guess that means you really can't explain it. Fine with me.

you're not referring to vb.net

[Anonymous Coward]

Obviously you are referring to VB6 and earlier and not VB.Net, which is a true object-oriented language (with the same lame syntax) so I won't go into any more of that.

I am a developer for a fortune 500 company with 110,000+ employees.

That means absolutely nothing in terms of credibility-- Fortune 500 companies do hire idiots, too.

However, many "enterprise" applications consist of a simple program running on the client (like a VB program) and all it's doing is transferring data to and from a back end database. You don't NEED a powerful language on the client side, if all of the magic is done with stored procedures and you're just displaying it.

But being from a Fortune 500 company with 110,000+ employees, you probably knew that.

running perl can handle the load that many other sites out there just crock on

Maybe it has something to do with the fact that Slashdot is hosted on 8 load balanced web servers (3 of which are dedicated to images). And you're comparing slashdot's ability to handle load compared to some dinky little server that gets slashdotted easily? I've got news for you... even cgi/perl boxes get slashdotted. It's all about the hardware. Sorry.

Thats part of the problem right there. If you dumb down a language too much such as VB, you loose all the power features that comes with a language such as C, C++. It also contributes to all the headaches in the world of IT when you have tons of piss poor code written by sup-par "programmers" that cannont grasp anything harder then VB. Trusting a VB-only developer to write an Enterprise class application is like having the "tire change boy" be your machanic. It is a stupid choice to make.

You are obviously an intern, or fresh out of school, and haven't had a lot of real world work experience yet.

Yes, VB makes it easy to write bad code that still somehow manages to work. Many languages do. Believe it or not, it is possible to be a GOOD programmer and write in VB.
If you were a real programmer, you would know that good programming is about HOW you use a language vs. whether you use it, because often you simply don't have a choice in the matter (unfortunately).

Re:you're not referring to vb.net

[AstroDrabb]

However, many "enterprise" applications consist of a simple program running on the client (like a VB program) and all it's doing is transferring data to and from a back end database. You don't NEED a powerful language on the client side, if all of the magic is done with stored procedures and you're just displaying it.

Ahh, the expert on how every enterprise runs its business I see. Well where I work we have many number crunching apps that VB or VB.Net just couldn't touch. Does VB.Net run on Solaris or Linux or AIX? Nope.

You are obviously an intern, or fresh out of school, and haven't had a lot of real world work experience yet.

Going on 9 years now champ with C, C++, Java, Perl, PHP, ASP, Python, PL\SQL, T-SQL and yes even VB on Solaris, AIX, Linux and MS Windows. How in the world can you deduce that opinion?

Yes, VB makes it easy to write bad code that still somehow manages to work. Many languages do. Believe it or not, it is possible to be a GOOD programmer and write in VB.

Sure, however, I have yet to meet one that ONLY knows VB.

If you were a real programmer, you would know that good programming is about HOW you use a language vs. whether you use it, because often you simply don't have a choice in the matter (unfortunately).

Yes, because YOU are THE only "real" programmer in the world. Sorry, but different languages cause one to adopt different sytles. The procedural mishap of VB is usually the cause for a poor program. Not to metion VB's horrid error handling and extensive use of On Error GoTO crap. If VB is so great, whey doesn't MS put out more of thier apps in it? IS SQL Server written in VB? How about the explorer shell, or MOM or MS Office or IIS or ...

Maybe YOU don't have a chioce but I do. I'll work with C, C++, Java, Perl and Python. Keep the VB away, unless it is to fix a legacy VB app or to port a legacy VB app. I won't touch a new project that uses VB. Where I work they actually LISTEN to the developers on what technology to use. That is why we are using Java and not .Net.

Re:you're not referring to vb.net

[Doctor Faustus]

Well where I work we have many number crunching apps that VB or VB.Net just couldn't touch.
And I'm sure you also have apps that are mostly just telling the database what to do, as he said.

Sure, however, I have yet to meet one that ONLY knows VB.
Who the hell hired idiots that only know one language? VB is not to blame, here; look to PHB's hiring based on a certification.

Oh, and 6 1/2 years with QuickBasic (legacy crap), VB, Java, PostScript (yes, it really is a programming language), C++, T-SQL and XSLT, if you insist on dickwaving.

IS SQL Server written in VB? How about the explorer shell, or MOM or MS Office or IIS or ...
Because those are in wide enough use to be worth spending the extra effort to use a systems programming language and pay attention to what's going on at a lower level. Application languages like VB, Java and Delphi are for internal and vertical market aps.

Re:Pathetic Heap of Poop

[Anonymous Coward]

ur ghey

Re:Pathetic Heap of Poop

[Anonymous Coward]

God damn, someone mod both of these assclowns down! -1 Offtopic!

Why Slashdot rarely gets everything-elsed

[yerricde]

Here are some reasons Slashdot runs so fast compared to some other dynamic web sites:

• Perl feature: Perl has performance-tuned string manipulation and regular expression handling.
• Slash feature: A Slashdot user's session doesn't have a lot of "state" associated with it.
• Slash feature: The Slashdot homepage and article pages presented to Anonymous Coward are cron-generated static pages that compress well.
• Slash configuration: Slashdot isn't graphics-heavy. It has an ad, a logo, topic icons, a couple rounded corner graphics, and that's about it.
• OSDN money: Slashdot has a load balancer in front of redundant application server hardware in front of a heavy-duty database server.
• OSDN money: Slashdot's load balancer has a really fat pipe to the Internet.

No, I can't think of any more reasons directly related to Perl features.

Not accurate. Sorry.

[icoloma]

There has been a benchmark between Jetty/Tomcat/Resin. I can't find the original post, but this one.

Basically they say that Resin isn't that fast. I think this has started with Tomcat 4.

How about measuring things a bit?

[icoloma]

we use PHP here for huge web applications.. we have six servers pumping out one website and it connects to a redundant database server.

The same system in java probably would not work, and if so would take up so many resources as to be no efficient.

Well, I have seen a bit of Java the last four years, and can tell you two things:

1.- To check the performance of things you have to _measure_ and not _guess_. Words from the gurus out there, not mine. If you have not seen a system like the one you describe with java (I have mounted two quite more complex at the time of this writing) you just don't know. You are guessing.

2.- I don't know PHP (beyond the basics, that is) but with the description that you give, Java can do the job quite well. And .NET. And perl. Because, basically, you are saying nothing about the stress of your system.

Sorry, but java is being used in quite big systems out there. It scales well. What you have to prove is that PHP scales BETTER.

Scalability

[Anonymous Coward]

I am not sure when the word 'scalability' started to take on a political meaning as well.

dictionary.com defines it as:
'How well a solution to some problem will work when the size of the problem increases.

For example, a central server of some kind with ten clients may perform adequately but with a thousand clients it might fail to meet response time requirements. In this case, the average response time probably scales linearly with
the number of clients, we say it has a complexity of O(N) ("order N") but there are problems with other complexities.
E.g. if we want N nodes in a network to be able to communicate with each other, we could connect each one to a central exchange, requiring O(N) wires or we could provide a direct connection between each pair, requiring O(N^2) wires (the exact number or formula is not usually so important as the
highest power of N involved)."

I understand that one element of an enterprize application is in fact scalabilty. With that said, no where does scalabilty reffer to OOP, or the speed comparisons to other languages.

For instance, in PERL I can do string manipulation quicker than JAVA or PHP. That doesn't mean that PERL is more "enterprize" than PHP or Java.

Thus arguments like "Connection pooling (Java) is faster than persistant connections (PHP), means PHP is not Scalable" is not true. You are comparing speeds of languages, not their respective scalabilty. If you prove however that PHP persistant connections can not scale, then you have proven that at least one aspect of PHP is not scalable.

I am sick an tired of people stating comparisons in speed as to the quality of a product, or "enterprize" status.

Please do research before you say somehting like "PHP is not enterprize". Otherwise, you're an asshole for making a blanket statement.

Goodnight.

An endorsement from a top-5 web site

[yerricde]

So basically Yahoo! are moving from an interpreted language written in C, to an interpreted language written in C. Woo hoo.

A major web site with millions of viewers is moving from a proprietary framework to a commodity framework. This shows how mature this particular commodity framework is.

Re:Pathetic Heap of Poop

[Foofoobar]

Ah... yep. That was the other 3rd grade tactic I was waiting for.

Those who speak non-European languages care

[yerricde]

If Unicode is dead, what else should one use? What widely used character encoding, other than a popular Unicode encoding, supports English, Japanese, Hebrew, Arabic, Korean, Russian (Cyrillic script), Hindi (Devanagari script), and Greek?

PHP myths

[MattW]

I'd say anyone working for a 'true' enterprise doesn't need an article to tell them what's best; otherwise, they're in trouble already. I'll also note I've seen plenty of things I might classify "enterprises" using ASP as a primary language.

First, don't go counting PHP's compile time. If you're balancing across several servers, you're paying for the Zend Optimizer, and you've got code precompiled and parsed, and optimized. When I converted my ~30k line project to encoded, CPU use fell by 30-50%.

Second, unless you're absolutely gluttonous, then session data is not an incredibly significant thing to store in the db. You're working off a single key with a chunk of data, you're keeping the table small with constant GC checks... it's possible that using the db is faster than using the disk-based caching. And note you can split off the session data to a separate db; there's not significant overhead forming connections because you can use persistent connections that stick around through many pageviews.

I have a high volume site I've worked with to split their e-commerce app across servers. Session data is handled via the db; it is ready to be split off to a separate db as needed. Most data is read-based and not very time sensitive (people looking up items, searching for items, generating dynamic pricing data based on sales and so forth), and this balances easily across many servers.

One thing I'm quite sure of is that your design skills count more than the technology in PHP vs Java. One wrong query, one bad decision about caching, and you're wrecking your performance. If one looked at 99% of the apps out there, they'd benefit 5x as much from optimizing the application logic as compared to 'switching languages', regardless of which has the edge. So I view the whole discussion as a red herring; if you're Amazon.com, or the FTC, maybe you need to solve this question. Otherwise, it is unlikely.

The point of the "scaling" issue

[happyclam]

For me, this article is all about the PHBs. In my experience, most of the web applications I've seen could be built quickly, cheaply, and reliably using PHP (or perl for that matter). But the PHBs get all caught up on "scalability" and "extensibility" and "portability" and "promotability" and "budgetability" and "sexappealability" and "studability" and think they have to plan for everyone in the world accessing every feature of the application at the same time, from two different computers.

The end result is a project that costs three times as much, takes twice as long, is half as reliable, and barely works.

This is not true for all projects in the world, and of course YOUR project is far too complex to be done in a scripting language, but in my experience 100% of the non-PHP web applications I've worked on (in largish teams, so it's not all due to my incompetence) would have been better delivered using PHP. And 100% of the web applications I've built using PHP have been unqualified successes.

Another articale on PHP

[oglueck]

http://www.odi.ch/prog/design/php/index.php

I wrote that independetly.

Losers...

[Anonymous Coward]

C++ is for pussies. I code in machine language... Assembly if i'm feeling lazy. screw OOP, i like spaghetto code.

yahoo_performance - bad

[Anonymous Coward]

ya. and yahoo's gotten A LOT worse lateley.

should stick with C for speed.

speed made yahoo #1

Java Runtime.exec()

[Admiral Burrito]

Don't get me started on how [random deity]-AWFUL Java is for reliable Runtime.exec() in a cross-platform manner.

The only problems I've ever had with Runtime.exec() is when the underlying process outputs to stdout and/or stderr, fills up the buffer, and blocks. That can be avoided by draining stdout/stderr, using a background thread if necessary.

Re:Java Runtime.exec()

[Space cowboy]

I warned you [grin]

On win-32, Runtime.exec() is simply broken in every (sun) VM I've tried. Our most-recent (as of about a year ago) invocation uses a background thread polling for data and inserting into a StringBuffer, but it still blocks / hangs / dies when large chunks of data are sent by the executing program. If you have 40 Mbytes suddenly appear (a couple of film-frame images for example) the process will die. Guaranteed every time. Sometimes it'll die anyway on smaller files, after long periods (weeks or months) of successfully working. This is a 24x7 service... death is not an option!

Not all, but a lot of our use of JNI is to work around Runtime.exec(). It's far-and-away more reliable to embed C/C++ code which does the appropriate thing to get subprocesses to run. Under OsX or Linux it's not so bad. Under Irix, it's virtually impossible to *reliably* get Runtime.exec() to work - here we actually used to redirect the output to a file and read the file when we've finished the process. JNI is far more efficient...

We need huge reads (up to 1Gbyte at a time) and reliable operation over long time periods. Java was ideal for other reasons (cross-platform, and dynamic class loading, mainly) but turned out not to be so good for basic process control. I realise that we're stressing the system along paths that perhaps aren't so well-trodden, and you expect the system to be more fragile than usual under those circumstances, but it doesn't change the fact that it's broken.

Simon.

well to be honest

[Anonymous Coward]

i run a couple of sites on which each page is php scripted and most pages are pulling stuff from a database.

40,000 visits a day, 1,300,000 pages a day, complex queries that are several 100Kb of sql, gigabytes of image and mpeg files on a basic dual xeon box, without exception all pages load in milliseconds and the average cpu useage peaks around 7% with an average load of 0.2 (in other words the dual xeon thing is overkill and the whole thing would run quite happily on my celeron laptop)

oh and the uptime over the last 12 monts is 100% (not 1 minute of downtime in 1 year)

i hate all this "enterprise-ready" "scaleability" "mission-critical" bullshit that the big corporates push to knock open source. what's happening above is not a testement to me, it's a testement to the quality of the linux/php/apache/mysql/thttpd software that is driving a site that is actually doing the business. and of *course* i can make it scale to 50 times that size- the strategy is already planned and is so straight forward a monkey could do it. come on guys! what's to discuss? this stuff rocks!

It's not about the scaleability.

[Trejkaz]

If you want to code in a crappy, hacked language like PHP, then do it. I'll stick to the language with some semblance of design behind it. :-)

(Also I get the feeling that if your PHP app consists of 100 source files, then the interpreter has to parse all of them every single request. Do you have to do that in Java? Nope.)

Re:It's not about the scaleability.

[Anonymous Coward]

Crappy, hacked language?

Interesting that someone who programs Java would say that. Well, to each his own, but the way I see it, I'd rather not code in a language that's almost as complicated as C but has pathetic functionality. Anything that can be done in Java can be done in another language, and for the most part, it can be done more quickly and easily, plus it'll run much faster.

Moderators on drugs again?

[Anonymous Coward]

Why in the hell was that troll given points?

> most of the time is spent idle waiting for the user to do something.

Wrong. Do you have any clue how the web works? Either that, you're just trolling. The server, whether it's CGI, mod_perl, JSP, PHP, etc., doesn't sit around idle waiting for the user to do something. It processes the form output from the user then immediately sends the response. There is no idle time spent waiting on the user to do something. Ever.

Zope

[SlightOverdose]

Zope gets surprisingly little mention in these sorts of discussions. Zope has...

* a persistant enterprise level object database, that handles a distributed backend completely transparently (so you dont have to use nasty hacks like hidden variables to store state data. The session data can store key-value pairs of any python object, and is duplicated across multiple servers using ZEO)

* Zope Page Templates
Possibly the best templating language in existance, ZPT fullfills everything you need for your presentation layer.

* Python Scripting
Zope supports python scripts and python products. Scripts are stored inside the ZODB and are generally used to help process data for page templates.

Python Products are where the meat of the processing happens. This is where you define your classes. Each class can be instantiated multiple time into the ZODB (i.e. /sites/clienta AND /sites/clientb). So you can have the same codebase running two sites without setting up a seperate server.

* CMF and Plone
Two out-of-the-box products available for Zope, CMF and Plone are probably the most powerfull content management systems known to man. You can extend these to your hearts content- I've created systems for under $1000 that were estimated at $50,000 by a J2EE development firm. I've consistantly been able to duplicate a weeks worth of J2EE in about a day of Zope.

I havn't even began to touch the full power of zope. It's really such an extreme difference in philosophy to J2EE or PHP design models that you need to experience it for yourself.

PHP rox

[POds]

PHP is awsome, and from what i've seen of presentations regarding PHP5, scalability is not the only thing in common, but so is public,private,protected types, exceptions (try & catch), and other things that for now have been the domain of Java or C++...

When php5 comes out i believe i'll start to dabble in it again. Php is an awsome language and i believe the future will be built around interpretive langauges.

By the looks of php5 (following link) it has a great future!

take a look at this

was that a troll or a flame?

[Anonymous Coward]

it is so hard to differentiate sometimes. Since such loaded and emotional racked statements were used throughout I am surprised jbottero didn't just say, "Yo mamma so fat."

The VB comment in the end was a perfect closing.

Interestingly enough, it seems that if jbottero didn't actually understand the underlying point made, then why did they get so obviously offended and lash out? What came out in text was the slavering comments of a PHP zealot.

Then to actually attempt to qualify the statement, "How is maintaining 100,000 libes (sic) of PHP any different than 100,000 lines of any other code?" I just don't know where to begin. Whether or not Java and PHP are similar or the same in terms of scalability seems to not even be an issue. Different code structures (and coding paradigms) can very much matter with large amounts of code. Understand that there is more to the maintaining of code than just having it around. Maintenance often involves expanding, updating, etc to the code base. Doing so with convoluted code is not the best thing as far as efficiency and productivity are concerned.

Interestingly enough, the flame comment at the end about VB would seem to indicate that jbottero does indeed believe that certain languages lend themselves better to smaller or larger projects.

Yep, zealot detector 3.54-2 returns a clear positive.

The thing with Perl [Re:Given a choice]

[kg4czo]

But here's the thing with Perl. Alot of times the code is unreadable after say... a week. Even commented code can be a mess. PHP *can be* unreadable and messy, but most of the time you can clean it up enough to still figure out how something works. PHP fills that niche of being easy to learn, simple to writea and good for beginner programmers. When I want to use a non-web interface, I choose Python for it's powerful, yet simple syntax, which is similar to PHP in many ways.

Re:The thing with Perl [Re:Given a choice]

[bmedwar]

How about compiling Python to a native executable? Is that possible? Are free tools available for creating Windows, Linux and Mac binaries? Is there a GUI widget libarary like Swing or SWT?

Re:The thing with Perl [Re:Given a choice]

[bmedwar]

jython is compatible with SWT... http://aspn.activestate.com/ASPN/Mail/Message/Jyth on-users/1800265

Don't you mean Value Object?

[sundling]

I think you mean value object instead of view object. Value Object is actually one of the design patterns that's expected fot this sort of use.

Re:Don't you mean Value Object?

[Jmstuckman]

Java Developers that I've worked with called them "view beans." You pull your data from your model layer, put it in view beans, and ship it off to the presentation layer.

Mod up parent

[mgkimsal2]

EXCELLENT POINT. If only I had the modpoints... :(

The Static versus Dynamic war again.

[Tablizer]

What I would love to see is a 100,000+ lines project written in PHP being mantained by one or two developers. You can't do that without strict typing.....PHP is perfect for small projects, but when you have huge....

The static typing versus static or "loose" typing Holy War has been going on for ages. I think it has more to do with development style and personal preference.

Anyhow, you are not going to settle it in 20 messages. Software people have spent years debating this topic in every programming forum I have ever seen and still don't agree.

Personally I dig dynamic typing. It allows one to view large applications as multiple smaller applications and keeps the code simpler and closer to pseudocode IMO.

Wanna-be programmers

[Latent Heat]

Actually, writing direct to the Windows API in C using the "giant switch" statement in your WinProc to respond to messages is pretty straightforward -- don't look at the VC++ generated WinApp as an example because everything Microsoft does is convoluted and crufty -- where did those guys ever learn to program? Go straight to Petzold and he will walk you through it.

But we are all supposed to be using C++ and Object Oriented programming, and the Microsoft OO framework is this abomination called MFC (I am beginning to sound like the 2nd and 3rd Dune novels. Abomination! Abomination!). The dudes at Microsoft had trouble programming cleanly in C, and turn them lose in C++? MFC is this ugly mess of typedefs, macros, classes, templates, AND wizard-generated code. Abomination!

If you want to pound out a quick GUI program, you are much better off in VB 6 than to wade through MFC. All of the Windows stuff, including support for COM objects is designed into the language rather than (Abomination!) the way it is in MFC. I would just as soon use the Borland languages (I use Delphi -- I am told C++ Builder is pretty much the same) to generate COM and ActiveX objects and then use them from VB 6.

So don't blame the wanna-be programmers for not understanding C++ and being lazy and using VB 6. Blame Microsoft for not knowing how to program in C++ to develop a usable framework for it.

Zope is good... but slow?

[Anonymous Coward]

Most of people who had ever tried Zope - love its functionality. I am one of them. But one thing is bothering about Zope AND especially about Plone - run-time performance. When you try to zope for a first time slow responses is the one what's annoying.

Are there any links to Zope performance tuning guides? Any bechmarks comparing Zope (and Plone if possible) to PHP and JBoss?

Re:Zope is good... but slow?

[axxackall]

Well, Zope does a lot of more job comparing to PHP or J2EE. Developing with Zope vs PHP or J2EE is like coding on a PHP or J2EE vs doing it on Assembler. Yes, Zope does for you many usefull things, but there is a price to pay for it - the hardware resource utilization. Zope require more resources than PHP, that's for sure. I would compare Zope by hardware requirements to a low-end Java sever, like Tomcat. Well, it's often smaller and faster than Tomcat on a low bandwidth. But it keeps the performance better with growing sessions/connections, while Tomcat begins to require more resources like mad.

One good news is that Zope is implemented with Python, C and GDB - I think it would work several times slower would ALL THAT ZOPE FUNCTIONALITY be implemented on Java or PHP.

Another good news is that there is ZEO (Zope Enterprise Object) which lets you to have several load-balanced Zope web servers sharing several replicated ZODB instances.

PHP developers can only dream about such functionality as ZEO brings for web-clusters. Well, with Java you can have the same, but the price will be really very high: Java Application Servers will not work (even start) on a hardware you can run Zope (in terms of memory and CPU requirements). And, aside of JBoss, you have to pay gold for the commercial software license.

However, I agree, there is certainly a lack of Zope benchmarks and performance tuning guides and that makes bad for Zope marketing. Personally, I think that this lack of performance documents is a big strategic mistakes of Zope Corporations.

All I have to say about this is

[Anonymous Coward]

Java sucks

Big time. Always has, always will.

Not likely. freshmeat.net has images.

[brlewis]

I just took a look at freshemeat.net and it looks like there are at least 9 images on the front page. I would guess that means 9 HTTP requests where the database connection was not used and 1 where it was used.

Amazon/Perl

[bill_mcgonigle]

And Amazon is using Mason/Perl/mod_perl/Apache. Methinksts they know something about scaling.

Cuz The Managament said so, of course

[RoboProg]

THAT'S one good reason to use XML between your own processes, rather than in in-memory data structure and/or RPC. Mgt. is often former COBOLers used to archaic mainframe style processing of many simplistic programs dumping into many many temp files. It's the architecture they know. XML sucks much less than many file formats, but files aren't always the best way to join tasks / processes, as you seem to be "hinting" at.

Jocky or the Horse?

[Anonymous Coward]

There is some fuzzy thinking around the subject of computer languages.

There are simple languages, eg. COBOL which, because of their operating environment, scale well enough to run most of the World's enterprise database systems.

Analogy-wise I see PHP and Python more as agile young jockeys than race horses.

Java is unwieldy, lets face it, the corporates have gone outsourcing to bring development costs down, when they ought really to have bought and paid for some better advice from among their own economic eco-system.

I am glad that it could conceivably cost $billions to turn things around to efficiency, because I am bitter - and unemployed :-)

Comment removed

[account_deleted]

Comment removed based on user account deletion