Bill Venners is president of Artima Software, Inc. talks about the addition of new features in a language and the challenges of backwards compatibility.
He has the exact point of view I have regarding this issue, programming languages with lots of features still need a good tooling support like the one we have nowadays with the Java platform.

What Scala and every other alternate language for the JVM currently lacks, however, is anywhere near tool support that the Java programming language enjoys.

Here he points the importance of great IDEs with features we can't live without anymore like Refactorings, static code analysis, etc.

The Java language has great refactoring IDEs, static analyzers that look for bugs, code complexity, and code style problems.

And says he thinks tool support is much more valuable than language features.

Nevertheless, the tool support for the Java language is so much greater, I judge it more appropriate to leverage that than to chase fun and productivity by experimenting with a new language.

For this path of using a different language for the JVM to actually become practical, some other language besides Java will need to become mainstream enough to motivate the tool support.

That's precise my point of view when talking about the Java platform, which has enough features and expressiveness that along with all it's ecosystem gives the developer a huge advantage in terms of productivity.

The OLPC will give the kids even a flavour of smalltalk!

We will support five programming environments on the laptop: (1) Python, from which we have built our user interface and our activity model; (2) Javascript for browser-based scripting; (3) Csound, a programmable music and audio environment; (4) Squeak, a version of Smalltalk embedded into a media-rich authoring environment; and (5) Logo. We will also provide some support for Java and Flash.

I shall arise the same, though changed

That's how the Platform Lead for Java SE, Danny Coward, describes the process of incorporating new features in the next major releases of the Java language.

He compares good design principles making us recognize instantaneously different classic car brands even they having changed so much in the last decades. He considers that a good set of core principles are always respected in the new releases of these products and I agree with him.

Have you ever wondered why some cars are instantly recognizable? Seen a new BMW in the last 25 years without twin headlamps? Wondered how an SUV can still look like it's a Porsche? How a Corvette can still convey "Corvette" after over 50 die-hard years?

He says the new Java language features must evolve following its core principles and I personally like this idea.

These are other good points from the article I'd like to highlight:

Innovation for established products is arguably more difficult: You have customers who already like your product who you want to keep.

we need to scan the horizon for ... non-disruptive innovations that have widespread useful consequences

And finally he wisely states: Reading is more important than writing and One language, with the same meaning everywhere.

As much as I liked the article there are some new features he puts under the light that makes me worry, they are:

• Closures, Block Constructs, Method References;
• Operator Overloading;

I really don't think these features should use the classic Java language as a home as I can live pretty well with the static nature of anonymous inner classes and I love to know that [] will be always used on arrays and my plus sign will always add numbers/Strings without my need to investigate it.

I agree with Yakov.

Is Java the primary language that pays my bills today? Yes it is. Are there other languages/technologies I work with? Yes, there are. Do I want to see new language constructs in Java? No, I do not. People propose adding closures to the language. There are some attempts to introduce data binding to Java Beans. I do not think you can teach an old dog new tricks. If you remember, Java has been created as a simple version of C++. Let's keep it as simple as possible.

When I hear about all these additions to Java, I see an aging woman that keeps coming to her doctor for another Botox injection. These doll-looking faces do not trick men anymore. Keep Java simple, let it age gracefully! It’s a very robust platform for enterprise and mobile applications and let’s leave it right there. Fine-tuning of the JVM is fine, but I do not need new language features. I'd rather use some other modern languages that can be easily integrated with Java EE.

Sun Microsystems has excellent engineers who can craft a brand new language in a year or so. May be creating a new language is better than trying to add patches to Java here, there and everywhere? I'd rather see a new cool and light-weight language from Sun, especially for the GUI development that can compete with offerings from Microsoft (WPF and WPF/E) and Adobe (Flex and Apollo).

From: TSS Asks: Why resist change to Java?

From Artima, stil gotta read it and write my thoughts, no time for this now (changing from one company to another, looots of stuff to do ;)

Comparing Inner Class/Closure Proposals

There are at least 4 inner class/closure proposals for Java 7 and it is hard to compare them because they use different terms and different syntax for similar concepts. This post makes the comparison easier by separating concerns.

In addition to Bruck Eckel and Guy Steele, now Brian Goetz talks on the Sun Developer Network: "Writing Better Code: A Conversation With Sun Microsystems Technology Evangelist Brian Goetz".

I try to convince them that by relinquishing some control, they'll get huge productivity and reliability benefits -- and maybe even better performance as well. Some programmers see the trade-off and think it's great, while others resist it and code Java programs as if they were coding in C, thereby getting the benefits of neither. The Java language is not just a syntax: There's a design philosophy that goes with managed languages. To get the benefit of Java programming, you have to understand that you are not just programming in C with a different syntax.

