Why does functional programming matter?
Functional programming is the new hotness right now, but regardless of the hype, most modern programming languages are introducing FP-friendly features that make a big difference to software quality:
- Delegates
- LINQ
- Read-only properties
- Pattern matching
- Readonly value types
- Tuples
As we’re adding features and applying good software engineering practices, we’re actively working to make sure that the code we’re trying to implement is correct. An OO first language like C# provides support for this thanks through features such as static typing, scoping and access modifiers. If you make a mistake, the compiler will warn you. Although those features are great, there’s more that can help the developers to reason with their code and make sure that the code that was either added or maintained will behave as expected and have little to no ripple effects in the system(s).
That’s where functional programming shines. By embracing concepts such as immutability, developers have access to an implementation that is more predictable and less likely to have a mutation that wasn’t foreseen since you have 100% control on what is updated.
More to this is the declarativeness of the implementation. The F# type system evolves through expressions which makes the code declarative when embracing the functional paradigm. Here, we can focus on the concepts and make sure the workflow pipeline corresponds to the business requirements.
Another thing that helps developers in functional programming is that the strict type system is actually consider a friend. There’s a saying in the FP community that says once it compiles, it works. What’s to be understood with functional programming is that with a type system that is more strict, it like having compile-time tests that make sure the implementation is correct.
What is F#?
F# is a functional programming language that makes it easy to write correct and maintainable code.
F# programming primarily involves defining types and functions that are type-inferred and generalized automatically. This allows your focus to remain on the problem domain and manipulating its data, rather than the details of programming.
Are there any company in the industry that use F# internally?
A month ago, I stumbled across a list of companies using Haskell in the industry. This kind of project was interesting and I couldn’t find one for F#. To solve that problem, I created a list of companies using F# and the F# community was really great and helped me expand that list. I invite you to take a look at the list!
How popular is F# in the functional programming community?
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
So by consulting the TIOBE list along with the result of the developer insights from stackoverflow, we can see that F# is quite popular in the professional and hobbyist worlds. When looking at functional first languages, F# comes on top and is located in the top 5 of the most paid programming languages globally.
The mission of the F# Software Foundation is to promote, protect, and advance the F# programming language, and to support and facilitate the growth of a diverse and international community of F# programmers.
Are there any companies that benefited from using F# in their product?
Kaggle: [..] we initially chose F# for our core data analysis algorithms because of its expressiveness. We’ve been so happy with the choice that we’ve found ourselves moving more and more of our application out of C# and into F#. The F# code is consistently shorter, easier to read, easier to refactor, and, because of the strong typing, contains far fewer bugs
Counterparty Risk Handelsbanken: Our first delivery is approaching rapidly and F# has proved itself as a real life-saver. We started off using C# in many places but have since then moved almost entirely into F# due to its ability to reduce the amount of code required and its simplicity when developing massive parallel computations. The performance is phenomenal. We can now re-calculate the entire bank portfolio from scratch in less than a second and the response-time for single deal verification calculation is far below 100 milliseconds(the original demand was 200 milliseconds to make the application usable for electronic markets). Although some gains are to be attributed to how we have built our calculation models, F# made it possible for us to implement our algorithms and techniques with very little code and with a huge similarity to the original mathematical models and regulations (which is important for verification of correctness). We have also been able to use the support for Async-workflows producing code that is simple and clear and easy to understand but still runs in parallel when required.
Bayard Rock: we work hard every day in the pursuit of new approaches towards anti-money-laundering. Before adopting F# there were often months of turnaround time between development of an idea and actually testing it on real data in our production environment. F#’s succinctness and composability allows us to rapidly iterate on ideas while the type system acts as a safety net. On top of this, it has the advantage of being a first class member of the .NET ecosystem and so integrates seamlessly with our Microsoft stack systems. This means that instead of months we can often see our ideas come to life in just days.
The benefits of functional programming in F# have given us a great advantage over our slow moving competitors. After three years of using F# our products have consistently gotten significantly better each year without sacrificing stability. Our clients often are amazed by how we can quickly adapt to unique challenges and how we can find the bad guys hiding in their data much more effectively than anyone else. Little do they know that it’s largely thanks to our secret weapon, F#.
GameSys: F# is becoming an increasingly important part of our server side infrastructure that supports our mobile and web-based social games with millions of active users. F# first came to prominence in our technology stack in the implementation of the rules engine for our social slots games which by now serve over 700,000 unique players and 150,000,000 requests per day at peaks of several thousand requests per second. The F# solution offers us an order of magnitude increase in productivity and allows one developer to perform the work that are performed by a team of dedicated developers on an existing Java-based solution, and is critical in supporting our agile approach and bi-weekly release cycles.
What are the added benefits of F# for a C# team?
F# is not cluttered up with coding “noise” such as curly brackets, semicolons and so on. You almost never have to specify the type of an object, thanks to a powerful type inference system. And it generally takes less lines of code to solve the same problem.
F# has a very powerful type system which prevents many common errors such as null reference exceptions. And in addition, you can often encode business logic using the type system itself, so that it is actually impossible to write incorrect code, because it is caught at compile time as a type error.
Although F# is a functional language at heart, it does support other styles which are not 100% pure, which makes it much easier to interact with the non-pure world of web sites, databases, other applications, and so on. In particular, F# is designed as a hybrid functional/OO language, so it can do almost everything that C# can do as well. Of course, F# integrates seamlessly with the .NET ecosystem, which gives you access to all the third party .NET libraries and tools. Finally, it is part of Visual Studio, which means you get a good editor with IntelliSense support, a debugger, and many plug-ins for unit tests, source control, and other development tasks.
The conciseness of the type system in F# is particularly useful when doing domain driven design (DDD). In DDD, for each real world entity and value object, you ideally want to have a corresponding type. This can mean creating hundreds of “little” types, which can be tedious in C#
Type inference and low overhead type definitions. One of the major reasons for F#’s conciseness and readability is its type system. F# makes it very easy to create new types as you need them. They don’t cause visual clutter either in their definition or in use, and the type inference system means that you can use them freely without getting distracted by complex type syntax.
What are the things that F# can do that are impossible or hard to do in C#?
In C#, there is a disincentive for creating new types – the lack of type inference means you need to explicitly specify types in most places, resulting in brittleness and more visual clutter. As a result, there is always a temptation to create monolithic classes rather than modularizing them.
In F# there is no penalty for making new types, so it is quite common to have hundreds if not thousands of them. Every time you need to define a structure, you can create a special type, rather than reusing (and overloading) existing types such as strings and lists.
This means that your programs will be more type-safe, more self documenting, and more maintainable (because when the types change you will immediately get compile-time errors rather than runtime errors).
F# was built with features so developers could easily reason with their code. Here’s a non-exhaustive list of said features:
- Values are not allowed to change their type. (And this even includes implicit casts from int to float, say).
- Records with the same internal data ARE equal by default.
- Comparing values of different types IS a compile-time error.
- Values MUST be initialized to a valid state. Not doing so is a compile-time error.
- Once created, values ARE immutable by default.
- Nulls are NOT allowed, in general.
In equal circumstances, is F# faster than C#?
That depends on the context. Natural F# code (e.g. functional/immutable) is slower than natural (imperative/mutable object-oriented) C# code. However, this kind of F# is much shorter than usual C# code. Obviously, there is a trade-off.
On the other hand, you can, in most cases, achieve performance of F# code equal to performance of C# code. This will usually require coding in imperative or mutable object-oriented style, profile and remove bottlenecks. You use the same tools that you would otherwise use in C#: e.g. .Net reflector and a profiler.
In any given situation, it’s always important to remember that profiling the code is crucial. We cannot make assumptions based on sentiment; we need to take decisions based on data. At the end of the day F# is compiled down the same IL and will use similar constructs.
F# and C# both emit IL (intermediate language) which is what’s run on the CLR. This is why it’s possible to have C# calling F# and F# calling C#. That brings me to the following point which is, they can have pretty much the same performance. For certain tasks, such as concurrency and parallelism, F# performs better because of its functional-first nature. If really required, it’d be possible to write imperative code in F# that would boost the performance of the implementation.
It does impact performance, but the order of magnitude is unlikely to be meaningful. It’s also worth noting that strictly immutable values that don’t change will have no performance impact.
“We made many improvements to F# and its tools,” Microsoft said in its release notes. “Performance and cleaning up existing experiences with .NET SDK-style projects has been the focus for this release. As always, we also received significant contributions from the wonderful F# community.”
Can the development team build the same kind of applications and tools with F#?
Yes. Being a .NET language, F# can interop without any problem with any library that was written in either VB.NET or C#. Another thing to take into account is that it’s possible to implement the data structures in F# and have a C# developer interact with those structures in their C# implementation.
Could you compare F# community resources vs. that of C#. Which one is growing at a faster pace?
As for this, because C# is more used in the industry, samples and documentation tend to be found in C#. I’m working with the F# community (outside of work) to add more F# samples and documentation out there,but that takes time. A thing to remember is that because they are .NET languages, if I find a fix in C#, I can surely apply it in F#.
Kevin
The focused generalist 
Leave a comment