The Wayward WebLog : Language

Rotten to the Multi-Core

mattwar — Wed, 06 Jun 2007 03:56:00 GMT

Everyone’s trying to figure out the next big software gimmick that’s going to make utilizing your multi-core machines super easy. Let’s face it, having to write code with locks and threads is not going to be it. We’ve had that capability for a long time and only the cream of the crop developers even dared to tread there, and even fewer were actually capable of getting it right. The average programmer, including me on most days when I’m not hyper caffeinated, need a better mouse trap to make writing and executing code in parallel an everyday task. ...(read more)

IQueryable’s Deep Dark Secret

mattwar — Fri, 01 Jun 2007 23:05:00 GMT

I love the IQueryable interface, but it’s got a dark checkered past that most of you might not know about. IQueryable is a great way to expose your API or domain model for querying or provide a specialized query processor that can be used directly by LINQ. It defines the pattern for you to gather-up a user’s query and present it to your processing engine as a single expression tree that you can either transform or interpret. It’s the way LINQ becomes ‘integrated’ for many LINQ to XXX products. Yet it was not supposed to be that way; with all that ease of use, plugging automatically into LINQ with an abundance of pre-written query operators at your disposal. You were not supposed to use it for your own ends. It was not meant for you at all. ...(read more)

The Origin of LINQ to SQL

mattwar — Thu, 31 May 2007 21:52:00 GMT

LINQ to SQL, possibly Microsoft’s first OR/M to actually ship in ten years of trying, was never even supposed to exist. ...(read more)

Beyond Dynamic Languages

mattwar — Fri, 28 Apr 2006 19:16:00 GMT

Everywhere I turn, all I read about is dynamic languages. Apparently, there is a small yet growing contingent of programmers that think dynamic is the only way to go. These guys are frustrated with the shackles of static type systems that force them to write clean code. And apparently, there is also a small and growing contingent of media types that think “hey, there’s a buzzword I haven’t heard before, let’s use it until we wear it out.” And they have. Believe me, its paper thin and about to be ripped through like a rubber eraser pulling double duty.

However, I’m not here to debate the virtues of dynamic languages. Some of these languages have really cool features, but that’s beside the point. It’s the dynamism that’s at issue and for some purposes dynamism is simply the better model. When you are dynamic you don’t have to know upfront the correctness of any particular thing. You just do what feels right and let the runtime figure out the rest.

That’s why I’m here today advocating the next logical step. It’s not enough to simply have dynamic languages. Sure, they make some of your programming tasks a bit easier to perform, but how much time do you spend programming anyway? Most developers produce on average one line of quality code per week. It’s not that they are lazy; it’s just that the ‘coding time’ turns out to be a small fraction of the overall product cycle.

So as you can see, what we really need to do is to take the advancements that dynamism brings to programming languages and apply them to those other things that busy your day.

Dynamic Meetings – Don’t plan specific meetings with agendas. Just show up in a meeting room at the same time everyday. It doesn’t have to be the same room, just pick one at random. At five after the hour, go around the room and ask each person that happened to show up in the same room as you what they’d like to talk about, write it down on a whiteboard in some order and then have at it. It doesn’t matter if you don’t have enough context to have a meaningful discussion. No one is listening anyway. It’s a good meeting if someone spontaneously decided to bring donuts.

Dynamic Design – This works best as part of a dynamic meeting. Take notes, but not too many. You wouldn’t want to fence your ideas in too soon. Doodling helps the creativity flow; be sure to use multiple colors. Don’t worry about getting agreement or buy-in from others, they aren’t paying attention anyway. They are working on their own ideas and drawing their own cartoon stick figures. When you think you’ve got a good concept, go away and write some code. Eventually, everyone will figure out something to do and will be busy writing code too. Don’t worry about integrating it all together. Its all just code, ones and zeros, adds, shifts and branches. The runtime knows what to do with it.

