Re: F# fsharp

On May 29, 2010, at 12:20 PM, Brandon Van Every wrote:

> On Sat, May 29, 2010 at 10:36 AM, Douglas Cox <[email protected]> wrote:
>> Brandon,
>> 
>> For example, what were you looking for in an interpreter?
> 
> Scalability with respect to compilation.  If I write some code and run
> it through an interpreter, and it turns out to be slow enough that I
> notice a problem, then as a first pass optimization, I'd like to
> change it into compiled code.  I suppose this can be accomplished
> easily enough with F#, C# + Mono, or Lua .NET.  I don't know if the
> performance gains are sufficient for Lua .NET, I haven't looked that
> up.  The scalability is not easy to accomplish when using an
> interpreted language and native C++.  One has to do a lot of work
> converting between languages.  This may not be as much of a problem
> with respect to Squirrel; I know that it interfaces to C++ better than
> Lua, but I don't know about translating to C++.

Most of the various "interpreted" languages in .Net/CLR-land operate by compiling code to CIL on the fly, rather than actually *interpreting it* directly.  To the best of my knowledge, this includes F#.

Your "first pass optimization" is therefore happening automatically, 100% of the time.


> Maturity of support.  F# ships with an interpreter out of the box in
> VS10, although I would expect the usual "first MS product" pitfalls.
> IronPython does not have that same level of support, that's why it's
> not included in VS10.  I don't really know about Lua .NET.  Squirrel
> is a new kid on the block with a small support team.

When you speak of "maturity of support", do you mean:
1) How well integrated it is with the VS toolchain.
2) How mature the language/runtime itself is.
3) How effective/available commercial technical support is.


> Ease of interop at the language boundary.  If you're using only 1
> language, there's a lot less to worry about, crossing from compiled to
> interpreted code.

The DLR was specifically intended to address that and make it feasible for languages to be constructed that integrate seamlessly via the CLR.  It may be the case that .Net Framework 4.0 is required to fully realize this (via its support for dynamic dispatch) but at best I'd say that this is only a transient differentiator for F#.


> Speed of builds.  Editing code on the fly and not having to wait for a
> build is a boost to developer productivity.  In native C++
> development, changing header files definitely triggers recompliation,
> sometimes tons of recompilation.  Changing a single source file may or
> may not be noticeable.  Link times can definitely be noticeable,
> depending on how the app is structured.

The CLR is at a bit of a disadvantage here versus, say, the JVM, where individual classes can be recompiled without necessarily having to recompile anything more than that (well, barring dependent classes of course) -- interpretation on the CLR basically involves constructing an "assembly" (DLL) on the fly, in-memory.  An interesting question here is what the scoping of that assembly is and what the behavior is wrt reloading of code.  If, for example, all interpreted code must be part of the same assembly to ensure classes are visible to one another, then you could still wind up with considerable overhead when reloading your interpreted code after a change.


> 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.


> 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).


> For bonus points, I'll say that I'd like to dump C++ for good.  As the
> years go on, my objection to garbage collection gets less and less.  I
> first learned C++ 17 years ago.  That's a long time, and it shows in

A good GC is a godsend.  I remember profiling a Java 1.4 based server app some years ago and discovering that it was creating and discarding some 300,000 transient objects per second -- and that this was a negligible consumer of time.  That was at least 4 years ago, on fairly low-grade server hardware (certainly below what I imagine is a 'typical' gaming desktop these days).  My experience with Microsoft's .Net runtime is similarly positive.

My experience with the Mono implementation of the CLR has been considerably less impressive, and their efforts to get "sgen-gc" implemented imply that they don't quite have the resources they need for it.  Last I saw in the commit notes, for example, the mark/sweep collector had been disabled due to bugginess while they work out the remainder of the generational implementation.  That more or less eliminates the potential benefits of the generational model and is thus a rather considerable setback.


> Unfortunately, um, in the meantime Java and C# are pretty dumbed down
> languages.  I've never been interested, and they've never become
> interesting.  Partly because I just don't care about the web, or about
> mobile devices.  The former, because of my 3D ASM biases, has always
> been too slow.  The latter, have screens that are too tiny.  They're
> both an opportunity to do all the games that have been done to death
> forever.

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.


> commercially viable functional programming language.  F# potentially
> has dollar signs written on it, whereas previously everything was just
> R&D academic stuff, with a few narrow exceptions in some corners of
> the computer industry.  It's much easier to justify a learning curve
> now, and I'd rather put it into new stuff (FP) than old stuff (C++).

That's a bit of a myopic view.  Ruby has gained significant traction in the web world -- hardly "R&D academic stuff".  Scala and Clojure also seem to be making inroads.  While F# may be the first viable 'functional' language for the *game industry*, that is a very different thing.

-JF

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