Slashdot Mirror
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?"
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.]
Slashdot monitor for your Mozilla sidebar or Active Desktop.
For everything.
Perl is also a nice choice. Sites Running mod_perl
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.
I don't get it.
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.
No question about it!
performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools
Performance? Assembly will give you the best performance followed by C and C++. All three of do not have that great of support for web apps..
However, Java is almost exclusively being used for large enterprise websites. Its powerful enough to handle the big jobs, and using the appropriate app server will give you great performance.
Cost of development is heavy in initial development, but pays for itself in maintenance. Most libraries and APIs are free in java (struts, spring, hibernate, tapestry, etc etc etc...). I'd say they are second to perl in terms of freely available and powerful libraries and APIs.
Development tools? Just check out the (free!) eclipse platform.
In my mind there is no question that Java (more specifically J2EE) is the best option for general large scale enterprise applications.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
And you said it...
Maybe language choice is irrelevant, only good people (developers) matter?
We are blind to the Worlds within us
waiting to be born...
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.
What's your damage, Heather?
It does it all, and it values the most expensive component of software (for all but the biggest Web apps): programmer time.
this should've been a survey
bite my glorious golden ass.
For large scale applications, java, c/c++, perl, PHP just don't cut it. You should really check out mod_fortran. Everything you love about fortran with none of the hype.
I've been getting into Ruby on Rails 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.)?
Python is the way go to. For anyone who's built custom sites based on Zope, I think they would agree with me. Python is really easy to use for building big apps for use in web stuff, and Zope provides an easy-to-code-for application server.
Hi there
(yes I program with this monstrosity of a system)
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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?
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.
This is my sig. There are many like it but this one is mine.
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.
Perl is a great choice. You can do anything with it and nobody else understands what your code does so they have to get you to maintain it :)
PHP is only popular because it's popular?
Microsoft uses ASP (what else?).
.net
err, no. MS does not use asp, they use ASP.net. There is a BIG difference between the two. The former is VB and the latter is C#,VB.net,J#,managed c++ etc etc. basically any language that runs in
The war with islam is a war on the beast
The war on terror is a war for peace
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.
Make America grate again!
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.
Social scientists are inspired by theories; scientists are humbled by facts.
Ruby on Rails, try it, you won't want to use anything else. Ruby on Rails is just so sweet, just like the original Java alpha was all those years ago.
threadeds blog
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.
I still use PHP for a lot of personal work and quick stuff, but I've been leaning more and more on Python, Zope, and Plone for building stuff at my day job. If you need to quickly and easily implement role based security, Zope makes it drop dead easy because it's built in and through ZEO, zope apps can be highly scalable. Of course as with most things, use whatever technologies get the job done. For example, my Zope apps live behind an Apache server that I use for SSL as well as access control.
To the making of books there is no end, so let's get started
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.
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...
Large standard library :-P
Excellent MVC model
Integrated caching capabilities
You can compile your libraries before uploading
Excellent Web Services model
Free tools
Works on Linux (through mono)
Large third party support
Very Fast
Easier to use and deploy than J2EE
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.
Recommend Brainfuck to your company. Sure, they will eventually fire you when they realize what they got into, but you will go out with a hell of a snicker.
Table-ized A.I.
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.
This is my sig. There are many like it but this one is mine.
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.
This sig has been temporarily disconnected or is no longer in service
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.
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.
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 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.
Speak before you think
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.
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.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
saying that E-Bay uses ISAPI / C may be oversimplifying things. I see that some of their url's still include isapi.dll, which does suggest using ISAPI. But they had gone on the public record a few years ago as saying they were migrating to Java / J2EE, specifically IBM WebSphere software.
a ppdev/story/0,10801,63692,00.html
http://computerworld.com/softwaretopics/software/
I would guess that they're actually using a mix of technologies. Any insiders have any insight they can share? Even anonymously?
// TODO: Insert Cool Sig
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.
LedgerSMB: Open source Accounting/ERP
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.
Whenever I hear the word 'Innovation', I reach for my pistol.
yeah, there is a huge difference between the two. With Visual Studio ASP.net has been by far the simplest web dev environment i have used. It seems the story submitter didn't bother doing any research becasue of the MS factor. That unfortunate becasue ASP.net is actually really fast and really good.
The war with islam is a war on the beast
The war on terror is a war for peace
You say it's "simply not true" but don't actually give any reasons.
.NET 2003 and Eclipse in daily work. Here are just a few reasons I much, much prefer Eclipse to VS.NET:
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
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?
It is Saturday, and instead of being out in the sunshine, taking in rays, talking to women, GOING OUTSIDE, here we are, in front of our screens debating about which language to build our web apps with? Can we suck enough?
Dont bother replying, because when this damn compile is done, I am going outside if it kills me. I wont be here to read any replies, dammit.
You forgot -
VI vs EMACS
GNOME vs KDE
The only reason people think they use ISAPI is because that's what they originally used, and an executive decision was made to not break any existing links at any time, ever. Check the Powered by Java image. The /ws/eBayISAPI.dll that you see in all of the requests just invokes a servlet.
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-???
ASP is a better environment than ASP.NET???
.NET's arcane vocabulary and squirrely architecture
/., but I refuse to let religion cloud my view on a good technology.
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
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
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.
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.
[fill_in_the_blank] is the way go to. See [blank].org for more. For anyone who's built custom sites based on [blank], I think they would agree with me. [blank] is really easy to use for building big apps for use in web stuff, and [blank] provides an easy-to-code-for application framework that saves lots of time and money.
Best of all, it is [blank]-oriented so that you just snap functionality together like Lego blocks to get an instant app that runs at the speed of light almost right out of the box! And [blank] scales to every user on the entire planet. And it plugs into XML.
Only a Devry graduate would use anything different. Go with [blank]!
Table-ized A.I.
I think that Java is the gold standard for small and large web portals in terms or reliability, good performance, etc. I have done portals that simply use Tomcat with either Prevayler or Hibernate/JDBC for persistence that basically run forever, until we want to do a software upgrade.
That said, for CRUD applications, RoR is good - the scaffolding gets you up and running quickly, and views, controllers, etc. are easily customized.
I used to use Python and Common Lisp a fair amount, but not recently. The UnCommon Web Common Lisp package looks good; I would like to check it out in some detail when it is more mature. It uses continuations (like Seside for Squeak and VisualWorks Smalltalk) to manage state between web pages.
Sure, there is some overhead for using multiple langauges and frameworks, but I have always believed that it is best to be a "generalist" who can drill down when required.
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.
.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.
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
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...
Of course you also have to adjust for a few orders of magnitude in the other direction, now that registers are larger.
Here's how to add two 32 bit numbers on the 8 bit 6502 (C = A + B):
Oh man, that was exhausting.
-Don
Take a look and feel free: http://www.PieMenu.com
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.
Are you going to trot out the "parenthesis are hard to read" argument? Well take a look at XML: that has TWICE THE NUMBER OF PARENTHESIS, only they're pointy instead of curved. That old "I'm afraid of parenthesis" argument is bullshit.
Now look at Perl code: instead of seeing the explicit, unambiguous parenthesis in the code, you have to remember and resolve all of the implicit and complex special syntax rules, punctuation, precidence order, left/right evaluation, contextual quirks and special cases, etc.
If you think Lisp is harder to read than Perl, then you obviously don't know either language, and you're just basing your beliefs on rumors you heard ignorant people distort and repeat, without learning those languages for themselves.
-Don
Take a look and feel free: http://www.PieMenu.com
#3 is where there's the most flexibility. Speaking very generally, there are two ways to go:
a. Lightweight scripting systems that depend only on the web server (probably with a loaded module) for support. Typically PHP, Perl, Python, or JSP/ASP using Java or a Microsoft language.
b. Heavyweight systems, of which the two most common are J2EE and .NET. J2EE uses Java as its language, and .NET usually uses C# or VB.
The usability, performance, etc., of the heavyweight systems depend as much on the middleware as the language itself. .NET is .NET, but for J2EE there are several choices. In my own experience with heavyweight systems, I found Java to be wonderful, but our J2EE server (Oracle's) very difficult to work with operationaly, and way too complicated for what we needed. So, in my opinion, one has to have much education, experience, and patience if one is to use a heavyweight system.
My conclusion, however, would be that a heavyweight system is the correct choice for a big web application. My bias is towards J2EE because it's more open (and even has open source choices available), but the complexity of J2EE servers is a big concern.
From what I hear, .NET has superior development tools and better support. I don't know whether this is (a) true and (b) worth the disadvantages of using a proprietary system.
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?
... 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.
... 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.
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
If you do write web-apps in C++
FYI, features 1, 5, 6, and 9 are all supported in VS.Net by using Resharper. I couldn't imagine using VS.Net without it...
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
Take a look and feel free: http://www.PieMenu.com
most Visual Studio.NET developers don't understand the WWW and the Internet at all, they drop and drag controls onto a form.
:-) 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.
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
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.
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.)
:)
.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 :)
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