"He brings up three points: the first point is that Java doesn't require extra tiers for application development, and in the case that extra tiers are chosen, are they really that much of a problem?"

"Our app has 4 basic layers which i think are common for the current ideas of java development: Model, data access layer, action layer, and the view. In fact, if you use Annotations and JPA, your model and data access layer can be combined, similiar to Active Record. Then you have the same 3 simple layers Rails has. However, even if you have the 4th layer, for us its iBatis, how much extra work is it really? At least for us, very little. Taking the extra 5-10 minutes to add some SQL to an xml file isnt exactly pushing our development schedule out by 6 months."

"The second point is about Java compile time. He says that compile time really isn't much of a factor at all, if you're compiling changes to your codebase rather than recompiling an entire large codebase at one time. Compiling changes-only is a very common practice, and it's implemented by default in Eclipse-based IDEs; Even javac won't recompile classes unless it can determine that the class' dependencies have changed. "

"[Editor's note: Anecdotally, I have a sizable project that does a clean build in seven seconds on a fairly underpowered system by today's standards, which doesn't really interrupt my personal flow at all.]"

"If you work in small cycles like most developers probably do, does the 10 second compile time really bring your brain and development momentum to a halt? Come on...if you are making changes in small chunks (i.e. not modifying 100 files at once without testing your code), then this argument is bogus. The day that the extra 5-10 seconds it takes to run the Compile task in my build.xml file throws off my development hot streak (sarcasm) is the day i need to find a new job."

"The HUGE (more sarcasm) time it takes to recycle your changes on the webserver to test your changes. I can buy this argument if you are running on a heavy appserver, but we use relatively simple tomcat for development (and production)."

"This point is a little harder to accept, using Mr. Cunningham's benchmark of 10-20 seconds for a complete recycle of the application deployment. It'd be interesting to see how long the average redeployment takes, and on which application servers."

"What do you think? Is the constant comparison of Rails to Java a "scare tactic" or does it have merit? If it has merit, should Java EE do more to address its weaknesses in comparison to Rails? "

" I agree that most of the arguments to support RoR can be questionable. RoR has a very simplistic approach to web applications and surely there is a number of those who can benefit from it. However, there are also a high number of scenarios in which I believe RoR falls short."

"That said, competition can only be good. J2EE-RoR comparison is not FUD and will surely push java in a direction where simple applications (hopefully) will have simpler solutions - I think that most people agrees that many J2EE specs are overkill for average Joe's CRUD. "

" Java solutions should constantly keep getting better. The lack of -zero- turn around time is a big impediment for many development styles, especially when involved in design and prototyping. People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required."

"Java is not just being compared to the fashionable RoR, it's also being compared to languages like PHP, which despite (in the case of PHP) being a dog's breakfast often yielding unmanageable code bases, can be much easier to set up and work with, even compared to RoR, and are trying to move into Java's "enterprise" space (see Zend &c's recent efforts). "

" Wrt instant code compile / browser refresh of changes - some people are fighting the good fight to get java web development more on par with dynamic languages. "

"Howard has a similar instant class reload setup in the new Tapestry version being worked on....If more frameworks work to address the simple (but hard to implement) things like this it might make for a better java argument. "

"Java solutions should constantly keep getting better. The lack of -zero- turn around time is a big impediment for many development styles, especially when involved in design and prototyping. People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required."

"Java is not just being compared to the fashionable RoR, it's also being compared to languages like PHP, which despite (in the case of PHP) being a dog's breakfast often yielding unmanageable code bases, can be much easier to set up and work with, even compared to RoR, and are trying to move into Java's "enterprise" space (see Zend &c's recent efforts)."

" What doesn't kill Java makes it stronger. IMHO Ruby or more specifically Rails is a sideshow that will see its conventions and language become assimilated into bytecode. It's the VM not the language."

"Now that Vista is out, Microsoft will turn its agile teams to tools. The MS FUD factory hasn't even begun to spew. "

"I'll use SEAM. It has a big enough community at this point, it doesn't matter what people say or do. I would LOVE for Oracle and Weblogic to speed up efforts to make SEAM compatible with their app servers. "

