And for clarity: the other ones aren't function definitions, they also build a new list, like your example. The examples are meant to be run in a REPL and that's why they don't send to stdout, although it will be just another function application in most cases (but your example works in beanshell, the stand-alone java quasi-REPL, so we're ok). I think all of them can be considered a full-program in those languages: as a stand-alone chunk of code that can be compiled/interpreted and will produce an executable output, that is. And, yes, the autoboxing was the only reason I chose generics, but I tried for it to be concise, given my limited knowledge of java; the max-verbose mode would have used a Runnable or something evil to simulate a higher order function.
My experience with all the languages in your sampler is that their runtime performance usually lags the Java on the JVM for general purpose programming. This is not an argument not to use them - I would prefer many of them in certain use cases. But if I want a managed runtime, and have some performance critical code that I am OK with being written in an imperative language, it is hard to beat the performance of simple Java on the JVM. There has been so much tuning to Hotspot over the last decade. That's been my experience anyways.
// Learn more about F# at http://fsharp.net
open System
let consume x = ()
let start = System.Environment.TickCount
Seq.init 100000 id
|> Seq.iter (fun x -> [0..4] |> List.filter (fun y -> (y % 2) = 0) |> consume )
let endTime = System.Environment.TickCount
printfn "%f milliseconds" (TimeSpan.FromTicks(int64(endTime - start)).TotalMilliseconds)
Output: 0.014100 milliseconds
Press any key to continue . . .
I'm sure if I added some java line noise I could get it up to 6 milliseconds. Too bad I didn't need a calendar class to figure out how to get from ticks to milliseconds. It's also really unfortunate that System.Environment.TickCount compiles down to a single assembly instruction. I was really hoping to use a factory pattern in there somewhere. Maybe some IOC containers. What good is a language if you can't write half your code in XML.First off, the resolution of TickCount is not less than 500 milliseconds. Are you sure you are actually timing it right? Maybe you should have used DateTime.Ticks which has a higher resolution. (seriously - I think you need to check your code)
But in any case, let's say your test is actually valid. You mentioned "Java line noise" - not really a real explanation for the difference.
So let me guess for you - maybe your F# runtime knows the function is pure and idempotent, and after running it once it probably just cached the output. So your run doesn't actually execute the filter across the list for every iteration, whereas my Java code did.
I could rewrite my Java code to return the same array over and over after it has been computed once, but it sure won't look as clean as a functional language like F#. I grant you that, and that's one of the reasons I prefer functional languages to Java.
Next time maybe put a little more thought into the response if you actually really have no idea why your program said "0.014100 milliseconds".
// Learn more about F# at http://fsharp.net
open System
let consume x = ()
let start = System.Environment.TickCount
let arr = [| 1..4 |]
for i = 1 to 100000 do
arr
|> Array.filter (fun y -> (y % 2) = 0)
|> consume
let endTime = System.Environment.TickCount
printf "%d milliseconds" (endTime - start)I do hope to learn more about F#, I am hearing good things about it.
Great article about how F# can approach the speed of C with some fancy inlining.
1) The chunk of Java code shows a complete program - the others show function definitions 2) The Java is written purposely to be as verbose as possible 3) The Java sends it's output to stdout, unlike the others 4) The Java code is needlessly written using generics
Things the comparison ignores: 1) The Java code is more toolable than the others 2) The Java code will outperform most of the other examples once it has been subject to Hotspot
Here's a more fair comparison, at the function level to level the playing field (and only one import needed: java.util.*):
Here's why I absolutely do heart Java:I just ran this 100,000 times in 6 milliseconds on a Core i7 920 (2.67 GHz). And I scanned it with Findbugs, and PMD, and a security vulnerability tool. And I refactored it in my IDE with crazy IntelliJ foo-jitsu. And it's more strongly typed. And it's runtime memory model is safer.