An important question when choosing a scripting language is “who is going to write the scripts?”.

If the scripting language is used mainly by the development team then something like ML is just fine... like any other language. It doesn't even need to be a real scripting language: The game may use libtcc or even shellexecute a compiler at runtime to compiler some shared libraries.

But if the scripting capacities are thought to be used by some hobby programmers who would like to write same small mods and have fun then I think a well known language like python is the right choice.
A game like WoW may motivate people to learn lua, c++ or even a language just used by Blizzard but the popularity of WoW isn't because of the scripting capacities, on the other hand indie developers may hope their game to become more popular because of some nice mods. I think in the latter case the language preferred by those hobbyist should be used.

I'm not sure functional programming is going to become mainstream soon either. Maybe though; C# is getting more functional programming support and F# is becoming an official Visual Studio language.

Quote:Original post by ToohrVyk
This is the classic Turing tarpit argument. Yes, since OCaml and PHP are both turing-complete, you can trivially write in both languages a virtual machine for a simple type-less language. The real question is whether this fits within the language's design and typical usage patterns.

The argument doesn't have much to do with turing-equivalence. I'm not talking about writing an interpreter or virtual machine for an untyped language in a typed language. I'm talking about the relative expressive power of languages in the vein of On the Expressive Power of Programming Languages. You said "sure, the absence of types means your language is more expressive than about every single other language except Java and C#", presumably because Java and C# have an Object type. I'm just saying that holds for ML too, you just have to write the Object type that is the type of all untyped values first. It's the typed language therefore, that is more expressive because it can do everything the untyped language can and more.

Quote:In practice, nobody writes OCaml type-less code by hand

I've written code like that before. All you need to make it practical is syntactic sugar for creating values of type Uni, so you can say something like '1' and get the value representing the number 1 of type Uni, and something like 'true' to get the value representing the boolean true of type Uni. This would be easy to add using Camlp4.

Quote:In fact, some type-less idioms are so powerful that the OCaml developers made heavy efforts to incorporate them into the type system (for instance, format strings for use by the Printf module)—I could write a printf-like function in PHP with ease (although it involved defining my own format specifiers) yet could not do the same in a type-safe manner in OCaml.

Well you're comparing two different functions, an untyped printf and a typed printf. Untyped printf (or of type Uni) should be just as easy to write in OCaml as in PHP (well, if OCaml had variable arguments). Typed printf like the one in the Printf module that does static checking of its arguments takes much more effort, but it's not writable at all in PHP!

All I know is this ... ever since using functions like iter and fold in SML (or `each', `map', or `inject' in Ruby), I have thought that for looping around arrays is soooooooo 1998...

But honestly, for most of us, programmer cycles > computer cycles most of the time. Only in extremely time-critical applications does computer cycles become more important, in which case you are probably writing very specific and specialized code, which makes this whole conversation moot...

Quote:Original post by ToohrVyk

Quote:Original post by Oluseyi
Given that a functional language requires that expressions have no side effects, functional programs, then, are more amenable to parallelization and will factor heavily in future high-performance programming.

I seriously doubt it. The functional approach does indeed allow easy parallelization, but it has the severe downside of being unusable by the vast majority of programmers. People tend to prefer parallelization solutions on top of existing imperative languages (such as C + MPI) instead of moving to functional-based programming.

Unless some iconic coder writes the next killer app in some functional language showing tremendous speed up due to inherent parallelization and Haskell becomes the new C.

On a more serious note, I think that the future lies in allowing the programmer to express where the parallel portions of a program are, letting the system sort out how to actually parallelize them on the hardware. Pure functional elements can be quite useful here if the programmer has control over it. E.g. types of expressions could be tagged as pure if they may contain no side-effects, then the compiler would enforce that all subexpressions must also be pure. Another good way to parallelize programs is through light-weight processes like in Erlang. I hope to see both of these approaches gain traction.

Quote:Original post by Rebooted
The argument doesn't have much to do with turing-equivalence. I'm not talking about writing an interpreter or virtual machine for an untyped language in a typed language. I'm talking about the relative expressive power of languages in the vein of On the Expressive Power of Programming Languages. You said "sure, the absence of types means your language is more expressive than about every single other language except Java and C#", presumably because Java and C# have an Object type. I'm just saying that holds for ML too, you just have to write the Object type that is the type of all untyped values first. It's the typed language therefore, that is more expressive because it can do everything the untyped language can and more.

Then you misunderstand equivalence as it means equal if it can do more then it isn't equivalent. You are going to have to explain what you mean by expressive if you are going to claim that typed languages are more expressive than typeless, I am pretty sure in a typeless language can write a sort that will work for anything where as in a typed language I would have to write one for each data type I wanted to sort or rely on some template to write the code for me. Which makes the typeless version much more expressive by my measure of the word expressive. aka how many lines of code written to express an idea.

Quote:Original post by stonemetal
Then you misunderstand equivalence as it means equal if it can do more then it isn't equivalent. You are going to have to explain what you mean by expressive if you are going to claim that typed languages are more expressive than typeless, I am pretty sure in a typeless language can write a sort that will work for anything where as in a typed language I would have to write one for each data type I wanted to sort or rely on some template to write the code for me. Which makes the typeless version much more expressive by my measure of the word expressive. aka how many lines of code written to express an idea.

The purpose of types is to capture something of the semantics of the program. You can't express that at all in a typeless language and even dynamically typed languages must defer type checking to run time.

Also your example is rubbish. In a close approximation of a typeless language, namely C, you'd sort an array with quicksort passing it the array to be sorted and a comparison function. In O'Caml, you'd do exactly the same, with the only exception that the compiler will check that the comparison function is correctly typed with respect to the type of the array. No more, no less code. Polymorphic functions in O'Caml aren't even instantiated like C++ templates.

Quote:Original post by ToohrVyk
How do you call this "not writing an interpreter or virtual machine" ?

I don't understand.. No interpreter or virtual machine is written. There is just a direct mapping of untyped programs from language A as fully equivalent typed programs of language B. If you mean the syntactic sugar, then I don't see how a fully syntactic mapping purely for convenience counts as a virtual machine.

It's not like it's hard to program without special syntactic sugar for the type anyway, we do it in ML for most types we define:

import Prelude hiding (($), True, False, not)data Uni = True | False | I Int | Fun (Uni -> Uni)(Fun f) $ x = f xnot :: Uninot = Fun (\b -> case b of  True  -> False  False -> True)  inc :: Uniinc = Fun (\(I i) -> I (i + 1))plus :: Uniplus = Fun (\(I x) -> Fun (\(I y) -> I (x + y)))

*Main> not $ TrueFalse*Main> inc $ I 3I 4*Main> plus $ I 12 $ I 7I 19*Main> plus $ I 12 $ True*** Exception

[Edited by - Rebooted on June 5, 2008 12:30:14 PM]