I feel like some qualification is in order. I can't make any excuses for SOAP (maybe someone else wants to take that up), but COM, at its core, is indeed a simple and dare I even say elegant technology. COM is alive and well on Windows, because it still serves a basic need (cross-language binary interop) and it does so well.
The problem is that COM just couldn't stay simple -- the basic idea of querying an object for reference-counted interfaces was quickly buried under incomprehensible layers of pUnkOuter and IMoniker and apartment states and OLE activation sites and god knows what other stuff that you have to know about but doesn't help you getting work done.
I've seen people who can get carried away adding layers of stuff to something simple and beautiful without ever realizing that it stopped being simple and beautiful quite a while ago, because they still understand everything. Boiling frog design, if you will. I don't know Don Box well enough to tell if he's one of those people, but COM and related technologies seem to have seen a lot of that crowd.
I did like the article though, even though there wasn't much to it. One of these days when I have some time, I'm going to write a LISP/Scheme compiler for .NET/CLR...my goal is to get Arc running on .NET, specifically for IIS7 since it has better support for MVC applications.
There was also a port of an interpreted scheme written in Java that someone brought to C# -- I think it was floating around as ".NET Lisp" or "Lisp.NET"; NOT the 'example' Lisp 1 that someone wrote in the earliest days of the CLR, but a straight port of the Java project.
I used it myself once; snuck it into a project to run an admin interface for one of those crappy CRM's you're always being asked to make as a Code Monkey (it was just a little embedded language and user-interface element that let admins drag-and-drop "listers" and filters for various types of data, embedding them at will within the articles that they wrote -- I couldn't have imagined trying to write something like that for ASP.NET, so I lisped it, and I believe it's still humming along, for years now: a homebrew DSL parsed and executed by a pre-alpha interpreted lisp sitting at the heart of a .NET 1.1 application. Never a hiccup, and being admin-only, performance wasn't a concern; the end-result was compiled to a canonical XML format, which most .Net coders have no problem writing XSL for).
The project was being maintained on SourceForge by a really bright guy (from Australia afair); he'd added Arc-style lets and a nice little parser (for evaluating quoted infix expressions)
I remember trying to look it up a couple of years ago, to forward it to a friend still stuck in .netland, but it had disappeared; maybe someone here knows more.
FWIW, being a Distinguished Engineer is a big deal. The guy running my team is a DE and he's probably the brightest person I've met at Microsoft...I consider myself fortunate to work for him. I've met people who've been full time (I'm an intern) for a few years and never met a DE.
... Heh, no, yield isn't the same as a continuation.
Yield, for iterators at least, is basically just calling a function that you've passed in.
In Ruby (and now C#) and many other languages, there's what appears to be syntactic sugar around this idiom, and especially in C# it's a bear to follow what's happening because of the sea of syntax.
But all that's really happening is, you pass in an anonymous function, and when the iterator calls yield(x), it calls that anonymous function with x.
In C#, you're saying
okay, for this foreach doodle with a variable i, HereIsAnInterator(initialized) {
but you can imagine this whole block as
a function that gets called with i
every time yield() is called.
}
Behind the scenes, the stuff between the braces gets turned into a function f, and attached to HereIsAnIterator, accessible via (at least) yield().
Yield for iterators is just sugar around an anonymous function.
Continuations are a whole other bag o worms. (edit: originally invented as a powerful memory-wasting device, some people now find them almost useful ;) ).
:P Look, I felt dirty enough just reading the C# code for an idiomatic usage of an iterator ...
Obviously, in a compiled language that you control, you could take that block and turn its contents into a method of a class for speed.
Conceptually, much easier to understand the base case: that you're passing in an anonymous function.
In ruby, since they let you pass blocks around as objects, suddenly, poof, you can understand and implement ruby's iteration, just by learning about blocks and seeing a snippet of code.
I like how, when they're talking about how to handle ITERATION, they say "we thought about coroutines; we thought about continuations; we settled on what we've got now" ... thinking about how I'd do it in CL (if I were writing a library to make iterator-style programming more friendly, perhaps as a macro), I have to say I wouldn't have immediately thought of using either of those. :P
Of course, I suppose for their target market, features that let you "roll your own x", for almost any x, are far too dangerous to allow. Ugh.