Dynamic Testing – Don’t make a plan. Don’t do code coverage, write unit tests or abide by any particular testing methodology. Let the runtime do it for you. Just load the program in ‘Test Mode’ and execute. The runtime will proceed to apply a series of random tire-kicking algorithms that will give the dynamic code a good workout. Believe me; you couldn’t have planned it anyway. With dynamic code you’re never quite sure what it does until you run it.

Dynamic Debugging – Yes, even dynamic programs will have bugs, though you might not ever know for sure. If you think the code is acting flaky, you may want to do something to fix it. It will probably mean looking at the code or some facsimile of it in some tool that will help you understand it. The old-school way would have been to use a debugger, set some breakpoints and walk through it, observing the behavior, looking at variables, etc. But that would require too much static knowledge about the code, things like specific variables, types, and ‘lines’. Since we’ve done away with these antiquated notions we’ll need a new style debugger that will help us deduce the problem without actually using any particular facts, a precognition engine if you will that uses advanced artificial intelligence techniques to divine the future. It’s either that or printing out text.

You see, if we take dynamism just one step further, we can vastly simplify the work we do now, by offsetting the part about doing a good job and getting it right until sometime later when hopefully we've moved on to another project.

But I digress

Matt

Beyond the Query

mattwar — Wed, 19 Apr 2006 10:20:00 GMT

I have been working a long time to bring queries into a modern programming language. Seven years ago I looked beyond ORM and saw the next horizon, a new world where boundaries between data are blurred and popular paradigms from different disciplines combine. Many have tried to convince me that it is simply a mirage, and maybe in some respects it is, but as with anything else there is often a lot of utility born out of imperfection. I have been marching steadily toward that horizon ever since.

I also realize much of it has been done before. From academic languages to real world database scripting engines, the concept of the query itself is nothing new. Yet, it has never been mainstream before, baked in as a first-class feature of a general purpose programming language. It is no longer a novelty, applicable to only a single domain, each domain with its own variant, bound in shackles, caged like a dangerous animal. It is becoming something real, something you can reason about and rely on, a permanent fixture of the natural programming environment, a part of its substrate.

And I’m not just out to promote a particular language. In a few years, there won’t be a language without queries. Eventually, queries will become one of the most used tools in your toolbox. And not just for databases; all aspects of your application will be queryable to some degree, allowing you the freedom to apply set-like operations anywhere and everywhere. Queries will bring power through simplicity and abstraction. What was once proscriptive will become descriptive, pushing more and more of the gritty details down into the runtime. And still the benefit will go beyond merely your personal productivity boost. The next horizon is already in sight. Queries will eventually become runtime optimized. They will enable automatic parallelism, scaling and distributed processing.

Yet, we are not there yet. With the help of a lot of other people, I’ve only just arrived at that first horizon, a place where the mirage forms into solid shapes and the world that I only imagined becomes substantive, where I can look out across the landscape of all that was devised and see it functioning, its clockwork gears spinning, its implications twinkling like dew upon fields of freshly grown grass. And I can simply query it, all of it, the grass, the trees, anything identifiable and enumerable. And it just works.

Yet in the midst of all that, I am overcome with another thought. Another horizon has opened up in my mind and I can see a bit further, beyond the benefits and the boosts, beyond the query itself. I can see now that it was only the first stepping stone. Something much bigger is out there. A paradigm shift is coming, where all things become fluid, all boundaries dissolve and intent becomes first class.

And it has certainly all been done before.

Matt

YODA the Programming Language

mattwar — Mon, 10 Oct 2005 08:34:00 GMT

Now that LINQ is out the door, so to speak, I can start focusing my efforts on the next next technology here at Microsoft. Ever since I joined up with the C# team nearly two years ago I’ve been frustrated by my inability to wax poetic about all the goodness we were working on. I was sworn to secrecy. Mum was the word. Perhaps if you were paying attention to the work in C# 2.0 and C-Omega, you may have guessed what was to come. Looking back, it’s easy enough to recognize it in the design of Generics, Iterators and Anonymous methods. The existence of Nullables in there as well should have made it obvious. We were planning ahead for the big pay off, language integrated query.

