Rather than type what I wrote in a similar thread again, I'll just link to it here.
Summary: qsort [1..10000] is slow not so much because it isn't an in-place sort, but because naive quicksort on an already-sorted list is O(N^2) rather than O(NlogN). If you use an element from the middle of the list as the pivot instead of the first element, it performs much better.
As the other reply already stated, you can do in-place quicksort in Haskell by using the ST monad, if that's really what you want.
Quicksort with in place arrays is O(nlogn). Quicksort with lists is O(nlogn). The difference between the two is a constant factor. Not everyone cares enough about constant factor speed increases that they would abandon a programming language because of it, but some do which was the point I was trying to make.
Using lists just means that quicksort isn't any better than any of the other nlogn sorts, but it's still one of the easiest efficient sorting methods to explain. Mergesort is usually preferred in functional programming circles because it's about equally complicated but you don't have to worry about bad performance in the already-sorted case.
While a focus on games may help stir interest, it seems as though game development studios are as yet unimpressed by most game-related college courses. To those who have taken such courses or considered hiring those who have: what has your experience been?
It seems like that's not the point. The goal of having students write games isn't to turn them into game programmers, but to show them that programming can be fun, and then they can use their new skills to solve all sorts of problems.
purity, side-effects, and monads explained
on
Haskell 2010 Announced
·
· Score: 4, Interesting
Let's see if I can explain this simply.
The Haskell language, like any other language, needed constructs like "read" and "write", but to implement them as simple functions would have broken the underlying assumptions of purity and lazy evaluation.
Haskell happened to have monads. A monad is essentially a typeclass for containers, that allow you to do certain things to combine containers of the same type, without having to worry about what kind of container it is. Most (all?) of the containers in the standard library are instances of Monad.
The Haskell language designers came up with (or perhaps borrowed) an idea. They would create a new container type, called IO, and make it an instance of Monad. However, unlike other containers, it would not have any accessor functions. You can pass around an object around of type IO in pure code all you want, but you can't ever examine the contents of the IO container from within "pure" code. The only thing you can do with it is combine it with other IO objects. Combining two IO objects is equivalent to evaluating the file operation or what have you inside one IO object and passing it's result to and executing whatever is inside the second IO object. The actions within an IO object, however, are free to invoke pure code if they like.
Every haskell program has a main() function, which is an IO action. This allows you do do any necessary file IO your program needs to do, and it can also call out to pure functions. Pure function cannot invoke IO actions. Most Haskell programmers try to keep the IO actions as simple as possible and rely on pure code for the bulk of the program.
As a concrete example, I wrote a ray tracer, which parsed a text file and generated an image. As I was writing it, I got to the part where I needed to write the file parser. I thought "oh, no, this whole thing has to execute within the IO monad and it'll be a big mess". However, it was not so. After scratching my head a bit, I ended up writing a pure function that takes a simple text string and converts it to my internal representation of a scene, ready to be ray traced. Within main (within the IO monad), I would read the text file in with a lazy function "hGetContents", which returns a string which is the contents of the file. I would pass that string to the parser, and then trace a grid of rays (one per pixel) against the parsed scene. The list of pixels with their calculated color values was returned to the IO monad, where I used OpenGL to plot them to the screen.
The interesting bit about this is that hGetContents is lazy. In a strict (i.e. non-lazy) implementation, the whole string would be read at once. This is inefficient, and may cause problems for text files that won't fit in memory. Due to laziness, however, the string is passed into the parser without being fully evaluated. As the parser needs more data, the run-time system will cause hGetContents to read another block. So, here we have an example of a pure function that's indirectly triggering IO, and it's doing it all without violating the constraints of the type system.
I would consider Lua a functional language (and I think it's designers went out of their way to make it so), though it isn't exclusively functional; it is possible (and typical) to write imperative, stateful code in Lua as well. I haven't used it much, though, so it may be that there is some drawback to using a functional style that I haven't considered.
Then why aren't the FP shops kicking as and taking names?
There are several reasons. As abigor stated, functional programming is not well understood by the majority of programmers. If you suppose that there is one Haskell programmer for every 1000 Java programmers, then that one Haskell programmer has to be one thousand times more productive in order to get noticed by the larger programming community. (I don't know if the distribution is that skewed, but I think you get the idea.) There are small companies that have been very successful at using FP, but they're easy to miss if you don't look in the right places.
Another reason is that the fastest functional languages are still slower than C in general. I don't think the difference is as much as you say, Haskell and Ocaml both have very good code generators. Do check out the "programming language shootout" results. (Be sure to use -O2 with ghc, though, or you really will see a 10x difference.) However, there are many programmers for whom if you give them a choice between one language and another, they will always choose the faster language regardless of other considerations. A lot of supercomputing people still use Fortran, for example.
A third reason is that software firms are very risk averse. If you have a problem that you know a team of average Java, C++, or C# programmers can solve in N months, versus a smaller team of more expensive functional programmers who may or may not be able to solve the problem in much less time in an unknown language that no one else seems to be willing to bet the farm on, then a lot of firms will see FP as an unacceptable risk.
Fourth, consider the sales pitch for Haskell: "Hey, check out this cool new language! It's a bit slower than C, and you can't change the value of any of the variables. It was designed by committee. Half of the people who use it got their PhD by hacking a type system extension onto ghc." The primary benefits of Haskell are hard to describe to people who haven't used it, namely that programs tend to have fewer bugs (thanks to the strict type checker), and it often takes much less code to solve a given problem. The drawbacks, however, are rather obvious up-front: how many programmers do you know who would welcome the idea of "everything is const"? There aren't really any Haskell programs that you couldn't write in C, or Java, or C++, or C#, or Python or any of dozens of other languages. The difference is, how much code are you going to write, and how much work is it going to take to make the program reliable?
I agree it's not always the best example, but there are four reasons why "qsort [1..10000]" is slow, and you can address three of them without writing something that's "100 times less readable than C".
The first problem is that naive quicksort on an already-sorted list/array is O(N^2). The fix is to grab an element out of the middle and use that as your pivot. That alone will make qsort far faster. (I tried it.*) The resulting code is, of course, a bit messier.
Secondly, the qsort function has no type signature, so it will default to the most polymorphic implementation, which is something like qsort:: Num a -> [a] -> [a]. Typing "qsort [1..10000] probably (though I'm not sure, it's a ghci-specific thing) defaults to using Integer, which is less efficient than a machine Int. If you constrain the type signature the code will be faster.
Thirdly, you're using ghci. Code compiled with "ghc -O2" is far faster. (Be sure not forget that -O2, it make the code about 10x faster.)
The fourth reason is that C is doing in-place array swaps. (You can do the same thing in Haskell using the ST monad if you really want to. I don't think the result will be "100 times less readable", but it will be fairly ugly compared to the pure version. There are a couple such implementation here.) Whether doing quicksort with lists is good enough really depends on what you're doing.
* Quicksort modified with a swap, then mangled by slashdot:
module Qsort
where
qsort [] = []
qsort xs =
let n = length xs
in
if n > 100
then
let split = n `div` 2
(a,b) = splitAt split xs
in _qsort $ (xs!!split) : (a ++ (tail b))
else
_qsort xs
_qsort [] = []
_qsort (x:xs) =
qsort (filter (= x) xs)
I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ?;-))
Whether it works or not depends on what your task is and how you try to solve it. There are several ways to do concurrency in Haskell, and they're each appropriate in different instances. If you're just calling a lot of pure functions, then "par" and "seq" might be what you need. If you need shared, mutable state, then STM might be a good approach. If you want to do message passing or traditional locking, then using Chan and/or Mvar in the IO monad might be the right thing.
The announcement is perhaps a bit less interesting than the summary would have you believe... The most recent Haskell standard was Haskell 98, eleven years ago. A new committee was formed to bring the standard up to date with current implementations. Most of the changes listed have been in GHC and other implementations for some time now, and none of them appear to have anything to do with concurrency directly. (Which isn't to say that interesting stuff hasn't been happening in the Haskell world in that area, it just doesn't directly affect the core language.)
That's not true unless you are using a different definition of "functional" than I am. I can't comment on Scala since I haven't used it, but Erlang is indeed a functional language. It is not a _pure_ functional language, as Erlang does have some mechanisms for manipulating mutable, global state and message passing, but it's at least as functional as a lot of other language that are widely regarded as "functional programming languages" such as Lisp and ML.
I'm going to elaborate on the Maybe type idea because I think it is important. In Haskell, there's no distinction between a value and a pointer to a value, and these things can't be Null. In C, one often wants to represent, say, an optional value. A pointer can be used for this: it is either assigned a value, or it is NULL. In Haskell, we do the same thing with a Maybe type. Maybe is a container that can either have the value "Nothing", which means it's empty, or "Just a" where "a" is the value you stored.
The important thing about Maybe types is that they let you make a distinction between things that can be empty and things that can't. In C, any pointer can be NULL, so we can't tell from the type signature of a function if it's okay to pass in a NULL value or not. And indeed, a large proportion of all C runtime errors is the dreaded NULL pointer exception.
What I am suggesting, is that Go should have a notion of a pointer that can only point to a valid object, and a pointer that can be set to NULL. They type system should distinguish between these two cases, and the compiler should fail if the user tries to mix the two. NULLable pointers should only be used when absolutely necessary.
From what I've read so far, I have no idea if Go allows standard pointers to be NULL.
As a Haskell programmer myself, I see where you're coming from, but realistically there are a lot of C and C++ programmers who are never going to be able to accept the idea of "everything is const". There are also some problems for which Haskell would not be a good choice. (That category is much smaller than I initially thought, but there are still a few problems where the easiest way to get good performance is to just write it up in C.)
From the looks of it, the Go designers have at least borrowed some useful ideas from Erlang, and they have a primitive kind of type inference. Their "interface" mechanism also has a lot of similarity with Haskell's type classes.
The Go designers may not have borrowed as heavily as they might have from Haskell*, but at least the result is a lot closer to Haskell than C or C++.
* Things I hope the Go designers do borrow from Haskell: The "$" operator, Maybe types, parametric polymorphism. Things I hope the Haskell implementer borrow from Go: Erlang-style message passing, fast compilation.
They say that Go was designed to give them a better language for writing server code than the C++ they're using. I think it makes a lot of sense in that context. They don't need to use Go in every project to be a worthwhile effort.
We need as many new languages as it takes in order to get languages that actually work well for the jobs we need them to do. One of the reasons we have so many languages is that users are dissatisfied with current languages, so they roll their own. And it isn't just that the old languages were good at one thing, but bad at something else so we needed new tools to solve new problems. Many languages in common use aren't even very good at the things they're most commonly used for.
C basically works, but any moderately complicated C project inevitably turns into a huge project with many man years of effort to find all the bugs, most of which would never have gotten past a reasonably strict type checker. I'm pleased to see that C may get some serious competition from a language with modern features (like type inference and type safety) that may make it much easier to write high quality, fast, low-level code.
I do that. It's really not that big of a deal; sometimes I'm not even consciously aware that I've switched layouts. For awhile I had trouble with letters like "y" that you type with the same motion but the opposite hand.
I don't think you should dismiss the idea just because there are a few use cases where universal binaries wouldn't work. I've installed Linux on WRT54Gs before and am aware of their limitations, but I also can see how it might be convenient sometimes to distribute universal binaries (i.e. for desktop users). I'm not aware that anyone is advocating to remove standard ELF binary support from the Linux kernel, so I don't see how this would be a problem. If you don't want universal binaries, just don't use them.
Sort of. The analogy breaks down if you take it too far.
There was an article in Make magazine about how to build your own pulse jet out of a jar with a hole in the lid and a bit of alcohol in the bottom. I haven't tried it.
If I remember correctly from seeing watching the tech talk on youtube about a year or so ago, the idea is not to produce a continuous, stable fusion reaction, but to produce an unstable reaction that lasts for only a moment. By creating reactions many times per second, substantial amounts of energy are produced. (Hopefully more than is needed to initiate the reactions in the first place.)
The device is in some ways similar to a spark plug.
I would recommend including Phantastes by George MacDonald, which is a good example of the type of fantasy that influenced the later work of Tolkien and C.S. Lewis. The copyright is even expired.
I would also recommend a few of Tolkien's less well-known stories, like Leaf by Niggle or Smith of Wooton Major.
If you want to expose them to the Silmarillion, I'd recommend the chapter on Beren and Luthien, and the one about Turin.
I'd also recommend Cory Doctorow, though I haven't read any of his short stories.
Learn you a haskell is certainly a good place to start. Real world haskell is also available on the web, if you want more detail than LYAH provides, particularly as it pertains to building applications that deal with IO, networking, interaction, etc...
I've head closer to $2,000 per pound for low earth orbit. The moon would be more expensive, of course, and you're right that weight is the biggest cost.
Just because no one is going to lose tens of millions of dollars in venture capital if Love fails doesn't automatically make it low-risk. Love is high risk for the developer, Eskil, who is spending several years of his life with no income to write a game that may or may not be successful. It is high-risk in the sense that it employs some unique game mechanics that haven't been copied from other large, successful games.
Slashdot Mirror
Rather than type what I wrote in a similar thread again, I'll just link to it here.
Summary: qsort [1..10000] is slow not so much because it isn't an in-place sort, but because naive quicksort on an already-sorted list is O(N^2) rather than O(NlogN). If you use an element from the middle of the list as the pivot instead of the first element, it performs much better.
As the other reply already stated, you can do in-place quicksort in Haskell by using the ST monad, if that's really what you want.
Quicksort with in place arrays is O(nlogn). Quicksort with lists is O(nlogn). The difference between the two is a constant factor. Not everyone cares enough about constant factor speed increases that they would abandon a programming language because of it, but some do which was the point I was trying to make.
Using lists just means that quicksort isn't any better than any of the other nlogn sorts, but it's still one of the easiest efficient sorting methods to explain. Mergesort is usually preferred in functional programming circles because it's about equally complicated but you don't have to worry about bad performance in the already-sorted case.
Data.List.sort uses mergesort (and the implementation is actually a bit shorter than your code, though yours seems a bit more readable to me). http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html#sort
Well said.
It seems like that's not the point. The goal of having students write games isn't to turn them into game programmers, but to show them that programming can be fun, and then they can use their new skills to solve all sorts of problems.
Let's see if I can explain this simply.
The Haskell language, like any other language, needed constructs like "read" and "write", but to implement them as simple functions would have broken the underlying assumptions of purity and lazy evaluation.
Haskell happened to have monads. A monad is essentially a typeclass for containers, that allow you to do certain things to combine containers of the same type, without having to worry about what kind of container it is. Most (all?) of the containers in the standard library are instances of Monad.
The Haskell language designers came up with (or perhaps borrowed) an idea. They would create a new container type, called IO, and make it an instance of Monad. However, unlike other containers, it would not have any accessor functions. You can pass around an object around of type IO in pure code all you want, but you can't ever examine the contents of the IO container from within "pure" code. The only thing you can do with it is combine it with other IO objects. Combining two IO objects is equivalent to evaluating the file operation or what have you inside one IO object and passing it's result to and executing whatever is inside the second IO object. The actions within an IO object, however, are free to invoke pure code if they like.
Every haskell program has a main() function, which is an IO action. This allows you do do any necessary file IO your program needs to do, and it can also call out to pure functions. Pure function cannot invoke IO actions. Most Haskell programmers try to keep the IO actions as simple as possible and rely on pure code for the bulk of the program.
As a concrete example, I wrote a ray tracer, which parsed a text file and generated an image. As I was writing it, I got to the part where I needed to write the file parser. I thought "oh, no, this whole thing has to execute within the IO monad and it'll be a big mess". However, it was not so. After scratching my head a bit, I ended up writing a pure function that takes a simple text string and converts it to my internal representation of a scene, ready to be ray traced. Within main (within the IO monad), I would read the text file in with a lazy function "hGetContents", which returns a string which is the contents of the file. I would pass that string to the parser, and then trace a grid of rays (one per pixel) against the parsed scene. The list of pixels with their calculated color values was returned to the IO monad, where I used OpenGL to plot them to the screen.
The interesting bit about this is that hGetContents is lazy. In a strict (i.e. non-lazy) implementation, the whole string would be read at once. This is inefficient, and may cause problems for text files that won't fit in memory. Due to laziness, however, the string is passed into the parser without being fully evaluated. As the parser needs more data, the run-time system will cause hGetContents to read another block. So, here we have an example of a pure function that's indirectly triggering IO, and it's doing it all without violating the constraints of the type system.
I would consider Lua a functional language (and I think it's designers went out of their way to make it so), though it isn't exclusively functional; it is possible (and typical) to write imperative, stateful code in Lua as well. I haven't used it much, though, so it may be that there is some drawback to using a functional style that I haven't considered.
There are several reasons. As abigor stated, functional programming is not well understood by the majority of programmers. If you suppose that there is one Haskell programmer for every 1000 Java programmers, then that one Haskell programmer has to be one thousand times more productive in order to get noticed by the larger programming community. (I don't know if the distribution is that skewed, but I think you get the idea.) There are small companies that have been very successful at using FP, but they're easy to miss if you don't look in the right places.
Another reason is that the fastest functional languages are still slower than C in general. I don't think the difference is as much as you say, Haskell and Ocaml both have very good code generators. Do check out the "programming language shootout" results. (Be sure to use -O2 with ghc, though, or you really will see a 10x difference.) However, there are many programmers for whom if you give them a choice between one language and another, they will always choose the faster language regardless of other considerations. A lot of supercomputing people still use Fortran, for example.
A third reason is that software firms are very risk averse. If you have a problem that you know a team of average Java, C++, or C# programmers can solve in N months, versus a smaller team of more expensive functional programmers who may or may not be able to solve the problem in much less time in an unknown language that no one else seems to be willing to bet the farm on, then a lot of firms will see FP as an unacceptable risk.
Fourth, consider the sales pitch for Haskell: "Hey, check out this cool new language! It's a bit slower than C, and you can't change the value of any of the variables. It was designed by committee. Half of the people who use it got their PhD by hacking a type system extension onto ghc." The primary benefits of Haskell are hard to describe to people who haven't used it, namely that programs tend to have fewer bugs (thanks to the strict type checker), and it often takes much less code to solve a given problem. The drawbacks, however, are rather obvious up-front: how many programmers do you know who would welcome the idea of "everything is const"? There aren't really any Haskell programs that you couldn't write in C, or Java, or C++, or C#, or Python or any of dozens of other languages. The difference is, how much code are you going to write, and how much work is it going to take to make the program reliable?
I agree it's not always the best example, but there are four reasons why "qsort [1..10000]" is slow, and you can address three of them without writing something that's "100 times less readable than C".
The first problem is that naive quicksort on an already-sorted list/array is O(N^2). The fix is to grab an element out of the middle and use that as your pivot. That alone will make qsort far faster. (I tried it.*) The resulting code is, of course, a bit messier.
Secondly, the qsort function has no type signature, so it will default to the most polymorphic implementation, which is something like qsort :: Num a -> [a] -> [a]. Typing "qsort [1..10000] probably (though I'm not sure, it's a ghci-specific thing) defaults to using Integer, which is less efficient than a machine Int. If you constrain the type signature the code will be faster.
Thirdly, you're using ghci. Code compiled with "ghc -O2" is far faster. (Be sure not forget that -O2, it make the code about 10x faster.)
The fourth reason is that C is doing in-place array swaps. (You can do the same thing in Haskell using the ST monad if you really want to. I don't think the result will be "100 times less readable", but it will be fairly ugly compared to the pure version. There are a couple such implementation here.) Whether doing quicksort with lists is good enough really depends on what you're doing.
* Quicksort modified with a swap, then mangled by slashdot:
I would add a couple other "must have" features in functional languages:
* The ability to pass a function as an argument to another function (i.e. higher order functions, like qsort in the C standard library).
* Support for a points-free programming style in which things can be passed from one function to another without naming them.
Some other features that perhaps aren't technically required but make functional programming a lot easier:
* Closures, local function definitions, garbage collection, partial evaluation of function.
Whether it works or not depends on what your task is and how you try to solve it. There are several ways to do concurrency in Haskell, and they're each appropriate in different instances. If you're just calling a lot of pure functions, then "par" and "seq" might be what you need. If you need shared, mutable state, then STM might be a good approach. If you want to do message passing or traditional locking, then using Chan and/or Mvar in the IO monad might be the right thing.
I'd recommend looking at Real World Haskell chapters 24 and 28.
The announcement is perhaps a bit less interesting than the summary would have you believe... The most recent Haskell standard was Haskell 98, eleven years ago. A new committee was formed to bring the standard up to date with current implementations. Most of the changes listed have been in GHC and other implementations for some time now, and none of them appear to have anything to do with concurrency directly. (Which isn't to say that interesting stuff hasn't been happening in the Haskell world in that area, it just doesn't directly affect the core language.)
That's not true unless you are using a different definition of "functional" than I am. I can't comment on Scala since I haven't used it, but Erlang is indeed a functional language. It is not a _pure_ functional language, as Erlang does have some mechanisms for manipulating mutable, global state and message passing, but it's at least as functional as a lot of other language that are widely regarded as "functional programming languages" such as Lisp and ML.
I'm going to elaborate on the Maybe type idea because I think it is important. In Haskell, there's no distinction between a value and a pointer to a value, and these things can't be Null. In C, one often wants to represent, say, an optional value. A pointer can be used for this: it is either assigned a value, or it is NULL. In Haskell, we do the same thing with a Maybe type. Maybe is a container that can either have the value "Nothing", which means it's empty, or "Just a" where "a" is the value you stored.
The important thing about Maybe types is that they let you make a distinction between things that can be empty and things that can't. In C, any pointer can be NULL, so we can't tell from the type signature of a function if it's okay to pass in a NULL value or not. And indeed, a large proportion of all C runtime errors is the dreaded NULL pointer exception.
What I am suggesting, is that Go should have a notion of a pointer that can only point to a valid object, and a pointer that can be set to NULL. They type system should distinguish between these two cases, and the compiler should fail if the user tries to mix the two. NULLable pointers should only be used when absolutely necessary.
From what I've read so far, I have no idea if Go allows standard pointers to be NULL.
As a Haskell programmer myself, I see where you're coming from, but realistically there are a lot of C and C++ programmers who are never going to be able to accept the idea of "everything is const". There are also some problems for which Haskell would not be a good choice. (That category is much smaller than I initially thought, but there are still a few problems where the easiest way to get good performance is to just write it up in C.)
From the looks of it, the Go designers have at least borrowed some useful ideas from Erlang, and they have a primitive kind of type inference. Their "interface" mechanism also has a lot of similarity with Haskell's type classes.
The Go designers may not have borrowed as heavily as they might have from Haskell*, but at least the result is a lot closer to Haskell than C or C++.
* Things I hope the Go designers do borrow from Haskell: The "$" operator, Maybe types, parametric polymorphism. Things I hope the Haskell implementer borrow from Go: Erlang-style message passing, fast compilation.
They say that Go was designed to give them a better language for writing server code than the C++ they're using. I think it makes a lot of sense in that context. They don't need to use Go in every project to be a worthwhile effort.
We need as many new languages as it takes in order to get languages that actually work well for the jobs we need them to do. One of the reasons we have so many languages is that users are dissatisfied with current languages, so they roll their own. And it isn't just that the old languages were good at one thing, but bad at something else so we needed new tools to solve new problems. Many languages in common use aren't even very good at the things they're most commonly used for.
C basically works, but any moderately complicated C project inevitably turns into a huge project with many man years of effort to find all the bugs, most of which would never have gotten past a reasonably strict type checker. I'm pleased to see that C may get some serious competition from a language with modern features (like type inference and type safety) that may make it much easier to write high quality, fast, low-level code.
I do that. It's really not that big of a deal; sometimes I'm not even consciously aware that I've switched layouts. For awhile I had trouble with letters like "y" that you type with the same motion but the opposite hand.
I don't think you should dismiss the idea just because there are a few use cases where universal binaries wouldn't work. I've installed Linux on WRT54Gs before and am aware of their limitations, but I also can see how it might be convenient sometimes to distribute universal binaries (i.e. for desktop users). I'm not aware that anyone is advocating to remove standard ELF binary support from the Linux kernel, so I don't see how this would be a problem. If you don't want universal binaries, just don't use them.
Sort of. The analogy breaks down if you take it too far.
There was an article in Make magazine about how to build your own pulse jet out of a jar with a hole in the lid and a bit of alcohol in the bottom. I haven't tried it.
If I remember correctly from seeing watching the tech talk on youtube about a year or so ago, the idea is not to produce a continuous, stable fusion reaction, but to produce an unstable reaction that lasts for only a moment. By creating reactions many times per second, substantial amounts of energy are produced. (Hopefully more than is needed to initiate the reactions in the first place.) The device is in some ways similar to a spark plug.
I would recommend including Phantastes by George MacDonald, which is a good example of the type of fantasy that influenced the later work of Tolkien and C.S. Lewis. The copyright is even expired. I would also recommend a few of Tolkien's less well-known stories, like Leaf by Niggle or Smith of Wooton Major. If you want to expose them to the Silmarillion, I'd recommend the chapter on Beren and Luthien, and the one about Turin. I'd also recommend Cory Doctorow, though I haven't read any of his short stories.
Learn you a haskell is certainly a good place to start. Real world haskell is also available on the web, if you want more detail than LYAH provides, particularly as it pertains to building applications that deal with IO, networking, interaction, etc...
I've head closer to $2,000 per pound for low earth orbit. The moon would be more expensive, of course, and you're right that weight is the biggest cost.
Just because no one is going to lose tens of millions of dollars in venture capital if Love fails doesn't automatically make it low-risk. Love is high risk for the developer, Eskil, who is spending several years of his life with no income to write a game that may or may not be successful. It is high-risk in the sense that it employs some unique game mechanics that haven't been copied from other large, successful games.