Mr Fusion was based on the 1980s era kitchen appliance brand Mr Coffee

This is 2013 so we would have to call it the Keurig Fusion

I immediately did the same calculation. It's not that much relative to the footprint of a house, but it's probably quite huge compared to the footprint for an equivalent capacity natural gas or nuclear plant.

Whether it makes sense depends on the potentil revenue generation value of the land -- the opportunity cost. It wouldn't make economic sense in the Santa Clara Valley in CA, where land is fabulously expensive, but it might make sense in an undeveloped area of the Sonoran Desert where land is cheap -- e.g. on the outskirts of the Phoenix area. This discounts any environmental costs, of course, but these also would vary from site to site.

It's pretty clear this is not a technology for solving *all* our energy needs (as nuclear was intended to be in the 50's and 60's). But the nifty thing about electricity is that it doesn't matter where it comes from. You don't have to put all your eggs in one technology basket, you can use a mix of sources. Which means you can stop building these things when the marginal *environmental* cost starts to go up. You just have to build enough to reach economies of scale that allow you to make a decent profit.

Well, nuclear reactions that we can turn off like laser-initiated fusion are a lot nicer than the alternatives. The inside of your car engine is a raging inferno shot with electric sparks and compressed with inexorable steel cylinders. That doesn't keep you from going on a nice drive with your sweetie.

Just like python!

Actually, no.

Python lets you use spaces or tabs, and will do pretty much the right thing. You can sometimes get into trouble if you mix spaces and tabs.

If you have multiple lines and they are indented identically, they are a block. It's easy to indent identically if you use nothing but spaces; still easy if you use nothing but tabs. (If you indent with a mix of tabs and spaces, and use the identical indent on each line, it will still work but this is very non-recommended. If you indent two lines such that they visually line up, but they have spaces and tabs in a non-identical configuration, it won't work right... but Python will raise an exception and warn you.)

Recommended practice in the Python community is just to use spaces for indenting. Everyone's editor agrees on how that would work. Most editors have an option to use spaces automatically even if you hit a tab when indenting a line.

The white space situation in Python is not perfect, but you really cannot say that Python has a syntactic distinction between tabs and spaces like Make does.

Actually, GNU Make has got pretty good in this regard and usually does the correct thing if you use the wrong kind of indent.

This has not been my experience, but perhaps you are right. I have been using vim with syntax highlighting, and every time I use spaces instead of a tab, the highlighting reveals my mistake and I fix it, so I haven't screwed this up in a while.