You may be amazed that so much planning goes on in the features that we roll out version to version. Sometimes big ideas and far-reaching visions take many releases to come to fruition. You cannot always do them in one release. Sometimes you have to take a risk and dole them out piece by piece. This may cause a bit of confusion at first, when no one can truly understand why a particular feature was included and not others, or why one design was chosen. Yet once all the pieces are together you can finally make sense of it all, and then as if by magic it all just seems right.

Of course, this time is no different than the last. We planned ahead and baked in features into C# 3.0 that will lay the foundation for the next big thing. LINQ is only the start of the revolution. Yet, unlike last time, the features we added now make it rather obvious what is coming next. If you connect the dots in your mind and extrapolate just a bit you’ll see what I’m getting at. You’ll begin to notice that’s its not just about query in the language, or first order functions or everything else that seems to be borrowed from languages of yore. No, these pieces are just stepping stones for what is yet to come, something truly original; a next generation programming language.

The evidence is there right now, plain to see. The query expression exhibits it quite clearly. Yet, that’s just for starters. Eventually, the same degree of innovation will influence the rest of the language, and then you’ll have something quite different, a language the likes of which you have not seen before, one that is simple and elegant, yet secretly powerful: a YODA-like programming language.

You see, putting the ‘from’ ahead of the ‘select’ was not by accident. Soon the whole language will be re-arranged in an effort to make expressing intent easier and more logical.

Instead of the cryptic c-like syntax below:

public void Main(string[] args) {

Console.WriteLine(“Hello World”);

}

We will now have eloquent YODA-like syntax:

(args of string many are they) Main is what they seek yet return they do not.

Brace you must

Written it is, the Console. “Hello World”

I know it’s difficult to believe, as strange as it seems. Yet, sometime in the future, everyone will be writing software this way. Knowing this, it makes my work so much more invigorating. I can literally feel the electricity in the air around here. It’s like some queer energetic force.

But I digress

Matt

What the World is saying about LINQ

mattwar — Thu, 22 Sep 2005 04:07:00 GMT

“LINQ is totally awesome. It’s like this thing that you use to condense your entire application into one line of demo code. Sweet!” - Stanley Morgan

“LINQ is divine but DLINQ is a delinquent. It gives programmers too much power and makes programming against data way too easy. Is nothing sacred anymore?” – Ned Flanders

“Lambdas are old school. LISP had these decades ago. If all you want to do is be a sheep then go right ahead. I prefer ACME.” – Wyle E Coyote

“I can’t remember what they are called, but those things you make to build up a result out of a bunch of braces and stuff are really cool.” - Anonymous

“LINQ will change the way we think about thinking about programs without requiring us to actually think about them.” – National Research Council

“LINQ puts the 3GL back in the 4GLs, together making a 7GL!” – Guy Steele

“LINQ is the next best thing since sliced bread. Before LINQ we had to cut those database loaves up ourselves. It was a mess. Now programming against data is as easy as simply selecting the slices we want. Anyone seen that plastic doodad that holds the bag closed?” – Heimlich

“LINQ is the best party game I’ve played in a long time.” – Jeff Bezos

XML Generics

mattwar — Sun, 24 Jul 2005 11:10:00 GMT

Designing a programming language is like inventing a metaphor for thought. Most of the time you struggle to find just the right metaphor, hoping the one you eventually choose will be the best at communicating the idea it is meant to represent. So you can imagine the process of language design leaves a lot of dead ideas on the floor as it refines itself toward the ultimate goal of intuitive expression. This can happen for many reasons, but often it turns out to be just that some representations are better than others due to the way they evoke immediate recognition, understanding and emotional attachment. Often the best representations have nothing to do with logic or consistency. Sometimes they are just better.

