Wondering about F#

[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