If the tabs vs spaces thing was the only issue with Make, I could live with it (just as I can live with Python's handling of white space). The baroque syntax bothers me much more.

There is a lot I don't like about Make, including GNU Make. The extensions it has received over the years make it incredibly baroque. I can't work on nontrivial makefiles without keeping a copy of the reference manual open to look things up, and the magic differences between tabs and spaces mean I need syntax highlighting to make sure I know what my makefiles really will do.

So now GUILE integration. How many Slashdot users are big fans of the Scheme language? I appreciate the elegance but I don't want to work in it, and I don't look forward to trying to debug makefiles that make heavy use of it.

I'm not sure what to use to replace Make though. I'm a Python guy so I would probably want Scons or something like that, but Ruby fans probably want Rake, Java fans probably want Ant, and in general I don't think there is any consensus on what might be the best replacement for Make.

It's not just kids. I used to work on mobile software for guys doing various kinds of outdoor field work. I told clients to figure on replacing their PDAs at least every two years. I'd reckon about 20% broke outright each year, and at the end of two years even the ones that weren't actually broken were falling apart from heavy use. These were well-made PDAs in rugged cases that guys could carry in their pockets. I shudder to think what they're doing these days with iPads.

When you're thinking about adopting any kind of gizmo that's supposed to be used all day long, you have to look at that gizmo as disposable. Stuff happens to things you carry around all the time. I have a light touch with equipment, so my stuff tends to last longer than most people's; but even I once broke a Newton screen, back in the early days. There was a guy in my office who destroyed one laptop per year, like clockwork.

I used to tell my clients that equipment was made to be used and thrown away. The important thing is preserving data. If a device is so expensive you've got to count on people mollycoddling it, it's not ready for field use.

And she puts a piece of masking tape over the camera lens, right?

#27,315 of the collusional and oligarchic things that happen in real life that libertarians won't admit to when they enthuse about their ideology

apparently the free market regulates itself, and consumer choice takes care of problems like this. seriously?

why do people believe this free market fundamentalism nonsense?

simple fact: a market needs to be heavily regulated by a strong central govt, or small competitors get crushed and consumers get abused

wake up fanboys

You mean whites are a minority already? I'll have to call my Asian friends and tell them we're running the show now.

Or is it the Jews?

Let's disaggregate the data by US State, so we can find out which of them are dragging us down. Any wagers?

What was in the tablet offered at $1238.72/yr?

is that when you're looking for precedent there are always those two little words: "it depends". You can't count on history to repeat itself.

I don't think there's a fundamental economic principle that says, "productivity increases actually increases employment." Yes, it *tends* to do so. If the next dollar of labor produces fifty cents of income, a firm won't lay out that next dollar; but if it produces *two* dollars of income it will.

However that scenario assumes that demand for the product is "elastic"; that if you drop the price a little you'll sell more, and make more profit. Suppose demand for a product is *inelastic*, that dropping the price won't get you much more in units sold. If the market won't buy more widgets at a lower price, then it makes sense for a firm to lay off workers as productivity goes up.

In the past the fear that greater productivity would result in job loss tended not to come true. At the outset of the industrial revolution nearly everybody would be considered materially poor by modern standards. Even in my granfather's generation it was common to by new clothing just once a year, and nearly everybody mended their own clothing. When computers were introduced to do things like payroll, yes the people who manually processed paychecks lost their jobs, but businesses responded by demanding far more complex and timely financial information products.

Now we live in a different world now. Almost nobody darns socks or turns collars; they throw worn or even stained garments away. Clothes shopping has become a pastime, not an annual ritual; many people shop every week. Financial products turn on split-millisecond timing, and are so complex you need an advanced degree in math to understand them. It makes me wonder whether we might be approaching a kind of productivity/demand singularity.

The biggest problem with predicting the future isn't *what*, it's *when*. People were attempting computer tablets decades before the iPad, but until the processor, battery, software and user interface technology were all available it was an exercise in futility. Much of Steve Jobs' genius was a matter of timing, of sensing when there was an opportunity to be created. I think there may be a productivity singularity in our future, a point where our established wisdom based on past experience fails. But I can't say when that will occur. I'm certain the market has surprises in store for us, but in the short term at least they'll probably tend to confirm established wisdom.

disclaimer: I am not an economist. But I *do* write science fiction.

By established constitutional case law. A president doesn't have a line item veto, either formal (striking something down with a signature) or informal (pretending it isn't there).

Right, agreed. What you are describing reminds me of the approach recommended in some FORTH books, which they called "bottom-up design". You keep making building blocks and snapping them together into more-powerful building blocks, and iterate until you have completely built everything you need.

Design simple parts that work together well... keep in mind Gall's Law: "A complex system that works is invariably found to have evolved from a simple system that worked."

http://en.wikipedia.org/wiki/Gall's_law

And if you do have a bunch of simple parts that work well together, your design is likely to work well and be easy to expand.

In college I took one course where the instructor made us draw diagrams with bubbles and arrows before we wrote any actual code. Out in the real world of professional software development, I haven't yet worked at a place that did that, but left-corner design of simple systems has served me very well.

The most important book I read as a beginning software developer was Software Tools in Pascal. That book teaches a technique it calls "left-corner design". It's kind of a rule-of-thumb for how to do agile development informally.

The basic idea: pick some part of the task that is both basic and essential, and implement that. Get it working, and test it to make sure it works. Now, pick another part of the task, and implement as above; continue iterating until you either have met all the specs or are out of time.

If you meet all the specs, great! If you are out of time, you at least have something working. The book says something like "80% of the problem solved now is usually better than 100% of the problem solved later."

For example, if you are tasked with writing a sorting program, first make it sort using some sort of sane default (such as simply sorting by code points). Next add options (for example, being able to specify a locale sort order, case-insensitive sorting, removing duplicate lines, pulling from multiple input files, etc.). A really full-featured sorting program will have lots of options, but even a trivial one that just sorts a single way is better than nothing.

Also, the book recommends releasing early and often. If you have "customers" you let them look at it as early as possible; their feedback may warn you that your design has fatal flaws, or they may suggest features that nobody had thought of when imagining how the software should work. I have experienced this, and it's really cool when you get into a feedback loop with your customer(s), and the software just gets better and better.

Way back in high school, I tried to write a program to solve a physics problem. I hadn't heard of "left-corner design" and I didn't independently invent it. I spent a lot of time working on unessential features, and when I ran out of time I didn't have a program that did really anything useful.

This is the one thing I would most wish to tell a new software developer. Left-corner design.

P.S. Software Tools in Pascal is a rewrite of an older book, Software Tools, where the programs were written in a language called RATFOR. Later I found a copy of Software Tools and found it interesting what things were easier to write in Pascal vs. what things were easier in RATFOR... and when I thought about it I realized that everything was just easier in C. C really is the king of the "Third-Generation" languages.