That's why we got so much immediate flak internally when we first introduced XML Generics. It was hard to understand the logic in them, but the emotional draw was undeniable. They just seemed to be the right thing. It's not that we did not care to hear the feedback from others, it was just that we knew going in that those closest to us were too tainted/attached to the current design. Developers and most other logically minded folk have a difficult time detaching from what they know, stepping back and taking in the bigger picture. And believe me the design for XML generics was going to be a big change, one that would be very difficult to understand without a deep appreciation for where we were going with the language.

Likewise, it was anticipated that many in the blogging community would have a similar reaction, so we decided early on that we would need to reach out to the community directly, explain our approach, and gather what feedback we could before launching into a full scale marketing push on the unification of XML and Generics.

Some of the more touchy-feely readers out there might start to see it already. The intuitive leap needed to bridge the two ideas together is one that must be made emotionally not logically. On the surface, the two might seem to have nothing to do with each other, but if you dig deeper you soon realize that the two are fundamentally linked, both concepts actually compliments of one another.

To bring the rest of you up to speed, let’s first take a look at generics, a new feature in C# 2.0 that allows you to define parameterized types. A generic type is defined using the syntax below. The name ‘T’ refers to the type that parameterizes Foo. Generic types can have one or more parameters that are substituted on use with actual types.

public class Foo<T> { … }

When you refer to a generic type, you do so in a similar way, replacing the parameter with the type you would like to use instead, such as in the variable declaration below.

Foo<int> x;

As anyone can clearly see generic types have a striking resemblance to XML. Both represent parameterized data. Both are descriptive and declarative.

We realized intuitively that a greater generalization could exist that tied the two together. Since this is a quality we strive for when designing the language we knew we were on to something if we just could find the right metaphor to bring the two together in the syntax.

And that’s when it hit me. The solution was right there, obvious all along. As it turns out, it was the reason that the whole thing was intuitive in the first place. It was the brackets, the angle-brackets. They were the key. So you can understand how the syntax had to change, to evolve, to make the two into one.

Foo<int x = “…” />

It was beautiful.

That’s why I’m so annoyed that it got dropped for something better. I mean really, do you think pure genius like this grows on trees?

But I digress

Matt

This post rated: AH - Attempt at Humor

Refashioning Software

mattwar — Thu, 14 Oct 2004 21:22:00 GMT

In our never ending quest to provide you with better, faster, more powerful products and tools, we some time find it necessary to redo a little of what was done before, to revamp it so-to-speak, to spruce it up, to splash on a new coat of paint and add new life to the old tried-and-true features that just seem to lack the luster of the new fangled frontiers that we foresee for the future as we scrawl upon our whiteboards and plot how the industry will be shaped by our ~~devious~~, ~~conniving~~, forthright innovations.

Sometimes, however, we find the glitter of new graphics insufficient or the haphazard cobbling of incremental features too stifling for the visions we hold of our grand new design. And its at these times that we propose major shifts in the architecture, sea changes if you will, that develop into new corporate directions, coin a plethora of new acronyms and buzzwords and become overtly evangelized by the enormity of our marketing force.

Of course, not all new visions are as groundbreaking as others, and not all are as grandiose or sweeping in their changes. Sometimes even small facets of products undergo independent upheavals that might have otherwise gone unnoticed unless you dared to look. Surely, the designers of these pieces were motivated by the same zeal that drives the big boys to reinvent, recast and reissue their offerings. It's easy to see how they can get caught up in it. It's not as if our modern culture dissuades us from this practice. In fact, we are actually encouraged by the media to remake ourselves, to remodel our lives around ever increasing fickleness in design and fashion. As consumers we have not only come to expect it, we demand it.

Recognizing this trend in human behavior, we at Microsoft have built in the mechanisms of change into the .Net platform right from the beginning. No longer do you have to wait for entire new platforms shifts before major improvements in subsystems and API's can be brought to you by the hard working developers here. You've seen some of this already, those little compiler warnings when you've errantly used a feature that has been redone, remolded into its sparkly newness. That has been our way of alerting you to the fact that the API has been revised, and that if you continue to rely on the old, outdated one, you stand a chance of being caught running code that is now inexcusably out of fashion.

