I definitely agree. Trying to jump into F# without any knowledge of .NET just requires so much mind-juggling. As a beginner, so much of the difficulty and frustration comes from the fact that you are missing so much foundation knowledge that you don't know what to ask or look for, and may not even recognize the answer. Interop won't look or behave or be optimized how you expect and will just wreak havoc with your attempts to build a mental model of what you're learning because of the strange inconsistency.
Sometimes the answer is just so obvious to people who have that foundation knowledge that no one else has bothered to ask on reddit/stackoverflow and you are googling into the wind. Sometimes the only thing you can find is several years old and giving advice that's no longer correct. I'm not sure which is worse.
I had the same trouble trying to build a learning project in Clojure. I remember when starting, I had only used pip and apt-get (and not knowing them well), I didn't even recognize Leiningen as a package manager. It worked so differently from what I thought I needed (and billed itself as a "project automation and configuration tool") that I didn't even recognize it was the solution to my problem.
It's just so easy to take for granted how many things are obvious to us that make solving problems in our comfort zone easy for us and paralyzing for another person, and I think this bias finds its way into the documentation and mindset of entire communities. This makes it harder and harder for something to be approachable if you don't fit in that same box. I'd love to love F#, (I read F# for fun and profit and worked through the F# Koans, but haven't made anything), but I'm not sure if I'll ever get over the hump unless I find myself working somewhere that's already using it. My feelings on Python are somewhere between ambivalent and bitter by now, but the work gets done, I know what to expect, and I never feel lost.
What would really help me, I think:
- More "idiomatic" wrapper libraries around .NET libraries, even if they're slower or have less features/customization.
- Pure F# libraries of typical utilities or ports of popular libraries in other languages, even if they are slower or have less features/customization.
- Content about F# project management from the perspective of someone who uses Python. This is how you do it in Python, this is how you do it in F#, this is why, these are the pros, these are the cons, these are just different because that's the way it is.
I can't upvote your comment enough. Learning F# w/o .NET and Clojure without JVM knowledge is next to impossible. There is no good doc despite what people say (and I own several books in this space). Scott W's F# articles are great for foundational FP, but neither that, any of the F# books, or any of the online tutorials show me how to do even simple things like iterate through a file. I'd love to see "Basic Office Programming in F#".
For what it is worth, the Microsoft docs are getting easier to navigate. https://docs.microsoft.com/en-us/ They are currently putting a lot of effort into docs. It's got to be hard to learn .NET from zero. Try figuring out which namespaces are the most common and start browsing the docs.
I really disagree with Microsoft's approach of homogenizing their products, and this is a perfect example.
- There's never a need for "Microsoft" documentation -- you'll have a question with a specific product or service. They really should be distinctive visually.
- This is on the microsoft domain and top left click goes to microsoft.com, but you can't get back here from microsoft.com
- By the time I click through to something (for example, .NET->F#->Get Started), I have not one but two major navbars and footer featuring prominent links and menus completely orthogonal to what I'm viewing. There is nearly zero typographical variation among the content I've expressed interest in (F#), and tons of variation for this separate content. This is distracting.
I've never had that problem with AWS and their docs are EXTENSIVE and homogeneous.
Honestly, I've always found the .NET(C#) docs pretty good even going into naming conventions and design patterns. However I'm open to improvement as they were looking a bit dated and I often had trouble ending up in docs for older versions of software/OS's.
What problems did you run into with Clojure? I haven't missed JVM/Java experience. The Clojure standard library provides nearly everything and third party Clojure libraries wrap Java libs. Off the top of my head, the only Java thing normal code sometimes references is numerics, so you might glimpse Long/MAX_VALUE or Math/sqrt.
A lot of things require you to specify the Java namespace like the "swing" demo. Iterating through a folder was similar. There are several Clojure books explaining FP concepts, but not much in the realm of here is how you do basic task "x". This isn't perfect in any language, but I've never had trouble with Perl, Python, C#, Java, Fortran...etc.
Sometimes the answer is just so obvious to people who have that foundation knowledge that no one else has bothered to ask on reddit/stackoverflow and you are googling into the wind. Sometimes the only thing you can find is several years old and giving advice that's no longer correct. I'm not sure which is worse.
I had the same trouble trying to build a learning project in Clojure. I remember when starting, I had only used pip and apt-get (and not knowing them well), I didn't even recognize Leiningen as a package manager. It worked so differently from what I thought I needed (and billed itself as a "project automation and configuration tool") that I didn't even recognize it was the solution to my problem.
It's just so easy to take for granted how many things are obvious to us that make solving problems in our comfort zone easy for us and paralyzing for another person, and I think this bias finds its way into the documentation and mindset of entire communities. This makes it harder and harder for something to be approachable if you don't fit in that same box. I'd love to love F#, (I read F# for fun and profit and worked through the F# Koans, but haven't made anything), but I'm not sure if I'll ever get over the hump unless I find myself working somewhere that's already using it. My feelings on Python are somewhere between ambivalent and bitter by now, but the work gets done, I know what to expect, and I never feel lost.
What would really help me, I think:
- More "idiomatic" wrapper libraries around .NET libraries, even if they're slower or have less features/customization.
- Pure F# libraries of typical utilities or ports of popular libraries in other languages, even if they are slower or have less features/customization.
- Content about F# project management from the perspective of someone who uses Python. This is how you do it in Python, this is how you do it in F#, this is why, these are the pros, these are the cons, these are just different because that's the way it is.