Quoting wikipedia: "Intel planned to have engineering samples of Larrabee ready by the end of 2008, with a video card featuring Larrabee hitting shelves in late 2009 or early 2010."
Of course, it's always possible that AMD or Nvidia could beat Intel to market with a ray-tracing friendly GPU, but it doesn't seem likely that they'll bet the farm on a technology that isn't well-established.
If you want to play a software ray-traced game right now (or you just want to heat your house for the winter), you might want to look at Outbound or Let There be Light, which are both open-source games (though they run on Windows) built on top of Arauna. Gameplay is not really up to par with commercial games, but as a technology demo they're quite impressive. Framerates are tolerable on reasonably modern CPUs.
Interesting article. A little light on details. (What renderer were they using? OpenRT? Something they wrote themselves? Is it based on Kd-trees? BVH? BIH?) Also, not much mention of animation. Re-sorting the geometry whenever objects move is a hard thing to do efficiently, though there has been a lot of recent research in this area.
I'm no free market radical, but this does seem like a good example of something that is best left to the market.
I would agree with you if consumers were provided with sufficient information to make informed choices, but they're not. In markets where consumers are unable to determine the quality of products (where quality in this particular example is energy efficiency; consumers are generally well informed about other quality metrics like brightness, resolution, size, etc...), only the worst products survive. See The market for lemons to understand why.
The time and money no doubt involved in this regulatory process might be better spent on improving the level of mandatory information disclosed in relation to all electrical products so that consumers can (voluntarily) make an informed decision.
I totally agree with you there. The right way to proceed is to mandate that any device that plugs into an electrical socket should be clearly labeled with it's peak and idle energy usage, and then let the markets decide.
Qwerty is better than dvorak despite conventional wisdom. We know this is true because a) some early studies that showed dvorak to be superior were flawed and b) more recent government studies have clearly shown that typists who have typed on qwerty their whole lives and then trained on dvorak for a month are slower than if they had just stuck with qwerty.
Also, anyone who thinks that network effects have an influence on market acceptance of products must be a commie. Product quality is clearly important, and it's too hard for me to imagine that there could possibly be more than one factor influencing product acceptance.
(I didn't read the whole article, so I may have overlooked a few more gems of insight.)
I use dvorak myself, and while I think I'm probably a faster dvorak typist now than I ever was with qwerty, that is only after using it for about 10 years. If you use both layouts on a daily basis, you'll probably always be slower than if you just pick one. (I can still type qwerty just fine without thinking about the transition, I just don't use it regularly.) However, speed isn't the only reason to use dvorak; I find that it's a lot more comfortable (and that isn't an easy thing to quantify). Comparing the two layouts objectively is probably close to impossible unless you use test subjects who have never used a computer or typewriter, so I think people ought to try it for themselves and if they like it that's great, and if they don't, that's fine too.
The real important number that we don't see reported very often, is what does the CPU consume when idle? I just got a 4-core phenom, and it sits at about 120 watts all day long, which is about the same as my athlon x2 which preceded it. Of course, it goes up to 200 watts or so when I'm really stressing the CPU, but as far as the power bill goes that's pretty irrelevant if I'm not crunching numbers all day long.
(I have a strange power supply that I found at a garage sale that's conveniently equipped with an analog watt meter that fits in one of the drive bays in the front of the computer.)
There's some documentation on Galois' web page. I looked at it once awhile back, and it seemed a lot like Haskell, but with extra syntax for doing common cryptographic operations.
Chapter 8 of the programming guide has example cryptol implementations of DES, RC5, and AES.
This free trial version lets you explore the Cryptol language. It compiles and interprets Cryptol specifications but does not translate the specification into an implementation and only QuickCheck verification is enabled. The download includes the documentation suite and many examples.
So, they're providing a compiler and an interpreter. It sounds like there's enough restrictions that it would be hard to use anything cryptol-derived as part of a commercial product (or even an open-source project) without paying for the full version. However, one might implement a new cryptographic algorithm first in cryptol and then in some other language like C.
Presumably, the cryptol implementation would be easier to reason about then the C implementation. (I haven't tried cryptol myself, but I understand this is one of its main selling points.) One could then feed both algorithms a lot of random input and see if they both come up with the answers every time. So, the cryptol version could serve as the reference implementation for the final released version.
This is obviously less interesting than if Galois had just released the whole thing for free, but it's still better than nothing. I was kind of surprised to see this made its way to the front page of slashdot after seeing the announcement first on the haskell-cafe a few days ago. It seemed like good news, just not the sort of thing that very many people are likely to be interested in.
What Galois has been doing that does deserve a lot of credit (in my opinion) is they've been actively supporting the haskell community. I may be somewhat biased to think favorably of the company since a few of my friends work there, but as a haskell user it does seem like the language has benefited a lot from some of the work done at Galois.
Firstly, cryptol is being released by Galois, a private company, and not the NSA directly. I don't know the details of Galois' relationship with the NSA, but my understanding is that cryptol was developed by Galois, and it's quite likely that the NSA doesn't have any say in whether cryptol is released or not.
Secondly, there are a lot of social benefits to widespread access to good cryptography. Bad security is a constant drain on the economy, in the form of stolen credit card numbers and the like.
Thirdly (and as someone else pointed out), the NSA has to work with a lot of private companies, and if those companies have access to better tools, they can more easily supply the NSA with the products they need.
For a history of the (often antagonistic) relationship between the NSA and those who would promote "crytographic anarchy", I'd recommend reading "Crypto" by Steven Levy. I don't know what the current ideology is within the NSA, but ten or twenty years ago they would likely have been very much opposed to widespread public access to cryptographic tools.
As I understand it, cryptol was developed by Galois, a private company, and not by the NSA. Whether you find this reassuring or not is up to you. However, if a tool for developing cryptographic protocols were to, say, substitute a weak algorithm in place of a strong one, in many cases it would simply fail to interoperate with any reference implementation not developed using cryptol.
Cryptol, as I understand it, was developed by Galois (who, for some reason, is not mentioned in the summary) and not by the NSA. It would be interesting to know whether it was a joint decision between Galois and the NSA to release cryptol, or just Galois' decision alone.
I think any atmosphere thick enough to provide enough buoyancy is going to cause a horrendous amount of drag at those speeds. Low earth orbit is about 8km per second. Wind resistance goes up proportional to (iirc) the cube of velocity.
I might be misunderstanding what you are saying, but I don't see how accelerating for a couple of weeks to achieve orbit is going to work. If you're not up to orbital velocity almost immediately, you're going to crash back into the earth. The international space station, for instance, orbits the earth in about an hour at an altitude just grazing the top of the atmosphere. If it were going just a little bit slower, it would crash immediately. Fortunately, there's not much up there to slow it down (though they do periodically have to burn propellant to maintain altitude).
Tethering the base of space elevator to a zeppelin might not be a bad idea, though, as it would isolate the effects of wind loading on the cable. I don't know if it would be worth the trouble or not. (On venus it might be the only option, given that the atmosphere moves much faster than the surface, i.e. one revolution per 4 earth days, versus about 8 earth months.)
Actually, launching stuff beyond earth orbit is one of the intended applications. Not the only one, mind you, and maybe not even the most important, but it's not a new idea. In order to function properly (i.e. not fall down), the elevator will have a counterweight on a tether beyond geosynchronous orbit to counteract the weight of the tether between earth and geosynchronous orbit. If you go out to the end of the tether where the counterweight is and let go, you get flung off into space with considerable velocity. Depending on how long the counterweight tether is, you could lob stuff off the end and have it arrive in the vicinity of, say, Mars, without having to use rocket propulsion at all.
The article seems to be saying that you aren't going to be able to lob stuff off the end with any accuracy if it's swinging back and forth. I don't see this as an unsolvable problem, just a matter of keeping track of position and velocity of all parts of the elevator at all times and being able to make accurate simulations of the results of any actions before they're taken.
Also, the elevator's rotation is going to be inclined to the plane of the ecliptic anyways due to earth's tilt (unless it swings back and forth to compensate), so proper alignment wrt mars (or other exciting destinations) is already going to depend on time of day and time of year (to say nothing of the position of mars).
I did try OCaml a little while back, reasoning that because it supports mutable state, it would be easier to learn. It was. I ended up writing procedural code in it, which rather defeated the whole point.
Ocaml was a nice transition language for me. I got used to ML syntax and functional programming ideas, but I could fall back on imperative concepts if I got stuck. This book helped a lot to show how to get stuff done in a number of different styles.
Haskell's the best option that I know of, but the syntax is rather weird to anyone who's used to languages like C or Java. Are there any other lazy, strict functional languages that aren't descended from the ML family that I should look at?
There may be, but none that I'm familiar with. Syntax you can get used to if it's consistent; that's one reason I prefer haskell to ocaml, the former (in my view) has a better thought out syntax. (Ocaml's revised standard form seems to be a lot better than the default syntax, but the existence of a whole cottage industry in the ocaml world around camlp4 scripts to modify the syntax should be an indication that something is wrong.)
That said, there are some common coding idioms in haskell that I've just never gotten used to. The "$" operator I have come to appreciate, but "." just seems confusing. I think the best approach if you're writing code from scratch is to just use whatever syntax seems the most straightforward at the time, and ignore whatever you don't need to get the job done.
If you're still willing to give haskell a go, I'd recommend "The Haskell School of Expression" as a pretty good book on doing things in a functional way. It's perhaps a less good book if you don't want to write just pure code, but want to understand IO, state, and monads in depth as well (for which "Real World Haskell" is perhaps a better choice).
You have shared data in the 1.5-2 gigabyte neighborhood. It should be pretty obvious that you can't give each thread their own copy of that structure. More importantly, every thread must update entries in that data structure. If they don't, then the thread that handles the next request won't have the updates from this thread to work with.
I realize that some parallel tasks need to share mutable data; that is, in fact, what STM is for. To use STM, (as I understand it, I'm no expert) you just store your mutable state inside of TVars, which are generic containers that can hold any normal value as long as it's well typed (Ints, Lists, Tuples, More TVars, etc...). In the case of your web analytics server, I imagine you might construct a hash table out of a large array of TVars indexed by, perhaps, some hash of the client's IP and port number. All of the threads on the machine have access to the array (which is just a pure immutable global variable), but to read or write to any individual TVar element, the thread has to call readTVar or writeTVar, which can only be called within atomic transactions within the STM monad.
If two threads race and, say, one writes to a TVar that's being read by another thread in another transaction, the runtime system responds by re-executing the conflicting transactions.
One could reasonably claim that this doesn't sound a whole lot like functional programming anymore, but the clever thing about STM is that the runtime system can safely replay transactions because they aren't allowed to cause any side effects outside of the TVars managed by STM. There aren't many programming languages that can make a guarantee like that.
There might be other valid reasons for not using Haskell in this sort of system (file descriptor exhaustion if they're not being garbage collected fast enough, lack of a parallel garbage collector, slower than C in general, higher memory use, difficulty in finding qualified developers, etc...) but you seem to be arguing that Haskell wouldn't work in your case because it can't share state between threads, which isn't the case.
There's definitely a big learning curve. In haskell, a lot of the things you'd normally do with loops can be achieved through standard library functions, but you have to know a lot of functions to get anything done.
Bad analogy: C is like DOS, whereas Haskell is like Linux. In DOS you could do just about everything there was to do with about 8 commands (cd, edit, md, rd, dir, del, copy, move). On my current ubuntu box, there are 1931 programs in/usr/bin. Of course, I don't need to know them all to get stuff done, but it helps to know more than 8.
So, instead of iterating over a data structure with a loop, you use maps and folds. It's a different way of doing things.
IO is a particular stumbling block for many who would learn Haskell. IO itself isn't really any trickier than it is in any other language, but to do IO you also need at least a rudimentary understanding of the whole monad thing. I think the only solution is to find one of the several good books on programmin in haskell. (Real World Haskell just came out, and is focused particularly on making useful programs that interact with, say, files and databases.) From my experiences, Haskell IO makes a lot more sense than it did when I started. It seems like a lot of work initially, but it's nice to be able to look at a several thousand line program you wrote and not have calls to read and write, and mutable global variables everywhere.
It's even taught in every basic programming course: avoid global variables, stick to local variables only so you don't have to worry about side effects and synchronization. So why hasn't this taken the world by storm at any point in the last 30 years?
Because sometimes global variables are really convenient, and the compiler for most languages doesn't force the programmer to write the program the right way.
It's certainly not impossible to write correct parallel C code, but the fact that it's easy to write incorrect code means that a lot of parallel C programs are incorrectly written. Or the programs call libraries that were written by someone who didn't need thread safety for their application.
The difference between C and the Haskell STM monad is that the latter enforces the constraint that your code can't be mutating any global state except that which is accessed through the STM api. If you try to write to a global variable, the program won't compile because you're not in the right monad to be able to do that.
The extra protection that STM enforces might come at some run-time costs; there may be cases where the programmer knows that a certain operation is safe, but must still pay for the STM overhead regardless. There are situations where C really is the right language for doing parallel computation, but C does tend to be high-maintenance simply because it lets programmers do dumb things. And even if you write perfect code, you may have to work with programmers who don't, and you might dependencies on libraries that you don't necessarily know if they're thread-safe or not. Rather than expecting everyone to be perfect, it seems to me safer and easier (in this case, at least) to use tools that have fewer ways they can be used incorrectly.
Sometimes C is a defensible choice, but if you just want to write a program quickly and have it work without a lot of testing and debugging, Haskell might not be a bad option.
I agree. I don't understand them very well, but fortunately one can make use of them without a complete understanding. For many programs, it suffices to understand that if you want to do IO, you need to do it within the IO monad (often in the IO action "main" which is equivalent to "int main() {...}" in C).
This doesn't mean you have to write whole file parsers in monadic fashion, which is what I thought until I actually had occasion to write a file parser in Haskell, and found that I could write the parser as a pure function that accepts a string and returns the parsed data structure. Then, in main, I just read the file in with hGetContents (which takes a filename and returns a string) and then pass that string to my pure file parser.
This would seem horribly inefficient for large files; what if there isn't enough memory to store the whole file as a string? But here, laziness comes to the rescue. The actual file IO doesn't happen until the file parser starts reading in the string. My pure function churns along, oblivious to the fact that it's causing deferred IO in the background, simply from forcing the evaluation of the string's value.
This is, perhaps, not a very great insight into the nature of monads, but I thought I would share my experience, and if not enlighten then at least show that one can write normal programs in a fairly straightforward manner without being fully enlightened.
And multi-threaded is hard. It's not a matter of the language, it's a matter of having to remember that other things may have their fingers in your data, or of designing things so they don't. That's what gives most programmers fits, and I don't see FP making that any easier because it happens before you've gotten to the code.
Many functional languages do not allow the program to manipulate shared state, which removes that whole class of problems; information sharing is limited to letting the run time system fork threads and copy function arguments and return values back and forth.
However, if you really do need shared mutable state (and there are plenty of algorithms that do), in Haskell there's software transactional memory, which provides a restricted API for manipulating shared mutable state with the STM monad. Since the code within an STM transaction is not allowed to cause side effects or access any shared mutable state outside of STM, the runtime system is able to stop and replay transactions whenever it detects conflicts. This is one area where FP actually can make things easier, by enabling the same sorts of operations you might do in an imperative multithreaded program, but doing it in a much safer way.
And, if you don't need shared mutable state, sometimes parallelism can be achieved just by replacing "map" with "parMap" in the right places and recompiling with the appropriate options. It doesn't get much easier than that.
The biggest problem with functional languages tends to be their type systems (I'm looking at you, Haskell).
I would say rather that the nice thing about Haskell is its type system. I haven't programmed in Erlang, so I can't compare the two, but I find type inference and strong type checking make for easy refactoring, not a whole lot of unnecessary typing, and very robust code.
I would say Haskell, but I think that's the language everyone should learn, so I'm biased. The typeclass system provides for some of the functionality of object oriented programming.
If Haskell scares you, Ocaml is another good choice. It's a multi-paradigm language with an emphasis on functional programming, but it also allows you to use mutable state wherever you like (whether this is a good thing or not is a matter of some debate). It even has some traditional object-oriented programming features, but they tend not to get used much in practice.
If you care about performance, they both have decent native-code compilers. My impression is that Ocaml is a bit faster for single-core tasks, but Haskell's parallel programming features are much better.
While pure functional code isn't allowed to manipulate mutable, shared state, functional languages often provide some mechanism to mix "pure" and "impure" (stateful, imperative code).
In the haskell world, there is the IO monad, which is sort of a sandbox where anything is allowed. Functions within the IO monad (often called "IO actions") are allowed to invoke other IO actions or call pure code, but the reverse is not true; pure code cannot invoke an IO action. Also, due to laziness, pure functions that were passed an unevaluated "thunk" as an argument might trigger deferred IO, but this is (usually) transparent to the programmer.
So far, this doesn't sound any better than a pure imperative language, but there is also an STM monad (for software transactional memory) which is like pure code except that you're allowed to access shared mutable data through a restricted API. STM is based on the idea that if two processes race and manipulate the same shared data structures at the same time, the conflict can be detected by the run time system, which can stop and replay the transaction one after the other.
The reason STM transactions can be safely replayed by the run-time system is that the language guarantees that the STM transaction doesn't have any hidden state somewhere, that might cause problems if the transaction were replayed. This is not a guarantee you can make in C, C++, Java, or any other popular language that I am aware of.
Note 1: It is possible for STM transactions to livelock if they continually conflict and are replayed, so you can still shoot yourself in the foot. However, it does make avoiding certain other problems much easier.
Note 2: I'm not really a haskell guru, so everything above should be taken with a grain of salt. Real World Haskell has a chapter on STM, which is the basis of my current understanding (I haven't yet had cause to use STM in any program I've written.)
"Salt-tolerant (moderately halophytic) barley and/or sugar beets are commonly used for the extraction of Sodium chloride (common salt) to reclaim fields that were previously flooded by sea water."
Slashdot Mirror
Quoting wikipedia: "Intel planned to have engineering samples of Larrabee ready by the end of 2008, with a video card featuring Larrabee hitting shelves in late 2009 or early 2010."
Of course, it's always possible that AMD or Nvidia could beat Intel to market with a ray-tracing friendly GPU, but it doesn't seem likely that they'll bet the farm on a technology that isn't well-established.
If you want to play a software ray-traced game right now (or you just want to heat your house for the winter), you might want to look at Outbound or Let There be Light, which are both open-source games (though they run on Windows) built on top of Arauna. Gameplay is not really up to par with commercial games, but as a technology demo they're quite impressive. Framerates are tolerable on reasonably modern CPUs.
Ah, I guess I skimmed the article a little too quickly.
Interesting article. A little light on details. (What renderer were they using? OpenRT? Something they wrote themselves? Is it based on Kd-trees? BVH? BIH?) Also, not much mention of animation. Re-sorting the geometry whenever objects move is a hard thing to do efficiently, though there has been a lot of recent research in this area.
I would agree with you if consumers were provided with sufficient information to make informed choices, but they're not. In markets where consumers are unable to determine the quality of products (where quality in this particular example is energy efficiency; consumers are generally well informed about other quality metrics like brightness, resolution, size, etc...), only the worst products survive. See The market for lemons to understand why.
I totally agree with you there. The right way to proceed is to mandate that any device that plugs into an electrical socket should be clearly labeled with it's peak and idle energy usage, and then let the markets decide.
(I didn't read the whole article, so I may have overlooked a few more gems of insight.)
I use dvorak myself, and while I think I'm probably a faster dvorak typist now than I ever was with qwerty, that is only after using it for about 10 years. If you use both layouts on a daily basis, you'll probably always be slower than if you just pick one. (I can still type qwerty just fine without thinking about the transition, I just don't use it regularly.) However, speed isn't the only reason to use dvorak; I find that it's a lot more comfortable (and that isn't an easy thing to quantify). Comparing the two layouts objectively is probably close to impossible unless you use test subjects who have never used a computer or typewriter, so I think people ought to try it for themselves and if they like it that's great, and if they don't, that's fine too.
The real important number that we don't see reported very often, is what does the CPU consume when idle? I just got a 4-core phenom, and it sits at about 120 watts all day long, which is about the same as my athlon x2 which preceded it. Of course, it goes up to 200 watts or so when I'm really stressing the CPU, but as far as the power bill goes that's pretty irrelevant if I'm not crunching numbers all day long.
(I have a strange power supply that I found at a garage sale that's conveniently equipped with an analog watt meter that fits in one of the drive bays in the front of the computer.)
That wasn't intentional. I think I must not have enclosed the "a href" tag properly. Here, let me try again.
I assure you that there really is such a company; I have visited their offices on several occasions.
There's some documentation on Galois' web page. I looked at it once awhile back, and it seemed a lot like Haskell, but with extra syntax for doing common cryptographic operations.
Chapter 8 of the programming guide has example cryptol implementations of DES, RC5, and AES.
From the download page:
So, they're providing a compiler and an interpreter. It sounds like there's enough restrictions that it would be hard to use anything cryptol-derived as part of a commercial product (or even an open-source project) without paying for the full version. However, one might implement a new cryptographic algorithm first in cryptol and then in some other language like C.
Presumably, the cryptol implementation would be easier to reason about then the C implementation. (I haven't tried cryptol myself, but I understand this is one of its main selling points.) One could then feed both algorithms a lot of random input and see if they both come up with the answers every time. So, the cryptol version could serve as the reference implementation for the final released version.
This is obviously less interesting than if Galois had just released the whole thing for free, but it's still better than nothing. I was kind of surprised to see this made its way to the front page of slashdot after seeing the announcement first on the haskell-cafe a few days ago. It seemed like good news, just not the sort of thing that very many people are likely to be interested in.
What Galois has been doing that does deserve a lot of credit (in my opinion) is they've been actively supporting the haskell community. I may be somewhat biased to think favorably of the company since a few of my friends work there, but as a haskell user it does seem like the language has benefited a lot from some of the work done at Galois.
Firstly, cryptol is being released by Galois, a private company, and not the NSA directly. I don't know the details of Galois' relationship with the NSA, but my understanding is that cryptol was developed by Galois, and it's quite likely that the NSA doesn't have any say in whether cryptol is released or not.
Secondly, there are a lot of social benefits to widespread access to good cryptography. Bad security is a constant drain on the economy, in the form of stolen credit card numbers and the like.
Thirdly (and as someone else pointed out), the NSA has to work with a lot of private companies, and if those companies have access to better tools, they can more easily supply the NSA with the products they need.
For a history of the (often antagonistic) relationship between the NSA and those who would promote "crytographic anarchy", I'd recommend reading "Crypto" by Steven Levy. I don't know what the current ideology is within the NSA, but ten or twenty years ago they would likely have been very much opposed to widespread public access to cryptographic tools.
As I understand it, cryptol was developed by Galois, a private company, and not by the NSA. Whether you find this reassuring or not is up to you. However, if a tool for developing cryptographic protocols were to, say, substitute a weak algorithm in place of a strong one, in many cases it would simply fail to interoperate with any reference implementation not developed using cryptol.
Clarification:
Cryptol, as I understand it, was developed by Galois (who, for some reason, is not mentioned in the summary) and not by the NSA. It would be interesting to know whether it was a joint decision between Galois and the NSA to release cryptol, or just Galois' decision alone.
I think any atmosphere thick enough to provide enough buoyancy is going to cause a horrendous amount of drag at those speeds. Low earth orbit is about 8km per second. Wind resistance goes up proportional to (iirc) the cube of velocity.
I might be misunderstanding what you are saying, but I don't see how accelerating for a couple of weeks to achieve orbit is going to work. If you're not up to orbital velocity almost immediately, you're going to crash back into the earth. The international space station, for instance, orbits the earth in about an hour at an altitude just grazing the top of the atmosphere. If it were going just a little bit slower, it would crash immediately. Fortunately, there's not much up there to slow it down (though they do periodically have to burn propellant to maintain altitude).
Tethering the base of space elevator to a zeppelin might not be a bad idea, though, as it would isolate the effects of wind loading on the cable. I don't know if it would be worth the trouble or not. (On venus it might be the only option, given that the atmosphere moves much faster than the surface, i.e. one revolution per 4 earth days, versus about 8 earth months.)
Actually, launching stuff beyond earth orbit is one of the intended applications. Not the only one, mind you, and maybe not even the most important, but it's not a new idea. In order to function properly (i.e. not fall down), the elevator will have a counterweight on a tether beyond geosynchronous orbit to counteract the weight of the tether between earth and geosynchronous orbit. If you go out to the end of the tether where the counterweight is and let go, you get flung off into space with considerable velocity. Depending on how long the counterweight tether is, you could lob stuff off the end and have it arrive in the vicinity of, say, Mars, without having to use rocket propulsion at all.
The article seems to be saying that you aren't going to be able to lob stuff off the end with any accuracy if it's swinging back and forth. I don't see this as an unsolvable problem, just a matter of keeping track of position and velocity of all parts of the elevator at all times and being able to make accurate simulations of the results of any actions before they're taken.
Also, the elevator's rotation is going to be inclined to the plane of the ecliptic anyways due to earth's tilt (unless it swings back and forth to compensate), so proper alignment wrt mars (or other exciting destinations) is already going to depend on time of day and time of year (to say nothing of the position of mars).
Ocaml was a nice transition language for me. I got used to ML syntax and functional programming ideas, but I could fall back on imperative concepts if I got stuck. This book helped a lot to show how to get stuff done in a number of different styles.
There may be, but none that I'm familiar with. Syntax you can get used to if it's consistent; that's one reason I prefer haskell to ocaml, the former (in my view) has a better thought out syntax. (Ocaml's revised standard form seems to be a lot better than the default syntax, but the existence of a whole cottage industry in the ocaml world around camlp4 scripts to modify the syntax should be an indication that something is wrong.)
That said, there are some common coding idioms in haskell that I've just never gotten used to. The "$" operator I have come to appreciate, but "." just seems confusing. I think the best approach if you're writing code from scratch is to just use whatever syntax seems the most straightforward at the time, and ignore whatever you don't need to get the job done.
If you're still willing to give haskell a go, I'd recommend "The Haskell School of Expression" as a pretty good book on doing things in a functional way. It's perhaps a less good book if you don't want to write just pure code, but want to understand IO, state, and monads in depth as well (for which "Real World Haskell" is perhaps a better choice).
I realize that some parallel tasks need to share mutable data; that is, in fact, what STM is for. To use STM, (as I understand it, I'm no expert) you just store your mutable state inside of TVars, which are generic containers that can hold any normal value as long as it's well typed (Ints, Lists, Tuples, More TVars, etc...). In the case of your web analytics server, I imagine you might construct a hash table out of a large array of TVars indexed by, perhaps, some hash of the client's IP and port number. All of the threads on the machine have access to the array (which is just a pure immutable global variable), but to read or write to any individual TVar element, the thread has to call readTVar or writeTVar, which can only be called within atomic transactions within the STM monad.
If two threads race and, say, one writes to a TVar that's being read by another thread in another transaction, the runtime system responds by re-executing the conflicting transactions.
One could reasonably claim that this doesn't sound a whole lot like functional programming anymore, but the clever thing about STM is that the runtime system can safely replay transactions because they aren't allowed to cause any side effects outside of the TVars managed by STM. There aren't many programming languages that can make a guarantee like that.
There might be other valid reasons for not using Haskell in this sort of system (file descriptor exhaustion if they're not being garbage collected fast enough, lack of a parallel garbage collector, slower than C in general, higher memory use, difficulty in finding qualified developers, etc...) but you seem to be arguing that Haskell wouldn't work in your case because it can't share state between threads, which isn't the case.
There's definitely a big learning curve. In haskell, a lot of the things you'd normally do with loops can be achieved through standard library functions, but you have to know a lot of functions to get anything done.
Bad analogy: C is like DOS, whereas Haskell is like Linux. In DOS you could do just about everything there was to do with about 8 commands (cd, edit, md, rd, dir, del, copy, move). On my current ubuntu box, there are 1931 programs in /usr/bin. Of course, I don't need to know them all to get stuff done, but it helps to know more than 8.
So, instead of iterating over a data structure with a loop, you use maps and folds. It's a different way of doing things.
IO is a particular stumbling block for many who would learn Haskell. IO itself isn't really any trickier than it is in any other language, but to do IO you also need at least a rudimentary understanding of the whole monad thing. I think the only solution is to find one of the several good books on programmin in haskell. (Real World Haskell just came out, and is focused particularly on making useful programs that interact with, say, files and databases.) From my experiences, Haskell IO makes a lot more sense than it did when I started. It seems like a lot of work initially, but it's nice to be able to look at a several thousand line program you wrote and not have calls to read and write, and mutable global variables everywhere.
Because sometimes global variables are really convenient, and the compiler for most languages doesn't force the programmer to write the program the right way.
It's certainly not impossible to write correct parallel C code, but the fact that it's easy to write incorrect code means that a lot of parallel C programs are incorrectly written. Or the programs call libraries that were written by someone who didn't need thread safety for their application.
The difference between C and the Haskell STM monad is that the latter enforces the constraint that your code can't be mutating any global state except that which is accessed through the STM api. If you try to write to a global variable, the program won't compile because you're not in the right monad to be able to do that.
The extra protection that STM enforces might come at some run-time costs; there may be cases where the programmer knows that a certain operation is safe, but must still pay for the STM overhead regardless. There are situations where C really is the right language for doing parallel computation, but C does tend to be high-maintenance simply because it lets programmers do dumb things. And even if you write perfect code, you may have to work with programmers who don't, and you might dependencies on libraries that you don't necessarily know if they're thread-safe or not. Rather than expecting everyone to be perfect, it seems to me safer and easier (in this case, at least) to use tools that have fewer ways they can be used incorrectly.
Sometimes C is a defensible choice, but if you just want to write a program quickly and have it work without a lot of testing and debugging, Haskell might not be a bad option.
I agree. I don't understand them very well, but fortunately one can make use of them without a complete understanding. For many programs, it suffices to understand that if you want to do IO, you need to do it within the IO monad (often in the IO action "main" which is equivalent to "int main() {...}" in C).
This doesn't mean you have to write whole file parsers in monadic fashion, which is what I thought until I actually had occasion to write a file parser in Haskell, and found that I could write the parser as a pure function that accepts a string and returns the parsed data structure. Then, in main, I just read the file in with hGetContents (which takes a filename and returns a string) and then pass that string to my pure file parser.
This would seem horribly inefficient for large files; what if there isn't enough memory to store the whole file as a string? But here, laziness comes to the rescue. The actual file IO doesn't happen until the file parser starts reading in the string. My pure function churns along, oblivious to the fact that it's causing deferred IO in the background, simply from forcing the evaluation of the string's value.
This is, perhaps, not a very great insight into the nature of monads, but I thought I would share my experience, and if not enlighten then at least show that one can write normal programs in a fairly straightforward manner without being fully enlightened.
Many functional languages do not allow the program to manipulate shared state, which removes that whole class of problems; information sharing is limited to letting the run time system fork threads and copy function arguments and return values back and forth.
However, if you really do need shared mutable state (and there are plenty of algorithms that do), in Haskell there's software transactional memory, which provides a restricted API for manipulating shared mutable state with the STM monad. Since the code within an STM transaction is not allowed to cause side effects or access any shared mutable state outside of STM, the runtime system is able to stop and replay transactions whenever it detects conflicts. This is one area where FP actually can make things easier, by enabling the same sorts of operations you might do in an imperative multithreaded program, but doing it in a much safer way.
And, if you don't need shared mutable state, sometimes parallelism can be achieved just by replacing "map" with "parMap" in the right places and recompiling with the appropriate options. It doesn't get much easier than that.
I would say rather that the nice thing about Haskell is its type system. I haven't programmed in Erlang, so I can't compare the two, but I find type inference and strong type checking make for easy refactoring, not a whole lot of unnecessary typing, and very robust code.
I would say Haskell, but I think that's the language everyone should learn, so I'm biased. The typeclass system provides for some of the functionality of object oriented programming.
If Haskell scares you, Ocaml is another good choice. It's a multi-paradigm language with an emphasis on functional programming, but it also allows you to use mutable state wherever you like (whether this is a good thing or not is a matter of some debate). It even has some traditional object-oriented programming features, but they tend not to get used much in practice.
If you care about performance, they both have decent native-code compilers. My impression is that Ocaml is a bit faster for single-core tasks, but Haskell's parallel programming features are much better.
While pure functional code isn't allowed to manipulate mutable, shared state, functional languages often provide some mechanism to mix "pure" and "impure" (stateful, imperative code).
In the haskell world, there is the IO monad, which is sort of a sandbox where anything is allowed. Functions within the IO monad (often called "IO actions") are allowed to invoke other IO actions or call pure code, but the reverse is not true; pure code cannot invoke an IO action. Also, due to laziness, pure functions that were passed an unevaluated "thunk" as an argument might trigger deferred IO, but this is (usually) transparent to the programmer.
So far, this doesn't sound any better than a pure imperative language, but there is also an STM monad (for software transactional memory) which is like pure code except that you're allowed to access shared mutable data through a restricted API. STM is based on the idea that if two processes race and manipulate the same shared data structures at the same time, the conflict can be detected by the run time system, which can stop and replay the transaction one after the other.
The reason STM transactions can be safely replayed by the run-time system is that the language guarantees that the STM transaction doesn't have any hidden state somewhere, that might cause problems if the transaction were replayed. This is not a guarantee you can make in C, C++, Java, or any other popular language that I am aware of.
Note 1: It is possible for STM transactions to livelock if they continually conflict and are replayed, so you can still shoot yourself in the foot. However, it does make avoiding certain other problems much easier.
Note 2: I'm not really a haskell guru, so everything above should be taken with a grain of salt. Real World Haskell has a chapter on STM, which is the basis of my current understanding (I haven't yet had cause to use STM in any program I've written.)
I found some information on wikipedia about that:
"Salt-tolerant (moderately halophytic) barley and/or sugar beets are commonly used for the extraction of Sodium chloride (common salt) to reclaim fields that were previously flooded by sea water."