Hello world example is the 'Just jump on the hump of the Wump of Gump' introduction to computing

by Offray Vladimir Luna Cárdenas — on  ,  ,  , 

cover-image

A critique to the most widely used introductory example to learn/teach programming languages/environments

We have used “Hello, World!” for the past 25 years because text was the medium that was easiest to manipulate with the given technology. Today’s technology can manipulate sound, graphics, and video with the same responsiveness and ease. Today’s technology produces the media that “kids these days” are consuming. These same kids can produce their kind of media using today’s technology. In fact, they want to. And they’ll learn programming to do it.

Mark Guzdial, Elliot Soloway in "Teaching the Nintendo Generation to Program"

"Hello world"?... teacher, what are you talking about?

My first experience with programming was at six, with logo at the Pompilio Martinez public primary school, in the small town of Cajicá, Colombia. After that programming has been an interesting but discontinous activity in my life, with broad gaps in between: graphical casio calculators at secondary school, pascal and C(++) as a freshman undergrad, and exploring mathematica, matlab, octave, python, by myself as student and scheme and Squeak smalltalk as teacher, and now Pharo as a reasearcher and hackerspace member. Not much happened with learning/practicing computing in my life in beween.

While using logo, calculators, math programming languages, scheme and smalltalk was refreshing because I was thinking about the world since the first exposition and examples in those languages, python, C(++), pascal and others introduce themselves with a popular but poor example: the 'Hello World' program. I remember, as a newbie, my disconfort with this example and asking myself what I'm trying to model/express here? A Teletubbie?

Greeting Teletubbies
^Up | Greeting Teletubbies

Of course, I understand the purpose of introducing the syntax of a language with a simple example, but language is a tool for thought and expression about/in the world and this seemed to me like a poor first example of how computers would help us to achive this. When I commented this to my fellow programmers, it seemed unimportant to them, kind of invisible problem: it was the "natural" thing to do for starting with a programming language/environment. After several years with this mostly lonely feeling, I found, almost by accident, a paper that shared my concern. Reasons were different, but conclusion was the same: Hello world is not a engaging example, in this case for the "nintendo generation", because it doesn't reflect a world of permanent interactivity, and their "other techology" does that all the time (which is increased by the pervasive social media, for good and bad). You don't need to be part of that generation to have this feeling. If you're young enough or old enough, well mainly if you're not a programmer, you'll feel it almost naturally. So in relevance and interactivity, the hello world example is really a poor one. After this first example, you almost surely would think: duh... seriously? computing seems powerful, playful, awesome and useful in the "real" life.

I learn/teach as an adult, mosly in the context of other youth and/or adults and to me the "hello world" is like 'Just jump on the hump of the Wump of Gump', or the "Mi mama me mima" in Spanish, of learning a language, which, when you get older, becomes more and more irrelevant and uninteresting. Even in rare ocasions when I teach children, I try to start with Scratch/Phratch environments and more interesting interactive examples that "Hello world" (what about making a video game or some robotics?)

An alternative approach

What I try to do when I learn/teach computing environments/languages to is to start with problems. These problems try to be interesting and in some cases real. I try to experience/experiment how the environment/languages would help us to deal with that problem an also which are their limitations for that. In some way this seems similar to the Freire's critical pedagogy, but was developed by myself as student and teacher (the fact that learning/teaching from problems can be developed independently in different contexts, being them explicitly informed or not by critical pedagogy, is one of the powerful aspects of Freire's approach to education. When you find it you think: wow that resonates a lot with my learning/teaching experience). Finding the proper problem is the main challenge here: it should be simple enough to first encounters, but relevant enough to matter.

The most recent case is the Data Week workshop. This is a recurrent meeting where we start with a problem, for example visualizing political discourses on twitter and we draft in the whiteboard what we want to acomplish and then come with one approach of that, made with the computer. It is not perfect, but give us, the participants, a sense of what can be done, what is difficult, and how to continue our explorations.

Mapas del silencio, del tablero al código: El tablero Mapas del silencio, del tablero al código: El código ^Up | whiteboard draft at the beginning of our Dataweek (mostly newbies) workshop and polished prototype result a few days after it ended. Details, in Spanish, here.

Despite of being intensive and prototype oriented and in that sense, similar to a hackathon, keeping the same problem between workshop editions gives a sense of continuity beyond the hype, randomness and usual futility of a typical hackathon. But at the same time we try to create some grounding curricula that let newbies to learn the basic and to confront their own interesting problems (see memories, in Spanish, for previous editions). Because we're working with data visualization, the feedback is richer and the participants get visual, symbolic and numerical representations in dialogue. While we're on the workshop, we contact local and international communities. In local context, all happens in HackBo, our local hackerspace and for international ones, we bridge the event with the communities behind Pharo, Moose and Agile Visualization (these ones are small, smart and overlapping which is an advange most of the time), by sharing results with them and letting the participants know them and become part of those communities.

To sum up:

  • Start with a problem, an interesting and/or real one. Choosing the proper problem is the challenge here: simple enough to be introductory, complex enough to be interesing.
  • Use several channels in dialog to approach and understand the problem: visual, numerical, symbolic.
  • Use the example problem in several editions of your teaching/learning experience to stablish continuity, but also create/adapt grounding material dealing with core concepts so learners can tackle other problems interesting to them.
  • To address the first 3 previous points is easier to start with particular infographic elements instead of full domain visualizations (unless you're doing a introductory workshop for that specific domain).
  • Connect your local and particular learning experience with broader communities local and international.

It's easier to let these things take the form of an experience, like a coding camp instead of a book, for example. Most of the books start with core concepts and end with real life problems/applications (which are too complex to start with). The Agile Vizualization book is not the exception. I think that a proper balance would be to chose a simpler problem to start with in a book, and deconstruct the elements that make the problem work in terms of core components and see how they can be recombined or modified to approach other problems or variations of the original one. This kind of literature can be complemetary to the more classical one. For example, I'm planning something that I call data selfies and data portraits, which show how people are reflected in the (broken) mirror of some social networks. They're not as complex as specific domain visualizations on epidemiology or astrophysics, but closer to infographic elements dealing with data, and representing specific problem issues. So we can use them to understand a problem and its representations (data, visual, code) and how basic components are used to build them without going to a full domain. I will keep you posted about how this idea advances.

Finally, I would like to thank to Leandro Caniglia and his wife for bootstrapping this post with an small conversation in the UBA coffe shop during the Smalltalks 2015, Argentina, where I came with the "Hola mundo es como el Mi mamá me mima de la programación" (I tried to use some kind of translation in the title considering how small kids learn English [1][2]). It was the first of many interesting conversations and hopefully of many more to come. Also thanks to Martin Bähr and Ben Coman for proof reading this blog entry (of course all remaining error are my fault).