" I have only used it on JBoss. Last I checked it had some issues, but for all I know SEAM may work fine with oc4j now. "

"I'm back on the Groovy booster side now that 1.0 has been released and there are good books/websites for it."

"- Groovy is easy for Java developers to pick up (although it may take a bit longer to master some of the cooler features)"

"- Groovy code has direct access to all of the Java API and the huge amounts of 3rd party libraries. Ruby, does not have nearly this amount of support yet."

"- Groovy compiles down to ordinary bytecode so it benefits from all the high-tech JVM enchancements and on the fly compiling."

"- Java projects using Groovy (e.g. Grails) can run on industry and time-tested application containers (tomcat, websphere, jboss, etc). This is a big plus for java developers since they can reuse their significant time invested in learning J2EE security, JNDI, JMX, app server setup/configuration, etc."

"- Since Groovy is a Sun standard it is much easier to get it accepted into corporate environments. Ruby is a resell of an entire stack."

"- You probably don't have to look for Groovy developers. It would be just as easy to retrain your good Java developers and have them bring along their J2EE experience."

"I don't worry about RoR that much. Ruby is a pretty cool language but Groovy matches its features. To my eyes Ruby is slightly better looking code but Groovy opted for sticking close to established Java conventions, which was the right choice IMHO."

"I'd love to do a Ruby project but right now I'm more excited about mixing Java and Groovy. It is nice to actually be excited a bit about Java development."

"Of course I do ActionScript 3/Flex too if I need to go totally off the rails.... "

"The lack of -zero- turn around time is a big impediment for many development styles, ... People sometimes, reasonably, want to change some code, hit reload in their browser, see the change immediately, and continue tweaking as required."

" My view is that, while the Ruby fanboys are doubtless unnecessarily loud and often blind to the shortcomings of their own toy, they are pointing out valid deficiencies in the Java development model. Filter through the noise and see if there's a useful core message!"

" Well, hmm, to build a DB-aware Web app you have to jam together a bunch of frameworks/libraries/whatever. At the very least, you'll be dealing with, say Hibernate and Stripes or maybe Wicket or Tapestry. OK, they "

" be made to work together, but you have to do the impedance matching yourself. Chances are you'll have to build 2 or more sets of XML files for configuration. And maybe deployment descriptors on top."

" One app I'm involved with has 10,000 source files (!) and requires about 15 minutes to compile. Incremental compilation would be cool but I don't have enough control (= I'm not allowed) to change build process, i.e. to change the Ant task in all the ways this would require. One of the impediments to incremental compilation is ejbgen. If the parts of my project could dynamically link via reflection or something, that might do away with the meta-compilation process and make incremental compilation much easier."

" The app I mentioned takes 4 minutes to deploy. Again, this is partly due to boneheaded policies in place; it should be possible to replace individual JAR files rather than the complete EAR. But it would be still sweeter if a single source file could be replaced in a running program."

"Hot swapping at the class level is possible, at lease in the debugger, since about 1.4."

"This is all good news even if it comes a bit late for the project I'm on; but there's room to improve even more. It ain't gonna happen if people pretend to be perfectly happy. "

"I think this statement is incorrect. I believe 'hot-swapping' is an outstanding Java feature planned forn a future JSR (JSR292). I do not know the specifics of resin, but I'd guess that it can only deal with 'hot-swap' changes that do not change the 'shape' of classes without having to do a full redeploy."

"It all comes down to classloaders I believe. The bottom line is that Java is not dynamic, and instant feedback in the form of REPL has been available in Lisp since 1956."

"BTW static type-checking is no excuse to stick with a early-bound language like Java either. If you take a look at Strongtalk you will see that you can have your cake an eat it too."

"The bottom line is that Java was never destined to be the last word in computer science. It was a tactical language, rushed to market, that fitted nicely between C++ and Smalltalk and allowed Sun, Oracle etc to fend off the impending threat from Microsoft on the Server in the mid-90's."

