Some d00d named Leppie has written a Lisp for the DLR [via Jason Bock]

Silverlight steadfastly refuses to install on my development Tablet PC or in my "Orcas Beta" Virtual PC. Those are the only two machines on which I'll put an under-development CLR, since experience has shown that it can be very difficult to cleanly uninstall anything in Microsoft's browser-CLR-plugin axis. This is a shame, because I have some ambitious Silverlight projects.

Via  Rob Connery Interviewed by Miguel de Icaza, I took a quick look at SubSonic, which appears to be a good solution in the ASP.NET world for very rapidly generating Create-Retrieve-Update-Delete functionality pages that honor database foreign keys.

One of the dazzlers in the Ruby world is a library called ActiveRecord, which powers similar functionality within Ruby on Rails. If you're lucky enough to be starting with a new database, you can generate "scaffolding" to edit your tables in a matter of quarter-hours. (As Steve Jones says in CRUD is Crap, that such functionality is considered dazzling in the year 2007 is an indictment of our toolsets, but nonetheless.)

Any client-facing application almost instantly moves beyond scaffolding, but I've been reminded recently of the need for rapid data-editing / cleaning in any large application but especially in SOAs, with data continuously flowing into the system boundaries. Garbage-in, garbage-out is a big problem in SOAs.

Two downsides of ActiveRecord are that:

• Foreign key relationships must be manually inserted, and
• It's naming conventions can be tough to overcome when using a legacy DB

These seemingly minor issues can be significant when you're dealing with an enterprise-sized database with several hundred tables. Whether SubSonice addresses these issues, I don't know, but I look forward to adding it to my arsenal.

The source code to the Microsoft.Scripting namespace is available at http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=438

A review of the IronPython codebase in the release makes the early-stage processing look pretty close to the (well-designed) IronPython 1.0 release: there's a language-specific tokenizer, parser, AST generator and walker. Once you've transformed your AST into whatever-the-appropriate-form is, code generation looks insanely easy.

