A good turnout this week, with I believe 8 or so attendee's, and some great discussions.

So let's get into it...

First off while everyone was arriving Keith talked about his recent experiences with F#, including the implementation of the classic TDD "bowling game" exercise - which he's been blogging about lately, I myself have bitten by the F# bug and have been grappling with getting my head around the concepts in the language this weekend - it's a lot of fun, especially pattern matching and pulling apart the type system - but I've got a few more "ah hah" moments to go through before I've grokked it I think... Considering this language is going to be mainstreamed into the VisualStudio.Net product, and it's suitability for building parsers (among other things) I definitely think this is a skill worth adding to the toolbox.

From F# Keith then talked about his tangent into non-Von Neumann programming languages, and in particular Function-level programming, which works at a higher level then functional languages, suited to working with array-level information i.e. matrices - allowing for variable-free development (Tacit programming) it lets you do some pretty amazing things.

The function-level language that Keith took a look at was "J" (an APL-like language) which is cryptic - just like APL (at least to the uninitiated) but incredibly powerful i.e. a tacit implementation of the quicksort algorithm looks like this:

quicksort=: (($:@(<#[) ,="" (="#[)" ,="" $:@(="">#[)) ({~ ?@#)) ^: (1<>

Yes, no variables, and one line of code! Compared to the C# equivalent which is normally 12 to 20 lines long, depending on braces etc.

Keith highlighted some good points - in that it actually becomes very readable once you understand how the language is put together, and it certainly shouldn't be discounted before your attempted to understand just what it is your discounting - I guess the message here is don't be a blub programmer.

I actually wonder wether working at this higher level actually makes the barrier of understanding what's going on lower in many cases - for instance, no variables = no mental state you have to keep in your head as you look at the code... I suspect long-term it would probably take less time to understand what this one line of code is doing, then reading through 20 to 30 lines of C# code, with variables, recursions/loops state and scope - especially with a set of unit tests to back it up, providing the specification and aiding in understanding what's expected/happening in your snippet of J code.

And of course, function-level programming is well suited to parallelization and optimization, more so then value-level or functional languages - a popular topic among the group.

After that a little discussion was had around SSIS, ETL tools etc. - largely caused by a protagonist (who shall remain nameless ;o) stirring up some trouble in the dot.net.nz Sql mailing list this week - the net effect is that there are largely disparate views between many of the senior DBA/Dev community at the coal face vs. Microsoft, marketing etc. To quote the message:

"SSIS is a dog, great for BA's, but otherwise is always seems to fall short!".

Everyone basically agreed with this statement - SSIS just doesn't provide a good experience for developers and admins, take a look at Ayende's list on his wiki if you want a bit of a (depressing) laugh at the common pain points for developers.

As much as Microsoft employees reiterate that SSIS "is not a dog" - the reality is drawing pretty pictures with a sub-par UI is not productive for a developer, and the end results are notoriously brittle and hard to collaborate with other developers on.

On the flip side, we discussed alternatives i.e. cutting your own code, windows services, emerging tools like Rhino ETL - which a few of us like, but just can't justify dropping into a clients infrastructure at this point because it's a bit of a unknown quantity and quite immature - a bitter pill for a Microsoft-only organisation to swallow, because it's not necessarily mort-friendly at this stage.

After that we had the discussion about the IKVM.Net, boojay and grasshopper java <-> .net technologies - there still doesn't seem to be a silver bullet here for solving the problems of developing in .Net with the BCL etc. and then having it just "work" in the JVM on a Linux virtual machine, suitable for dropping into say the Amazon elastic cloud (EC2) - the more reasonable approach seems to be developing in java and then targeting either .Net or the native JVM, or developing in vanilla C, on a side note  I spent some time evangelizing about the boo language, and more importantly it's great extensible parser/compiler experience which makes it so very easy to write template engines and DSL's with it.  I'm still not 100% sure why mono doesn't work well in this case, but by experience a few have had a lot of trouble getting it work properly.

A short warning and Rant was had about Flash 8 (Action Script 2) by Peter - believe it or not, it doesn't have native support for 64 bit integers ... I haven't got time to verify it, but I'm assuming it's probably because it represents all numbers as double-precision floating point values. Grim tidings!

Following that we had a discussion around Framework development - this is a topic that's cropped up a number of times, so I won’t go too heavily into it... but basically it focused around a few discussion points:

• Building applications with re-use in mind, and in fact building frameworks/factories for producing the application i.e. spend 80% or more of your time building the framework, and 20% of your time implementing the project with the framework, with the view of reusing/re-purposing the framework "next time".
• It was argued that building frameworks is often YAGNI.
• Why are parts of software you’re developing not naturally reusable?
  • Largely because development practices aren't focusing on composability and enforcing the principle of single responsibility.
  • Test driven design encourages Composability.
  • Without an IoC container it may be a little challenging at times.
  
  
  
  
• Frameworks often require additional skills to maintain.
  • Is there a risk in letting Junior/Intermediate resource make changes?
  • Does the difficulty in finding/retaining senior resource make frameworks risky?
  
  
  
  

Lastly, we touched on other subjects - but my memory is a little hazy on the details:

• The challenges in Porting data binding from WinForms to WPF when upgrading an application.
• Brief thoughts on the features in Lightspeed 1.1, I like the aggregate-level validation support - something I forgot to mention was that the source code is available with the enterprise edition, which is great news - and that Ivan Towlson has joined the Mindscape team, you can see his first blog post here.
• The Xero revenue announcement - a lot of us have either worked / started startups in the past, or are in still in the process of "starting up" - so it hardly came as a surprise that progress is slow... I think Nic Wise had it about right in this post - this led onto a discussion about the nature of the banking market, competing products, white boxing etc.
• The fact that expression web is pretty sweet, and that there is still a load of html-only work out there.

At any rate, see everyone in 2 weeks time (29^th of this month) - and thanks all for coming along, it's encouraging to see the numbers climbing back up after the Alex James exodus (btw, he has an msdn blog now, for anyone who missed the announcement).