"I think it is time to move the debate beyond brands like Java and Ruby and to focus on programming concepts like late-binding, polymorphic message sends and class reshaping. Trying to make Java more dynamic is a real nightmare, and you would not start with the current JVM. Put it this way the lead of JSR292 to make the JVM more dynamic is an old Smalltalker, who has given up on the job and left Sun. That speaks volumes to me. Don't expect Java to be fully dynamic any time soon."

"The web is dynamic (which is why incidently that JavaScript is also dynamic and is based on Self), and I believe that the future of the web will be dominated by mobile objects written in dynamic langauges, I'm sure of it. Ruby, Groovy, Python etc is just the start, and they are here to stay, so get use to it :^). "

""To my eyes Ruby is slightly better looking code but Groovy opted for sticking close to established Java conventions, which was the right choice IMHO.""

""Languages are important, because they affect the way you thing about the problem, but again, they can have only impact on the implementation part of the project. Because of their exaggerated claims, some of our newer languages qualify as laetrile. Sure it may be better to do new application in PowerBuilder, for example, rather than COBOL, but even before PowerBuilder there were better ways than COBOL: niche tools that make inquiry and update pretty easy. Unless you've been asleep at the switch for the past few decades, change of a language won't do much for you. It might give you a five percent gain (nothing to sneeze at), but not more." "

"Yeah, I wouldn't say "far more" either way. It is just a difference. I'd bet that Java developers will prefer Groovy's look just because it is more in line with what they are used to."

"I find most of the Groovy warts are a side effect of its biggest benefit: tight integration with Java and the JVM. When Groovy looks less-than-slick it is usually when you are using an existing Java API."

"One app I'm involved with has 10,000 source files (!) and requires about 15 minutes to compile. Incremental compilation would be cool but I don't have enough control (= I'm not allowed) to change build process, i.e. to change the Ant task in all the ways this would require. One of the impediments to incremental compilation is ejbgen. If the parts of my project could dynamically link via reflection or something, that might do away with the meta-compilation process and make incremental compilation much easier."

"As soon as I read 10K source files I guessed that many of these had to be generated. Still, it seems like way to much to put into one compilation unit. Couldn't you break this system up into separate libraries? That seems like it would be more effective than custom ant tasks."

"I'm not sure I get the connection between a weakness in Java and your case example. But your point about pain points=innovation rings true. "

"laetrile:a drug derived especially from apricot pits that contains amygdalin and has been used in the treatment of cancer although of unproved effectiveness."

"So does the more slang usage mean "of unproved effectiveness" or does it mean something else when you use it more loosely?"

"I'm not sure what you are measuring when you say 5% gain. Developer productivity, maintenance, lines of code (or reduction in lines of code), etc? "

""BTW static type-checking is no excuse to stick with a early-bound language like Java either. If you take a look at Strongtalk you will see that you can have your cake an eat it too.""

"Yeah, I can get late binding and strong type checking but will the same code run on almost every machine known to mankind? Nope. Does that language offer vast libraries used by the largest enterprises? Nope. Java has its strengths and people are to quick to forget them when they are point out its flaws. On the other hand, I agree that we should always look at new languages to see what they offer."

"Finally, the old Smalltalker who left Sun who was working to make Java more dynamic holds no meaning whatsoever unless he's publicly stated his reasons. People leave companies all the time for many many different reasons. You're making a big assumption about his motives. "

"I'm not sure what you are measuring when you say 5% gain. Developer productivity, maintenance, lines of code (or reduction in lines of code), etc?"

"Finally, the old Smalltalker who left Sun who was working to make Java more dynamic holds no meaning whatsoever unless he's publicly stated his reasons. People leave companies all the time for many many different reasons. You're making a big assumption about his motives."

"I'm not trying to sell Java short. I'm just pointing out it's limits. The issue like I said should be the right tool for the job. Today the job is web applications. In the rich internet application space Java is being out done by C# with WPF and ActionScript with Adobe Flex/Apollo."

"If you aren't looking to web 2.0+ type apps then a static language like Java may well be fine. C++ still flourishes in many domains. I feel that for web applications that the future is dynamic."

"BTW the JSR292 lead was Gilad Bracha, and he has given a detailed presentation at the 2006 Lang.NET dynamic language symposium, that clearly describes the limits of the JVM for dynamic languages. The line "Don't expect the JVM to be dynamic anytime soon" is almost a direct quote:"

