DISQUS

Have you considered SBT? It's basically what you just wrote, except with some more time in grade. Personally, I use Buildr for my Scala projects. It's not a Scala-based build script specification (it's based on Rake), but it is quite concise and manageable.

I would be curious how you consider other JVM languages or even Python on the JVM (Jython). The main reason you listed for choosing Java over Python is portability and long-term relevance. In order for Java to make it for the next 10 years, the JVM will also need to stick around. If that's the case, then other languages like Jython, JRuby, Groovy and *especially* Scala will be able to run without a hitch. (I say "especially" because Scala's output bytecode is much closer to Java's than the other three languages, meaning that future changes to the JVM intended for Java will affect it less).

WRT the implementation of sum, I would *like* to do it this way (doesn't compile):

type T = { def +[A <% T](o: A): T }
def sum(nums: Iterable[T]) = nums.reduceLeft[T](_+_)

Scala doesn't support self-referencing types (classes are fine, types are not). I'm sure there's some deep theoretical reason why this is, but it does get a little annoying for situations like this one.

I've seen a fair bit of code which over-uses functions like fold and flatMap. Heck, I've even *written* code like that! I think the reason it exists is a lot of people using functional programming in any language (including Scala) are those who learned its precepts under the cruel lash of a more strict language. Think about it, if you learned how to code in Haskell or even Lisp and then tried to learn Scala, you would end up producing some hideously functional code. Now, this isn't as bad as it could be in languages like Java using its sorry-excuse-for-a-lambda, but it is still a problem (if nothing else, because non-trivial Scala is much more verbose than the equivalent Haskell or ML, partially due to the differences in type inference algorithms).

I think that your point is spot on: don't marry yourself to a particular methodology just because it solves *some* problems well (or even worse, just because it's "hip"). Even Scala's standard library adheres to this principle, implementing functional constructs (like everyone's favorite persistent collection: List) using imperative algorithms for efficiency.

While I think that it is *rare* that a trivial computation such as the ones you illustrated can be cleaner imperatively than in the functional style, there do exist many examples of a non-trivial nature for which this holds. The beauty of Scala is that it doesn't restrict you to one or the other, letting you mix and match, getting the best of both worlds. I suppose that sounds like PR, but it really does solve this problem of divergent methodologies quite nicely.

Ruby documentation: http://ruby-doc.org/core/

The problem with benchmarking this sort of thing on JRuby is the platform has significant overhead, both in startup time and invocation cost. Ruby is an almost excessively dynamic language. It lends itself extremely nicely to metaprogramming and other nifty tricks, but this dynamic nature also precludes use of the native JVM call stack for most situations. For this reason, JRuby has quite a bit more overhead associated with a simple call than does Scala or Clojure. Also, JRuby has a fairly large runtime (including JIT) which must be init'd prior to doing anything. Groovy has something similar, but with Scala it's all just part of the JVM. Scala *literally* compiles down to Java-equivalent bytecode, there is no runtime or indirection layer other than the JVM itself.

I think I agree with your central point, that the use of additional languages just to be "trendy" introduces unnecessary overhead and performance costs, but when judiciously applied, this overhead can be acceptably mitigated or even less-costly than the same algorithm handled in the single "main" language.

While I agree that polyglot programming is over-hyped and dangerous, I'm not sure that your reasoning is sound. As a previous commenter pointed out, a lot of the "polyglot languages" being pushed these days already run on the JVM. Some of these languages (such as Scala, Clojure, Groovy, etc) even go so far as to use the same call-stack and internal runtime semantics as Java. For such languages, the intrinsic performance penalty is extremely minimal. Obviously Groovy imposes all the overhead of a dynamic language, but Scala is just as fast as Java (even faster for some operations). Interop between such languages really seems to be the only significant overhead (loading the extra support libs, etc), but because the call stack is shared, "polyglot calls" are really just the same as normal Java method invocations.

Your arguments also make the assumption that developers are jumping into polyglotism blindly without considering the performance implications at all. I don't think this is the case. When I use Ruby for something, I'm well aware that there are much faster (in terms of runtime performance) options. Given the vociferous nature of most language proponents, it's hard *not* to be aware of the performance minutia of modern languages, especially as they compare to old stand-bye languages like Java.

There are a lot of reasons to be wary of polyglot programming, but I don't think performance is one of them.

For the record, the "bug" has been examined and duly considered by the Firefox team. As it turns out, this is actually a problem with the Silverlight detection script shipped by Microsoft. Apparently, the whole thing hinges on a private API with undefined behavior. Naturally, it's annoying that Firefox 3 doesn't support Silverlight, but putting the blame on Mozilla is misleading at best.