Functional programming and blind adoption of 3rd party software.
Training
I was lucky enough to have had the pleasure of attending an introduction to Domain Driven Design, CQRS (coined - in part at least - by the presenter himself) and Event Sourcing by Greg Young at Skills Matters in London last week. It was snappy, contentious - at times - and very informative and definitely gave me a lot of food for thought, I now have a reading list as long as my arm. As an added bonus, the people who attended, as well as Greg himself, were approachable and easy going, as the beers after will testify to.The background to me getting on this course, is that we are currently going through a massive set of architectural, infrastructural and cultural change at my current employer, and this course has set me up to be asking more searching questions and provide input on some of the stuff we are currently doing and are planning to be doing soon.
I'm not going to write about any of the above though, a quick search will elicit a million articles, and will be a lot more informative about them than I could be, at the moment.
Piqued Interest
However, the thing that interested me most was a small nod to functional programming. I'm aware of functional programming but didn't study it at Uni and didn't really know the differences between imperative and functional programming until I actively searched it out.
Greg mentioned that he was using Erlang which has been developed by a phone company for future use internally and this had given him ideas about how to approach programming in the imperative world, from different angles. I was hooked, anything that can make me think about problems differently is worth knowing about.
Containerless
Everyone knows, by now, that the best (and maybe only) way to arrange your n-tier architecture is to introduce your favourite IOC container after separating out your dependencies and introducing myriad mapping between the layers. You are now at the pinnacle of software architecture. Or not, perhaps.The problem with introducing a container, or any 3rd party library for that matter, is reliance on that bit of software being stable or reasonably straightforward to leverage. When they are neither or worse, life becomes painful. Greg raised this point and it really resonated, as I have been there before. No matter though, he suggested a way around it!
Container Bowels
I have been in the bowels of Unity (of Enterprise Library fame) trying to work out why I'm getting a Stack Overflow exception after cycles in my composition root (where the dependencies are registered) have been inadvertently configured (obviously only knowing that bit retrospectively). Whilst at the same time the job I'm actually supposed to be doing is on the back burner.The solution. Ditch the container. I had searched for alternatives registering dependencies without a container, in the past, but gave up after about 10 minutes of Googling and didn't think to attempt it any other way. I know it's not a great leap to do all the wiring up in one place but its easy to become blinkered when something, in the main, seems to work even if it is a painful from time to time.
Partial Application
Partial application is a technique used in functional programming which allows a function to have some of its arguments to be made invariant or hard-coded in effect. This function can then be used as an argument to another function giving the same result each time it is invoked. This allows composition of dependency trees . For example, a function which took a connection string, which returned a data access component could be used by multiple functions which required data access. (Code example to follow)This approach can be used as a way of performing dependency injection and allow you to get rid of the container and see all of your dependencies up front in one place without 10k lines of code acting as an intermediary. You will inevitably lose some flexibility and features but on the other hand you may gain simplicity, performance increases and less headaches, so make a judgement call; you might just have defaulted on this before. It will certainly make me think twice.
Haskell
After learning about this I wanted to know a bit more about functional programming and came across Haskell and an absolutely fantastic tutorial website Learnyouahaskellforgreatgood. The first few chapters are fairly easy going and I am now up to the section about Currying (related to Partial Application) and it was only at this point that I had to refer to my mother tongue of my day to day programming (C#) in order to understand exactly what was going on, as I couldn't quite visualise or translate it.Step forward Jon Skeet and his distillation of the concepts in C# Jon Skeet currying in C#. This helped to highlight a potential issue or advantage, perhaps, I end up trying to transpose one language into another. If I was starting programming from a clean sheet I wouldn't suffer from this turmoil.
Haskell is based on lambda calculus and its easy to see it was used as an inspiration for C#'s LINQ - which has seen "lambdas" being awarded first class citizenry by the language designers.
And so it dawns on me that by using LINQ and lambdas I have been using (at least in essence) functional programming without even knowing it.
I particularly like the heavy use of recursion (not always optimal but definitely elegant) the quick sort example (although noted "cheesy" by the Haskell tutorial website author) shows just how elegant Haskell is and, shown side by side with a C example, is about 10 times smaller!
Collections and their processing are a fundamental tenet of Haskell and simply splitting lists into heads and tails makes you reason about where that approach might have been useful before. I am yet to get to folding but I'm hoping this and other features, gives me some new ideas about how I can approach problems in the imperative world in the future.. I've still got lots to get through and it may just turn out to be an academic exercise but its better than Coronation Street.
Comments
Post a Comment