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?"

Comments

Perl?

[hanshq.net]

Perl is also a nice choice. Sites Running mod_perl

Re:Perl?

[VGPowerlord]

I do some Perl programming, and I try to avoid the "I can do that in fewer keystrokes!" mindset. The only exception to that is using the ternary operator to set variables that could only have two possible values based on a condition. Another thing I hate seeing in perl is this:

sub change_it() {
s/something/nothing/i;
return chomp;
}

This sub is oversimplified, but it isn't immediately obvious to a non-Perl coder that the substitution and chomp are happening on the first argument to the function. The same goes for the "diamond" operator <>. It's not immediately obvious that an empty diamond operator works on STDIN... unless @ARGV is populated, in which case it works on those instead. Which probably isn't what the author intended.

Re:Perl?

[Fjornir]

Your point about the default operands is well received -- but it's a handy feature included in the language primarily to support a specific scenario: one-liners. A small change in your mindset will help you tremendously with these -- think about Perl as being rather like an RPN calculator.

As to the diamond operator it has an ecological niche which is part of Perl's philosophy of cooperation -- in this case the cooperation is making it easy to write Perl programs which exhibit similiar behavior to a whole slew of unixish shell utilities. Say you wanted to make a special kind of 'cat' utility -- the diamond operator would prove quite handy for this.

In both cases these default behaviors are there to make certain sorts of tasks easier to perform with Perl. Use them when appropriate. Use the more explicit longhand format when appropriate.

I'm pulling for you. We're all in this together.

Re:Perl?

[rascal1182]

This thread is really starting to make my point for me. Perl is just too idiosyncratic. There's too much to remember, and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.

Yes, there are some nice features for writing shell utilities (which is where Perl should be). But if we're talking large scale apps, my thoughts always go to object orientation, when things get more complex than processing text and command line options. Don't go telling me that Perl has superb OO features.

As much as webtrash gets a bad beat, developing a good application is a really complex problem, simply because of the limitations of the web.

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)...

Also, your sig is awesome.

Who do you have?

[rob_squared]

Smarter people than myself have said it, if the people you have know a certain language, use that, don't force them to use something else even if it is conceived to be better. Now if you're going out and specifically hiring people for this project, things get a whole lot more touchy-feeley and you'll be forced to do much research. But then again, you're probably expecting to do a lot of that anyway.

WebObjects

[lightningrod220]

Apple uses WebObjects for its online store and the iTunes store. Consider that those go under a lot of stress. Those seem to be the biggest examples of its use, so I don't know what kind of performance it does in other situations. But for an all-around package, it seems to be pretty good.

Re:WebObjects

[Pius II.]

I started using WO last week, and I have to say, it's great. I was able to go from "I don't know what a database is" to deploying my own Java client for my web page interface in about two hours. Of course, knowing Cocoa, Cocoa Bindings and the corresponding patterns helped a lot.
BTW, according to the blurb on the (German) Apple home page, other large users of WO include the Deutsche Bank, O2, Consors, Bayer and T-Systems.



Fuck T-Systems!

Re:WebObjects

[FlyerFanNC]

I've looked at Ruby on Rails, and I'd love to use it because I *love* Ruby. My problem with Rails is its poor Oracle support. This may have changed in the couple months since I checked it out, but it doesn't seem likely (to me anyway). The impression I got from the design of the database API is that it's very MySQL-centric and provides little flexibility for databases that do things in other ways. Unless the API itself changes, I don't see how it could adequately support Oracle, and for me, poor support for Oracle is an automatic disqualification.

Let me get this straight...

[Anonymous Coward]

PHP is only popular because it's popular?

PHP

[AVryhof]

We have a small website (85,000 hits a day)

So here's the rundown of what we use...
CGI/Backend: PHP

Client Side: Javascript

Presentation: CSS/HTML 34 (Somewhere between 3.2 and 4)

Then of course there is the PHP and static generated RSS feeds.

Re:What about security?

[jadavis]

Perl, Python, and Ruby are handy because they have an interface to C. You never find yourself without a module if you can just make a wrapper for C.

Although I haven't tried it, you can get similar benefit from using Jython. Having two languages like Python and Java at your disposal has got to be a godsend for a large web app. I'm not sure if you still get to use C modules if using Jython.

Please stop insulting python.

[Some Random Username]

You can certainly make a large, high traffic site in python. But not with zope. Zope is brutally slow, and the only thing you can do about it is shove a cache infront of it, which does nothing to help speed up user-specific content.

Just use a decent python web framework with a real webserver, zope is a waste of time.

Programming language is NOT a success factor!!

[koenkam]

