LambdaConf's video: Phillip Carter- You got FP in my Enterprise - C 2019

Functional programming is often touted as simple and robust. But how does it fare in the realm of enterprise software tooling? Learn about how F # is used to build F #, and how the challenges of being a Visual Studio product affect our approach to writing F # code! F # is used to implement the F # language and F # tools. As you would expect, various functional programming idioms are applied in its development. Although using a language to implement itself is not uncommon, very few languages must also act as a product within Visual Studio. The duality of being an open source, functional language while also being a product within a larger enterprise product presents significant challenges for F # and preferred approaches to functional programming: * Compatibility is king. The language, core library, and tools must be built such that code you wrote 10 years ago can still compile and run today. This immediately rules out breaking changes and can also present intense difficulty when implementing a larger feature that spans the whole codebase. * Performance is also king. Ensuring that a feature emits performant code at runtime is critical. Even more critical is that the implementation of a feature and tooling performs well if it is repeatedly executed in a long-running process. This forces us to write things in a different way than you may expect. * People can come and go, but the product remains. Code that can be quickly understood and worked with is incredibly valuable in the long-term. However, this does present a danger of reducing new code you write to be a “lowest common denominator.” * Today’s programmers inherit the mistakes of yesterday’s programmers. A large and long-lived codebase that has undergone many organizational changes carries the artifacts of past teams’ priorities. Some choices that made sense five years ago are now irrelevant, but the code cannot simply be ripped out. * Change is the only constant. Visual Studio and .NET evolve faster and expand their capabilities. F # and the F # tools must keep up and innovate in the midst of this change, forcing difficult re-prioritization and tension with certain parts of the F # community. * Impedance mismatches are everywhere. Although F #, being a .NET and Visual Studio language, is a boon, a primary tradeoff is that there are numerous non-FP pieces that must be plugged into. Reigning this in is not often straightforward, especially since not all concepts are something you can merely interface with. By the end of this talk, you should have a strong understanding of some of the challenges we face when evolving F # and F # tools. Approaches to solving these challenges may also be applicable to the broader functional programming community, especially as functional programming languages breach further into the mainstream.