What you have described is called photon mapping. I think there is some support for photon mapping in at least some version of povray (I'm not sure if it ever made it in to an official release), but in any case it's an optional feature. It is more accurate to refer to povray as a ray-tracer. In ray-tracing, you send out rays from the camera position and test them for intersection against objects in the scene. These rays can in turn spawn additional rays (for reflection and refraction), and at each hit location you can cast a ray back to each light source to test whether that light is occluded by an object.
There actually are some pretty good game engines that do ray tracing. I'd recommend looking into Arauna and Brigade. (Last time I tried them they were a bit sluggish and ran at a low resolution, but that was about 5 years ago so things have probably gotten better.)
Road powered electric vehicles are awesome, I'm glad to see someone doing it, but I'm a little worried about safety and efficiency with the inductive charging technology. I certainly wouldn't want to be right on top of a 20khz rf transmitter that's pumping out tens of kilowatts. I don't remember the permissible exposure limits off the top of my head, but this sounds like it would be way above what's considered acceptable for HAM radio. Is there some way to keep that RF energy from spilling all over the place? How much of that energy actually makes it to the car, and how much is lost to RF, heat, noise, etc..?
Wrong, this still requires amplifiers every 100km, just like today.
They don't explicitly say that there were no repeaters for this particular test, but that is strongly implied. (Sloppy reporting.) However, they do compare it to a test done recently over 10,000km with no repeaters:
Then in January 2012 a Japanese team working out of NEC successfully transmitted 4Tbps over a single “ultra-long haul” (10,000km) fibre optic cable (no repeaters) by making use of WDM just like Alcatel-Lucent (here). Lest we not forget all the other developments, such as the successful UK test of a new type of hollow fibre optic cable that earlier this year delivered speeds of 73.7 Tbps (here).
Alcatel-Lucent might have just set a new record and one that it is arguably most notable for its distance but such records are clearly made to be broken. GCHQ will probably get a headache if they want to “tap” (spy) on the next generation of transoceanic cables.
I had no idea that those kinds of distances were possible without repeaters. This is, indeed, big news.
What do you think Wikipedia is going to need to do to keep up with content maintenance in the long term? Is editor decline inevitable, and thus the focus should be on making vandalism harder, or do you think current trends can be reversed with the right tools or policy?
There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).
Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs, because suddenly you have to care about whether the caller frees the list properly, and what if the things in the list are used elsewhere and we need to do reference counting etc.. etc... I've worked on a C codebase that was a couple hundred thousand lines of code, and I can't think of anywhere that we ever returned a list from a function. I can't think of any Haskell program more sophisticated than "hello world" that I didn't use "map" and other list functions all the time.
Ultimately, the cost of manual memory allocation isn't just the extra work you have to do to make sure you aren't leaking or corrupting memory, it's the algorithms you won't allow yourself to even consider because the memory management would just be too hard.
I'm not saying C doesn't have it's place, I'm just saying that there are software engineering costs associated with using C as opposed to a higher-level language.
Given that this thread mentioned using an RTG (a Radioisotope Thermal Generator, which is just an electrical generator that operates off of waste heat produced by a radioactive material decaying), it seems like the solution here is pretty obvious, even if it might be a painfully slow.
Guitar and piano are usually both equal tempered, though pianos typically have a slightly stretched octave to compensate for the strings having harmonics that aren't exact integer multiples of the fundamental. (In other words, it's done to compensate for the physical limitations of the instrument, rather than to compensate for the mathematical limitations of the tuning system.)
One can, of course, tune a piano to just intonation. (My piano is currently tuned that way, partly because I wanted to hear what it would sound like, and partly because, with an oscilloscope, it's a lot easier to tune to just intonation than 12TET and I'm too stingy to hire a tuner to do it the "right" way.)
It is possible to make a just intonation guitar as well, though it's not usually done. Here is one of mine that I made a couple years ago. I just finished putting together a just intonation walnut through-neck electric bass with a 2-octave fingerboard a couple days ago.
There's something that bothers me about this story. Linus's G+ account is basically a personal blog. It isn't tied directly to Linux or the open source community in any way other than that the author is Linus Torvalds and his posts occasionally mention Linux or open source software. If we were to judge everything Linus says about anything in public based on the criteria of how it "reflects on the open source community", then doesn't that essentially mean that we don't think Linus has a right to express his own opinions in public?
If you don't like those opinions, or find them offensive, that's fine. But let's not always assume that any famous person expressing an opinion must always be representing something bigger than him or her own self.
I second the functional language suggestion. For awhile, the only two languages I used regularly were C and (to a lesser extent) Perl, and felt a general sense of dissatisfaction with programming -- it wasn't clear at the time if it was the tools, or just me. I happened to take a pretty hard class on game tree search, and realized I needed to learn a more expressive language fast if I was going to keep up with the assignments. I picked Ocaml, and within a few weeks I was more productive (for the kinds of problems that were assigned as homework in this class) than I would have been in C or Perl. I stuck with it and eventually used Ocaml for some bigger projects that I did on my own. After a few years of Ocaml, I switched to Haskell because I wanted better parallelism support. By then, I'd become sufficiently accustomed to functional idioms that Haskell didn't scare me, and I've been using Haskell ever since. Not at my current job though, unfortunately... that's still C, but I rest easier knowing that there is a more pleasant way to get stuff done and I don't necessarily have to write C the rest of my life.
I have a netbook with Ubuntu 11.4. I didn't mind Unity at first, but then I quickly realized that a) it is designed to prevent me from working the way I want to and b) it's really buggy.
I won't elaborate on the second point. If you already know what I'm talking about, then fine, if not then it must either be working fine for you, or you aren't using Unity at all. Regarding the first point, though -- there seems to be someone out there with some sort of religion about not having two windows of the same application at once. Years back, there was a big controversy about Nautilus not opening a new window when you double-clicked on a directory. I didn't pay much attention because I don't use Nautilus. More recently, I've been using gedit quite a lot to write code (take that, vim and emacs users!), but every now and then I want to have two windows open so I can look at more than one file at once. Can't do it. If I try to open another gedit window, it just creates a new tab in the existing window. Maybe there's some way to turn this off, but it seems like a pretty bad default to have an application go out of its way to prevent a user from ever looking at two files at the same time. Fast forward to Ubuntu 11.4. Now, the application launcher thing on the left has some default launch buttons that can be deleted and replaced with the applications I actually use (good bye, word processor; hello, terminal). These launcher buttons have strange behavior though -- if the app is already running, they just highlight the window of the already opened app instead of opening a new window. I'm not convinced that's a good idea even for a word processor, but for terminals it's just unusable.
To be fair, it is possible to open multiple terminals if you don't use the launcher, but instead click on the magnifying glass with a plus in it, which (contrary to every GUI interface I've ever used before) isn't actually a zoom button, but rather is used to search for applications. Searching for terminal and launching it from there allows you to open more than one window.
I feel like the party line about Unity is that "It may be different from what you're used to, but Unity is a significantly better, more usable interface and it will be worth a short learning curve." In actuality, it seems like the real story is, "Working with multiple windows is too messy. We've fixed that bug by not allowing you to use multiple windows. If this upsets you, then you're not Ubuntu's target audience."
I haven't tried the newest Ubuntu. If it isn't any better, I think it might be time to start looking for a better distro.
Quite true. As I understand it, members of the United States military are subject to the uniform code of military justice, and we typically require soldiers to have immunity from local laws as a condition of us maintaining a military base on foreign soil. In the case of Iraq, they as a sovereign nation decided not to grant that immunity, so we're leaving.
I'm not so sure what the situation is for contractors. I believe there were a few embarrassing events where private security personnel killed civilians and, not being subject to either local laws or the UCMJ, there was no way to charge them with a crime. I don't know if Iraq has relinquished immunity from contractors since then.
I'm not sure exactly what you're trying to say, but it sounds like something along the lines of "We already have for loops and spinlocks and they work. Why would anyone want anything else?", so I'm just going to assume that's what you meant.
Haskell doesn't use for loops because they don't make any sense in a pure-functional execution model. "You want to cause a side effect N times? What is this "side-effect" that you speak of? What do you mean the body of the for loop doesn't have a value?" Haskell does have a sort of for loop for monadic code called forM_, if that's what you really want. Ignoring the restrictions of the Haskell model of computation, if we take a look at the for loop construct, there are few things in its favor and a few that aren't so great. It is simple and it is possible to express a surprising variety of common patterns with the for loop, thus freeing the programmer from learning to use a larger number of special purpose constructs (like map, fold, zip, etc...) that you might use in a language like Haskell. On the downside, though, for loops are rather verbose, they tend to be lousy at abstracting away the details of iterating over data structures, and the compiler often has to make fairly conservative about how it optimizes the loop. It may be a "solved problem", but technology isn't just about running with the first solution that happens to work. Sometimes, it's worthwhile asking if we're using the best abstractions. I'm sure Alta Vista thought search was a "solved problem" before Google showed up.
As for spinlocks, they certainly do work but they're pretty easy to misuse. Common mistakes include forgetting to grab a lock in the first place before reading or writing some shared variable and getting into deadlocks by acquiring multiple locks in an inconsistent order. You can't make either of those mistakes in STM, and it comes with an added benefit that it's possible to take two existing atomic operations and combine them into a single atomic operation without having to re-write the original two operations.
This is assuming you use STM, but in Haskell you don't have to. If you like spinlocks, then you'll be right at home with the MVar interface. Alternatively, it is possible to parallelize pure code without using locks at all, using par, parMap, pseq, etc... The neat thing about going the pure route is that you get parallel code that is deterministic. Pure functions are guaranteed to always return the same value given the same arguments, even if the function is implemented internally as a parallel computation. It's these sorts of invariants that make Haskell programs rather easier to reason about. If you know a certain class of bug won't happen, you don't have to be always on your guard.
I use Haskell for personal projects and use C at work. The reasons I use Haskell when I have a choice is that a) I like the typechecker to catch my mistakes, b) the language is performant enough for what I want to do, c) I can get a lot done with not very much code, d) the language is aesthetically appealing and e) using Haskell is fun. If "d" and "e" were the only reasons, I wouldn't use Haskell. I'm lazy, and if I just want to get something done, I'll usually do it the easiest way I know how. For many problems, Haskell is the easiest way I know.
I don't expect people who haven't used Haskell to understand this. I didn't, until I had used the language for awhile and found to my surprise (writing my first large Haskell program) that restricting file access to the IO monad not only didn't restrict me in any significant way, it actually made the design of the program cleaner than what I would have come up with had that restriction not been in place. "Clean design" may sound like an aesthetic issue, but for some reason cleanly designed programs seem to consistently work better than programs that aren't cleanly designed. (I'm not claiming that writing in Haskell is the only way to achieve clean design, just that the language seems to encourage it.)
Some programs I've written in Haskell are the glome raytracer (available on hackage), a web-app, and an environmental simulator. I would consider these, if not "real world" programs, then at least representative of real world programs. I could have written them in other languages... but I didn't. Glome is the most complicated piece of software I've ever written by far (meaning that it does a lot, not that is internally complex), and I don't think it's a coincidence that it was written in the most powerful language I know.
I don't think pre-rendering all possible images would be practical (except in a game like Myst where movement is confined); however when we get into the realm of global illumination, it does make a certain amount of sense to do the ambient lighting computation (which is the same regardless of camera position) up front. In a sense, this is what modern games already do -- the lighting effects are essentially painted on the walls as textures. I think the areas where there's room for improvement is that global illumination ought to respond to changes in the scene (opening a door or window, for instance), and these calculations could be made part of the game engine rather than as an artist's tool, so that procedurally-generated content could benefit from the same high-quality lighting effects as static scenes produced by level designers.
I'm a big fan of real-time ray tracing, but this doesn't sound all that exciting, considering that about three years ago I was able to play a real-time ray-traced game on a middle-of-the-road laptop. Resolution and framerate weren't great, but it was playable. The game I refer to is Outbound an open-source game based on the Arauna engine.
It's great that this is on Intel's radar, but whenever Intel demonstrates some new real-time ray-tracing demo that requires a cluster of machines, or some other kind of expensive, specialized hardware, I just think they've kind of missed the boat. We can already do that sort of thing on an ordinary desktop. (The linked site is down, so perhaps there's more to this announcement than the slashdot summary would lead me to believe.)
I think it's mostly a matter of the toolchain being different and very, very primitive. My impression of Verilog (from a few trivial experiments) is that it's the sort of language you might expect someone to design 40 years ago. Also, many idiom are different. Some things may be easier, but programmers tend to take for granted that they can make random memory accesses -- they don't expect to need to implement a memory controller to do so.
I have an EMU Proteus 2000 midi synthesizer that happens to have an FPGA in it. (I can't remember off the top of my head if it was a Xilinx Spartan or an Altera Cyclone, but I think it was one of those.)
It may sound strange, but sometimes it's actually pretty nice to have the computer built into the keyboard, but no screen. For several years I used an old laptop I bought cheap from a friend because the screen was cracked. I took the screen off and just plugged it into a monitor and used it like that -- it's nice to have a computer that's portable, but you can use with a full-size screen without the bulit-in screen getting in the way.
If I remember correctly, a couple of the proposed crops for making cellulosic ethanol are switchgrass and miscathus, and they both grow fine without human intervention. Switchgrass is native to North America. My understanding is that either crop could be used on land that isn't actively being farmed for food crops or that is "resting" for a few years as part of a normal crop rotation cycle.
Strange as it may seem, the parent is right - a lot of modern ad-hoc routing algorithms don't automatically keep their routing tables up-to-date -- instead, they flood the nework with a "where is so-and-so" message when they need to send a message to a certain host they don't already know about. As the reply is flooded back from the destination node, every other node learns how to reach it, and the path is built up by the forwarding nodes in the reply, so that when it finally gets back to the initiator, it knows the full path to get to the destination. Data packets are not flooded, only route requests and replies. This is how DSR works. AODV works a little differently but I don't remember the details. By contrast, OLSR is a link-state protocol rather than a distance-vector protocol -- every node tries to keep a current map of the whole network. This is expensive for large networks, but it's reasonably efficient for small ones, like you might see popping up in a disaster area in order to re-establish local communication. The nice thing about OLSR is it runs at the IP layer, so it doesn't have any kind of weird hardware dependency -- it's easy to set up on all kinds of computers (Linux, Windows, WRT54Gs...), or at least that was the state of things a couple years ago when I was using it.
I have used OLSR in small networks of wireless routers (running OpenWRT) and laptops, and it seems to work well. I haven't done any large-scale testing, but some people have.
Slashdot Mirror
What you have described is called photon mapping. I think there is some support for photon mapping in at least some version of povray (I'm not sure if it ever made it in to an official release), but in any case it's an optional feature. It is more accurate to refer to povray as a ray-tracer. In ray-tracing, you send out rays from the camera position and test them for intersection against objects in the scene. These rays can in turn spawn additional rays (for reflection and refraction), and at each hit location you can cast a ray back to each light source to test whether that light is occluded by an object.
There actually are some pretty good game engines that do ray tracing. I'd recommend looking into Arauna and Brigade. (Last time I tried them they were a bit sluggish and ran at a low resolution, but that was about 5 years ago so things have probably gotten better.)
That's quite an allegation. Do we have any reason to believe that Miranda was transporting anything of the kind?
Road powered electric vehicles are awesome, I'm glad to see someone doing it, but I'm a little worried about safety and efficiency with the inductive charging technology. I certainly wouldn't want to be right on top of a 20khz rf transmitter that's pumping out tens of kilowatts. I don't remember the permissible exposure limits off the top of my head, but this sounds like it would be way above what's considered acceptable for HAM radio. Is there some way to keep that RF energy from spilling all over the place? How much of that energy actually makes it to the car, and how much is lost to RF, heat, noise, etc..?
They don't explicitly say that there were no repeaters for this particular test, but that is strongly implied. (Sloppy reporting.) However, they do compare it to a test done recently over 10,000km with no repeaters:
I had no idea that those kinds of distances were possible without repeaters. This is, indeed, big news.
What do you think Wikipedia is going to need to do to keep up with content maintenance in the long term? Is editor decline inevitable, and thus the focus should be on making vandalism harder, or do you think current trends can be reversed with the right tools or policy?
There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).
Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs, because suddenly you have to care about whether the caller frees the list properly, and what if the things in the list are used elsewhere and we need to do reference counting etc.. etc... I've worked on a C codebase that was a couple hundred thousand lines of code, and I can't think of anywhere that we ever returned a list from a function. I can't think of any Haskell program more sophisticated than "hello world" that I didn't use "map" and other list functions all the time.
Ultimately, the cost of manual memory allocation isn't just the extra work you have to do to make sure you aren't leaking or corrupting memory, it's the algorithms you won't allow yourself to even consider because the memory management would just be too hard.
I'm not saying C doesn't have it's place, I'm just saying that there are software engineering costs associated with using C as opposed to a higher-level language.
Given that this thread mentioned using an RTG (a Radioisotope Thermal Generator, which is just an electrical generator that operates off of waste heat produced by a radioactive material decaying), it seems like the solution here is pretty obvious, even if it might be a painfully slow.
That's hard to do without the ethernet port, but it's been done with the model B.
Guitar and piano are usually both equal tempered, though pianos typically have a slightly stretched octave to compensate for the strings having harmonics that aren't exact integer multiples of the fundamental. (In other words, it's done to compensate for the physical limitations of the instrument, rather than to compensate for the mathematical limitations of the tuning system.)
One can, of course, tune a piano to just intonation. (My piano is currently tuned that way, partly because I wanted to hear what it would sound like, and partly because, with an oscilloscope, it's a lot easier to tune to just intonation than 12TET and I'm too stingy to hire a tuner to do it the "right" way.)
It is possible to make a just intonation guitar as well, though it's not usually done. Here is one of mine that I made a couple years ago. I just finished putting together a just intonation walnut through-neck electric bass with a 2-octave fingerboard a couple days ago.
There's something that bothers me about this story. Linus's G+ account is basically a personal blog. It isn't tied directly to Linux or the open source community in any way other than that the author is Linus Torvalds and his posts occasionally mention Linux or open source software. If we were to judge everything Linus says about anything in public based on the criteria of how it "reflects on the open source community", then doesn't that essentially mean that we don't think Linus has a right to express his own opinions in public?
If you don't like those opinions, or find them offensive, that's fine. But let's not always assume that any famous person expressing an opinion must always be representing something bigger than him or her own self.
I second the functional language suggestion. For awhile, the only two languages I used regularly were C and (to a lesser extent) Perl, and felt a general sense of dissatisfaction with programming -- it wasn't clear at the time if it was the tools, or just me. I happened to take a pretty hard class on game tree search, and realized I needed to learn a more expressive language fast if I was going to keep up with the assignments. I picked Ocaml, and within a few weeks I was more productive (for the kinds of problems that were assigned as homework in this class) than I would have been in C or Perl. I stuck with it and eventually used Ocaml for some bigger projects that I did on my own. After a few years of Ocaml, I switched to Haskell because I wanted better parallelism support. By then, I'd become sufficiently accustomed to functional idioms that Haskell didn't scare me, and I've been using Haskell ever since. Not at my current job though, unfortunately... that's still C, but I rest easier knowing that there is a more pleasant way to get stuff done and I don't necessarily have to write C the rest of my life.
I have a netbook with Ubuntu 11.4. I didn't mind Unity at first, but then I quickly realized that a) it is designed to prevent me from working the way I want to and b) it's really buggy.
I won't elaborate on the second point. If you already know what I'm talking about, then fine, if not then it must either be working fine for you, or you aren't using Unity at all. Regarding the first point, though -- there seems to be someone out there with some sort of religion about not having two windows of the same application at once. Years back, there was a big controversy about Nautilus not opening a new window when you double-clicked on a directory. I didn't pay much attention because I don't use Nautilus. More recently, I've been using gedit quite a lot to write code (take that, vim and emacs users!), but every now and then I want to have two windows open so I can look at more than one file at once. Can't do it. If I try to open another gedit window, it just creates a new tab in the existing window. Maybe there's some way to turn this off, but it seems like a pretty bad default to have an application go out of its way to prevent a user from ever looking at two files at the same time. Fast forward to Ubuntu 11.4. Now, the application launcher thing on the left has some default launch buttons that can be deleted and replaced with the applications I actually use (good bye, word processor; hello, terminal). These launcher buttons have strange behavior though -- if the app is already running, they just highlight the window of the already opened app instead of opening a new window. I'm not convinced that's a good idea even for a word processor, but for terminals it's just unusable.
To be fair, it is possible to open multiple terminals if you don't use the launcher, but instead click on the magnifying glass with a plus in it, which (contrary to every GUI interface I've ever used before) isn't actually a zoom button, but rather is used to search for applications. Searching for terminal and launching it from there allows you to open more than one window.
I feel like the party line about Unity is that "It may be different from what you're used to, but Unity is a significantly better, more usable interface and it will be worth a short learning curve." In actuality, it seems like the real story is, "Working with multiple windows is too messy. We've fixed that bug by not allowing you to use multiple windows. If this upsets you, then you're not Ubuntu's target audience."
I haven't tried the newest Ubuntu. If it isn't any better, I think it might be time to start looking for a better distro.
He runs electoral-vote.com and also wrote a textbook on operating systems that many of us read as undergrads.
+1
Quite true. As I understand it, members of the United States military are subject to the uniform code of military justice, and we typically require soldiers to have immunity from local laws as a condition of us maintaining a military base on foreign soil. In the case of Iraq, they as a sovereign nation decided not to grant that immunity, so we're leaving.
I'm not so sure what the situation is for contractors. I believe there were a few embarrassing events where private security personnel killed civilians and, not being subject to either local laws or the UCMJ, there was no way to charge them with a crime. I don't know if Iraq has relinquished immunity from contractors since then.
I'm not sure exactly what you're trying to say, but it sounds like something along the lines of "We already have for loops and spinlocks and they work. Why would anyone want anything else?", so I'm just going to assume that's what you meant.
Haskell doesn't use for loops because they don't make any sense in a pure-functional execution model. "You want to cause a side effect N times? What is this "side-effect" that you speak of? What do you mean the body of the for loop doesn't have a value?" Haskell does have a sort of for loop for monadic code called forM_, if that's what you really want. Ignoring the restrictions of the Haskell model of computation, if we take a look at the for loop construct, there are few things in its favor and a few that aren't so great. It is simple and it is possible to express a surprising variety of common patterns with the for loop, thus freeing the programmer from learning to use a larger number of special purpose constructs (like map, fold, zip, etc...) that you might use in a language like Haskell. On the downside, though, for loops are rather verbose, they tend to be lousy at abstracting away the details of iterating over data structures, and the compiler often has to make fairly conservative about how it optimizes the loop. It may be a "solved problem", but technology isn't just about running with the first solution that happens to work. Sometimes, it's worthwhile asking if we're using the best abstractions. I'm sure Alta Vista thought search was a "solved problem" before Google showed up.
As for spinlocks, they certainly do work but they're pretty easy to misuse. Common mistakes include forgetting to grab a lock in the first place before reading or writing some shared variable and getting into deadlocks by acquiring multiple locks in an inconsistent order. You can't make either of those mistakes in STM, and it comes with an added benefit that it's possible to take two existing atomic operations and combine them into a single atomic operation without having to re-write the original two operations.
This is assuming you use STM, but in Haskell you don't have to. If you like spinlocks, then you'll be right at home with the MVar interface. Alternatively, it is possible to parallelize pure code without using locks at all, using par, parMap, pseq, etc... The neat thing about going the pure route is that you get parallel code that is deterministic. Pure functions are guaranteed to always return the same value given the same arguments, even if the function is implemented internally as a parallel computation. It's these sorts of invariants that make Haskell programs rather easier to reason about. If you know a certain class of bug won't happen, you don't have to be always on your guard.
I use Haskell for personal projects and use C at work. The reasons I use Haskell when I have a choice is that a) I like the typechecker to catch my mistakes, b) the language is performant enough for what I want to do, c) I can get a lot done with not very much code, d) the language is aesthetically appealing and e) using Haskell is fun. If "d" and "e" were the only reasons, I wouldn't use Haskell. I'm lazy, and if I just want to get something done, I'll usually do it the easiest way I know how. For many problems, Haskell is the easiest way I know.
I don't expect people who haven't used Haskell to understand this. I didn't, until I had used the language for awhile and found to my surprise (writing my first large Haskell program) that restricting file access to the IO monad not only didn't restrict me in any significant way, it actually made the design of the program cleaner than what I would have come up with had that restriction not been in place. "Clean design" may sound like an aesthetic issue, but for some reason cleanly designed programs seem to consistently work better than programs that aren't cleanly designed. (I'm not claiming that writing in Haskell is the only way to achieve clean design, just that the language seems to encourage it.)
Some programs I've written in Haskell are the glome raytracer (available on hackage), a web-app, and an environmental simulator. I would consider these, if not "real world" programs, then at least representative of real world programs. I could have written them in other languages... but I didn't. Glome is the most complicated piece of software I've ever written by far (meaning that it does a lot, not that is internally complex), and I don't think it's a coincidence that it was written in the most powerful language I know.
I don't think pre-rendering all possible images would be practical (except in a game like Myst where movement is confined); however when we get into the realm of global illumination, it does make a certain amount of sense to do the ambient lighting computation (which is the same regardless of camera position) up front. In a sense, this is what modern games already do -- the lighting effects are essentially painted on the walls as textures. I think the areas where there's room for improvement is that global illumination ought to respond to changes in the scene (opening a door or window, for instance), and these calculations could be made part of the game engine rather than as an artist's tool, so that procedurally-generated content could benefit from the same high-quality lighting effects as static scenes produced by level designers.
I'm a big fan of real-time ray tracing, but this doesn't sound all that exciting, considering that about three years ago I was able to play a real-time ray-traced game on a middle-of-the-road laptop. Resolution and framerate weren't great, but it was playable. The game I refer to is Outbound an open-source game based on the Arauna engine.
It's great that this is on Intel's radar, but whenever Intel demonstrates some new real-time ray-tracing demo that requires a cluster of machines, or some other kind of expensive, specialized hardware, I just think they've kind of missed the boat. We can already do that sort of thing on an ordinary desktop. (The linked site is down, so perhaps there's more to this announcement than the slashdot summary would lead me to believe.)
I think it's mostly a matter of the toolchain being different and very, very primitive. My impression of Verilog (from a few trivial experiments) is that it's the sort of language you might expect someone to design 40 years ago. Also, many idiom are different. Some things may be easier, but programmers tend to take for granted that they can make random memory accesses -- they don't expect to need to implement a memory controller to do so.
I have an EMU Proteus 2000 midi synthesizer that happens to have an FPGA in it. (I can't remember off the top of my head if it was a Xilinx Spartan or an Altera Cyclone, but I think it was one of those.)
It may sound strange, but sometimes it's actually pretty nice to have the computer built into the keyboard, but no screen. For several years I used an old laptop I bought cheap from a friend because the screen was cracked. I took the screen off and just plugged it into a monitor and used it like that -- it's nice to have a computer that's portable, but you can use with a full-size screen without the bulit-in screen getting in the way.
If I remember correctly, a couple of the proposed crops for making cellulosic ethanol are switchgrass and miscathus, and they both grow fine without human intervention. Switchgrass is native to North America. My understanding is that either crop could be used on land that isn't actively being farmed for food crops or that is "resting" for a few years as part of a normal crop rotation cycle.
Strange as it may seem, the parent is right - a lot of modern ad-hoc routing algorithms don't automatically keep their routing tables up-to-date -- instead, they flood the nework with a "where is so-and-so" message when they need to send a message to a certain host they don't already know about. As the reply is flooded back from the destination node, every other node learns how to reach it, and the path is built up by the forwarding nodes in the reply, so that when it finally gets back to the initiator, it knows the full path to get to the destination. Data packets are not flooded, only route requests and replies. This is how DSR works. AODV works a little differently but I don't remember the details. By contrast, OLSR is a link-state protocol rather than a distance-vector protocol -- every node tries to keep a current map of the whole network. This is expensive for large networks, but it's reasonably efficient for small ones, like you might see popping up in a disaster area in order to re-establish local communication. The nice thing about OLSR is it runs at the IP layer, so it doesn't have any kind of weird hardware dependency -- it's easy to set up on all kinds of computers (Linux, Windows, WRT54Gs...), or at least that was the state of things a couple years ago when I was using it.
I have used OLSR in small networks of wireless routers (running OpenWRT) and laptops, and it seems to work well. I haven't done any large-scale testing, but some people have.