Dynamic Languages on the CLR

Jason Zander has a post that mentions dynamic languages on the Microsoft CLR. But don't get your hopes up yet.

Dynamic Languages

We had several questions about our philosphy on dynamic languages. I think I'll actually write a separate blog post on this one because it is such an interesting subject. A few quick notes for now:

I believe we already have a great platform for dynamic languages. You get the GC, exceptions, interop, and access to a huge set of libraries for free when you target the CLR.

That's nice marketing but not much information. Let's hope for the real post, and see what else he says here...

In Whibey we add Lightweight Code Gen (LCG) which further eases the ability to author the languages.

Alright. There's something. I wonder how the code generated supports dynamic languages.

Because we also built generics deeply into the runtime, you can leverage that support dynamically at runtime without having to "fake it out". This is a distinct advantage over techniques that use "erasure" to replace syntax with expanded code.

How is this an advantage for dynamic languages? "Because all our other programmer have to deal with rigid, unnecessary language constructs, we've preserved them at runtime so you can figure out how deal with them too!"

Thanks for that. What else have you done to make the CLR "compelling" on the Windows platform? Continuing...

Because you target our MSIL and type system, we also enable easy access to tons of tools that work across langauges seemlessly.

As opposed to the tons of cool tools that have been working in Lisp and Smalltalk for literally decades that do *not* require a "type system". Great fun... "Use dynamic languages in our world and as a bonus you get to understand our rigid type system."

By now I am feeling really frustrated and pessimistic. I am learning nothing about support for dynamic languages and only about how those languages will have to work with all the other rigid conventions of poorer languages. No news is good news compared to this.

I expect in the future to do a Project 7 style approach to adding more improvements to the engine, just like we did in the late 90's to form the current engine.

Any ideas what kind of improvements there will be for dynamic languages, your topic of conversation?

And finally a quick plug for Jim Hugunin who is doing a keynote at Pycon next week.

Finally there may be some information. Hugunin apparently has not posted since October. He's not participated in the IronPython email list. And recently someone *outside* Microsoft created a sourceforge site for IronPython fixes.

Maybe Sun can do better.

Programming

James Robertson writes...

There are a lot of developers who will have a really hard time letting go of the idea that all inbound CS people should take a compiler class. Ask yourself though - how many people are doing that kind of work, and how many are creating what amounts to glorified reporting interfaces?

I actually believe all programmers should have several compiler courses.

As it turns out a programmer friend with a mechanical engineering degree has been taking EE and CS courses over the last couple of years. He just completed a compiler course. He created an interesting SQL compiler for file systems as his final project.

I was reminded of the deeper value of learning the basics of compiling. We talked a few times over the semester, and his discovery process was familiar. The surprise he found building compilers are the regularity, and the patterns that decompose complex problems into combinations of simpler ones. Of course "back in my day" we did not have names for all these patterns, but the lessons are the same. The lessons learned building compilers can be applied to many other programming problems.

More advance compiler courses teach about the mathematics and engineering of representations and transformations of data. Denotational semantics, continuations, even "types" (gasp! I said it) are worthy topics that all programmers should understand.

Distributed Build Architecture

Vincent Massol proposes a distributed build architecture using JavaSpaces...

I personally prefer this architecture over one where the orchestrator directly sends build requests to build agents as I find it more scalable and more flexible.

Yeah, and robust as well. Just watch for that place where the build agent does a 'read' for a request. It should be a 'take'. Before the take though it should 'write' it's intent to take perhaps including an estimated time of completion. Then if it fails, another process can monitor the results and restore the request if it suspects or detects the agent failed to complete.

If the request included an estimate of time to build then build agents can predict their loads and which requests they should accept. These estimates can come from actual builds and improve themselves over time. Many possibilities for coordinated processes to evolve on their own through "metadata".

Would you like such a distributed build system?

Actually I'd rather use tools that did not require such massive builds, but the idea applies generally to many kinds of transformation activities. This is an ideal example of services built using simple, general coordination mechanisms.

You can build *all* kinds of coordination patterns using the simple Linda-like vocabulary.

Urp or ERP?

Notably the new Windows product VP has a background selling to customers with indigestion.
=8^o

Worth the Investment?

Alan Knight provides another story to guide your investment in software choices...

I spent last week in Cincinnati, at Cincom headquarters, in a variety of meetings. The meetings were quite good, as meetings go. The last day was spent in meetings with a large customer who has some very important systems dependent on VW. They had some very nice things to say about Smalltalk being the most stable piece of their information systems.

But it's so... different.

Yes, it is. And that's a *good* thing.

Coordinating Webs of Information

More from Jon Udell...

On today's Web, security, asynchrony, reliability, routing, and proxying are, in general, aspects of the data communications layer. On tomorrow's Web they'll be aspects of the application layer, and we'll operate more like weavers of business processes than plumbers of networks.

I'm not sure I understand this vision, but I'm also not sure I agree with my understanding of it.

