It sometimes shows up as Java versus Perl|PHP|Ruby, but it's actually about bureaucracy and CYA versus getting the job done. It used to show up as "nobody ever got fired for buying IBM," but these days, it's "web systems need to be enterprise-ready."
I let my programmers talk my partner and I into building our second generation web hiring app in Java with EJB on JBoss, and, yes, they were able to get it working and it's nice, but now, as we add features and bifurcate for modular products, they're discovering how much of A Big heavy Rock all that support code is and how little they need it. They're trying to slip little things like "rewrite in Spring instead of EJB" into the timeline for the separated products. Hmmm...
Meanwhile, in my day job here at SNL, as I've told you, I've been cranking out dozens of Really Useful Things using Embperl and Ruby that are solving problems for people in their daily lives.
I'm not suggesting that there aren't real applications that need the protections that layered code and team-oriented development using design patterns and Application Servers et al provide -- just look at all the hiring Home Depot is doing in Austin, TX on Dice.com -- but they are really few and far between. There are advantages to be had on many levels through developing upon these foundations, certainly, but a carefully crafted scripted web system is a better choice for 95% of all projects, in my !(so humble) opinion.
<ADVICE>
So, the next time you're faced with a Management Decision to implement An Enterprise-Ready Application, just roll the Dice and do a search for 'Software Development'. There's certainly going to be at least one monster project going on somewhere at any given time, and all you have to do is count the number of people being hired. Show that to your PHB, and then be ready with your proposal for getting the job done effectively with far less cost.
</ADVICE>
Don Wilde
"There's more than one level to any answer."
This kind of dynamic has been going on since antiquity. Scripting will always have a niche, and 'enterprise-scale' development will too. Rarely it is based strictly on nuts-and-bolts practicality. Let's not forget: human beings are always subject to political pressure, the desire to feel 'knowledgable' and 'prestigious', and the desire to make things difficult for potential competitors through barriers to entry (turf preservation).
You see it in every realm of human activity, which includes programming and language design.
For people with a 'nuts-and-bolts' inclination, this "political" aspect can be a bit frustrating and bewildering. Nevertheless some PHBs realize that if they don't use Oraclefoo or Javawhiz for high-profile projects, there is a certain level of 'prestige loss' (and perhaps other issues) that cannot be quantified in mere nuts and bolts.
In some industry segments, this is not a major factor; but for universities, large corporations, utilities, financial institutions and other realms where prestige and reputation is the name of the game, you can just bet you are more likely to be Oracalized than MySQLated.
'm not suggesting that there aren't real applications that need the protections that layered code and team-oriented development using design patterns and Application Servers et al provide
Not that you can't do those applications in Ruby or Perl or Lisp or whatever too...
I'm more and more of the opinion that most language choice is made for cultural/social reasons rather than technical reasons.
It does have a benefit for organizations which prefer to have programmers be lowest common denominator interchangeable parts, because it raises the bar of what one can turn in at the end of a shift to at least be something which the compiler will accept. This reassures managers -- who usually are LCD interchangeable parts themselves (to the org, anyway) -- that progress is being made. It doesn't in any way ensure that the _logic_ is complete or correct, but it does expose that level for discussion, which is a good thing.
On the political/cultural/social front, I heartily agree with both of you, adrianh and dimar. Indeed, one of my reasons for letting my guys proceed was the marketing value of that little cup of coffee.
I have to admit that I allowed them to go ahead without really researching it in depth. As I do so now, I see some advantages to the systematic approach espoused / enforced by J2EE, but also lots of disadvantages in the daily execution. I especially see that it's even more critical to understand the layering of the tools you use and their effects on execution. Simply put, there are lots more of them. Java is only one piece, and even in just the core language you have to be aware of the execution costs of things like passing around copies of objects as opposed to references, sorting of fancy collections, etc. Add to that key extensions like Hibernate, Jakarta, and JBoss, and you have an entire system that can be an order of magnitude more complex than Embperl/Apache/MySQL. Is it better? Well, it sure ain't faster, but, yes, it will be more scalable. Our first generation had lots of custom programming to support the PHP/MySQL main site for database and state replication, so that our customers would not be barfed like SalesForce.com is doing as we speak. Such protective mechanisms are much more cleanly created in the new system (although I see many J2EE sites that still don't bother; oh, well. Painful Learning Experiences coming up!) and we will be able to serve more customers faster in the future.
Did we need to do all this? In our case, I think the answer is 'yes and no'. Certainly the scripted version is working very well to serve our present customers. Certainly, the Java version is taking longer to deploy than updating the scripted version would have. Our particular case is a specialized SaaS app that has customers who are nearly all Fortune 500-caliber, and they do depend on us to be up and running 24x7. I think there are very few other applications which do demand this level of service, though, and especially for smaller companies looking to break in, the scripted web service model is entirely adequate and much less costly. Just as we have built our reputation on a scripted system, I believe it is the best way for other businesses to start out and build their way to success. It is even more appropriate for those businesses for which web services are not their core product.
Don Wilde
"There's more than one level to any answer."
One thing that puzzles me though, is that you say that J2EE is a lot slower, yet more scalable than the perl/apache/mysql solution. I don't understand that at all. Surely the slowness implies that you need more boxes to reach the same level of service?
I find making mod_perl apps scalable a breeze: the standard Apache reverse-proxy setup combined with a replicated/clustered mysql setup means that:
- I can have any number of frontend webservers
- Those reverse-proxy to any number of mod_perl application servers
- Those communicate with any number of database servers
For me, that says a LAMP setup can be both cheaper to start with, quicker to develop, and easier to scale.
It's entirely possible to set up this 3-tier model on a single machine, and I generally do so for my clients if they anticipate growth. Moving it to a multi-machine setup is a piece of cake, and doesn't require specialised perl skills. In my opinion, this means a LAMP setup is both extremely effective for small or starting businesses, but equally (cost)effective for large businesses.
Unless I miss something blindingly obvious, the only thing in favor of J2EE would be cheaper developers; but you'd need more of them (which means you need more managers), and they have to work harder, with more complex tools, to reach the same level of service.
I wouldn't say that our development team is larger, although I'll agree that they have to work harder (yes, Java is Awful Damn Wordy!!!). Honestly, market demand hasn't made Java programmers (here) cheaper, but what it has done is made it easier to manage overseas teams.
Again, I'll state my PoV: a great programmer can make a scripted / lightweight system run rings around a J2EE deployment in 95% of applications. However, the more intricate and interconnected the transaction requirements of the business rules, the more you need a well-defined definition layer that insulates you from your Real World. Yes, said great programmer can write one if needed, but the level of app I'm describing also has to be defended against requirement creep by dozens of stakeholders, and I don't know of many such programmers who will subject themselves to such a challenge willingly.
Don Wilde
"There's more than one level to any answer."
Let me just say that I agree with your remarks, even though I believe that many open source projects prove that it's not necessarily Java that makes managing international development teams successful.
I do concede the point that Perl (or rather, CPAN) does not offer as mature a framework for enterprise apps as Java. I suspect that's an indicator of the general interest of the respective developer communities. I do still wonder whether that means there's really a controversy going on between Java and Perl. Maybe I'm just too far removed from the intersection point between your 95% and the remaining 5%, but apparently nobody on either side debates that 5% area, while the 95% part is (from the bottom up?) overwhelmingly filled by Perl. I generally get the impression that most of those Java vs Perl debates are not much more than turbulence in the 90% region, so to speak. Do you think technology decisions in that area are made mainly on the differences between Perl and Java? I wonder.
I hope the above hasn't turned out to be a ramble after all...
Don Wilde
"There's more than one level to any answer."
Add to that key extensions like Hibernate, Jakarta, and JBoss, and you have an entire system that can be an order of magnitude more complex than Embperl/Apache/MySQL. Is it better? Well, it sure ain't faster, but, yes, it will be more scalable.
Well - I'd have to disagree with that :-) I've had more problems with scaling Java systems than I have with Perl ones. Not that this was due to any deficit in Java per se, just that J2EE led them to modularise the systems in a way that could only scale by buying bigger hardware, rather than more hardware.
It's just as simple to write a scalable and reliable Perl application (or Ruby, or Python, or Lisp, or whatever) as it is to write a Java one. Most of the expertise in producing something reliable and scalable sits in the developers head rather than in the language.
Truer words were never spoken, adrianh. That's the crux of the matter. Yes, Perl can be done right and can scale, too. However, it takes a gifted programmer who understands the nature of the environment and the application. Perl can also be done wrong, and that's where I worry. While there's more that has to be learned to do a J2EE scalable app, you can't do it at all until you succeed in putting all the pieces together. It's a PITA, but it does lead to working large applications. I think one gifted programmer would prefer Perl as his vehicle, but if dragonchild's right that those comprise only 1% of our population, lots of companies need an alternate route that isn't so knowledge-critical and is more noob-tolerant.
Don Wilde
"There's more than one level to any answer."
While there's more that has to be learned to do a J2EE scalable app, you can't do it at all until you succeed in putting all the pieces together. It's a PITA, but it does lead to working large applications.
Yet I somehow encounter bad Java apps that don't scale. So the magic J2EE pixie dust doesn't seem to work any better than the magic Perl pixie dust :-)
You seem to be saying that you can give a non-gifted developer (whatever that means) J2EE and they'll have a better chance of producing a good scalable application. That's not been true in my experience.
It seems like you consider Java not to be a scripting language. I don't understand why. As far as i can tell java meets all the requirements of a scripting language.
And it seems to me that there is no case at all to say that scripting is going to go away, ever. The fact is that scripting languages solve a whole bunch of problems of traditional software development and because of this they will never go away.
What criteria do i use to say something is a scripting language? The following:
- Does not compile to native machine code but instead runs on a virtual machine of some sort.
- Does not require (one might even say does not allow) the user to manage memory.
$world=~s/war/peace/g
Let me make one thing perfectly clear (jowls wobble a la RMN!), I'm all for scripting / lightweight web development in 95% of all cases.
Don Wilde
"There's more than one level to any answer."
I don't understand why.
I understand why. Because it's verbose. Very verbose. If nothing else, this alone keeps it from being seen as a "scripting" language by nearly everybody. If you think, "This task is so simple it shouldn't take me more than 5 minutes to write a script to do it", you're not going to reach for Java. (Of course, there's always the hammer/nail syndrome; but those whose only hammer is Java probably don't believe in "scripting" anyway.)
Does not compile to native machine code but instead runs on a virtual machine of some sort.
I don't think so. There's little to stop Java or Perl compilers from targeting real machines; and a Java or Perl "real machine" could be constructed. In the real world :-), compilers for C targeting virtual machines have been around a long time. So this really can't be a discriminator.
Essentially, whether a language is a "scripting" language or not is really in the mind of the programmer. It's about ease of use; about how quickly one can go from problem to algorithm to solution. Whether the machine running that solution is real or virtual rarely if ever enters into that thought process.
perlfaq1: Is it a Perl program or a Perl script?
Most of the above is a regurgitation of a discussion that occurred in the chatterbox.
Scripting languages aren't intended for writing applications from scratch; they are intended primarily for plugging together components.In my mind, to be a script,
- The source code must be ready-to-run. That is, you hand your source file directly to the interpreter and your program is running. Any language could meet this criterion with an "interpreter" that did the compile and run, but C and Java typically don't meet it.
- The language cannot require blocks. A script should be able to run top to bottom without any further structure than lines.
I also like this brief explanation of the difference.
Caution: Contents may have been coded under pressure.