Discussions

Reflecting on the recent Ruby vs. Java debate, Tom McQueeney has written an analysis about the fear that scripting languages are a threat to Java.

Tom provides a great analysis of some of the recent history that got us to this point:

What I think we're seeing in the Rise of the Scripting Language is that Java is overkill for a lot of projects. Just like we all accepted a couple of years ago that EJB is overkill for a lot of projects. The interest in scripting languages could be a trend similar to the growing interest in Spring and Hibernate to help us simplify our applications.

Tom concludes:

...what makes me believe Ruby, Python and PHP won't kill Java is that they haven't been able to do it in almost a decade...the use of scripting languages like Ruby, and scripting-language based frameworks like Ruby on Rails, will increase in the coming years. Still, I don't think Java will fade as a result. I think the increase in scripting languages will help developers refine their decisions on where the power or maturity of Java is needed, and where it's not.

What about groovy which is fully designed by java developers for java programmers. http://groovy.codehaus.org/faq.html#why-groovyIt has fully scripting capability and shortness of python,ruby etc. , but is so tightly integrated with java/jvm. Hence who cares if java dies (in sense of popularism with scripting langs) but jvm lives with groovy. There are so many langs like jython (for python) etc. too which are fuly integrated with jvm. But i feel every body fan of scripting lang should try groovy and see what fabulous it is. It is so close to java syntax and easily mixable with java. You can very easily write beans,servlets etc. too in groovy. It is very less verbose than java, like other scripting langs, but outputs .class after compilation.

>>> Think of Groovy as a Ruby or Python like language that is tightly integrated with the Java platform (as opposed to the Unix/Posix command shell and C-libraries) - allowing you the same powerful and concise coding syntax as Ruby or Pyton but allowing you to stay on the JVM and protect your investment in J2SE, J2EE and all the plethora of great useful Java code out there "without any adapter layers or parallel API sets etc."<<

One of the problems with the 'use the right tool' principle has been wasted code: a powerful library built in one language that is considered the right tool for one task can only be used with difficulty in another language when that is the chosen tool.

For this reason I think there is a platform on which scripting languages will thrive - the JVM. I believe there will be a growth in the number and use of scripting languages that not only run on the JVM, but can call Java classes, and themselves be compiled into classes than can in turn be called from Java. This allows for both seamless code re-use, but it also gives the scripting language access to the full power of Java libraries and those languages that compile into java byte codes get a huge performance boost, especially with the recent speed enhancements for features such as reflection. Instead of having to wait for various independent VM and JIT projects in the open-source world, scripting languages on the JVM can become reasonably high-performance development tools right now. I don't think scripting languages will be much of a threat to Java - on the contrary, I think they will make the Java platform even more versatile and popular.

Scripting languages on the JVM will combine both ease of use and speed of development with the power and maturity that is Java.

Scripting languages on the JVM will combine both ease of use and speed of development with the power and maturity that is Java.

Agreed. That's why I tried to help get Groovy going as a JSR and from that we know now that there is no institutional roadblock to having multiple languages on the JVM.I'm looking forward to having a choice of VM-based languages, for the same VM, in my toolbox.-- geir

Absolutely. Groovy is something I intend to use a lot (especially as there is now a reasonable NetBeans plugin).

Scripting languages on the JVM will combine both ease of use and speed of development with the power and maturity that is Java.

Agreed. That's why I tried to help get Groovy going as a JSR and from that we know now that there is no institutional roadblock to having multiple languages on the JVM.I'm looking forward to having a choice of VM-based languages, for the same VM, in my toolbox.-- geir

Absolutely. Groovy is something I intend to use a lot (especially as there is now a reasonable NetBeans plugin).

Can someone explain me what is so complicated about Java and slow when pressin run in eclipse? I see Groovy as Java+. Sure this + gives shorter code, but how often do I have to open the browser to see the api docs - not to speak of the not typing when using ctrl-space.

I guess what makes Java difficult is first the amateur unfriendly enviroment (unuseable on the Desctop and unaffordable on the server) and second the books which explain synchronized (Hibernate and JMS) in the first chapter.

Out of context: I switched to JDK5 recently and tried generics. Those are - too me - realy difficult. But than I recognized earsure. Now I declare my Lists etc using generics but use them in code as normale Lists. This at least gives me a concise form of documentation. Everything works fine except the warnings (I ignore them - do tests). This is like scripting on a higher level. May be there could be a warning like 'ok in before JDK5 but ....". Thanks JCP for earasures - realy.

Can someone explain me what is so complicated about Java and slow when pressin run in eclipse?

I would like to hear the answer to this too.

Why do you think people are desperately developing frameworks, patterns, aspects, annotations, code generators, and yes, new languages?

Don't get me wrong: I love Java, but the fact is that there are lots of redundant patterns that cannot be expressed as formal language constructs, but rather they are used in an informal way i.e. copypasted time after time.

Are you suggesting people are developing these items because Java is too complicated ?

I mean some things need to be done in a complicated way in Java. Here's a simple example: if you want to implement an interface by delegating all functionality to another implementation, you need to create lots of trivial "boilerplate" code. Of course code generators are helpful, but their problem is that they are one-shot: changes in the interface force you to rerun them.

Another example: to create a singleton you need some trivial boilerplate, too (private constructor + instance variable + factory method). And compare this to ruby or io: just override the method for creating a new instance.

The real problem here is not that these "problems" make code creation more difficult. It's that boilerplate code is harder to read and maintain.

And these were just some "low-level" patterns. How about when you want to express some higher level business concepts? You'll definitely be happy to have more languages (and even create them yourself).

It's always better to be able to declare things instead of writing them out. (For example, it would be possible for a language to provide a singleton keyword to declare a class singleton. In fact, I have created this keyword for Java using JSE.)

If the patterns are redundant as you state then we don't need formal language constructs do we ?

I mean that in order to apply a pattern you need to write redundant boilerplate code. So there is no formalism to support you in writing and maintaining the patterns. (And no, refactoring tools and other helpers are not a formalism.)

Groovy is something I intend to use a lot (especially as there is now a reasonable NetBeans plugin).

Can someone explain me what is so complicated about Java and slow when pressin run in eclipse? I see Groovy as Java+. Sure this + gives shorter code, but how often do I have to open the browser to see the api docs - not to speak of the not typing when using ctrl-space.

I have two specific uses for Groovy. These might illustrate why a scripting language, can, in some situations, be less complicated than using Java.

1) As an expressive language for some business logic.

Java is verbose, and has some language constructs that can interfere with an understanding of what code is doing. An example is dealing with financial calculations. There are no operators allowed for the java.math.* subclasses of java.lang.Number, so you end up with code like this:

when you are writing hundreds of lines of financial logic, this clarity is important - it means that non-coders can read what is happening and provide feedback.

