They won't and can't understand the value in improvements in test suite results or complexity measures.

Explain very simply.

Features are assets.
Lines of code are liabilities.

People confuse the two because you need some code to make a feature, but every line has a finite chance of creating a bug incurring a support cost, and whether it introduces a bug or not it makes for more code to sort through to find the bugs in other parts of the code.

The only real value of your application is in the features. If that's hard for them to quantify, that's understandable, but if that's hard for them to understand then that's insane. If you like, as a last ditch effort you might go back to the scenario oriented demonstrations that were convincing the first time but if that doesn't work, it's time to look for greener pastures.

Knuth lost his wager how many times?
Of course there should be reviews.

And yes, in the short term, it would benefit the reviewer more than the reviewed. Does that make it a bad thing?
Think about organizations with highly centralized expertise and trust vs. ones where it's more distributed.
Which are better places to work, keep better people and do better over time?
If Google doesn't they should start making him do code reviews.

Consumption taxes, when level and consistent are recognized as being really highly efficient and non-distorting in comparison to other schemes.

The thing that stinks is that those at the lower and lower middle parts economic scale generally consume just about 100% of their income.
As a result, this sort of tax hits them the hardest.

In European countries, this is offset by directed government largess. I propose that instead of directed government largess with all the complexity/inefficiency and corruption that invites let's have the government's largest expenditure be transparent, no strings attached supplementation of legally earned pay, per pay period.

