• About
• Contact
• Clients

< Previous Page

I’ve been thinking about my last post, and I realized it was a bit imprecise.

See if we drill in on the axis “unsafe” versus “safe” and “useless” versus “useful” as described in the video Programming language Nirvana, Erik suggests introducing another axis that measures how precise or imprecise (or for embellishment “honest” and “dishonest”) types are in the language.

Now how exactly is this preciseness to be measured? Well the type of a method is precise if in addition to the value that is returned, it also specifies the potential effects involved in computing the result. For instance, Java’s throws clauses, or Haskell’s monads. Interestingly, if you apply this measure to dynamic languages they are trivially precise simply because they specify no type at all.

But if you take for example a property such as System.DateTime.Ticks, it is imprecise because it claims to be a long, where as in reality it is a value that changes over time, rather rapidly in fact J.

Now except for mathematically oriented languages like Haskell, which is precise, safe, and useless, most practical languages are by this definition imprecise.

So if you are really pedantic and extremely precise in your definition of “functional” programming, like say Erik, then most languages do not hit the Pure Functional Programming bar. Indeed Erik would be much happier if we agreed on a less precise word for languages that encourage a functional programming *style*. Perhaps something like “closure oriented programming” would make him happy? Examples of closures range from anonymous delegates and  lambda expressions in C#, VB and F#, to even more powerful closures constructs like object expressions in F#.

Notice that a language can add excellent features that encourage a functional programming *style*.  Like pattern matching which is found in both in F# and Erlang, or concurrency oriented programming found in Erlang which makes it dirt cheap to create threads, so cheap in fact that you can build clever abstractions for fault tolerant code.

Still if we return to the question of precision, one of Erik’s favorite interview questions is to ask how you might simulate one language effect with another. For instance spawning up a new thread is such a powerful effect that you can simulate mutable cells with it.  

The point being that, just because you remove one imprecise language effect doesn’t mean you can’t simulate it with another even more imprecise effect…

If you want more, I suggest you check out these mind expanding videos:

Programming language Nirvana

Brian Beckman on Monads

Joe Armstrong

Joe Armstrong and Erik Meijer

Dave Thomas and Erik Meijer

F# videos

Happy viewing…

Okay so I've finally got around to setting up my own msdn blog.

Over there on that blog I will post all work related posts. So if you are at all interested in the EntityFramework, the Entity Data Model and Metadata you might want to head over and subscribe...

In the meantime this blog won't die... but I suspect the other one will get more attention going forward.

Okay I’ve been pretty busy recently... at Microsoft they have a phrase for this phase “Sucking on the firehose”.

But last friday evening I got to sit down with Wes Dyer, who sits about 5 doors down, and have a bit of chat (yes I talk code on Friday night).

My first question was one that has been bothering me for a while. Indeed ever since about  5 months ago when I showed how you can use Extension methods to make IDataReader play nice with LINQ…

To refresh your memory:

public static IEnumerable<IDataRecord> Enumerate(this IDataReader reader)
{

    using (reader)
    {

while (reader.Read())

yield return reader;

    }
}

The key trick is that IDataReader extends IDataRecord too, so you can use the IDataReader Read() method to move through the IDataRecords.

Anyway what concerned me was this, what happens if you do something like this:

foreach (IDataRecord record in reader.Enumerate())
{
   break;
}

It looks a lot like the iterator will never leave the using {}. Now since we are relying on the using pattern to automatically dispose the reader, I worried that the Close() method would never be called on the reader, and we would leak connections.

When I asked Wes about this, he said ‘that is amazing’, see Wes had just come out of a 2 hour meeting covering that exact topic!

It seems that what I feared, was indeed a problem in C# 2.0. But Wes implemented a fix for C# 3.0 to insure that iterators if interrupted will dispose of resources appropriately.

Now if only I could remember how Wes said the C# 3.0 compiler expanded that statement under the hood!

I have a vague recollection of how it works, but before I share it I need to be 100% sure... stay tuned!

In the meantime checkout section 10.14.4 of the C# spec... you'll see that calls to Iterators actually involve the creation of an Enumerator Object that implements IDisposable, the Close() on this object is put in a finally block to guarantee it is called, and it does the magic that insures all inner block resources are disposed.

... is an opinion lots of C# snobs hold.

There is just one problem.

We C# snobs are often completely ill informed and ignorant when it comes to VB.NET, not that that stops us judging...

I really need to re-learn VB so I better understand VB and C#'s relative strengths.

But thanks to people like Erik Meijer, Paul Yuk and the ever vigilant Nick Randolph I already:
1) ...think VB is cool
2) ...understand that VB has significant advantages over C# in many scenarios
3) ...know VB has, and is gaining more, compelling dynamic capabilities

Paul Stovell has been working on an interesting extension to LINQ called SyncLINQ.

The basic premise is that when you data bind to a LINQ expression today, if the underlying data-source changes you have no obvious way of knowing whether you should refresh the user interface. SyncLINQ fixes this by raising events from the underlying data source through the various intermediary enumerations as appropriate, so that if the resulting data actually changes you can be notified with an event.

The code revolves around a call to datasource.ToSyncLinq(), which returns something that raises changes to the underlying datasource as events and flows the event raising through any chaining of typical linq comprehensions (where, orderby, select etc)

Paul has put together an interesting demo showing how this works. The code is not available yet, but I will definitely check it out when it is.

Unfortunately it currently looks as if you have to call lambdas for each operation directly Paul and I both find it more convenient to use lambda's directly for each operation:

.ToSyncLinq().Where(p=> p.Firstname == “Paul”).Select(p=>...

rather than using a standard LINQ comprehension:

from p in DataSource.ToSyncLinq()
where p.Firstname == “Paul”
select new …

4. Metadata Management

Metadata is the foundation for information infrastructure and is found throughout your IT systems: in service registries and repositories, Web semantics, configuration management databases (CMDB), business service registries and in application development.

“Metadata is not just about information management,” Cearley said. “You need to look beyond that. Metadata is everywhere.”

I've got a little time before I start at Microsoft, so I am enjoying some nice light reading about the future of data. I thought I should share what I've read so far:

The “What, Why and How of Master Data Management” (MDM).

Two things prompted me to get more familiar with the terminology around managing master data, my recent discussions with Ayende and MDM was mentioned in passing by a colleague.

The End of an Architectural Era (It’s time for a complete rewrite).

A paper hypothesizing that the age of the RDBMS is almost over. Fascinating reading, even though some of what they take as a given is debatable and some of the solutions presented are trivialized.

The motivation for the paper is that the general purpose RDBMS is already being out performed by at least 2 orders of magnitude in specialized areas like text search (i.e. yahoo,  live and google), Data Warehouses, Stream Processing and Scientific databases, and the remaining sweet spot of online transaction processing (OLTP) is seriously under threat.

The basic premise being that RDBMS were conceived in a time with vastly different hardware constraints to today, and yet RDBMS’ remain fundamentally unchanged.

Dare’s thoughts on Amazon’s internal storage system called Dynamo are pretty good reading too.

Incidentally, unless I am very much mistaken, according to the “End of an Architectural Era” paper, the redundancy OR consistency tradeoff discussed by Dare can be handled by single threading each node’s actions assuming all data is in memory and nodes are time synchronized. But as I said this is one of the areas that seem a little glossed over…

Single threading??? Very much a contrarian view given the times we live in. But I have to say that the arguments all have surface validity.