Introducing Robot School

Clean Blue Dot Robot School is opening soon! This post outlines our initial approach. Expect to see refinements and additions.

Initial Lessons

Enter and Run Example Code

The first thing we do, when learning to write code, is enter some example code, and run it. Even professional programmers obtain examples of code and integrate them into commercial software. There is an infinite collection of code examples on the Internet.

Steps:

• Enter the code of an existing program (move-the-dot).
• Run the program.
• Go over the code to understand how it works.

Modify and Run Example Code

Professional programmers are constantly modifying code, whether it is their own code, code written by someone else, or a code example that may (or may not) become part of what a programmer needs to accomplish. The first thing you will notice, when learning to modify existing code, is that it does not always work. You may find yourself “undoing” your changes, to make it work again. You may find that the existing code does not work, even in its original form; or it works only on a particular machine, in a particular configuration.

If you break code by modifying it, this is a good thing! You will never fully understand the limitations of a system unless you break something. There is an infinite collection of broken code examples on the Internet, as well as an infinite collection of examples that may (or may not) fix a particular problem.

If you fail to break code by modifying it, you have been playing it safe: Keep modifying the code until you break something!

NOTE: Intentionally breaking things is not a recommended approach to pursuits other than programming, or where programs may direct robots to physically break things, therefore doing harm.

Steps:

1. Modify the code of an existing program (move-the-dot).
2. Run the program.
3. If the modified program works as expected, return to step 1.
4. Go over the code to understand why it does not work.
5. Modify the code to fix the problem.
6. Return to step 2.

No User Interface Design (yet)

We will avoid User Interface Design until much later, even keyboard input routines. Robot School is more about programming machines and less about using machines.

Robots operate autonomously, without user input. This is what makes them useful. If you have to constantly type commands into a machine, that is not programming. A robot that is dependent on user input to function is nothing more than a user-controlled toy; it is meaningless without a real-time operator.

Code Rather than Infrastructure

Not everything we write, as programmers, is code: Much of our work is necessary to satisfy infrastructural requirements; such as using a comma to separate items in a list, or a semicolon to denote the end of a line of code. Some programming languages/platforms are good at minimizing the amount of infrastructure that is necessary to support the actual code, and some are bad. Fortunately, programming robots is not as heavy on infrastructural requirements as, for example, User Interface (UI) Design; The worst of which (in my opinion) is designing User Interfaces for the Web.

DRY versus WET

DRY is an acronym for “Don’t Repeat Yourself.” The best code is DRY code. Easier to understand, easier to type, and easier to run. In contrast, WET is an acronym for “Write Everything Twice” or “Write Everything Thrice.” A good example of DRY code is functional C programming, where functions are re-used, as much as possible, to avoid implementation of a particular piece of functionality more than once. Even “Object-oriented” C++ code can be DRY, as long as it is not overtly refactored. An example of very WET code is the mixture of PHP, SQL, HTML, JavaScript, and CSS that is used for most Web sites: I call this WEFT (“Write Everything Five Times”), as the programmer must write five different representations, in five different languages, for every aspect of their program. Ruby on Rails offers some relief, on the SQL front, with Active Record, but programmers still need to write custom SQL for special operations. The Microsoft stack (ASP.NET) adds even more languages/frameworks to the pile, by offering the choice of “code first” or “database first” along with CLR (Common Language Runtime), which supports multiple languages, such as C#, J#, and Visual Basic; then there is WCF services and Transactional SQL to deal with. If that is not overloading enough, there are myriad cloud services and JavaScript-based frameworks that Web programmers could use. Good thing our robots are all operating on DRY code!

Artificial Intelligence

Our robots have AI, but are not dependent on any third-party AI implementations. Therefore, our robots operate with absolute autonomy; independent from the entire AI Industry. The AI that we program for our robots is restricted to specific areas of functionality, such as determining if an encountered object is waste, trash, recyclable, reusable, animal life, or plant life. We are aware, however, of the ecological cost of the machinations of the AI Industry, and we encourage integration of our open source code offerings to make their implementations more economical and planet-friendly.

Object-Oriented Programming

Object-Oriented Programming (OOP) is nothing more than a lie, that we (programmers) tell ourselves, to make our code easier to understand and maintain. It is also useful for making a published API/SDK easier to understand and utilize. No CPU executes code in an Object-Oriented way: compilers/interpreters reduce it all to “functional” machine code before any instructions are executed. We discourage the AI Industry practice of using AI to generate WET Object-Oriented code in cases where the code is never intended to be read by humans: AI could just as easily generate DRY “functional” code, minimizing the cost of execution. Again, we encourage integration of our open source code offerings to make their implementations more economical and planet-friendly.