[Courses] [Basics] Lesson #0

[Samantha Blackmon]

On Sunday 17 March 2002 06:52 pm, a magikal owl from Sonja Krause-Harder 
delivered this message:
> + About this course
>
> When I taught myself programming, I found the material available (both
> online and printed, both free and non-free) lacking in certain respects
> I can only name and describe now, after I finally found things out by
> myself, by chance, or by accidentally stumbling over them hidden in
> various texts.
>
> On the net, you will find introductory texts to teach you the basics
> of many computer languages (in varying degrees of abundance. There's
> a lot more material on Perl than on Assembler). It is harder to find
> texts to teach you what you need to know to understand those tutorials,
> and where to get from there.
>
> In this class (or series of articles), I want to show you three things:
>
> 	* The concepts that are roughly the same in most programming
> 	  languages in use today (and inherent to the way programming is
> 	  done today).
>
> 	* The nifty magic details everyone involved in programming seems
> 	  to know, but nobody cares to write down (I probably forget many
> 	  of them, as I _do_ know them now, so please ask if you think I
> 	  assume you to know things you don't).
>
> 	* A broad overview of what belongs to the process of programming
> 	  in the mental space.
>
> + What you will need
>
> 1. A computer
>
> I will assume that you have access to a computer and a good working
> knowledge of the operation system running on it. The lesson texts will
> assume Linux, other unixoid systems are dealt with on request and on the
> list.
>
> Whenever I say "I assume you know something", I really mean "I will not
> explain this in the lessons, please ask if you need help". This is not an
> introductory class in Linux usage and administration, so any questions
> that arise belong on the list and on #linuxchix. We will sort them out
> together. In particular, this does _not_ mean that you can't learn
> how to program if my assumptions and your reality differ.
>
> "Working knowledge" includes knowing how to install software packages on
> your system. You will not need anything exotic for following the class, so
> knowing how to install packages from your distribution's CDs with the tools
> provided with your distribution should be sufficient. If your distribution
> disagrees with my notion of "not exotic", please tell me and ask for help.
> If you can't use the distributor-provided tools for whatever reason (e.g.
> not having root access on the machine), please speak up as well.
>
> 2. Time
>
> This is not "Teach yourself XY in 21 days". Those books have their use
> for people who already know programming and need to learn a certain
> language for their job, or their resume, or just for fun. Once you've
> grasped the concepts, you may find that "uploading" another language
> into your active knowledge may take even less time. The concepts
> themselves, however, take some time to settle down.
>
> If the lessons go to slow for you and you feel bored, feel free to
> explore on your own. I will try to provide you with links to
> "further reading", and I hope that you will find these lessons
> interesting even if you are "ahead of class". Also, do ask any
> questions you have, not only those referring to the lessons
> posted so far.
>
> If the lessons proceed to quickly for you to follow, take your time.
> I actually expect people to drop in later, or to drop out for a
> while and come back later. That's why the lessons are available on
> the web. If you happen to know the answer to any question a beginner
> (i.e. someone who started later than you) has, please do not wait for
> me to provide the solution, but help each other. This is how LinuxChix
> (and many other mailing lists) work, after all.
>
> The lessons will have exercises at the end. Do them. I don't know
> how much time you need for that. If it's too much, don't do them
> all. You will not learn programming from reading, though, so
> some time spent with actually typing code is absolutely necessary.
> If you find yourself really enjoying the act of programming, however
> simple it may seem, you're on your way. And if something else you
> want to program is more fun than my exercises, then, please -
> do something else.
>
> 3. Some software
>
> The act of programming consists of breaking down problems (and formalized
> procedures to solve them) into pieces small enough to express in special
> languages that are "understood" by both humans and computers. On the human
> side, this is finally done by creating ascii text files and typing code
> into them, and this is most conveniently done by using a text editor.
>
> vi in all its flavours is fine (classic vi, vim, elvis, nvi). I've never
> used emacs, but many programmers swear on it. Other console-based editors
> I know of, but haven't used, are pico, joe and jed. GUI-based editors are
> KEdit and GEdit, one for each major desktop, and there are many more I
> do not know. Pick one, but keep in mind that you need a tool to edit and
> produce pure ASCII text, so a word processor won't do.
>
> On the computer side, you need some program to put your code into action.
> I will use Tcl as your first language to learn, so this role will be taken
> by the Tcl interpreter, a program called tclsh.
>
> + Hands on: getting the tools
>
> If you are in a GUI environment like KDE or GNOME, open a terminal. If you
> are on the console, open a new virtual console. Type
>
> 	$ which tclsh
>
> at the prompt. (Without the "$", this is meant to be your shell prompt.)
>
> If tcl is installed on your system, the 'which' command will answer with
> its location. On my system, this is:
>
> 	/usr/bin/tclsh
>
> If you don't see any output from 'which', the Tcl interpreter is probably
> not installed on your system. If your system uses rpm for package
> management, type
>
> 	$ rpm -q tcl
>
> rpm should answer with either the full package name (tcl-8.3.3-44 on my
> system) or a statement that 'package tcl is not installed'. (If you are
> using Debian and don't know how package management is done there, please
> ask.) If needed, use your distribution's method to get and install the tcl
> package. If you don't know how, please ask on the list.
>
> When you've successfully installed tcl, type
>
> 	$ which tclsh
>
> again. Most likely, the output will be
>
> 	/usr/bin/tclsh
>
> or
>
> 	/usr/local/bin/tclsh
>
> or, of course, something else. Write that down somewhere, you'll need it
> soon.
>
> Now, open your favourite text editor and create a file called "test" with
> the following content:
>
> 	#!/usr/bin/tclsh
> 	puts "Hello, world!\n"
>
> The first line points to the tclsh executable you just located with the
> command 'which', so you have to change that line to whatever 'which' told
> you.  Save the file and close it. Now open a shell again, navigate to the
> directory where you saved the file to, and type
>
> 	$ chmod a+x test
>
> to tell the operating system that this file is now an executable. Now type
>
> 	$ ./test
>
> (the dot and the slash are important here). If you see the line:
>
> 	Hello, World!
>
> in your terminal window now, and your shell prompt below, you have a
> working tcl installation on you system, and everything you need for the
> first lot of lessons. If anything went wrong on the way, please ask on the
> list.
>
> ===+ Exercises
>
> (As this is lesson #0, these are not "real" programming exercises yet ;-))
>
> 1. Choose an editor and explore its features. If there is a tutorial (at
>    least vim and emacs have one), take it. You might find a feature called
>    "syntax colouring" very helpful very soon. Try to find out if your
>    editor supports this and how to activate it.
>
> 2. Subscribe to the list (courses at linuxchix.org), if not yet done, and
>    introduce yourself
>
> ===+ Further exploration
>
> 1. If you are curious about tcl, the language I will use for this class,
>    go to: http://dev.scriptics.com/

Is there a website for the basics course? Its been kinda quiet since Lesson 
#0 and I want to make sure that I am not missing anything

Samantha (aka Teknogrrl)