Category Archives: F#

Why should you use F# when your team uses C#?

0
by

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:

  1. Delegates
  2. LINQ
  3. Read-only properties
  4. Pattern matching
  5. Readonly value types
  6. 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.

More here

 

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!

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.

2019-09-10_17-21-19

2019-09-10_17-00-33

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.

More here

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.

Reference

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:

  1. Values are not allowed to change their type. (And this even includes implicit casts from int to float, say).
  2. Records with the same internal data ARE equal by default.
  3. Comparing values of different types IS a compile-time error.
  4. Values MUST be initialized to a valid state. Not doing so is a compile-time error.
  5. Once created, values ARE immutable by default.
  6. 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

Advertisements

Implementing a Stack in F#. Tail Recursion.

0
by

Viral F#

Since Push requires stacks to manipulate its data, we need an implementation of this data structure. There is of course a .NET implementation, however, it is not a “functional” data structure, in a sense that it is mutable. It is easy enough to implement our own, purely functional, immutable stack.

F# list is a logical choice for an underlying implementation. It derives from Seq (i.e. implements all IEnumerable flavors), has a useful length property which we would like to have for our stack as well:

What remains is to implement basic operations, which are all static members of the Stack module.

These are pretty straightforward. pop function has a slight quirk: we would like to return both the value of the head of the stack as well as “the rest” of the stack. So the return type in this case is a tuple.

Another slight irregularity: stack functions work on…

View original post 270 more words

Bullet points formatter

0
by

Hey guys,

So this week I worked on a small code kata. The purpose of this project is to simply be able to format text into a bullet point like any text editor allows you to do it. To complete this challenge, I decide to use F# since it’s so great for prototyping and get fast results. The project had the following requirements:

  • Produce an outline of headings
  • Heading values are provided

Here’s an example of what should be printed in console :

  1. Software development is

A. An awesome thing to do

2.  Why do code katas ?

A. They are

i. Entertaining

ii. Challenging

So as we can, we have three different level of formatting to do on the string and heading values are provided for the formatting. Those requirements led to the following code :

code language="fsharp"]
 open System
 open System.Linq 

type Indexes = {
     Primary: int 
     Secondary : int
     Third : int 
 }
type BulletPointStyle =
     | NumberedStyle 
     | LetteredStyle 

type HeadingWeight = 
     | HW1 
     | HW2 
     | HW3 

type Heading = {
     Weight : HeadingWeight
     Text : string
 }

type Node = {
     Line : Heading 
 }

type Outline = {
     Text : string 
     HeadingIndexes : Indexes
 }
 with 
     member x.addContent str = { x with Text = x.Text + Environment.NewLine  + str }

let updateIndexes (o: Outline) (h: Heading) = 
     match h.Weight with 
     | HW1 -> 
         let indexes = { o.HeadingIndexes with Primary = o.HeadingIndexes.Primary + 1; Secondary = 1 ;Third = 1 }
         { o with HeadingIndexes = indexes }
     | HW2 -> 
         let indexes = { o.HeadingIndexes with Secondary = o.HeadingIndexes.Secondary + 1; Third = 1 }
         { o with HeadingIndexes = indexes }
     | HW3 ->
         let indexes = { o.HeadingIndexes with Third = o.HeadingIndexes.Third + 1 }
         { o with HeadingIndexes = indexes }       

let determineBulletStyle (hw: HeadingWeight) = 
     match hw with 
     | HW1 -> NumberedStyle
     | HW2 | HW3 -> LetteredStyle

let getLetter (index: int)=
     (("ABCDEFGHIJKLMNOPQRSTUVWXYZ".[index-1]).ToString())

let formatTextNode(n: Node) (o: Outline)= 
     let header = n.Line
     let mutable text = ""
     let style = determineBulletStyle header.Weight
     let indexer = o.HeadingIndexes
     match style with 
     | NumberedStyle -> 
         text <- (indexer.Primary.ToString()) + ". " + header.Text
     | LetteredStyle -> 
         let head = 
             match header.Weight with 
             | HW2 -> String.Join("", Enumerable.Repeat(" ",4)) + getLetter indexer.Secondary
             | HW3 -> String.Join("", Enumerable.Repeat(" ", 8)) + String.Join("", Enumerable.Repeat("i", indexer.Third))
             | _ -> ""
          text <- head + ". " + header.Text 
     text

// Folds an Outline and a list Nodes to an Outline
 let formatTextOutline(nodeList: Node list) =
     ( { Text = ""; HeadingIndexes = { Primary = 1; Secondary = 1; Third = 1 } }, nodeList) 
     ||> Seq.fold (fun outline node -> 
         let text = formatTextNode node outline
         let outline = outline.addContent text
         updateIndexes outline node.Line
     )

[<EntryPoint>]
 let main argv = 
     let nList = 
         [
              { Line = { Weight = HW1; Text = "Software development is" } } 
              { Line ={ Weight = HW2; Text = "Super fun" } } 
              { Line ={ Weight = HW3; Text = "But challenging" } } 
              { Line ={ Weight = HW3; Text = "And rewarding" } }
         ]
     let outline = formatTextOutline nList
     printf "%s" outline.Text
     0 // return an integer exit code

[/code]

So basically, the process is made thanks to formatTextOutline and formatTextNode. Through those functions, I can create the Outline record that holds the formatted text and the indices for the level of formatting (Indexes). When I get in formatTextNode, I can first establish the heading style of the line thanks BulletPointStyle discriminated union(DU) type. Using the style enables me to know if I only have to take care of numbers or the letters. When I have to deal with characters, the HeadingWeight DU becomes handy to see whether or not I’ll be using a single tab (4 spaces) or a 2 tabs (8 spaces).

There you go ! 🙂

Kevin out

Why F#?

0
by

Didactic Code

If you’ve been following along with my posts over the past six months or so you can probably imagine that I’ve been asked some variation of this post’s title more than a few times. One question that I keep getting is why I chose F# over some other functional languages like Haskell, Erlang, or Scala. The problem with that question though is that it’s predicated on the assumption that I actually set out to learn a functional language. The truth is that moving to F# was more of a long but natural progression from C# rather than a conscious decision.

The story begins about two and a half years ago. I had pretty much burned out and was deep into what I can only begin to describe as a stagnation coma. I stopped attending user group meetings; I cut way back on reading; I pretty much stopped…

View original post 2,559 more words

Posted in F#

Book Review: F# for C# Developers

0
by

This book looks interesting enough to give it a try. I’ll order a copy today.

The Education of a Programmer (Me)

I recently read F# for C# Developers by Tao Liu. As usual, the disclaimer is that I received a copy of the book for free in return for the review. This one was a challenge. Not because of the programming paradigm shift from imperative driven programming in C# to functional programming in F#, but because the density of the book and my having read a different book on F# rather recently.

Mr Liu is most certainly an expert on F#, both from his work at Microsoft and this book. However there were times when I felt a little frustrated in reading the book. My favourite chapter of this book was Chapter 3 where he examines design patterns which can be found in C# and then applies these patterns to F# code. It remains dense reading, but it demonstrates those patterns very well. Mr Liu takes the notion, as I read…

View original post 295 more words

Posted in F#