Why F#?

Curried functions combined with that magnificent pipe operator, overlaid on the .NET runtime. Don Syme et al knocked it out of the park.

It's the one programming language that changed how I think about programming.

I'm only talking about the version before type providers. Then it got messy.

Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.

F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.

I tried F# when it was first released and was not a fan, but it sounds like that impression is a little outdated. C# has come so far in that time it’s almost a new language. I’ll have to take another look.

Why would type providers be avoided? It seemed to me like a nice metaprogramming feature, akin to what Zig does with comptime types (except runtime?)

Type providers can be extremely brittle IME. Altough, I guess if it is referring to version controlled example data that probably works better than referring to a DB or something like that directly that the dev has to provide.

Type providers are very powerful but involve running arbitrary external software at compile-time (e.g. a SQL Server or Postgres database). This can be difficult to set up and configure reliably in a multi-person project.

For me, I already had all the featues I needed.

Plus, I'm not going to be downloading, configuring, or running any separate code at runtime. The project is the project, it's going to process some files, communicate with some services, and communicate with the UI, if any.

If I need to consume a service, it should be defined such that I manifest the interface module (perhaps via WCF) and then connect to it progressively from stub to ever greater functionality in test to final implementation. Trying to write a program to do all that at runtime is not sensible, IMO.

Metaprogramming via reflection, however, was useful for exploring the vast .NET framework, and I used those to great effect, especially in exploring .NET's various UI frameworks (WinForms and Silverlight), but never to create code at runtime via the emit functionality. No, that's my job: to emit code that is tested and works and is comprehensible.

I don't doubt it, but I don't run Microsoft software any more. I've seen enough embrace, extend, and extinguish in my lifetime to not depend on them for my code's execution environment.

My current work needs nothing the .NET environment provides that I can't use python's standard libraries to get done, or bash and C if I need to.

But I'm lucky to no longer be in a corporate environment, so I don't need to consume commercial services, which was much easier using WCF within .NET. Back in my previous life, constructing n-tiered services on top of SqlServer using WCF was slick, indeed.

To any who are interested in how to construct such n-tiered applications simply but securely and precisely, I highly suggest Juval Lowy's IDesign system. He had three specific videos that I watched three or four times each until I understood his distillation of his vast expertise. Of course, Mr. Lowy is one of the co-designers of WCF, which was an excellent bit of tech.

I don't know what C# has for an interactive prompt nowadays, but F#'s commandline environment, via its fsi.exe, was a revelation back then. It prevented having to have entire solutions to contain test projects to explore different areas of the vast .NET framework, especially when just learning how to use specific methods or objects.

FWIW, F# is an open source project controlled by the F# Software Foundation, the .NET Foundation, and Microsoft.

> controlled by the F# Software Foundation, the .NET Foundation, and Microsoft.

It is controlled by Microsoft. It's not going on my Linux or BSD boxes.

I know how they work, and I want nothing to do with them.

Yeah, they're terrifying. It's often not that hard to generate the code (e.g. https://github.com/Smaug123/WoofWare.Myriad/ is where I pump out these things) for a bunch of what you would want to do with a type provider, and that's much less existentially terrifying if it's possible.

It has great ideas but because of all these conveniences it is very bad for performance based programming making it slower than C#. I like the ideas in Roc language to make functional programming as fast as imperative by controlling allocations in things like closures

Do you make sure to run a linux kernel with all the MS stuff patched out also?

No, but if it came in the standard install there's nothing I can do about it save spending hours and hours auditing my install. I don't do that kind of thing nowadays.

Separately installed software? Not a bit of it.

That's interesting. Thanks for the heads-up.

For C# you can use LINQpad, a .NET scratchpad. You can even mix and match F# in it.

You're not entirely wrong, but when it comes to SQL, the trade-offs are unavoidable. You either embrace a conventional, not-SQL approach with all its limitations, or you treat the database as the single source of truth (SSoT). Both have downsides, but configuring a designated local or shared database for this purpose is no less reliable than conventional approaches.

As for type providers in general, I don't think databases are the best example of their typical use case. Most type providers don’t interact with external systems; they usually parse schemas, configuration files, or other structured data to generate strongly typed representations. The database-backed approach is just one variant, not the norm.