Although Mindstorms kits are available commercially, there are a series of specifically educational tools that the company has developed in conjunction with other organizations, including MIT, Pitsco, and National Instruments. These help expand robotics education beyond what was, arguably, the initial target audience: middle-school age boys.

Robotics in Elementary School

One of Lego's newest robotics programs goes a long way towards this, in part by starting much earlier than middle-school to introduce programming concepts. The Lego WeDo set is aimed at elementary school age children. This set uses the familiar, basic Lego bricks, as well as various gears, cams, and axles, and comes with a motor and two sensors - a tilt sensor and a motion sensor - along with a USB hub.

That hub lets students design creations that can, in turn, be plugged into the accompanying software and automated using a visual programming interface much like Scratch. By dragging-and-dropping commands together, students are able to easily program their creations. (In fact, you can actually use Scratch to run your WeDo robots too.)

The basic WeDo kit comes with a guide for building 12 different robots, each of them teaching a basic building concept. This makes the kits not just easy for elementary-age kids to use, but for teachers with limited programming or engineering knowledge.

But this is Lego we're talking about, and although every Lego kit comes with the designs for various models, the fun really begins when you start to design and build your own creations. The activities around the WeDo encourage just that thing - and not just with the building of models but with the programming component as well.

All of this makes WeDo seem a lot less "robotics" and a lot more, well, "Lego." The comfort level most of us have around Lego could be key to getting more students (and teachers) interested in science, technology, and engineering.

Rethinking Robotics Education (Rethinking Legos)

But Lego is also investigating other programs and projects to help challenge some of the stereotypes about robotics. At the ISTE conference last week, I watched a demo of Lego's Green City Challenge, a programming kit that asks you to build robots for environmental good, not just as battle-bots. While the skills learned in this challenge echo the sorts of things necessary for other robotics competitions, there's a social element here that, according to Andy Bell, LEGO Education's Director of Innovation and Alliances, may help get more girls interested in engineering and robotics.