"When I first championed the use of Java back in 1996, it was conceptually a better language for server-side application development then C++, even though C++ had many of the benefits Java has today over languages like Ruby."

"Do you remember Java 1.0 and AWT? It was pretty rough around the edges, poor library support and it was slow, but productivity won through and library support and ubiquity followed."

"So like I said, we should really be discussing the language features that are needed for the web applications of the future. "

"...I do not know the specifics of resin, but I'd guess that it can only deal with 'hot-swap' changes that do not change the 'shape' of classes without having to do a full redeploy..."

"But I'm sure that Resin treats ".java" and configuration files exactly like ".jsp". It detects a file change, recompiles it and unload/reload (part of) the application. It does it fast enought to clasify as ZTT to me."

" "So like I said, we should really be discussing the language features that are needed for the web applications of the future. ""

"I agree but Java and Ruby are about the same age and don't forget that Smalltalk had almost all of Ruby's features 20 years before Ruby existed. There's a reason why a language comes out ahead beyond the mere sex appeal of the language semantics. The language has to prove itself in the enterprise development world to really take off and most languages fail to do that for a wide variety of reasons. Java, for all its faults, was able to make the cut. There's also nothing inherent in Java that makes it any less capable of doing rich internet apps than it is doing any other kinds of apps. "

" The problem here is that most of these folks are comparing either the previous generation of Java technologies (Struts+Spring+Hibernate+J2EE) or the even older generation (EJB2+J2EE) with a totally new technology stack that is still maturing (RoR) and will take another 2+ years to really be ready for serious deployments."

"This is quite unfair, of course. J2EE is now >5 years old! This is obsolete technology! Arguing against EJB2 is fighting a strawman. Likewise, the adhoc Struts+Spring+Hibernate solution is almost 5 years old, and showed its warts over the years. That's why we have the new crop of frameworks to address those problems and reach a new level of simplification."

"A fair comparison would be to compare Ruby technologies to the new generation of Java technologies (Seam/Grails/whatever+EE5). If you do this comparison fairly, you'll see that the EE5 stacks are more mature and stable for production usage, but somewhat less documented and well-understood for development. The underlying machinery is there, but we don't have the books and the real-world success stories just yet, and some of the APIs are still changing."

"* architectural complexity - the new Java EE 5 based stacks are just as simple in terms of layering as the Rubyish solutions"

"* code level elegance - there are wins on both sides: Ruby has some nice elegant language features, but also some awful warts in the way Rails uses these features (compare RHTML to Facelets). Groovy brings many of these same nice things to the Java platform."

"* LOC - there is now no longer much difference in linecount between the Rubyish and Java-based frameworks (of course, the typesafe nature of Java means a few more characters on type declarations, but this is a feature, not a bug) - in many usecases, a Seam solution will have a smaller linecount than a Rails solution "

"* Code/compile/test cycle - the idea that Java developers are sitting around waiting for their compiler to run is hilarious - this is simply not a problem and never has been. OTOH, incremental hot deployment certainly has been a major problem for the previous generations of Java technologies, but this problem is being addressed and solved in the new generation (Seam, Tapestry and Grails now all feature some level of support for this). Meanwhile, the fact that the Java compiler spots all kinds of common errors without even needing to execute the code (wow!) speeds up development considerably for most people."

"* Refactoring and Tooling - Java kills Ruby dead and this is a problem that cannot be fixed in Ruby or any other language without static typing. I will surrender my "rename method" refactoring when you pry it out of my cold dead fingers!"

"* Deployability - don't make me laugh - Java is almost a decade ahead. JBoss or WebLogic vs. Mongrel??!!!"

"* Ecosystem - the Java ecosystem is immense, viciously competitive, and amazingly self-correcting. Ruby has yet to reproduce anything remotely similar."

"But by all means, let the bashing continue, life would just be no fun without it ;-) "

""So like I said, we should really be discussing the language features that are needed for the web applications of the future. ""

