3 ms·

Thanks, but I still can't see it from where I am. The problem isn't that I can't see the use of (to take your example) sum types. I've coded around C#'s lack

Thanks, but I still can't see it from where I am. The problem isn't that I can't see the use of (to take your example) sum types. I've coded around C#'s lack of them before, and sure, it was clunky and painful. But I've needed them like < 1% of the time. If I had them as a first-class language feature, would I use them more? What for?

dvdkon 6y ago
I think you would. It's hard to see from the perspective of using another language, because you don't think of the code you write as emulating sum types. For example, in my biggest F# project I parse a local standard for public transport timetables. In that format a trip can either drive through a stop, drive around it or stop there at a particular time. With a sum type, I can represent all three of these cases without worrying about a value of that type having both "driving through" and a time set. When you've got a language that effortlessly allows something like this, you'll find uses for these paradigms.
- mtVessel 6y ago
  Okay, that makes sense. I appreciate the concrete example.
phillipcarter 6y ago
You would absolutely use them more, provided that the mechanism for working with them (pattern matching) is also in place. In F# coding you not only model your domain with sum types, but you operate on instances of them with pattern matching that gives you completeness checking. This does two things: 1. Allows you to make failure scenarios intrinsic to your domain, and the compiler then is a tool for domain correctness. 2. It provides a beautiful symmetry between how you define your domain and how you operate on it. The syntax is even almost identical. The features "fit" incredibly well because of that. Beyond that, with optionals and results defined as sum types you find that any time you're in a "It may explicitly give me nothing" or "It may explicitly give me an error" scenario these types are the first your reach for in your toolbag. Sum types don't completely obviate classes, but they are a better tool than classes for several scenarios.

dvdkon 6y ago

I think you would. It's hard to see from the perspective of using another language, because you don't think of the code you write as emulating sum types. For example, in my biggest F# project I parse a local standard for public transport timetables. In that format a trip can either drive through a stop, drive around it or stop there at a particular time. With a sum type, I can represent all three of these cases without worrying about a value of that type having both "driving through" and a time set. When you've got a language that effortlessly allows something like this, you'll find uses for these paradigms.

mtVessel 6y ago
Okay, that makes sense. I appreciate the concrete example.

phillipcarter 6y ago

You would absolutely use them more, provided that the mechanism for working with them (pattern matching) is also in place. In F# coding you not only model your domain with sum types, but you operate on instances of them with pattern matching that gives you completeness checking. This does two things: 1. Allows you to make failure scenarios intrinsic to your domain, and the compiler then is a tool for domain correctness. 2. It provides a beautiful symmetry between how you define your domain and how you operate on it. The syntax is even almost identical. The features "fit" incredibly well because of that. Beyond that, with optionals and results defined as sum types you find that any time you're in a "It may explicitly give me nothing" or "It may explicitly give me an error" scenario these types are the first your reach for in your toolbag. Sum types don't completely obviate classes, but they are a better tool than classes for several scenarios.