←back to thread

Why F#?

(batsov.com)
438 points bozhidar | 1 comments | 01 Apr 25 12:34 UTC | HN request time: 0.199s | source
Show context
nickpeterson ◴[01 Apr 25 12:42 UTC] No.43546092[source]▶
Because it’s great, and people that think otherwise are dead to me.
replies(3): >>43546162 #>>43546305 #>>43548281 #
MrMcCall ◴[01 Apr 25 12:48 UTC] No.43546162[source]▶
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.

replies(2): >>43546316 #>>43550647 #
munchler ◴[01 Apr 25 13:03 UTC] No.43546316[source]▶
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.
replies(3): >>43546741 #>>43546839 #>>43548606 #
speed_spread ◴[01 Apr 25 13:56 UTC] No.43546839[source]▶
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?)
replies(4): >>43547007 #>>43547567 #>>43548456 #>>43550319 #
1. MrMcCall ◴[01 Apr 25 16:08 UTC] No.43548456[source]▶
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.