The issue discussed here is the implementation and signature of "map", a trivial function that anybody should be able to understand and implement without a sweat.
Sure, if you OK with your code running magnitudes
slower than the built-in stuff
...
scripting languages force you to use the built-in stuff
These 2 sentences don't compile.
You should also realize that the speed of the JVM has nothing to do with the static-ness of the language. The bytecode is in fact dynamic ... the only instances where certain assumptions where made based on Java (the language) being:
1) classes are immutable and can't be garbage collected unless you destroy the corresponding class loader
2) the method dispatching done cannot be overridden (so when calling a method on an implicit object, you also have to specify the interface where that method is defined) ... but this has nothing to do with the inner-workings of the JVM and is being addressed with the work done on InvokeDynamic
Really, if you're worrying about "scripting" specific behavior sneaking in on you, stealing away precious CPU cycles or RAM bytes, then you should stay away from the JVM.
Seeing that you still don't grok the basics discussed here, this is probably my last answer to you.
You still fail to understand that the `map` (and other methods) are far more flexible in Scala, making them play well with sub-typing and inheritance (and in fact with stuff like `String` and arrays which don't implement any collection methods at all).
With your examlpe above, what result collection type would you get when you map with `Int -> String` over a `BitSet` or with `Char -> Int` over a `String`?
> You should also realize that the speed of the JVM has nothing to do with the static-ness of the language.
You have obviously never seen the mess JRuby and Clojure employ to run on the JVM.
The example above was made by me, on purpose to explain the difference, which I did.
On the JVM - I've implemented dozens of parsers and simple compilers, I did a lot of bytecode manipulation. I know my bytecodes, I know very well the challenges involved.
Your oppinion is based on gospel and the authors of Clojure or JRuby dissagree with you ;)
You should also realize that the speed of the JVM has nothing to do with the static-ness of the language. The bytecode is in fact dynamic ... the only instances where certain assumptions where made based on Java (the language) being:
1) classes are immutable and can't be garbage collected unless you destroy the corresponding class loader
2) the method dispatching done cannot be overridden (so when calling a method on an implicit object, you also have to specify the interface where that method is defined) ... but this has nothing to do with the inner-workings of the JVM and is being addressed with the work done on InvokeDynamic
Really, if you're worrying about "scripting" specific behavior sneaking in on you, stealing away precious CPU cycles or RAM bytes, then you should stay away from the JVM.