3 ms·

Heh, that's really interesting! Do you have a link to your work? > Personally, I don't find Option types in C# all that compelling because the pattern matchin

by louthy 12y ago

Heh, that's really interesting! Do you have a link to your work? > Personally, I don't find Option types in C# all that compelling because the pattern matching mechanism doesn't compel you to handle all cases like F#. In my library you are compelled. You must provide both a Some and None handler, even on the fluent variant. That was one aspect I absolutely wanted to nail after doing a reasonable amount of F# work recently. The only exception to that is you can ignore the Some branch, and just handle failure. The Some branch then just uses an identity function behind the scenes. So you're still compelled to deal with the failure case, which is where I feel most of the C# null carnage comes from.

steego 12y ago
> Heh, that's really interesting! Do you have a link to your work? I do and I don't. I actually wrote a lot of these things in VB.NET 4-5 years ago and I've recently returned to the .NET world, so I'm in the process of converting it to C#. There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.), and there's a ton I'm going to let die out. :) Here's a work-in-progress: https://github.com/steego/Steego.NET https://github.com/steego/Steego.NET
- louthy 12y ago
  > There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.), ahem https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad ;-) > Here's a work-in-progress: Cool, I'll take a look.
  - steego 12y ago
    > ahem https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad ;-) Very nice! You may save me a bunch of work yet. We should get some of your stuff into NuGet packages so you can spread the love. I saw on Twitter that Miguel de Icaza approves of your library. :) BTW, I just pushed up my little Tree library to my repo. Feel free to incorporate and change it however if you like it. https://github.com/steego/Steego.NET/tree/master/Steego.Trees https://github.com/steego/Steego.NET/tree/master/Steego.Tree...
    - louthy 12y ago
      > I saw on Twitter that Miguel de Icaza approves of your library. :) That's awesome! Thanks for sharing. I wouldn't even know how to get something onto NuGet. I guess my weekend project might have to become a bit more serious ;) Time to do some research. EDIT: research done... https://www.nuget.org/packages/LanguageExt/0.0.1-beta https://www.nuget.org/packages/LanguageExt/0.0.1-beta
Too 12y ago
It's a good idea but i think in reality people will be lazy, not know what to do, and just throw their own NullPointerException inside the None-handler. And then we are full circle back on square one. It's like checked exceptions in java. Sounds good on paper but in practice this happens: You are in the middle of just bursting out code to quickly get a response from a local rest api and you hit compile to suddenly get a whole list of "NetworkException/JsonParseException/WhateverBloatException not handled". At the moment you couldn't care less and just convert everything into a RuntimeException and tada! you don't have checked exceptions anymore. I think it might also cause unnecessary bloat when mixing code that uses the Option type and not, I've seen it happen with code contracts, either everything or nothing must be annotated. Once you start mixing you will have to add assertions before or after every call to the unannotated library.

by louthy 12y ago

steego 12y ago

> Heh, that's really interesting! Do you have a link to your work? I do and I don't. I actually wrote a lot of these things in VB.NET 4-5 years ago and I've recently returned to the .NET world, so I'm in the process of converting it to C#. There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.), and there's a ton I'm going to let die out. :) Here's a work-in-progress: https://github.com/steego/Steego.NET https://github.com/steego/Steego.NET

louthy 12y ago
> There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.), ahem https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad ;-) > Here's a work-in-progress: Cool, I'll take a look.
- steego 12y ago
  > ahem https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad ;-) Very nice! You may save me a bunch of work yet. We should get some of your stuff into NuGet packages so you can spread the love. I saw on Twitter that Miguel de Icaza approves of your library. :) BTW, I just pushed up my little Tree library to my repo. Feel free to incorporate and change it however if you like it. https://github.com/steego/Steego.NET/tree/master/Steego.Trees https://github.com/steego/Steego.NET/tree/master/Steego.Tree...
  - louthy 12y ago
    > I saw on Twitter that Miguel de Icaza approves of your library. :) That's awesome! Thanks for sharing. I wouldn't even know how to get something onto NuGet. I guess my weekend project might have to become a bit more serious ;) Time to do some research. EDIT: research done... https://www.nuget.org/packages/LanguageExt/0.0.1-beta https://www.nuget.org/packages/LanguageExt/0.0.1-beta

Too 12y ago

It's a good idea but i think in reality people will be lazy, not know what to do, and just throw their own NullPointerException inside the None-handler. And then we are full circle back on square one. It's like checked exceptions in java. Sounds good on paper but in practice this happens: You are in the middle of just bursting out code to quickly get a response from a local rest api and you hit compile to suddenly get a whole list of "NetworkException/JsonParseException/WhateverBloatException not handled". At the moment you couldn't care less and just convert everything into a RuntimeException and tada! you don't have checked exceptions anymore. I think it might also cause unnecessary bloat when mixing code that uses the Option type and not, I've seen it happen with code contracts, either everything or nothing must be annotated. Once you start mixing you will have to add assertions before or after every call to the unannotated library.