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?"
I prefer english
There is no sig
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.
..almost every web host supports it. I'd say 99% of hosts that market to online audiences support PHP/MySQL.
How many of them support Python/PgSQL, for example?
None. That's why PHP is popular--if you code in anything that isn't PHP, most people on LAMP won't be able to use it. People not being able to use it = people not buying it. Which is bad.
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.
You ignorant fools! FORTRAN! The only real uppercase language!
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!
perl
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?
Ready, set, go!
Erlang!
I would elaborate, but I'm afraid it would go straight over the heads of all you imperative programming dweebs. </smug>
-- If no truths are spoken then no lies can hide --
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.
Lets not forget ASP.NET, but since we are talking langages and not frameworks/platforms i would say "C#"
You must choose a language which is actually maintainable. By maintainable we mean the language must supports modern ways of modularization etc.
This means PHP is a poor choice due to the lack of namespaces and poor resolution of includes.
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.
anyon has some good questions on building a web application, but once the thing works, it must be audited regularly and updated to secure poor coding. Perl and Python are excellent choices for this - build the front end in whatever you want, utilize the huge libraries of Perl and Python modules for back-end functionality, and keep tabs on updates to the modules to keep the application from being exploited.
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.)?
Emacs
Slashdot uses perl! Regardless, If I were to choose any web language I would use Perl. Lib's? Free! Tons of dev's out there too.
snowulf.com
Python of course.
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?"
Your OS is written in it. Your server is written in it. Your browser is written it. Your database is written in it.
Get the point?
Bottom line: C is the lingua franca of computing.
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.
How about asp.net on the front end and vb.net on the back end...
The Kai's Semi-Updated Website Thingy
Microsoft ASP.NET is also an alternative. It's fairly new but the new MSDN is written in asp.net 2.0. It's a mixed application between parsed stuff (like traditional asp and perl) and compiled stuff like Java, C++. Couple benchmark proved that this was faster that Java. Not platform independant for now, but it's a mather of time with mono.
I like the language... Microsoft took java, added language features I was missing from Borland's C++ builder (events, properties, delegates), let you call an windows dll.
I've also enjoyed the platform. It was rather trivial to change our logging system to use non-blocking calls to send these logs over the MessageQueue, and then to have an NT service receive those messages for later processing.
When the database CPU load went up to 70% we implement caching using their intrinsic ASP.Net Cache objects on often used and rarely changed data. This immediately dropped the load down to 2%.
Also, I work in a LAMP shop (mysql/perl, not the lightbulb kind), and we've had no problems interfacing our systems using SOAP.
I don't think c# is always the best tool for front-end websites in all situations, but for the backend I've been extremely happy with it. Even for the front-end I've been happy.
PHP/Perl/Python are all good choices where performance is not critical, those particular parts would be better written (or re-written after design and prototyping are completed) in C or C++. I like Python in particular as a prototyping and glue langaugage. I would avoid Java at all costs as it is not a standard commodity language but a single companie's product. The same, of course, applies to C#/ASP only more so as you are then locked in to a particular vendor's platform - not just a particular vendor's whims pertaining to the language.
Java (gmail)
Gmail does not use Java, it uses Javascript ( AJAX).
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?
ColdFusion is always getting dismissed, but it's actually very easy to learn and maintain, has much better debugging than PHP and can scale to very large web sites - yes it can - the most widespread misconception about CF is that it doesn't scale, but just take a look at myspace.com it's currently ranked 24 on Alexa and it runs entirely on CF.
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
Carl
Vote Libertarian
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!
This is wrong. They use JavaScript, not Java. Completely different entities.
http://tnx.nl/php
* Re^2: Is Perl a good career move? by Juerd, 2005
o Still no namespaces
o No closures, not even anonymous functions
o No good HTML parser
o No easy MIME builder
o No good WWW library
o No CPAN
o No arrays
o Less useful logical operators
* Yaywoo! by Dave Brown, 2004
o No way to avoid the (unsafe) shell with system()
o XY-problem
o Huge proliferation of different functions to do more-or-less the same thing with minor variations
o Second parameter and return value make no sense
o Bad spelling in function names
* Why PHP sucks by Edwin Martin, 2004
o Bad recursion support
o PHP is not thread safe
o PHP is crippled for commercial reasons
o No namespaces
o Non-standard date format characters
o Confusing licenses
o Inconsequent function naming convention
o Magic quotes hell
* Perl vs. PHP - octo's subjektiver Vergleich by Florian Forster, 2003 (German)
o Perl is faster than PHP
o Perl is more versatile than PHP
o Perl has better documentation than PHP
o PHP lacks support for modules
o PHP's here-docs are useless for Windows users
o PHP lacks a consistent database API
o PHP dangerously caches database query results
o For graphics, PHP is practically limited to GD
* I hate PHP by Keith Devens, 2003
o Idiotic call-time pass-by-reference deprecation
* Experiences of Using PHP in Large Websites by Aaron Crane, 2002
o PHP promotes interweaving presentation with business logic
o Not having namespaces causes problems
o Global configuration with php.ini
o Oversimplification leads to excessive complexity
* PHP Annoyances by Neil de Carteret, 2002
o No real references or pointers
o No idea of namespace
o No componentization
o Wants to be Perl, but doesn't want to be Perl
o No standard DB interface
o All PHP community sites are for non-programmers
o No chained method calls (Not true anymore --tnx.nl)
o No globals except by importation
o Both register_globals and $_REQUEST bite
o Arrays are hashes
o PEAR just ain't CPAN
o Arrays cannot be interpolated into strings
o No "use strict" like checking of variable names
I am sure even the average Slashdot visitor's English is good enough to have the feeling this submission was translated from English to Russian and then back to English? I mean, "good quality people"? "What language you would chose?" ROFL.
Duh, Visual FoxPro of course. Where would Egghead.com be without it today?
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
I use PHP on the front end and call Perl and C programs when necessary. The results of the Perl and C programs are then rendered to the screen with PHP.
I've had problems with the scalability of some of my back end stuff that was written in Perl. Some image processing modules had to be rewritten in C for speed.
for real applications which are more than a database backed dynamic website.
.net has no feature that j2ee couldn't provide and it has nothing like jca).
when it comes to critical features like 2face commits when speaking whith cics and ims at the same time, nothing beats j2ee. perl is unmaintainable at a large scale, php is to much front-end-oriented, and
beer as in "free beer"
org.slashdot.post.SignatureNotFoundException: ewg
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.
Amazon uses Mason
Realities just a bunch of bits.
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
ASP: Advantage - one of the largest pools of experienced developers. Disadvantage - ties you to Windows; can't take advantage of much free/open-source software.
PHP: Designed specifically for web programming but not proprietary like Microsoft. Disadvantage - it's rarely used by anyone outside of Web programming, so it's hard to find PHP software libraries or example code to do anything not commonly done on a web server.
Python: Some would argue, one of the nicest languages for rapid prototyping, but scales quite well to large applications. Disadvantage - smaller pool of experienced developers, plus unique syntax that some people don't like.
Java: Very large pool of knowledgeable developers, powerful class libraries, and better performance than scripting languages. Disadvantage - very verbose syntax; it often takes a lot more code to accomplish something than any of the scripting languages (above).
C: No good reason to use C to develop the whole backend. Use C to implement a few extensions where performance is critical, and use a higher-level language to implement the rest.
C++: Advantage - Huge developer pool, great performance, a little less verbose than Java, and lots of free software to re-use. Disadvantage - you have to compile your code before running it, you worry about memory management and buffer overflows, and in general it's not as nimble as scripting languages.
Don't forget Yahoo!, which swears by PHP.
What kind of app are you building?
fsck -u
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...
AJAX != Java, ass faggot!
I'm currently developing an web application using Java as the core language. I've decided upon JavaServer Faces (JSF) as the view, the Spring Framework (with Acegi Security) for the application layer, and Hibernate (and Lucene) for the database abstraction layer. That's combined with a number of smaller frameworks, like SiteMesh, to fill in any gaps.
I made the choice because there is significant community knowledge and support, as well as an abundance of open source projects. My entire application stack is open source, which greatly reduces my costs. They are also mature and quite robust, with the benefit of not being stale yet (e.g. Struts). I'm pretty happy with my choice, but there are many alternatives and you have to do a cost/benefit analysis based on your background and situation.
The only way to hire a good architect is by poaching. We had a tester on our team, and he was lazy, clueless motherfucker. He left the company and joined a startup which his drinking buddies founded. Guess what's his title now? Yup, he's a Software Architect, no less.
If you want to hire one of those smooth-talking fellows, go ahead do it. I wouldn't hire an architect if I was starting a company. I'd hire a few good developers and then see which one of them is the best (as in "writes the best code") and promote him to an architect.
Amazon.com has it right... mod_perl + HTML::Mason are a very, very potent combination.
your mom is a good choice when i want to do something large-scale
sorry, couldnt resist!
Lately I use Javascript on the front-end as well as the back-end, and with each passing day my skills grow stronger with the language. I've been programming for 25 years and using Javascript for about 7 of those.
;)
You don't need 5 different languages to get a job done, thats insane, and nobody could ever really master any of them that way.
The javascript functions I write can be used on the front-end or the back-end, and that not only saves me a huge amount of time and effort, it also makes it very easy to port to any platform. Hell, i can even run it on my cellphone.
Using 5 languages for one job is of no use to me. Even having to use two seems burdensome. I've used many other languages in the past, but now i'm pretty much set with Javascript for web development projects.
For anything else, Assembly Language is a good choice
Money. How much is the customer willing to play? Screw the other bits. I like C++, but it is hard to find a lot of gigs out there doing it. PHP is common, but folks don't pay much for the code. Java - now there are folks who have fat wallets and easily seduced by shiny things. C#/ VB.NET/ASP.NET is somewhat in demand, but I've got the feeling it is going to end up 'priced' like it is easy.
+++ UGUCAUCGUAUUUCU
"C/C++" is not a language. C is a language. C++ is a language. Each have various versions and implementations, with various quirks.
There is no "C/C++".
Meaning do not forget what happens once it goes into production. Are the people who can troublshoot, maintain or update your app and source code redily available? Personally, this narrows it down to codes and applications using standard app servers like Java and ASP. Being able to hire most any java web developer to maintain your code, for example, is a good thing. Coding it in a language like C++ that many people know, but few know well, would nto be my prime choice.
So I put to you to be part of your decision, think down the road a year or 2, when new features need to be rolled out or there are bugs and perhaps your contractors are gone and/or not available.
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
I can say that application are made from peaple. I thing that large entrprises like Google, Microsoft or Apple can pay good programmerus with strong knoweledge, thus they use whatever tecnology they want. .net or whatever alese, if your are you'll miss even if you use the best techno in the world!
The point is very simple: if your are good you'll success with php, java,
Just an advice: if you plan a project, don't choose the technology first, choose the peaple! If you choose right they will know what to do, if not...
I'am shure that apps like Google, or AppleStore can be done pretty the same way with other technologies if you choose the right peaple.
Dual0
Damiano Vedova
http://dual0.mine.nu/
while I would go PHP with confidence, read mysql dox before putting a real big (large scale) application on mysql.
.....
....) by the way ehre is the freebsd port .....
While mysql can be pretty nice, it has issues with
one thing i really needed in a project:
Full text indexing.... this is only supported in myisam tables, however i would not suggest using myisam tables for anything large scale if you have lots of deletes and create "holes" in your tables because of the aggressive locking (locks whole table including selects)...
just a warning, i might also be wrong, i just found out some weird things while working with a database of 3-4 million records stuffed with varchar 255 and text fields and some updates locked my DB for 3-4 hours....
and again i never used myisam on that big full text indexed tables before, so if you know better just ignore this
also you can get an oracle personal for a $500 or so, (it needs more machine too and limits you L into redhat/suse unless you want lots of hacking during installation on other distros
I'm sure that this will get drowned out by people yelling the name of their favorite language without explaining why it might be good to solve your paticular problem, but you might look at asp.net. You can use any dot net language to build the asp pages, so the actual language that you pick is sort of moot, but IIS has some interesting features designed to make building a scalable web farm simple. That was one of your major criteria, right? Be sure to look up what Apache has to offer there too, since it is as much a part of PHP as asp is connected with dot net.
Personally, I find asp.net to be a mixed bag. It's pretty good, but there are still a lot of things that could be improved on.
HA! I just wasted some of your bandwidth with a frivolous sig!
Definately.
If you've worked on a large scale app, you'd know what I mean.
Lisp is the answer. Paul Graham explains it at http://paulgraham.com/icad.html .
http://naeblis.cx/rtomayko/2005/05/28/ibm-poop-hea ds
And then start on something with a LAMP setup
For a complex app with lot's of business logic, I'd use Java and the related frameworks. Unless my team had a lot of Windows developers than I'd use .NET (shudder :-).
For a dynamic app with many users probably php.
For something simple with a big bunch of users, probably python or C/C++.
Again it would really depend ...
What's going to be the big cost? What kind of thing is this "web app" doing? Does it involve a lot of CPU activity? Once you get the thing developed, how much will it change? These factors matter enormously, because different languages have different strengths and weaknesses. Consider, for instance, just two languages: C and Perl. C, competently used, will be able to squeeze more performance, in some cases quite a lot more, out of the hardware, but you're going to spend 10+ times as many developer hours on everything, because there's no CPAN, no taint checking, no CPAN, no testing framework, no CPAN, no highlevel data structures, and no CPAN. You really need to evaluate how your costs are going to break down and where you need to save and where you can afford to spend, to come out ahead overall.
Every language has its own strengths and weaknesses. Is everything going to be on the web, or are you going to want to branch out to the desktop GUI? In the latter case, should you be looking into a language with good GUI tools, such as Java? Perhaps the problem you are wanting to solve lends itself particularly well to a fully object-oriented approach, and you'd like to consider Python. Or maybe 80% of your application is text processing and interfacing with a database? Perl is really good for those things.
Do you see the problem? The description you gave, "Large-Scale Web Apps", tells us almost nothing. We're answering out of complete ignorance, taking shots in the dark, telling you... whatever pops into our heads (Perl pops into my head for most things...), but our answers are basically useless to you, because they don't have anything to do specifically with what you're doing.
Cut that out, or I will ship you to Norilsk in a box.
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.
Here is a brief overview of what we do here:
We use what we call web-terminals and app-servers. Web-terminals run web servers ( Apache and Zeus, currently ).
App-servers run our custom-built application servers. Those servers host modules. The modules are writen in C/C++. They export methods and events, which are made available through the AppServer via a, what we call, 'binary XML-RPC' interface, as well as plain XML-RPC. Each module provides functionality for a single service, for instance 'search' or 'membership' or whatever. Each App-Server usually hosts over a dozen modules. The modules are implemented as DSOs/DLLs, and (Re)loaded dynamically.
The AppServers offer a lot more : sessions, 'virtual clusters' ( where app servers can talk to each other ), caching and so on, so forth.
We use PHP for the frontend. For interfacing with the App servers we use a PHP 'module' which takes care of invoking methods on the app servers, retrieving results and other related operations.
There is a load balancer ( custom made, which is actually used for managing all our services ) which also manages our Web Cluster. It also manages the 'AppServers cluster'.
So, we have X web terminals and N app-server nodes. Here is what happens when an HTTP request hits our LoadBalancer
1. HTTP-REQUEST reaches Load Balancer
2. Load balancer determines which web-terminal is least busy
3. The least busy web-terminal receives the HTTP request.
4. The PHP script responsible for rendering the page talks to the app-servers cluster by connecting to a node ( via connecting to the Load Balancer which in-turn picks the least busy app-server node ) and invokes methods, which return results, and then it simply renders whatever based on the results set.
5. The load balancer sends the HTTP response to the user.
There is no practical limit to the scalability of the system. Whenever we need more power, we simply add new web-terminals or new app-server nodes.
Our company runs the second most visited site in Greece ( pathfinder.gr ). We decided to go for this architecture after having tried many other 'popular' models. This solution is almost perfect, for us. We get complete power ( C/C++ for the modules ), allow the web-designers/developers to do whatever they want extremely easily and transparently by using a very simple PHP API for invoking methods, there are zero scalability issues, and we can isolate our backend from 'newbie' developers since they can only access it through methods on modules ( coded by our 'experienced' developers ).
Last but not least: the web-developers can use PHP, C/C++, Java, Python, Ruby and whatever else they wish to use for building web-applications, because all they need is an API for communicating with the AppServers cluster.
There is lot more to it, but thats what we do, more or less. We couldn't have been more happy with it.
Technology ramblings : Simple is Beautiful
Your guess is right: it's Javascript!
framework which supports powerful patterns, and have nice toolset with it is very crucial for choosing a certain language. PHP, java, perl, python has lots of good frameworks and new kid on the block is a ruby framework rubyonrails (http://www.rubyonrails.com/ you should certainly check it out.
Any programming can do their good! Of course with well managed server (and sane administrators) and other supportive applications. If you're one of the world's top 10 programmers but your code for 50,000 customers will be running on a crumpy box of Pentium III server (can be found anywhere in my country) your program will definitely mean nothing!
But this is not a web application, it is a simple application that could have been a command line program.
For a scalable robust web application, you need the ability to deploy and undeploy portions. You need to be able to share objects around each webapp instance and you need a database abstraction/cache. You need a robust operating system which behaves. You need robust server hardware.
For me the language portion is Java, Linux and pre-built x86 servers. Java with libraries, java with a nice J2EE container. It is all there to pick up and use.
JBoss
Eclipse
Hibernate
C3P0
Tomcat
Some MVC framework like struts, you choose.
Then you'll need squid upfront and probably balance, an open source load balancer. This means you can bring up a new version of your app and switch it over. You'll also need Postgres.
The one thing you'll notice is that you needed to bring a lot of NON JAVA things in to fit the picture, and that is how it should be.
postgres, linux kernel, linux threading libraries, linux socket libraries, squid, balance and probably ssh, tar -jc, tail -f /var/log/messages, qmail and everything else are C,C++/ I don't care.
[% slash_sig_val.text %]
Mason is a set of HTTP extensions for Perl. It's what I use at work to develop front end systems at Amazon.com.
I'm not really a fan of it, but it seems to work quite well for us.
I've used a lot of different things professionally but I consistently find that large projects go a lot smoother with Java. It's easier to find skilled developers, especially web developers.
The platform is effectively free (Tomcat, MySQL, Eclipse). I never have trouble finding JARs or examples of solutions to any and all common problems.
There's a wealth of work being done on high-level design and patterns (Struts, J2EE, personal info fave: The Server Side).
When you're trying to juggle a dozen coders: Java's OO roots, built-in documentation generation and relative ease-of-use all contribute to making things run smoothly.
And while a great development team is the best resource of all, the reality is you sometimes get stuck with un-experienced, un-talented and/or lazy programmers. If there's an easier language to teach, understand and use than Java, I haven't yet found it.
The meek shall inherit the earth, in 3 by 6 plots. - Lazerus Long
There is no language called C/C++ either.
+++
My new Home
We recently ported an app back end from EJB 2.1 to Spring plus Hibernate. I am incredibly impressed by the latter; this is the simple, efficient, well-architected ORM system Java has lacked for years. I'm still absorbing the beauty and power of inversion of control. And we haven't even begun to (directly) make use of Spring's AOP features.
I was beginning to have doubts about Java as a biz-dev language/platform. But Spring and Hibernate have made me a happy Java advocate again.
When all you have is a hammer, everything looks like a skull.
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.
English, possibly a choice of German/French/Spanish/Italian.
I've used 'em all.
Java is the answer if the site is reasonably large sized.
Scalability, maintainablity, 3rd party support out the wazoo, large pool of experienced developers, proven to work up through the largest applications in the world.
IMHO Python or Ruby are great for smaller sites. PHP is quite usable by novice programmers, but in my opinion is not really well structured enough to recommend to anyone.
Perl should be relegated back to where it belongs - parsing, system maintenance tools, etc. Although I find that nowadays I use Python for that because I hate Perl syntax (you call that a syntax?).
C# isn't a player for me - I refuse to bend my knee to Redmond. I have made a lot of money porting old VB code to Java because of scalability, lack or portability to C#, etc. and don't want to get trapped in that world.
C/C++ are for specialty applications like EBay that handle 4 billion transactions per day. Nobody else can afford/justify the longer development times associated with these languages.
First you say you like PHP because it focuses on one thing. Then you admit that it doesn't actually focus on one thing, it has a huge pile of random modules that when enabled clutter the global namespace with crap. Obviously the latter is true, so your first point is wrong.
And of course, PHP doesn't scale. And yes, it is because of the architecture that PHP forces you into. Being an apache module limits PHPs scalability. With perl or java or anything but PHP basically, you can write a fastcgi application or a servlet for an app server, which will keep your entire application persistant. PHP doesn't offer a way to do this, and if can be a huge problem.
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.
PHP is as interpretted as Java and C# are. It uses a 'Virtual Machine' just like they do and it can also be compiled as a binary before execution. So calling in interpretted while allowing Java and C# to be called compiled is a contradiction. Either they ALL are compiled or they ALL are interpretted.
They way C# handles compiling is NOTHING like how C++ handles compiling. To call both of them compiled does an injustice to the term.
This is my sig. There are many like it but this one is mine.
I almost always use javascript (ASP) on the server side. It's much more powerful than vbscript, allows me to write everything in the same language, and is somewhat portable, though the mod_js project seems to have been abandoned many years ago. Javascript gets bad reviews from people who barely know it and have seen ugly spaghetti scripts written by other people who barely know it. PHP is also fun, and I really like its string performance, object serialization, and vast selection of built in libraries for every conceivable need. It makes me wish my keyboard had a dedicated '$' key though. ASP.NET, whichever flavor you prefer, is very fast for serving complex pages, and probably very good for RAD-developed intranet apps where appearance and bandwidth are not important, but for normal web development I haven't been interested by any of its silver lining like
For normal websites that are database driven but where the data doesn't change much, I've been moving away from server side scripts except where absolutely needed, and writing site generator scripts instead whenever possible. The pages are served faster. The server scales better. They aren't penalized as dynamic by search engines. I can put as much processor time and memory as I want into generating them. And they're hacker proof. A lot of functionality like building up a shopping cart or customizing a product can be done better and faster on the client side and still work for 98% of visitors, with usable alternatives for the other 2%. If I want to port a website, I'll only have a few pages to rewrite.
With Java and Jython on the server side, you have many solid libraries and full scalability. By leveraging Java side, you will also have fantastic multi-threading support for large deployments.
By using Python as probably your templating layer on the server, you could easily utilize JSON to transport data from your JavaScript application on the client and the server. The nice thing about Python and JavaScript is that they both natively interpret JSON which will allow for more compact data transport and rapid interpretation. Throw in JSO/XML-RPC and you will have some really sweet UI's for your users (ie google maps).
I know quite a few languages, and I write web apps for a living. I love them all, and don't think I'm going to tell you anything is 'dying' here... but here we go:
PHP 4.3 - Works well for small projects because you can pump scripts out REALLY FAST. However, if you want to make something big and complicated, you have to REALLY know how to hack around the language. Has FANTASTIC documentation and a large community of developers making great extensions. PHP is the kind of langauge that you can be assured that your code won't have much of a problem getting setup wherever you take it.
However, PHP runs pitifully slow, is buggy, and brain dead design features such as magic-quotes, register-globals, object assignment copies instead of references (REALLY BAD), segfaults on stack overflows, inconsistent naming conventions (Ex: nl2br(htmlspecialchars(str_replace($x, $y, $z)))), etc. PHP is what I like to call a, "good enough" langauge and isn't a bad choice, just don't shoot yourself in the foot with the bad features.
(Off-topic: I pretty much think the only reason this language became so popular is because Perl was far too steeped in Unix culture for people who grew up on Windows and ASP costs money and was less availible)
JSP/Servlets - Difficult to setup, consumes a lot of memory, but runs faster than all the scripting languages. Unlike PHP, if you're distributing your code, your users won't be able to just throw it in a directory and have it work.
Because you're using Java, you get all it's plusses. For example, Java has a very, "there is only one way to do it" philosophy, making it great for a large team of developers and future developers. Definately the best for scalability, speed, and complicated applications.
Perl: Like PHP, this is also widely supported. The catch is Perl isn't a friendly language to Windows culture and is losing popularity. It has great documentation, but people these days just can't seem to figure out man pages. Perl is also quite fast relative to PHP. Perl doesn't scale well because it's not intended for large-scale OOP development. Perl's "there is more than one way to do it" philosophy is not great for a large team of developers, because the last thing you need is individuality in a corporate team setting (must... not... betray... hacker values...) But for small to medium applications, it's a solid choice.
C/C++ - Development time and bug-fixing time is VERY HIGH compared to Java/Perl/PHP. C is really only appropriately used for writing speed-critical functions that you can link in to your scripts. C++ is a tolerable choice for writing the bulk of the application.
Then answer to the original ask slashdot is, of course, LISP.
It's written "Lisp" these days, and yes, it could well be a suitable answer for the original ask slashdot question. Common Lisp has quite a decent set of Lisp-based web libraries, servers in lisp, and app. frameworks. e.g. Get Uncommon Web here - Watch the Video!
However, PHP runs pitifully slow
I've not found that to be the case at all, in fact, if you are running PHP as an apache module with a bytecode cache and optimiser (like the free eAccelerator for instance) PHP positively flies.
I am NaN
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.
There is no objective evidence that OOP is better for web apps; Only anecdotes from overcharging zealots. Yeah, go ahead and mod me down, I am just the Anonymous Messager of Truth. Prove me wrong with evidence, not modding if you have any balls.
Unlike a lot of folks here I've used all these languages for web dev.
In order from "fastest" to "slowest", my experience shows:
Perl (mod_perl), Python (mod_python), PHP, Ruby
In order from "most productive" to "least productive":
Ruby (BY FAR), Python, Perl, PHP
So you should pick your sweet spot. It's usually cheaper to buy machines rather than talented programmers, so I personally stick with Ruby whenever possible.
However I have a very high performance app written in mod_perl which gets hundreds of hits per second on a single slow one-process box, MySQL included, I'm pretty proud of it. You can do a lot of cool stuff with mod_perl although it's painful to code in Perl.
As soon as Ruby gets a real VM, it will kick so much ass! But until then you gotta make the trade-offs.
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
Smart, well thought out design is more important than the language you use, just pick one from the list of languages that will offer you most of the features you need and get thinking.
Wikipedia is powered by PHP and, although can be slow at times, makes good use of PHP bytecode caching and, probably, HTTP caching as well. Caching isn't a silver bullet but for web overheads and interpreted languages it is a pretty magical thing.
You haven't said what type of web application you are building, like so many Ask Slashdot questions there isn't really anything specific enough in your submission to offer decent guidance.
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.
The title was supposed to be "Smarts > Language", pray tell me why Slashcode doesn't encode html entities.
If it were a PHP application I suppose it'd be doing "$subject = htmlentities($subject);"
CafeSpot is a pretty fancy Web 2.0 type app and uses Common Lisp along with a bunch of CL libraries.
There are advs and disadvs for every language. But my choice of language is ColdFusion. Very simple to learn for programmers new to a project. One can use the OO standards or Modular standards, or a combination of both to help organize the code for scalability. My favorite features of it is that you can easily and I mean easily integrate Java Objects or C++ with it, it has an almost flat learning curve, and it takes fractions to code in cfml over some of the other server-side languages. Other cool features include Flash forms to have a more Rich Internet App feel. There are also tones of free API's, functions, modules,... out there to use. Our team uses Dreamweaver and CFEclipse to make life even more easier. And we also coding using the model-view-controller structure, and it works great with CF. Now, off course I'm biased towards CF, that's b/c I use it every day! But I'm still willing to mention the bad things about using it. It's not free :( there I said it. But if you're talking about large scale apps, the cost is relatively nothing. Something that's questionable about CF is its future. It has come a long way and it now kicks ass and there's lots of potential. But a lot of ppl are a bit worried about its future since Adobe bought Macromedia. But, Hey!! It's not going anywhere, it's only gonna get better.
CFML integrates very well with Flash and web services. And on a side note, if you have the money Macromedia's Flex is a pretty cool tool as well for building Rich Internet Apps.
there's my 2 cents!!
The tools for working in java are also a step ahead of anything else right now (idea and even its slightly retarded younger brother eclipse are both way ahead of the tools for any other language).
With all due respect this is simply not true IMO. Allthough I have never worked with Idea for a prolonged period of time it did in deed seem like a verry good IDE. But the latest (stable)version of Eclipse is not as good as Idea or even Visual Studio 2003. Now I don't know how asp performs on large sites because I have never worked with it on large sites. But as an IDE Visual studio i really find Visual studio to be better than Eclipse.
Idea on the other hand is IMO at least as good as visual studio. (and maybe even better but once again i don't have nearly as much experience with it as I have with eclipse and VS).
I know this is all MY oppinion and peaplo will certainly bash me fo using VS but I like it and claiming Eclipse is 'a steap ahead' is simply not true. (allthough Idea most likely is a steap ahead)
I could have sworn that Yahoo with its PHP, google with its C/C++ were considered much bigger than any enterprise site, which shows how to really scale a site at a much lower cost.
I prefer the "u" in honour as it seems to be missing these days.
Why not PHP with Cake? Basically, an MVC based approach to PHP, plus all the goodies of a clean, rapid app development library.
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.
I have to confess that I haven't yet done/compleated any large scale web-application. Actually I'm developing now one, a data analyzing tool for enteprises, with my friends (a start-up building up). The application communicates with many systems and involves some complex calculations to archieve it's goals. Thought it's not as complex or large as Google, in my mind and experience it's definately larger than your average web-project.
The reasons why I use and would recommend using Java to develop web-applications are that
- there are large commercial entities taking care of Java (with IBM and Sun, Java won't be disapering)
These are just some of the reasons why I use and would recommend Java for developing web and enterprise applications. Personally I like Java as a language because it gives enough freedom to express fairly complex datastructures with ease and has a very readable syntax. Of course sometimes Java can be very brain dead, but that is the price you have to pay. There isn't any perfect language, and Java isn't even close, but it's enough to get the job done, and in the end of the day that is what counts.Survey research tool for commercial and scientific use
- Valid point, methinks.
Java compiles byte codes and is deployed as byte codes, PHP is deployed as a script and C/C++ can only be deployed as a program to the webserver. From a developers point of view PHP is probably much easier than C/C++ in the develop-test-debug cycle. That is why I chose to name PHP interpreted.
While I agree that C# compilation and C++ compilation are completely different, I state in my posting that Java and C# are in-between compiled languages like C/C++ and interpreted languages like PHP. My original posting is therefore correct and we are in agreement on the issue of their compilation.
Actually, you can do some fun stuff with Domino as you can program your WebApps in Java, using either Servlets or even Domino Agents that use the Domino-Java-API (careful with that..).
.
I did the Java part for some quite big applications that were part Notes, part Java; example:
for a big company - already using tons of Notes - we designed the Intranet, associated with a CMS and some workflow managment
(for example: page changes or publishing of some reports had to be approved or edited by the right persons before going online etc.)
So all the data input was done in Notes (personal data, product info, reports,..whatever; even the template for the Webpages could be modified there, complete with an inclusion concept),
dito of course the workflow stuff.
The webapp for searching, displaying etc was done with Servlets that used not only the template blocks (edited in Notes) to create web pages according to preferences (edited in Notes);
also, for some sensitive parts you could easily fall back to the already existing Domino users (>20000) and ACLs to restrict the access.
P.S. Yes, Domino/Notes sucks (don't get me started on the memory issues in the Java/Corba-API..); but it sucks with some powerful possibilites..;-)
This is the pattern that I have used for a couple of quite substantial applications:
1. PostgreSQL database. Don't try to get too clever with programing in SQL; a few triggers and views work, but if you find yourself writing pages of plpgsql, think again.
2. C++ for the logic in the middle. How much of this there is depends on your application. Find or write some good generic interfaces to the adjacent layers. Don't be scared of STL and "fancy" object oriented stuff. A smart algorithm here is what makes "wow" stuff possible.
3. XSLT to generate the HTML. Hmm, well, this is possibly the bit I'm least happy with at the moment. It is certainly preferable to doing it long-hand. As with SQL, I think that the danger is trying to do too much in this layer. Push anything algorithmic back into the middle bit. Worry about the size of any intermediate in-memory XML documents.
4. Javascript for anything client-side. Use a library like Sarissa or IE7.js to help multiplatform support.
Run it all on Linux with Apache2. Don't be afraid to write it as an Apache module, rather than a CGI, if you find that startup time is poor. Use apache modules like mod_disk_cache and mod_deflate. Make sure you generate appropriate cache-friendly headers.
Don't worry much about optimisation until you've benchmarked the system and found where the bottlenecks are. Consider memory capacity and I/O bottlenecks as well as processing time bottlenecks.
Good luck!
I'm starting to hear more and more about it lately...
"Thanks to the remote control I have the attention span of a gerbil."
It works for Microsoft. Let's face it, their chief asset is ubiquity, not quality.
If your comment title says 'Re: Foo', I'm not likely to read it.
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
Real programmers don't care.
Whatever language is eventually used is chosen is done so by a CSP with a weighting function.
ASP.net -- Some good ideas, but I like the OSS paradigm too much to go back to proprietary stuff.
perl, PHP -- Great for small to mid-range stuff. Both excel at library support. Perl with CPAN, PHP with the many built-in functions (yes, they're unorganized, get over it) and third-party modules available. But they don't naturally lend themselves to disciplined structure that a large app requires. I started to feel the stress at around 20k lines in my last web app.
I'm not sure I can put C and agile in the same sentence. Wow, I just did.
Java -- All around great once you get up to speed, but man do you have to learn a lot. If you're using a pretty standard "lightweight" stack, you might have to be intimately familiar with Hibernate, Spring, and Struts, all of which have a huge variety of configuration options, gotchas, etc. You try to simplify with AOP tools, and more gotchas. It feels like there's too much software to keep track of.
Ruby on Rails -- feels halfway between Java and PHP. You get the benefits of that huge Java stack, with more unity and cooperation (and all of the docs in the same place!). The language is very flexible. I'm definitely working it into my smaller web projects, and every time it works, then I feel comfortable using it on a bit larger project. Once I got past the gotchas, I became about 50-100% more productive than with PHP.
Downside to Rails is the lack of thrid-party libraries, when compared to perl, PHP, or Java. And since we're talking about large projects, its unproven when it comes to scaling. DHH argues that it's boring to scale with rails.
I have a large web project coming up, and at this point I intend to use Rails for it. I'm going to have to drop out into C, or maybe use web-services RPCs for some of the heavy stuff (notably PDF generation). But I anticipate that the productivity will outweigh the cons.
Legacy, whether a company is a *NIX shop or an MS shop. In my experience whether you can walk on water or not, generally has mattered little. Go into an MS shop strutting your *NIX stuff and you're likely to be disliked and labeled as an "icehole" or "arrogant" and everything else. Go to a *NIX shop with MS preaching and you're likely to be seen as a lover of everything "evil" there is about Microsoft.
Frankly, all these arguments are childish... it's about business folks... something I've said time and time again. Yeah, Google uses LINUX and Yahoo! uses FreeBSD... but outside of all the technical arguments for why they use it, the fact that they don't have to pay any company for an OS license every time they setup a server is a big deal.
It's about business, simple as that, pure technical arguments rarely win.
-M
I've been hearing a LOT about this lately. What do Slashdoters think?
-- -- Tom Mornini
Nowadays, there are plenty of frameworks to create webapps, choose the one you think have all you need,
... "for work I use Java". And the forum would be pro OSS or pro Perl etc....
Most frameworks have one primary language used to extend the framework
That what makes the language relevant in your choice, if you will be working on the site yourself, choose the framework with the language you know best, else choose a framework that is exensible using the so called commercial languages, Java or C#; to make it easy to find programmers.
I can't count the time where I've on programming forums, think like
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
PHP is as interpretted as Java and C# are. It uses a 'Virtual Machine' just like they do
Wrong. PHP is interpreted. Java is partially compiled. It may seem a small difference, but it's big difference in performance. With PHP files, the file is interpreted from scratch, every time, including syntax checks, etc. With Java files, part of this is done the first time the file is run, then never again unless the file changes.
I recommend Esperanto...
and I say there is more than one way to do it.
If your building from the ground up you should stick to one technology, and one only. It's more scalable in the long run, even if you'll have to write stuff the plattform hasn't got yet.
These comply to what you need:
Java
Python
PHP
PHP is the most advanced SSI solution in existance, but can suck for larger specific apps. PHP 5 has changed that, but you still want to keep this problem in mind.
Java has something like 10 Million webappserverwhatnot solutions available - check apache to see what I mean - but has one downside: It's not pure OSS. And this IS a downside if you're into large scale custom developement.
Python has Zope, which is something like 5 years ahead of any other web application server/database out there. It's object database is a slowpoke by relational standards, but loadbalancing with Zope Farms is a piece of cake. And the ease of developement and the absence of ancient SQL crap make data drive development a trip to the theme park. You definitely want to check this out.
I'd recommend Python/Zope based on what you said, but of course you'll have to look into the details.
We suffer more in our imagination than in reality. - Seneca
Cuttently using Java, JSP on the front end and Middleware being Spring/JDBC. Hibernate can't handle the query's we're going to have to write.
In the past I've done ASP VB/JavaScript, and TCL. I help other out with they're PHP stuff.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
I've used the same approach, albeit with a Ruby backend:
PostgreSQL <-> Ruby <--SOAP--> PHP
PHP is a reasonable templating language, which is really what it should have been all along. The business logic goes into something saner and more maintainable, and everyone's happy.
Don't get me started on the problems of SOAP interoperability, however. Each implementation has its own quirks and foibles. I'd have chosen XML-RPC, but my boss was enamoured with the SOAP buzz....
If your comment title says 'Re: Foo', I'm not likely to read it.
Bah! I tried the original Java back in nineteen-ninety-whatever. It sucked then, and I haven't been back since. (Yes, I know it's improved since, but that initial exposure prompted me to take my focus in other directions.)
Ruby, on the other hand, is a lovely language, although the speed issue has caught me out a couple of times.
If your comment title says 'Re: Foo', I'm not likely to read it.
With confidence I can say that C++ is the best choice of a language for developing large-scale applications. As any experienced developer know there are numerous reasons: portability, scalability, performance, etc. etc.
I've had a lot of success over the last 3 years developing in Visual FoxPro and West Wind Web Connection. I've created large web apps for everyone from Real Estate to Medical Clinics to Publishing. It allows me to have multiple apps running on the same server and scales very well. I've used my share of php/mysql, but this has been my dominate language for the last year or so.
History does not long entrust the care of freedom to the weak or the timid. ~Dwight D. Eisenhower
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 are right, but _NOT_ the queries you used, before submitting links atleast check your results...
o m+filetype%3Aasp&hl=en&lr=&as_qdr=all 1,050,000 Matches
o m+filetype%3Aaspx&hl=en&lr=&as_qdr=all 793,000 Matches
ASP http://www.google.com/search?q=site%3Amicrosoft.c
ASPX http://www.google.com/search?q=site%3Amicrosoft.c
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.
Interesting that nobody has mentioned Pike. It's a very nice interpreted OO-language with C-like syntax. Here are some apps developed with Pike, including the Roxen WebServer.
To steal my idea you'd have to make me forget it. Otherwise you'd just be copying it.
Read On!
_ scalability.html
http://www.onjava.com/pub/a/onjava/2003/10/15/php
As far as scaleing CF runs the number 5 site on the internet MYSPACE.COM. CF is very fast for development. It currently runs on CF 5 and is moving over to New Atlanta's Bluedragon .Net implemtation of CFML. On the question of CF's future I don't see that as an issue there are now 3+ other implementations of CFML by other companys. 2 in full release Coral and BlueDragon. Coral is a desktop implementation and BlueDragon is a full J2EE and .NET implemtation of CFML. It is the fastest and easyest language to build and consume web services. And easyest for publishing content to the web. If you need heavy lifting that you want more speed you can develop directly in java or .NET or C or C++ and make calls to that from CF.
Almost all my home programs are written in Perl or C++. Perl gives me great tools to write quick programs on web or the CLI. C++ gives me sheer speed and control.
One of these days I'm going to learn how to make web pages with C++. Though I have a feeling I'm better off sticking with Perl.
Speed wise, isn't Perl one of the fastest script languages? (vs PHP, etc)
"That's so plausible, I can't believe it!" - Leela
Back in the 1990s that was probably true - programmers worked in OECD countries and made good money.
Now, programmers work in India and China and think themselves lucky to get 20 yuan a day (in China). The cost of programmer time is no longer important. Marketing costs much more.
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
The language you use for development isn't so important as the database you use and project's architecture.
In general, the most flexible architecture is lots of small modules that interact with the database. These modules may initially be written in one language but over time may be rewritten in various languages, depending upon performance requirements and the evolving skillset of the staff.
Pay careful attention to what functionality you can put into the database's stored procedures. Stored procedures can provide a standardized and simplified interface to access the content of the database and solve some of the performance issues.
Concentrate the complexity of the design in the database as much as possible. Document the interface well. Then chose whatever development language the staff is comfortable with.
I get paid to program Java. .jsp or .do that indicates it's a Java site.
Sometimes for the web.
But whenever I see a popular site with incredibly slow response times (early Friendster, several inranets) there's a 3/4 chance that I'll look up to the URL and see a
And PHP is showing up more and more often...when I looked at it in 1992 it seemed definately not ready for prime time, bug-wise, and even weird conceptual stuff like having to reset an array to walk it twice, but now it seems to be making huge strides. I prefer Perl, but there is something neat in how all the libraries are RIGHT FRICKIN' THERE with PHP.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
for everything. Fast and reliable.
I see suggestions to use Java but I'd be hard pressed to come up with an example of a large scale web site that uses Java. Perl and PHP are all over the web. Amazon, Yahoo, Sportline - sites that get serious traffic.
Heard and knew that Gmail uses a lot of JavaScript and XMLHTTPRequest (the so called "AJAX" thing). But the underlying codes are in Java or it's running on a Java platform is unheard of...
Somebody please advise...
And here is my take on it...
Most of the well known languages, if not all, have proven themselves as enterprise ready, because they are used in enterprise level applications. These languages can be used efficiently and cleanly, and applications can be built with them that are scalable, portable, maintainable, ect.
There is no "best" language. Everyone will come up with valid arguements to support their personal preference. This is like argueing whats better, a Lambourhini Diablo or a Ferrari F50. The dragsters will tell you the F50 because it has faster acceleration, the racers will tell you the Diablo because it is faster. So which one is the better car?
This question is a failure. It has been asked so many times and there never has been a clear answer, though I'm sure many will respond to this with a "THERE IS A CLEAR ANSWER YOU IDIOT, USE [insert language here] BECAUSE [insert reasons here]". Meh...
I'm god, but it's a bit of a drag really...
You forgot Poland!
I find that using multiple languages helps enforce the n-tiered architecture. One architecture I like is to wrap an Oracle Database in a layer of PL/SQL objects, then to generate the web pages with PHP or Java. PL/SQL seems optimized for scribing business rules. PHP is optimized for generating web pages. Using two languages seems natural.
Having two languages involved forces a cleaner separation of the layers.
In the real world, we often end up interfacing with applications written in a wide variety of languages. Designing web applications with a variety of languages makes the system more robust.
Read AOL's documentation for their opensource AOL server. Yes, AOL, the big company.
Wrong. PHP has the ability to be compiled prior to launch. You have the OPTION to compile before it is interpreted or not. Most people just use the default which happens to be interpretted but saying that PHP does not have this ability is incorrect.
This is my sig. There are many like it but this one is mine.
What do Ebay, Google (let's insert Amazon in there too) and Microsoft's web sites actually use?
(I don't know.. I'm just asking...)
I thought eBay used Java, no?
? q=&url=technorati.com? q=&url=indeed.com
Technorati uses Java and is pretty big [1].
Simpy [2] uses Java.
Indeed [3] uses Java.
All 3 use Lucene [4] (Java search engine)
[1] http://www.alexa.com/data/details/traffic_details
[2] http://simpy.com/
[3] http://www.alexa.com/data/details/traffic_details
[4] http://lucene.apache.org/
Simpy
How can PHP be compiled? I have never seen this feature. It almost sounds like the PHP to C++ translation thing.
I'm god, but it's a bit of a drag really...
WebObjects (still) can't handle even medium stress without an insane amount of machines and machine power. Also, it is (again still) full of strange edge case bugs that pop up when you least want it. Apple can afford to run their stuff on it, because they can throw insane amounts of machines at it, and they have the source code so they can fix the bugs they encounter. No such luck for most of the rest of us.
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.
For small or medium applications, I'd use PHP. I find it more productive. For large applications I'd use Java, simply because it's more maintainable using design patterns. I suppose design patterns could be applied to any object oriented language but it's usually best to use a tried and true development technology.
caching
I do a fair amount of development, and I like using:
Apache
Jakarta Tomcat
JBoss
MySQL
I'd like to say I also use Linux, but my company doesn't care for it as much as Windows, so I'm usually stuck putting this stuff on Win2k3, which isn't really a bad option - Of the security holes in Windows, half are in IIS, half are in SQL Server. The other half are in the OS itself. (Gotta love Yogi!)
I don't like to do alot of client-side scripting in the web pages, but when I do, I stick to JavaScript and Applets. The nice thing about this setup is that you only need to learn 1 & 1/2 languages, (SQL counts as 1/2.) JBoss handles scalability with EJB's, and Tomcat handles the rest of your business logic.
It should also be noted that paying for some of the non-open alternatives to these platforms is just silly - Yeah, you can use WebSphere or WebLogic for your App. Server parts, but you're STILL using Tomcat, you're just not paying for it! Under the hood, they're both just using Tomcat, under the auspices of the Apache Software License. (More liberal than the GPL, the ASL permits you to rip off their code, and not even include the source, provided you just ADMIT to it!)
As for an IDE, I'm sorry I can't help you. I use emacs, (well, TextPad in MS Windows,) as my IDE. Frankly, IDE's are for p#$$!3$.
I'll have to disagree somewhat with this. Firstly, I have to take issue with the premise that because a language is well known, you can hire more competant people. For a competant programmer, the time needed to learn a new language is negligible. A competant python programmer, for instance, will be a competant java programmer.
The other difficulty I have with Java is the syntax. Java is a low level language, and thus generally unsuitable for tasks where a high level language can be used. Java's use of primatives and its reduced syntax are perfect for applications such as J2ME, but on more advanced architectures, this low level behavior becomes more of a hinderance than a benefit.
Now this I happen to agree with. Java has a lot of good tools, and most are very robust. I wouldn't really class them as a step ahead, as RoR seems a more efficient development environment, but Hibernate and Java servlets seem pretty good for designing large, complex systems.
If you combined these tools with Nice, I'd agree further. Nice is a high-level programming language that compiles into native Java bytecode. With Nice, one gets all the benefits of the Java library, along with the advantage of working in a strongly typed, high-level language with similar capabilities to Ruby or Smalltalk.
That all said, for the majority of web applications, RoR seems the better choice.
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.
Running your enterprise app on Tomcat is like building your house out of crepe paper. Sure it can be elegant but sooner or later the rain is gonna come.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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.
php can be cached into bytecode. very similar to jsp pages on a first run basis. there are a few op code caches available for php including one from zend (which costs money) and a few free ones such as mmcache (which we use at FotoFlix and it's great).
Better than Flickr - Manage, Share, Archive
Or what ever they use to program FPGAs...
Ok, weak joke I know.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
Not only does CFML streamline many of your common tasks in middleware/front end processing, but the runtime deploys as a J2EE application on any J2EE-certified application server. This means that you can write all of your backend processing in Java and use those Java classes directly in ColdFusion. I have experience with .Net, Java, and PHP and must say that you can get much more done much faster with ColdFusion.
Look into Smarty and other great PHP template engines. They make that separation for you.
Otherwise HEREDOC's help a lot in large blocks of easily updatable code.
-M
when you see the word 'Linux', drink!
[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.
The United Nations are moving to this...
spider
It's new, like PHP but based on Python, not a subset like Zope.
PEAR::DB encourages $db->quoteSmart(...) that will properly quote it with the database-specific escaping.
Plus teach a newbie to use sprintf when making their SQL and you'll find that it's a lot easier to remember that.
magic quotes should always be disabled. The language shouldn't make up for the lack of information the developer has.
-M
when you see the word 'Linux', drink!
Actually I can tell you that the major performance hit comes from the database, not from the Web Application itself.
Bad designed databases, and insanelly large queries can be quite a performance hit.
On our devellopment server, Java itself account only for 0% to 1% of processor usage, while database activity sometimes accounts for 99%! That's because there's a lot of legacy code there, and a lot of spaguetty SQL...
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
There are really only two choices. Erlang or lisp. For smaller projects, Smalltalk in the Seaside environment may be acceptable.
All three support the best time proven techniques, and have withstood the test of time.
Some people seem to like Ruby on Rails. I haven't tried it myself, but it looks acceptable.
I'm a loser baby, so why don't you kill me.
Probably more accurate to say "similar to ASP/VBScript". The Java HotSpot compilier is vastly more sophisticated than anything available for PHP.
Whenever I hear the word 'Innovation', I reach for my pistol.
Know any large scale apps done in Brainfuck?
I hear people saying all the time that they are not using J2EE when in fact what they mean is that they are not using the very bloated and usually difficult to develop (and slow) Enterprise JavaBean platform - EJB. When you are using the stack you mentioned you are using a very large part of J2EE - JDBC, JSP, and JNDI most likely. There is a whole suite of technologies that fall within J2EE - most are just fine, EJB being the primary exception.
Your characterization of asp.net is incorrect. The way it works is you write it as though it was ASP (like a script), but it gets compiled during runtime (the first time) and from then on runs as compiled code (you could also precompile everything beforehand as you mention). Now that MONO supports asp.net, seems that it is a good choice.
In any programming project the choice of language always becomes an issue. One choice is, for me, easy. I would never choose a language that in any way supports Microsoft. Period. That means no ASP, no C# or anything else that M$ may have up its sleeve, including M$ extensions to things that they have `embraced.'
It's the moral thing to do. Each time I choose Free Software, make Free Software or contribute to Free Software we all grow just a little bit more free.
I would have a look at the nice ideas behind Templeet http://templeet.org/ that make any dynamic website runs as fast as astatic one. Worth the headache of learning it and saves you money on hardware and development cost (quick and dirty but it works)
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.
Dynamic includes don't really substitute for COM or other objects, nor do they seem to be a very sound "large application" strategy, so I don't get your point.
I tend to do a lot of data driven programming, and dyanamic includes form a large part of my strategy for handling modularization of large PHP or Perl apps. This allows the application only to run the code it needs to for the action necessary, and to include an extensible set of possibilities without having to maintain separate decision trees.
You are right that they are not a substitute for COM. But in ASP apps, I would have to use COM as a substitute for dynamic includes.
Let me give you an example. Imagine if you could specify from the URL the type of interface you needed, the data entry screen required, etc. and have the application only execute the code necessary to build these. Dynamic includes make this sort of thing possible without sacrificing maintainability.
So for example... I can handle authentication and make sure that a user is authorized to access the application and then do something like:
include $config['callback_dir'] . "/$form.call.php";
Thereby processing the event buttons. As I add new data entry screens, I don't have to add new switching mechanisms. I could do this using COM and ASP, but I can't do it maintainably without COM.
Again in HERMES, there are several portions of the application which are separate and distinct from eachother, Dynamic includes are only necessary for two of them (i.e. the core application server and the UI engine). Revising my set of modular components, we have:
1) Core app server (dynamically includes appropriate UI engine).
2) UI engines (dynamically include UI and callback scripts)
3) UI scripts.
4) Callback scripts (paired with UI scripts).
5) Core data object model.
6) Utility/Library Object Model.
4, 5, and 6 are largely OO. 1 and 2 are pretty much procedural/data driven. 3 and 4 are lightweight automations of 4, 5, and 6 with some data driven aspects as well. Each UI script is paired with a callback. Also, note that the callback can change one variable which will determine which UI script will be called next.
The whole 20k-line app is such that someone with a one hr introduction to the source code can probably start programming quickly and be reasonably productive immediately.
I expect that when HERMES 1.0 is fully complete, it will be approximately 50k lines and still be as easy to maintain as it is today.
LedgerSMB: Open source Accounting/ERP
Okay, I know, but I just couldn're resist :-)
It's the most commonly-used language on the Net.
Bad puns gave me bad karma. =(
Nope... more similar to PHP...
.NET crowd -- you've finally caught up! Microsoft's use of the word "compiled" in regard to .NET is not what a C++ coder would call "compiled". Zend, the corporate face of the PHP project, have been doing this for a while now with PHP Accelerator (for a free equivalent, try php-accelerator.co.uk). Unfortunately for Zend, they chose to describe what Accelerator does as "advanced caching" (read more on what Zend means by "caching").
.NET is not compiled. You've only been fooled into believing Microsoft rhetoric and in comparison benchmarks by Oracle (not Zend or IBM), even PHP 4 is faster than ASP.NET.
:)
Here's news for the
So you see,
Do you ever get tired of being wrong? Because I sure as hell don't get tired of showing you how wrong you are. It's fun!
This is my sig. There are many like it but this one is mine.
Save tons of money by using Linux (or FreeBSD) Clusters (instead of Windows * Server or Sun Solaris).
.NET/MS-SQL platforms by using XML.
Save tons of money by using MySQL Clusters (instead of oracle or sql server).
Create scalable object oriented web interfaces with PHP5.
Make your web applications inter-operable with Java/Oracle and
Create Programs in C/PERL/Python that can be integrated into your web application.
Access TONS of free online resources for all of these technologies, including support from other developers via IRC.
Laugh at the rest of the comments below... =p
the only permanence in existence, is the impermanence of existence.
In a computing environment dominated by servers and networking equipment, I am a bit surprised that there isn't more of an effort to move back to machine level code to tweak that extra throughput out of the server.
To an extent, the driver for the higher levels of abstraction was to shield the programmer from the vagaries and peculiarities of individual machines. One could imagine this new world of big servers under the complete control of the programmer could reverse the historical trend to greater abstraction in code back to the machine level.
Perhaps the handling of millions of random events is better served at the abstract level.
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...
Perl is meant to minimize typing. It is neither easy to maintain or debug. While it may be possible to write code with perl which is easy to maintain or debug, no perl coders will do it because then they might as well use another langauge. Poor coding practices are encouraged from the top down. Look at CPAN. Some of its modules are composed of a single 3000 line nested regular expression.
Your use of terminology is wrong. You may understand the concepts, but using words wrong just confuses people. Java is still considered an interpretted language even though it is compiled into byte code. It is run on a JIT compiler and suffers from many of the same overheads as a souce-code interpretter. The JVM is the Java interpretter.
r _software)
Read through Wikipedia on these subjects to get a better grasp of the terms: http://en.wikipedia.org/wiki/Interpreter_(compute
Well, I wouldn't expect a PHP programmer to understand that Java and .NET are two different things. So, I will attribute your reply to the intense gay lust you have for me and my super l33t programming sk1lz. (Cue "Can't Touch This" by MC Hammer.)
Whenever I hear the word 'Innovation', I reach for my pistol.
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
Ever heard of deprecation? You'd be surprised to know that it happens in ALOT of languages, databases and more. No matter what language you move to, this will happen. Even HTML has parts that have been marked as deprecated.
So please don't blame little ole PHP unless you are also going to blame practically every other language out there.
This is my sig. There are many like it but this one is mine.
Wow. Java and .NET are two different things? Alert the newspapers! How long did it take you to have this little brain fart of a realization? Major Duh award to you, my friend.
:)
Heh. Yep, all 13 year olds think they are s00p3r l337. Puberty gives them all huge egos and sparse crotch hair. Soon you'll be finding out that girls don't have cooties too.
This is my sig. There are many like it but this one is mine.
You forgot MSPX: http://www.google.com/search?q=site%3Amicrosoft.co m+filetype%3Amspx 938,000 matches.
Oh, wait...
Python and C (not C++) are the two that are required for someone to get a job with us. If they have actual assembler experience, they get priority, because I am confident that this makes for a much better C programmer. I have a short assembler test I abuse prospective employees with; it is designed to see if they understand how stacks work more than anything else, because that is the key to not screwing up a lot of C programming. If they can tell me how a basic microprocessor system works, as in the hardware design, then that gets them even more priority. Aside from that, pixels need to be their subservient little bitches.
I've fallen off your lawn, and I can't get up.
Photobucket.com uses php, and a little perl (but not for serving pages). Objectify your php so that things remain very maintainable, write your perl so that someone can read it. What it comes down to is the fact that bad code can be written in any language, and good code can be written in any language.
Oh, yes Large-Scale.
George II -- Spreading Freedom and American values, one bomb at a time.
And what does that have to do with how right I was and how wrong you were about C# not being compiled? Hmmm?
Ever notice how stupid people like yourself often like to open their uninformed mouths?
This is my sig. There are many like it but this one is mine.
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
A good worker knows that it's easier to repair something that has common parts. You don't switch between screws with different heads, just because one works slighlty better in a given situation.
-Don
Take a look and feel free: http://www.PieMenu.com
While your criticism of Perl is entirely valid, I think you're missing the main problem (such as it is) with readability in Lisp. In fact, the other example you gave, XML, suffers much the same problem.
In neither case is the problem the vast number of () or <> pairs you've got in the code. That's tedious and doesn't help readability, but it's not the end of the world.
Rather, the problem is that (up to a point), that is all you've got. Languages evolve syntactic sugar for a reason. Of course you can create a very pure, very small language without much syntax at all. Indeed, classical Lisp is about as pure and small as you can get. But in doing so, you force all concepts to be represented in the same uniform notation, even if that notation isn't necessarily the most natural or readable.
Lisp-like languages with more friendly syntax don't suffer the same problems here of course, but I suspect these are rarely what people are complaining about when they attack the readability of "Lisp".
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Ooh! Ooh! Can you give me a link to this fabulous optimising compiler then? Because gcc ain't it!
BTW it must support the proprietary instruction set architecture that our chip supplier invented.
On the large-scale web application my company has been working on for 3 years, we used Flash for the front end (Flex for some front end parts), and JBoss on the middle tier with EJBs and an Oracle database. A big, complex system with thousands of moving parts, so to speak..
#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.
I have heard a bit abut QUISP (Quick Server Pages). Does anyone have an opinion/information about it?
"Love is like a trampoline, first it's like "SWEET!!" then it's like *BLAMM!*"
Hotmail originally ran on (IIRC) FreeBSD & Apache. When Microsoft accquired them they started switching over to an Windows/IIS architecture in an eat-your-own-dog-food move. It took a long time to complete the transition (if they ever have) as they found that it took something like 3x as much hardware to handle the same load using Win[NT|2K].
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
I have used a hammer to drive a screw before. It works much better than you think it would. Not nearly as good as a screwdrive would do the job, but it gets the job done. It may hold better than a nail would (again, not as good as if you had done it right).
In short: you can use the wrong tool for the job, and it might work better than you would think. It is still the wrong tool for the job, so get the right tool if you can.
The X and Y registers on the 6502 were called index registers for a reason. Index X to A, and Y to B, and you can not do it in less lines.
My way is slower, but uses less bytes (I can't recall the syntax of 6502 asm, so I'm not going to write it). Since we are talking about a processor that could deal with more than 64K at a time this is a critical concern.
Well, it's hard not to start a flamewar with all of this, but here's my opinion on the matter.
Perl
Definitely not Java
Why Perl? HTML::Mason and mod_perl provide a great means of integration to the Apache web server. It has an extensive history and development effort in web applications with a very large set of libraries available.
Why not Java? There's a lot of stuff that Java can do that Perl can do. But there are two points that I think are important to consider when looking at making a real website. First Java is a fundamental memory hog in comparison to Perl. The really nasty experience that I've been having with Java is that a majority of the developers who you can hire cheap are very poorly experienced developers who really don't know how to do any serious design.
And now for my segue into why I would really not recommend Java and I would recommend Perl. The entrance barrier to Java is much lower than the entrance barrier to Perl mainly as the result of Java being pushed as a Corporate Standard. It's much easier for me to get a certificate in Java than I can a certificate in Perl. Similar in concept to the MCSE certs I can get as well. What do they really mean in the real world? That's for the developer to sell and you to buy.
These languages are rather close in performance capabilities, but the quality of developers you would find in Java I would expect to be lower than the quality of developers you would find with Perl experience.
Actually, odds are that hand written assembly will underperform compiled c these days. Hiring or training people that can write better assembler than a modern compiler is very very difficult.
Have you written much assembly? Modern assembly focuses a lot on memory access optimization (caching, etc), and parallel programming, and compilers tend to have trouble with that. On a webpage by Paul Hsieh you may find this quote:
Most assembly programmers are neither knowledgable or good, but those who are knowledgable and good have little trouble beating compilers.
http://www.azillionmonkeys.com/qed/optimize.html
Qxe4
esperanto....
eBay uses several languages. While C/C++ plays a large role, nearly all new development is in Java and there is still a good bit of Perl hanging around .
Language differences are about a lot more than just syntax. If all you want to do is crank out code without respect to whether or not it's implemented well in the chosen language (based on its own idiosynchrasies), then I suppose that learning the syntax alone might be enough. I dare say though, that most people will have a rough time becoming proficient using C++ templates after only two weeks, or settling on a reasonable memory management scheme after spending most of their time with Java.
I'd say that once you know the syntax, you've only mastered the least common denominator. Then you have to factor in the time required to master the language itself.
Right.. but you seem to be forgetting that Myspace.com is just a terrible mess.
"Progress comes from the intelligent use of experience."
T - 32 seconds before the flames start.
http://aolserver.com/
You should choose a platform rather than a language, such as .NET or J2EE.
PHP is a great small-to-medium project language, which is why it became so popuar. It was very easy to make a guestbook or send an email, and as the Teach Yourself PHP in 24 Hours "programmer" learned more, it had modules to do more. We use PHP and MySQL at work for intranet applications and I hate them.
RubyOnRails looks like a decent platform but I think the mass-hysteria buzz it is getting is what is pushing it more than anything.
AJAX anyone? Remote requests have been around forever but is now suddenly discovered since someone put a buzz term on it that gets the friendzy started.
Rails Day: http://railsday.com/blog/ 24 hours to come up with the best application? The winner is something I could have written in [insert language here] in 6 hours. Use ASP.NET, slap some validators on it and a few editable datagrids. Time? What, 2 hours? Use PHP and do it manually, OO or not. 10 hours?
Scripting languages are becoming very popular (PHP, Python, Ruby) on the Internet lately. They're easy to use but are per-request scripts, not a platform with caching, persistence, and other platform technologies. I din't mention Perl since it has been around forever.
Several reasons why this is a no brainer:
- Low cost. You can do all of them on open source platforms, no penalties. To scale java well, you often need third parties in the mix. ASP? Yea.
- Fast development. You can push out a webApp in much less time than you can in Java, or C++ no question about it.
- Scales (on the lower end) just as well, if not better than Java or C++, which requires a much higher investment (look how many shared hosting enviroments support Java well enough to actually use).
If you make it to being an amazon.com or an eBay, you can likely afford to re-engineer your app into something better. But if you spend to much on scaling at the start... you have nothing.
People forget that to have a successful business you need a business plan and the tech. Not just the tech.
That's what the dot com bubble was partly about. Lots of tech and jargon. But no business plans (except for a small few).
Think business plan
Example: Did a large chain like Subway, McDonalds, or Walmart start out with thousands of stores? Or build to that specification from day one? Or did they build a solid business first, then work on restructuring for that type of growth? Yea that's right. In fact, Sam Walton (Walmart founder) used to have a niche in a wall for each store he opened. That's how the accounting was done. Each store had a hole in the wall. That was the start of their accounting. Now they have a giant department, servers, computers, and certified accountants managing their accounts. But guess what. They didn't purchase that when he opened his first store.
Scalability only means something when you have a business plan
Not really. It's totally different from most other web development systems. First off it has an IDE!-)) And the architecture is both arcane and designed to tie you into Microsoft's toolkit forever. While any PHP or Perl developer will understand how ASP works, ASP.NET will require some retraining (blinding them in one eye, hobbling them and hitting them in the left hemisphere with a hammer will also help).
I meant what I said about Microsoft's squirrelly architecture and terminology: most Visual Studio.NET developers don't understand the WWW and the Internet at all, they drop and drag controls onto a form.
The "separation of code and content" that you speak of has always been optional. And in the latest release Microsoft has changed it so that the default is _mixed_ code and content. So you get some idea of how popular that was.
This isn't religion, this is a non-MS developer's view of MS technology. ASP.NET is a bad implementation of OOP and a bad WWW implementation. It will never supplant ASP.
ASP.NET is quietly dying. Do you think you can save it?
...another language-x-is-better-than-y holy war disguised as a thoughful, coherent discussion!
What are you doing now, you lazy drunken obscene unsayable son of an unnameable gipsy obscenity?
I always give the same answer to this question as I do to the question which OS is best. The one you know how to use! If you know ASP use it, if you know PHP use it. If you don't know one already and want to learn one then the next question to ask is what infrastructure are you going to be using. If you are going to be deploying your application into a Microsoft environment then use ASP.NET, if its Linux then PHP. Don't expect to start working for a corporation that is a Microsoft shop and have them install PHP on their web servers for you, it wont happen. My experience as a web developer for the last 6 years is that ASP and PHP are easy to learn but hard to master. Many of the projects I have worked on I have had to support code written by other developers and most of the difficulty in getting up to speed on a new project is understanding the mess created by the previous contractors. The problem is not the choice of language. If the original design was constructed well then the people who make modifications to the application generally follow the original framework and keep the project maintainable. When the original project was constructed by inexperienced developers who have no idea about good design or code reuse then each contractor who comes in just makes the project that bit more unmaintainable until the point where you get 5 year old applications that have reached that point where maintaining them is more expensive than starting again from scratch. The worst thing is when the project managers have no idea how bad the code they have is. Trying to convince project managers that scrapping what they have already spent hundreds of thousands of dollars on is hard for them to swallow. In the end a good web application development comes down to good design with well structured classes that encourage easy code reuse and maintainability. The language that is best suited to this is the one you know well. If you don't know the basic principles of object orientated design and code reuse then these are the things you are really in need of learning. You can only create a massively unmaintainable beast with whatever language you use without these skills! No matter how much you want to argue the merits of Java or .NET over ASP I would much rather maintain a well designed ASP application over a bug filled poorly designed Java app any day.
P.S. My recommendation to a newby looking to start developing web applications would be ASP.NET. I don't care what you anti MS zealots have to say about that, that is my opinion.
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.
Of course, they all write in Java, since they're paid by the number of Lines of Code (LOC) generated.
Myself, I'm a perl loyalist... what problems it has can largely be avoided if your programmers are any good, and it has in my opinion a spirit of cooperation going for it that most other languages can only hope for (it's *extrememly* difficult to think of an idea for some general purpose code that has been implemented on CPAN six times already).
But when you really come down to it, it just doesn't matter that much... the idea that you're going to win the battle by technical superiority is a standard sci-fi geek fantasy, but it just doesn't play out that way in the real world all that often.
I prefer ASP over ASP.NET
ASP.NET and its WebForms are abhorring - it doesn't comply to standards. Which means you have to go down the XML/XSLT route. Complexity then shoots up astronomically from there.
For *tiny* applications ASP is ideal, you can edit run-time.
For *big* applications you really can't use ASP unless you have your own dedicated server. Many separate logic from presentation by using Components, some even use WebClasses.
I suspect most huge website using ASP uses components and MTS.
I seriously wished I knew JSP.
It seems to be better than ASP / ASP.NET / PHP by many leaps and bounds.
ASP however, seems ideal for the quick website though, you can put something up (searches, email forms, etc) in a matter of minutes.
With just the differences between PHP 4 and 5 one could say these are two different languages--and I won't even go into previous versions. The change in OO features has been dramatic, I don't think you can debate that. While Java has also changed significantly over the years, entire basic syntactical structures have not received nearly as dramatic changes--I've mostly seen upheaval in libraries and additions to syntax, including evolution in the way design patterns have been approached as people have learned to use the core syntax of Java effectively. But I digress...
For this and this alone I will make the claim that Java is 'older,' whether or not this is absolutely true. It certainly is more mature, and does not suffer as dramatically as PHP from the "language by committee" problem.
Word.
I work for a large-scale ISP/Media/Publishing company and we just went through about 12 months trying to analyze this question. In the end, we resolved that no language stands out of the pack once you put them in a scale, heterogeneous, production environment, that connects to a wide variety of backend services. If your developer pool knows one language over another, you're likely better off just going with that lang. If you're C#'ing it, you're stuck w/ MSFT VMs and servers. If you're Java'ing it, you have to wade into all the different VM/app-server providers, though we concluded they're all the same over a six-month period; the engines themselves are commodities at this point.
Your point about the necessity of communicating precisely what is meant by using the correct terminology is well taken and I stand corrected. You however could benefit by including elements of civil discourse in your postings.
My final year undergrad project at University was to write a two-dimensional flight simulator (really only one dimension of control - pitch, the second is throttle) in Macromedia Director (using the inbuilt scripting language Lingo).
It was the pet of the head of the Aeronautical and Mechanical Engineering School, and I took over from a PHD student who had managed to mangle it pretty badly, and it was still not workable after two years.
The intent was to provide a learning tool for first and second year Aeronautical Engineering students to provide practical display of the theory being studied.
When I started reading the code, I quickly decided that the easiest way to refactor it was to nuke most of it and start again. The logic was very poorly presented, and poorly documented, but there were some inspired elements which were worth keeping.
Inside of six months, I had managed to deliver above and beyond what the School Head was expecting, and had a fully functional simulator, with some interesting additions. Unlike MS FS, which uses approximations and predetermined limits for a flight model (which doesn't really exist), the simulator used the base theoretical models as applied to a true NACA aerofoil. The difficulty was determining the lift curve when the aerofoil was travelling in a reverse flow (i.e. backwards), allowing demonstration of tail slides and horizontal aircraft movement when the aircraft is pointed straight up or down.
One of the best moments came early in testing when the model demonstrated a pilot induced oscillation recovery perfectly, telling me that the model worked. At the end of the project, even I was amazed that such a piece of crap as Director could be hammered into submission for such a project, but just because it can be done, doesn't always mean that it should.
InfoSec that matters, when it counts.
I've seen code that executes stuff on the command line, right from a GET string.
If there was a Darwin Award for programming...
Maybe like a "Bonehead Code Resulting in Job Loss" for people who (for the better) have been removed from the labour market for programmers. Kind of like a Black-List if you will.
I'd say this is the strongest case for such a title. Anyone else got any other nominees?
Good job on the moderation. Always nice to see pointless demonstrations of ignorance,
"As many as possible" => Not really.
... } main; exit; 1;" and document code with POD, divide things into modules and document any non-trivial regexp, like you would do in a sensible language. Then when the project is done do a code review, if people say:
.NET, ASP, ASP.NET, C# and similar IIS crapt... thanks to MSCE and MSDN Universal licenses...
.NET were "over budget, over 12 months late on their release date. At least one of them changed often their 'incompetent' MSCE employees... while the other seems to have perpetual MSCE job offers.
.NET manager, who fired the 5 out of 6 "Junior MSCE" and who was still looking for some "Senior MSCE"... [Another true story]
Use the best tool for the best job, it really comes down to what is the language that easily support the feature you may need.
If you use perl, then force everyone to
"use strict; use vars qw{GLOBAL_VARS}; sub main {
"I don't wanna do or care about a code review", they probably wrote some crappy code. You may want to use mod_perl for speed, just wrap your thing into modules and call the "main" loop.
Don't forget to free up any resource.
You may also want to use the Perl Template Toolkit, see the books by O'reilly.
"Use PHP for the front end",
PHP or Perl both are good and simple to maintain, *if* written properly. Any source code is hard to maintain especially if temp() and V was supposed to be called getInventoryStock() and StockEntryVector, respectively, but were not because the 'incompetent programmer' decided to use these since that part never worked and once it worked *by magic*, he didn't clean up the code...by fear that it will break again. [True story]
For one project we used both, since it was easier to create 3D pie chart on-the-fly in PHP then it was in Perl. So, Perl called PHP with a generated DB array... [Another true story]
There is a sample 3D pie chart tutorial here:
http://www.peters1.dk/webtools/php/lagkage.php?spr og=en
"Perl for input parsing," => Yes.
"Euphoria for the graphics," => Probably better off with Flash... or with Perl/GD, PHP/GD... depending how simple/complicated it is.
Next bet would be SVG, but it's not widespread enough yet.
"JavaScript on the client-side," => Yes, that was straight-forward, unless you think about IE-specific VBScript... which is a big no-no unless you work for Microsoft.
"Moo for the database" => PHP/PEAR or Perl/DBI or or Perl/Class-DBI or similar please. [Did you really ever use that?! or you simply search google for a weird technology to look cool?!]
"and Python for the glue to hold things together."
Perl is the mother of all glue language... for more than a decade, check CPAN.
[Personally, I find Perl more readable then Python, even cryptic Perl]
As for if you want true speed and write a GUI front-end for a locked-down kiosk machine, you may need to interact with device drivers
and therefore C mod_apache modules may come to the rescue... [Another true story, was better than X11, since they planned to move it to Windows CE in the future!]
mod_apache modules are also much more faster then
mod_perl, but unless you're dealing with millions of queries per day, it should not be needed.
I never saw a 'huge' commercial project done in Python, Ruby, Moo or Euphoria, in the last 10 years...
Also, there is JSP and J2EE, they seems also to be good technology, even though I never used them
personally. But maybe for secure e-commerce website, I heard some good comments about it...
In general, I have seen tons of website done in:
Perl, PHP, ColdFusion, Flash, legacy C/C++, JSP,
and more recently tons of
As a side note, the 5 companies which were using
The word 'incompetent' came from the mouth of a
What is funny is that 2 weeks later, the "average MSCE" decided to quit for a better
MOD PARENT UP TO +5!!!
"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."
The developers of Perl wanted to save time in script programming, and that worked when all other tools were worse. But trying to make Perl a full language has exposed design deficiencies that were always there.
I agree there. Lotus Notes is and always has been a very good workflow, mail and colllaboration system. It is not very good at anything else though.
Thhe problem is exactly that "pretty" part in the webappp. That is an issue if you site need to have some kind of actual coorporate design, as quite often it does. Notes is great for small internal dev apps if nobody cares too much about the looks and its great for quick jobs. I once wrote a app for sommeone to upload a set of files with comments while I was on the phone and the chick was very seriously impressed.
As for the normal Notes client, I am not convinced that it belongs in the User Interface Hall of Shame (where it occupies a honorary position). Lotus Notes's interface is somewhat different fromm amyn other (and its the only thing that look like crap on my Mac) but in general its really not that bad and it has some very good iideas. Not if only the iidiiots would let you select alll the doocuments in a category by clicking next to the twisty...
If you develop for the Notes cllient in the collaboaration space Notes is fine. Using it for most others things is a bit of a disaster though, and that is sadly what happenns to it.
And I have nothing to say except negative things as to the friggin need to BUY a plugin to SEARCH your codebase. What else do they want, buying a plugin to display on the screen??!! Searching your code should comms standard and iits s damn shame because Notes already has a very good search engine built in. Notes has quite a few quirks like that, things that should have been obvious but not put in, the whole API seems to be a set of hacks appended to a non-too-bad base.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
The right language depends on who's doing the work. That's right. Today, there really is NO right language. There are many languages. Some of them are very comparable.
But the language doesn't really matter. Look at the developers, your staff. What are they proficient in?
I once had an executive ask me about buying Sun hardware. I told him that Sun was irrelevant. Take a look at his staff. What were they familiar with?
I'm personally very familiar with RedHat on Intel - so I'll buy Intel Hardware, and run Fedora or Whitebox on it. I'll do a good job, and what I put together works very well.
I know Windows admins who do a good job with Microsoft tools. Not my boat, and I'm not floating in it - but they do a competent job.
Don't look at the language, look at your staff, and compare that to what you're trying to accomplish. Trying to ask what's the "best" language is like asking what's the "best" car.
What are you trying to do? A car that goes 0-60 in 4.5 seconds is probably going to suck if you have 5 children in your family that you need to transport from soccer games!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
It's OK. Basically, what's nice about it is the automatic database layering, but any dynamic language like python can do that, and in fact, does do that. Even PHP5 has similar options, afaik. However, RoR doesn't scale as well as it looks in examples: things get complicated quickly. Also, if you're not used to the syntax of Ruby, it can be hard to get to grips with. Personally, I'd recommend Python. It's a modern, powerful, well-supported language, and it's incredibly fast language for development: building complex features that would take a day in C++ takes about an hour in python, yet it still encourages most of the best practices for good programming, unlike languages like PHP. It's much more readable and maintainable than Perl, and modern APIs and refactoring tools like Eric3 make it a pleasure to work on, too.
If you want to stay cross platform. Java with JSF/MyFaces for big sized webapps (the component model slashes development time significantly although the learning curve is very steep)
.Net Webforms)
Ruby/Rails for small to medium sized apps with small dev teams. Active Recordsetzs and other nifty things slash also development time down to nothing, but do not scale very well once teams get bigger of apps more complex.
All other interesting options (Tapestry) either lack tool support or lack crossplatform support or are crippled by deployment licenses. (ADF Faces, Webobjects,
There's the rub, babe. Particularly the "review" part.
The point, which you've obviously taken into account yet discarded for the sake of being contrarian, is that in an environment of any large application, there is a "testing and review" stage in the lifecycle.
Certainly the vast, vast majority of major deployments contain varying degrees of Byzantine or worse "review." If your environment does not and you are managing such a large codebase, you are in for one hell of a CYA session (perhaps resume polishing, even) should anything not go as expected if that is not the case as the sole responsible party will thus be the developer who last typed "commit, deploy."
If you happen to have such a rapid turnaround as is implied, the next question is, what species of beings occupy your organization? If "minutes" is truly the turnaround, clearly it is not "humans."
Someone is getting PHP and MYSQL confused...
Wow! You clearly don't have the least fucking clue waht you're talking about.
care to elaborate?
What bollocks, WebForms have nothing to do with standards, and comply with the abilities of the browser recieving them. If the abilities cannot be ascertained, a safe fallback set of HTML is output. This scales from the latest IE right down to web enabled phones if you do it right, as evidently you are not.Scalability has little to do with what language you use, and plenty to do with how you use it, and how well seperated your logic and presentation tiers are. Ideally a well crafted presentation tier will use so much caching and work avoidance that you can add plenty of them and still not tax your database machines limits.
*That* is how you scale. Another good trick I use is decoupled database writing using a message queue, and then optimizing for fast reads with indexes. If you design your application so that fast comitting is not nessecary, you gain a large performance boost straight off the bat.
PHP and Ruby have lots of easy to use code libraries. But for secure, scalable, solid performing, provable code...I just can't get over my happiness with erlang. http://www.erlang.org./ I worked with Java for over 7 years. We developed very scalable network oriented apps. We built our own frameworks and used others as well. Much of the code was well engineered, but at a high cost of dev time and testing. The problem of massive concurrency was a continual worry. We could be very diligent in making things thread safe, but little things would pop up every now and again. Things that were very difficult to debug. New server, more CPUs...get ready for new found concurrency bugs. As I started over last year to build a new system, I wanted completely away from concurrency problems. I also wanted frameworks that were more lightweight that J2EE ('nuff said). In addition, I wanted something new that made me enjoy programming again. I ended up choosing erlang...yes, it has everything for developing web apps...and then some. It is very scalable and the code is provable to be correct for concurrency issues. Security is top notch and performce is very good. In addition, HTTP server, a good object/relation db, Jabber server, HTML script engine...everything is all written in erlang. No need for mixing code to get a complete solution!!!. Venture out a little...try something new...you might be very surprised.
Certainly it makes sense to involve the developers, but not to give them that degree of power. And further : to involve them in such a way that the eventual choice is not resented, or not resented much; and I think that giving them the impression of choice is one way to eventually get a lot of resentment.
I should also add that allowing developers to choose the language is an unhealthy precendent that has a significant potential for eventually undermining management. Don't give an inch...
Seems like it is you who dont have the foggiest idea what I am talking about .. go and revise some textbooks.
Oh and instead of wasting time and money for Crystal Report, reuse those HTML reports and batch print them directly to the network printer from your user-friendly C++Builder application by embedding InternetExplorer using DCOM.
But Crystal is "paper friendly", HTML is not. Getting the margins, borders, and page-breaks to work right with HTML is a major PITA, if even possible.
Table-ized A.I.
There are some interesting frameworks, like Ruby on Rails, and Seaside.
http://nanoweb.si.kz/manual/mod_bsp.html 'nuf said.
XSLT is a weak, horrible programming language, which gives other XML based programming langauges a bad name. It's only useful for performing simple XML text transformations, but not for programming interactive networked XML data driven graphical user interfaces, which OpenLaszlo is great at.
OpenLaszlo is an excellent open source web programming language based on XML and JavaScript. Your class declarations, object instantiations and configuration constraints are all defined in XML, with JavaScript expressions in attributes and JavaScript methods in text content.
OpenLaszlo strikes an elegant balance between XML and JavaScript, so Laszlo code is quite clean and easy to read and maintain. IBM has developed an Eclipse IDE plug-in for creating Laszlo applications with drag-and-drop and XML outline editors.
You can see for yourself how easy it is to develop interactive graphical web applications in XML+JavaScript with OpenLaszlo: Laszlo in 10 minutes. You can actually see, modify and run Laszlo scripts over the web, to learn how it works.
-Don
Take a look and feel free: http://www.PieMenu.com
Yes, especially for lame bugs, like trying to find out why "while ( && )" doesn't work.
No, PERL was badly defined, just to hack a few scripts and then extended by people who knew absolutely nothing about syntax, orthogonality or readability. A horrid language.
By the way, there's only one language for building large scale web-sites: AWK!
I'm a PHP programmer learning Java right now, but I've also dabbled in python and C++. So far, I can see making general useful tools with both. PHP was written for the Web. Hands down it is the easiest language to learn I know of. Very little can compete with the MySQL/PHP for web applications involving the need for a database.
Java and Javascript, on the other hand, can be mighty powerful. The main problem I see is that serverside implementations like Tomcat and JBoss don't use the same, or even similar syntax, so you're pretty locked into whatever you start with.
PHP is probably the most common, cross-platform, out-of-the-box running web scripting language, besides maybe perl(ack!), I've found. Did I mention it's fast? Also, most of the webhosts running on *nix systems support it, but very few also support JSP's. (I've been on the webhost "scene" for more than 2 years now)
Another problem I've seen in my place of business is that most of the JSP/Java programs are really, really, really slow. We're talking about a program that takes MINUTES to load, or a web/database frontend that takes MINUTES to find what it wants, format it, and present it. This is rather annoying if you ask me. Especially when there's a customer on the phone also waiting for the data. bleh! We also run multiple Java backends (JBoss, Tomcat, and Resin) which always seem to crash for one reason or another.
Chances are, if you're hosting your own site(s), do whatever you want. Any language is scalable and fast if the developers do it right. Otherwise, I'd probably go with PHP on the frontend, and use any number of SQL servers freely available if it's needed.
Let's see...
I know that Abbott and Bayer use Notes for worldwide applications in an FDA regulated environement. They scale, they're secure, they meet FDA's Part 11 rule, they're easy to build, easy to deploy, easy to maintain...hardly the stuff of small time intranets.
Look and feel - that's not a Notes thing. You can make Notes apps as pretty or as ugly as you want. Like everything else, it's just time and money. I prefer quick, easy, native and am more than willing to live with ugly if it gets the job done.
Re the 'must buy addin to search'; I'll concede this point. On the other hand, Notes does provide several native ways to find code so you don't actually have to buy Team Studio.
Doug
Perl has been gradually tacking on closures, declarative programming, metaprogramming and other lisp-like features to the language, in a piecemeal fashion. But Perl will NEVER have a powerful, simple macro system like Lisp, since Perl's fractal syntax makes that totally impractical.
-Don
Interview with Mark Jason Dominus
The Perl Review: Why did you write Higher Order Perl?
Mark Jason Dominus: My main reasons were as I explained in the preface of the book: It had become increasingly clear to me that most Perl programmers seemed to be writing C programs in Perl, and that it was possible to do a lot better than that. We have a really good tool, and it's a shame that we're using it the same way that we have to use the old crappy tool.
[...]
TPR: At the start, you compare Perl, Lisp, and C and say that Perl is more like Lisp than C. Do you think Perl would be as powerful if it was closer to C? Could it be more powerful if it was closer to Lisp?
MJD: I don't think anyone thinks that Perl would be more powerful if it were closer to C. In the 1980s, Unix sysadmins wrote in C and in Bourne Shell, and Perl has largely replaced both of those for those sorts of tasks, leaving C a fairly small niche.
In the preface of Higher-Order Perl, I said that Perl shares six of Norvig's "seven features that make Lisp Different". The seventh one is the one that Norvig calls "uniform syntax". That's the one that led Larry to say that Lisp looks like oatmeal with fingernail clippings mixed in. But it enables language features that are so powerful that they're almost unimaginable to people who haven't studied Lisp. It's really hard to do justice to the huge benefit that Lisp gets from its simple and uniform syntax, which Perl just doesn't have at all. Any attempt to construct Perl code dynamically is fraught with error, and we take it for granted that it won't work. For example, in the documentation of the Perl6::Subs module that was recently released, Chip Salzenberg says "This module is a source filter. Source filters always break." And I think that's true. But source filters in Lisp are easy to write, and they never break. Lisp's main assignment operator, "setf", is implemented with a source filter. So if Perl were more like Lisp in that sense, I think it might be more powerful. On the other hand, I don't think it would be very Perl-like.
Take a look and feel free: http://www.PieMenu.com
JSR routine
as compared to:
MOVE high 16 bits to register
OR 16 bits to register
Branch and link register
Dang, branch delay slot?
Notes is not a relational database. If you need relational systems, don't use Notes. The lack of joins is not dumb, it's a result of Notes' object database structure.
Views are not tables - the SQL join thing really doesn't exist in Notes. If you need joins, don't use Notes.
Thing is, I've found most apps can be built without the need for relational structures. Sure, there's data redundancy required (store user name in ever doc/record if you need to look up results for the user later) but disk space is cheap.
Use the _right_ tool for the job. Notes excels at quick development of workflow type apps (approval systems, doc control, discussions, action items, etc) which turns out to be a major class of apps used by businesses. Throw in the fine grain security (down to encrypted single fields in one record) and you have a great development platform for lots of apps.
It's been a while since I did anything remotely like a web application. For those of us that don't know, why are Application and Session variables bad?
:)
I'm not saying they're good -- I don't know anything about them, and am looking for better understanding.
The senior programmer (manager of our department) where I used to work wrote an entire web application (seemed small, but was VERY robust) in COBOL. He ended up writing his own HTTP replies by hand, etc.
;))
Crazy stuff.
We had built several Java-based web apps, and the sheer amount of things he had to do that were done 'automagically' for us (such as getting/parsing input parameters, hehe) was staggering.
So yes, you *can* write web apps in COBOL. If you're a programming GOD. (Jim is
Think about it, man!! YOU'LL BE THE ONLY ONE TO MAINTAIN IT!
8 of 13 people found this answer helpful. Did you?
PHP does not seperate modules from language, that is the problem. If you add a module, it is just a mess of shit shoved into the global namespace. Reasonable languages have namespaces.
As for scaling, you are talking out of your ass. Please, go ask those people about scaling PHP. They are using it as a template language, and wasting money on lots of extra hardware to do it. It does not scale well at all compared to better languages (pretty much everything but PHP) when used to create web applications.
And I am not confusing anything, you are just ignorant. PHP itself has had DOZENS of stupid security problems. There is even a hardened PHP project in an attempt to address the fact that the PHP developers are incompetant, constantly create trivial exploits in PHP, and do not care enough to learn to do things correctly. This has nothing at all to do with writing code in PHP, and everything to do with all the exploits in PHP itself.
I suggest hooked on phonics, it will help you understand the words you read so you don't respond with a pile of complete and utter bullshit.
Look harder, PHP has a horrible security track record, no other language is even close to as bad.
I said nothing about writing insecure code in PHP, although it does encourage that with its idiotic configuation (register globals, magic quotes, etc), and with even zend putting up example PHP code to teach people that is insecure and full of SQL injections.
I guess you never worked professionally in a BigCorp(tm).
The number one concern in the CS field for the last decades has been to manage complexity. To use as few different kinds of technologies as possible is one way of helping reduce complexity. To use a bunch of different techs (languages, middleware, hardware, network configurations etc.) increases complexity and is A BAD THING. Any experienced architect or programmer thinks both once and thrice before introducing any new tech for a variety of reasons of which complexity ranks at the top.
If you use different techs to get a performance boost, I'm must certainly sure you are tackling the problem the wrong way. The number one reason for bad performance is by using sub-optimal algorithms. Start by profiling and using better algorithms for your bottle-necks. After that you throw more iron at the problem (one server costs about the same as about 10-20 developer hours, i.e. dirt cheap). Introducing new techs comes when alternative 1 and 2 isn't enough. Usually only done under very special circumstances and most likely shows you did a poor tech selection early on, going with the wrong tech for the problem at hand to begin with.
Just because many of us wants to keep complexity low by standardizing on as much as possible doesn't mean we don't know a lot of different languages and arhitectures. Your basic reasoning is flawed as you assume
A is a subset of B <-> B = A
(where A are the techs we talk about for the propose of application to a specific problem and B are the techs we know)
Perhaps it's time to realize that it's probably more likely the following is the case
A is a subset of B <-> there exist n which is an element of A such that for all n, f(n) is a good solution
(where f is a problem domain)
Note, this says nothing of the number of techs we know, only that we chose to talk about selected ones which we deem suitable to the problem domain.
well, you stumped me. I tried haskell, ocaml, python, forth, erlang (although I don't know enough about erl to see anything, even an error message), tcl, perl, bash, csh, and DCL, and none of them liked it.
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?