Choice of Language for Large-Scale Web Apps?

anyon wonders: "PHP is the most popular language for the web. eBay uses ISAPI (C), Google uses C/C++ (search), Java (gmail), and Python. Microsoft uses ASP (what else?). For small web site, it really doesn't matter. What's your take on language choice for large-scale web applications? Maybe language choice is irrelevant, only good people (developers) matter? If you can get the same good quality people, then what language you would chose? Considering the following factors: performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools? Has there been a comprehensive comparison done?"

Polyglot

[FTL]

What's your take on language choice for large-scale web applications?

As many as possible. Use PHP for the front end, Perl for input parsing, Euphoria for the graphics, JavaScript on the client-side, Moo for the database and Python for the glue to hold things together.

Every language has strengths and weaknesses. There is no killer language. A good carpenter has lots of tools and uses the most suitable tool(s) for each task. Likewise a programmer should be skilled in many languages and should pick the most appropriate one for each task. Learn as many programming languages as you can, and when you've done that, learn a few more.

[The feeling of job security is also rather nice.]

The only thing that counts...

[Qui-Gon]

And you said it...

Maybe language choice is irrelevant, only good people (developers) matter?

Consider the employment market

[Brento]

You're using examples of Ebay, Google and Microsoft's web sites as your "large-scale" web app description. If you truly do want to build something as large-scale as that, then you're going to have a lot of hiring to do. Take a look at your local market - or even better, place ads for architect-level people in each of the languages you're considering. See what kinds of people you get, and that should weigh into your decision.

ASP.NET w/C#

[gfody]

this should've been a survey

Where are the best practices for each language?

[Alderete]

I've been getting into Ruby on Rails [rubyonrails.com] recently, and am most excited by how Rails makes it very clear what the "best practices" for organizing and building your application is.

I have long despaired of learning that same information for PHP (with which I have much more experience). I've not yet found a book or other documentation that provides a concrete approach. And looking at existing large-scale projects, e.g., WordPress and others, reveal a myriad of different philosophies. It leaves developers basically trying different things out on different projects, and picking up their own favorite best practices as they go along.

While it's great that the languages are so flexible, well, sometimes it's nice to be guided to a known solid approach. It leads to consistency among and across many developers and time. This makes it easier for new developers to join or take over a project, or even for the original developer to do maintenance on components which were written long ago.

So, where are the recommended approaches for organizing and constructing large-scale applications for PHP (and Python, etc.)?

C/C++

[Anonymous Coward]

Your OS is written in it. Your server is written in it. Your browser is written it. Your database is written in it.

Get the point?

Bottom line: C is the lingua franca of computing.

Depends

[boner]

What you are asking is a dilemma that has been around since the invention of different programming languages. My personal opinion is that the best investment of your time is designing the web-app itself. Once you understand the feature set you require/desire then it makes sense to start looking at how the feature set requirements map to the available languages from a development and performance point of view.

Most people tend to forget to take a productivity point of view and let themselves be guided by whatever is available or what's cool. If you follow a productivity approach it will help you make the trade-off decisions between interpreted languages like PHP and compiled languages like C/C++, with ASP and Java somewhere in between.

There is a balance between development and production, when you go live and your web-app is well-designed it should be easy to add additional hardware to compensate for performance issues (server is about US$ 2000,- , or the equivalent of 10-20 hours of developer time.)

The single most important piece of advice after recommending that you spend more time on designing the app: don't get married to the language. Be prepared to use PHP to develop quickly and understand what works and what doesn't for your web-app. Once you have solved the usability bugs, investigate how you can drive efficiency by choosing a different language or not.

There is no template for what is the best environment, only your common sense, and oh... did I mention that you should spend more time designing your app?

Depends on what you want to do...

[Foofoobar]

I use PHP myself because it focuses on one thing and doesn't get distracted by trying to do more than it's build to do... that being, serve dynamic web pages.

Sure you can use it to dynamically generate images, PDF's and alot more but these things tend to slow down and detract from what it is meant to do and should be handled by third party apps preferably on a different server that way you separate your processes and keep PHP focused on it's task.