Believe me, this has provided a valuable service to multitudes of ~~shoppers,~~ programmers out there, as evidenced by the tremendous amount of feedback we have received since the shipment of the 1.1 version of the .Net framework. We take this information seriously, so it should come as no surprise that we find it necessary to devise improvements to even the mechanism by which we alert you to changes. As it turns out, many of you found the warnings of feature obsolescence unexpected and abrupt. You felt cheated in not knowing until so late in the cycle, unable to avoid the embarrassing disclosure that your code may no longer be bleeding edge.

So we plan to introduce a new obsoleting mechanism that is more descriptive and will alert you sooner to potential changes, giving you a chance to prepare for future re-alignments that could catch you off guard. The new mechanism still comes in the form of an code attribute that you can use to decorate your own sources, but it has been renamed and moved into a new namespace. There is a new option on the attribute allowing the specification of not only the degree of obsolescence but the time frame by which it should invariably become so. For example, you will now be able to determine precisely how many months into the future that the current code usage will be considered in style and by what degree you will appear foolish for having used it beyond its freshness date.

The next release of the framework will come completely redone using the new mechanism. Each and every class will be outfitted with the new attribute, giving you the information necessary to predict when each individual feature will eventually fall out of favor. The compilers will also change, giving you cumulative feedback on the desirability and estimated fashion sense of your software. There will also be a tool that you can use to run against and rate precompiled modules from other vendors, so you will be able to accurately determine your softwares total degree of compliance and qualify for the new 'Microsoft Seal of Freshness'.

Of course, you will still be able to use the old obsolete, obsoleting attribute in your code, it just won't be as effective as the new design. But don't worry, there will be a compiler warning alerting you to this fact.

But I digress

Matt

Code Shock

mattwar — Fri, 17 Sep 2004 17:41:00 GMT

The first time I ever saw code written in Java, it scared me. The code looked awful. I mean it. There was no way this stuff could be for real. The source code I saw looked as bug prone as anything I could imagine. There were 'new's flying around everywhere, no clean up code, no error cases, no asserts, no assumptions, no sanity checks what so ever. I wondered what kind of novice wrote this stuff. I mean, it looked like something that was written by a computer science prof.

You obviously couldn't ship code like that. But even as a sample it was so flagrantly bad it was dangerous. I had downloaded the code to take a look at it. (Those were my pre Microsoft days.) I thought it sounded cool and new and I'd give it a look, yet after wading through the quagmire of source for only a few minutes I was certain that I'd never give it another look again. So I walked away from it that day, turned of the PC and left it behind.

Fortunately, I changed my mind.

You see, what had happened was that I looked at that source through the eyes of a professional C programmer, and everywhere I looked I saw all the rules being broken. The language looked like C, sort of, so it had to behave like C, right? Wrong! I had let all my assumptions get in the way. There were new things going on that I had not even considered. The next time around I dove into the language spec and learned about the garbage collector, the exception handling, the pcode validator, etc, all these things that when added together gave you something quite different. That code I had scoffed at on first inspection had in fact been abiding by all the rules. The rules had just changed, that's all.

Years later, with lots of experience working in managed environments, Java and .Net, I've grown accustom to all those services and practices that at one time seemed not only alien, but flat out wrong. Now, I find myself completely on the other side of the fence. I find myself now looking at C code, unmanaged, raw, savage, and I cringe. Not because the code is poor or violates any rules, it's just running without the safety net. Whenever I see a fixed sized buffer on the stack, a flurry of asterisks or even an innocent looking 'new', I get a bit nervous. I start to wonder if the code was written correctly, if all the cases were handled, and if some errant state in a far off function will suddenly go astray, launching the processor into a tantrum, wreaking havoc across the codescape, a whirlwind of destruction that will quickly lay waste to even the cleanest lines of logic.