2) As an easy-to-change scripting language.

In some applications I am using user-customisable reports. It would be good if, during the development and testing, some of the logic could also be customised by the user. This can be done by allowing them to change small Groovy scripts which are loaded each time the reports are to be run. This means that the user can change what is happening without having to stop or re-build the application or app server. When the reports are finally as desired, the Groovy scripts can be 'frozen' in as compiled Java classes.

I'd like to hear more about this Steve. I've sort of kept an eye on scripting languages but have not found a good use for them yet (other than for bat files to launch apps).

I must set up a blog. I intend using Groovy for this, but I'm currently finding bugs in the Groovy/Java interface (may be because I am using Java 5.0) - if I get it working, I'll put up a case study. I'm particularly keen on the business logic/rule use - I let verbose Java handle the high-performance stuff, and, at least during development, keep the bits that managers or accountants need to see in something that is readable and easily changed. The combination of transparent persistence + Groovy seems to be a powerful way to write some business code.

I do have a place where I spew out all the useless junk in my remaining 2 brain cells. it's really not worth anything though :) I'm sure if you google, you can find it in a trash on the far edge of the internet.

I do have a place where I spew out all the useless junk in my remaining 2 brain cells. it's really not worth anything though :) I'm sure if you google, you can find it in a trash on the far edge of the internet.peter

Well, at least you do it somewhere else, unlike Rolf who does it here. Speaking of, wonder where our resident jester is. Hopefully on a long vacation.

All this technology stuff really doesn't add up to much. 300 years from now, no one is going to give a hoot what language we're using to write applications. All this banter back and forth will be seen for what it is. A bunch of programmers entertaining themselves :)

Hell yeah! These are the days.I only wish I could go back in time for some PDP assembly-induced brain damage, for the joy of discovering ALGOL on Burroughs B5000, for the glory years of C, for the joy of working with AT&T's cfront (is that still available? please?) and I could go on forever.And, let's not forget, for the opportunity of doing acid at a floyd concert in london.

Surely not... Oh no, I'm reliving the trauma of 15 years ago. Figuring out what on earth was happening with name-mangled translated methods, dealing with the various valid C++ constructs it couldn't cope with...

I think you're in for some serious pain, choosing Groovy I mean. Those guys, frankly, might have half a decent idea where Groovy is going, although I do doubt it, but they're definitely unable to produce something coherent off it.

Take a look at Scala's site and you'll see what I mean.Also stuff like OCaml and Ruby too, the language designers do know their shit.

I think you're in for some serious pain, choosing Groovy I mean. Those guys, frankly, might have half a decent idea where Groovy is going, although I do doubt it, but they're definitely unable to produce something coherent off it.Take a look at Scala's site and you'll see what I mean.Also stuff like OCaml and Ruby too, the language designers do know their shit.

I'm not fussy. Any scripting language that is reasonably dynamic, has closures and can produce class files will do (the latter requirement is not vital).

I'm after a language that can be used for prototyping, yet can be 'frozen' into class files for performance.

we know now that there is no institutional roadblock to having multiple languages on the JVM.I'm looking forward to having a choice of VM-based languages, for the same VM, in my toolbox.

I agree. I think the real issue is the Java platform, rather than the Java language. They are not one and the same, although Java is obviously going to be the dominant language on the JVM for the foreseeable future.

Developing libraries and an ecosystem of the richness around Java takes a lot of time, good management and luck. Thus it's hard to see the platform being seriously challenged by scripting languages that don't enable access to all that good stuff.

However, no language will endure forever, and I think that it is possible that the Java platform will outlive the language, with scripting languages that allow full access to the non-language investments on the platform.

Re choice of tools: late last year we added an experimental feature to Spring (the sandbox, not main distribution) that enables any managed object to be implemented not just in Java, but in a choice of scripting languages. Groovy and Beanshell are supported out of the box, but the abstraction can support other languages. This means that not just the implementation class is hidden by the use of Dependency Injection; so can be the implementation language. (Actually, I got the idea partly from Dion Almaer, who was doing cool stuff with Groovy and WebWork.)

