Re: F# fsharp

First, an introduction.  I am not in the game industry any more, nor have I
been for nearly a decade.  I have been following F# for several years,
however, and I read this list because game engineering was always cutting
edge and I believe it continues to be.  To see both come together was quite
intriguing.

In that light, I'd like to share some F# opinions that I believe are
relevant to the discussion.  First and foremost, I believe Microsoft's
motivation for pushing F# to market in the first place is the language's
strength in the imminent issue of multiprocessing,
See: http://www.gotw.ca/publications/concurrency-ddj.htm

I'll go into that a bit more below because Jon provides brilliant motivation
for it.

To lead off, here's a recent interview with the inventor of F# lots of talk
about parallelism, among other things (he does a much better job than I ever
could):

http://www.infoq.com/interviews/don-syme-fsharp-2_0

It is of note that Microsoft is standing behind Mono support for F#:  Even
though F# 2.0 came out in April 2010, F# 2.0 for Mono is already available
here (not aware of the exact release date):

http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/release.aspx

On Sat, May 29, 2010 at 8:38 PM, Jon Frisby <[email protected]> wrote:
> > support for higher level constructs such as lists and pattern
> > matching.  C# does not.  C# looks like Java.
>
> See: Linq.  No inbuilt regex syntax that I'm aware of, but a fairly novel
approach to list manipulation.  Novel in the sense of
> eschewing the more typical functional paradigm in favor of something
SQL-inspired -- I haven't yet used it enough to decide if it's a
> good or bad idea, but it's certainly a far cry from Java wrt handling of
lists.

I've used Linq on a daily basis for a couple of years, mostly from C#.  (Of
course: C# and F# are trivially inter-operable)  Linq is very, very handy
and I would have loved it in my C++ days.  However, from F#, I haven't used
or missed Linq much for numeric manipulation because F# has
list/array/sequence comprehensions.

>From this article:
http://www.anexperimentinscotch.com/2008/07/list-comprehensions-in-f/

You have this example in C#/Linq (edited for brevity):
   var squares1 = Enumerable.Range(1, 10).Select(x => x * x);

And this in F#:
   let num = [for x in 1..10 -> x * x]

Note that array comprehensions look nearly identical, but are much faster
for some things.  Sequence comprehensions also exist to express infinite
sequences, which are useful in more situations than some initially identify.

Linq still offers many advantages in data manipulation (contrasted to
numeric manipulation) as exemplified in projects like LinqToNHibernate or
LinqToTwitter, but the comprehensions go very, very far and remain quite
terse and readable for raw numeric manipulation.

> > Metaprogramming.  This is a core strength of functional programming
> > languages; really, what does C# have to say here?  Lua probably does
> > an ok job of this in its own way, but if I wanted to implement general
> > purpose DSLs, code translators, or dynamically generated code, F# is
> > the more powerful toolbox.  I will be using these capabilities for
> > procedural / dynamic content generation.
>
> And this would be where F# interests me, particularly with regard to
metasyntactic constructs (I.E. hygienic macros or anything
> remotely analogous, if it has such a thing -- haven't looked at it enough
to suss that out yet, but I'm hopeful), or functional
> constructs (although being a Mono users, the implications of the latter
wrt memory allocation make me nervous).

This is a key strength of F#.  Most importantly, there are monads which are
not exactly about metaprogramming but accomplish many of the same goals more
safely.  More immediately relevant to the comments here, though, is the
construct built into the language called quotations.  Quotations allow you
to compile your F# program into a data structure that you can in turn
manipulate in a strongly-typed manner to do things like transform your
program into GPU instructions (indirectly in this case, but I've seen it
done directly by Chance Coble).

See: http://tomasp.net/articles/accelerator-quotations.aspx

Much of the ground is already broken, though translating some of the more
sophisticated language constructs directly into shader language is far from
a trivial task.

However (though I haven't seen anyone do this), translating from IL to
shader language using F#'s exceptional pattern matching features might be
less burdensome.  You cannot use quotations for that, but you may not need
them... enter: pattern matching.

(* From wikipedia, example of pattern matching in F# that prints a list of
numbers *)

let rec printList lst =
   match lst with
   | [] -> ()
   | h :: t ->
       printf "%d\n" h
       printList t

This is a very, very trivial example of F#'s pattern matching.  For the real
power of pattern matching, though, note that you can extend what is on the
left hand side of "->":
http://blogs.msdn.com/b/chrsmith/archive/2008/02/21/introduction-to-f_2300_-active-patterns.aspx

F# offers many novel solutions to previously non-trivial problems.  And I
have yet to talk about parallelism.

> Calling them "dumbed down" is a misnomer.  They attempt to automate away
tasks that programmers overall have consistently
> demonstrated difficulty in properly managing -- such as memory management.
 While some programmers can more or less handle
> it, every programmer makes mistakes in this area when they have to handle
it themselves.  Double-free bugs, use of uninitialized
> pointers / memory clobbering -- these are very real issues in C++ code and
devoting the resources to ensuring your code does not
> contain such mistakes is just not a good use of resources.

This is a gorgeous paragraph and the one that justifies F# in the two large
fonts of errors and resource wastes: multi-threading and optimization.

First, let's lead with an article with code samples, timings and
measurements.
http://www.infoq.com/articles/pickering-fsharp-async

Then, a surprising result, F# beating unmanaged C++ raytracer for raw speed.
http://fsharpnews.blogspot.com/2010/03/f-vs-unmanaged-c-for-parallel-numerics.html

Note that I'm dubious of these results and maintain that post-optimization
on most modern hardware, C++ would likely win over F# in the end.  However
the raw speed and readability that the F# solution offered gave me pause.
 The majority of a program is not its render loop and to see any interpreted
language approach C++ is significant in my opinion.

More significant is to see any parallel program be written in nearly the
same clean and readable manner as a serial program, and without the
[explicit] use of mutexes anywhere.  This, I would have said, was impossible
before I saw monads, which is how F# is doing its parallelism.  There are
plenty of mutexes et al being used in the implementation of the F# language,
but they unnecessary when writing many F# programs.  Microsoft has
painstakingly augmented its IO libraries to be compatible with this manner
of parallelism to ensure that remains true, and that support will only
increase over time.

This is why F# is such a strong parallel language: Not having to worry about
protecting your memory allows you to better use your resources, to
paraphrase Jon above.

There are other major points in F#'s favor, but I believe I've covered
enough with introductions F#'s comprehensions, pattern matching, parallelism
and even some allusions to monads in one email.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com