"I agree but Java and Ruby are about the same age and don't forget that Smalltalk had almost all of Ruby's features 20 years before Ruby existed. There's a reason why a language comes out ahead beyond the mere sex appeal of the language semantics. The language has to prove itself in the enterprise development world to really take off and most languages fail to do that for a wide variety of reasons. Java, for all its faults, was able to make the cut. There's also nothing inherent in Java that makes it any less capable of doing rich internet apps than it is doing any other kinds of apps."

"You make a lot of statements. You can make a number of arguments for the success of Java over say Smalltalk, not all technical. Equally if we were in 1998ish I could make similar arguments for the success of Visual Basic over say Smalltalk. Visual Basic was by far the most popular language then. Today many of those same arguments would appear foolish."

"For me popularity is not an indicator of being the right tool for the job. C/C++ is a system language yet it is still used as a high level application language by many who still insist to hand-code garbage collection in their applications themselves, etc."

"Like I've said, we should really be discussing language features and the appropriateness for the web. Early-binding at compile time to an interface that exists on the other side of the web (like we are encouraged to do with WSDL for instance) is not a good idea, because every time that remote interface changes (like someone choosing to add an additional method), all the remote clients will break, and new stubs are need and the clients must be re-compiled, and re-deployed. This is very brittle and IMO the main reason why CORBA failed (so we are doing it all over again :^))."

"As for the web and REST, it doesn't work that way. Web pages are self describing, and the HTTP interface is uniform across all servers. So when you add a link to your web page, all existing clients (and thats all the browsers in the world) can update themselves dynamically (well once your user presses refresh)."

"A dynamic message send has similar dynamic semantics, this is very different from a virtual function call which is resolved (mostly) at compile time."

"This is just one example of inapropriateness. BTW C# and ActionScript (as I understand it) don't fare any better in this regard either. "

"Take a look at this site, were a guy is rectifying this problem (amongst others) by layering Lisp then Smalltalk as a Lisp DSL on top of Flex/WPF:"

"He is doing this stuff for a reason, and for me it points to the future. Another site worth checking out is Croquet:"

"Is it? I have come clients and some pending clients who hate web apps, at least those that they use pretty much all day. "

"In the rich internet application space Java is being out done by C# with WPF and ActionScript with Adobe Flex/Apollo."

"It is? How? With Java, I can have a client that functions in the browser, via Web Start or deployed otherwise and have them function the same. WPF is not barely out and one major .Net magazine suggest you not use it right now. Also, WPF in the browser doesn't function like WPF on the desktop. (And it only works in Windows ) And Flex/Apollo, well they have their good points but are not as flexible as Java/Swing/Groovy."

"If you define "web apps" as HTML, Javascript and AJAX then I can understand why your user's don't like them. I don't like them either."

"When I first started using Java, Applets where meant to be the preferred internet application solution, and html and Javascript was just a quick and dirty interim fix until Netscape won through and Applets became ubiquitous."

"Well the problems with Applets have finally been solved, but now Applets are called Flex/WPF RIA Apps and the VMs used are Flash and .Net. This is what I mean by Java being out done!"

"The web isn't standing still, and people are already integrating Ruby with Flex today. I see more changes coming, and I just don't think Java is that well positioned. "

" He is right about everything but the deployment cycle. Yeah sure with jetty or tomcat it is less of a problem but I dont live in a jetty/tomcat world unfortunately. I live in websphere world and there seems no escape from it. When I do small projects on behalf of my own company everything is fine and I enjoy my proffesion but when I work on larger projects it is always websphere. I can work for 3 months with it max, otherwise I start barking at my manager, suffer from sleepless nights, lose weight and hair, look like shit and need prozac or derivatives to get myself going. I had an offer the other day with the best hourly rate ever but I refused it because of this. I know when my money runs out and I cannot find a small project I have no choice but to work with it again, thinking about it alone pumps the cold sweat out of my armpits already. I stink, yak."

" I agree that the Java bashing has been pretty heavy of late, but it stopping altogether is just as extreme as some of the arguments have been. If we all stopped arguing about it as a community, we'd all take orders from one all-knowing entity that decides everything for us because they think they know best (and want to keep selling Windows)."