All this effort at getting younger users to learn programming doesn't mean that Lego is forgetting older students. Indeed, Lego's robotics programs extend well into college now. Lego Tetrix, for example, is fully compatible with Lego Technic (the line of Legos that includes rods, wheels and more moveable parts) and with the Mindstorms controller. The big difference with Tetrix: the pieces are metal. (I don't know about you folks, but I'd rather have a Lego self-driving car than a Google one. Somewhere, there's a kid working on that very project right now. Thanks, Lego.)

The challenges that our schools face in teaching science, technology, engineering, and math have been making headlines lately, with many business and political leaders expressing concern that we aren't doing enough to equip students to work in the tech sector. It may well be that Lego, the most loved toy of all time, could go a long way to helping address that.

Scratch is often cited as one of the best introductory languages for teaching kids - or anyone, really - to code. So it's no surprise that a Rutgers University honors class called "Programming for the Masses" would utilize Scratch as part of its goal of making programming a more accessible, everyday skill. What is unique - and if I may say so, pretty fun - is the direction that a research project, an outgrowth of the class, has taken since.

Build Your Own Home Automation System

These devices use the BYOB (Build Your Own Blocks) offshoot of Scratch as the user interface. This way, the end-user can drag and drop blocks with commands instructing the device what to do (such as "turn on"), when or under what conditions. Ideally, people without any programming experience will be able to learn to program their devices by using this simple interface.

On the back-end, the programs that users write in Scratch are converted into radio transmissions received by the Scratchable Device. The devices are equipped with an XBee module connected to Arduino microcontrollers. The latter are programmed to read the messages and perform the necessary hardware actions.

The group has already built "Scratchable" lamps, alarm clocks, fans, and coffee makers, and they say they have more devices in the works.

We wrote a story earlier this fall with 4 suggestions for some of our favorite programming tools aimed at kids. And that list is worth repeating: the graphical programming language Scratch, the programmable robotics of Lego Mindstorms, the 3D programming environment Alice, and the Android App Inventor.

But in the spirit of National Computer Education Week and the hopes that we can encourage more kids not just to use technology but to build technology, here's a list of 4 more:

Kodu

A product of Microsoft FUSE Labs, Kodu is a visual programming language made especially for creating games. Kodu's language is entirely icon-based and is fairly easy to learn. By getting children to think about "if/then" statements, Kudo helps teach important programming concepts of actions and conditions. Kodu works on PC and XBox 360.

Small Basic

Another Microsoft project, Small Basic is a beginning programming language - a variant of BASIC, but based on the .NET platform. Small Basic is designed for students between the ages of 10 and 16 and consists of the language, the programming environment, and libraries. There are a number of resources available for working with Small Basic at TeachingKidsProgramming.org.

Arduino

Arduino is an open-source electronics prototyping platform with both a hardware and software component. Arduino's hardware is programmed with a language similar to C++, and although it may not be the easiest of entry points for learning programming, there's something about building things that actually move that can be pretty compelling. Projects that use Arduino to introduce children to programming include a modification of Scratch to support simple programming on the Arduino hardware.

Squeak

Squeak is an implementation of Smalltalk, an object-oriented programming language. The latter was designed in the 1970s in part as an educational tool for teaching programming. Squeak may be best known as part of the Children's Machine, part of the One Laptop Per Children initiative. Squeak is closely related with Objective-C, and Smalltalk and Squeak have both been influential on the development of other languages.

What other languages or platforms would you recommend for budding computer programmers? Python anyone? Let us know your experiences teaching kids to code in the comments.

As our world becomes more tech-oriented, educators are faced with not just teaching children how to use computers, but how to build and program them as well.

Fortunately, there are a number of great tools to teach programming to K-12 students, along with a lot of resources for computer science teachers:

1. Scratch

Developed by the MIT Media Lab, Scratch is a graphical programming language for children age 8 and up. Since its release in 2007, over one million projects have been shared on the site. That sharing aspect is important as projects posted are available to others to download and remix. Scratch is available free of charge, and runs on Mac, Windows, and Linux computers. For those working in Scratch, the new Scratch Wiki is a good resource.

2. App Inventor

In July, Google announced the launch of the Android App Inventor. App Inventor uses building blocks, of sorts, to help you design your own Android applications. Like Scratch, the App Inventor has roots at MIT, as the project was led by Professor Harold Abelson, quoted in a New York Times interview as saying that the goal of the App Inventor "is to enable people to become creators, not just consumers, in this mobile world."

App Inventor is still in closed beta, but it was mentioned in our survey of teachers' most anticipated back-to-school tech tools. If you're interested in App Inventor, the Google Group is very active.

3. Alice

Alice is a free and open source 3D programming environment designed to teach students object-oriented and event-driven programming. In Alice, students drag and drop graphic tiles in order to animate an object and create a program. A variant of Alice, Storytelling Alice was developed by Caitlin Kelleher as part of her doctoral work in Computer Science at Carnegie Mellon University. By emphasizing animations and social interactions, this approach was found to greatly increase the level of student interest in programming.

4. Lego Mindstorms

Lego was recently voted the "most popular toy ever," and despite all the wounds from stepping on my son's Legos while barefoot, I am still remarkably fond of the toy. Add programmable robotics to the mix, and you have Lego Mindstorms.

There are numerous other programs aimed at the K-12 level, including Small Basic, CHERP, Kodu, and of course BASIC.

Whether or not computer science becomes a baseline subject like Math or Writing or Social Studies remains to be seen. But the lessons learned from computer science - logic, critical thinking, problem solving - are crucial. So teach kids to hack while they're young.

We talk a lot in ReadWriteWeb about the products of mathematics, the programs and devices that amplify and extend the reach of our human dreams. But we rarely talk about the structure that underlies these things and makes them possible. There's a reason for that. Math is hard. So, I wrote a sonnet.

The Hirsch Conjecture, Disproved

Does math describe reality we know
Or is it just a self-referring system?
Do overlapping circles, either/or,
Obscure a vital truth, or truths sustain?

When someone like Santander's Paco Santos
Reaches out and wrings conjecture's neck,
Does he build, or simply banish phantoms?
Tell us what you've done was for our sakes.

Vertices in polytopes connect
By paths no more than d's length less than n,
Unless this theorem of Klee and Walkup, d-step,
The tyranny of Hirsch and Dantzig ends.

And if it does, are human souls ennobled?
Is one more bolted door to stars thrown open?

The proliferation of notification icons, that are not really associated with the delivery of any kind of notification, has added to the ineffectiveness, junking up the tray and making it harder to read at a glance.

"In Ubuntu 10.10, we plan to introduce a power menu, which replaces the Gnome Power Manager applet; a network menu, which replaces the Network Manager applet (nm-applet); and a clock menu, or time and date menu, that replaces the Gnome clock applet. We'll also be extending the sound menu, to replace the notification area items for music players...The pattern here is that everything is becoming a menu...Our roadmap is that in Ubuntu 11.04, one year from now, there will be no notification area."

As an alternative to sharding, Twitter has developed a framework that can be used in lieu of either custom-building data-store systems or using untested open-source alternatives and is sharing the code with the public.

As an example, Kallen provides "Rowz."

"To get up-and-running with Gizzard quickly, clone Rowz and start customizing!"

The full code for Gizzard is also available.

He describes Gizzard as a middleware networking service that handles partitioning through a forwarding table, supports migration and prosecutes "eventual consistency."

The implication of this may be that startups and smaller companies may better be able to deal with large amounts of data quickly, and thereby better serve the needs their users with fewer resources expended.

Overall, this looks like a very versatile tools for programmers and everybody else who wants to easily share short snippets of code.

Snipt.net

Of course, there is also snipt.net, which is not related to snipt.org at all (at least as far as we can tell), and which focuses on creating a repository of code snippets. Snipt.net does not feature any Twitter integration, though, according to the snipt.net team's latest Twitter updates, they are thinking about this.

The highly anticipated general release of StackOverflow, the social site for programming questions developed by rock star programmers Joel Spolsky and Jeff Atwood, hasn't happened yet - but the doors are cracked open and many new users are streaming in this morning.

The Big Idea

The idea behind StackOverflow is to offer a really well designed site where programmers can find answers to questions that are more obscure than they can get answered elsewhere. Site founders Spolsky and Attwood are software gurus focused on developer relations and user experience. They've got a very capable team with them as well, as is evidenced by the product so far.

The community is for developers working in any programming language and use of the site is completely free. The name StackOverflow refers to an infinite loop or recursion in the programming languages C or C++ and sure enough, a lot of the conversation on the site is self referential so far. The team's got plans for that, though, so we're confident this will be less the case than it is on other sites.

So far, we like it a lot. What does it look like? Check out these screen shots.

Screen Shots

The front page.

My Question Got Answered!

I got a good answer to an admittedly simple question, in 2 minutes. Awesome.

Asking a Question.

Pretty smart UI here, quite helpful and fun to use.

A User Profile

Above, the top half of a user profile, below the bottom half. Note that you can see how often a user votes things up or down but you cannot see specific voting history. The user feed is nice.

Our Thoughts

The UI here has lots of really nice little touches, it's responsive, communicative and relatively clear. We like it a lot and that was one of the site's big goals, to build an effective UI.

Account creation looks very good, it happens automatically via cookie until you register, but OpenID association with your account is not implemented particularly well. Attwood is blaming OpenID providers for that on Twitter, but we're seeing a few too many problems to buy that.

There's already an active community of beta testers on the site and they've developed extensions like a Firefox and IE7 search plugin, a couple of Greasemonkey scripts and a Ubiquity script. That's pretty awesome.

There's a sophisticated credibility system at work here, where users who build up their reputation are given new capabilities. Those capabilities include commenting on questions instead of just answering them and doing some moderation.

The "community mode" is interesting, things are wiki style on the site and once a certain number of edits have occurred the original asker of the question no longer owns it - it becomes a community question, with lower credibility thresh holds required for interaction, etc. The Community User username is tied to these threads and acts as an automated bot repairing things like malformed tags through out the site. That sounds really helpful.

Finally on the positive side, we got some good replies to our questions really quickly and we're already having a lot of fun just browsing the site.

The Down Sides

We like StackOverflow a lot so far, but there are some real concerns that deserve to be raised. As the site's owners have voiced throughout its development, the quality of discussions may go down rapidly when they open up to the world at large. We hope that's not the case but we will watch the reputation and bios of the people who answer our questions.

More importantly, perhaps, we're not sure the Digg-style home page is the best way to organize these discussion. Is it on the basis of the newness or hotness of questions that things should be ranked? Or should top answers be highlighted? We know that the site's developers have spent a lot of time wrestling with these questions, so we won't pretend to know better, but we hope the core prioritization principles work out well in this context.

There are some features that we expected to see here but don't. An easy way to mark a thread for reading later would be really helpful, as would a feed for those items in our account. A feed for answers given to our questions would be nice. So would the option to get an email notification when one of our questions is replied to, or another question we're interested in. GetSatisfaction's "I'm interested in this too" feature would make a world of sense - let me know when someone else gets an answer to this question because I'm curious. Finally, a "thanks for this" button like Ma.gonlia would make sense and offer a different kind of feedback.

We've already subscribed to the feeds for several topic tags and we're excited about everything we expect we can learn from the StackOverflow community. General availability of the site is expected sometime this week or next.

With Cascada Mobile's platform called Breeze, anyone can take their idea from thought to app in about fifteen minutes. Well, maybe not anyone - the apps are built using HTML, so you would have to have some rudimentary web programming knowledge to use their platform. Still, you have to admit, that's a lot easier than using a professional development platform.

With Breeze, you can build, test, and distribute mobile J2ME apps that run on hundreds and handsets. And these are "real" apps, too - fully integrated mobile applications with their own icon, not just mobile widgets.

The "Breeze Simulator" lets the novice developers test their app for hundreds of different handsets - a usually daunting task in the world of mobile web programming where apps that work on one model don't work on another, even if they're similar in design or from the same manufacturer.

Check out this video that shows Breeze in action:
Cascada Mobile Breeze from Cascada Mobile on Vimeo.

In addition, Breeze developers will receive a line of code they can put on their web sites, blogs, or social network profiles that let their visitors download the app by entering their mobile number. Breeze takes care of the distribution via SMS, WAP Push, and direct download. To subsidize the cost of distribution, the apps are ad-enabled. However, developers wanting to go ad-free can pay for the use of Breeze in order to do so.

Should Programming Be Left To the Professionals?

So, now we have an application that lets everyone program web apps (Iceberg) and a platform for building mobile J2ME apps, what's next? If this trend is to continue, the next big move would be to let novice developers build their own iPhone applications, you would think. But the real question is do we actually want amateurs building apps for our mobile devices? Or would you rather that was left to professionals?

You can try some Breeze applications for yourself from here. (Ooh, mobile Twitter!)

Learning Iceberg is relatively easy - Byrne says "20 minutes and you can be a programmer" - I'd argue it's a bit more than that if you haven't ever been exposed to any programming concepts, but it's far from impossible. To get you started, there's a vast and well-documented training section available from Iceberg's web site, which includes free sample applications, step-by-step guides, screenshots, diagrams, videos, and more.

Build an App in 3 Minutes

As far as what you can build with Iceberg, it's really up to you. Although the focus is on business applications, like CRM or PM tools, you can interface with anything that offers up a web service. For enterprise environments, instead of using Iceberg as a service, I.T. departments can download and use Iceberg offline, behind the firewall, to work with their in-house servers, like Windows SQL server for example.

For companies making an investment in using Iceberg, the team will even go a step further than just providing the service, but will also work with the business to help them with the process of building and customizing their apps. Several of the companies out of the 2000 or so downloads Iceberg has had to date have had this type of assistance, including companies that have moved from Zoho's CRM to their own personalized version.

Today, Iceberg is revving up to a new version: Iceberg 2.1. In this latest iteration, there are new features like a getting started wizard that makes creating applications as simple as answering simple questions about their business needs. They've also added a bug tracker, a more flexible interface, and a new embed feature that lets you "mashup" snippets from any web site or widget right into your form or application.

Google Maps Mashed Up in Form

They've also introduced what they're calling their first "killer app," a project management application for any design/development agency. With this app, users can manage projects, get intelligent estimates based on history, interact with clients, view charts, and more. Unlike with Basecamp, for example, emails are built into the system, you can automatically track and refer to all the communication about the project with ease.

Email functionality in Iceberg's PM App

If you've already written off Iceberg as just another business/enterprise app and therefore not for you, then you're missing the bigger picture. Of course, Iceberg is offering tools for business - that's where the money is - but it's also offering tools for the everyman/novice programmer. Want to build the next great Twitter app?  You can use Iceberg for that...but you can also use it to build the next Twitter, too.

If you want to try Iceberg today, you can download it from this link here for a special deal. The download includes 5 licenses, but if you choose to tell your friends about Iceberg, then you can get access to 2 more free licenses, as will your friends.

1. Loves To Code
2. Gets Things Done
3. Continuously Refactors Code
4. Uses Design Patterns
5. Writes Tests
6. Leverages Existing Code
7. Focuses on Usability
8. Writes Maintainable Code
9. Can Code in Any Language
10. Knows Basic Computer Science

1. Loves To Code

Programming is a labor of love. Like any occupation, truly great things are achieved only with passion. It is a common misconception that writing code is mechanical and purely scientific. In truth, the best software engineers are craftsman, bringing energy, ingenuity, and creativity to every line of code. Great engineers know when a small piece of code is shaping up perfectly and when the pieces of a large system start to fit together like a puzzle. Engineers who love to code derive pleasure from building software in much the same way a composer might feel ecstatic about finishing a symphony. It is that feeling of excitement and accomplishment that makes rockstar engineers love to code.

2. Gets Things Done

There are plenty of technical people out there who talk about software instead writing it. One of the most important traits of a great software engineer is that they actually code. They actually get things done. Smart people know that the best way to solve problems is go straight at them. Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand? The recent methodologies for building software, called Agile practices, focus on just that. The idea is to break complex projects into short iterations, each of which focuses on a small set of incremental features. Because each iteration takes just a few weeks to code, the features are manageable and simple. Teams that follow agile practices never create infrastructure for its own sake, instead they are focused on addressing a simple set of requirements. The secret is that when this approach is applied iteratively, a rich, complex piece of software arises naturally.

3. Continuously Refactors Code

Coding is very much like sculpting. Just like an artist is constantly perfecting his masterpiece, an engineer continuously reshapes his code to meet requirements in the best possible way. The discipline of reshaping code is known as refactoring and was formally described by Martin Fowler in his seminal book. The original idea behind refactoring was to improve code without changing what it does, moving pieces of the software around to ensure that the system is free of rot and also does what it is supposed to do based on current requirements. Continuous refactoring allows developers to solve another well-known problem - black box legacy code that no one wants to touch. For decades engineering culture dictated that you should not change the things that work. The issue, though, is that over time you become a slave to the old code, which grows unstable and incompatible. Refactoring changes that, because instead of the code owning you, you own the code. Refactoring establishes ongoing dialogue between the engineer and the code and leads to ownership, certainty, confidence, and stability in the system.

4. Uses Design Patterns

Ever since the so called Gang of Four published their famous Design Patterns book, world-class engineers have been talking about patterns. Patterns are ubiquitous in our world - both in nature and all human endeavors; software engineering is no exception. Patterns are recurrent scenarios and mechanisms that live across languages and systems. A good engineer always recognizes and leverages patterns, but is not driven by them. Instead of trying to fit the system into a set of patterns, the engineer recognizes opportunities in which to apply patterns. Applying a pattern ensures correctness since it leverages existing know-how: a method for solving a particular engineering problem that has worked before.

5. Writes Tests

Long gone are the days when engineers thought of testing as beneath them. After all, how can you be certain that your code is actually working if you never test it? An agile practice called Unit Testing has recently gained popularity because it focuses on writing tests to mirror the code. As the system grows, the body of tests grows with it, providing proof that the code actually works. Experienced engineers know and understand the value of tests, because their goal is to create a working system. Good engineers will always write a test once a bug has been exposed to make sure it does not come back again. But a good engineer also knows not to waste time writing trivial or redundant tests, instead focusing on testing the essential parts of each component.

6. Leverages Existing Code

Reinventing the wheel has always been one of the biggest problems in the software industry. From inventing new languages to rewriting libraries, the strange drive to ignore and redo what is already there and already works has been the cause of a lot of software failures. A rockstar engineer will focus on three essential kinds of reuse. First of all, the reuse of internal infrastructure, the code that he and his peers have written. Secondly, the use of third party libraries, for example, in Java, the libraries that are part of JDK or popular libraries provided by the Apache Foundation. And finally, a good engineer would look to leverage web-scale web service, like the ones offered by Amazon. Correct leveraging of existing infrastructure allows rockstar engineers to focus on what is most essential - the application itself.

7. Focuses on Usability

Good engineers always focus on the users. Whether the user is a business or an individual, whether the engineer works for a consumer software company or an investment bank, the focus is on working, usable software. How will users interact with the system? Does it provide a simple, intuitive, and smooth experience? The notion that because a software engineer is a techie, he or she thus can not relate to how other people interact with the system is deeply flawed. Good engineers work hard to make the system simple and usable. They think about customers all the time and do not try to invent convoluted stuff that can only be understood and appreciated by geeks.

8. Writes Maintainable Code

The other secret of good engineers is that it takes the same amount of time to write good code as it does to write bad code. A disciplined engineer thinks about the maintainability and evolution of the code from its first line. There is never any reason to write ugly code, a method that spawns multiple pages, or code with cryptic variable names. Rockstars write code which follows naming conventions, code which is compact, simple and not overly clever. Each line of code serves its purpose and resides in the right place. The bits that are difficult to understand are commented, but otherwise naming conventions are clear. Expressive names for methods and variables can make the code self-explanatory.

9. Can Code in Any Language

A good engineer might have a favorite programming language but is never religious about it. There are many great programming languages these days and to say that you only can code in one of them is to demonstrate a lack of versatility. In Java, C#, or C++ you can write any modern software. You can code the back end of any web site in PHP, in Perl, or in Ruby. At the end of the day, the language does not matter as much as the libraries that come with it. A good engineer knows that and is willing and able to learn new languages, new libraries and new ways of building systems.

10. Knows Basic Computer Science

The last, but certainly not the least trait of a great engineer is a solid foundation. A good engineer might not have a degree in computer science but must know the basics - data structures and algorithms. How can you build large scale software without knowing what a hashtable is? Or the difference between a linked list and an array? These are the basics that everyone should know. And the algorithms are just as important - from binary search to different sorts to graph traversals, a rockstar engineer must know and internalize the basics. These foundations are necessary to make the right design decisions when building any modern piece of software.

Conclusion

There are many traits that distinguish great software engineers. Among the ones we discussed, passion is certainly very important. Knowing the basics like code reuse, design patterns, fundamental data structures, and algorithms is necessary, while agile practices of refactoring and unit testing help engineers iteratively evolve complex software. Most importantly, rockstar engineers believe in simplicity and common sense. It is these beliefs that help them succeed in building the seemingly impossible, complex software systems that are necessary in today's world.

Let us know what other traits you think a rockstar software engineer should have, in the comments below.

And then what happens?

Programs will fail, of course. Since they will see times not as being in 2038 but rather in 1901, erroneous calculations and decisions will occur. (It's true, I checked Wikipedia!)

We've actually seen fallout from the 2038 bug already, back in May of 2006 when the AOLserver web server software crashed. The software was designed so that database requests would "never" time out. Instead of assigning a "0" to the timeout, the software specified a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date. The system calculated a timeout date that was actually in the past, got confused, and crashed.

The bug even affected the Mars Rover!

Want More Proof?

Check out the archived outputs from test scripts here:

• http://www.lugmen.org.ar/pipermail/lug-list/2005-May/035318.html
• http://www.sec.org.il/coverages.php?c=53
• http://unix.derkeiler.com/Mailing-Lists/AIX-L/2004-01/0011.html

What's Affected?

By 2038, it's likely that many of the susceptible machines will have been decommissioned before the critical date occurs. However, legacy systems and embedded systems could still be affected. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, routers, gas pumps, etc. It may not be possible to upgrade many of these systems, so they will need to be replaced.

I'm a Programmer - What Can I Do?

• Test your code or use utilities such as the FakeTime Preload Library.
• See the programming recommendations from The Open Group (formerly X/Open), which maintains the Unix specification and trademark.
• If you're working with Open Source code, this free library may be a useful reference for patching existing code for high-accuracy longterm time calculation.
• Read the Solutions to the Year 2000 Problem by Steve Manley. Many of his suggestions can be applied to the 2038 problem, too.
• Keep tabs on any recent updates on the 2038 Bug web site

(Source: the 2038 FAQ)

The End?

Before mass hysteria sets in, let's all remember that we have years, decades even, to deal with this latest programming glitch.

Well, I'm pretty sure that self-improving Artificial Intelligences will be running the world by then, so we probably don't need to worry too much about this.

(via guardian.co.uk)

]]> Discuss]]> http://www.readwriteweb.com/archives/the_internet_will_end_in_30_years.php http://www.readwriteweb.com/archives/the_internet_will_end_in_30_years.php Trends Thu, 13 Mar 2008 14:00:00 -0800 Sarah Perez