I’ve seen a few posts flying round between Ivan (1,2) and Ayende (1) re: meta programming in C# v.next and the implications of it being a statically typed / pre-compiled language...

It’s an interesting thought, but I can’t help wondering if implementation of a rich meta-programming environment in C# - allowing changes at both a class and instance level at run-time - wouldn’t go against the original spirit of the language itself, for me at least I’d be looking for a different language if I yearned for meta programming on a daily basis... one that was built from the ground up with my desires in mind.  Take a moment to consider if C# had been built with meta-programming in mind from the outset, would we have bothered with declarative attributes?... ruby seems to get on fine without them (well at least until you try to integrate ruby with Java or .Net libraries)... and what about interfaces, what’s the point of them?

Language spirit is an interesting thing – I don’t think it’s something intangible (this is science after all), but often it’s something that’s difficult to put into words, because it’s a feeling coming up from a rapid and subconscious judgement call as you work with a language (ah la Blink) – it’s also something that’s difficult to appreciate until you start sitting down and thinking about writing a programming language of your own (what you haven’t? For shame!)... and it builds an immediate appreciation for languages like C# and ruby and there founders – there are lot of difficult decisions, compromises and reasonable defaults that need to be decided on – and a massive amount of jiggling to make sure it all fits well together – so that you can finally identify the essence of the language – and worst of all you’re not just having to satisfy your internal subconscious judgement calls, but a large audience in the development community, so that your language will be adopted by people because it feels "right" to them.

I still gravitate towards programming language pragmatics as a good book for examining the spirit of languages throughout the years and guises – it's definitely a book computer science student’s should all be armed with on their first year, though I doubt many will be interested in the nuances of Fortran today.

Now, following up on that – I’d like to contrast meta programming with functional programming... are we in need of meta programming as we move towards a more functional approach by necessity (to reduce the overall complexity of software, and take better advantage of existing/emerging hardware by working at a higher level of abstraction, allowing for judgment to be made on our behalf i.e. about parallelization) and what makes more sense for a language like C#?

Personally I see C# moving more and more towards providing a pleasant bridge language between the imperative world and the purely functional word (weighed in favour of the imperative world, where as F# is weighed in favour of the functional world) ... and as such it makes more sense to me at least to draw inspiration from that domain, then dynamic languages and meta programming... just my opinion of course. 

Given the time frames between C# versions – IronRuby should be mature enough by the time c# v.net arrives that it should be a moot concern, and IronPython is already pretty capable in the meta programming stakes as well, if you can hack the whitespace sensitivity.

Funnily enough (and this a bold claim I know :) – but I think the pattern matching support and associated features in F# would prove far more valuable tools for solving many of my day to day problems in C# than meta programming would be, when I take a subjective look at the code I write and the goals it’s generally trying to achieve combined with the existing features and practices I’ve already embraced in C# (IoC/DI) it looks to "click" together in a much more cohesive manor.

Thoughts?

So I see both Andrew, Nick and Alex J have some thoughts on languages, and of course Rowans post sparked it off... and people talk about beautiful languages, mentioning expressiveness in the same breath. 

Personally I love how expressive Ruby is - I think potentially because I got my first exposure to ruby after reading Why's poignant guide a while back (I see there are new chapters ...oooh) which was quite surreal compared to how I say learnt C++ (from reading the Borland Turbo C++ manual when I was 11, also my first exposure to OOP)...

When I code in ruby I feel like I'm telling stories... I dig that :)

So Alex J mentioned that extension methods let us achieve much of the syntactic sugar that ruby provides (though obviously in ruby's case this isn't so much syntactic sugar as core mechanisms in the language itself) - and of course Lambda expressions are helping too, but does expressive == good 100% of the time?   I don't think I'm qualified to say, but I can't help but feel that a language which is very expressive, isn't necessarily the easiest to manipulate and refactor, so I may not be as productive and it may not feel as fluent to me... I quite liked this resharper horizons post which suggests that tooling support should probably influence future language design - could that requirement possibly fight against an increased level of expressiveness in a language, will compromises need to made, or is nirvana just around the corner?

As for C# vs VB.Net - large clumsy keywords are only a probablem until something like Resharper steps in... when I'm developing I see a lot of unusued space on the right hand side of the editor with C#... if VB.Net fills it up, and I'm not typing any harder to get there, why should I care - hell it'll probably make a VB.Net Resharper Jedi look more impressive then the C# equivalent, he'll be producing more characters ;o)

OK, well I figured this post should at least have some code... I'd feel uneasy otherwise... so how about:

So now we could try and do this....

Alas I don't think C# will ever match ruby in this game, no matter how we try to nudge it there... and until the development community figures out where the healthy place is to draw the line in the attempt, we may be doing more harm then good by pushing for it, sacrificing discoverability/maintainability for expressiveness.   Maybe that's just dogma, and expressiveness makes code inherently easier to maintain in the first place, so we don't need to care.... time will tell.

Of course I could be wrong, I am a little sleepy ;o)