Lang.NET 2006, Day 3
Okay, so it isn't really the third day - that was back on Wednesday. But I was completely wiped out that evening and Thursday was traveling back to Austin. But now I can finally give my little summary of the events.
As usual, I'll put most of this "below the line" since it's of limited use to someone who wants to know how to program .NET from within LabVIEW. Of course, anyone can read it.
Also, I'll be pretty brief on the Second Life part because I want to do a separate post on that - it's the only presentation during the conference that left me with cold chills...
Second Life
So, the day started off with a presentation by the team from Second Life. As I said, I'll go into much more detail on a separate post about them, but to summarize - they are a massive online...existence. They are not a game, but a 3d animated community. The interesting point about them, in the .NET sense, is their move to .NET from a proprietary scripting engine.
Inside Second Life, you can create scripts to animate or automate events in the game. These scripts are key to the content creation and thus there are "a zillion" of them running around on the servers. In addition, as your avatar (your virtual, visual representation in the world) moves around the world, it may move from one backend server to another. This means the script needs to be packaged up and moved to another computer altogether.
Due to a variety of reasons, mainly centered around performance, they decided to replace their own script engine with Mono (the open-source .NET implementation). The technical challenges they faced were amazing, as is their solution.
For example, consider taking a running bit of .NET code, stopping it, capturing all of the data associated with it (on the stack, in the heap) and moving to another computer! Then inflating it back and letting it run right where you stopped it - without the code ever realizing what happened. Amazing work - and results. It isn't released yet (we were shown a demo of the current alpha), but they're seeing performance gains of 50-150x! Just goes to show the power of compiled code over interpreted (anyone remember going from LabVIEW 1.x to 2.x, where we went from interpreted to compiled?)
F#
The F# language is an implementation of a (mostly) functional language on the .NET platform. For those that are unaware, most of text programming languages today can be broken into two primary areas: functional (F#, oCaml, Haskell, etc.) and imperative (C/C++, C#, etc.). Read the wiki links I've given you for the best definition of them - I can't really improve on that.
Like most "(mostly) functional" languages today, F# is not a pure functional language, but does provide many constructs to allow you to do some interesting things - and in a concurrent-safe manner if you do it right :)
In Don's talk this time, the focus was more on the implicit typing scheme the language used and the benefits you gain from that. Similar to the VB.NET and IronPython talks, the fact that you don't need to explicitly define a type for every variable allows for a simpler code representation of what you are thinking. However, since F# is strongly typed, the compiler can infer the correct type you would have typed, and so you get the best of both worlds.
An interesting tid-bit is that the guys at MS Research developed the algorithm for the XBox Live! ranking system in F# - and I believe he said that it's being used now in production.
Phoenix
The Phoenix project at Microsoft is a new compiler backend technology that is to be the basis of future Microsoft compilers - such as C++ and C#. A funny thing about it is that it can create both native and managed (MSIL) code, but is itself written in C#. Since the C# compiler was originally written in C++, you gotta love the irony.
The presentation gave the overview of the technology as well as a demonstration of it's modular architecture. He also demonstrated a visualizer that showed what was happening to the code after each successive passes of the compiler - a wonderful insight for those that have worked with compilers before. I'm not sure how the final version will be surfaced in VS.NET, but I've gotta say I'm very interested in seeing what we can do with it.
As I said, this isn't a shipping product yet - although VS.NET will ship with it in an upcoming release (didn't catch whether it would be the next "Orcas" release, or after), but he did say it currently compiles the entire Windows Vista code base every night.
Ruby, Part II
On the first day, we had a presentation on porting Ruby to be a .NET language - actually generating .NET assemblies. This time we heard from John Lam on getting Ruby to talk to .NET. It was a fascinating talk for me as he faced the same issues we've faced getting LabVIEW to talk to .NET. However, while we do it for love of country, a sense of honor, and perhaps a paycheck, he did it so that he could write a flashcard program for his 3 year old son! It was, as he said, a very clever way of explaining how locking himself away in his den night after night was actually "family time". I wonder if his wife actually bought that?
Javascript - A different perspective
In this talk, Danny Thorpe from Microsoft's developer labs at Live talked about web programming. The interesting aspect of the talk was the completely different look at Javascript. Why the interest? Well, as Danny said, his job is somewhat unusual at Microsoft - he's responsible for getting Live working on every platform possible - not just Windows. Thus, with browsers as the largest deployed application in history, that's his OS to worry about.
The different perspective was to look at Javascript as the assembly language of this "web OS". He had a good slide showing the similarities between the two, but I'll sum it up as "the most fundamental language that runs across the board on the platform, and you would be fired if you tried to write a large application in it".
Solution? Create a higher level language whose compiler emits Javascript. He pointed out a couple of such projects, such as Script# and the Google Web Toolkit, but that there is still a lot of work to be done. For example, the Javascript language itself doesn't allow communication between different IFRAME's. This is a good security wall, but one that should have a safe way to breach if you're writing both sides.
PowerShell
What can I say - a presentation on the most amazing shell technology I've ever seen? Yep - I love that ol' Monad...I mean "tumpt tada tummmmm" PowerShell.
I'm not sure I need to go into a lot of detail here as I've written about it before. So, let me give the summary
- Works on XP, 2003 and Vista
- Access to all sorts of features of Windows with a simple API
- Use objects and properties, not parse text
- Call any .NET routine directly from your script
So, why not use it?
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83424ed4953ef00d83509473053ef
Listed below are links to weblogs that reference Lang.NET 2006, Day 3:
Verify your Comment
Previewing your Comment
This is only a preview. Your comment has not yet been posted.
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
Comments