The best way to build a web of information and processing appears to go back to blackboard architectures in the 1970's. These ideas also proved to be agile for a more broad set of coordination problems. Today's web is showing an approach along these lines may be effective at scaling to the world for machine-machine as well as human-machine.

I thoroughly doubt "we'll operate more like weavers of business processes than plumbers of networks". We need to hide business processes as much as possible, favoring coordination via semi-structured data showing up here and there on flexible networks of cooperating-yet-arms-length processes.

BKM's

Jon Udell asks...

Why must we make everything into a rivalry? Why can't we just enjoy the best of all worlds? That's how I use programming languages, that's how I use operating systems, and that's how I intend to use this stuff too.

Because we are confused. Or at least I am. About what *is* the best of all worlds. And there is a cost to all this. Combining Python, Smalltalk, and Java is one thing. But what are the Pythons, Smalltalks, and Javas of this new industry?

When you see so much, well, stuff, being flung at the wall, why wait to see what sticks? Go with what seems simple enough and works already. Doing that much is hard enough. Let others invest in prediction.

Prediction is very difficult, especially if it's about the future.
-Niels Bohr

Accretion vs. Evolution

Also from James Robertson, on accretion of features in popular programming systems, if not most software.

Java/JVM and C#/CLR evolution is interesting to watch as compared to the history of Smalltalk and Lisp. Consider how drastically Lisp changed from 1960 to 1970 or so, and the same for Smalltalk from 1970 to 1980. They had real developers using them in real situations, but the pressure to stagnate or the pressure to accrete cruft rather than replace it was not there.

Not only did Lisp and Smalltalk languages and tools support evolution as well as backward compatibility, the culture and organization encouraged even drastic swings in features.

J/J and C/C do not have those benefits, neither technical nor organizational. They are ultimately doomed, so the word to the wise would seem obviously to get off those platforms ASAP. Invest in systems that have proven themselves already for decades.

Do You *Like* Handcuffs?

Ramon Leon writes...

With or without Seaside, Smalltalk needs to return to the mainstream. The current crop of mainstream languages, pretty much feel like handcuffs in comparison.

Numbers Games

Jono Bacon writes...

Bear in mind that the headlines may simply be an illusion in an industry where the real success stories are happening all around you.

Yeah, but...

James Robertson is looking for a MSFT course correction...

You know what? As far as I'm concerned, MetaWebLog API sucks, Atom is pointless, and SOAP is a huge duplication of CORBA on port 80. But you know what else? It doesn't matter what I think, because I have to support these things anyway. Whoever runs Product Management/Marketing for IE - it's time to fire their sorry butt, get someone new in there, and slap them around with a cluestick until they get it. I'm tired of paying the IE penalty for CSS, and so is everyone else.

Yeah, but XAML and Avalon are going to be so, um, compelling.

Really.

Reference Relevance

As seen in an email list for dotnet programming...

Passing a reference type by value lets the callee manipulate the object that is referenced. Passing a reference type by reference lets the callee manipulate the reference to the object itself - to change where the caller's reference points.

Such are the things one gets to sweat about when the language is not as simple as possible.

Yeah, I know.

And ouch...

One thing to keep in mind when is that the 'ref' is very important when you cross application boundaries. Specifically this applies to .NET Remoting. If a parameter is labeled with 'ref' it will copy the changes back to the caller. This differs significantly from calling a member function locally.

We're Waiting Already

From CNET...

"It's a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century," said Charles Fitzgerald, Microsoft's general manager for platform technologies. "But XAML is in a whole other class. This other stuff is very kludgy, very hard to debug. We've seen some pretty impressive hacks, but if you look at what XAML starts to solve, it's a major, major step up."

Please actually *deliver* something newfangled, and show us why its significantly better than the older technology. Then you might generate more buzz than Google.

But then again what about Firefox? Opera? Safari? Charles... I think you've got a lesson or two to go with XAML. You may know more than I do about how you'll win this one, but either show your entire hand or get back to work.

(via Jim)

Asynchronous SQLServer Messaging

High on my reading list, from MSDN on SQL Server 2005...

"Get an overview of how the new Service Broker functionality in SQL Server 2005 enables faster and easier development of SQL Server applications that rely upon asynchronous, queued operations."

The Future of Data

Martin Fowler writes...

If applications were more aware of version control then I think we would see more interesting things being done with it. I hope that a solid, usable, open source tool will spread the usage of version control to a wider audience - after all we are no longer short of disk space.

I have to agree, and think Subversion's support for WebDAV and API could help get there. Thinking back about a year, where I speculate...

From working on systems in a half dozen domains I have come to the conclusion there are three simple patterns we should lean on for making documents and messages persistent.

