in reply to Whither scripting? Will scripting wither?

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

  • Comment on Re: Whither scripting? Will scripting wither?

Replies are listed 'Best First'.
Re: Whither scripting? Will scripting wither?
by samizdat (Vicar) on Feb 01, 2006 at 15:41 UTC
    That's very true. There are numerous modules on CPAN which support such efforts. Having started to learn the Java pantheon in order to understand my guys' production, I would say that the programming model espoused in J2EE development takes an extreme view, where _everything_ is completely defined through enforcement of edict. The goal is to prevent anything ever from being a loose end. A laudable goal, but a royal pain in the @ss in the way of actually getting anything done.

    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."
[reply]
      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.

[reply]
        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."
[reply]
      I agree with most of your points. I don't have enough experience with large management structures to say anything concrete about it, but it does sound plausible that most decisions in those environments aren't primarily based on technical considerations.

      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:

      1. I can have any number of frontend webservers
      2. Those reverse-proxy to any number of mod_perl application servers
      3. Those communicate with any number of database servers
      That means there is no single point of failure, and increasing scalability simply means adding another box to one of the tiers. Since mod_perl apparently outperforms J2EE, that means you need less machines for the middle tier.

      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.

[reply]
        In our case, we have colocated machines in several cities, with DNS switching. It made the replication far more challenging, but we are free of the SPoF of one datacenter's Internet connection. We will eventually get to the point where we are willing to pay for two direct copper T-1's (or future equivalent) from different ATM entry points into one rack, but, until then, spreading servers out around the Net is the way to go.

        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."
[reply]

In Section Meditations