From Wiki

These are proposed guidelines for authors thinking about creating a ShowMeDo series on a programming language. They are proposed because they haven't been accepted yet. For now consider this as a working document that's open for change. It will hopefully from the start also serve as a useful resource for authors to help them demistify one of the many programming languages out there.

Contents 1 Introduction 2 Outline 3 Style guidelines 4 Find your own style 5 Content 6 Video settings 7 Feedback requested

Introduction

I'm writing these guidelines as I'm thinking and preparing a ShowMeDo series on the Perl programming language. At the same time I also would like to start planning and preparing for similar series on OCaml and C.

I find that introducing a programming language is not an easy task at all particularly because it's so easy to loose focus. If I would be learning a programming language - and I have learned many over the years - I want to first get a solid understanding about the basics of the language that I absolutely must know.

Later on I can then rely on this solid understanding to dive deeper into modules, libraries, tools, editors and so forth. But before all that I want to feel like I'm starting to master the basic concepts and am quickly advancing. I can use a book or any resource like a tutorial or - why not? - a ShowMeDo series :-)

If I would have had someone in the past who would have told me: learn this, this and that before you learn anything else, it would have saved many months of my time and waste of a lot of energy. For me learning a language is as much about having fun and getting excited as it is about actually improving my skills. I'm not new to programming so I am able to quickly learn new concepts when I'm introduced to them. But often I find that I'm going too fast or that I'm - unintentionally - skipping over fundamental concepts that are slowing down my progress.

I believe it is our job as ShowMeDo authors to make sure our viewers are first exposed to easily digestable, fun, exciting and appropriate material before advancing to books and other online resources. We should first provided them with the basics and then point them to other resources - like Ian did in his excellent videos on Python resources for beginning developers.

By focussing very hard on the basics of a language - and nothing else - I'm convinced that we will find it easy to create highly-appreciated content. And at the same time we'll feel highly appreciated ourselves :-) Which will motivate us to record more videos and will make Ian and Kyran more than happy.

Outline

As a general rule of thumb I suggest to use any means, ways of working and tricks to help us focus on the language and nothing else. Ideally we'll find a balance between learning the language and learning to use the tools that make the learning process more comfortable. In my opinion we should always talk for 85 to 90% of the time about the language and for the rest of the time about the tools.

I'll give an example: if I would create a series on Java I would not use Eclipse, nor NetBeans but BlueJ. This is a development environment specifically designed to teach Java to developers. Once they understand the Java and OO basics they can still learn to use any IDE they like and we can also help them with that.

In my Perl videos I'm planning to use vi as an editor. It's easy to use and does an excellent job at what it's supposed to do: easily navigate source files and otherwise not sit in the way of the learning process. And once the viewers know what they need to know about Perl they can still choose to keep using vi or switch to Emacs or any other editor.

Another important way of focussing on the language is to stay clear of all kinds of gizmos that intermediate and advanced developers have to know about, but not beginners. I again take Java as an example. When I bought the very first Java book that ever was published - it ofcourse had the Duke on the cover - it dealt with almost all features of Java 1.0 and did a lousy job at actually teaching the language. They reason in my opinion is lack of focus.

Instead I propose to stick to these topics and concepts (in the order as listed):

1. the very first thing to talk about is setting up the environment for writing and executing code.
2. printing something to the screen
3. variables and the simplest types (no stories about memory footprints here please)
4. simple calculations
5. the conditional statement (if and else)
6. arrays if they exist, otherwise lists
7. looping statements (not necessarily all of them)
8. lists if not yet covered or tuples
9. methods without arguments
10. methods without arguments that return something
11. methods with arguments (if possible without having to cover pointers)
12. in strict OO languages like Java: classes and objects
13. reusing classes, modules or libraries.
14. exceptions

I understand that this order cannot be easily applied to every language and that it doesn't apply at all to some language (for example assembler). To me however it seems like a reasonable approach that's totally open for discussion.

The goal of this approach is to get new developers started. It should allow them to write basic applications. Ofcourse we shouldn't stop with these 14 points since there are many other topics to learn about:

• capturing input from the console
• reading from and writing to files
• creating your own modules, libraries or packages.
• pointers!
• regular expressions!
• the switch statement?

And so forth. It's clear to me however that there's little interesting in teaching these things if developers don't understand the very basics of the language they're learning.

Style guidelines

How to set up your environment for max. benefit

Find your own style

It's important to be yourself and to have fun.

Content

Which topics to cover and how to organize yourself for the task.

Video settings

Make sure that everything's readable.

Feedback requested