101–110 of 130 posts
Earlier quoted context omitted.
C# 8.0 will have a switch expression: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... .
As C# gradually becomes F#, I have to wonder, why not just use F#?
[1] https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
Earlier quoted context omitted.
Thank you for these links. I will look at them! But I am wondering qualitatively, along the lines of whb07’s sibling answer: is the experience good? Is it as good as on Visual Studio?
VS Code doesn't work for the older .NET Framework stuff (pre .NET Core). As for doing .NET Core stuff, it depends a lot on your setup of both Code & Visual Studio. Code has some nice features that you would need extensions or an upper tier VS version to get. Code can be faster at times as well. At the end of the day it is a different experience with a few pros & a few cons. It will greatly depend on the way you progr…
This is not true for F#.
I used to be a big Haskell programmer. While I still love the language, I've really come around to the idea that strictly evaluated functional languages like F# or OCaml are the best for programming in. You get the nice functional features but don't have the straightjacket of laziness forcing you into certain design decisions. It's really nice sometimes to be able to mix in impure, side effectful code without having…
Hopefully we will see this one day: https://github.com/fsharp/fslang-suggestions/issues/243
Earlier quoted context omitted.
The first stepping stone the front-end folks take into server side programming. :D
What would you choose instead if you needed to write a simple web server?
If I'm making a simple API, I've already moved into territory where I'd prefer to use C# or something like that. The ecosystem is better and you can write it to avoid runtime gotchas.
Big languages/stacks can still write tiny programs.
Earlier quoted context omitted.
I use F# daily, and to get around this limitation I use hacky custom code generation an F# script (fsx) to generated specific types. Additionally, on cases where you’re not specifying the data of the type itself, you can use static type constraints on members. This doesn’t give you a default implementation like Haskell but you can always provide one as a function. Btw the monadic threading is still very useful, espec…
Oh, for sure I still love monads. I miss Haskell's do syntax in every other language. I think it's a great design pattern that starts popping up constantly once you know where to look. My objection is being forced to use monads due to the language's lazy by default semantics. You get this problem with haskell where the IO monad eventually just pollutes a huge chunk of your code because you can't safely sequence side…
http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...
Years ago I was working a miserable job writing boilerplate template code where I had to sub in variables based on certain conditions, it was using a very bland language to look up data from our database and format the output. I wasn't allowed to download any software onto my work computer despite having a technical background. So what I did instead to make my life easier was write F# to create a kind of DSL and crea…
Earlier quoted context omitted.
EF isn't really needed with Dapper and the available SQL type providers. Even still it's totally naturally to have a C# project holding the base EF stuff which you reference from your F# projects
Try to use that argument to sell F# to the large majority of .NET shops.
It's a pity the tooling is comparatively immature, with F# (or at least that was my experience last time I tried to develop with it). I think Rider is getting there, though. To go into more detail, the initial implementation in Rider was limited to not much more than syntax highlighting. Inspections were fairly limited, ASP.NET MVC integration was not as featureful. On the C# side, it's much more developed and refine…
Earlier quoted context omitted.
There's no compiler warning for incomplete matches, and without discriminated unions it's pretty verbose to write pattern-match friendly types C# has support for most F# features, they're just often awkward to use
You can get a pretty reasonable facsimile using some libraries I made: Discriminated unions: https://github.com/mcintyre321/OneOf and One line value objects: https://github.com/mcintyre321/ValueOf
Earlier quoted context omitted.
Try to use that argument to sell F# to the large majority of .NET shops.
The vast majority of .Net shops would run shrieking when faced with F# code. I still run into people regularly that shun the var keyword for type inference in C# because they think it is actually the evil old VB6 Variant type.