So the bad news is that there's no compiler = new Language(BNF myGrammar); statement. The good news is that we already have such things: they're called Lex and Yacc -- or better yet, ANTLR. Although the sheer line-count of a language-specific compiler using Microsoft.Scripting seems large, such tools should be able to generate maybe 80-90% of it (I'm talking of the compiler, not the shell or runtime support, but that, too, looks generically handled by Microsoft.Scripting).

But this is one of those recursive things -- you can't generate a DLR-based compiler until someone writes a DLR target for the compiler-compiler. Interestingly, the definitive ANTLR Book will hit the shelves any day now. Hmmm ... if I was a kid interested in getting a job at Microsoft, I know what I'd be doing this Summer ...

That Microsoft was going to increase support for dynamic languages is no surprise: they've been talking about that since (at least) PDC '03 and various hires and initiatives have clearly been in the works. I haven't seen the DLR yet, but my big question is: what version / runtime / patch level of the CLR  and libraries becomes the lowest-common denominator for Silverlight (i.e., cross-platform, in the browser)? Because for better or worse, that becomes the platform for dynamic languages in the .NET world.

I am surprised by the IronRuby announcement (and officially bestow the He-Man Programming Award to John Lam). I really thought we were going to see some form of Ruby#:Ruby::C#:Java. Although I'm happy (Ruby is now my #1 administrative programming language), I was actually hoping to see a new language. Ruby's a fine language, but it doesn't have a good story for concurrence, it has a boring model of XML (unlike VB), it has some unattractive Perl-isms. Most importantly, I think MS does a good job when they have the flexibility to evolve the language and, simultaneously, can devote the resources to developing the compilers, libraries, and toolsets.

Scott Guthrie just announced IronRuby! Yeehaw!!!!!!

--

Silverlight binding; demoing on Mac

--

Dynamic Language Runtime announced

--

"Shipping later this week" (I'm sure he means shipping a beta / CTP)

--

Uses Ruby naming scheme when programming .NET libraries (weird. Not sure I like that.)

--

"Switch the console into Python mode, Ruby mode, VB mode" (he means something called "Dynamic VB")

--

www.silverlight.net is the commmunity site

(No sign of DLR / IronRuby / IronPython / Dynamic VB on that site as far as I can see)

--

"Componentize dispatching code, code generation, that sort of thing that compiler vendors do" ... namechecks to Hugunin and Lam ... we shipped this morning the DLR source code" on Codeplex ...

(http://www.codeplex.com/Project/ProjectDirectory.aspx?ProjectSearchText=dynamic%20language%20runtime ? )

Naysawn has announced that the Visual Studio unit testing framework (MSTest) is moving into the Pro SKU of Visual Studio. That's a good start, but I want to lobby for going the whole way:

Please move the unit testing framework into the .NET framework.

Source: MSTest Moving to VS Pro
Originally published on Wed, 28 Mar 2007 08:35:00 GMT by Brad Wilson

And there was much rejoicing...

Of course, Brad's right that unit-testing libraries ought to move into the base library, but the VS tools are sophisticated enough to be implemented solely as VS add-ins.

John Lam, whose RubyCLR bridge led to a position in Microsoft's CLR team, hints that an announcement on his project (my guess, X:Ruby::C#:Java) will be forthcoming. Sadly, he hedges as to whether it will be MIX or PDC. Of course, I'll be going to PDC, but if there is a major dynamic language announcement at MIX, maybe I'll have to go to that as well...

Absolute times to calculate a fixed range of the Mandelbrot set:

This isn't even fair because the non-GPU timings are strictly timings of the calculation loop. The GPU timing is actually derived from my frame-rate.

I'm having some trouble getting my shader to run on my desktop (ATI All-In-Wonder with Radeon X800), but will post that number when I can.

Ah, that's more like it. This is a graph of duration (in seconds) versus the number of threads during a calculation of a Mandelbrot set using the XNA Framework on the XBox 360 (Neil: The previous graph was normalized speed, as you suspected. For more on labeling the Axis in Office 12, see the next post.)

In order to have the XNA Framework distribute processing, you must explicitly set the "thread affinity." This must be done within the worker thread (presumably early in the ThreadStart delegate) and, on the XBox 360, you must not use the values 0 or 2, which are reserved. Thus, I use code like this:

struct ThreadWorker

{

    int processorAffinity;

    static int processorAffinityIterator = 0;

    internal ThreadWorker()

    {

        switch (processorAffinityIterator)

        {

            case 0  :

                processorAffinity = 1;

                break;

            case 1 :

                processorAffinity = 3;

                break;

            case 2 :

                processorAffinity = 4;

                break;

            case 3 :

                processorAffinity = 5;

                break;

            default :

                processorAffinity = 1;

                break;

        }

        if (++processorAffinityIterator == 4) { processorAffinityIterator = 0; }

    }

   internal void ThreadRun()

   {

     Thread.CurrentThread.SetProcessorAffinity(processorAffinity);

     ... begin work ...

UPDATE: See this new post It looks like XNA does not distribute processing across the multiple cores of the 360:

This is identical code (a Mandelbrot calculation of a fixed size) running with multiple threads. While my desktop machine speeds up with more threads (peaking at 3), the XBox 360 running XNA runs at almost exactly the same speed.

Incidentally, the graphic shows normalized speeds. The actual performance of the XBox 360 is 1/5 - 1/9 that of my desktop (4.43 seconds as opposed to ~.8 seconds single-threaded or ~.47 with 3 threads).

Sweet. Stay tuned for performance benchmarks, concurrency and GPGPU programming experiments on the 360, and maybe even some games...Maybe even a domain-specific language for writing board games.

Here's a good pattern to use when you have a domain object that combines non-varying and time-varying data. Perrin's modified the original pattern to use generics: a good choice. (Why is it a good choice? Because objects that combine these two types of data are usually conceived of in a direct-but-composed way: we don't think of a Product as changing it's identity because it is or is not on sale, but we do think of a Product and its normal- or sales-price as a combination of two things. While it's easily possible to express this type of structure using inheritance, making them parameters to a generic is a batter match with the conceptual model.)

Here's a challenge (for explicitly typed languages: for those with duck-typing it's trivial):

Design a Snapshot<T> such that you can query any property P in T for a given time. For instance, if you had Snapshot<PlayStation3> myPlayStation, you could query it's price using code similar to this form:

Price p = myPlayStation.ValueAt(myDateTime).Price()

Hint: Would the problem be easier (or possible) if you were to use a CTP?

John Lam, whose RubyCLR bridge has been a fascinating and seemingly highly-successful project, is joining Microsoft. Details are vague, but he says he'll "be working in the CLR team" and "I’m not going to leave the Ruby community" but makes it pretty clear that he's looking to hand off the RubyCLR codebase to the community (hmmm...I have such copious spare time...).

I'll be trying to wheedle details out of him, but I still feel that Microsoft will not produce a Ruby but, something at least Java:C#::Ruby:X if not even a little bit more of a Ruby-VB hybrid. Timing-wise let's say that Microsoft has designed a "more dynamic" language (VB.Nexter, Sapphire [Perl->Ruby->Sapphire]). One could well imagine that they might be in a good position to develop a back-room prototype for PDC2007.

Scott Swigart describes Vista Server Core, a GUI-less version of Vista. While I quite like the idea (not just for resources, but because a purely command-line driven server facilitates a shift towards scripting repetitive tasks), there is a deep irony that this version of Vista does not support the .NET Framework.

So we beat on, boats against the current, borne back ceaselessly into the past.

Update: Brian Brewder observes that no .NET == no PowerShell, which pretty much destroys the "shift towards scripting" concept.

The Made In Express contest is over, with the winner being an "All Terrain Self-Maneuverable Robot." This is unfair for at least two reasons:

1. It's a group entry ("Group entries will not be accepted"), and
2. It's been under development for years

I downloaded the source to the robot and the very first file I opened had a history file showing it had been finished in March of 2005! This is patently unfair to individuals who wrote their programs, as the contest clearly promotes, in two or three months.

To be fair, a re-reading of the rules page doesn't restrict time of development to the big graphic on the frontpage that says "May: [Finalists] start to build their ideas into projects," but the "group entry" thing is clearly forbidden.

"Made In Express" was a contest to highlight the use of the freely downloadable "non-professional" versions of Visual Express. I had criticized some of those chosen as finalists, including the robotic entry, because they were clearly overly ambitious for the short development window. I don't want to rehash the particulars, but I hope that if there's a repeat of this contest, the process could be a little more rigorous.

Twenty minutes ago I was throwing up my hands in despair at the C# code being generated by ANTLR and, turning to my blogreader, saw that Microsoft has released the documentation for their DSL (Domain-Specific Language) tools. Boy, is that a frustrating set of Web pages.

I'm all for revisiting the assumptions about language design and implementation. Perhaps it is the case that Microsoft's DSL tools make perfect sense to a person with a blank slate of expectations. But, for a person who's been spending time reviewing the latest version of The Dragon Book and comparing a bunch of compiler construction tools, Microsoft's DSL documentation seems just impenetrable.

Microsoft's approach emphasizes the use of a Visio-like design surface to create some form of directed-acyclic graph. I think the result is a visualization of the grammar of the target language. But the documentation uses a  vocabulary different than standard "compiler 101" talk of tokens and lexemes and so forth, so I'm not sure.What the heck is a "relationship swimlane" and what does it have to do with language design and implementation? Is this vocabulary difference gratuitous or necessary?

The button-pushing walkthroughs are too mechanical for understanding. For instance: "Step 7. On the Define New Model File Type page, under What extension should model files use?, type ftree, and click Next." Directing attention to this kind of trivia is counter-productive.

Developing a four-function calculator is a cliche of compiler construction and I applaud teaching newcomers with something different. But it does have lots of advantages: the syntax and semantics are minimal and, if nothing else, it could help map Microsoft's vocabulary into something more familiar. Even if Microsoft intends these tools to be used by a broader audience than traditional lex/yacc users (and I hope they do), there needs to be some outreach to us old-timers, who are, if nothing else, the one's who are most likely to advocate the power of DSLs.

The release of IronPython is, in and of itself, A Good Thing. But maybe the best thing is that it's a shared-source release with a very reasonable license. Not because I'm a utopian about the quality of open source, but because I really quite like the code structure. Apropos my dismay that there is not a compiler-design tutorial that reflects modern techniques, IronPython is as close as anything I've seen to just that.

Hey, how awesome would this be:

Three big problems with understanding compiler techniques are that

1. tutorials traditionally use a single implementation language, and
2. toy samples (calc) morph into complex samples (mini-C) morph into esoterica (unification) rather than iterate on a single problem, and
3. there's a gap between hand-coded tutorials and tutorials based on the use of tools (lex, yacc, bison, antlr, etc.). The two techniques should be shown in parallel, with an emphasis shifting from one to the other as the tutorial gets more advanced.

Jim Hugunin wrote the first few iterations of IronPython in Python, then switched to C#.

How rocking would it be to have a tutorial that started with those Python-based prototypes, showing the development of the object structure, strategies for this and that, etc. and then switched to C#, showing the complexities of implementation in a explicitly typed, mainstream language? Meanwhile, you track the development using a tool like Antlrworks:

While I believe that IronPython is 100% hand-coded, I think that most will want to use tools to automate the process as much as possible.

Oh, man, such a tutorial would be great. Jim should so do it in his copious spare time.

Alright! Jim Hugunin et al. have shipped IronPython 1.0. You can get it at CodePlex.

Oh, bummer! Given that XNA GSE is a beta and given that it requires C# Express, not Visual Studio, I installed it in a VMWare OS, but when I went to run the sample SpaceWar game, I received a "No suitable graphics" message. I think that leaves me out of luck. Maybe I'll install it on one of my laptops, but if anything actually needs the power of my development machine, it's game programming.