I think this is pretty cool, but the interesting thing (which suggests that there's plenty of life in Java yet) is that it doesn't seem to have excited anything like the interest from developers I would have expected.

(Actually, I got the idea partly from Dion Almaer, who was doing cool stuff with Groovy and WebWork.)I think this is pretty cool, but the interesting thing (which suggests that there's plenty of life in Java yet) is that it doesn't seem to have excited anything like the interest from developers I would have expected. RgdsRod

For me, this is the first I've heard about it. But even so, as far as scripting languages go, so what? :-) I've gone the C->C++->Java route over the years and some scripting language or other is always present, but I've just never seen a concrete need for one for my work.

Rapid prototyping, <insert cool feature here>, none of it has been especially compelling in that I haven't done anything that made me say "Boy, I could really use a good scripting language here."

Perhaps if I was working on a product that needed a scripting language integrated in, but otherwise, It just hasn't been a big deal to me.

For this reason I think there is a platform on which scripting languages will thrive - the JVM. I believe there will be a growth in the number and use of scripting languages that not only run on the JVM, but can call Java classes, and themselves be compiled into classes than can in turn be called from Java. This allows for both seamless code re-use, but it also gives the scripting language access to the full power of Java libraries and those languages that compile into java byte codes get a huge performance boost, especially with the recent speed enhancements for features such as reflection. Instead of having to wait for various independent VM and JIT projects in the open-source world, scripting languages on the JVM can become reasonably high-performance development tools right now. I don't think scripting languages will be much of a threat to Java - on the contrary, I think they will make the Java platform even more versatile and popular.

This could become a reality in Java, but people need to make Dynamic Languages the default method of developing in Java. It means that people need to eat what they put out. It means that J2EE should have a default Dynamic Language for development. It means that Swing needs to drop MVC and go for Morphic with a Dynamic Language. It means that the IDEs should provide the same functionalities that people expect from Java.

Hi I have a doubt ...The advantages of scripting language issaid to be fater development ...lesser lines of code and ease of use. If this is the case i beleive a well developed eclipse platform can do the stuffs easily.1.Having a short scripts [Not a full flown scripting language] which will be convered to java then compiled..if u have autobuild like future i feel the benifit of it.2.prebuilt templates..3.Visual progeamming assembly kind of stuff.

I am a scripting advocate myself, but do not find scripting languages suitable in all scenarios. From my experience, they lend themselves well to applications or application tiers where business logic and business rules can vary greatly, and thus where the ability to test and deploy in a highly dynamic fashion becomes necessary. Such languages are also handy to wire incoming requests to backend services, taking care of the nitty-gritty-dirty stuff that happens in-between.

Yet, I still think that a strongly-typed language is better suited to backends and reusable libraries, especially in the context of teams of developers that must share common code and documentation (and if such doc is missing, then at least code implemented in a strongly-typed language is self-documenting, up to a certain extent).

So no hype and no threat here. This just confirms that developers should master a couple of scripting languages on top of the one they use.

In the microcosm of a single application, that sounds great. But consider that you are managing an IT department that has hundreds of applications.

While it is true that Ruby might be perfect for one application, .NET perfect for another, and Java perfect for another. If you go down this road, you end up with a giant spaghetti ball mess of a development and deployment environment to support.

Forcing your IT department to support that many tools not only makes the environment more complex, but it makes the task of keeping and hiring a staff to cover that environment much more expensive. And training is much more complicated since the number of necessary courses is enormous.

The reality is that in the macrocosm of a modern large corporation, the "choose the right tool" argument breaks down. Or rather, you have to at least take into account whether an existing tool, while not ideal, is "good enough" to get the job done.

And the reality of most business IT shops is that Java is generally the best fit for those applications as a "jack of all trades" tool. (I will leave open the possibility that a similar argument could be made for .NET, but Ruby and other scripting languages clearly do not qualify.)

Sure, if you are developing operating systems or embedding software or something, Java is not appropriate. But that is not the typical charter of most IT shops.

But if you are throwing up an quick application for your church group or something, by all means choose a lightweight scripting tool that meets your needs.

I think there's a tendency for those new to programmers to use technologies that seem easiest and that are "good enough" for the task at hand. People used to write desktop apps in C. Then newer entrants into the field chose C++ instead. Nowadays, more people are writing these apps in Java or Python because a gui app rarely needs speed, and Java and Python are just easier to write in.

I applaud this tendency whole-heartedly.

The only reason I stick with Java for my home projects and gui apps is because I really like source code that include typing information, and I enjoy playing with bleeding edge stuff, like aspects and IoC that I don't see in the Python community. Although IoC is frequently about working around Java's static typing, I don't believe that's all it offers, and I don't know of a Python IoC effort.

People still use C when they have to. People will continue to use Java when they have to as well, but I do think the less people write gui apps and hobby projects in Java, the better - it's not as well suited to that stuff as Ruby or Python, or Nice, etc. I don't doubt that Java's future is more niche-y than ruby or python. Nor am I upset by it.

People will continue to use Java when they have to as well, but I do think the less people write gui apps and hobby projects in Java, the better - it's not as well suited to that stuff as Ruby or Python, or Nice, etc. I don't doubt that Java's future is more niche-y than ruby or python. Nor am I upset by it.

People tend to stick with the language they use for a living! For most that will be Java, C# or C++. At this moment Ruby is an extremely niche language, mostly for those who have to develop in the PERFECT language. Remember Stroustrup's infamous quote about PERFECT languages?

Now Python has made it out of the niche language and I've seen it replacing PERL in many projects.

As for GUI's not needing speed, if that were actually true Java/Swing would dominate the desktop market.

As for GUI's not needing speed, if that were actually true Java/Swing would dominate the desktop market.

That had very little to do with it (and has nothing to do with it now). It is all about perception and very little about reality. For example, VB is horrible for large applications (and getting the same functionality as Layout mangers is - well I've never seen it). For example, want to do have the same view on a popup window and a MDI child? You need to code an ActiveX control. And then the real fun begins. Yet VB is (was) very popular for making, at least internally, desktop applications.

I used Perl 5 quite a bit back around 1996 to 2000 and it had this half breed mix of procedural and object-oriented notation which made it inconsistent. The Perl 4 branch did not have OO features and Perl 5 was stretched to support it. I do not want to see Java try to be all things to all people. There is nothing wrong with having a happily satisfied niche.

One of the scripting languages should become a de facto standard which compliments Java and allows for quick scripting of simple tasks. I could even see how a Spring framework could allow for access to rich Java libraries from scripting code much like how Perl can use modules. If Java tries to becoming a managed language and a scripting language all in one it will be a big mistake.

Currently Perl 6 has been in the incubator for more than 2 years to attempt to satisfy the "golden hammer" mentality of Perl users. A scripting language, such as Ruby, which has a clear purpose and goal (only OO) is able to move more quickly to implement new and useful features. And many Perl developers (like me) have left because it became to time-consuming to manage all that complexity.

J2EE should shoot for a .NET like CLR env.The support by J2EE for other languages should be standardised via a JSR.

Pure Java is what 99% of the users need. So I don't see Java dying out any time soon. But Sun should satisfy need for a hodge-podge of languages recognizing that some languages may have an edge over java on certain things.

How is maturity a feature?And how do we measure maturity?How can we compare two language and decide which one is more mature?Maturity of what: design, implementation, theoretical background?

Calling a language mature, reminds me of when I debate something with an older person, I read more then him on the issue, I faced and dealt with the situation in real life, I do have a better opinion on the issue. So to save his pride, the older guy will say things like, you can only learn this from experience, you will only get experience with age.

Just because I am younger doesn't mean I know less, actually it could mean I know more since I read more recent literature on the issue. Also, for many things, no mater how much you repeat them, you won't learn something new. You are hitting the same nail from the same angle.

Beside, will python or ruby ever catch up, or will java always be the older more mature sister!

And what about perl or tcl they are as old as java. I am a big Tcl fan by the way.

How is maturity a feature?And how do we measure maturity?How can we compare two language and decide which one is more mature?Maturity of what: design, implementation, theoretical background?

All of that, and being thoroughly tested, and having enough people use it so that the capabilities and limitations are well understood.

Calling a language mature, reminds me of when I debate something with an older person, I read more then him on the issue, I faced and dealt with the situation in real life, I do have a better opinion on the issue. So to save his pride, the older guy will say things like, you can only learn this from experience, you will only get experience with age.

Ah, the innocence of youth! As someone who you would probably classify as an 'older person', I can verify that the experience that comes with years and years of development does indeed help you become a far better developer. Lack of experience does not relate to having a better opinion.

But, of course, that is just my view as an 'older person'. Perhaps we could have a little less ageism here?

Just because I am younger doesn't mean I know less, actually it could mean I know more since I read more recent literature on the issue.

Yes, because we older people never read recent literature!

Also, for many things, no mater how much you repeat them, you won't learn something new. You are hitting the same nail from the same angle.

Yes, because you never learn anything just by getting more experience, do you?

Beside, will python or ruby ever catch up, or will java always be the older more mature sister! And what about perl or tcl they are as old as java. I am a big Tcl fan by the way.

Should I learn a new language for each domain? What can I trust to be there for me 5 years from now? Will they be backwards compatible? Am I just wasting my time having to replace X with Y all the time when things go bad with X?

Scripting can be great, but it can't fulfill the core development role. Scripting is for spesific tasks in spesific domains.

Groovy/Ruby/Python will not replace Java in every case. Strong typing means less productivity, but also better security, and better complie-time safety. The question is, what's it worth to you? Can you get "close enough" with scripting languages?

I'm working with a start up as CTO with Justin Gehtland. We switched to Ruby for our project because it made us roughly five times more productive. There are lots of reasons for this:

- The feedback cycle is faster. Change a JSP (or RHTML script) and immediately see the results- just reload. Change Ruby code, and you see the same thing.

- The meta-programming is awesome. Rails is just one example of this. When you need to attach functionality at a high level, just modify the object. Need to build an interceptor? Just rename a method, and add a method in front of it that does some work and forwards the message...dynamically, at run time. All people who are bashing Rails don't get it. Rails lets you do some pretty sophisticated stuff, without code generation (in the IDE, with byte-code enhancement, with XDoclet, with code generation). Sure, it's not yet as mature...but the fixes that go into rails to add better security and better ORM will go into the framework, and will not impact the code base.

- You get fewer lines of code. To us, that means less effort to write, but more importantly, to maintain.

We should face it. If we need a middleware language, Java is it. But too many of us have been using an adapted systems language to write application code, and some people are feeling the pain.

By the way, I ditto the comments that say that the real strengths of Java are in the community, and in the JVM. Those are the crown jewels.

I am all for the simplest solution that could possibly work. And here's why non-type-safe languages yield more complex code:

1. Reading and understanding the code is difficult because it doesn't inform you of properties/behaviors supported by variables. You are forced to trace through the code to understand how it works.

2. You can't perform any kind of usage analysis or refactoring on non-type-safe code. This makes it difficult to understand existing code and refactor it to make it more intuitive.

3. You can't reverse engineer code into UML, again inhibiting understanding of the code.

4. It is easy to call a method that doesn't exist on an object. You only find out during Runtime, rather than at compile time. You can easily compile every line of code in project to ensure a minimal level of integrity. However, executing every line of code in a non-type-safe project can be challenging and time consuming.

5. You can't use many IDE features such as code completion, flagging syntax errors, and automated navigation to parameters, documentation, etc.

6. Since you can't use code completion, you are more likely to introduce spelling errors.

Lastly, to those are argue that strongly typed languages are unnecessarily verbose and that compiling is an unnecessary step, consider this: Complexity is the bottleneck in software development, not the time it takes to type a few extra characters, nor the time it takes to compile code.

Okay, the right tool for the right job. Frankly, I've never work in a project where it took more time to write code that it took to understand, fix and maintain it later.

Actually, you can have code completion and refactoring. Even Python's eclipse plugin supports code completion, and there are tools that do some refactorings. I'm not saying it's as powerful as what you can do in Java, but you might be surprised at how good it is, even at this early stage in the plugin's development.

I am all for the simplest solution that could possibly work. And here's why non-type-safe languages yield more complex code:1. Reading and understanding the code is difficult because it doesn't inform you of properties/behaviors supported by variables. You are forced to trace through the code to understand how it works.2. You can't perform any kind of usage analysis or refactoring on non-type-safe code. This makes it difficult to understand existing code and refactor it to make it more intuitive.3. You can't reverse engineer code into UML, again inhibiting understanding of the code.4. It is easy to call a method that doesn't exist on an object. You only find out during Runtime, rather than at compile time. You can easily compile every line of code in project to ensure a minimal level of integrity. However, executing every line of code in a non-type-safe project can be challenging and time consuming.5. You can't use many IDE features such as code completion, flagging syntax errors, and automated navigation to parameters, documentation, etc.6. Since you can't use code completion, you are more likely to introduce spelling errors.Lastly, to those are argue that strongly typed languages are unnecessarily verbose and that compiling is an unnecessary step, consider this: Complexity is the bottleneck in software development, not the time it takes to type a few extra characters, nor the time it takes to compile code.Okay, the right tool for the right job. Frankly, I've never work in a project where it took more time to write code that it took to understand, fix and maintain it later. Juan

Juan,

I agree with a lot of what you are saying. I don't think this has to be the case. The IDE tooling for Jython, Groovy et al is not that good (does it really exist yet). See my earlier comment for more details.

I am all for the simplest solution that could possibly work. And here's why non-type-safe languages yield more complex code:1. Reading and understanding the code is difficult because it doesn't inform you of properties/behaviors supported by variables. You are forced to trace through the code to understand how it works.2. You can't perform any kind of usage analysis or refactoring on non-type-safe code. This makes it difficult to understand existing code and refactor it to make it more intuitive.3. You can't reverse engineer code into UML, again inhibiting understanding of the code.4. It is easy to call a method that doesn't exist on an object. You only find out during Runtime, rather than at compile time. You can easily compile every line of code in project to ensure a minimal level of integrity. However, executing every line of code in a non-type-safe project can be challenging and time consuming.5. You can't use many IDE features such as code completion, flagging syntax errors, and automated navigation to parameters, documentation, etc.6. Since you can't use code completion, you are more likely to introduce spelling errors.

I have to disagree strongly with this. Smalltalk is a non-type-safe language, and good Smalltalk IDEs have none of these problems. Usage analysis and refactoring have been present in Smalltalk IDEs for decades. UML production has been around for a while as well. Other features, such as code completion and navigation through documentation are also available.

I think the problems you mention are only likely to be present in some scripting languages, and even then there are some good IDEs, such as for Python.

Lastly, to those are argue that strongly typed languages are unnecessarily verbose and that compiling is an unnecessary step, consider this: Complexity is the bottleneck in software development, not the time it takes to type a few extra characters, nor the time it takes to compile code.

I do not know why people have to disgrace one language in order to praise another one. Unfortunately, they, most of the time, do exactly that.

I am not surprised about Bruce Eckel et al., though. He is the person who was bashing C++, in his Thinking in Java book, saying C++ is far inferior. Quite the same attitude that he had regarding Ruby vs Java. So, as much as I may respect him and others - I am not surprised, neither convinced.

I, also, can not possibly believe that productivity is all about the language/technologies you use. I know a group of very bright programmers writing in TCL, archaic language for web-development, by all means, and producing far better system than most of the Java rubbish (or PHP or whatever) that me and you have seen. The project I mean is .LRN, developed in MIT and based on OpenACS platform to the core of which is TCL language.

I do not know about Ruby to argue but I know much about PHP so here is what, I think, is the matter of fact: PHP _is not_ easier than Java. They are not even comparable but if you mean - developing web-pages in PHP and in some of Java technologies/frameworks that are comparable - PHP _is not simpler_ period.

What is very different (and makes huge difference) is the availability of cheap, shared LAMP hostings and huge number of modules you can install for free (news, forum etc.).

There are not enormous number of 5$/mo Java hosting solutions. And, most of Java OSS projects have been about the creation of frameworks, not working modules (even if lousy). The latter is improving. There are number of solid Portal+Portlet OSS solutions in Java, now.

If now, somebody would have enough common sense to invest in making easy Java shared hosting solution, so that hosting companies can market it as easily as CPanel, WHM and Exim of the PHP world - the picture WILL change!

Create such solution, get it installed on a critical mass of hosting servers and let's talk about PHP superiority two years after that!

Shared, easy, cheap hosting system - that's where Java world has come short on. The reason is - Java is mostly used in the enterprise and they do not seek for light hosting packages. That is understandable but does not have to be that way, neither is a good excuse.

What is very different (and makes huge difference) is the availability of cheap, shared LAMP hostings and huge number of modules you can install for free (news, forum etc.).There are not enormous number of 5$/mo Java hosting solutions. And, most of Java OSS projects have been about the creation of frameworks, not working modules (even if lousy). The latter is improving. There are number of solid Portal+Portlet OSS solutions in Java, now. If now, somebody would have enough common sense to invest in making easy Java shared hosting solution, so that hosting companies can market it as easily as CPanel, WHM and Exim of the PHP world - the picture WILL change!Create such solution, get it installed on a critical mass of hosting servers and let's talk about PHP superiority two years after that!Shared, easy, cheap hosting system - that's where Java world has come short on. The reason is - Java is mostly used in the enterprise and they do not seek for light hosting packages. That is understandable but does not have to be that way, neither is a good excuse.

+1

You hit the nail on the head with that one IMO. I have 6+ years of Java experience and had never used PHP before, yet I chose PHP to create my last two websites. The 2 reasons were the ones you stated: a much cheaper hosting option and a full featured CMS with many extensions that I could use to get my websites out the door with everything I wanted in the space of hours.

I have 6+ years of Java experience and had never used PHP before, yet I chose PHP to create my last two websites. The 2 reasons were the ones you stated: a much cheaper hosting option and a full featured CMS with many extensions that I could use to get my websites out the door with everything I wanted in the space of hours.

Sure PHP is great for websites. Now web apps or more specifically apps that have, as one of their UIs, a browser UI ... that is a totally different story.

The JVM is a good platform for scripting languages. You can leverage the massive API, frameworks and community of Java.

For more information on scripting languages and increased productivity check out the paper "Scripting: Higher Level Programming for the 21st Century" by John K. Ousterhout. The paper basically states what I have experienced: namely, a sharp increase in productivity by using a higher-level language. The paper states that a scripting language is five to 10 times more productive than a strongly typed language like Java. (There are some issues noted below).

Scripting languages, however, don't replace a Java language; they augment it. And five to 10 times more productive seems a little high to me. My personal experience has been two to three times as fast, depending on the application. Your results may vary. Jython and its cousin Groovy are very expressive.

Like many platforms (and Java is very much a platform), the JVM has many languages. And the list of those that work in the JVM seems to keep growing. Mixing Java with a scripting language is a powerful one-two punch.

If you application was a building, think of Java as the foundation, the wood framming, and such. The scripting languages would be the paint, window treatments and couch. You change the paint, window treatments and furniture more often than you change walls, and foundations. Thus, scripting languages are more flexible and should be used for the parts of the applicatiion that changes the most.

I don't view it as a competition... more like a marriage.

Problems with this approach....

The issues is that other languages (besides Java) are not supported that well. The problem is not with the JVM, but with the dev tools. What Jython and Groovy are missing is good tooling (code completion, refactoring, debugging, etc.).

This is one reason that I don't use Jython as much as I use to. Frankly, the Java IDEs are really good, and I don't want to give up that support. The IDEs are so good that a lot of the advantages (tersensess and expressiveness) of scripting languages are negated.

If the tools (read IDEs) were better at supporting other languages (Jython and Groovy for example) the scripting languages would be more viable option to Java (running in the JVM).

The other reason I don't use Jython as much is that other developers can't support it (won't support it). If you are the only one who knows it, you own it (forever).

Hopefully Groovy will be supported well by IDEs in the future and since it is a JSR maybe it will ship with the J2SE one day. Groovy is very Python/Jython like. Perhaps if Groovy is a standard more people will take it seriously (a problem I found with Jython).

In short, I don't view scripting languages as a threat to Java since the JVM is the best platform for scripting languages.

I generally don't have many issues with what you have written, but this:

In short, I don't view scripting languages as a threat to Java since the JVM is the best platform for scripting languages.

Is very limiting to a language author. Matz, author of Ruby, considers that it's not very good to write an OO language on top of another OO language. You could have a good subset of a good Dynamic Language written for the JVM, which is what many of you propose, implicitly. But it would need to move with the JVM changes, maybe supporting only the latest JVM version, because to support anything beyond what is available in the JVM would be close to impossible, because C wouldn't be available. Still, the language would need to create its own *easy* wrappers around the most used Java libraries, which would mean two different APIs with two different documentations. It definitely could be done, but it would be an inglorious job. I think Sun is going to trick you in believing that the Dynamic Languages are coming... just so you won't jump ship.

Matz, author of Ruby, considers that it's not very good to write an OO language on top of another OO language.

With these scripting languages you are targetting the VM, not Java. It isn't on top of another OO language - it is on top of the VM machine code.

But it would need to move with the JVM changes, maybe supporting only the latest JVM version, because to support anything beyond what is available in the JVM would be close to impossible, because C wouldn't be available.

The VM itself is highly stable. I think you are confusing the VM with the language and libraries. Code written years ago still runs fine on the Java 5.0 VM. Of course, C is always available via JNI.

Still, the language would need to create its own *easy* wrappers around the most used Java libraries, which would mean two different APIs with two different documentations.

The language usually doesn't need to create any wrappers. There is usually a single mechanism for accessing Java classes and that can then be used to call any Java class.

Here is a JRuby example, taken from the website:

require 'Java'

module Foo include_package 'java.util'

r = Random.new

You see, no need for any wrappers.

I think Sun is going to trick you in believing that the Dynamic Languages are coming... just so you won't jump ship.

There is no trick. There have been dynamic languages on the JVM for years: Jython, JRuby, Smalltalk, TCL etc.

With these scripting languages you are targetting the VM, not Java. It isn't on top of another OO language - it is on top of the VM machine code.

Alright. Don't you think that Groovy could use some help? :-)

The VM itself is highly stable. I think you are confusing the VM with the language and libraries. Code written years ago still runs fine on the Java 5.0 VM. Of course, C is always available via JNI.

I see. Jython must be up-to-date then.

The language usually doesn't need to create any wrappers. There is usually a single mechanism for accessing Java classes and that can then be used to call any Java class.

Here is a JRuby example, taken from the website:

require 'Java'

module Foo include_package 'java.util'

r = Random.new

You see, no need for any wrappers.

Nice code. Same with Ruby:r = rand

I don't sell complexity. I don't expect complexity.

There is no trick. There have been dynamic languages on the JVM for years: Jython, JRuby, Smalltalk, TCL etc.

I know -- hundreds of marginalized languages. When is their time coming within the JVM? I don't know. Maybe never, as people want to sell complexity, and I am not referring to any of you alone, but the whole Java techs and vendors.

With these scripting languages you are targetting the VM, not Java. It isn't on top of another OO language - it is on top of the VM machine code.

Alright. Don't you think that Groovy could use some help? :-)

Well, yes, perhaps, but I don't see the relevance.

The VM itself is highly stable. I think you are confusing the VM with the language and libraries. Code written years ago still runs fine on the Java 5.0 VM. Of course, C is always available via JNI.

I see. Jython must be up-to-date then.

How is this relevant? When it is up-to-date, there will need to be few if any modifications to track VM changes.

The language usually doesn't need to create any wrappers. There is usually a single mechanism for accessing Java classes and that can then be used to call any Java class.Here is a JRuby example, taken from the website:require 'Java'module Foo&nbsp;&nbsp;include_package 'java.util'&nbsp;&nbsp;r = Random.newYou see, no need for any wrappers.

There is no trick. There have been dynamic languages on the JVM for years: Jython, JRuby, Smalltalk, TCL etc.

I know -- hundreds of marginalized languages. When is their time coming within the JVM? I don't know. Maybe never, as people want to sell complexity, and I am not referring to any of you alone, but the whole Java techs and vendors.

I'm puzzled. How have I been trying to sell complexity? Why is the simplicity of languages such as Ruby and Python in any way reduced by having them in the JVM? The JVM can be considered as nothing more than another processor type, and the interpreters for the language are written in Java as against C/C++, so I fail to see how this is introducing complexity. I would say it makes things far simpler: JRuby can directly call a Jython class. I would be interested to see Ruby directly calling a Python class!

I'm puzzled. How have I been trying to sell complexity? Why is the simplicity of languages such as Ruby and Python in any way reduced by having them in the JVM? The JVM can be considered as nothing more than another processor type, and the interpreters for the language are written in Java as against C/C++, so I fail to see how this is introducing complexity. I would say it makes things far simpler: JRuby can directly call a Jython class. I would be interested to see Ruby directly calling a Python class!

Library writers might not want to use Java ever again, which means that they could write their own "wrappers" and libraries to avoid having to type the code just like it was Java but with a different syntax. It would have been better if these "wrappers" and libraries could have been provided by default, which would make writing JRuby code almost as pleasureful as if it was Ruby. You would need to take the "red pill", just like Neo:http://www.arrod.co.uk/essays/matrix.php

You can't force people to keep taking the "blue pill" forever.

By taking the "red pill" and having many "wrappers" and new libraries which would make use of the JRuby syntax to its fullest, you could approach a lot what is possible without the JVM. It would mean less need to use code completion, automatic refactoring and giant IDEs.

When you put JRuby or JLanguage against their original versions, you are comparing much more than simply syntax. If you haven't ever used really easy and powerful libraries outside of the JVM, you don't know what you are missing. If you haven't ever written your own custom and specialized library, you don't know what you are missing. If you haven't yet written something close to a "Domain Specific Language", you don't know what you are missing.

If you don't take the "red pill", you will not know what you are missing, but it's your choice, Neo.

I'm puzzled. How have I been trying to sell complexity? Why is the simplicity of languages such as Ruby and Python in any way reduced by having them in the JVM? The JVM can be considered as nothing more than another processor type, and the interpreters for the language are written in Java as against C/C++, so I fail to see how this is introducing complexity. I would say it makes things far simpler: JRuby can directly call a Jython class. I would be interested to see Ruby directly calling a Python class!

Library writers might not want to use Java ever again, which means that they could write their own "wrappers" and libraries to avoid having to type the code just like it was Java but with a different syntax. It would have been better if these "wrappers" and libraries could have been provided by default

This is a bizarre statement. You are implying that having access to the full range of Java libraries is some kind of problem? You aren't forced to use anything.

It would mean less need to use code completion, automatic refactoring and giant IDEs. When you put JRuby or JLanguage against their original versions, you are comparing much more than simply syntax.

Who says you need to use code completion, refactoring and IDEs? You can use JRuby, Jython etc. straight from the command line just like Ruby and Python. There is no difference.

The JVM is just a bytecode interpreter. It need not take up much memory. You can run command-line scripts using your own libraries if you wish.

If you haven't ever used really easy and powerful libraries outside of the JVM, you don't know what you are missing. If you haven't ever written your own custom and specialized library, you don't know what you are missing

I have been a developer for decades, long before Java appeared. I did not find that the power of libraries suddenly vanished as soon as they were placed on the JVM.

If you haven't yet written something close to a "Domain Specific Language", you don't know what you are missing.If you don't take the "red pill", you will not know what you are missing, but it's your choice, Neo.

I have used a very wide range of languages over the years: these include such dramatically different languages such as COBOL, Smalltalk, LISP, Prolog, TCL, Modula. Guess what? They are all available on the JVM, and none of them magically lose their power because of it.

If you haven't used a JVM, you don't know what you are missing - you have a reliable system available from multiple developers and vendors that runs almost everywhere. There are even open source versions.

In a way you could say that JSP with JSTL is another( very limited application) language running in the JVM. JSTL is not strongly typed, actually I think it goes quite a bit of the way from java to a being a scripting language which interoperates quite well with java (OK so we have a compile phase involved but the way we write and run is very script like). I doubt there are many people out there who would rather be using servlets to create their web pages.

If JSP can be so widely accepted and welcomed why not the a JVM based scripting language such as Groovy, Jython and JRuby.

To me things like groovy are really exciting, they mean I can use my java skills (which are far stronger than my perl) for my throwaway once off code and other code where performance is not so vital.

By taking the "red pill" and having many "wrappers" and new libraries which would make use of the JRuby syntax to its fullest, you could approach a lot what is possible without the JVM. It would mean less need to use code completion, automatic refactoring and giant IDEs. When you put JRuby or JLanguage against their original versions, you are comparing much more than simply syntax. If you haven't ever used really easy and powerful libraries outside of the JVM, you don't know what you are missing. If you haven't ever written your own custom and specialized library, you don't know what you are missing. If you haven't yet written something close to a "Domain Specific Language", you don't know what you are missing.If you don't take the "red pill", you will not know what you are missing, but it's your choice, Neo.

I guess you are just saying that if you use a script language in the JVM environment, you should open your mind and see what else the language has to offer besides the syntax. Am I right?

I definitely agree. But I don't see how this can be used as an argument against porting languages to JVM.

Foreach X in Languages JX >= X. (The JVM version has everything the original has, but in addition it has access to the awesome library of Java code.)

I guess you are just saying that if you use a script language in the JVM environment, you should open your mind and see what else the language has to offer besides the syntax. Am I right?I definitely agree. But I don't see how this can be used as an argument against porting languages to JVM.Foreach X in Languages JX >= X. (The JVM version has everything the original has, but in addition it has access to the awesome library of Java code.)How can this be bad?

I guess you are just saying that if you use a script language in the JVM environment, you should open your mind and see what else the language has to offer besides the syntax. Am I right?I definitely agree. But I don't see how this can be used as an argument against porting languages to JVM.Foreach X in Languages JX >= X. (The JVM version has everything the original has, but in addition it has access to the awesome library of Java code.)How can this be bad?

Once you reach this point, you could have made the new Dynamic Language just as useful as the Java Language. This is important, else it won't be useful beyond your "scripting language", which could just be Velocity, most of the time. :-)

But even this is not enough. To address the verbosity of Java and its libraries, the new language would need:1- Cool and Open Source IDEs available on all platforms, or2- Easy wrappers to the most common APIs.

There is a catch, though. If you choose the "1" above, it means that the language would need to compete with Java on its own territory, and it would lose -- terribly.

It means that you need "2" and -- who knows--, "1".

There is another catch: people think J2EE is Java. It's difficult to address Java in the general sense to the J2EE people. If you want an awesome and competitive J2EE, just force the complexity of the Frameworks down, make them totally Open Source, and provide easy access to them from the Open Source IDEs. You don't need ASP.Net 4.0 and VS.Net 6.0. These technologies are Microsoft only. You need to address this in the complexity and availability (free) issues.

If you make things complex enough to create a market of its own, it's difficult to compete even with your own shadows. You don't want to address this because it's what sustains many of you. Your market is in "helping" the developers accomplish their jobs. Many people are saying: "thank you very much. So long." And migrating to other platforms.

As I see it, the next revolution of languages and tools is going to cost you a lot. The JVM is like a sitting "duck" waiting to be shot, i.e., waiting for some killer and expensive tool.

I believe in you when you say you want "Dynamic Languages", but I want such a thing as generic as the Java itself, as available as Java, but I want it more powerful than Java -- in a sense that you haven't experimented yet. But I doubt it is going to happen, as I said in a couple of previous messages.

There is a catch, though. If you choose the "1" above, it means that the language would need to compete with Java on its own territory, and it would lose -- terribly.

I must admit that I have difficulties trying to understand you. You mean there can never be a really cool language for the JVM, because it will inevitably fail for not being Java?And since there is no point in trying to invent non-cool languages, the JVM is a dead end?

So the only way to make progress is to create a replacement both to Java and the JVM?

If you really think that, I'm starting to see a troll here :-)

But in the same time you are trying to sketch some requirements for future languages. I agree, current languages need lots of improvement. However, I think your point gets missed because you try to say two things simultaneously.

To address the verbosity of Java and its libraries, the new language would need:1- Cool and Open Source IDEs available on all platforms, or2- Easy wrappers to the most common APIs.

Sorry, but this is plain nonsense. A language on the JVM does not need to know anything about Java at all! There is no complexity to address. The JVM is a smallish program that interprets byte codes. Languages can use the Java run-time libraries in the same was as they can use the C runtime libraries. Do you say that these languages need to address the verbosity of C and its libraries? Of course not.

It's difficult to address Java in the general sense to the J2EE people.

I think this is an extremely condescending statement. Do you have evidence for it?

Steve, Unfortunately he sort of does have a point there. Not sure it is well applied though. Anyway. You and I know what Java is. But many, including some of those here, think Java is only J2EE and/or that it is somehow better than J2SE. It is the Enterprise in J2EE that usually gets them confused. I've run into it a few places.

It's difficult to address Java in the general sense to the J2EE people.

I think this is an extremely condescending statement. Do you have evidence for it?

Steve, &nbsp;&nbsp;Unfortunately he sort of does have a point there. Not sure it is well applied though. Anyway. You and I know what Java is. But many, including some of those here, think Java is only J2EE and/or that it is somehow better than J2SE. It is the Enterprise in J2EE that usually gets them confused. I've run into it a few places.Mark

Ok, fair enough. I guess I don't like generalisations. I don't believe there is a single group called 'the J2EE people' who share one view. But I was probably over-reacting and being pedantic.

I don't believe there is a single group called 'the J2EE people' who share one view. But I was probably over-reacting and being pedantic.

I don't either but he wasn't using it like Rolf does.

That would be hard.

Contextually, it was "ok".

I'm not entirely in agreement. I mean, even the EJBers are now talking about POJO persistence and APIs that can be of use in J2SE. It's as if they have started to realise that not all Java runs in app servers. I was trying to be a little generous to the J2EEers.

Matz, author of Ruby, considers that it's not very good to write an OO language on top of another OO language.

Obviously these words have come straight from the lips of God himself. Who are we to question them? ;-)

You could have a good subset of a good Dynamic Language written for the JVM, which is what many of you propose, implicitly. But it would need to move with the JVM changes, maybe supporting only the latest JVM version, because to support anything beyond what is available in the JVM would be close to impossible, because C wouldn't be available.

Amazing how with so few words, you manage to show how little you know about the JVM. If you are worried about changes to the JVM, your worries are over, as it evolves extremely slowly, and its evolution almost never breaks backwards compatibility.

Secondly, regarding the availability of C, it will never be more or less available from Java or Ruby than it is today. In both Java and Ruby, there is no C, but from either you can get to code written in C. Isn't that what you are after? So what does it mean to say "to support anything beyond what is available in the JVM would be close to impossible, because C wouldn't be available"?

Still, the language would need to create its own *easy* wrappers around the most used Java libraries, which would mean two different APIs with two different documentations. It definitely could be done, but it would be an inglorious job.

Yes, but whatever libraries are available to Ruby code outside of the JVM would have to be available within the JVM, for portability reasons (etc.)

The "other" functionality provided by Java wouldn't require special wrappers, as long as it were available (see jRuby).

I think Sun is going to trick you in believing that the Dynamic Languages are coming... just so you won't jump ship.

I think Sun has more important fish to fry. While Ruby may be the center of your small universe, it is as interesting and important a topic to Sun as "Java" is to my cat.

Groovy is very Python/Jython like. Perhaps if Groovy is a standard more people will take it seriously (a problem I found with Jython).

I can't believe you actually said that. Python is like 15 years old and there is a huge amount of mature, stable, useful and in use software built on it. Python may not be an ISO or ANSI or ECMA standard, but it's a de facto standard. I've been using python by using software written in python for ages now, ever since my first redhat 5 installation. Python is definitely taken seriously.

As for Jython I think the only problem it has it's last release date is 2001... It seems that the main man agrees: check out the paper from Jan 2005 on moving jython forward.

This is not a fanboy message. I don't like python for a lot of reasons but that's largely irrelevant to the points above.

And groovy ? It's a hack. I've seen, read about and programmed in quite a few languages, starting with assembly (thru pascal, c, c++, java, python, ruby, eiffel, lua, as2, oberon, scheme, php, etc, etc, etc) latest one being o'caml. I've read code in double that many.I've also written a couple - granted, a simple velocity-style template engine and a "small c". So it's a rather educated assertion my calling groovy a frankensteinian hack. It's a six headed monster with razor thin legs tied to a strong pole (the jvm) that keeps it from collapsing.

The JCP process is a joke. I like James but I think he has an attention span problem. A big one. It might be due to the early pub closing hours in the UK.

Compared to groovy, jython is a hard realtime rocket gasoline pressure regulator for space rockets. And it's taken way more seriously than groovy is.

PHP's sweet spot is pages. Java is components. PHP will take over where there was overkill/impedance mismatch between Java and enterprise content management. And this is most cases. Java resists integration with content management, PHP integrates readily with it.

From content management point of view, page technologies from competing application frameworks(JSP/ASP) are all weak when compared with PHP.

PHP is powerful, embraces pages, embraces content management, is free. That's the threat, not to Java, but to the other scripting frameworks that eventually lose to Java, will have no place to stand.

Zope/Plone is the same ball-of-wax as J2EE/.NET when the real problem of CM is taken into account.

Why hasn't this been noticed by anyone? If J2EE developers were forced to re-skin their own applications on a regular basis (with the CM impedance), they would quickly gain this insight themselves. Their insight on CM would be as clear to them as their insight about trying to do component-based development in a scripting langauge, and so say that the scripting frameworks don't stand a chance.

I don't see why I can't write quick and dirty code in Java. Why do I need a scripting language for that?. I think the problem I see is with the Java development community's use of the language and not the language itself.

There is a growing obsession with writing pattern driven, super generic class hierachies for solving trivial problems at hand. A simple task such as reading from the database, displaying it on the web and saving it has been absracted out ad nauseum by several vendors.

Do I hate what the community is doing? Absolutely not, I totally agree with the abstraction but given this mindset of having Java code always be pattern/framework/abstraction driven, is it really fair to compare it to scripting language development?

Development in scripting languages would become cumbersome too, if the next Python or Ruby developer started thinking in terms of patterns, layers, container driven persistence etc etc instead of stuffing everything in one mammoth file.

I don't think scripting languages can ever be a threat to Java.

What can be a real threat to development in general (i consider it a threat) is the possible trend to run away from abstracted, pattern driven code with the adoption of scripting tools.

Its like we hated puting all the code in a single JSP, so we adopted MVC, now we find MVC and its artifacts cumbersome so we are going to start putting all the code back in a single php file?

I've recently worked and still am working on a fairly large financial application. Java server, hessian for opening services etc.Prototyping and having a nice looking, fully functional web ui xhtml-mobile (for phones and pdas with xhtml browsers) took 1.5 days with php, during which I wrote all the code (css, xhtml and php) in IDEA (not even syntax highlighting for php!). It uses hessianPHP and it runs on an different box than the Java server. And yes, I was faster and easier and generally more pleasant to do it in php than say JSP. The code is cleanly separated from the presentation - to the extent possible using only php (no template engine), i.e. at most loops iterating over session data and outputing stuff.

Besides, PHP does not equal spagetti code in pages _at all_. Trust me on this one. I've seen PHP applications and frameworks used in a lot of small and big projects that are _very smart_ about the way they do things. To give you a hint how smart they have exception handling with stack traces in php4.

I don't see why I can't write quick and dirty code in Java. Why do I need a scripting language for that?. I think the problem I see is with the Java development community's use of the language and not the language itself. There is a growing obsession with writing pattern driven, super generic class hierachies for solving trivial problems at hand. A simple task such as reading from the database, displaying it on the web and saving it has been absracted out ad nauseum by several vendors.

I agree with you: larger projects are best done following "strict disciplines" i.e. creating abstractions and frameworks, but smaller ones may benefit from a "lighter touch".

However, I don't think Java is the best choice for quick and dirty hacking. The reason: it's too verbose.

Some say that in Java easy things are difficult (and difficult things at least possible). Take file handling for example. If you have ever used bash or perl, for example, you know what I'm talking about. File handling in Java is difficult.

Development in scripting languages would become cumbersome too, if the next Python or Ruby developer started thinking in terms of patterns, layers, container driven persistence etc etc instead of stuffing everything in one mammoth file.

Based on this comment, It sounds like you have not worked with Ruby or Python. Ruby and Python are full-fledged OO languages. Python, for example, has packages and classes just like Java.

I like how you stated early (not quoted) that there is no need for a scripting language then you allude to the fact that you use a Model 2 style development. I assume by this that you use JSTL logic tags (with JSTL EL) or Java scriptlets. In either case, you are using something other than pure Java. JSP with JSTL (and JSTL EL) tags and constructs is not much different than having a scripting language (or other custom tags that perform logic). Many in fact consider it a form of scripting. So are you saying that scripting is only okay for HTML templates like JSP?

Do you see the hole in your logic?

Java is a great language, but more importantly it is a great platform. It is the best platform for scripting languages (a.k.a. Dynamic Languages). If Groovy succeeds, it will augment Java well. I had high hopes for Jython, but was mostly let down by its lack of adoption and its lack of growth. (See my earlier comments for more details).

PHP5 (and maybe earlier) can interoperate with Java libraries very easily. I don't think we have an either-or-tool decision here, we have a situation where two tools may open new doors to simpler development.

Scripting languages can simplify development. You can build great foundations and libraries with Java. Together they are better - think UNIX with its scripting glue.

PHP5 (and maybe earlier) can interoperate with Java libraries very easily. I don't think we have an either-or-tool decision here, we have a situation where two tools may open new doors to simpler development.Scripting languages can simplify development. You can build great foundations and libraries with Java. Together they are better - think UNIX with its scripting glue.

I think the problem here is twofold: Firstly, if you are integrating PHP and Java there is yet another feature that needs to be set up and managed. Secondly, I find there is enough difficulty involved in deciding where to place logic in a pure Java web application. I like to have the ability to refactor my code to move things around. Trying to design and possibly even refactor a mixed PHP/Java project is surely going to be troublesome.

There is another point: If you are going to integrate with Java at all, surely it makes sense to use Java throughout. If you really want to do scripting, JSP/JSTL gives you a way of developing in a PHP style yet access to other Java services or classes is seamless and fast. And, the whole application can be packaged as a single .war file.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.