Plus with the improvements in the ZEND engine and it's object oriented programming, PHP is now comparable and even sometimes faster than Java.

People will say that it doesn't scale but they base this opinion on a preset prejudice or on the scalability of the underlying architecture. But PHP's engine is actually more compact than the JVM because it has less to focus on and thus can scale along side Apache, the entire way.

And with tons of larger companies moving to PHP, it has proven it can handle the load.

My only complaint though is developers who try to do EVERYTHING in PHP. With all the added modules, it does have the potential but do you really want to waste processing power letting PHP handle all these extra tasks? Use PHP for dynamic webpages and any added processing you need to do, I suggest moving to a secondary app preferably built in C/C++ or even Java. That way you get the most bang for your buck.

Let your developers decide

[Dominic_Mazzoni]

You didn't make it clear who is doing the development.

If you're doing the development by yourself, then obviously you should weigh the choices and pick the language that will work best for you. Development time, for example, is highly dependent on how well you already know the languages.

However, if you already have a developer, or a team of developers, to do this development, then whatever you do don't force them to use what you think is the best language. That's a guaranteed way to lower productivity and morale if they think it's a poor choice! Ask them to make recommendations. Maybe even spend a couple of days prototyping various things in different languages first.

One of the nicest things about back ends is that it doesn't matter what language you use (nobody can tell from the outside) and you can easily mix and match languages. There's nothing wrong with writing the majority of the code in PHP or Python for rapid development, but using Java or C++ extensions for a few of the computationally-intensive algoritihms.

Re:Java Java Java!

[Surt]

Actually, odds are that hand written assembly will underperform compiled c these days. Hiring or training people that can write better assembler than a modern compiler is very very difficult.

But for web development, Java is generally the right choice for the backend. Lots of competent people available who will require no learning curve. The support tools available for java on the backend are also clearly the best right now, as you pointed out (hibernate etc.). The tools for working in java are also a step ahead of anything else right now (idea and even its slightly retarded younger brother eclipse are both way ahead of the tools for any other language).

Wrong

[dereference]

Ajax asyncronously calls JAVA functions without needing a page redraw.

Wrong.

AJAX asynchronously calls any server-side technology without needing a page redraw. It could be PERL, ASP, or anything else that can respond to an HTTP Request.

Please read the docs about Ajax before telling me something that has nothing to do with it.

Please follow your own advice.

Our standard enterprise stack these days

[BigGerman]

(for those who actually care to get something out of the door)

Java:

front end - Tomcat running JSPs (JSTL or Velocity for templating)

in the middle - Spring and Spring MVC

Closer to database - Hibernate.

Ideally, everything running in same JVM. Add more servers for scalability front-ending them with load balancer with sticky sessions.
No J2EE fluff, easy to find people, good productivity.

Language is mostly irrelevant

[PhotoBoy]

It's been my experience that language is mostly irrelevant when building a large, scalable web app.

There is certainly a difference in performance between various web languages/libraries but the most important aspect is how well you design your app to scale across multiple servers. Even if you were to spend years writing the most tightly coded app in Assembly that is 99.9% efficient you will still reach a point where you need to use more than one server.

As long as your app is designed with scaling to multiple servers in mind the choice of language should merely be down to what your team is best able to work with and support. It's no good doing everything in ISAPI just because eBay does it if your team is mainly experienced in Perl. Building the app to work well with multiple servers that are clustered according to their function (e.g. a DB cluster, load balanced webservers, large scale storage solution, etc) is the best way to ensure a scalable solution. Picking a database server for example that easily allows you to add a new machine to the cluster should be more important than language choice. Picking high availability software that doesn't require downtime every time you need to add a new server is very important.

Maybe I sound like I'm advocating writing sloppy code and just throwing lots of servers at the solution, but it's worth considering how today's top of the range server will be the cheapest low range machine in a few years. This means you can either pile high with cheap boxes or buy fewer but more powerful servers which have double the capacity of the cheaper server. It's certainly the solution that's worked well for Google...

COULD SOMEBODY PLEASE MOD THAT FUCKTARD DOWN?!