"A little over a year ago, I read Beyond Java and, despite the kayaking stories, loved it. The Fortune 10 I work for isn't close to dropping Java development over the issues that book raises, but at least it raises them. Java's not perfect and could be better. To me, that's the point."

"BTW, add me to the list of people who likes the idea of running Rails on the JVM. I still wish JRuby could get a little more mature so my sys/admins and upper management could keep the app servers they've come to depend on but our development staff could choose to Ruby when situations warranted it. Now? No way you get Ruby past an architecture review because of the relatively untested (compared to 10+ years of Java) runtime environment. "

" given the policy is a major factor in how you build and develop, using Ruby would also slow down. The problem is stupid company policies that slow developers down. I've seen it first hand and honestly, to me the technology doesn't matter at that point. It's about the business exercising control over the developers because they distrust IT."

"sure, using Ruby might start out faster, but once the control goons get wind of it, they'll put up all sorts of barriers and you're back to the same situation."

"Likewise, the adhoc Struts+Spring+Hibernate solution is almost 5 years old, and showed its warts over the years. "

"A fair comparison would be to compare Ruby technologies to the new generation of Java technologies (Seam/Grails/whatever+EE5)."

"LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year! "

" "LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year!""

" You ever see what a struts-config.xml file or a Spring applicationResource.xml file looks like on your average enterprise app?"

"Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly. "

" An example that demonstrates the maturity and wide selection of libraries in Java compared to Ruby:"

""The MOle allows you to precisely analyze how your customers are interacting with your rails application.""

""LoL! So 'Struts+Spring+Hibernate' was 2006, 'Seam/Grails/whatever+EE5' is 2007? Please tell me the 'stack' for 2008 so that I can skip the drivel for the rest of the year!""

"Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly."

"Did the upgrades come and talk to my developers and force them to crack open the documentation for these technologies, or give them a lecture on what classes should be Sprung verses those that work with good old Java "new"? "

"While not ideal you could make pre-2.0 Spring manageable and even tame Struts. The problem is that configuration is still just code, but by putting it in XML developers treat it like a 2nd class citizen and don't review/refactor it."

"You ever see what a struts-config.xml file or a Spring applicationResource.xml file looks like on your average enterprise app? ugly Yea I know...Struts2 and Spring2 have fixed that, but Struts1 and Spring1 were XML ugly."

"IMO, the technology must be very immature when the hypes change so frequently. No matter what is praised today we know that it will be outdated next year. That's not a basis for serious professional work. "

"The web is dynamic (which is why incidently that JavaScript is also dynamic and is based on Self), and I believe that the future of the web will be dominated by mobile objects written in dynamic langauges, I'm sure of it. Ruby, Groovy, Python etc is just the start, and they are here to stay, so get use to it :^)."

"Paul, I've been on your side on these types of debates in the past (cue a Steve Zara post), but you're way off on this stuff about "dynamic languages". I advise you to lurk over at "

" a bit to get some insight on these "dynamic" debates. The bottom line is that dogmatic late-binding advocacy isn't very interesting or even very realistic. "

" both have late-binding options in otherwise static, type-inferred languages. Most of the critcism I see regarding Java is mostly boiler-plate related. You can have your cake and eat it too regarding static and dynamic typing. "

"obviously RoR is good on some scenario. We don't write our java application to meet one time client requirements. "

"Active record is good but why we will choose it? when we are using some thing better. i think DAO and Model separation is much more manageable and good for serialization."

"in case of serialization how Active record works? many stuffs we shouldn't mash up with Java.. rather go for Google mash up ;)"

"I'll take the risk and push out OSGi as the answer here. What do other people think? My early impression is that retraining enterprise developers in the modular approach enabled by OSGi would address many of the most prevalent and hard-to-fix problems we see in medium- and large-scale enterprise software deployments (read: the Java EE space) today."

"Lest it pass unnoticed, I couldn't help but be amused by Gavin King's latest backhanded swipe at Spring ("It's yesterdays technology everybody! Really!") I've always wondered why the alpha geeks at JBoss developed such a deep-seated grudge against Spring. In recent months they've largely abandoned the rather unseemly FUD campaign of yore, but it seems the old green-eyed monster still lurks in their hearts. Funny, and sad."