To collaborate to my last post: "Thinking" vs. "Typing" in Programming Languages.

It's quite common to meet software developers who actually think that the difference between 2 programming languages are only their syntax.

My first contact with a opposite opinion, strongly firmed on good arguments and examples, was reading [Thinking in Java] in the third year of my graduation course. As the name says already, the book is about not only java syntax and vocabulary but with a paramount emphasis on the Usage of Java, the unofficial idioms used by its community founders.

In my years of software development unfortunately I've came to know that most developers simply ignore this, and try to code in Java like they do in C++, or in Python like they do in Java, etc.

Not only people ignore this but when you talk to then about the need of studying how to "Think" in some language they simply don't value your advice. Well, on time, they will know that, but till then much code will be oddly written and that's what motivates this post.

To my surprise today, while waiting my light-speed machine to boot, I was reading the foreword of [Effective Java, Joshua Bloch] written by Guy Steele (yeah, the LISP guy ;). In this foreword Steele wisely describes this very problem of most books focusing only on Grammar and Vocabulary and *not* Usage and shows a good parallel with the learning of spoken languages.

It was very pleasant to see this flag raised not only by Bruce Eckel (author of the best Java book Thinking in Java) but also by another great computer scientist like Guy Steele.

Now if you don't agree with me, the reputation of both above authors might be a stronger influence you to give this idea some thinking ;)

When learning a new language look for the source code of a well established project, the language syntax and APIs will also be there and with a good change alongside with the good practices.

By the way, [Effective Java] it's just about Java good idioms.

I've just made a small Ruby script to download more than 500 zip files from a Brazilian topography site. The site display the DEM^[1] files sliced in small rectangles for each state, one download page for each one. But there's no single file containing all DEMs from all states, and as you can imagine, it would be a sin to a programmer manually download 503 different files, mouse clicking link by link :)

To each state of Brazil the site displays a web page containing a image map of the rectangular areas. So my first option was to view the HTML source, extract the image map declaration and make a awk script to generate several wget commands. The strategy would work pretty well if Brazil had not 27 states ;)

So I've managed to do some use of the casual reading I make at my PDA of the Programming Ruby book. With less than a hour the script copied bellow was made (credits goes to the good examples of the book):

   1:require 'net/http'
   2:
   3:@h = Net::HTTP.new('www.relevobr.cnpm.embrapa.br', 80)
   4:
   5:def forEachLine(pattern, page) 
   6:    resp, data = @h.get(page, nil)
   7:    if resp.message == "OK"
   8:        data.scan(pattern) { |x|
   9:            yield x
  10:        }
  11:    else 
  12:        puts "could not download #{page}"
  13:    end
  14:end
  15:
  16:wgets = []
  17:
  18:forEachLine(/area shape.*href="(.*)" alt.*"/, '/download/') { |x|
  19:    stateReq = "/download/#{x}"
  20:    dirPath = stateReq[0..-7] #example: getting the /download/ms/ from /download/ms/ms.htm
  21:    forEachLine(/area shape="rect".*href="(.*)" title.*"/, stateReq) { |j|
  22:        fileName = "#{j}"[0..-4];
  23:        wgets << "wget http://www.relevobr.cnpm.embrapa.br#{dirPath}#{fileName}zip"
  24:    }                          
  25:}
  26:
  27:for wget in wgets.uniq!
  28:    puts wget
  29:end
  30:

It was really nice to use Ruby features like code Blocks, regular expression statements, iterators, string slicing, etc. All those features that fit so nice in small hacking scripts ;) And I'm not saying Ruby is only well suitable for that.

Just one observation is that the script doesn't actually download the files, in a good Unix philosophy it delegates this task to another small program that only does that, the good old wget. In fact it only outputs the wget statements that I redirect to a bash script file.

The script was generated and executed during the night, now I have several megabytes to play with :)

I just ran into this article of Wikipedia explaining the concept of a programming paradigm. I was surprised to find this classification of so many different kinds!

I'm not telling that this Wikipedia classification is the right one, but it certainly must have its value. Among all those paradigms I knew only 3, which are procedural, functional and Object Oriented. One I found interesting was the Constraint programming paradigm to which there is a API written in Java, called Choco.

The most exotic multi-paradigm programming language I'm aware is Oz, which according to Wikipedia supports 8 of them!

Well, a promise I've made to myself is to someday to give a try in the functional programming style (with Haskell maybe).