[Anonymous Coward]

AJAX != Java, ass faggot!

Re:Polyglot

[Tablizer]

As many as possible. Use PHP for the front end, Perl for input parsing, Euphoria for the graphics, JavaScript on the client-side, Moo for the database and Python for the glue to hold things together. Every language has strengths and weaknesses.

Noooooo!

It will just produce a job ad that says:

Required: 3+ years experience in PHP, Perl, JavaScript, Euphoria, Moo, and Python.

Then when they can't find any individual to fit the bill (surprise!), they will lobby Congress for more visa workers so that they can hunt the entire globe for the "best and brightest".

(Hmmmmm. What the hell is "Moo"?)
       

Re:Consider the employment market

[Tablizer]

You're using examples of Ebay, Google and Microsoft's web sites as your "large-scale" web app description. If you truly do want to build something as large-scale as that, then you're going to have a lot of hiring to do.

If you are building something that large and asking for advice from slashdotters, you have faaaaaar bigger problems, dude :-)
         

Re:Perl?

[rascal1182]

Ruby is another write only language if you dont know it (actually arent they all!).
This is I presume simple example code. God only knows what kind of code a ruby "haXX0rzzzz" would produce:

The thing about this is, skilled Ruby programmers (that I've seen) produce beautiful, simple code, devoid of silly things like conditionals. These programs aren't hard to understand.

OTOH, the Perl mentality seems to be "I can do that in fewer keystrokes!"

These are obviously over-generalizations. I have seen good Perl code and lousy Ruby code. I just think that Ruby is more condusive to good code (personal preference, really).

Re:Depends

[morten poulsen]

it should be easy to add additional hardware to compensate for performance issues (server is about US$ 2000,- , or the equivalent of 10-20 hours of developer time.)

I guess that you are NOT a system administrator?

"No, I don't need to think before I code, you can just buy more servers. I also killed the database server? Can't you just buy a larger database server too?"

God damn programmers.

Language != module

[Foofoobar]

You are mixing up the language with the modules. There is a reason why PHP comes without all those additional modules... so you can decide what you want it to do. If you want to add all those modules to PHP and make it do all that, then you have to do it yourself. But the base install does not include them. In fact it no longer includes MySQL support in it and that too must be added as a module.

As far as your opinions on PHP not scaling, tell that to IBM, Avaya, Hewlett Packard, Disney, Sprint and the others who get millions of hits a day using PHP. Seems to me if sites that get millions of hits a day can handle the bandwidth using PHP, that it JUST MIGHT be able to scale. :)

And as far as worst security history, you again confuse bad programming with the language it is written in. For this analogy, C# and VB still hold that title. Just because the language allows you to make mistakes in your programming, does not mean it is the languages fault when you create a recursive function that loops perpetually.

I suggest trying a course in logic; it makes your programming better and your argumentative rhetoric make more sense. :)

Re:Perl.

[hahafaha]

I absolutely agree. The only danger with Perl is speed. Perl is not the fastest language, but unless your web application needs speed, Perl will work 99 percent of the time

Code management

[sterno]

Another aspect of Java for dealing with large sites is that it lends itself to cleaner code and better organization. PHP pages end up being a bunch of pages which means you get UI and business logic all entangled. In java, there's a lot of ways to avoid that mess and make a more organized and more readily maintained system.

The real problem in comparing Java and PHP

[amarodeeps]

Java is called a language but in this context it is more of a platform which, frankly, is older, more robust and better thought-out than anything PHP has to offer--at this point. I believe PHP is great for small to medium scale web sites, but once you start to deal with the large structures that enterprise systems require, PHP is just not an option--if you want packages already available to you which are thought-out, mature and stable, like all the various J2EE solutions available.

PHP very well may be faster for an individual page--but what are you comparing that to? Tomcat set up to use JSP? Well, there's a lot of infrastructure there that a PHP developer is probably not going to use for a simple dynamic page. And the fact is, PHP is incorporating a lot of 'heavier' OO features now whose effective use is debatable when considering web apps tied to the HTTP protocol--why build and tear down your entire OO structure every time you load a page? To do that intelligently you want an application server caching these objects...and then we start talking about Java and all the years it has on PHP there.

