6 ms·

The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries -

The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries - these .NET libraries are not nice functional libraries and don't encourage you to think functionally. Eventually I felt like everything I wrote was wrong and I just gave up on it.

vosper 10y ago
I had the same feeling with Clojure. I'm not sure it's due to not having a strong functional background; I think it might be the reality of interop between very different languages.
- orderlyoctopus 10y ago
  Definitely. Understanding Clojure/Java interop to consume a library requires that you understand both Clojure and Java far more than you would need to if you were to consume a library native to whatever you were using.
  - vosper 10y ago
    That's one of the reasons I gave up on Clojure, though I think it could be a good option if you're coming from the Java world.
jackmott 10y ago
F# can be a nice language even if you don't care for the functional paradigm. Discriminated Unions and pattern mactching still come in handy, the syntax is still less verbose, there is less biolerplate/ceremony than in C# where everything has to be in a class. it is easier to pass a function to a function than in C# inlining functions is easier the type inference can be useful in various ways. if/then/else statements being expressions is extremely nice. I tend to code in a mostly imperative style, even in F#. I understand it better, it usually performs better.
smoothdeveloper 10y ago
Thing is that putting together short helpers for the "nasty" bits often revolve around 1 line helpers. You can do so along the way without focusing so much on doing idiomatic FP and achieve both pragmatic and palatable results. Designing solutions with the type system enabled by F# and it's ability to interop with whole .NET ecosystem is really a powerful combination.
- orderlyoctopus 10y ago
  It's very hard to do it along the way if you aren't familiar with C# either. Now you're struggling to get your head around both paradigms as well as however the thing you're trying to do works. I doubt I would have ever stuck with Clojure longer than a day, for example, if it wasn't for this library. It's not very long and all the functions are very short, but it meant that everything I needed from the file system was a 30s peek at the documentation and exactly what I expected rather than ~30+ minutes futzing with Java and forgetting what I was doing in the process https://github.com/Raynes/fs https://github.com/Raynes/fs
  - smoothdeveloper 10y ago
    > It's very hard to do it along the way if you aren't familiar with C# either. Which I keep overlooking with so many years of C#, I'm so sorry about that :( That being said, looking at the .NET framework documentation and hanging out on fsharp.org's slack might be a good way to make up for what you are missing to get started.
    - orderlyoctopus 10y ago
      If I ever get up the nerve to give it a real try, I will certainly test the slack's patience for stupid questions :) The .NET reference is useful if you are reading through code and maybe to modify it slightly, but I find it (and class hierarchy style docs in general) to be close to useless if you are writing new code and new to the library. Using a new library in Python (especially one that's heavily object oriented), I often find it easier to learn from tests instead of the docs. Reference docs are often inaccurate or too verbose or show no sense of importance or are just poorly written. Tests are straight to the point, include examples, and tend to focus on the most important parts of the library. The MSDN docs have quite a bit of "How do I..." content, but unfortunately F# is seemingly always blank as an example. Combine this with a huge proportion of commonly used third party libraries being .NET rather than F# libraries, and so much of the .NET infrastructure you need to use being C# focused, and as a newcomer you are paralyzed. If F# is serious about building a community of more than just C# converts, they need to recognize that the convenience of .NET for people who already know it carries a commensurate tax for everyone who doesn't. It's harder for me to learn .NET as an F# user than a C# user. It's harder for me to learn to use NuGet as an F# user than a C# user. It's harder for me to learn to use Visual Studio as an IDE with F# than C#. In everyone of these scenarios, you're running up hill because examples and documentation and interfaces are all for the majority, which you won't be.
pmarreck 10y ago
Sounds like the same issue I had with Clojure and Scala. As soon as you touch anything Java or mutable, it's like WTF? Come to the Elixir/Erlang camp; our functional turtles go all the way down! The only jarring thing is having to write to a mutable database. They even borrowed the |> operator! And it has great pattern matching of course.
- davidgl 10y ago
  Or use both: https://www.youtube.com/embed/HLs6WgAmX64 https://www.youtube.com/embed/HLs6WgAmX64
  - pmarreck 10y ago
    Holy crap. Interesting!
- problems 10y ago
  Yeah, Elixir or Haskell is probably the way I'll wind up going if I want to pursue functional programming again. I can do the basics enough to handle LINQ well and stuff, so I'm getting away without a strong knowledge for now. One of the biggest disappointments in software development to me though is that practically all of the cool libraries these days are hitting the javascript ecosystem rather than those of all the interesting languages. So if you want to interact with these great libraries, you have to tolerate a pretty shitty language with annoying tooling at best. So when I want to do something practical, I wind up going that way disappointingly often.
orderlyoctopus 10y ago
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.
- throwaway7645 10y ago
  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#".
brianberns 10y ago
Can you give an example? I think F# has nice functional replacements for most of the nasty (mutable) bits of the .NET Framework, such as List, Set, Dictionary, etc. Most of the other areas of .NET work just fine with F# in my experience.