Matt

Style is Serious

mattwar — Wed, 15 Sep 2004 05:54:00 GMT

It's been difficult to focus on work lately, let alone find the time to contemplate something worthy of a blog post. The distraction of the presidential race is too compelling. My wife and I are glued to the television, CNN, FOX, MSNBC. I'm starting to have lucid dreams about dastardly swifti-boat word documents. Just make it stop. Just make it stop!

Those of you outside the U.S. probably find all this a bit humorous, but its actually rather serious business. There has been so much media coverage lately and the mood around here is so pro civic duty, I actually spent a few minutes today thinking about who I might vote for in the upcoming election. Generally, I start by making a list of the pros and cons for each candidate, highlighting the ones that most correspond to and diverge from my own personal views, and then I wad it up into a ball and toss it in the waste basket, because when it comes down to it there is only one factor that matters to me any more, and that's style.

It doesn't matter so much what each candidate believes, what programs they are for or against, or their history of executing on them. It doesn't matter what system they are affiliated with or what platform they choose to build upon. It's just about style. A candiate with a good style, easy to understand, direct and to the point gets my vote every time.

I realize you may find this a bit unorthodox, but in my experience bad style is a sure sign of an unfocused mind; sloppiness leads to a whole host of potential problems. So before I punch my chit this November I want to have a few questions answered by both Bush and Kerry. Do you put the open curly on the same line or the next? Do you indent? How many characters? 4? 2? 8?!! Whitespace or tabs?

Style is serious.

But I digress.

Matt

Focused on the Customer

mattwar — Thu, 29 Jul 2004 17:25:00 GMT

The top level management at Microsoft spend a lot of time keeping the rest of us focused on the mission, making sure that we never lose sight of the end goal, and that its all about the 'customer', not the fantastical whims of a few developers. Still, being one of those fantasy led whimsical developers, I have got to admit the siren song of self gratification is hard to keep at bay. Every time I sit down at my desk or stare at a white board I am compelled to imagine products and features that likely have no place in the real world. I just can't help it. I'm like a kid in a candy shop.

Knowing this about myself and others, I expect that as a group we can easily succumb to unnecessary distraction. So its quite telling to take a look at the proceeding of an average C# design meeting from an analytical perspective. You see, before I showed up on the scene, before the product team started focusing on data, there was a sort of apathy toward customers. Now it has all changed. I can tell by taking a look at past meeting notes. You'd be hard pressed to find a customer anywhere in them at all.

Now, if you could take a look at my track record here at the company, you'd find a strong customer focus. The time working on Xen/C-Omega, the ObjectSpaces years, the .Net data and XML frameworks, and even good ol' abused but used ADO. Every time we talked about these guys, every time we designed a feature or examined a flaw, it was always about the customer, customer, customer!

Imagine my surprise when I joined up with the C# rabble. In these meetings, nary a customer in sight. When someone walked up to the board to write down a snippet of code, it was always the same old anti-customer, developer whimsy that got spit out.

public class Foo {
public int X;
public string Y;
}

Foo? What the heck is a Foo? That's the sort of self gratifying stuff I'm talking about; not even an attempt at grounding the discussion on real customer needs. That all changed when I started slapping down code up on the board.

public class Customer {
public int Id;
public string Name;
}

Finally, we were talking about customers. People starting asking the hard questions, like what about 'Bar', customers don't have Bar's, they have things like addresses and orders, don't they? I could see it their faces. It was like a light suddenly turned on.

The next day everyone showed up wearing Khakis and Polo shirts.

But I digress.

Matt

Warped Weaving

mattwar — Tue, 27 Jul 2004 21:04:00 GMT