So, I'm really just saying--some things are right for some projects, others for other projects. Choose wisely.

Re:You are contradicting yourself.

[gregmac]

Lets not forget that PHP has the worst security history of any language, there are constant exploits and there's nothing you as a PHP user can do about it.

Constant exploits? For PHP, or for crapply-written content management systems (ahem, phpnuke) that happen to be written in PHP?

CERT has issued two advisories for PHP itself: CA-2002-05 and CA-2002-20. Looking through the changelog [php.net] I see only a handful of security fixes.

Like most languages, it's possible to write unsecure code. I've seen code that executes stuff on the command line, right from a GET string. It's just as possible to write secure code.

One problem with PHP is it's a simple language, and a lot of beginners with no experience pick it up and can use it to write applications. Knowing nothing about software development, or security issues, they tend to write bad, insecure code. This has nothing to do with the language, it simply has to do with the developers. If python or ruby came into incredibly widespread use (ie, available on pretty much any hosting account you can buy, like PHP is), then you'd probably see the same thing happening. It doesn't say anything about the languages, it's simply a matter of inexperienced developers writting bad code.

Re:The only way to hire a good architect

[the eric conspiracy]

I wouldn't hire an architect

I am a lead or senior architect for a medium sized software company - and I have a big problem finding/recruiting good architects. Internal candidates want to do it for all the wrong reasons- thier project manager is a jerk, etc. The good programmers really enjoy coding so they want to stay as programmers, and are afraid once they take on the role of architect they will be just paper pushers. The experienced 'architects' out there are almost all centered on business analysis these days, very few have enough code skills left to really be able to do a good job designing code.

Re:Java Java Java!

[Rakishi]

Just as difficult as was writing assembly back in the 60s and 70s?

Probably a lot more difficult, CPUs are a lot more complex (to make them faster, just look at the transistor count) and have more instructions/quirks. To get the most speed you'd need to know most of them I assume, since that nice looking instruction which seems to do just what you need may actually be slower than using 5 other instructions.

Re:If you are a singlehanded developer

[kraut]

The corrolary is that you have to maintain it, and you never get to do the fun new stuff.

Re:Java Java Java!

[drgonzo59]

You are right, performance from the language point of view is won by assembler, but often it is the choice of the algorithm that will make the big difference. A bubble sort in assembler of 1 million items might be slower than a quicksort of the same million items in python.

Often when someone asks the question "what languages do you know?" or "what languages are the best?" it shows a lack of CS background and experience. The right question is "what programming paradigm would you use?" or "what programming paradigm is better?" (Of course when you come down to a specific problem, then the choice of libraries might determine the language, but the original poster only specified "large web application" as the requirement so talking about a specific language is pointless).

The difference between the two questions underlies the difference between the two types of education most programmers have. Some have gone to 4 year colleges and got a "Computer Science" degree, while some learned a language in their spare time, or went to technical college. The people from the technical college will know just one language and ask others what langues are the best, what languages they use etc. To them learning a new language hard. What a CS degree teaches (or should teach) is different programming paradigms - procedural, functional, object oriented, along with an algorithms and data structures. So if someone knows how to think in terms of objects when they solve the problem they can program in java, c++, python, ruby and other object oriented languages.

I used C++ in college, then I learned Java, now I use primarily Python. All I had to do is learn the syntax and some of the common library functions -- all can be done with a good reference book and/or Google in a couple of weeks.

Or if a problem can be better solved with a functional approach, I would use Prolog or Lisp (you can use Lisp for websites too!).

So, I think the original question should have specified the problem more exact or ask about what paradigm would be better. Rather than give a general requirement ("large web application") but then then ask for a specific language. This is bound to lead to nothing but arguments of why everyone's favorite language is best and that's about it.

Re:Java Java Java!

[Surt]

Actually, if your hand written assembly doesn't look like compiler generated assembly, you're probably missing out on things like multi-functional unit parallel scheduling etc. The number of people who can code in a way that will feed instructions to a modern cpu successfully is very small.

