Functional languages in gamedev

David Lindström · 2011-12-21T00:02:45

Does anyone here use (or know of someone using) a functional langauge in gamedev? Any game that there's a remote chance I may have heard of? A friend and I was having this discussion about languages when he mentioned Scheme. He posted some examples of scenarios where scheme was much simpler/cleaner [than <insert_imperative_language_of_choice>] and so on, in particular an algorithm to generate primes. While I may or may not agree, he can be right for arguments sake at least. My response was "the question is how nice and clean you can do something more practial.." to which he said that Lisp was invented for AI, so it should at least be able to handle that, and probably also physics.. I then asked him if he could name an example, which he couldn't. I'm guessing that's because there are none, (feel free to prove me wrong) but why is that? Education among developers (or lack thereof)? Lack of performant implementations? No significant advantage? Solution looking for a problem?

Telastyn

3,778

December 20, 2011 02:29 PM

What does C# miss that F# has, in today's .NET 4 world?

F# has units of measure, some syntactic sugar for type fiddling, type providers (which are cool for programming language theorists, but I haven't seen them do much in practice yet). But mostly F#'s fancy pattern matching capabilities.

Personally I don't think that those are anywhere near enough, given C#'s advantages with tooling and more natural integration with existing .NET code.

Well, referential transparency and deep immutability are quite generally useful tools in my opinion that deserve to be used a lot more. Tools, that is, that I would wish to be able to opt into whenever I want, instead of getting them shoved down my throat, after which I have to take a doctorate in CS to relearn how to print to the command line using monad-magic.
[/quote]

Indeed. And that's what we're seeing. Scala and C# pulling in the good stuff of functional programming to use where applicable.

On an unrelated note, I heartily despise the terseness of most functional languages.
[/quote]

I very much agree, though among programming language theorists it's not even discussed. Take a look through LtU sometime and see how much of the site is dedicated to programmer usability. But then again, I tend to be on the far end of the spectrum in wanting/making verbose programming languages.

-- Tangent Developer Journal - Delegates - Part 2

Alpha_ProgDes

6,963

December 20, 2011 03:18 PM

I think the rub, for me anyway, is that these 5th-gen PLs are becoming more and more functional. It's almost like, us as programmers, are in some weird denial process. We use imperative languages that are becoming more and more functional. But at the same time we say, "OMG, it's functional! The syntax. My eyes, my eyes!" (ok, there's some exaggeration there) We should just brace F#/OCaml/Lisp and be done with it.

(end rant)

Beginner in Game Development? Read here. And read here.

Eelco

301

December 20, 2011 04:04 PM

[quote name='ranakor' timestamp='1324378739' post='4895664']
What does C# miss that F# has, in today's .NET 4 world?

F# has units of measure, some syntactic sugar for type fiddling, type providers (which are cool for programming language theorists, but I haven't seen them do much in practice yet). But mostly F#'s fancy pattern matching capabilities.

Personally I don't think that those are anywhere near enough, given C#'s advantages with tooling and more natural integration with existing .NET code.
[/quote]
Dunno, considering how painless it is to add an F# project to your C# solution and just call its functions, id say the barrier to entry is very low. I dont see F# replacing C# anytime soon, but its certainly a nice option.

Dont forget the type polymorphism.

Well, referential transparency and deep immutability are quite generally useful tools in my opinion that deserve to be used a lot more. Tools, that is, that I would wish to be able to opt into whenever I want, instead of getting them shoved down my throat, after which I have to take a doctorate in CS to relearn how to print to the command line using monad-magic.
[/quote]

Indeed. And that's what we're seeing. Scala and C# pulling in the good stuff of functional programming to use where applicable.
[/quote]
C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

On an unrelated note, I heartily despise the terseness of most functional languages.
[/quote]

I very much agree, though among programming language theorists it's not even discussed. Take a look through LtU sometime and see how much of the site is dedicated to programmer usability. But then again, I tend to be on the far end of the spectrum in wanting/making verbose programming languages.
[/quote]

Interesting post. Cant find a link to more info about the language though.

Telastyn

3,778

December 20, 2011 04:33 PM

Trying not to get too off track...

C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

I don't see deep-immutability as being a language feature (unless I misunderstand you). If you want an immutable object, make one; declare it sealed.
Likewise with pure functions. If you want a pure function, write one.

The optimizer loses some opportunities, but the core concurrency benefits will exist regardless.

Interesting post. Cant find a link to more info about the language though.
[/quote]

Clicking the blog title brings you to the landing page. Most info is there, otherwise a PM might yield better answers to questions.

-- Tangent Developer Journal - Delegates - Part 2

Eelco

301

December 20, 2011 05:04 PM

Trying not to get too off track...

[quote name='Eelco' timestamp='1324397057' post='4895744']
C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

I don't see deep-immutability as being a language feature (unless I misunderstand you). If you want an immutable object, make one; declare it sealed.
Likewise with pure functions. If you want a pure function, write one.

The optimizer loses some opportunities, but the core concurrency benefits will exist regardless.
[/quote]
Well, of course one can always program in an immutable style by convention, in any language. But aside from compiler optimizations, its also a matter of coding efficiency. If I use a library function marked as 'pure', I know what im getting into. If I pass into a function an object declared as immutable, I know its going to be the same before and after the call. Without having to dig into the function and check for myself if the person making that function stuck to the convention.

Sealed only applies to declarations, not to instances of the class, or am i missing something?

RivieraKid

706

December 20, 2011 05:53 PM

I use F# in the financial sector.

good because

Pattern matching and discriminate unions,
Currying,
cleaner syntax, especially when nesting functions in functions and using tuples,
evaluated if statements,

bad because

must explicit cast from int to double, wtf?
must cast 'this' to interface type to use interface functions
no auto property (until F# 3.0)
currying can be really ugly

i prefer F# over C#, you make less mistakes and its easier to change your code because its so breif. Dont really need resharper, in C# resharper is a must

Telastyn

3,778

December 20, 2011 06:22 PM

Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.

-- Tangent Developer Journal - Delegates - Part 2

Eelco

301

December 20, 2011 06:41 PM

[quote name='Eelco' timestamp='1324400665' post='4895779']
Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.
[/quote]

Yes, but only if you instantiate that subclass. The issue im concerned with is that an object gotten from a readonly property need itself not be immutable. Even though the object pointed to might not change, the content of the object very well might. Thats a rather useless form of immutability, for the purposes of functional programming.

Eelco

301

December 20, 2011 06:44 PM

must explicit cast from int to double, wtf?

I minor point id say, but one that makes sense. The integers are not a subset of the doubles, so it is by no means a lossless conversion. Personally I prefer to only have true upcasts be implicit.

Telastyn

3,778

December 20, 2011 06:51 PM

[quote name='Telastyn' timestamp='1324405345' post='4895801']
[quote name='Eelco' timestamp='1324400665' post='4895779']
Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.
[/quote]

Yes, but only if you instantiate that subclass. The issue im concerned with is that an object gotten from a readonly property need itself not be immutable. Even though the object pointed to might not change, the content of the object very well might. Thats a rather useless form of immutability, for the purposes of functional programming.
[/quote]

I understand that, but if you write class A to be immutable, operations that work with A can make decisions based on that design. If some clever bastard comes along and makes B that subtypes A and isn't quite immutable, the function that works with A under the assumption of immutability will likely break. Hence the need to also make the type sealed in addition to effective immutability in order to maintain the implied contract with its consumers.

(and yes, having a compiler to verify such things would be nicer and easier)

-- Tangent Developer Journal - Delegates - Part 2

Functional languages in gamedev

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Functional languages in gamedev

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines