> Having seen a fluent southern brazilian portuguese speaker effectively
> navigate the baja peninsula, I know you're overstating your case.

I don't think so. I live in France, in a region with many Spanish immigrants. The French idiomatic expression for "Massacre the French language" is "To speak French like a Spanish cow". In other words, speaking Spanish loudly with a bit of French vocab doesn't cut it, at all.

There's a huge difference between "navigating through" a country and engaging with it. I'm sure your anecdote is true. I'm also sure that fluent Portuguese is of very little use if you want to fill in government forms or even understand the news on the radio. (We have a lot of Portuguese migrant workers here.) I'm reminded of an observation by a colleague working with international youth teams that a Swiss German who says he doesn't speak a language probably knows it better than an American who says he is fluent.

> but that doesn't mean that working in one language and (more importantly)
> understanding the descripting mechanics of it won't dramatically
> help you with another.

Of course! People who master two natural languages pick up other languages much quicker. But the key is "master". Knowing how to order a beer in ten languages doesn't equip you to do anything other than order beer. And knowing how to put a button on a screen in ten programming languages isn't very useful either.

I'm sure that experience of Perl, Lisp, assembler and other languages helped me to pick up C++ faster than would otherwise have been the case. But the differences matter as much as the similarities, and to get the most out of a language you need to embrace rather than work around those differences.

For example, nothing in any other OO language I have used prepared me for what you have to do to get a container with a superclass type in C++, or for the fact that the compiler will happily accept code that is going to throw away all the subclass functionality. I could have worked around that in various ways, but I think finding out what was really happening made me a better C++ programmer.

I can do lookup tables using STL maps in C++, and then my C++ feels just like Perl hash tables. But I'm realising there's a good reason that C programmers use enums in some places. And so on.

> Once you know a paradigm, picking up a new language under that paradigm will
> be just "yet another language", and you can learn one in a week (or 7 in 7
> weeks). Of course, it will take more time to actually become fluent in language
> specific idioms, standard libraries etc, but those are not rocket science either.

I know people who take the same approach to natural language. After all, Spanish and Italian are very very similar, aren't they? The reality with natural languages is that "all languages are the same" thinking enables you to abuse several cultures without actually understanding any of them.

And I think that to a large extent the same thing goes for programming languages. For example, if one of your "paradigms" is "object-oriented", does learning Smalltalk really prepare you for making best use of OO in Java or C++? Or vice versa? The inventor of Smalltalk and OO certainly doesn't think so.

I spent some time a while back trying to explain Scala to a Java programmer. His response was "It's just like Java." Well, Scala *is* just like Java, as long as you ignore the huge and central features that are not like Java. When I started to show him those features, generally in a "replace a page of code with one line" sense, his response was "I don't like it", and that was the end of the conversation. That, in practice, is what "learn 7 languages in 7 weeks" looks like.

My defining experience in this context was observing a government contractor whose preferred language was FORTRAN, who was told he had to code in Lisp. I would not previously have believed that it was possible to write Lisp as if it was FORTRAN, but that contractor proved me wrong. And, to be fair, I find that I have to make a conscious effort not to write C++ as if it is Lisp, eg "everything on the stack and screw the efficiency".

"7 languages in 7 weeks" only works if you stick to programming with the features that can be found or kludged in just about every language. Nowadays that's going to mean procedural code with loads of variables and a bit of OO for accessing libraries. It works, but it's a recipe for terrible, terrible code. But, hey, it will be equally terrible in 7 different languages!

I'm holding out for Quantum Google, which displays instantly every single web page that does and could ever exist. That way I'll never need to search for anything ever again!

> Interpreted languages, such as Perl, Python, Lua, Ruby

I'm not sure about the others, but Perl isn't an interpreted language. The script is compiled, and then the compiled code is executed. That's not a million miles from a JIT compiler.

> is trendy at this moment

Maybe I missed somethng, but wasn't Perl running half the Internet before Java was a twinkle in Gosling's eye? There are many things to be said about Perl, but "new-fangled" isn't one of them.

> It is unthinkable for a higher education course to waste both the teacher's and student's time doing vocational training

Right, but why is that an argument for Java? You can teach Java as a way to tick CV boxes, and you can teach other languages as a way to really understand programming.

> If a course is based on a technology which doesn't have a stable basis and which is likely to drastically change due to a project leader's whims.

You're saying that the Perl community rushed into Perl6? Or maybe that a decade-long upgrade cycle for C++ standards is too rapid? And that the future JVM roadmap as of today is very clear to you?

> Then there is the issue of control. If a language is not standardized then you don't have any assurance that your code will run at all in the future.

Not sure why this is an issue for education but, in any case, backwards compatibility in Perl is legendarily good. There are plenty of production sites running Perl code that is decades old.

I can see an argument for teaching CS using C or assembler (because they force you to understand what a computer does under the hood). I can see an argument for teaching CS using functional languages such as Haskell. I can see an argument for using Perl because it's possible to demonstrate a much wider range of programming styles than with Java. ("Whatever the question, the solution is an object" doesn't seem to me to be ideal in an educational context.)

But I can't see offhand why Java is different in kind to any of the other languages in your list as far as suitability for education goes. It's not a very pure implementation of OO programming, it doesn't teach you anything about memory management. If you are not careful, you give students the impression that it's impossible to write code without an IDE. Java has its merits, its fans and its detractors. But it's not self-evidently The One Right Language to use to teach CS.

A somewhat sweeping statement. Most Christian denominations worldwide take a fairly "modern" view on contraception. And you have to wonder about the influence of the Vatiican when highly Catholic Italy has a catastophically low birth rate.

Atheism has only had about a century in which to wield political power, but it has caught up fast on the genocide front.

"I've never got it when it comes to SQL databases. It's like, why? Just give me a hash table and a shitload of RAM and I'm happy."

Agreed. But at least serving over HTTP is something you can reasonably assess on the basis of single requests (because it is stateless). I'm not quite sure what stateless emotion would mean.

On another skim through TFA, it turns out that the system doesn't read anything - it seems to be based on a set of carefully crafted graphs representing the fables. It's hard not to feel that producing the graphs is 90+% of the task.

So it's more like setting up a webserver to return a page of HTML in response to a URL, and then saying

"Web server understands requests for news (once that natural language request has been turned into a URL)"