Writing efficient assembly code today is at least 3 or 4 orders of magnitude harder work than it was in the 60s or 70s, and there are far fewer experts available to hire today than there were back then. There are maybe 3 or 4 major computer game developers still doing hand assembly optimization these days, and those guys would be extremely hard to hire away from their current jobs. Most games are just developed in c, and are bound by the performance on the video card anyway, so that optimization on the CPU just isn't that important any more.

Re:Polyglot

[Anonymous Coward]

Boy you sure are an idiot, it is possible to dominate all the languages, if you know how to program one you know the rest, if you know how to read documentation and api's you can take advantages from each, get your sorry ass of the sofa and learn someting will ya, the specialization era is not appreciate it any more, give with the times.

Re:Not all true (imo)

[Westley]

You say it's "simply not true" but don't actually give any reasons.

Now, I've never used IDEA for a prolonged period of time - I couldn't get into it, and was happy enough with Eclipse not to worry. (The fact that Eclipse is free helps - it would be difficult to persuade my company to pay for loads of licences for IDEA when Eclipse is perfectly all right and free.)

I do, however, use Visual Studio .NET 2003 and Eclipse in daily work. Here are just a few reasons I much, much prefer Eclipse to VS.NET:

1) Refactoring. Yes, there are tools available to help - but it's free and bundled into Eclipse.

2) Organise imports. Even with VS 2005 having some limited support, it doesn't help nearly as much as it should.

3) Built-in unit testing tools. Using TDD.NET to fire up NUnit GUI (or any of the other things it can do) is much, much uglier than the built-in support for JUnit in Eclipse.

4) Ant support in Eclipse. Our Java build script is *so* much nicer than the nastiness VS.NET encourages. I'm looking forward to investigating the VS 2005 integration with MSbuild.

5) "Hold down ctrl to make anything a hyperlink" - want to go to where a method, variable, class etc is declared? Just hold down ctrl and click. Navigation was never simpler.

6) Search for all references (etc) - in theory there's "go to definition" in VS.NET 2003, but half the time it doesn't work when you're in a large solution, and I don't believe there's any way of finding all references.

7) The VSS plugin for Eclipse is actually better in my view than the VS.NET support... much easier to understand the configuration, change it on a per project basis etc.

8) Launching Tomcat in a debugger with Eclipse (even without any extra plugins) seems a lot more reliable than trying to make sure that IIS has actually caught up with changes. Why do web projects need IIS to be running even to open in VS.NET? It's crazy.

9) Quick Fix and other source options - get Eclipse to write code for you, fix code for you, extract constants, etc. Fantastic stuff - especially in test-first development, where you can write code which uses the API you *want* to exist, then tell Eclipse to create the shell of that API for you.

10) Compile on save with a really good incremental compiler. This saves huge amounts of time. Oh, and changes really do happen, unlike in VS.NET where if you change an embedded resource, a normal build sometimes picks up the change but sometimes doesn't. (Not to mention VS.NET locking access to files it's built quite often, meaning you can't rebuild them without restarting VS.NET - particularly in terms of XML documentation.)

These are not esoteric features which are hardly ever used - although I could list loads of those too, if you want. These are things I use *every day*. My pair programmer and I are *always* saying how much easier our C# work would be if VS.NET supported the features above. Half of them aren't even in VS 2005 beta 2, as far as I can see - or at least aren't as well implemented. Funnily enough, I can't remember the last time we said something similar the other way round...

So, I've given some of my reasons why I think Eclipse isn't just a step ahead of VS.NET, but leaps and bounds. Now, why do you think VS.NET is better than Eclipse, and do you really not care about the above features?

Re:Use ASP If You're A Microsoft Shop

[wk633]

ASP is a better environment than ASP.NET???

I don''t normally ask things like this, but are you on crack? I have worked with both ASP and ASP.NET. No way in hell would I pick to do a new site in ASP over ASP.NET unless there were overwhelming reasons to do otherwise.

significant training to learn .NET's arcane vocabulary and squirrely architecture

