Been following some of the discussion around Action Script
3 on the tweetosphere. Here are three implementations of the
same model from Joa Ebert (he works on a fabulous Flash
product for doing music that I absolutely love).

Lately a lot of discussion had the ActionScript language as
its focus. People start complaining about complex language
features but I think they are great because the end user will
benefit from that. Yesterday evening I had my very first test
with Silverlight — and I am really impressed.

It took me a short amount of time to port the strange
attractor to Silverlight. I agree that this is may be not a
fair comparison because I know C# already but have a look at
the source code. I make heavy use of type inference and the
Matrix4x4 class has the plus, multiply and array-index
operator overloaded. The code is more readable. And besides:
it executes really fast. Faster than my heavily optimized
ActionScript version. Imagine I would write var bleh = 1.0 in
ActionScript. Framerate would drop to something like zero. But
this is sad since there is no reason for me to write var bleh:
Number = 1.0. A modern compiler should be able to figure this
out. haXe can do it, C# can do it, OCaml can do it and lots of
others as well.

Remember: This was my first time using Silverlight. To
achieve the same result with Flash you have to be kind of an
expert in strange player and language “features”. Now tell me
again that the end user will not benefit.

C# 4.0
introduces the
dynamic type into the language. The language will ship
in Visual Studio 2010.

Once a variable is declared as having
type dynamic, operations on these value are not
done or verified at compile time, but instead happen entirely
at runtime.

Marek has been working on Mono's C# 4 implementation and it
is coming along nicely. Zoltan wrote a small "PInvoke"
dynamic class using Mono's C# compiler that allows you to call
C library methods like this:

In this case "printf" is resolved at runtime to be a
method in the "libc" library. This is similar to Python's
ctype library in about 70 lines of C# leveraging LINQ
Expression, the Dynamic Language Runtime and C#'s dynamic:

Mono's C# 4 compiler so far implements optional parameters,
named parameters, has support for the new covariant and
contravariant specifiers and the dynamic keyword
is evolving very quickly (as shown by the example above).

If you want to test drive Mono's C# 4.0 compiler, you need
Mono from Git
and you must pass the "--enable-profile4=yes" argument. Once
you do this, the new compiler will be installed
as dmcs on your system.

The frequently
asked questions on the web site talks about performance
(it is about 5 times slower than native code, but still, it
can do 1.5 million selects per second, 300k inserts per second).

Still, not bad for a line-by-line port; Folks on the
#mono channel on irc.gnome.org a couple of days ago were
commenting on the possible ways of tuning it up by not forcing
the C way where the C# way would work just fine.

The potential for this library is huge. It could be used
for ASP.NET servers running in medium trust mode, or it could
be used by Silverlight applications.

It seems like Tim Anderson is attempting to remove all the
P/Invokes from it to make it run on Silverlight (the P/Invokes
are mostly used for doing file-level locking; Again part of
the line-by-line history of it).

We have reached feature completion status for
our MonoTouch
project and we are looking for some adventurous iPhone
developers that might be interested in trying out Mono for the
iPhone and the MonoTouch APIs (A C# API for building Cocoa
applications).

We are doing a closed preview to gather feedback on
MonoTouch, if you would like to be part of this preview/beta,
please fill
out the signup form.

We have reached feature completion status for
our MonoTouch
project and we are looking for some adventurous iPhone
developers that might be interested in trying out Mono for the
iPhone and the MonoTouch APIs (A C# API for building Cocoa
applications).

We are doing a closed preview to gather feedback on
MonoTouch, if you would like to be part of this preview/beta,
please fill
out the signup form.

On
his blog
post he looks at both the micro benchmarks and overall
benchmarks. The summarized results:

Antonio comment:

IronRuby went from being much slower than Ruby MRI to
considerably faster across nearly all the tests. That’s major
progress for sure, and the team behind the project deserves
mad props for it.

One final warning before we get too excited here. IronRuby is
not faster than Ruby 1.9.1 at this stage. Don’t let that first
chart mislead you. While it’s faster in certain tests, it’s
also slower is many others. Currently, it’s situated between
Ruby 1.8.6 and Ruby 1.9.1, but much closer to the latter. The
reason why this chart is misleading is that it doesn’t take
into account any tests that timed out, and several of such
timeouts were caused by IronRuby (more than those caused by
Ruby 1.9.1). If you were to add, say, 300 seconds to the
total, for each timeout for the two implementations, you’d
quickly see that Ruby 1.9.1 still has the edge. The second
chart that compares macro-benchmarks does a better job at
realistically showing how IronRuby sits between Ruby 1.8.6 and
Ruby 1.9.1 from a performance standpoint. If you were to plot
every single benchmark on a chart, you’d find a similar
outcomes for a large percentage of the tests.

Whether it’s faster than Ruby 1.9 or not, now that good
performances are staring to show up, it’s easier to see
IronRuby delivering on it’s goal of becoming the main
implementation choice for those who both develop and deploy on
Windows. This, paired with the .NET and possible Visual Studio
integration, the great tools available to .NET developers, and
the ability to execute Ruby code in the browser client-side
thanks to projects like Silverlight/Moonlight and Gestalt,
make the project all the more interesting.