vosper 10y ago

I had the same feeling with Clojure. I'm not sure it's due to not having a strong functional background; I think it might be the reality of interop between very different languages.

orderlyoctopus 10y ago
Definitely. Understanding Clojure/Java interop to consume a library requires that you understand both Clojure and Java far more than you would need to if you were to consume a library native to whatever you were using.
- vosper 10y ago
  That's one of the reasons I gave up on Clojure, though I think it could be a good option if you're coming from the Java world.

jackmott 10y ago

F# can be a nice language even if you don't care for the functional paradigm. Discriminated Unions and pattern mactching still come in handy, the syntax is still less verbose, there is less biolerplate/ceremony than in C# where everything has to be in a class. it is easier to pass a function to a function than in C# inlining functions is easier the type inference can be useful in various ways. if/then/else statements being expressions is extremely nice. I tend to code in a mostly imperative style, even in F#. I understand it better, it usually performs better.

smoothdeveloper 10y ago

Thing is that putting together short helpers for the "nasty" bits often revolve around 1 line helpers. You can do so along the way without focusing so much on doing idiomatic FP and achieve both pragmatic and palatable results. Designing solutions with the type system enabled by F# and it's ability to interop with whole .NET ecosystem is really a powerful combination.

orderlyoctopus 10y ago
It's very hard to do it along the way if you aren't familiar with C# either. Now you're struggling to get your head around both paradigms as well as however the thing you're trying to do works. I doubt I would have ever stuck with Clojure longer than a day, for example, if it wasn't for this library. It's not very long and all the functions are very short, but it meant that everything I needed from the file system was a 30s peek at the documentation and exactly what I expected rather than ~30+ minutes futzing with Java and forgetting what I was doing in the process https://github.com/Raynes/fs https://github.com/Raynes/fs
- smoothdeveloper 10y ago
  > It's very hard to do it along the way if you aren't familiar with C# either. Which I keep overlooking with so many years of C#, I'm so sorry about that :( That being said, looking at the .NET framework documentation and hanging out on fsharp.org's slack might be a good way to make up for what you are missing to get started.
  - orderlyoctopus 10y ago
    If I ever get up the nerve to give it a real try, I will certainly test the slack's patience for stupid questions :) The .NET reference is useful if you are reading through code and maybe to modify it slightly, but I find it (and class hierarchy style docs in general) to be close to useless if you are writing new code and new to the library. Using a new library in Python (especially one that's heavily object oriented), I often find it easier to learn from tests instead of the docs. Reference docs are often inaccurate or too verbose or show no sense of importance or are just poorly written. Tests are straight to the point, include examples, and tend to focus on the most important parts of the library. The MSDN docs have quite a bit of "How do I..." content, but unfortunately F# is seemingly always blank as an example. Combine this with a huge proportion of commonly used third party libraries being .NET rather than F# libraries, and so much of the .NET infrastructure you need to use being C# focused, and as a newcomer you are paralyzed. If F# is serious about building a community of more than just C# converts, they need to recognize that the convenience of .NET for people who already know it carries a commensurate tax for everyone who doesn't. It's harder for me to learn .NET as an F# user than a C# user. It's harder for me to learn to use NuGet as an F# user than a C# user. It's harder for me to learn to use Visual Studio as an IDE with F# than C#. In everyone of these scenarios, you're running up hill because examples and documentation and interfaces are all for the majority, which you won't be.

pmarreck 10y ago

Sounds like the same issue I had with Clojure and Scala. As soon as you touch anything Java or mutable, it's like WTF? Come to the Elixir/Erlang camp; our functional turtles go all the way down! The only jarring thing is having to write to a mutable database. They even borrowed the |> operator! And it has great pattern matching of course.

davidgl 10y ago
Or use both: https://www.youtube.com/embed/HLs6WgAmX64 https://www.youtube.com/embed/HLs6WgAmX64
- pmarreck 10y ago
  Holy crap. Interesting!
problems 10y ago
Yeah, Elixir or Haskell is probably the way I'll wind up going if I want to pursue functional programming again. I can do the basics enough to handle LINQ well and stuff, so I'm getting away without a strong knowledge for now. One of the biggest disappointments in software development to me though is that practically all of the cool libraries these days are hitting the javascript ecosystem rather than those of all the interesting languages. So if you want to interact with these great libraries, you have to tolerate a pretty shitty language with annoying tooling at best. So when I want to do something practical, I wind up going that way disappointingly often.

orderlyoctopus 10y ago

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.

throwaway7645 10y ago
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#".

brianberns 10y ago

Can you give an example? I think F# has nice functional replacements for most of the nasty (mutable) bits of the .NET Framework, such as List, Set, Dictionary, etc. Most of the other areas of .NET work just fine with F# in my experience.