Any web developer worth anything will take to ASP.NET like a duck to water. Same goes for J2EE or PHP or anything else. And any developer worth anything will understand and appreciate the seperation of code and content that ASP.NET provides.

Disclaimer: I'm as anti M$ as anyone on /., but I refuse to let religion cloud my view on a good technology.

Re:Polyglot

[Lord Ender]

If I were your boss, I would hire an intern and have him rewrite your apps from scratch with a single, maintainable language. Once he is done, I would hire him for half of what I pay you, then give you the boot. Job security through incompetence?

Re:Java Java Java!

[Anonymous Coward]

Thank you for depicting what computer science really is. Sure, I may know a good 50 languages, but does that mean I know which sorting algorithm to use, or to use an adapter over a factory for making any arbitrary wrapper class. I completely agree with you, in that it really is what you know about paradigms of programming and the system, not what language you use to control it.

If any of you have ever worked in the corporate environment, the company does not say "Use C++ to build us a backend server that incorporates this functionality." Rather they say "Build us a backend server that incorporates this functionality," and never specify a language.

So to those of you who ask what the best language is my response is every one. It's not what language you use; it's how you use it.

TCL and AOL server

[Anonymous Coward]

Read AOL's documentation for their opensource AOL server. Yes, AOL, the big company.

Some of us build more than one app.

[LibertineR]

Code reuse, baby.

Some of us want to consume services from other apps.

Some of us dont want to reinvent the wheel every time we code.

Design Patterns, baby.

I could go on, but I know I am typing to deaf eyes.

Pfft

[defile]

For small web site, it really doesn't matter.

Same is true for a large site.

A good way to define "large site" is "beyond the hardware capabilities of a single computer". For example, if you made a hand optimized assembly version of Slashdot that had its own network driver, TCP/IP stack, etc. its load would still probably be beyond the role of any one commodity computer.

When you throw this kind of a load at computers, many basic assumptions start to break -- you inevitably exercise a use case that is quite uncommon with no off-the-shelf solution that fits the bill quite right.

Of course, since large sites mean big business, vendors want you to believe that their solution can grow towards infinity. But don't be fooled: there are no silver bullets.

Getting into a religious war over what RDBMS, language, OS, etc. to use is pointless -- you just cannot avoid refactoring/rewriting major chunks of a project through its lifetime. It is undeniable.

Better to pick what your group is most comfortable with and just take it from there.

Re:Perl?

[Fjornir]

This thread is really starting to make my point for me.

I dunno. Unless your point was that you shouldn't use features of a language you don't understand I don't think this made your point at all.

Perl is just too idiosyncratic. There's too much to remember,

Funny that... Once you understand the key philosophies which made Perl the way it is, it doesn't really seem that odd -- and given that its backgrounds are in UNIXish operaring environments and C programming culture it maps to my own experiences quite well. As to the "too much to remember" I'd answer, "No. Not really.". It's neat that a lot of the one-off stuff is there but you don't really need to commit it to memory.

and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.

Hm.... I don't spend my time thinking about the niche features at all. I spend my time looking at how to write the program and then writing the program. Take the comments about the diamond operator, for instance. I know it's there, I know I can use it if I want to, but until VGPowerlord brought up its magic behavior in the no-filehandle-given case I hadn't thought about that aspect for... Oh, six years.

And that was just correcting a newbish misunderstanding about the language -- if you know of a language where new programmers don't make any mistakes or misunderstand anything I'd love to learn it.

Don't go telling me that Perl has superb OO features.

Well, you don't want to hear it so I won't say it. I will say that Perl's OO mechanisms are quite nice and dovetail quite simply with the way Perl does everything else. For sharp contrast look at how C++ handles OO behaviors.

I swear I'm done. I'll go piss off some Java people now, unless any Python junkies want to step up (I haven't yet seen much of that yet, and I'm surprised)...

Well, if you were trying to piss someone off I think you failed miserably. You made well reasoned arguments and presented them without being inflammatory. I happen to disagree with you but that's not enough to piss me off.