• Tuples Spaces (think Ruple Forums) for in-progress, state machine-like transactions and collaboration.
• Versioned document trees (think Subversion's file system) for long-lived, shared, document editing.
• Star Schema-based storage (think Sybase IQ, a simple, low-maintenance, scalable database technology) for read-only transaction history and analysis.

I deeply believe (it is my hypothesis) that these are the only patterns you need, and the implementations going forward can become far simpler and adaptable than all of today's cruft.

Emacszen

"Danny, after oscillating between NetBeans and Eclipse for several years, gets a surge of Zen and orders the Emacs Manual"

Success'ing

Ryan Tomayko writes... From the beginning, WS-* has been approached incorrectly. The approach that we're advocating is to first embrace and understand existing web architecture and then to gradually enhance (constrain) it to meet the needs of new requirements. We advocate this not because we think it's a better way to be successful, we think it's the only way to be successful. [That's some claim! Is "success" even defined in this case? -Patrick]

An example of the approach we're advocating is Bill de hÓra's recent proposal for reliable messaging over HTTP, (HTTPLR). The difference between the HTTPLR approach and the WS-ReliableMessaging approach is that Bill's proposal builds on simple proven web architecture without requiring additional apparatus.

This is interesting even inside the firewall.

April XPDX Code Sprint

The April XPDX code sprint (Extreme Programming in Portland, Oregon) is on for April 9-10.

We'll be using Python in several flavors: CPython, Jython, maybe IronPython, and Python.Net (CPython with the dll's to integrate with dotnet).

Also in attendance will be Smalltalk. Seaside with Squeak and VisualWorks, at the least.

The official April meeting, the following Tuesday evening, will be a retrospective on the sprint via Diana Larson.

Amazonian Art

Try these (via Lemonodor)...

• Lisp
• Smalltalk
• Python
• Ruby

D-Bate

Stu sez to Sean...

Does this cost a lot of money? Depends on what you define as "a lot".

And Avram Levinski adds...

Personally I think the whole WS-* is a gambit extended to outflank Java.

Before Tom closes with...

Stu mentioned: "Architecture groups are becoming keepers of the canonical schemas."

Kiss of Death. Just pack up and go home now.

Recombinant Gems

Carlos Perez keeps on putting out gems (with links to past gems as well). I am really enjoying these...

One key to a solution is the need for a recombinant architecture. That is a framework that will allow rapid assembly of components like we never seen before.

Apps

Danny Ayers writes...

I’d opt for a triplestore and Python, but even today we’re only just starting to see shrinkwrap apps moving to non-proprietary languages and interfaces.

The Race is On -- Where's the Goal Line?

From Infoworld...

What I thought would be a Java lovefest turned into a "How do we fend off Microsoft?" debate.

The consensus was that .Net is a strong technology but that Java provides the advantages and disadvantages of more community participation. While more amenable to community contributions than perhaps .Net is, it is thus more difficult to build a consensus on improvements than the monolithic .Net platform, which is controlled by Microsoft.

For the time being, both Java and .Net shall remain the dominant platforms. There may not be a victor, but continued coexistence for years to come.

I'm curious whether the interesting race is the emerging-yet-not-fully-realized race to "fully" support dynamic languages on these platforms.

Debasing

Danny Ayers writes...

It seems to me that a very large proportion of today’s user-oriented Web applications could run as CRUD. We’ve already got a fair idea how to separate content from presentation. But the business logic is usually all tangled up in a combination of SQL tables (and maybe triggers etc) and objects/procedures or other relatively hard-coded representation...

A part of the reason that middle layer has tended to grow over time is the mismatch between the logic provided by the database and the real-world data it has to manage (...much of this is to do with the design of SQL databases, not Codd’s model). Another problem is... up-front design of database schema... There isn’t much flexibility for continuous development at the back end, so things get pushed forward. Not very eXtreme.

...replacing the back end relational database with a triplestore, SQL with SPARQL and schemas with ontologies. Bit of RESTful HTTP and XML for the transport, bit of XSLT for the presentation layer (with HTML forms, XForms, XMLHttpRequest, whatever you like). There’s no reason why the whole lot couldn’t be generated from a set of statements, although a bit of PHP template hacking may be needed in the interim…

Yes, this is the old Semantic Web chestnut rewritten for a new generation…or rather, the generation that got quicker results with Dbase years back…

The Road Ahead

Mitch Kapor writes...

The challenge now is whether Ray and Groove, which represent forces of architectural innovation, can have a successful impact at Microsoft, which after all, is a large (58,000 person), middle-aged (30 year-old) company. It's hard to know whether the loss of nimbleness due to size and age is a greater challenge to Microsoft than is open source.

Groove and Croquet

Hugh Pyle writes some things about being owned by the borg and innovations...

What will become of Groove now? Good things, I think. After all, the only competitive architecture within a couple of decades is Alan Kay's mallet.

I wonder how Groove and Croquet line up. They seem fairly different on the surface.

Evolution

Sean McGrath writes about SOAP...

Behind the firewall, nobody can hear you scream and nobody can see your wallet bleed.

Success should also be measured by an ability to evolve. Building a system once is not the challenge.