The critical success factors for a large webapp are: 1. The programmers ----- The differences in popular OO web programming languages (Java, PHP, .NET) are really small. It's good programmers who make all the difference. Programming languages: - don't make scalable applications. - don't draft designs or requirements. - don't make code that is easily readable and maintainable. - don't create bugs or do poor optimization or create application bottle necks. These things are done by programmers. 2. Persistant data ----- For large-scale websites, speed is mostly determined by disk access. Database queries may take up to 50% of your total page execution time. Master databases can only handle a few hundred database writes per second and can easily become a bottleneck. Downloading uncached files can create 100% waits on your disks. Programming languages matter on large scale websites, but only after the point where the persistent storage problem has been fully addressed.

Re:Depends on what you want to do...

[unixbugs]

I probably write some of the ugliest code you've ever seen in any language, and using PHP, JavaScript, and MySQL with XMLHTTPRequests made me the sole developer of an intranet server for use by over 100 employees around the world.

OK, not large scale, but large enough to be a major pain in the ass when features and departements need to be added - but that was my fault for coding first and then checking to see if it works at all. Ive rewritten the thing a couple times since and can say that the system is now modular enough to where functional additions are a breeze.

Knowing nothing about any of these 'languages' I whipped up a beta in about a week with over 2000 lines of code. Its a real monster now with around 7500 lines of code, and does everything from manage employee information to providing a web based time clock and report generator. It even does some graph generation for employee performance analysis and has levels of logins where 'managers' can use the CMS front end to edit the site dynamically. Why would I go looking else where and waste time trying to implement a new system or language when this one has all these goodies right out of the ./configure?

Employee records, procedural and technical documentation, timeclock stuff, schedules and search features, its all there in no time. The idea was to replace the endless stacks of paperwork on my immediate supervisors desk, and now we wonder how we got along without it and why we didn't get someone to write it sooner.

If this does not say anything about the flexibility of these languages I don't know how to. My point is that if I can do this, anyone reasonably technically inclined can.

As I dig into the world of web based application design and engineering I'm finding more and more possiblities for how to handle events and situations where data should be presented and handled in a specific manner to and from the user. The PHP language is AWESOME for this kind of stuff , and as time progresses its track record will only improve.

I like telling people about this because it lends credibility to a language many of our customers don't see as a viable solution to any serious web based business endeavor. Its all in how you implement it, obviously. If I had to write this thing in C, Bash, or God forbid, Perl, it would have been written so, but since PHP was available and my initial attempt at managing user logins to a small test site was a great success, it was all down hill from session_start();

Python + PHP + XML-RPC

[MikeFM]

A solution I like is to write a Python backend that is exposed to the frontend as XML-RPC. Then use the language your designers find easiest to work in for front-end coding.. usually PHP.

Python is great for the backend because it has good namespace support which helps a lot for big complex programs. PHP on the other hand is well known and extremely easy for doing various web-scripting type tasks. I have a little PHP function that gets called by the PHP server for every page (without needing to be in the code exposed to the PHP coders) that simply passes the page inputs to Python over XML-RPC and puts the response into a global variable. Then the PHP coders jut display the results however needs to be done based on the inputs and outputs.

Some nice benefits of such a split system is that it's easy to keep UI logic sepperate from application logic and it's easy to split your application up over multiple servers so that it can scale to any load. For example you might have two PHP servers, three Python servers, and a DB server dividing the load. Normal load balancing techniques work just fine for deciding how the machines talk to each other. Pretty nice to be able to just throw another server in where it's needed if you suddenly find a 9/11-type day where your site is getting unexpectedly high loads.

Of course you can split your processing up in more levels if you need to. I like to abstract out all my queries into their own XML-RPC interface that sits in front of the DB so as to not allow direct access to the DB for security reasons. Anyone trying to hack the DB would have to use my stored queries and work through my XML-RPC interface rather than being able to access the DB directly. If your dealing with sensitive information it's just another layer of protection. If you have to access third-party systems that use some unstandardized method of communicating then it can help to keep your code clean if you create a proxy interface between those systems and your own that speaks XML-RPC. This way the code for speaking to that other system is a completely sepperate code base and your main code base is kept clean.

Re:The real problem in comparing Java and PHP

[mbyte]

I could not agree more. I used php extensively before and often laughed at J2EE as oversized and overblown for web sites. But i constantly hit the wall with every more compley web application. The fact that your goal is to build up your data structure as quick as possible only to display them and destroy them one moment later makes any real programming a pain. I even investigated in building PHP application servers, but they are far, far from mature. Most are just trying out the possibilities.

Compare to java now, many new technologies emerging to make J2EE simpler and less painfull (no need to edit XML config files of 2k sizes just to display a simple page). One nice ones i found was wicket (with hibernate and possible spring in the middle)

