Op mijn huidige project moet ontzettend veel met getallen gegoocheld worden. De klant heeft bakken vol met berekeningen en formules om daar fantastische dingen mee te doen. Ik vind dit zeer intrigerend. Zo’n bedrijf bouwt al jaren zijn producten en heeft hierbij een hele afdeling voor softwareontwikkeling opgetuigd. Binnen het bedrijf komen en gaan de ontwikkeltools, de operating systemen, de nieuwste ideeën over software-architectuur maar er is één constante. Juist, die berekeningen?
Komt dit bekend voor?
Ik durf te stellen dat voor eigenlijk alle bedrijven hun formules (ik denk aan financiële instellingen zoals banken en verzekeraars en aan productiebedrijven met krachten, uitvloeiing van kunststof of draaicirkels) gerust als de kroonjuwelen kunne beschouwen. Iedere investering hierin om ze nog beter, sneller en betrouwbaarder te maken is een juiste keuze.
Dit betekent dus dat er een goed versiebeheer moet zijn voor de formules, een goede distributie van de gereedschapskisten waar ze inzitten (dll’s of services) en ik stel me voor dat er ook een complete geautomatiseerde teststraat (lees buildserver met minimaal unittests en een code coverage van 100 procent) voor draait. Waarom 100 procent terwijl dat een hele opgave is? De kosten tegen verkeerde resultaten uit formules wegen niet op tegen de kosten van de enorme stap van 80 procent naar 100 procent. Er kunnen bedrijven failliet gaan of zelfs mensenlevens op het spel staan.
Dus…
Formules schrijven lijkt simpel maar het kan al snel ingewikkeld worden J
Nu heb ik zelf regelmatig formules mogen implementeren en dan ga je aan de gang met static methodes om stateless te gaan rekenen en je wordt overweldigd met reeksen en complexe structuren om door te werken. En dat wordt dan dus het ijdele handwerk in C# code.
Maar de laatste weken heb ik mijn tijd doorgebracht met de PluralSight presentaties over F#. En ik vind het kijken van inhoudelijke filmpjes over een nieuw stuk technologie zowiezo heel nuttig (Het kost veel tijd om zoiets op te zetten en daarom rolt er meestal uiteindelijk echt de essentie van een onderwerp uit) maar ik ben nu heel enthousiast over F#.
F# is gewoon een extra ontwikkeltaal voor .Net en wat het speciaal maakt, is dat het een functionele taal is. Dit soort talen is juist geschikt voor zaken als recursiviteit, reeksen, enz. Alles dus waar je óf van houdt óf wat je haat 🙂
F# is vooral interessant omdat eigenlijk alles types immutable zijn. En hierdoor kan er tijdens parallelle uitvoering geen conflict optreden waarbij de ene thread een gezamenlijke waarde overschrijft.
Helaas heeft Microsoft voorheen F# vooral willen postioneren als een programmeertaal waarin je ook Winforms apps kunt maken en waarmee je ook een WPF app in elkaar kunt draaien. Persoonlijk had ik hier geen trek in, dat kon ik al met C# en ik zag niet het nut in om een nieuwe taal te leren om hetzelfde te kunnen doen wat ik al kon.
Maar F# is superieur als aanvulling op C# als het om berekeningen gaat. Kijk maar eens naar de volgende vier F# functies:
module Functions
let Func1 (x) = 2*x*x + 5*x + 3
let Func2 (x) = x*x + x
let Func3 (x) =Â x*x*x - x*x + x
let Func4 (x) =Â x*x*x*x + x*x*x - x*x + x
Dit is de hele inhoud van een F# file in een F# library project. En ja, dit zijn gewoon vier functies. Sterker nog, dit zijn vier methodes. Om dit te bewijzen, heb ik deze aangeroepen vanuit C#.
Het enige wat ik moest doen was een reference leggen vanuit mijn C# console app naar de F# library:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("CSharp Host");
for (int i = -5; i <= 5; i++)
{
Console.WriteLine("Result of Func1 {0} = {1}", i, Functions.Func1(i));
}
for (int i = -5; i <= 5; i++)
{
Console.WriteLine("Result of Func2 {0} = {1}", i, Functions.Func2(i));
}
for (int i = -5; i <= 5; i++)
{
Console.WriteLine("Result of Func3 {0} = {1}", i, Functions.Func3(i));
}
for (int i = -5; i <= 5; i++)
{
Console.WriteLine("Result of Func4 {0} = {1}", i, Functions.Func4(i));
}
Console.WriteLine("Press a key...");
Console.ReadKey();
}
}
De uitkomst is dan:
Dit kan natuurlijk ook met een unit test gecontroleerd worden. F# is tenslotte een volwaardige .Net taal dus MSUnit is al voldoende:
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
// ARRANGE
var x = 5;
var expected = 78;
// ACT
var actual = Functions.Func1(x);
// ASSERT
Assert.AreEqual<int>(expected, actual);
}
[TestMethod]
public void TestMethod2()
{
// ARRANGE
var x = 5;
var expected = 30;
// ACT
var actual = Functions.Func2(x);
// ASSERT
Assert.AreEqual<int>(expected, actual);
}
[TestMethod]
public void TestMethod3()
{
// ARRANGE
var x = 5;
var expected = 105;
// ACT
var actual = Functions.Func3(x);
// ASSERT
Assert.AreEqual<int>(expected, actual);
}
[TestMethod]
public void TestMethod4()
{
// ARRANGE
var x = 5;
var expected = 730;
// ACT
var actual = Functions.Func4(x);
// ASSERT
Assert.AreEqual<int>(expected, actual);
}
}
Dit is wederom simpel en werkt direct:
En de code coverage is ook 100% 🙂
Zoals je ziet wordt alles als types ook goed ingevuld. F# kent dus geen variants maar alles wordt inferred, afgeleid. Dit maakt de functies compact en flexibel.
De F# functie blijkt met integers te willen omgaan:
En C# snapt dit:
En:
Dus doe eens gek en ga eens naar http://www.tryfsharp.org/ en speciaal naar http://www.tryfsharp.org/Learn/getting-started . Hier kun je online in de browser kennis maken met F#.
En kijk anders eens de hilarische video op Channel 9 van Luca Bolognese
Prima entertainment en je steekt er ook nog wat van op. Al is het maar om je behoefte te vervullen om jaarlijks een programmeertaal te leren.
Meer inhoudelijke informatie over F# is te vinden op: http://fsharp.org/
Sander van de Velde 