I'll close by saying that the important thing to me about Perl isn't if it's the perfect programming language or not. No, the important thing is that it let's me do the work I need to do quickly and easily while I get paid a handsome sum to do something I enjoy.

Re:Perl.

[jadavis]

We're talking about web applications here. I'm a great fan of C, particularly for manipulation of binary data and so forth, but your post makes no sense.

You would have to be doing something quite unique as far as web applications go for perl to be different speed-wise than C. Web applications are basically text processing and database queries (usually). Perl has highly integrated, optimized text processing routines that even a good C programmer is unlikely to match without years of development. And database queries aren't going to be any different at all... they just depend on the database.

Next, why do you say that perl is fast with arrays and slow with files? If you mean appending something to the end of a list in RAM (maybe a microsecond) is faster than waiting for a disk seek time (millseconds), well, duh. That is not language-dependent at all.

If that's not what you meant, it makes no sense either. Perl is designed and optimized for processing text and files. Perl's arrays are designed for flexibility, not speed.

And why did you ask what the application was? It's a large scale web application. You can infer a lot from that. Lots of text processing, use of many libraries, validating user input, database queries, and caching. Maybe some image processing. Lots of security concerns.

The obvious choices here are Java (many highly developed web frameworks, many libraries, many security features) and then PHP, Perl, Python, Ruby (which might add rapid application development to that list). C/C++ would be special purpose. Anything else is a platform-dependent solution that's an "all or nothing" approach.

I think most people would agree with the above statement, and the discussion should be mostly within that context. Not whether or not you can use C to marginally improve performance doing something that a web app doesn't need to do.

Re:Java Java Java!

[Surt]

The problem is, if you're 'just' writing sse/sse2 etc, you're missing out on potential parallelism. You want to deliver some of your work to the sse, some to the main adders, etc. I've done some of this, and it is fairly complicated work. Again ... I think this is sufficiently complicated that trying to find well qualified people to do it is going to be pretty challenging. And we started out with the premise that we were writing a whole program in assembler, rather than say just optimizing in a narrow area, where you can probably afford to try a large number of different possibilities and actually benchmark the different options to prove whether or not you've succeeded.

Tiny.

[C10H14N2]

If your code is at 20,000, you haven't even begun to get to the point where manageable code is truly problematic. A skilled developer can get a grip on that (about 400 printed pages) in a day unless it is utterly obfuscated.

Now, with respect to #1 and #2 as applied to #3? The WORST of execution and compilation time generalized to _all_ bytecode? WTF?

With a proper J2EE development environment (no .Net here), my compile/build/deploy cycle on most projects takes one command and, guffaw, 20k lines would compile in a few seconds. As for execution speed, this has been disproven so many times at this point that it is laughable.

In any organized production environment (that is, not just Rinkydink, Inc), changes will NEVER be immediate, usually they'll take at LEAST several weeks or months to implement, so this idea that somehow a 30-second build process is an impedement to large applications is just a joke. In such an environment, anyone who would just run in and perform a quick-and-dirty "fix" on the production server would be escorted out of the building before they got up to get their next cup of coffee.

However, we seem to agree that with any language, the problem exists between keyboard and chair...

Re:Seconded!

[cahiha]

It does it all, and it values the most expensive component of software (for all but the biggest Web apps): programmer time.

Programmers also have to debug and maintain that software, and that makes Perl one of the most wasteful languages in terms of programmer time.

Re:Polyglot

[mrlpz]

"As many as possible. Use PHP for the front end, Perl for input parsing, Euphoria for the graphics, JavaScript on the client-side, Moo for the database and Python for the glue to hold things together. Every language has strengths and weaknesses."

The above statement is PRECISELY why the state of software development across this country is as it is......I nominate this person as the FIRST person to vote OUT of a Software Engineer's Union when it comes down to that to protect the state of the business that the politicians and the beaners won't. It's precisely because nimnuls like this abound across this country that we're in the state that we're in. This is why HR departments are the hell holes that they are today. Because no one in their RIGHT MIND would think that ANY solution like this is truly viable.

I don't remember who to credit with this ..but it DEFINITELY applies....

Just because one CAN do a thing, means that one SHOULD do a thing.