That supplement could start at a fixed level and then match fractionally increases in pay with a lower fractional match as these numbers rise and eventually, past a certain good upper middle class income at which point the match should go away and it just becomes a fixed figure (if the desire strikes to have the this figure decline as income rises, you haven't set your consumption tax high enough). This paired structure would work like a progressive income tax in terms of who it draws revenues from and at what rate except that it automatically captures the black market, those who legally (but still annoyingly!) mooch off others, and those who inherited money from dead relatives and do nothing to produce on their own.

If the fixed initial supplement were generous enough to bring a household just past poverty level then you could make the statement that we have no working poor anymore... which would be a amazing. And if you'd take that level and add in current minimum wage, you could abolish the minimum wage, which would make more marginal people employable and provide a path for them back toward a law abiding existence. In fact I'd wager it would more or less solve the problem of unemployment except for those with pretty severe disabilities. If you have a good system for recognizing that and caring for those people then could solve the problem of poverty in this country entirely except for the very few who are capable of work, but unwilling to do so. I'm fine with letting them go.

Anyways, just a suggestion, and yes I know the consumption tax rate would have to to be very high to do something like this. I still think it's the right way to go.

This guy is a marketing/business guy.
The innovations he's going to care about in the game itself... there's nothing about angry birds as a game that would qualify.

It's the business model. So yeah, low priced cell phone games will be huge in terms of adoption, doubtless rivaling and probably eclipsing consoles and PC gaming because most everyone has a phone on them at all times.
Profitability, meh, who knows. But he's resting on a wild success story so he projects into the future based on that.

But anyways, hats off to him as a marketing guy, he got us talking about Angry Birds.

Right now gas stations have obvious peak times during rush hours. Obviously, nothing so ridiculous as everyone going at the exact same time, which is the best fit to your blurb, but still, high demand times nonetheless. And if we were talking about energy delivery comparable to how and when we gas our cars, I agree you'd have a problem. However, most people will get most of their juice at home overnight, which while increasing electricity draw, doesn't demand a bigger power station than we have now.

Charging stations will predominantly serve road trippers, and there's categorically less of that sort of traffic, and from my experience on the road, the "fill up" times are much more random and better distributed than on a day with a 9-5. These charging stations would need a lot of juice and possibly some special handling by the grid, but there wouldn't have to be such a huge number of these, so I think the challenge could be dealt with reasonably well.

My major concern isn't what the consequences would be if electric vehicles became ubiquitous, but whether this, like so many other stories promising great things for electric cars right down the road, will turn out to be mostly hype. The charging time statement is pretty incredible, and deserves scrutiny... how can you charge so fast without generating a ton of heat?

As are most managers.

haven't done this on a car, but I'll definitely recommend it for luggage.
Have nice cover since I'm always travelling with my wife.
Also got plaid luggage tags.
When luggage gets misrouted, all you have to say is pink with plaid tags and it gets back to you 10X faster than it would otherwise.

Implicit variables give some of the same convenience in programming as pronouns in natural language, except unlike pronouns, the implicit variables have the same meaning each time. I've never been a fan of Perl syntax, but if you spend any amount of time in Perl at all $_, and @_ should be old friends.

I think having form of implicit variables in the language is a great convenience feature and the only thing I'd say is that they should have names that let you know what you're dealing with without internalizing a table of (mostly) $<FOO>. But then again, we're talking about Perl here.

It's true that disks have been around longer and are cheaper to mirror, but proper wear leveling SSDs are the norm now, so reliability concerns are mainly FUD, and TRIM support is also the norm now, so performance degradation nearly as big a problem as it was. Importantly, there's nothing analogous to a head crash... if you loose data, it's at a much smaller granularity and more frequent than actual data loss is that blocks get marked as bad when the bits get stuck and you loose a little capacity over time.

Also, I'll say that in much much less than 30 years of experience, I've already seen RAID fail in a practical sense 2 times... that is two failures within the same drive array too close together to be replaced. One was related to ordering procedures and bureaucracy (2 weeks should be enough time to get a replacement drive), but another pairing of failures were only a day and a half apart... that's impossible unless you're getting your components from best buy. It makes sense... if you're using the same drives from the same manufacturing run in the same way, you're practically begging them to die at the same time.

Finally, I do support the notion of local nightly backups to disk for convenience sake, but the only truly safe backup is one that's distributed geographically as well as with repetition in media.

How valuable your computer's speed is to you depends on how valuable you consider your time to be. At home, maybe it doesn't matter to you, but from your employers perspective the value of your time is quantifiable... basically: salary+benefits / expected hours of work. Other people have already run their numbers and YMMV, but to me it's pretty convincing that the payback interval in terms of time saved is pretty short... not to mention the saved aggravation. CPU is the bottleneck a small and shrinking category of applications. OS bloat is inevitable, but you can pick a slim distro if you're feeling weighed down. In your list, that leaves fragmentation which is a problem tailor made for SSDs, because random access is orders of magnitude faster.

Man in Black: All right. Where is the poison? The battle of wits has begun. It ends when you decide and we both drink, and find out who is right... and who is dead.

Vizzini: But it's so simple. All I have to do is divine from what I know of you: are you the sort of man who would put the poison into his own goblet or his enemy's? Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me.

Man in Black: You've made your decision then?

Vizzini: Not remotely. Because iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you.

Man in Black: Truly, you have a dizzying intellect.

Vizzini: Wait til I get going! Now, where was I?

Man in Black: Australia.

Being able to clearly make out the immediate section of road ahead (pothole vs. oil slick, to use your example) is much more important than long distance vision as long as illumination distance > braking distance(including reaction time). If you're driving faster than that, then you're an idiot.

Being blinded by oncoming cars with their high beams is a problem either way, but when I use my lights, I'm certainly not blinded for anywhere near 10s (maybe 2s) because my pupils are not nearly as dilated as yours. That, and other cars on the road can see me, so I'm less likely to be hit.

All around much, much safer to have the lights on.

Pull my finger indeed.

Add increased stupidity (poor public education combined with broader usage) to bloat in TGMLC to get a real sense for what will really be run on this fabulous new hardware.

The ability to load and run stuff in C libraries is present in most major languages because it's too useful not to include. A lot of minor languages compile through C and make things potentially even easier (at least at run time).

There's plenty of highly dynamic languages in both of those lists that directly or indirectly could do what you're asking for here.

I will say, I'm disappointed by the comments I've seen here on slashdot.

Best comment came from an anonymous coward about the pining for an "emergent" type system, the fact that we're not wired that way, and that while more power gives some more in the way of degrees of freedom, it doesn't mean that everything can be analyzed together... you have to have some way of focusing (and a pretty darn good one to prevent unimaginable problem blowup).

Bootstrapping works well when confined to a fixed arena with observable and unambiguous criteria for selection of behaviors or incorporating a piece of knowledge and observable and unambiguous criteria for judging the success thereof. That is to say, a tight focus and goal directed behavior. Without these and a tight feedback loop, the resulting system tends to disappoint.

Having as your scope, reading the web to gain an understanding of the world is um... just a bit outside that template for success. While the big talk may be a pre-requisite for grant interest, I doubt have nearly as many illusions as the average slashdot reader. I hope their work goes well, and I hope some of their techniques for extracting information from the web prove useful. That said, it looked like their initial target was classification only. Not trivial, but a very small part of the puzzle of intelligence to say the least, especially when you consider the fact that the classifications this thing will suck in will reflect mostly the sort of classifications that we don't take for granted.

And here I'll start reflecting my bias. I am a former #$HumanCyclist (I did an internship about 10 years ago), because even though I am in some ways disappointed, I do think that the fact that they're actually building something (and along the way have been solving problems with it) and have been for a lot of years means that there's a lot to learn from them.

Among the things the Cyc project has shown, is exactly how important these sorts of unstated classifications turn out to be in the problem of doing even the most mundane things right. But there's no point dwelling on that, because even assuming you have some impossibly large beautiful graph reflecting a really solid and well thought out classification of everything, from every angle (hahaha), you're nowhere.

Facts are fuel... the engine is the rules. Reading those from free text is a very, very dicey proposition, both because the parsing is infinitely harder, and because much more so than facts, they're largely unstated and in terms of our own learning, inferred from examples. You can set up probability matrixes or the like, but only if you know what you're evaluating for (how would you program "curiosity"?). Even if you do get those matrices, reasoning with them directly is pretty much impracticable, so you have to have to make some arbitrary decisions about when you're confident enough to say you "know" something. This is just really, really hard knowledge to get in any automated fashion.

Finally, for both facts and rules, the consequences of incorporating a poorly considered one can be quite dire, and there's no practiceable way (as the amount of knowledge grows) to know whether it's consistent with what is considered true to that point.

Getting even more slippery, there is no one context or frame to consider everything in. This goes equally well for facts and rules. You could try and split hairs and say that given enough antecedents, your facts and rules are solid. However, as any kind of remotely practical matter, you need a way of accumulating and organizing these antecedents, and that's true from both from an technical (engine execution), and practical (reasoning and learning ease) perspective.

Oh, and as a minor matter, languages are difficult enough from a syntactic dimension, and the symantics of it (in order to understand a statement, you have to understand the ones prior, the context or framing that may have switched, the built up assumptions that maybe can be discarded, maybe not, etc...) make for a truly fantastically dificult problem.

Finally, not everyone uses perfect grammar, is perfectly informed or even tells the truth all the time.

So... you might say the problem is a bit tricky :)

The solution may not look like Cyc very much, I don't really know... that's just the lens I've spent more time looking through than any other. I will say that I'm deeply skeptical of the ability to engineer higher order general case reasoning with neural nets because there's no way to understand intermediate states and do debugging, but if someone shows me it works, then great.

I wish this group luck in making meaningful incremental progress... mainly I think in the direction of techniques for extracting info from the web rather than on the general problem, but every bit helps.

I wish the same for my former employer who I believe has made meaningful incremental progress many times.
Just because nothing big enough to live up to the overblown expectations of the field has happened doesn't mean nothing is happening.