Comments

FireGarden wrote:

If I met you two gay cow boys in a bar I would kick both your asses.

You hang out in a lot of gay cowboy bars, Firegarden?

Awesome video, guys!

evildictaitor wrote:

If your database was immutable (i.e. you never wrote to it), SQL would be purely functional, and achieves massive parallelism.

And be nowhere near as useful as a database where you could change data.

Great video!  I have been debating the pros and cons of reflective programming with somebody in the Techoff threads who is adamantly against it, and many of the points I would have liked to have made in favor of dynamic languages and better type systems were made here in this video and in a more eloquent manner.  Keep up the good talks, Charles!

I am looking forward to the new and improved MSDN Help!

Here's an off-the-wall suggestion (not necessarily for April and her team but maybe for a clever dev out there with some free time):  a command-line interface to MSDN Help a la UNIX man.

Here's another:  write a Sidebar Gadget with MSDN Help.

MetaGunny wrote:

I've watched all of the related videos.

However, I'm assuming that you reference reading other material because you yourself don't truly understand the why.

If you did, you could have explained it.

No, I referenced them, because they explain some of the benefits of pure functional programming where the minimization of shared mutable state can enable opportunities to simplify the construction of highly concurrent software.

Not sure why I wasted my time though. You're rude.

Why functional programming? See Joe Duffy's video on ParallelFx here on C9 and Simon Peyton Jones' papers on Software Transactional Memory on the MS Research site for a couple approachs to improving the concurrency of applications in this multi-core age we live in.

It's nice to put some faces and voices to the names and avatars!

I really don't like the "shiny objects" analogy.  Try asking IBM how many of those conversions from mainframes to Microsoft software were "green fields."  Now that Microsoft is the landscape, not IBM, suddenly those "green fields" are "brown fields?"

The disconnect here is why those libraries that are only available to C++ programmers are not available to .NET programmers.  Maybe you should have made them available to .NET programmers?  Not only are they not available, but there is no publicly available roadmap for when that might happen, if ever.

I loved the IntelliSense discussion!

So monads convert functions from this

int f(int x)


to this

int* f(int x)


where int* is int plus some encapsulation of relevant things that don't fit into your functional model, e.g., I/O, mutable state, etc.  Lambda functions are then used to transform int* back into int.

int* => int


The lambda functions allow the converted functions to seem monoidal like the original functions by isolating their side effects from the original functions.