Speaker 1: 00:00 Hey there, merge conflict listeners. Are you looking to make absolutely stunning mobile applications? Of course you are. I love building mobile applications, but I'm not all that great at designing them. That's why I use the Aurora controls toolkit as all sorts of beautiful and professionally designed controls for your xamarinforms applications. They come with dozens of highly customizable controls that are based off the hottest and most desired designs in the industry. It's really, really great. They have super simple licensing per app, which means that you buy one license per app. That's it. It's super easy to get beautiful, beautiful controls, special offer for merge conflict listeners, 40% off. All you gotta do is go to Aurora controls.app Aurora like the Aurora Borealis, Aurora controls that app and enter coupon code merge conflict. All one word for 40% off. Thanks to Aurora controls for sponsoring this week. All right, Frank, you are on the road this time, not me. How's it going? Speaker 2: 01:05 Yes sir. I am sweating away in San Francisco. Everyone told me it was going to be cloudy and rainy and I was like, great. I love cloudy and rainy. It's hot. I feel like I'm in the desert. Jane's, Speaker 1: 01:17 yeah, I'm about to head to San Diego for TwitchCon and I'll, by the time this comes out I'll be back. But I also fear as though maybe they're going through a heat wave based on what you have told me about San Francisco. So we will [inaudible] Speaker 2: 01:30 see how it goes. Either way though. Uh, I love San Francisco. I haven't been here in a long time, so it's fun. I'm in a fun part of the city. I don't even know what to call this area, so I'm not going to insult anyone by making up a name, but it's a fun part. Lots of restaurants, lots of bars. So aside from the heat, go to a cool F sharp conference, uh, open F sharp here and hang out in San Francisco. What more could you walk in this world? That sounds awesome. Yeah. Well maybe you could also hang out with the one and only Craig Dunn perhaps. I have to track him down. He, he, he runs fast. You know, he's hard to catch. Speaker 1: 02:09 Yes, that's true. He does run very fast. Well that's really cool. I heard about openF sharp because on one of the [inaudible] community stand ups, uh, Phil of Carter was talking about open F sharp. I think he may be there giving a presentation. I'm not positive or he was just talking about the conference and then you told me that you are going and that you were giving a talk. And then I looked up the title and I tried to find an abstract but I couldn't. But I found the title, which was why I wish I wrote my app in F sharp and I go, wow, that is a great name for a title. Like somebody went to marketing one Oh one and then I clicked on it to find out more information and there was nothing there. So I had to ask you, what the heck are you talking about? And I want you to just kind of maybe talk about this session, maybe just give the session Speaker 2: 03:00 for the podcast listeners. How does that sound? Oh boy. Enough sharp episode. It's been so long. Thanks happening James. That's all happening though. It's all happening. Yeah. The lack of an abstract adds mystery to the presentation. Don't you wonder what Frank's gonna say? No. Uh, my biggest apologies to the open F sharp organizers. I am a terrible person at being organized and hitting deadlines. Jamesy know this. Everyone who's dealt with me knows this. I stink at deadlines. So, but I promise there will be content and I appreciate this chance because honestly, I need to practice this presentation. Let's see how it goes. Let's see if it's interesting. Let's see if people care about F sharp. I know you out there. I know you do. Speaker 1: 03:44 They're out there. They're out there and they care about it. And I care about too. And I, I honestly was intrigued by this, by this session and you, when we were thinking of topics, I really did think I was like, man, I've never, we've never had a podcast in which someone did a presentation. And then I also don't know how that translates into a podcast. So I'm very curious how this is gonna work. So let's just go out with the formal openings here. Okay. So if you're at a comp class, um, I can introduce you. So our next session today is by, uh, Frank Krueger. Uh, it is why he wishes he wrote all of his mobile apps or apps in general and F sharp. And if you don't know about Frank, I'll let me tell you about his great abstract on the website. His bio. Um, Frank is a mobile app developer. He specializes in iOS and.net programming. He's into graphics, AI, robotics, and programming language. Speaker 2: 04:40 There's multiple programming languages. And without further ado, without further ado, Frank Krueger. Yay. Oh gosh. Thank you for that. Applause. Wow. I can't believe you applauded for 10 minutes. That was so miraculous. You're all such wonderful people. Thank you. Thank you. Well, I'm done now James, we can't do this as an actual presentation. I need you to ask questions. So first thing I'm going to say is this exam, this presentation has a lot of code examples, which if you're not paying attention or looking down at your email, you're gonna miss a lot of this. So you might have a lot of questions as I speak. It's, I'm hoping James, you can, uh, play the role of the not paying attention audience that has lots of questions. How's that sound? Yeah, yeah, let's do it. I'm excited. I will be here and yet and and yeah, this is going to be a fun one and, and this, this podcast will just happen. Speaker 2: 05:35 So I'm excited about it. I have no idea where this is going. Okay, I'm ready. Okay. All right. Uh, so yeah, the title is why rush? I wrote my app in F sharp. So this basically comes down to the fact that every time I start a new project I can't decide which programming language to use because I love F sharp and I'm about to do a whole presentation on the many ways that I love F sharp. And yet I write my apps in C sharp sometimes or my libraries in C sharp. And this whole thing is about when I'm writing in C sharp or the things I miss about F sharp, why do I sometimes wish that I would just go file new project and start that puppy over and go into at sharp James, do you ever have programming language dilemmas or you're just, you're all in on the C sharp, right? Speaker 1: 06:23 No, I'm, I'm all in on the, on the C sharp. No, I mean I used to have the dilemmas back in the day of what framework do I use to start my application. Is it a traditional iOS or Android app with the native UI UIs in those regards or is it a Xamarin forms based application? Nowadays it's nowadays I just go all new hotness. Right? I'm like app shell, C-sharp XAML hotness, compile bindings. Like I mean it's use the latest and greatest and just go for it. Um, but I never had the, in my entire entire professional career. I think that I've been really lucky because I've never had to decide between a, a language. And when I did have to decide between a technology stack, I had the range to be the one deciding it at the company. So the mobile platform, I got to decide what we were going to use as a company and I got to pick Xamarin. So I think I've been really lucky, uh, overall. So I've never had these debates. And, and I'm kinda curious what goes into your debate of why you would go with one or the other one, I guess. Speaker 2: 07:31 I guess I've just always been, what's the word? Promiscuous with programming languages. Um, I've, um, th throughout my life I've just like to using off the wall languages if I thought they serve the purpose better than other languages. And that was actually my whole attraction to the CFLR is the common language run time. The idea was you could write things in many languages using the appropriate language for the problem. And that always really attracted to me that there was this unified runtime, a unified library system, language independence. I love that freedom. The problem is with freedom comes choice and with choice comes decision and I'm not great at making decisions. Sometimes C also me missing deadlines. So I guess that is my personality disorder in play. But there are differences between the languages and I can tend to make engineering tradeoffs. In fact, I want to open with why would you use F sharp for app development? Speaker 2: 08:30 Because it's better. Simple as that. Number one, no semi-colon. So my calling is stupid. It's a hold over from simple parsers make your parts are better. Number two type inference. And guess what? Swift, it's not good enough. Guess what? C sharp. It's not good enough. If I have to declare parameter types, you've lost type inference. I don't want to type types. It's a of typing. Okay, I'll typing without the typing. Okay. All I know. So, so, okay. So I think when, when you say that there's VAR, right? And we have VARs and there's labs. Yes, but you're saying in parameters or in constructor properties, there aren't any. Correct. Yeah. So when you declare a method in C sharp, you are required to give the types to the parameters to the formal parameters. This is the same in a Swift. Uh, this is the same and I'm trying to name another programming language. Speaker 2: 09:28 I'm sure go in rust, but I don't know Java. Caitlyn. Thank you James. Yep. A C plus. Plus even they have the auto keyword instead of R. yeah. Oh, Oh. But C sharp has a much more powerful type inference system and it's able to figure out parameter types, not just local variable types. And for that reason you can write code that looks like a dynamic language like Python or Ruby where you don't give types with Java script I should say also where you don't give types for things cause it's a dynamic language and who knows what's going to happen. Magic. Um, but for us who like types who like the performance benefits and the correctness benefits, it's nice to have the power of a type system without necessarily having to, sorry, without using the keyboard to make the letters of a type without typing the words. Speaker 2: 10:25 Okay. So, so, so, so let me get this right. Like in JavaScript there, there aren't really any types. I mean there everything is very loosey goosey. It, it could be an integer, it could be a string who knows it. It's a, everything's an object basically. So you're saying though that that F sharp just there is a type, it's just smart enough to figure out what the type is. Exactly. It's just a strongly typed to C sharp and the same way that you can type VAR and it's not an object, it's strongly typed. It has a really good type, it's just saving the program or some physical work or some clarity. I would even argue in the language sometimes I would say the types get in the way of the readability of something. Um, and F sharp function definition can simply be Le, um, get item space item ID equal. Speaker 2: 11:19 There's no saying it's an integer, there's no saying what it's going to return. It's just saying here's a function, here's this parameter name, let's move on with our lives. Hmm. Is this Y pattern matching sort of became essential? Uh, like a very, it seems like pattern matching is a very core fundamental piece of F sharp where for a long time pattern matching hasn't been a core fundamental piece of C sharp. Is this the reason behind that? Um, sorry, I'd have, I'd have to say no. Um, I'd say the more core for there is how do you represent polymorphism that is given data, how do I change which functions, how functions work on that data and object oriented programming like C sharp, we have virtual methods and so if we have a specialized type, we override that specialized method. But whoever's using that object doesn't really know. Speaker 2: 12:12 They're just calling the method and polymorphism takes over. Virtual dispatch takes over in the right thing happens. And F sharp, you have pattern matching because in functional programming you don't really use polymorphism like that. You don't have virtual methods. So instead you're looking at the data itself and deciding what to do. And that's why pattern matching is so important because you're looking at the data, not saying data, go do this. You're saying the data looks like this, therefore I will do that. Got it. You're sort of flipping it around. Yeah, the parameter stuff is just literally, it's a more powerful type inference system. Um, anyone out there into programming languages and computer science will know exactly what I'm talking about. Um, you can have something that infers types that does the whole program or just as partial parts of the program. C sharp and most, uh, languages out there. Speaker 2: 13:06 Just do the partial one because it's a much simpler problem. Got it. Okay. I'm sold so far. I'm liking what I'm hearing. Frank continue. This was supposed to be my lightning round. I was just gonna rattle these ones off, but I appreciate you asking questions. We're not going into the thick of it yet. So, but along those lines of lightning ones, global functions, James, I'm sorry, I just like writing global functions. I come from basic, I'm trying to write a program. It's supposed to do this. Just let me write the global function. That's a bit of a joke. But in some ways it's not a joke. So liberating just to have them back. Nothing wrong with statics. They're fine. They are fine. Yeah. Yeah. I've, I've seen your code. There's global function everywhere. There are, I'm sorry, James, um, styles. But now the big one, and this is the truly largest reason why I use F sharp and it's immutable data, and I find that immutable data is where you don't have properties on your objects that you can set. Speaker 2: 14:13 You can only get things from it. So once you've created the object, that's what the object is. Some people call these value type objects. That's what they're called. And Swift and others, even C plus plus, I think. Um, but the idea is that I can't track mutation when there's multiple threads happening. It's too hard. And multiple threads exist in this world because that's the way operating systems work. That's the way the cor works. That's the way libraries have been designed and there are these fundamental problems that I've always had. I should say a lot of this is personal fundamental problems that I have had with multi-threaded programming that I just find that immutable data solves and it's also a lot of other problems. So now for the rest of this presentation, I'd like to dive into deeper topics about specifically how I use this feature of immutable data and other things too. Well basically when I'm writing C sharp, these are the things I wish I had. These are the problems they can solve, that kind of stuff. Speaker 1: 15:19 And, and I'm interested because for immutable data, I have had to use immutable data in iOS applications because iOS applications, you can correct me if I'm incorrect here, but there is mutable and immutable like dictionaries and, and if you attempt to mutate an immutable object, it cause very upset at you and does not let you do that. And it throws exceptions and early, I think it's still lets you, it still lets you write the code, but it will throw an exception and make it happen. And for somebody, like in my experience, it hasn't really ever had to worry about immutable data in the C sharp world. I'm going in and writing. It's funny cause it's like I can access, I can access that immutable object in C sharp, which is like a very foreign thing because it's an iOS specific thing that was created. And I'm curious why those things are so important. And I'm assuming that this is the stuff you're talking about, right? Speaker 2: 16:22 Yeah. I'm about to give her a love letter to immutable data. Basically it should show you how many problems it can solve and all that stuff. Yeah. Uh, it's funny, I actually really liked the design of the Apple libraries where they split most of the collection class like that. But even the string class, so for example, in C sharp, our string classes immutable, you can't change the characters and the string. Once you've created a string, we accept that. But in Apple world they have both immutable strengths, just like the C sharp one, but they also have mutable strengths and like you said, but the collections, they have a raise and mutable arrays. Technically we have this in.net world we have, I read only collection and I read it only lists, whatever it's called, those things, but no one uses them. The fact is we just don't. Speaker 2: 17:15 In C-sharp we just pass around collections. Who owns it? Who's mutating it? Who knows? Who cares? Let's just hope no bugs happen. I guess it's that questioning that. I also don't like, uh, once you've created an object, you know, it's just going to be that object and it's going to be that object for the rest of its life and there's no uncertainty involved. So overall, maybe that's the thing that I liked most about it, but James, let me start once again with multithreading and let me say, no matter how advanced our languages have gotten, C sharp, we have had a sink in a wait forever. They are wonderful. They have taken care of 99% of the multi-threaded programming that we've ever had to do. They are the greatest thing on the planet and don't look back. F F sharp also has these F sharp panic before C sharp with um, a sink. Speaker 2: 18:10 They have the async key word also. They're fantastic. But the fact is if you are doing native programming, the OS itself, libraries that you use, third party libraries are multi-threaded. You cannot avoid it. For example, Apple scene kit, which you use for three D rendering, it's actually a wonderful library, very easy to use. It's physics and it's drawing updates are run on our background threat. And yet you create the scene graph on the UI thread. Fundamentally, there's already a disconnect here. This is a multi-threaded program. You can't avoid it. There's an, you can't async await yourself out of this. This is how the operating system is choosing to execute this program. Are those the worst? Yeah. For forced multithreading so more examples of this. Yeah. Um, sensors, James, you know, this one, uh, excelerometers gyros, GPS, those can come in quite fast. And so the operating system puts those on a background thread in almost all conditions. Speaker 2: 19:18 You don't want to run those on a UI thread and woopsie Daisy. Now you have a multi-threaded app whether you wanted it or not, you're forced into it. Another funny one that I don't think a lot of people run into but I personally run into all the time because I write what are called document based apps on iOS and Mac and this means that you have files say file close history, you can use time machine. Lots of funny stuff with UI document based apps, but a funny thing about them is your document gets serialized on a background thread and yet all the mutation you do, all the work you do is generally on the UI thread and there you are another forced multi-threaded app. Speaker 1: 20:03 Yeah. You see this all the time, especially in more complex applications. If you're doing web requests or you're doing web sockets or signal large GRPC or any of these or background updates like you're saying, you know, for instance in the Hanselman forms application, I have a background worker that updates data in the background, but I also have a UI that's rendering that stuff. So applications very quickly I would say go into maybe multitasked based and multi-threaded base operation or you might not be spinning up new threads but things are happening in different contacts all the time in your application whether you like it. Speaker 2: 20:43 Yeah, exactly. Um, I'm using the word threat here instead task because task can be a thread or they can share a thread. It's confusing, but the fact that they can be a thread means that you have to consider that they are a thread because that's the most unsafe scenario you need to handle the unsafe snoring out the say scenario, that's easy. So you have to consider that all your texts potentially can be threaded and on a multi CPU device they can literally be running in parallel. Yeah, that makes sense. Quite different from not single CPU running multiple tasks because in the end it's all serialized like your apps probably are going to work unless you wrote the worst code ever. It's the moment that you actually get onto multiple CTOs and you're actually using threads that well, you know. Thanks. Break basically. Yeah. Wow. Speaker 1: 21:35 Yeah. Before we continue, let's take another quick break here, Frank and thank our second sponsor and last sponsor today in Ferno, red technology. Listen, are you building a mobile app? Maybe you want an F sharp while. Listen, Frank's not always around. You need someone to help you. That's where Inferno read technology comes in. They specialize in all aspects of modern development, web cloud, IOT, mobile apps, TV apps, even Aster smart refrigerators. They will build you an app for your refrigerator hack, even your toast or who knows? Nowadays they have a long history of working with.net and Xamarin to build across platform applications. Listen, if you're looking for an amazing group of developers, stop. You found them in Ferno red, go to Inferno red.com tell them that Frank and James sent you and you will be thankful and you will love them. So thanks you in front of red for sponsoring this week's pod. Speaker 2: 22:27 Thanks in for no red. That's the cool one. Welcome to the podcast. Speaker 1: 22:32 So well immutables you love them threading. All right, important stuff. Go. Speaker 2: 22:40 Okay. Right, so let me get to the nuts and bolts of it here and that is that we have two choices here and that is do we lock data structures, which I think we all know have problems with that. When you do a big lock, things slow down, you can't take advantage of multiple CPS and all of a sudden you're dead locking the UI. Whether it's really deadlocked or not, you're just kind of stuck. Sad times. If you use lots of little locks, then you've most likely made a dead locking bug. It's just that's what happens. I've seen me myself, I've spent years working on multi-threaded programming. My very first job when I was 16 was a multi-threaded app. I worked in a many core group at Microsoft. Uh, I still write multi-threaded bugs on a daily basis, so you don't want to write locks. Speaker 2: 23:29 It's the worst. So the biggest thing that I like to show off with the immutable data is that you can get a lot accomplished with just by switching a reference, having one mutable reference and that is like, here is my input document and now switch out that input document to a whole different one. This is in contrast to C sharp where we do events and property changed events and collection notified events and things like that. Instead I say, why not just have one event? The whole big document has changed, that kind of stuff. So I go into um, examples of where that's useful. I don't think it's going to, these examples are going to work well on the podcast. That's why I'm speaking kind of high level here. But I just wanted to make the point that, um, what I'm doing here is creating one mutable variable with one event instead of having lots of mutation with many objects, with many events, just kind of simplifying the whole data flow of the app. Speaker 2: 24:33 Mm, gotcha. That makes sense. Yeah. Just creating this one mutable thing that can actually be changed and that's the only one that can be changed. And when you have one mutable thing, you can use interlocked code. So the interlock compare exchange, that is a thread safe way to switch around data. Uh, without, it's not a full lock, it's not going to cause your app to pause, but it is going to guarantee that multiple CPS will see the same memory at the same time. So there's this wonderful trick where, um, I create almost a transactional database. So say I have two threads and they're both writing to the data. First they read from it, then they write to it. It's a classic scenario and multithreading where uh, you can lose data because one thing reads something. The other one writes that the other one overwrites it. Speaker 2: 25:25 Bad things can happen. Well I show in F sharp code that it's actually a very easy problem to solve. Once you've decided that you're gonna use immutable data. Basically you read the data, you do your operation on it and then you check if the um, the, the route has changed. If anyone else has changed the data in the meantime and if so then you just redo the computation. You just keep spinning in five lines of code. You can have thread safe access to very large objects. I think it's a very powerful feature. I'm not sure if I'm explaining it very well. I'm going to have to work on this section but uh, it is the root of why I feel comfortable writing multi-threaded apps in F sharp. I think Speaker 1: 26:10 a good example of sort of what you were just saying with the like database scenario I think is really good or just when you are reading and writing data because if anyone has ever written SQL Lite code, like I have just database access. You create this one database. Like, usually my database repository is like a static thing that everybody is, has access to. And if it doesn't exist, it will create one. And uh, since it's static, the static construct will get called only once. And this will be really nice and everyone sharing and then Speaker 2: 26:44 around every single call into that database, I have locks around all of them because I'm very worried that if someone is reading data and I'm modifying data that's coming in from anywhere, then that will cause an issue. And that sounds like a scenario that a lot of people understand in which this would solve it. Yeah, exactly. You'll never get into an inconsistent state. And I should say all these problems started with basically a bug that I've had to solve in my app before and the bug I really struggled with even once. It's those kind of terrible bugs that once you understand them, you're still not quite sure how to fix it. You're like, Oh boy, that's kinda rooted deep into how everything works, you know, fixing that, it's going to be tough. And I, um, consistency has been one of those for me. Uh, I'm going to get to another part in this presentation right towards the end where I really hammering, uh, this idea that I have two pieces of data and it's critical that they be synchronized with each other and if they're not bad things happen and this all finally falls under that same category of consistency during multi-threaded apps is probably the hardest thing to achieve and the most obviously the most important. Speaker 2: 27:57 Yeah, that makes sense. Yeah. Yeah. Especially in that scenario that you just said where they have to be in sync, you know, or you might have a drawing application and what happens when you have multiple touch inputs that are accessing yeah. And those events are coming in at different times is a good thing that I was thinking about right now. Yeah. A that's at the end of the presentation. Maybe I'll move that one forward. Thanks for helping me out with this on your wall. Yeah, we're going to have to think that one through. Okay. Good themes are good. I'm still hammering in on. Um, I find events very annoying just in general. There are definitely ways to help yourself get away from events. You can use something like Xamarin forms that has binding, you can use, um, our acts reactive programming. I don't have a lot of experience with that, but I know they try to abstract over events. Speaker 2: 28:48 But in general, um, events are both a blessing and a curse, but they're a blessing because it's a very simple data model to understand. Objects have methods that's you poking objects and objects also have events that's them poking you back. It's our two way communication flow with objects. The problem is when you're writing UI code that touches native resources, it is so easy to accidentally register an event with a native object that doesn't get released at the right time. I think anyone who's written a long running mobile app has eventually made mistakes with, oops, I did actually need to unsubscribe from this event, but I didn't because event unsubscription isn't fun. Right? James? No, it is not fun. In fact, it's the, it's literally if there's a C sharp nine has any feature, I hope they just do anything with events. Just help us somehow with these things like give me an unsubscribe all, like ignore everyone command on them or something, I don't know, like turn off of it. Speaker 2: 30:00 So, um, there's one trick that I love doing in F sharp and this is better looking in code, but I'll try to explain it and you can do the same thing in C sharp. The idea is that any UI object that you have, if you're creating, um, a superclass, if you're creating a derived version of it, boy, words are failing me right now. Um, what you do is keep a list of all the events that you've subscribed to. Then when, uh, the view disappears, you unsubscribed from those events when the view appears, you subscribe to those events. It's a good pattern to have in your mobile applications. It kind of guarantees that if you have a many layered app, maybe you have a navigation stack that's 20 deep, that if you mutate some data in the top, most one, that you're not updating 20 different UIs. Speaker 2: 30:51 It's such a waste of CPU. And at the same time, this solves that problem of you forgetting to unsubscribe from events because the moment that view isn't on the screen, you'll unsubscribe from those events. Now F sharp makes this very easy because every event that you subscribe to returns and I disposable object. So you can just throw all those I disposable objects into a list and then when the view disappears, you can just go through that list and disposed, disposed to, dispose, dispose. Now in C sharp where you use plus equals and minus equals it's not quite so easy. This is where you should look into libraries like RX and using bindings from Xamarin forms as such. It's terrible. Speaker 1: 31:39 Yeah. That is one of the trickiest things. And even in a MVVM helpers now Speaker 2: 31:46 I have like week week, like event managers and all these things and cause you I for no, ah, that's a good pattern too. I like that. So if you're creating events on your own objects follow the week pattern where, um, if, if someone who's subscribed to your event, they get garbage collected and just magically disappear, then you stop sending events to them. It's good because you allow them to get garbage collected. You're not holding a strong reference to them. That's good for you. Uh, I just, no one does it. It's just, it's, Speaker 1: 32:20 it's not built into the front, you know, it's not, it's not a default. And that's what's hard about it. Right? So you have to go create your own, and then everyone kind of creates their own, and then all the implementations created equal. You know, xamarinforms has one other people have one, like I have one. So that's the, that's the tricky part of it. And it is a common thing. I honestly think Speaker 2: 32:40 probably in our templates, we don't subscribe successfully to things either. And even in, you know, scheduling events or, you know, geolocation updates or things like that, you've got to make sure you unsubscribed things. I mean, granted, most applications are short lived, but that doesn't mean that someone just is putting your app in the background and things are still kind of happening and you don't want the system to kill your app, you know, either. And that's a, you know, you want to be a good citizen, good digital citizen. Uh, for your mobile app that's sitting there? Yeah, for sure. I mean this was definitely more appropriate back when the iPhone had like 256 mega Ram. No, now we actually have Rams, so thank goodness for that so you can get so far without doing it, but every time I release my app or run into a performance issue, it's almost always because I left some object dangling around in some lists somewhere and it's still receiving update events and just hogging the CPU. Speaker 2: 33:37 It's I every app I write, I go through a memory analyzer just to make sure I'm not doing that because it's just so common for me. It's such easy mistakes to make. Yeah, it really is. To be honest with you, I, that's one thing that I, maybe there's analyzers or something that could really help with your code and be like, Hey, make sure you subscribe that, that'd be nice. That's a good one. That'd be, it'd be a hard one to write, but I mean if you could do a 90% one for sure. Give me a warning. You know, maybe it's a compile time check and a little warning output. I need to write more analyzers. So many mistakes. I wish I caught on myself. Speaker 2: 34:19 Well the next section is going to be on, on, on undo and we did a whole episode on under your James, so I'm going to repeat some of that stuff but not even here. I'm, I'm mostly just going to reference people back to that wonderful episode or somehow we talked about that for 30 minutes or more. I will, I will, I will put it in the show notes if people missed it. That is correct. We did talk about on do for way too long. I'm not sure why we did that. Is episode one 59 cut, copy, paste, delete on. Do you? Yeah. Yeah. I can't help myself so of course it made it into this presentation, but now my undo manager has become amazing James. It can do a full get system with branching and checkouts. I haven't written merge yet, but it's got all the other features. Speaker 2: 35:08 Isn't that cool? That was pretty cool. That's pretty cool. That's pretty cool. I'm pretty proud of it. Um, this is just as a quick recap. I have a pet peeve which is undue and in complicated programs undo is complicated and I hope you'll go back and listen to that episode and know that there are actually not terribly hard solutions to adding undue to your apps and I hope you'll consider doing it. And I show off that in F sharp. It's easy. Look I wrote a full get implementation and just 50 lines of code. I feel so bad when I do the like X lines of code thing but I just can't help myself. Just can't. I like it now. I'm sure it has. Good. Yeah, that's good. Yup. Yup. Okay. Scrolling, scrolling cause Oh Lord, there's a lot on undo. Okay. And, uh, this last topic is again a small throwback to one of our episodes when we talked about cancellation, but I bring it together. Speaker 2: 36:10 Um, because I noticed a pattern in a lot of my apps and that was there is an input data model. So I have a bunch of objects that essentially mirror the UI because it's what the user is interacting with. It's how I'm recording data and yet there's whole other bits of data. And just for just for a name, we need a name, I'm just calling it derived data data that came from the user input. And in C sharp and Algerian programming, we do this a lot with properties. So you might have a read only property that does a little computation based on other properties or this or that or an extract some data. And so we basically distribute this a complication, this complicated computation of derived data. The thing James is it can get out of sync. Okay. Imagine the [inaudible] case if like object a, I asked you give me this complicated piece of data. Speaker 2: 37:13 Object big, you need this other complicated piece of data. And then I try to relate those two together and I guarantee that object a didn't change or something like that and so I always felt very fuzzy about this drive data. Let me give some concrete examples. Maybe it'll make more sense. Okay, so let's imagine I'm writing an IDE. I've done this before. The input model is a bunch of text files, some file names and some content. No big deal here. Okay, gotcha. That's not enough data for the app to do its job. It's not enough data for me to do and tell a sense or coloring or all of that. What I need is a parsed version of all those files. I need a semi compiled version of it so I can link symbols together and look things up. Let's just call that the derived data. Speaker 2: 38:02 It's hard. Where did would you represent that in the C sharp model? You would generally end up creating a separate object but then mixing them together. Like what a text file would you be able to get to the symbols on a text file? Where do you put that property? It got confusing for me of trying to keep all of these computer datas in sync with each other. Another quick example, circuits [inaudible] yes you have. We have resisters, voltage sources, things like that and wires connecting them all together. But that's not nearly enough data for my app to do its job. It needs to look at how they're connected, create things called nodes, look at how the nodes are connected, find current paths and look at how they're connected. That's derived data, ancillary data, computer data that it needs to determine. If you go back to um, a drawing app, maybe it has primitive shapes like boxes and circles, but then it also probably has group and union and difference and intersection and all these higher order operations. Speaker 2: 39:05 So what the program actually needs is a set of pads derived from all of that data. It needs to do this big computation. And so a feature that I love a lot about F sharp. Wow. That was a long way to get to the punchline. Here's the punch line people. The feature that I love from F sharp is its domain modeling. Is that as much time as I spend designing the classes for the user input I can spend designing the classes that represent the data that my app actually needs and then I'd write a function that from the user input I can convert to the data that the app needs. This is not rocket science. This is just formalizing an idea that all of this data needs to be con can be computed all at once. It's global data and it needs to stay in sync with the input data. And so it's this conception that um, all these things should just go together into their own class hierarchy. Speaker 1: 40:06 Wow. Lost every Phil here. I'm still here, I'm still here. I'm still a promise. I'm selling what I promised section. I'm going to work on that section. But Speaker 2: 40:17 in the end it comes down to cancellation. So again, referencing back to past merge conflict deficits, I'll tell you how to do all of this, keeping these things instinct, this derive data and your model and the faith of cancellation so that you're not burning CPU so that your app runs efficiently. I'm going to work on that section. Everyone. Thanks for beta testing it with me. Speaker 1: 40:39 I hope that you put lots of links and like URLs to the podcast in this talk by the way. Speaker 2: 40:45 You're right. I'm, I'm adding those slides right now. They'll get their own slide straight to the merge conflicts. Speaker 1: 40:51 Get those downloads. That's right. Uh, all right. Yeah, I mean I kind of understand what you're going here, um, in Jan are all some, yeah, go ahead. I'm sorry. Uh, I think this one will be better when I actually get to show code because just talking in the abstract over the podcast, I definitely didn't nail it on that one. Anyway. Please continue. No, no, no. I think, I think that it's, it's fun to talk about the conceptual bits and pieces of it. And if, if, if listeners, I think it'd be good feedback, episode two, because we, we have attempted to do all sorts of different topics over the years and sometimes we do talk about like little code that we're like writing and that's in front of us and trying to describe that code and it is over voice only is such a different medium than being able to see it. Speaker 1: 41:43 But I think you did a very good job of describing the process there of what you're, what you're seeing in front of you as you, as you give this. Yeah, yeah. I'll just, I'll start with the problem. The problem is I have data, I have computed data, got to keep them in sync. That's the problem. And I'll, I'll work from there. And to the wonderful world of domain D type development, I mean it's true. Like when you're giving a presentation, it's like, here's the problem, here's how I thought I could solve it and like, here's what I actually did. Or like, you know, here's the problem. Here's why this thing doesn't work. And here's why this thing's awesome, right? That's usually the same thing. When I started giving presentations, it was, you know, when I first got started with development, I had two months to build a mobile app for everything. Speaker 1: 42:30 I didn't know what to do, but I did know C sharp and I knew visual studio and boom, Xamarin came into my world and everything was amazing. Right? And like in this instance you're like, well, we know that here's the problem and I know this type of architecture and I didn't know what to do about boom, F sharp came into the light and everything was amazing, right? And, and really I think nailing home, why the comparison between doing it in other languages and this, and I think what was nice is it's like you're like, well, you could do it this, right? You could, for instance, right walks around everything. If you had immutable, immutable data, you could do that. But here are the downsides of that and here's why this thing is awesome. And I think that is why it is a nice compliment to even just try to describe it and talk about the other things around it that listeners may already know. Speaker 1: 43:19 Look at that. And everyone, you just got free advice from a professional presenter. Thank you James. I'm, I'm, I'm making a storm and I'm shortening it to make it a story. Make always make it a story that that's the best. That's the best presentations is when it's really personal and, and even in just in general. And, and I might just start with the actual bug, but I'm like, here's the bug that I still think about it at night because it disturbed me that much. How many of you have had something similar? And like probably somebody will write for real for real. Uh, so that's a, the the rest is just going to be a review of everything I just said. Um, so we had a safe threading with a mutable data. I think we had some disposable subscriptions which just solve all your inventing problems. It's so wonderful. We have amazing undo buffers, see also merchant conflict past episode. And then we have domain modeling, not just of user input but of your computed data too. It's important as a potent combination bringing those all together. Yeah. So these Speaker 2: 44:32 are the, those are the big features that I'm miss, which as you can tell is mostly immutable data. Some day C sharp. I'll get it Speaker 1: 44:40 one day I did see that C sharp aid is getting this crazy pattern matching with um, curly braces. Have you seen this? Speaker 2: 44:50 Yeah, I, I need to play with it some more people keep talking. The pattern matching has gotten insane, but I haven't actually done much with it unfortunately. Um, but yeah, I definitely need to take a look at it. So they're letting you look inside the object itself, right? Like match on properties, is that what you're saying? Speaker 1: 45:09 Yeah. So you could do something [inaudible] so you could do, ifX is, and then you can put squirrely Bree curly braces and, and then you can say length. So you can say like, is it a length? Or you could say is, is an object and then length and then you get the property from it. It's something crazy. It's like bananas, but um, Oh they, they, they no longer say like you can do, sorry. Yeah, you do. IfX is, is, is curly brace, open curly brace, closed curly brace. And that is is not, no, Speaker 2: 45:46 yeah, I saw that on Twitter. People are saying you should now say X is object or X is curly curly and instead of saying a X does not equal now and I get it, yes, technically people can override the equals equals and does not equals operators. But whoever did that should be fired. It's just not a problem I want to deal with. Yeah, you can do that. But I can also have a point or to random memory and crush the whole process. So guess what? [inaudible] but I guess some people really like how it reads. If X is object, if X is curly curly, Speaker 1: 46:25 I don't know. Yeah, this is what, so this was what like Mads did, he did, let's say of a person and they have like a middle name. So like person dot first name, person dot. Middle name [inaudible] and that could be, no. So you could do a person question Mark. Dot. Middle name is, and then you could say, so it knows it's a string in general and then curly brace length, and then it's actually pulling out the length of the string, which is a property, and then you record turn the length instead of doing like is string middle name, middle name. Dot length. It's bananas, but then Philip Carter told me like this is basically F sharp style. I'll doing this forever. Speaker 2: 47:06 It's a lot shorter and I'm sure it's good. It's good. Yeah. They created a local variable inside the pattern match. Ah, yeah. You know there's some good things from functional programming. Other things are not good, so it's all stylistic. Does it read well? Does it, is it clear to everyone on the team? You know, that kind of stuff applies. Speaker 1: 47:31 Now the next topic that I think we should really have you cover is why I shouldn't have written my app in F sharp. Yeah. I keep debating whether to tag that section onto the end. I'm thinking I'm going to leave it off. That'll be at the bar afterwards. Yeah, it could be a very, like, it's almost like a love hate relationship talk or like why I shouldn't and yet should have like written might happen F sharp and then the back and forth of it because I'm sure like that's the, the issue is that sometimes you like starting in one language and you're like, Oh I should have changed. Then you start in the other language like, Oh I should have changed cause this, this fits a little bit better than that other way, but it's good to know the core pieces of it. And then those are really powerful features that come from F sharp and um, I think C sharp is getting more features, but it's cool to kind of talk about like why you really, really, really love it. Cause we all know that you love the F sharp so it's C sharp or get me fully back when they removed the semi-colon, you know, I proposed that and people literally laughed at me. Speaker 1: 48:36 Never. I'll never happen Frank. Never so well, you know, whenever I've sharp can, um, you know, make white space not important then what are the other baby you got to have one or the other. I know if you can make file file ordering not matter, then yeah, that would be nice. Technically they fix that. But yeah. What AV that, that that's, that's for the bar talk at the end. That is, and that's where it comes from. Yeah. Huh. Well, Frank, I know you got to go. Thank you so much for literally giving basically your presentation to everyone here. You just got a free presentation. People, you should probably just buy Frank munch coffees and PayPal him a bunch of money. So, uh, anyway, yeah, Frank, go enjoy the conference. Go present speaker dinner tonight. I'm looking forward to getting to see a bunch of F sharp nerds that I haven't seen in a long time. Speaker 1: 49:31 It's gonna be fun. Very cool. Anything else from you before you go? Uh, I think that I concluded that a lot of this relies on code. So I'll try to put this up on a get hub or I just, there's something that we can link into too. So if you actually want to see the details of what I was saying during all of this, hopefully it'll be there for you. Yeah, very good. We have of course, specify that at the end of the podcast. So now you have to re listen to the podcast. Wow. Looking at that link, if it's there, it may not be there. So spoiler alert, it's a mystery. I go James, Frank, Frank. Oh, get out of here. That's going to wrap it up for this week's podcast. You can do all the things, follow us everywhere on the Twitters, but that's going to be yet. So until next time there's been merged conflicts. I'm James Bond, Speaker 3: 50:16 the Magnum, and I'm Frank cruiser. Thanks for listening.