" both have late-binding options in otherwise static, type-inferred languages. Most of the critcism I see regarding Java is mostly boiler-plate related. You can have your cake and eat it too regarding static and dynamic typing."

"Nice to hear from you. I think we are in agreement (again) :^). My view that late-bound, dynamic languages are better suited to the web has nothing to do with static type checking, and I agree that the two issues are orthogonal. See my earlier post where I mention Strongtalk: "

"The languages you describe as I understand it are late-bound and dynamic. My view is that the web is dynamic, and we should aim to get to the stage where we can mashup software objects written by different people at different times, across the web in the same way that we mashup web pages using HTML and Javascript today."

"You can do what ever checks you like at compile-time, but that should not fix the binding for ever more at runtime. At runtime you should be-able to swap and change, plug and play, and interface with any object that meets the required interface contract without having to re-compile. This is my point. "

"You can do what ever checks you like at compile-time, but that should not fix the binding for ever more at runtime. At runtime you should be-able to swap and change, plug and play, and interface with any object that meets the required interface contract without having to re-compile. This is my point."

"Just to be clear, by "interface contract", I do not mean a static interface, like a Java Interface or WSDL. No, what I mean is any service object that provides the behaviour you require as a client. If for example you find a service object on the web that satisfies the behaviour you want, and you stumble across another object that you want to 'munge' with that service to provide a new service, then you many need to write some 'glue code' to adapt the messages between them to what is required. The key here is that the services are encapsulated behind message sends, and all they expose is their message interface. You are then free to script and mashup to these message interfaces without worrying about Class (implementation) or Type (fixed Interfaces). "

" You are right, this ridiculous Java bashing needs to stop, I'll go back to using all the Java frameworks, and I'll just forget that I could get done in ActiveRecord what only takes me 4 or 5 classes in Java. Then, I'l hire the extra person it is going to take to complete this project becuase it is much easier to keep the web sites on Rails. When I recommend the extra hires, I'll copy them on this article as justification. "

"I'll stop trying to get Spring + Hibernate to get close to the ease of ActiveRecord, and we'll just go back to handcrafting all of our DAOs even though we've already deivered a functional prototype to the customer. I tell them I've had a change of heart. "

"You are right, this ridiculous Java bashing needs to stop, I'll go back to using all the Java frameworks, and I'll just forget that I could get done in ActiveRecord what only takes me 4 or 5 classes in Java. Then, I'l hire the extra person it is going to take to complete this project becuase it is much easier to keep the web sites on Rails. When I recommend the extra hires, I'll copy them on this article as justification. "

"I'll stop trying to get Spring + Hibernate to get close to the ease of ActiveRecord, and we'll just go back to handcrafting all of our DAOs even though we've already deivered a functional prototype to the customer. I tell them I've had a change of heart."

"All well and good, but if you've seen the light how come you are still haunting the J2EE boards? "

"Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs? Can ActiveRecord use stored procs? If you have to wait 2-4 months to get a physical database, how does ROR or active record help? Does ROR shorten your development time in this kind of environment?"

"Better yet, what happens when your data comes from several databases include a mainframe? And can you cluster ROR to provide fault tolerance and disaster recovery capabilities? I'm asking because I've never used ROR or active record."

">Here is a dumb question. What happens if you work at a company where developers are not allowed to run SQL and absolutely have to go through modeling with a Modeler and then wait for the modeler to talk to the DBA. The DBA then creates the tables. Once that is done, the developers have to write stored procs? "

"In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job? "

"In this scenario I don't think the question is RoR vs Java. I think it's time to ask yourself if it's time for another job?"

"So what you're saying is that everyone working at a large financial institution with these types of processes should find a new job?"

"There's a reason why some applications have this kind of process. Dismissing a real concern does not provide a solution. I've worked at companies with and without these kinds of processes. There are legitimate reasons why these kinds of processes are in place. Is it the best thing for developers? Sometimes it is and sometime it's not."

" I use Eclipse plus the Tomcat plugin from Sysdeo when I want to see my changes immediately on the web page."

"Anyway, the 10 seconds [sic] it takes to compile
... read the whole article