Wondering about F#

[Super Lloyd]

I have this feeling: data data data!...

My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!

[parths]

Have you tried TryFSharp[^]? They have a learning section (needs Silverlight) which takes you through most of the features of F# and a few example domain uses. I think it'd help if you're acquainted with functional programming but it's not necessary.

"It was when I found out I could make mistakes that I knew I was on to something." -Ornette Coleman "Philosophy is a study that lets us be unhappy more intelligently." -Anon.

[Super Lloyd]

Thanks, I discovered the link (it's in the MSDN documentation! :)) I was planing to try it on this weekend / tonight!! ^^

My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!

[Sander Rossel]

I was about to post that, then read your post :thumbsup: And actually I should be giving that thumbsup to Marc :laugh:

It's an OO world.

public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}

[Mark_Wallace]

Trumped by B#[^]

I wanna be a eunuchs developer! Pass me a bread knife!

[Bob Calco]

F# is an amazing language. It's "impure" in that it is neither Smalltalk ("pure OO") nor Haskell ("pure Functional") but its creators have struck an excellent balance between these two paradigms using OCaml as a basis -- but not the specification -- for the language. There are features in F# that OCaml developers wish they had! When you finally wrap your head around pattern matching, active patterns, quotations and computation expressions, you will not be able to look at mere mortal languages like C# and VB.NET with the same enthusiasm. The F# compiler is one of the smartest in existence and its type inference, tail-call optimization and code generation capabilities are second to none on any platform. F# and Scala are doing the same thing on their respective platforms -- bringing the worlds of OO and functional programming into practical symbiosis. F# kicks Scala's butt really only because the CLR kicks the JVM's butt in two specific areas: The ability to support tail-call optimization (which is critical to making functional programming's reliance on recursion efficient) and the fact the CLR did not have to resort to "type erasure" to support generics ... so, you don't lose any reflective capability over types at all with its seemingly loosey-goosey type syntax. For myself I use F# for nearly all business logic and in the MVVM paradigm for the VM part, almost exclusively. Manipulating collections is a delight in F# and VM is about binding data and actions to the UI. This is a non-visual exercise and F# really makes it nice. Using it for GUI programming is an exercise in self abuse because the tooling support just isn't there, but that's OK, what it does do is so outrageously cool and useful in real programming that it doesn't need to do everything. F# justifies the CLR's support for multiple languages in ways C#, VB.NET and other semantically similar languages cannot.

[Thornik]

F# is a hype. "Fire and motion" if you read enough Spolsky. For a normal human with normal brains F# means nothing - we DON'T think in "functional style".

[Super Lloyd]

you kind of confirm (very nicely) my growing (yet uninformed) bias, that F# is good at manipulating data... Will start to look at it this weekend! ^^

My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!

[Reese Currie]

Gave this a 5--great answer, Bob. I like how you fit F# into your process. I've tried and liked F#, but working more with the JVM and very rarely with .NET, I do more Scala. (.NET folks are welcome to send flowers of sympathy.) Scala is a lot nicer to work with than Java. I wanted to note there's a way to "simulate" tail recursion in Scala using "@tailrec" but simulation's not exactly the same thing; @tailrec is a bit of compile-time smoke and mirrors. At least it means you can write tail recursive code without worrying about blowing your call stack, and the performance "isn't that bad" on things I've written that rely on tail recursion. I think F# long-term will be more successful because Microsoft is interested in people using it. Oracle doesn't really encourage you to give Scala a try, and most of the writing on Scala is so academic in nature it really takes endurance to wade through it all to the point of doing something practical with it.

[JRickey]

I downloaded and installed F# to VS2010, but have not started using it yet. I currently am taking Programming Languages through coursera.org and the first half focuses on SML, which like OCaml and F# derives from ML. As Argonia mentions, there is a lot of power in functional languages. One of our assignments was to write a function that takes a list of strings and returns a list with only those strings that begin with a capital. The answer is one line of code that combines three standard library functions. Functional programming also emphasizes minimizing/eliminating side effects. I recommend learning a functional language even if you do not expect to write code production code in it, as the concepts can carry over into other code.

[KP Lee]

Manfred R. Bihy wrote:

Tim Minchin - F#

I extracted the link from my quote of you, but the link was hilarious. From my very short reading of functional programming, it looks like it has encapsulated iterative processes so you continue to do iterative processing, but behind the scenes. Which concerns me about how efficient a generic process is.

[einy]

Have a look at Nemerle. Nemerle is what C# should have been!! You can combine C# and functional programming. You can use C# syntax. If you are tired of {}, Nemerle accept indent. There is a nice plugin for VS2010. I think I have read somewhere that JetBrains is going to use Nemerle. Python is also a nice language with OOP and functional. It is also crossplatform who I think will be at more value as time goes by. Python is also very good at prototyping.

[CKnig]

No the basic functional paradigm is easier to understand then imperative and mutable style - in US colleges FP is taught first (and I think it's a great idea) - have a look at (SICP[^] if you really want to understand what all the fuss is about. Surley: there are "ebony tower things" (lot's of Haskell magic comes to mind) but this is not the core of what makes FP. I would give it a chance and for an C#/.net guy there is no better place to start then F# - you can even use your *old* OOP/imperative style till you know better :D - and BTW: LINQ *IS* FP - don't tell me thet LINQ is only for humans with anormal brains and that you have difficulties to think in LINQ :D

[irneb]

The biggest gripe I have with F# is that there's not enough samples to show how to accomplish UI library interfaces. And none of the G-IDEs tie your forms to F# code. So your assumption about F# being good for data manipulation is "true" in a sense - DM doesn't require too much integration with GUI design-like libraries, and if you do need to integrate / use a lib to obtain your source data or a link to the result store - that's usually a case of having to program the using clauses and function calls manually nearly every time in nearly all languages. It's not like say Delphi where you can visually place a DataStore on a form, map it to a DB table and map a data-grid into that store without even looking at the code (only doing point-n-click/drag and modifying some properties). As for F# (and "new" functional / hybrid languages overall) I'm still not convinced, it's not as if it's something "new" or even "better". That is still the biggest reason I prefer Lisp: You got the best of both functional and imperative without tricky ways to implement each other in an extremely mature language (literally decades of testing, optimization, standardization, etc.). Scheme is decent (especially since it always has recursive tail-call optimization, no matter what Scheme implementation you use), though I have the same gripe with it: libs are less than stellar and hard to find. Common Lisp on the other hand has huge libs, including some very good links to wxWidgets to make your GUI programming a breeze (e.g. using wxGlade), but only a few of its implementations include tail call optimizations: so you tend to steer clear of recursive mostly. And no recursive and functional do not necessarily go hand-in-hand. The one may compliment the other in some instances - but performing a map on a list/array/string/etc. is still an iteration, not a recursion. Using Lisp 1.0 (i.e. the version used in the 1960's):

;; Having a function like
(defun square (x) (* x x)) ;#

Then the functional method
(mapcar 'square '(1 2 3)) ;(1 4 9)

;; Is the same as the imperative method
(setq result nil)
(foreach x '(1 2 3) (setq result (cons (square x) result))
(reverse result)

;; Only there's no intermediate "result" variable, nor an iterator "x", yet it's still iterating over the list by simply passing the list's items one at a time to the square function.

;; A similar recursive implementation of the built-in mapcar would be something like:
(defun mapcar-r (func source)
(if source