91–100 of 203 posts
I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…
Good post. I really hoped for some f# code after listing all those scenarios where c# fails. Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all. I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if pe…
I'll tell you my experience. I never liked the arguments about reduced bugs or concise code. As a programmer the reason I would use F# (or OCaml, or Haskell, or Elm, or PureScript) is because it increases by day-to-day well-being. I'm happier writing Typed FP because the system is very concrete in my head as I work with it. In a dynamic language, there is always a nagging uncertainty about the system - if you're usin…
Is it possible to seamlessly integrate a user managment system in f# into existing c# code? I guess, it's not that simple.
It also reminds me of an experience I had in a former job with C++. There was a very, very experienced senior who wrote a very clever library which allowed us to add varous metadata to domain objects in a a compile-time checked, type-safe and very performant way. When the guy left, everything went downhill and the code from then on was regarded as mysterious black box noone dared to touch.
Somehow I am reminded if this when I read about 'magic' solutions in FP. Is it possible to reach a state with FP where seeing through it all gets too troublesome?
Earlier quoted context omitted.
I'm interested to know why you describe EF as a monstrosity? Genuine interest, I just started using EF for the first time a few weeks ago for a work project so I've only scratched the surface but it didn't seem terrible, although I did find that only being able to update all tables after a change to the database as opposed to a single table to be a bit of a limitation.
If you use code first it's very easy to get in a corrupted state where it doesn't know how to update the database. Otherwise it speeds up the basic tasks then it gets in your way to write more sophisticated queries. I found that a good solution is to write a generic sql serialiser that does all the basic operations (insert, update, select, delete, read one or multiple from readers) and do the rest by hand. It avoids…
I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site http://fsharpforfunandprofit.com
I'm definitely an F# evangelist at work, but we are not a .NET shop. But I was would say that the introduction of ML features in other languages, (Swift, Rust) are good for F# evangelism, because it makes these concepts more familiar. I think the focus should be on moving F# away from .NET because F# itself, it is much more accessible that its cousins OCaml and Haskell. And if Microsoft won't give proper support, the community should move to other platforms. Some discussions are already happening here https://github.com/fsharp/fssf-ask-the-board/issues/4
There is no "one best language" or even "one best programming style". Functional has worked for some people to address the problems they have, but not everyone has those problems.
For example: I once worked on a video switcher for TV stations. You have maybe 100 video sources, maybe 80 video destinations, and you can connect any to any. You also have about six different sources of commands to make connections. For responsiveness, each source has its own thread. So the nature of the problem is one giant shared mutable state. The functional people come along, and they say "shared mutable state is evil; don't do that". Yeah, well, that's actually not bad advice, but it doesn't help me at all with this situation, since I can't avoid it here.
There are other places where FP isn't the answer: Situations where you care about memory layout (high performance computing or just memory constrained), where one of the main concerns is sequencing (some industrial control operations, maybe robotics), where predictable timing is important (real time systems), maybe others.
Use the right tool for the job. FP is not the right tool for every job. Nothing is. The problem with evangelism is when it says "this is the One Right Way", instead of the humbler assertion "in some situations, this can help you with some of the problems that are slowing you down".
Don't get me wrong. FP has a good story. (Even if you don't use FP, learn its deepest lesson: Control your state space or die.) But FP is not always the answer. Evangelists might get further if they recognized that.
I usually don't try to sell F# as compared to C# as noted in many other responses here. Since most of my friends work in other languages I usually just use python as my reference. #ME: "Hey that stuff at pycon was pretty cool, huh?" #FRIEND: "Yeah it's interesting the directions they're going with the language." #ME: "Yeah the optional types could help clean up big code bases, and open up the door for quickcheck-like…
I mention it just because I've had almost a carbon-copy of that conversation but I showed them Julia and now that person actually is writing Julia for their startup. That person is doing technical chemical engineering stuff, so the fit is a bit more pronounced, but I think it's a neat language aside from that. Parametric types and multiple dispatch and lisp-macros, oh boy!
Earlier quoted context omitted.
I will just make one criticism ... it is sadly somewhat awkward to install F# even on windows and they do need a good ide if you go to the F# .org site, installing F# without installing visual studio, is a 4 step process .. and when I tried it on windows 7 it just didnt work for me i eventually gave up and install visual studio on linux, thing seems better, but .. still missing a solid ide
The first class IDE for F# is VS Code + Ionide. The language service backend for F# is also very well supported for emacs.
I've experienced sort of a diagonal problem to this. F# is way too entwined with .NET to be immediately useful to programmers familiar with Ocaml or Scala or Haskell, etc. Some of the basic List. , Array. stuff is simple enough, but then you start talking about interfaces and classes and members and all this stuff that doesn't really translate from C#->sanity very well. I know people love it, but I've long considered…
'There is no merit in your skin color or your genitals.' can't disagree with that.
Plus, if you're situated in a historical process (like we all are) then arbitrary things become important. Accidental weaknesses such as being perched on the CLR and tethered to the hopes, dreams and capabilities of common-garden C# enterprise developers invert strangely into advantages - in the case of F#, it makes for a very friendly, welcoming ecosystem.
First let me address those who are asking for Type Classes and Dependent Types. These would make the compiler too slow. The F# compiler works in the 100s of ms and the 100s of MBs ram. Where Scala is in the 1000s of seconds and the GBs of ram. People will give up on code completion if it takes more than 500ms and they generally don't like waiting longer than 200ms. Separately Martin Odersky (the creator of Scala) laments that the more advanced language features attracted the wrong type of people to the language and flooded the internet with overly academic tutorials.
I put a lot of the blame for the lack of F# adoption on Microsoft. Part of this is to do with the Dev Div vs Windows war that almost deprecated the whole .Net ecosystem. If Windows 8 wasn't such a disaster it's likely .Net would have been deprecated and would never had been open sourced. (at least something good came from Windows 8). Part of this war also ended with a lot of the best .Net people leaving to go to Facebook. This brain drain has really hurt Microsoft and I doubt they'll ever recover. Most of the old hands that know better are aging out and the new people at Microsoft don't know any better.
As for tooling, Microsoft has done and continues to do a bad job with F# tooling. There is is a not invented here culture at Microsoft Redmond which includes being hostile to Microsoft Research. Visual Studio is a bucket of bandaids and it takes an army of people just to keep it going. F# is given a low priority. It's worse with the latest release because they've gone overboard with compiler features with the Rosario release and have made it dog slow and painful to use. I hope they can fix it with updates but who knows. You can still get older versions. It's very possible to build a really good IDE around the F# compiler but unfortunately Microsoft refuses to do so. Thankfully, it looks like there are some good alternatives becoming available.
In comparing Scala and F# adoption, Scala has Hadoop/Spark which is a killer product that can earn a consultant a lot of money. The fact that C# is a better language that Java means there are more Java refugees going to Scala than there are C# refugees going to F#.
Thankfully Don Syme has made F# completely open source. Now with .Net being open source we no longer have to worry about Microsoft shooting itself in the foot again.
I make my money writing a product written in F# and can attest that F# is one of my big competitive advantages. I highly recommend it.
Earlier quoted context omitted.
This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.
Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…