+ 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@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/
-------------------------------------------------------------------------------
This text is work in progress, comments are most welcome. Redistribution for
non-commercial use is fine, as long as I know of it and this footnote is
included. Copyright Sonja Krause-Harder, 2002.
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@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/
-------------------------------------------------------------------------------
This text is work in progress, comments are most welcome. Redistribution for
non-commercial use is fine, as long as I know of it and this footnote is
included. Copyright Sonja Krause-Harder, 2002.