Aspect oriented programming uses a technique called 'weaving' to merge together and/or modify portions of functional/procedural code, to produce code that at the same time is both highly efficient and easy to understand in cases where normal procedural composition would have prohibited clean unification of these separate concepts. The general idea is that you the programmer get to write snippets of code called 'aspects' that do particular jobs by making modifications or whatnot to the rest of the code tree (usually during compilation.) This might sound like a brand new concept, but it is actually something that happens already inside of compilers, the only difference here is that now you get to define your own.

And that's really the crux of the problem. On the surface, all this sounds like a huge benefit, you can write your own style of transformations and/or optimizations of the code tree to achieve ends people have not even imagined yet. Unfortunately, it can quickly go awry when you try to combine multiple aspects together.

A compiler does this kind of 'weaving' during separate phases often referring to them as rewrites of the tree; validation, optimization, transformation, these are all steps that may in fact rewrite the semantic program tree before code generation. Whenever a language introduces concepts that are no longer one-to-one with the underlying processor architecture, it must in fact decompose/rewrite that semantic node as a series of more primitive instructions that the processor can understand.

But lets ignore the CPU for a moment, and imagine a perfect world where the language has already been parsed and bound into its most pure semantic form that can be analyzed, inspected, modified by other code. We can imagine a set of operations that we might want to do against this tree, patterns to match, rewrite to occurs, that still leave the tree in a full semantic state, swapping some semantic nodes for others, basically a closed semantic set with onto mappings. Even doing this, we still find ourselves in a state where our rewrites exchange some nodes for others, usually exchanging single nodes for a variety of equivalent decomposed ones.

This guarantees that after one rewrite occurs, the overall semantics may remain the same, yet the tree itself has changed in physical ways that are near impossible to reverse, to reconstruct the original form. That means any rewrites that may follow see a different tree than the first. Of course, you would have expected this, and actually intended it. However, if the second rewrite is looking for particular nodes and/or patterns now clouded by the operation of the first rewrite it is unlikely to perform as expected, if at all.

This means that in any system that may be expected to perform multiple rewrites, the order of execution of these rewrites is paramount to their operating effectively. You cannot in general develop a rewriting procedure that operates in isolation of the rest of the system. You must consider the rewrites that may have occurred before and those that are yet to come. A compiler designer working with only a few built in rewrites has a immensely difficult time grafting these together. Can you imagine how near impossible it would be to allow for just any rewriting procedures to be strung together?

Of course, you would have to limit your rewrites to those that only made orthogonal non-disruptive changes to the tree, adding a node here or there, preserving the physical tree at the same level of node granularity. Maybe that's why when people talk about AOP they always point out trivial examples like doing method call logging. Certainly, that's a rewrite that only adds a few orthogonal instructions.

Matt

Xen meets its Omega

mattwar — Wed, 14 Jul 2004 16:11:00 GMT

I got a surprise in my inbox this morning. An email from Erik Meijer read:

The impossible has happened: X# became Xen, Xen became Comega, and Comega has shipped.

http://www.research.microsoft.com/research/downloads/default.aspx.

Enjoy

Matt

Stuck in the Slow Lane

mattwar — Thu, 10 Jun 2004 22:33:00 GMT

Been writing in C++ lately. Man, I feel disconnected, alone, naked. So many pointers, deref'ing, addresses, pseudo-maniacal linked lists all over the place. Where's ArrayList when you need it, or managed arrays. I want my managed code back. Please, give it back.

Was this what is was like to program, you know, before? I don't remember it being so harsh. I suppose you never do until after you've been shown the way. Then everything becomes so much easier, you get so much more productive, your brain is happy, and you forget the past, forget the struggle, the fight against the machine, the compiler and the language.

Header files. Need I say more? Giant header files, ever member function listed. Monstrous class declarations, poorly factored code. It's a nightmare. You laugh. You think you are free of the horror. But just wait. It sneaks back up on you. Before you know it your back in the hard-cruel world, stuck in the slow lane waiting for a compile.

Wouldn't it be grand if the operating system refused to load apps written in anything but IL?

Matt