Still PHP has lots of uses, its enough by far for your average CMS. Use the right tool for the job !

Hmmm....

[einhverfr]

I actually like PHP for large-scale web apps. However, I agree that many PHP programmers do create unmanageable code. This is, however, a programmer issue rather than a language issue.

I started writing HERMES (a CRM framework/app) in PHP and it is now over 20k lines and when I have time to add enhancements it will grow again. The code is incredibly manageable simply because the complexity of the application meant that I had to divide the code into four main areas (each handled in different sets of files):
1) Main engine(s)/UI framework
2) UI generation code/data input screens
3) UI event handling code
4) Core object logic.

This way, if you want to change the user interface, you just change the user interface. System-wide changes get made in one place where screen-specific changes get made somewhere else.

Everything is relatively well abstracted, so the code is very manageable.

Now, other languages have very specific problems associated with them:

1) Scripted languages in general: slow performance

2) Compiled languages in general: Requires rebuild before changes take effect, so testing and retesting is slowed down.

3) Java/.Net/Byte-code languages: Worst of #1 and #2 above.

4) Python: Performs a little better than most scripting languages, but there are times when its reference-based structure can cause bugs to be very difficult to find.

5) PHP: Many PHP programmers write readible but unmaintainable code.

6) Perl: Many Perl programmers write maintainable but unreadible code.

7) LISP: See Perl only even more so.

8) ASP. ASP is only really useful in large apps when paired with COM objects written in C++ or VB. So you have the problems with a scripted language combined with the problems of compiled languages.

But again, many of the worst issues are programmer rather than language issues. Then again, depending on your project, you may have to eliminate possibilities because of language capabilities.

Re:Hmmm....

[MourningBlade]

6) Perl: Many Perl programmers write maintainable but unreadible code.

7) LISP: See Perl only even more so.

Hmm...having read quite a bit of code in modern common lisp packages, I'm going to have to disagree. For the most part, the code was quite readable and understandable. Some of it took a while to get the hang of (Aranaeda, for instance), but this was because what it was doing was large.

That's the average. On the other side of it I've seen code of blinding clarity that expressed its intentions so straightforwardly that it was amazing. This was done using a system of macros to create the way to describe these things.

On the lower end I've seen some lisp code that would make you puke, yes, but it's been by far the exception.

