PHP Scales As Well As Java 627
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."
What's the PHP equivalent to Java NIO? (Score:2, Insightful)
Re:What's the PHP equivalent to Java NIO? (Score:4, Insightful)
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? (Score:3, Insightful)
Maybe with dynamic typing, that would only be a 30,000 line project.
strict/loose dynamic/static explicit/inferred (Score:3, Insightful)
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.
strict typing (Score:2)
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.
You've hit the nail on the head. (Score:2)
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:What's the PHP equivalent to Java NIO? (Score:2)
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? (Score:2)
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.
Then what IS weak typing? (Score:2)
Re:What is your point? (Score:3, Informative)
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
>>> 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.
Scaling (Score:2, Insightful)
Re:Scaling (Score:3, Insightful)
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!
Apples to Oranges. (Score:3, Insightful)
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.
And in other news.. (Score:2, Funny)
Re:And in other news.. (Score:2)
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.. (Score:2)
Re:And in other news.. (Score:2)
Re:And in other news.. (Score:2)
of course it does... (Score:3, Interesting)
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 [intercosmos.net] 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... (Score:2)
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... (Score:2)
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... (Score:4, Informative)
Re:of course it does... (Score:2, Insightful)
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... (Score:2)
Re:of course it does... (Score:2)
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... (Score:2)
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... (Score:3, Insightful)
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... (Score:2)
we are a large domain name registrar (not the largest, but close).
yeah whatever (Score:2, Informative)
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 (Score:2)
Re:yeah whatever (Score:2)
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 (Score:2)
s/with/without/
Re:yeah whatever (Score:2)
and POOF! your_script.php executes
Though few people install PHP as a binary; most install it as a PHP module.
Re:yeah whatever (Score:2)
Learn something new every day.
Re:yeah whatever (Score:2)
They got it backwards (Score:2)
I thought the shocking revelation would have been "Java scales as well as PHP" under pathologically slanted circumstances.
No.. (Score:2)
No, it's not.
That's not to mention all the other architectual mishaps within the language. You thought perl was bad..
Re:No.. (Score:2)
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.
perl (Score:2)
Could someone explain instead of just flaming? (Score:3, Interesting)
Re: Could someone explain instead of just flaming? (Score:3, Informative)
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? (Score:3, Insightful)
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
Yahoo! (Score:4, Interesting)
Re:Yahoo! (Score:2)
Re:Yahoo! (Score:2)
Perl (Score:3, Interesting)
Re:Perl (Score:3, Insightful)
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.
Some facts (Score:5, Informative)
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 (Score:3, Informative)
Re:Some facts (Score:5, Insightful)
Re:Some facts (Score:3, Informative)
Re:Some facts (Score:2)
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 (Score:2)
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 (Score:2)
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
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 (Score:3, Informative)
They scale differently (Score:5, Insightful)
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.
Get the most out of that aging single server (Score:4, Informative)
Jetty [mortbay.com] running on that single aging server will blow the doors off of PHP. That's what I saw when I did some BRL [codesimply.net] benchmarking some time ago. Presumably you'll get similar results with JSP.
Re:They scale differently (Score:2)
IF you accept the underlying assumptions... (Score:5, Insightful)
"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 [jboss.org] 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... (Score:2)
Session state (Score:3, Interesting)
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.
Comment removed (Score:3, Insightful)
where I stopped reading (Score:5, Insightful)
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 (Score:3, Funny)
Welcome to the Real World.
I worked with That Guy (Score:2)
Re:where I stopped reading (Score:2)
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.
Web stuff again (Score:2)
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
Hrm (Score:5, Insightful)
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.
Performance scalability? Can that be right? (Score:2)
Back when I was concerned about whether BRL [codesimply.net] 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 (Score:4, Funny)
The Truth (Score:2)
Re:The Truth (Score:2)
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.
His definition of scalability (Score:2)
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.
see JBOSS (Score:2)
ah hell (Score:2)
it's not hard to be scalable (Score:2)
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.
"ignores horizontal scaling" (Score:2)
I cannot believe an article that talks about scalability simply just "ignores" horizontal scaling.
J2EE != EJB (Score:4, Informative)
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.
Confusion of terms (Score:2)
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.
The difference for me... (Score:2)
Debunking ... (Score:2)
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
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
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
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
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
Re:Pathetic Heap of Poop (Score:2)
Take your FUD elsewhere Microsoftie.
Re:Pathetic Heap of Poop (Score:2)
Re:Pathetic Heap of Poop (Score:3)
Daniel
Re:PHP Vs. Java (Score:2)
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 [gelotto.com]. his went bankrupt at the 90% mark three weeks after we were done.
Re:PHP Vs. Java (Score:2)
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 (Score:2)
Wow, is *that* what they changed the definition of 'scale' to?
Re:Props to PHP (Score:2)
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 (Score:3, Interesting)
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 (Score:2)
Re:Here's why... (Score:2)
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... (Score:2)
They had to use some obtuse compiler.
Mental blip.
Re:Here's why... (Score:5, Interesting)
Re:Here's why... (Score:3, Insightful)
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... (Score:3, Informative)
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:Props to PHP (Score:2, Insightful)
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:Kiss and say goodbye to Java language!! (Score:2)
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!! (Score:2)
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:Of course.... (Score:2)
Yeah PHP is quick and easy, but it's not for big projects.
Re:Not exactly... [Re:Java owns PHP] (Score:2, Insightful)