08.02.2006 09:40:32 PM (Last Update: 08.30.2007 07:08:10 PM)
The 3rd and last day of Lang.NET 2006 started with Cory Ondrejka talking about Second Life (SL). SL is a online virtual world. He made the interesting point how there's huge "digital" money and resources (basically a digital economy) based around these kinds of games. SL is not a game; it's virtual real-estate, where users get tools to create their world. SL also doesn't copyright user's contributions and creations, which Ondrejka said is different than other online games. SL seems huge - as he talks I'm getting really interesting in SL. He mentioned a game called Tringo (a mix of Tetris and Bingo) and it swept the SL world - it's actually going to become a game show in Great Britian. He made the point that, yeah, the web is decentralized and distributed, yada, yada, yada...but it's mostly text. Doing 3D, video, etc. is harder. But SL has lots of people who actually contribute material to the world - about 2/3rds of their members do, which is a lot higher than other mediums (web, Sims, etc.). A world with freedom, though, has unanticipated consequences (e.g. some people made aliens to abduct other avatars, and even "worse" consequences). Their user adoption is 50/50 men/women, which is unheard of in tech/geeky tools. (It's funny - as he talks people are going to the SL web site and looking at what SL is all about, but since Microsoft blocks the ports no one could actually try it duing the talk...which was probably a good thing anyway!). It's amazing, too - people are using SL to simulate real-world issues ("what's the most efficient way to organize material in my warehouse?"). SL is also helping people who have had strokes to help them recover from their stroke. Ondrejka then moved into the "how" of SL - specifically, how are objects and "things" created and used in SL? He also covered how their scripting environment must be safe and massively distributed (sounded a lot like continuations). The SL world is just phenominal - I'm continually amazed at what is in SL. He also introducted the term "ass-slow" (it's a techie thing). He was very honest about the scripting language they created (LSL) - it's slow, inconsistent, and very little "official" documentation. Jim Purbrick took over at this point, and he focused on why they've looked at the CLI and Mono for their scripting engine. By using the CLI, any language could (theoretically) be used. He talked about the technical issues they've run into, and the hacks they did to go around them. One was microthreading, which allowed SL to pull scripts from one processor to another via stack serialization. Another was AppDomain scavenging, which got around the issue of assembly unloading by loading the scripts in a small set of AppDomains. They basically watch how many dead scripts are in the domain, move live scripts in another domain, and kill the "dead" domain. Since they have microthreading and stack preservation this is easy for them to do). Their third "hack" addresses resource allocation and "zombie" or DDOS attacks - they call it "subverting the profiler". They hook the Profiling API and watch what the script is doing to prevent huge memory allocations or repeated HTTP calls. Overall, these hacks "mostly work", but there are room for improvements (mobile Mono microthreads, GC-supported memory usage queries, and explicit assembly unloading). He was clear that their "hacks" do not require a custom version of Mono, which means that what they're doing could also be done above Microsoft's version of the CLR. He ended with a demonstration of SL using Mono, which was absolutely phenominal. Even though this talk was 90 minutes long, it went by really fast - this was by far one of the most interesting talks of the entire symposium.
Next up was Don Syme. His talk was entitled, "Type-Safe, Scalable, Efficient Scripting on .NET and Beyond", but during the breakfast people were guessing that it would be on F#. I was really looking forward to hearing Syme speak - F# is a powerful mystery to me and I was hoping watching Syme in person would clear up some of my questions. Syme said F# is designed to be functional and OO, allowing developers to choose what they want to when it's necessary. Syme talked about how F# tries to merge all sorts of language features and how hard it is to do that. F# is primarily targeted to combine ideas from Lisp, ML, Scheme and Haskell in the context of .NET - it's functional, math-oriented, and scalable. He did a bunch of demos showing how F# works (in Visual Studio!). He showed how F# could crawl RSS feeds and do complex 3D manipulations via DirectX. The DirectX demo reminded me a lot of Mathematica or MathCAD (from my college days). He showed how F# code converted to C# gives all sorts of FxCop errors. F# also allows mutable data (as data is by default immutable). He went through a case study of gamer ranking for XBoxLive (TrueSkill). Amazingly, the code is 100 lines long. He discussed the OO programming model in F# ("classes only get used when necessary in F#"). He showed another case study on packet mining - 4 TB of packet information to study real-world network usage. The F# code base was 2000 lines of code, which reads 80,000 packets/sec. He showed that F# already supports LINQ. Syme ended by saying that combining all sorts of language features (succinct, safe, interoperable, etc.) are hard to tie together, but F# is getting there - "it's the combination that counts". Syme's talk was a bit jumpy, but F# definitely seems like an interesting language to investigate in the .NET space.
Andy Ayers was next - he talked about Phoenix. This was another talk I was looking forward to. When I went to Compiler Lab 2006 I got sick the day the Phoenix team came to talk and I really wanted to see what was behind Phoenix. My wife called me right at the start of Ayers's talk so I could hear Hayden say "dad-dy!" so I missed the first 10 minutes (but it was worth it!). Ayers said it was ironic to write a compiler that will write native code, but Phoenix is managed code. Phoenix seems like a whole suite of tools based on compilation and the features that are usually tied to compilation (ASTs, profilers, etc.). He showed an example compiling a C++ program, and by adding a plug-in during the compilation process a program showed what happened during compilation phases. He demonstrated how the C++ compilation can be retargetable from native compilation to CLR via a simple "-clr" command-line switch. He showed how you can write a plug-in to add a compilation phase to detect uninitialized variables. He demo-ed the Phoenix PE Explorer, which is kind of a knock-off of ILDasm and Reflector, but it's for any PE file, managed or unmanaged. Furthermore, he used his plug-in from the compiler in Phoenix PE Explorer, which was fascinating to see. Also, he showed how the Explorer can be used to inject code (like tracing) - very AOP-ish. I could've sworn I saw a "Miracle" phase during mtrace, but I could be wrong. Ayers said that the team is releasing RDKs every 6 months, and approx. 15 universities are using it. Phoenix is also compiling Vista (wow!).
After lunch, John Lam was up, talking about his work getting Ruby work with (not on!) the CLR. Lam said he's all about being pragmatic and simple, which is what brings him to Ruby - "it's a language that just let's you get things done". He then dove into how he gets Ruby to work on (!) the CLR, which is done via a bunch of dynamic shim methods. He showed Ruby examples using ArrayLists, event handlers, and interfaces and casting. Lam said that to help him with work context switches, he built a DSL in Ruby to make it easier to come back to his work after a month of doing other things (like paying the mortgage). He showed how Ruby idioms (like collect on a collection) work. Lam said that generic support is limited, but it's there. He showed that developers can hack the Ruby code with C# code to get around certain limitations in his implementation (nullable types are currently not in RubyCLR, char types, and method overloading). He dove into WPF and how RubyCLR makes it very easy to traverse the XAML tree.
Danny Thorpe followed Lam - his topic was "Paradoxes in Web Application Development". He said upfront that the development tools for web applications are "abysmal", which was echoed many times throughout the symposium. He showed an way to use VirtualEarth to find a specific site and the code necessary to do that. He dove into JavaScript and its strengths (ubiquity, easy accessibiliyty, easy programming environment) and weaknesses (scalability, symbol "stomping", no concurrency). A key point he made is that JavaScript is not concurrent; all it can do is deferred execution. He said there's a paradox: JavaScript is everywhere, but it's universally maligned. He then made the point that JavaScript is very similar to assembly language. He then said, why not view JavaScript as an assembly language and have higher-level languages "compile down" to JavaScript (Script# and GWT are examples of this), or compile IL binaries down to JavaScript? Thorpe then changed his talked to client-side communication, which is usually done client-server, rather than object-object. This gives rise to other issues, such as domain communication restricitions and tag editing quicksand. He said what is needed is "client-side inter-element messaging," but this has to be secure (think IFrames). His hope is that these issues will be addressed in the future, but he really didn't have any strong answers to solve his questions.
The next hour was devoted to a visit to the Microsoft store, with a one-hour open Q&A session followed. I bought a couple of things (a backpack and a golf shirt) and by the time I got back the Q&A session was just a bunch of people talking to each other in small groups.
The last talk of the symposium was devoted to Bruce Payette, who talked about PowerShell. Bruce's talk at Compiler Lab 2006...wasn't the best talk I've ever seen, but his talk this time was much better. He said that traditionally cmd.exe really, really sucks compared to "the other guys". PowerShell was created to fix that situation. He said, "the average length of a PowerShell script is 80 characters". He mentioned on key design rule (among others): "innovate as little as possible", which I thought was very cool to admit. He showed that PowerShell is much more than the parser; there's a whole bunch of set of APIs underneath the scenes to get it all to work. He demonstrated how you can create your own cmdlets that can plug into PowerShell. He also spent time on the type system - "PowerShell is type-promiscuous". He made a clear point that PowerShell scripts are not file-associated by default. He then went through a number of PowerShell scripts, including creating a WinForms application with PowerShell (!). He also had a nice WMI example, which is a lot simpler than what it would take in VBScript. Payette also mentioned that you can do inline IL "if you're demented". He also quickly demo-ed MMC 3.0, which will allow you to write managed cmdlets, which looked very interesting.
Comments
# Mr, from John Cargill at 08.16.2006 11:05:49 AM
# Google??, from Google?? at 05.25.2007 12:12:31 PM
Printer-Friendly Version