Logo, a programming language with visionary ideas


Nowadays, computers are truly ubiquitous and accessible to children, e.g., iPads are used at certain kindergartens in Sweden. Could we leverage these computers to improve education, innovate on teaching methods, and help students at school? I firmly think that the answer is yes! The key relies on teaching children how to program computers, a mental and creative activity.

Recently, there has been considerable efforts to push computer programming to elementary and high schools. As a concrete example, I can cite the Computing at School initiative to promote programming at schools in the UK, which has Simon P. Jones (co-creator of Haskell) among its collaborators. Another relevant example is Pablo E. Martinéz Lopez, who is part of the effort program.ar to push programming at the public schools in Argentina. For that, Martinéz Lopez participated in the creation, design, and implementation of a new programming language called Gobstones.

mindstormsWhile randomly discussing about teaching programming at schools, a colegue of mine (Ezequiel Gutesman) pointed out to me the book MindStorms by Seymour Papert, one of the creator of Logo. Logo is a programming language for education created in the 60s, and while the book was firstly published in 1980 (and a second edition in 1993), I found the book’s principles and ideas still applicable today. Below, I briefly describe the most relevant insights I got from the book.

Computers should not program children

Nowadays, smartphone and tables are often loaded with applications designed to entertain children—in fact, parents use them as a sort of XXI century pacifier. Children quickly learn how to launch applications, overcome obstacles by leaning the tablet slightly to the right, switching between games with a push of a button, etc. It is a reality that children learn “the way of the computer” in no time. However, it is the computer that decides how children should interact with it. In other words, computers are currently indoctrinating, i.e., programming, our children. While knowing how to use computers is important, children should also be empowered to instruct computers to carry out tasks in the way that their imagination determines, i.e., without being limited or restricted by pre-established software and user interfaces.

No fear for programming

Another insight I found relevant in the book is the fact that teaching programming is an inclusive activity. If compared with learning mathematics, where students often feel that they either “got it” or “got it wrong” (a binary cruel classification), learning programming is about try and error. Students (and even professional programmers) do not often get their code free of errors in their first try. The fact that programming works like this makes a difference: students are welcome to try, after all, everyone is surely getting it wrong in the beginning. Students should not be scared of failing, the very nature of learning programming consists more about repairing code than getting it right at once.

Modularity as a necessity to repair code

A modular program is one that subdivides the code into smaller, reusable, independent parts called modules. For example, if you write a program that sells products online, the code could be divided into the modules to handle payments, to display products, and to administrate customers. Now, have you ever wondered how to teach a 10 years old kid such an advanced concept? In this matter, the book is enlightening: children should learn the value of modularity as an aid for debugging. Repairing a big chunk of code is indeed challenging, not only for children, but also for professional programmers. If the code is divided into modules, children can focus on repairing the errors related to a single module without having to understand the rest of the code found in the other modules—after all, a module is ideally conceived as a self-contained unit of code. By showing that modularity alleviates debugging, children have a practical and genuine motivation for writing modular code.

Formal thinking at a very early stagehistoria-logo-01

The book is built on the Piaget‘s principle that children create their own intellectual structure from the material they find around them—often referred to as culture. For instance, a child usually learns the properties of liquid when they pour it on the floor. The book states that children should be immerse in a “computer culture” that they are familiar with. In that way, children can build their own intellectual structures from an environment that they know. In the case of Logo, children are placed in a world where there is a turtle that moves in a two-dimensional plane and is able to draw lines while moving. The creators of Logo believed so strongly in this approach that the MIT lab, where Logo was thought, had a actual mechanical turtle—making the computer culture as concrete as it can be. Is this enough to learn programming? While it definitely helps, children should also develop formal thinking in order to be good programmers.

Piaget says that a child achieves the formal stage of reasoning if he/she achieves (1) self-referential thinking, i.e., thinking about how he/she thinks, and (2) combinatorial thinking, i.e., being able to enumerate all the possible states of a system. Self-referential thinking starts manifesting when children take their first steps in programming: they need to think how to teach (program) the turtle to draw the figure they imagine—this path makes children reflect on how they think. With respect to combinatorial thinking, Logo provides the concept of loops. A loop enables children to systematically repeat the turtle’s commands, e.g., a square on the screen can be drawn as repeating 4 times the following instructions: move forward the turtle 1 cm on the screen, and rotate the turtle to the right 90 degrees. To illustrate the power of loops, consider that you ask the children to deduce all the possible colors that can be obtained by combining Red, Blue, and Green. As a response to your question, they will most likely get stuck. However, asking the same question to children who know programming, their mind will probably conceive nested loops, where each of them iterates over the color palette in order to achieve all the possible colors. Although such program will have some errors (e.g., emitting duplicate colors), they would indeed solve the challenge by taking the notion of loops from their computer culture.

To conclude this post, I strongly encourage the reading of Seymour Papert’s book to any educator who teaches programming at schools. Actually, I would even dare to recommend it to teachers in first programming courses at Universities. The book is not only interesting from a historical perspective, but from the applicability and validity of its ideas today. Sometimes, it is good to revisit old ideas.


Systematically Learning Emacs

LaTeX code

LaTeX code

Users can use text editors for so many different purposes, which might range from simply writing letters to do some advance programming. Some years ago, I switched from Vim to GNU Emacs (Emacs) in order to boost my productivity writing scientific articles. On that time, it seemed that Emacs provided better support to handle LaTeX documents (bibliography or reference citations, on the fly spell checking, different font sizes depending on the section heading, etc.) Deliberately, I began to adopt it into my other main activity: programming. Unfortunately, I did not find it as impressive as for writing articles. I forced myself to learn some Emacs tricks, keyboard shortcuts, and installing different modes to allow better experiences when programming.
However, I had never had a systematic approach to learn Emacs. It was precisely for that I decided to read the book Learning GNU Emacs, 3rd edition.

Learning GNU Emacs book cover

Book cover

The book explains the principles behind Emacs in a easy and clear manner. The chapters are concise and to the point. Topics are usually summarized with a table of keyboard shortcuts—a useful help in the Emacs world. I briefly highlight what I consider the most interesting concepts described in the book.

  • When editing, it is handy to know about the kill ring (Chapter 2). This storage area allows to paste any text that has been deleted or copied.

  • Collaborative paper-writing might find you opening files with different line lengths. Emacs has a fill-mode (Chapter 2) to set up the column width and automatically reformat paragraphs according to that.

  • Emacs has a search mode capable to ignore quotes, punctuation symbols, and line breaks (Chapter 3). More interestingly, recursive editing allows to pause the current task, perform some editing, and then resume it. This feature turns out to be quite useful when, for instance, performing a search and replace activity.

  • Grasping the concepts of buffers, windows, and frames makes a difference when setting up a productive layout (Chapter 4).

  • It is no longer necessary to open a terminal to handle files (Chapter 5). Emacs has support for shell commands which smartly treats and organizes the produced outputs.

  • One of the most interesting topics in the book are related to write macros (Chapter 6) and programs for Emacs (Chapter 7). These chapters give a feeling regarding how extensible Emacs is.

The book has chapters which are a bit out-of-date and might not be of great interest nowadays. For instance, how to write ASCII articles (Chapter 7) and HTML code (Chapter 8) as well as handling CVS version control systems (Chapter 12). I believe that some of those chapters respond to the philosophy of you can do everything within Emacs, which I do not share.

All in all, the book is of great help to systematically learn Emacs. It is of easy reading and, while not all the chapters are interesting, it is worth reading if you wish to raise your experience (and productivity) with the editor.