F# – the function keyword

Mark Needham explains very well why the “function” – keyword of F# (not to be confused with “fun” – which is VERY useful!) is not that a good idea to use and why “match” is the better choice:

http://www.markhneedham.com/blog/2010/02/07/f-function-keyword/comment-page-1/#comment-37656

Be inspired -> Generalize -> Specialize -> Win

You know, in software development, there is a paradigm that is called “reusability”. It’s something that I follow very strictly. The code that I write utilizes all kinds of devices that are intended to support this end.

However, what is really important is to develop a workflow for creating code that has a very high reusability ratio and as little noise as possible. I hate noisy code.

My personal workflow can be described by the words I use for the title of this article. I will explain each step of the process (yes, including the winning!).

This article is written WITHOUT an example, intentionally. I WILL give you an example, in a later post, but for now, I will try to stay as abstract as possible because I think that… I should generalize first and specialize later!

So, what about…

being inspired…

You want to accomplish something. You have your goal, you have your task, your tools and your environment.

This, actually, is a two – step process. First of all, there is the goal – and then there is the means.

The “proof of concept” – phase falls hereunder – and this is the only phase where I actually encourage you to write bad – TERRIBAD – code. It’s throw – away – code, it is only there to teach you “how stuff works”. Treat it this way! Don’t spend time commenting every statement (a practice I will talk about soon), don’t put too much effort into building a structure. Just use your unit testing framework (or write a console application if you must) and find out about the technicalities.

Now we need to…

perform a polycontextual generalisation…

Big words! But the idea behind this is that every problem we look at in software development encompasses at least two domains – the problem specific domain and the domain of general functionality for the application at hand and future developments.

The result of looking at things this way is that the amount of “throw away” – code, the amount of “noise” is reduced and that the building of the “general purpose” library is facilitated.

In other words, reducing the level of abstraction for a moment:

The problem to be solved has a context in which the code will be executed and requires a supporting framework, and if it is only the worst, the most smelly noise that I know of: boilerplate code.

So lets make a virtue of necessity and convert even the shortest bit of boilerplate code into a library function.

Another step lower on the abstraction ladder:

Use lambda expressions (“anonymous functions” if you use a substandard language) / delegates, the strategy pattern, double dispatch, dependency injection (btw, you can combine the latter two into a single pattern, I will show you that in a later post) and…

…unit test everything. Don’t write console application code at this point, don’t assemble a “button1_Click” – “GUI”. Use unit testing, be very zealous about your test cases, think about the most absurd things you are sure of being non – issues.

Also, think about “what else could I use this for in the future” and…

(this is the lowest I will go in terms of abstraction in this article!)

…”isn’t this a candidate for my ‘ComponentModel’ namespace instead of ‘ConcurrencyExtensions’ or even ‘GUIWrapper’”.

Then – and ONLY then – you get the best out of it.

And this applies to all domains the code belongs to. Put the problem specific part of the code into library methods as well – and generalize them as much as possible, you will be grateful in a few months or even years, when a similar problem turns up again.

Working with functional language elements (LINQ) and AOP (which covers crosscutting concerns mostly, but I also use it to facilitate my extreme lazyness when it comes to writing code) I became used to creating library functionality like crazy and seeing the solution of the problem as the distillate of all the work.

Now, the next step…

Specialize the general solution again…

At this point, you have created library functions, an object model, interfaces and clases. Lots of them, hopefully. You have separated the concerns, you followed the law of demeter zealously, you inverted the control and maybe you even injected some dependencies.

Now it is time to use all the assets you created to implement the problem that led to the creation of all this wonderful stuff – you specialize the solution now to solve the original problem.

If done correctly (this takes some practice and experience) you will now notice that solving the problem that inspired you in the first place is a matter of…

…a few moments!

You don’t think about “which loop goes where” and “do I call this or that method” anymore. You have a framework now that solves your problem – and you know the problem itself (and the technicalities) so well that everything works like a charm, it is like magic.

And this is the moment when you found…

the “I – win” – button for software development

A few weeks later, you find yourself in dire need of a similiar solution. A similar environment for another data handling issue that is closely related. “lol” you say to yourself… “I can do this with a few lines of code, I have a thoughly unit – tested framework for my problem. There will be no noisy copy & paste, no boilerplate code, no time wasted on code that I have already written. Now I have become a developer with a code base at my fingertips.”

Congratulations.

Luca Bolognese presents F#

Get hooked:

http://channel9.msdn.com/pdc2008/TL11/

…so who is this guy?

Preamble: I will focus on the developer aspect of my personality in this blog. There is much more, but this doesn’t concern you. So lets this done, shall we?

—

I was a kid when I started programming those computers, utilizing some obscure BASIC dialect (in a graphical environment called “GEM” on an 8086 PC) in the 80s of the last century.

Obviously, I had no idea whatsoever I was doing, but… I learned the language without having a manual, I just had a short article about the BASIC language in a book about computers (a colorful one) and a few demonstration programs that were shipped with the interpreter.

However, soon after I managed to write my first “shoot the blue circle down with the red triangle” – game, an uncle of mine gave me Turbo Pascal 4.0 as a “summer is over, but take this for consolation” gift and I could finally start learning a real programming language, that forces one to utilize at least a minimal set of structured techniques.

It almost feels like dialetictical materialism (note: I dislike the real world implications this philosophy has brought with itself, but the idea itself is sound, as long as it stays in the theoretical domain, so please try to differentiate between a theoretical thought and beliefs)… progress as a liberating process.

This was my first epiphany – while I thought “omg Turbo Pascal gives me executables and cool console programs” the REAL power it gave me was total structure. Usable and clear control statements, procedures, functions, variable declarations and “units” (modules, a bit like static classes, because TP 4.0 had no OOP yet).

Yes, it was liberating, being able to finally understand what the code was doing and being able to reuse bits and ideas.

—

The same thing happened a few more times, later in my life. First came OOP (with C++), then component based development (mostly COM), distributed stuff, design patterns, design by contract, agile development and (closely related) test driven development, to name a few.

My latest discovery was functional development… with a legacy that includes languages like Haskell and the amazing OCaml, F# arrived on the scene as a functional language that, for the first time, provides a full language infrastructure (first class virtual machine, full blown runtime library, user friendly development tools) we know by the name of “.NET”.

—

So, what am I going to do with this blog now?

My intention is to offer a different view on programming. Getting away from all kinds of so called “anti – patterns” and “code smells” (in fact, it IS possible to create complex software that doesn’t even have a single moment of bad style, malpractice and doesn’t smell, not even a tiny bit).

It is, however, a question of discipline and the willingness to reflect upon ones own methodology.

But it’s worth the effort. Even if some of the things that I will present here (and I will NOT present anything that I don’t practice in the most zealous way) may seem futile or dispensable at first.