Choice of Language for Large-Scale Web Apps? 801
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?"
Perl? (Score:2, Interesting)
Who do you have? (Score:3, Interesting)
WebObjects (Score:5, Interesting)
Re:Perl? (Score:1, Interesting)
Re:Where are the best practices for each language? (Score:1, Interesting)
Let me get this straight... (Score:2, Interesting)
PHP (Score:3, Interesting)
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? (Score:4, Interesting)
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.
Re:WebObjects (Score:3, Interesting)
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!
Please stop insulting python. (Score:5, Interesting)
Just use a decent python web framework with a real webserver, zope is a waste of time.
Programming language is NOT a success factor!! (Score:2, Interesting)
CafeSpot uses Common Lisp (Score:1, Interesting)
Re:Depends on what you want to do... (Score:2, Interesting)
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 (Score:5, Interesting)
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:Perl? (Score:2, Interesting)
Re:WebObjects (Score:2, Interesting)
Re:The real problem in comparing Java and PHP (Score:3, Interesting)
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.... (Score:5, Interesting)
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:You are contradicting yourself. (Score:3, Interesting)
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:Polyglot (Score:1, Interesting)
Consider some of the downsides. Interlanguage interfaces are often more complicated to use, setup, and maintain. Having multiple languages means it is more difficult to do things like use a debugger across the application. If you have some kind of standard error handling mechanism that gives the callstack you have to implment that in every language.
Your people also have to maintain a high competency level in multiple language platforms. This will probably come at the expense of expertise with a particular platform. For example, with multiple languages there will be some overlap in the functionality they provide. You might find yourself spending time learning Php/Pear/Db and Perl/Cpan/Db libraries which provide nearly indentical capabilities. In the same period of time, you could have learned Php/Pear/Db and Php/Pear/DataObject (an OO library on top of Pear/Db). Or maybe you could have learned JDBC and Hibernate.
Even if you don't have that kind of higher level overlap (because all business logic code is in one language, all data access layer code in another, etc), you're still having to learn and maintain knowledge about things like
foreach my $item(@list) {}
vs
foreach ($list as $item)
or
preg_match vs m//
In addition, by strictly separating out functionality (db code here, presentation code here), you miss out on many of the synergistic capabilities of a language. For example, Pear's DataObject libraries have QuickForm integration to make it easy to create web forms for database objects. If your DB code is separate from your web code, you can't use this kind of thing. If you decide to go around your DB codes back and use this anyway, then you're back to learning/maintaining database access knowledge in two separate languages. Since we're talking about data access at different levels of abstraction, it's not quite as bad as spending time learning Pear/Db and Cpan/Db, but there is still going to be duplication of effort because you'll need to know a little about the stuff that DataObject is built on top of.
A lot of people like to talk about languages and the right tool for the right job. You wouldn't use a hammer on a screw. To some extent, this is true for programming languages. You wouldn't want to write a web application in C or Cobol.
However, unlike simple tools like hammers and screws, programming languages are inherently flexible multi-purpose tools. If you try to hammer a screw into the wall, it won't work correctly. If you try to make a web app in C, it's possible. There is probably even an entire community of crazy folk making C web development libraries. In some cases, it may be easier for you to make a web app in C than in some language like PHP depending on your invested expertise.
There's some server monitoring software called Nagios, formerly Netsaint, whose core functionality was written in C. It also has a CGI interface that was written in C. Personally, I think it is daft to write CGI's in C. Everytime I think about it, I remember that seen from the holy grail, "everyone said it would be daft to build a castle in a swamp, but I built one anyway." However, if the author of Nagios had decided to spend lots of time learning new web programming platforms instead of creating a good server monitoring program with a basic CGI/C interface, maybe his project would never have achieved the status it has today.
Don't get me wrong, using multiple languages can be beneficial. If there's an overwhelming case for adding a new language/tool into the mix or if it's the only way to get something done, then by all means do it. But don't don't diversify uneccessarily.
Just a because a language is the best tool for a particular class of tasks does not mean it is the best tool for the job at hand. Perl is the undesputed leader
Re:Perl. (Score:1, Interesting)
Why do you think slashdot hasn't had any big change in its layout in years? The whole house of cards would fall down! Have you ever looked at slashcode? 'Cause I am scared to!
Re:Perl? (Score:2, Interesting)
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:Ruby on Rails? (Score:2, Interesting)
Re:Perl? (Score:2, Interesting)
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.
Re:WebObjects (DON'T!) (Score:1, Interesting)
Add to that, that WO costs money, is closed source, and good luck getting any support whether you've paid for it or not... it's not a very good deal.
It is kind of bad though, because the idea and architecture behind WO makes more sense than most things from a developers perspective. It is fun and fast to develop in and the tools are good. It's just that in the end, it usually won't work because of something intricate... or just that the machine dies under load. Oh, and the build systems use tons of magic, so if anything breaks (or you just upgrade WO)... you probably will have to start over with a new project. And so on, and so on...
Don't take my word for it, see any relevant (non-Apple controlled) mailing list or forum.
Some other poster mentioned Rails, and I have to agree on that, so far. It builds somewhat on the same idea, but better - this is simply next generation. What lacks there is actual builder tools, but they aren't as needed. It still may need some maturing, but unlike WO it is actually doing that constantly, which is a plus. =)
If you really like WO, I seem to recall other alternatives like Tapestry as well.
Oh well, just don't say you haven't been warned... WO is a great idea in theory, but hopeless for any practical use.
Re:Depends on what you want to do... (Score:1, Interesting)
Re:Seconded! (Score:2, Interesting)
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:Hmmm.... (Score:3, Interesting)
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:Polyglot (Score:3, Interesting)
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? (Score:2, Interesting)
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 (Score:3, Interesting)
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:Seconded! (Score:2, Interesting)
My "aspersions" are based on using Perl since Perl 3 days--roughly 15 years. Perl has numerous severe problems that make testing and debugging in it unnecessarily hard. People like me picked up Perl back then because it was a slight improvement over sh/awk/sed scripting, but fortunately, lots of better open source scripting languages have come along since then.
I'm not one to disparage other languages. There are plenty of desirable features in each.
Sorry, no go. One can debate the relative merits of Ruby, Python, REXX, PHP, and VB, but Perl clearly is inferior to all of those. For small projects, Perl's libraries still may tip the balance, but for any kind of large project, the severe deficiencies of the Perl language make it a poor choice.
Perl6 perhaps may re-enter the race, but it is effectively a different language from the Perl we all know and despise, and Perl6 doesn't seem to be happening.
Re:Not all true (imo) (Score:3, Interesting)
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