Martin Odersky says on this interview that types can be really annoying for small scripts but for the other case, big systems (real production systems) the refactoring that it allows and the reliability of your code are a fair (or small) price to pay:

They are probably less important when programming in the small. Types can be in a spectrum from incredibly useful to extremely annoying. Typically the annoying parts are type definitions that are redundant, which require you to do a lot of (finger) typing. The useful parts are, of course, when types save you from errors, when types give you useful program documentation, when types act as a safety net for safe refactoring.

I could not agree more, if I'm doing a 50~100 lines script I'm probably not using a full IDE and the Java anonymous inner class full syntax will not be generated by my jEdit (or any other text editor), so a friendly idiom for closures are really a differential.

At the same time I'll not need to maintain this script for months or years, or might never read it again, hence the possibility of powerful automated refactoring (that for instance IntelliJ of Eclipse provide) are not a need, like they are and we already take them for granted on regular systems that we deploy to hundreds/thousands of users.

Automated refactorings are the open gates to the easy and encouraged evolution of software code, and statically declared types are their very foundation.

Could the Java Platform be the a major helper in order to help Ruby apps to scale more easily?

Ruby and JRuby still generate a lot of enthusiasm. More and more Ruby programmers are looking at JRuby as their Ruby projects mature — when they move into heavier loads, larger systems, more cores, more processors. Most significantly, as Ruby development branches out into larger enterprises where deployment on Java servers is important, JRuby is seen as the solution.

A less obvious advantage to JRuby is that it may already be a better Ruby implementation. Certainly that's where it's headed — faster, better use of memory, better use of resources. Many Ruby programmers are starting to see these advantages.

So, people are beginning to understand that whether it's based on Java or the standard implementation, JRuby is better at handling resources, better at taking advantage of multi-core processors, and so on. This is the impetus for people to try JRuby, and to stay with it once they've tried it.

It's really sad that most people simply ignore the fact that the Java Virtual Machine supports multiple language for so many years now.

The Java VM is multi language since its conception, as its runs above the called Java bytecodes which is the needed layer of indirection between it's languages and the VM, with the compilers the actors needed to fill in the gap.

Many years before now we could play with so many languages that compiled to the JVM. I hope JRuby and JPython communities keep up with their great work a take advantage of such mature and sophisticated JVMs we have (available for free) nowadays!

Simon Peyton Jones talks about the right measure of success and hence freedom a programing language should have to evolve without the chains of backward compatibility.

As for the second, I don’t know if you know this, but Haskell has a sort of unofficial slogan: avoid success at all costs. I think I mentioned this at a talk I gave about Haskell a few years back and it’s become sort of a little saying. When you become too well known, or too widely used and too successful (and certainly being adopted by Microsoft means such a thing), suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things.

Simon works in the design and implementation of the GHC, which is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.

A 2006 interview with the creator of the popular CVS, short and interesting:

the core concurrency piece of the shell script version (which was brilliant and ahead of its time), ended up being 239 lines of shell script code. My version of it, in C, weighed in at 289 lines of code, and I only recall extending it to handle directories (making CVS recursive was one of the killer feature additions)

CVS would not have been as successful had it not been a key part of the early Open Source movement. I nurtured CVS, part-time, for a couple of years past the first release. Jeff Polk helped me rewrite the internals of CVS during this time - he was a better programmer than I would ever be.

A very interesting interview with Bjarne Stroustrup:

HD Have we placed too much emphasis on architecture?
BS No, at least not the way I would define architecture. On the contrary, there is too little emphasis on architecture and too much poor coding with little understanding of structural principles. I suspect a major problem with architecture is that many programmers have only a vague idea of what makes good code good. Being able to recognize it when you see it is not enough. Having rules for what not to do is not enough. We need articulated prescriptive rules.

HD Do you see a serious shift towards dynamic languages in the near future?
BS Not really. I think people are comparing apples and oranges too often. I don't think we have a choice between static and dynamic languages in general and furthermore I don't think languages cleanly fit into those two categories: most if not all dynamic languages have aspects that are statically determined, and all the major static languages can do things that require run-time determination of the meaning of values. There are fashions, of course, and I can't guess about those, but I think that many real-world language choices are rationally made based on the requirements of an application, an application area, and/or the skills of the available developers. For example, I'd not try to implement a Java runtime in (say) Ruby or express a heavily interactive simulation language as C++ (as opposed to its implementation).

A very interesting point of view of Cay Horstmann published on his interview at SDN:

Horstmann: When I compare blogs about C# and Java technology, I'm struck by the differences in tone. Many C# bloggers talk about the latest goodie that came from the heavens at Redmond and how they might use it. But the Java technology bloggers write about why something is no good and needs to be improved. Now it could be that C# is such a wonderful creation that no one needs to complain. But I don't think so. If it were, more people would use it by choice. Instead, I think that the Java community has a culture of healthy whining.

We have both the will and the means to improve things and do not passively accept what is handed to us. We don't wait for Sun or someone else to fix what doesn't work. We tinker in a thousand projects and build improved libraries, frameworks, and even new languages. The open sourcing of the Java platform will enable it to be viable for years to come.

The strong and active community behind Java has always being one of its fundamental strengths.

Joshua Bloch, a former Sun Engineer (author of Effective Java, JSR 175 spec lead, where Java 5.0 annotations came from) currently working at Google, talks about a obscure bug in a binary search algorithm he has learned during in one of his Ph.D. classes. He points that this bug persisted to exist for two decades :) and says:

The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.

A interview with J. Bloch (text and asf formats) about the new Java 5.0 features are available at The Server Side. One interesting comment on this interview, about Generics, goes something like this:

"proving the type safe system is correct is pretty much rocket science" ;)

Tim Bray wrote a short and interesting post on his first impressions on Ruby.