Learn an alternative interpretation of the railway-oriented programming paradigm to improve your understanding of the pattern.
- [Instructor] Before we wrap up, I just wanted to talk a little bit more about railway oriented programming. The reason I want to talk about it more is 'cause it's something I actually found it quite hard to get my head around and I tried for a long time. It's rather unfair to expect you to understand it just in the course of one video. I'm going to share my own personal thought process about this. First thing to say is that Scott Wlaschin's website F# for Fun and Profit is definitely the definitive source for this. I'm going to share with you the way I think about railway oriented programming.
In fact, I use a slightly different analogy from the one that Scott uses. Think about a production line for cars. It consists of a series of operations. Add this or that body part, paint the bodywork, fit the windows, each of which could go well or might go wrong. When dealing with things that go wrong, you've got a number of choices. One is to shut down the whole assembly line and fix the problem. No one wants that. In our analogy, that's like letting the whole program crash when there's an error.
A second option is to have a multiplicity of diverging branches on the production line for handling good and bad cars. That's, to mixed metaphors, the pyramid of doom scenario with lots off if then branches to defend inner functions against bad inputs. A third option is to pull the problem car right off the line as soon as you detect the problem and cart it off using a special transport mechanism to be dealt with. That's the equivalent of raising and handling exceptions which is the conventional way of doing things in the .NET C# world.
This is simple, but thinking of it in assembly line terms, it means you have to provide a path away from the assembly line from every single operation, down which you can drive a forklift or whatever to carry away the problem car. But here's a final option. Just put a big red label on the car, saying 'don't do anything further to this car, it's a dud'. Maybe you could also put a note of what went wrong on the label. In this view of the world, you also have to program every robot and tell every worker they shouldn't do any work to red labelled cars, they should just let them trundle by on the assembly line.
And, of course, you have to separate out the red labelled cars at the end of the line so they don't get sent to the dealers. That's exactly what's going on here. By calling bind and bind2, we're doing the equivalent of programming our assembly line robots to ignore red labelled cars and just let them pass by down the line.
- Defining values and calling functions in F#
- Defining and identifying discriminated unions
- Working with if-else expressions
- Writing unit test
- Using type providers to access data
- Analyzing data with collection functions
- Plotting data using the R type provider
- Using railway-oriented programming to handle errors
- Integrating with Twitter
- Deploying an F# application to Azure