I find that the ability to express things in an ideal way in common lisp and the fact that programming by that method is the easiest one (if you're experienced in it) leads to very clear code.

Scheme, on the other hand, has been a bit more nasty to me. I have found scheme programs to be a lot larger and quite a bit more complex than their equivalents in common lisp. I think it's mostly because scheme is like talking using small words: it doesn't affect the brilliance of the ideas, it just takes more words to say them - though no one will require a dictionary to understand it, whereas they might with common lisp.

Re:You are contradicting yourself.

[NutscrapeSucks]

Like most languages, it's possible to write unsecure code.

And PHP does a few things that are UNlike other environments that encourage insecure code.

The database interface pretty much encourages SQL-injection friendly logic, and the "Magic Quotes" hack that PHP came up with is just disgusting. Compare that to Java where programmers are encouraged to use safe Command and Parameter objects, or just abstract the SQL generation away with Hibernate etc.

And the Register Globals thing was just lamebrained to begin with. Apparently there's still projects that depend on it, so it can't entirely be removed.

So, yeah, webapps can be insecure in any language, but much of PHP's poor reputation stems from PHP trying to be too smart for their own good, and a community that doesn't really understand good practices.

Re:Ruby on Rails?

[gattster]

I've been using it professionally for a few months and LOVING it. My experience breaks down like this: PHP 1998-2003 Java(Spring/Hibernate) 2003-2005 Ruby/Rails - 2005-???

Re:Seconded!

[Tablizer]

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

I don't know about that. Perl has a reputation for being a "write-only language". Even if initial development is faster, long-term maintenence may be at risk. It is not that Perl is inherently tangled as a language, it is just that it seems to attract the kind of people who *like* obfuscation, for unknown reasons.

Re:Polyglot

[SeventyBang]

And...ASP is not a language.

You can write for ASP using PHP, PerlScript, JScript, oh, and what those with an overwhelming trait of ignorance presume ASP to be: VBScript.

It's no more difficult to write an ASP-based website using the other (non-VBScript) languages than it is VBScript. And for that matter, those are the scripted languages. You could code in practically any language you choose if you can compile it and plug it into IIS appropriately.

What has seemed to be an interesting pattern is those who write IIS|ASP web sites and are wearing blinders - believing VBScript is the only tool they can use, generally write slow, sloppy sites. It doesn't mean VBScript alone makes the site projects so bad, but the people who are so shortsighted seem to not fully comprehend the architecture they're dealing with. These are the same people who think they've invented something no one else has thought of: stashing various ADO objects in Application() and Session() variables. Almost without exception, if you sit down with access to source code on a poochy site and grep for "Set Session" or "Set Application", you'll see a slew of hits. And the reason those two statements will appear is because the only people who do those things are VBScript-only people. Oh....anyone whose code which contains such statements should be taken out back, have their peepee whacked, then die a death of a thousand cuts in return for the grief they cause the users of their web sites.

Re:Lotus Domino-what's the problem?

[dogugotw]

Guess I must be using a different Notes than you folks. OK, I only write apps using the native gui, no web browser stuff yet but I love this thing. I can put up a fairly complex workflow app in about a day that scales nicely, is secure, and is easy to maintain. I've pretty much written an entire manufacturing quality system using Notes. It's a breeze to support. We have no admin so I double duty as developer and admin. I support 50 apps or so and 150 users solo and go home every night on time, don't work nights or weekends, and actually take vacations.

If you need to search code, use addins like Team Studio Configurator. It does have a query language built in, you just need to know how to use it. You can build adhoc user driven queries without a lot of effort. (check LDD's FAQ of FAQ for the 'friendly query' article).

It's not a relational db and that drives some folks nuts. Once you get your head wrapped around an object db model, and use it for what it's good for, you can do wonders in almost no time at all.

It does support large web based apps (see IBM's Notes Developer Domain and the forums) that use JavaScript, html, xml, java, whatever you want.

User rights management, heavy duty encription, replication (second to none) all come standard. Every app is web enabled without doing anything special (yes, the apps won't be very pretty or friendly but the point is the app works using the Notes client or a browser by without doing any extra programming).

And that's just for starters. Your piece of shit is my palace of gold. It's kept me happily and gainfully employed for almost 10 years now and my company keeps looking for new and more interesting places to use it.

One man's opinion.

dogu.

Re:Not so much

[SimHacker]

Good Lisp code is zen-like in the way it uses white space and indentation to express structure, instead of cluttering the code up with a bunch of punctuation. Lisp macros let you program with meaningful words and phrases, which are much easier to understand than punction.

Lisp doesn't require excessive punctuation to write understandable code, because it has a real macro system. Lisp's macro system is vastly more powerful than "syntactic sugar" or string substitution macros like the C preprocessor. It enables you to deeply customize the language for the task at hand (including extend the surface syntax by adding punctuation, if you insist).

Throwing in a bunch of punctuation marks doesn't automatically increase readability. But at least the base Lisp lanuage doesn't use up all the punctuation marks itself like Perl, and it even allows you to define your own for application specific purposes. All that and a kick-ass macro system: What more could you ask for?

The problem with messy, nuanced, ambiguous, punctuation-heavy "Do What I Mean" languages like Perl is that it's much more difficult to figure out exactly what the code is doing just by looking at it, because there are so many special context sensitive rules and special cases (like scalar versus list context, etc), which intricately interact with each other.

Perl has a much higher "syntactic surface area" than Lisp (they're at different ends of the spectrum). High syntactic surface area makes a language hard to learn and understand. All of the effort pointlessly wasted struggling with Perl's fractally complex syntax would be much better spent solving real problems that weren't solved decades ago by Lisp.

Many Perl evangelists actually prefer to program in Perl because it allows them to show off how studly and ingenious they are to handle such a pointlessly complex language, and it gives them job security because it's so impossible for anyone else to understand or maintain their code. So of course those people hate Lisp for its simplicity, and spread misinformation about it like "too many parenthesis".

-Don

Re:Not all true (imo)

[Westley]

It sounds like you have a lot better luck with "Go to definition" in VS.NET than I do. With the large C# projects I work on, it very rarely works. At home with smaller projects, it seems to be okay - but still less convenient than in Eclipse. (I didn't mention the Declaration view in Eclipse, which shows you the declaration of whatever you've got selected - no need to even navigate there half the time.)

As far Find References, I've just trawled through VS.NET 2003's menus and I think I've found it - is it the "Edit -> Find and Replace -> Find Symbol" option? I'll admit I hadn't seen that before. Thanks for pointing it out. Even though I prefer the way Eclipse does it (finding uses of that particular identifier, rather than any identifier with the same name) it's now not a big enough issue to get on the list, as it were :)

Oh, I forgot to mention something else which VS 2005 really should have pinched from Eclipse - the idea of combining class view and solution explorer. Being able to expand a .java file to see what classes are in there, then expand the classes to see the methods (and refactor against them etc) is very handy - I'd forgotten about it until I started navigating around a project to try to use Find References in VS :)