Re:The real problem in comparing Java and PHP

[OpenServe]

..why build and tear down your entire OO structure every time you load a page? To do that intelligently you want an application server caching these objects..

Thank goodness somebody mentioned this. For this and other reasons, PHP is an architectural disaster when it comes to trying to write real world applications (vs. dynamic web pages and ultralight web apps like blogs, wiki's, etc.) PHP fanatics continually ignore the fact that their language of choice is nothing more than a glorified form of CGI. Indeed, PHP is great for doing CGI, but beyond that it's the most useless language on the planet. This is 2005, not 1995.

The worst part is that, within the Open Source community, PHP has diverted enormous resources and man-hours away from Java in cases where Java is the obvious right tool for the job. As a result, we still have virtually nothing in the category of quality core business applications. (finance, accounting, payroll, ERP, CRM, document management, etc.) The distraction of immature Python has been to no gain either. I firmly believe that if the Open Source community had co-opted Java 5+ years back, nobody would be talking about .NET today and we'd be seeing far more large scale Linux/BSD rollouts across corporate America. That includes desktop rollouts too, because once your core apps are web-enabled, who needs Windows?

ok.. off my soapbox. :)

Re:Perl and C++

[Unordained]

Last time I tested speed (very simple timing of a large increment loop), ... compared to some simple C/C++ (at this point, the difference is moot) ... perl, php, and python were all in the range of 1/10 to 1/14 the speed of C (pretty much equal.) Ruby was 1/40, which ... sucked. But that was ... let's see ... four years ago? And a really icky way to test speed anyway?

But really, it doesn't matter. You can write good and bad code in any of them, and raw looping speed rarely matters. Most of our apps are just glue, talking to databases, networks, files -- all bottlenecks. The CPU isn't our problem. And where speed does matter, pretty much all of these languages rely on C libraries that -are- speedy. Most of them seem to compile to some form of bytecode at the very least, and will cache that bytecode to avoid a recurring cost.

These days, we pick languages more on features and libraries than speed. And most people just pick by features, because they're not interested in building -new- architecture where features matter. I still am, and C++ does that for me. But for web apps? I'm not coding architecture with really neat stuff going on ... I just want to grab from a db and spit it out. PHP does that for me, so it's fine. Perl would too. So would python, and ruby, and probably COBOL if I were willing to ever do that again. I think the only reason I went with PHP was the db function set, and that's not much to go by, considering that most of these languages rely on similar/same C libraries, so it's just a matter of time before they all have the same library features -- just the time required to write wrappers to make C functions available in the scripted language itself.

If you do write web-apps in C++ ... apache modules aren't that bad, but there's a certain amount of "getting started" cost. Find yourself a good set of CGI functions if you're doing it the CGI way -- C++ doesn't hand you your $_POST stuff neatly the way PHP does. Beyond that ... meh? It's pretty much all the same.

Re:Wrong

[Citizen Gold]

Ajax asyncronously calls JAVA functions without needing a page redraw.

Wrong.

Uh... you fail to explain how this statement is wrong. It is in fact correct, unless you're telling me that Ajax can't asynchronously call server-side java code.

Just because you're on the internet, doesn't mean you get to be a pompous ass.

The emphasis was put on the word JAVA. I also read it as the commenter thinking server side Java was the only option.

Re:Use ASP If You're A Microsoft Shop

[wk633]

most Visual Studio.NET developers don't understand the WWW and the Internet at all, they drop and drag controls onto a form.

I guess our millages varry. I have yet to meet an ASP.NET developer (including myself) who didn't already have a background in other areas. Probably myself least of all, but I don't see the big deal with dragging/droping controls. That's just the tool. You can write ASP.NET in vi if you want to :-) Actually, often as not, I work in HTML view. I am equally fluent writing server side Perl or classic ASP. Give me a nutshell book, and I'll do PHP or Zope or tack your pick.

Time will tell which of us is correct about the direction ASP.NET takes. I'm not going to try to save it, I'll just use it because it's a lot easier to design maintanable web sites in it than in the classic ASP/PHP model.