It's strange how appealing F# becomes once you realize you have the full power of the Visual Studio debugger and the .NET libraries. To someone who has mostly worked with Haskell (w.r.t. functional languages), that sounds great. Good debugging is absolutely essential - though with strongly typed functional languages, it's not often that necessary. But it's nice.
Then again, it's a very liberal language, if the end of the spectrum is Haskell. It allows side effects and mutable variables. While very convenient, nothing forces you to use these though. There are immutable data structures for everything. But it seems there are all the functional tools you'd want.
It's not Haskell, it's not pure and beautiful like it, but you still have computational expressions, which allow you to implement monads; metaprogramming, operator overloading, units of measure, and active patterns.
My only gripe is that the compiler doesn't translate functions that can return null to return an option value (i.e. Maybes), and null values in general! Would make interfacing the .NET library much cleaner. Right now I have to do something silly like this:
let notNull a = if a <> null then Some a else None
So I have to pipe every function call that may return null to this function when I'm in the Maybe monad, which is frankly a bit bothersome.
Still. Even being able to use the Maybe monad when working with .NET is really cool.
I'm not sure I understand what you mean. `=` is only assignment in C (or Java, or C#, or most any language I know of). `==` is comparison, being a different operator, one wouldn't say `=` is "overloaded".
Two different operations, two different operators. Yes, C famously makes it easy to miss the extra `=` in if expressions, but that's C specifically, and it's not the fault of the operator, that's actually the fault of automatic conversions from int to bool. Static languages designed after I was born usually require boolean expressions in their `if` statements explicitly.
But `+` and `+.` are the same operation. Or are you saying that adding integers and adding reals are not the same operation, and thus warrant separate operators?
I've begun to like having '+' and '+.' operators in OCaml. Not that I'm never tripped up, I often am, but I can never hide implicit conversions.
Another thing to consider is how you would implement having '+' for both integers and floats. In a language like C, '+' is designed for its numerical types, but what if you want to use it for big ints? Or for vectors? In a language like C++ you can overload operators, in Haskell or Rust operators are part of a typeclass or trait respectively; you need to add extra features to the language and the code generated by '+' is no longer a simple iadd or dadd instruction.
OCaml's choice may not be the best one or the most popular one, but I think it works fine.
Perhaps you know this, but just for the sake of precision and avoidance of doubt: Haskell numerical operations don't actually do any sort of conversion.
If I recall correctly I think at some point Ocaml required a paid developer licence to be obtained from Inria. Has this changed or am I just misinformed?
Not that I'm aware of. AFAIK anyone can submit a patch to OCaml without any hurdles. There is a Consortium that companies can join and they benefit from a different licence. That might be what you're thinking of.
The F# language has been open source for 4 years and MS has accepted pull requests to the compiler, core library, and tools for over 6 months (100+ PRs going into F# v4.0). Now with Microsoft fully committed to open source and cross-OS development with .NET Core, this is a very good time for hackers interested in meta-programming to get in on the ground floor of F#, the only functional language fully supported by .NET.
This article is a complete guide to hacking on the F# core, in this case an end to end example of extending the core library, including setting up standard unit tests. And mentions looking to F# Language Design User Voice, http://fslang.uservoice.com/ as the source for extension inspiration. One thing mentioned in the article, that F# will "likely" move from codeplex to Github, should read that the MS team is committed to fully migrate to Github, they are just busy right now with v4.0 of the language.
I'm still hesitating between learning Common Lisp or F# for my next web service project. I work with C# in my day job, so F# seems like a no brainer, but I'd like to get away from the CLR and there isn't much out there on getting F# running with vnext on linux (digital ocean).
Any opinions?
As for the posted link, quite interesting, a similar one for C# would be cool.
You should ask on the fsharp-opensource[1] mailing list; a large portion (maybe even a majority) of the posters on there are using Mac/Linux/BSD for their F# development/deployment.
Yeah I wouldn't spend time on F# on non-Windows until the community builds up more. So you probably want to try either OCaml or, if you're up for a bigger challenge, Haskell.
How are the Mac and Linux Mono versions? Are they production ready? It's not really about the "bigger challenge", but being able to ship code that solves real problems for clients.
This is actually my impression, that Mono isn't at the same level of performance than the windows counter-part. I guess we can expect with .Net Core to see improvements. But will the Mono runtime ever be as good as the CLR ? The CLR isn't open sourced. The whole open-sourcing happening in the .Net world is quite interesting, but It is also confusing the hell out of me.
Then again, it's a very liberal language, if the end of the spectrum is Haskell. It allows side effects and mutable variables. While very convenient, nothing forces you to use these though. There are immutable data structures for everything. But it seems there are all the functional tools you'd want.
It's not Haskell, it's not pure and beautiful like it, but you still have computational expressions, which allow you to implement monads; metaprogramming, operator overloading, units of measure, and active patterns.
My only gripe is that the compiler doesn't translate functions that can return null to return an option value (i.e. Maybes), and null values in general! Would make interfacing the .NET library much cleaner. Right now I have to do something silly like this:
So I have to pipe every function call that may return null to this function when I'm in the Maybe monad, which is frankly a bit bothersome.Still. Even being able to use the Maybe monad when working with .NET is really cool.