I don't think C# is an ideal first language, to be honest -
particularly not C# 2 and 3. I've heard good things about Squeak, a
Smalltalk variant often used for education.

Bob,

The learning curve for basic .NET 2.0 is not that hard. Even if your son
has little to none experience in coding he should be able to create
console / form applications in no time. When using form applications he
immidiately sees what he has created so its a good motivation to
continue. When he has basic knowledge of C# it might be wise to show him
some sql before letting him work with linq. the step will be small from
there as the basics of linq aren't to difficult to understand with some
sql knowledge.

Finally WPF: I can't say I've tested a lot of WPF features but what i've
seen indeed has great potential. The only problem is that the components
have different attributes and methods then the normal c# components so
that development was not as easy as I hoped. Also, when deploying wpf
over the internet as an xbap application all king of security issues
come up.

Hope this information could be of any help

Edwin

I agree with Jon that C# is probably not a good choice for a first  
computer language.

Frankly, I think that someone first getting into programming, especially  
at a young age, should probably not even start out with an OOP language.  
For all its flaws as compared to other high-level languages in common use  
in the industry, BASIC still remains IMHO a very good introduction to the  
basic ideas of data storage, flow control, and i/o.  There's a reason the  
word "beginner" is in the name.  :)

And I'm not talking about an OOP variation of BASIC like VB or VB.NET  
either.  Just plain old BASIC.  Though, properly managed I think one could  
use a VB-based environment to introduce someone to programming.  You'd  
just need to be careful to provide all of the non-BASIC goop for that  
person.

Another good starting language is Logo.  Granted, it's a little more  
object-oriented and even a bit functional in nature, but IMHO it's still  
at its heart a straight-forward procedural language.  It's also inherently  
graphical, which can make it a bit more fun to play with than BASIC  
(though frankly, when I was a child learning BASIC, it never once occurred  
to me that I might not be having fun even when the only output I could do  
was text).

I also think that Lisp can be a good starting language.  It's actually a  
relatively powerful language IMHO, but it's fairly simple to describe at  
its most basic.  Of course, the downside is that learning Lisp doesn't  
really give you much of an introduction with respect to the procedural  
environments that are the bread-and-butter of the software industry.  But  
at least it helps a person start thinking in a more structured,  
computer-friendly way (which IMHO is an essential part of being a  
programmer).

Basically, I don't think that C#, or any .NET environment for that matter,  
is a very good way to introduce someone to programming.  Even without the  
changes in C# 2.0 and 3.0, it's a fairly complicated, abstract environment  
and much better suited to someone that already has some good programming  
fundamentals under their belt.

Pete

I don't think C# is a good first programming language.

The 'purer' functional languages are a much better bet. ML, Haskell, and
(if you want a .NET language) F# are much better languages to learn first.

Alun Harford

C# is not that bad a language to start with.

Just start with a reasonable level of ambition.

Do not jump to LINQ in week 2.

Of course there are other languages as well.

20 years ago Pascal was generally considered *the* language
for learning programming.

It is not in favor today, but it is still a good learning
language. Not too complex and you will learn good practices.

Arne

I just would add that my kids, started with "Scratch", a language from MIT.  
It teaches some of the basic principles before moving on to a more
traditional language.  I liken it to the old "Logo" language.  Now the older
one is dabbling in C#.

http://scratch.mit.edu/

You may be experiencing some of your concern as a result of not seeing the
long historical view of the development of programming languages, and the C
family in particular. Programming languages have been evolving ever since
the first Assembler code was created in order to facilitate the generation
of machine code, which is ultimately what all code becomes. Your son should
learn something about the foundations of programming languages before he
dives into code. The point here is that programming evolves in nature, and
programming languages evolve, but ultimately they all do the same things
they did originally. Sequence, Selection, and Iteration underly all
processes. All data is "simply" bits.

As for the C family, which I am particularly fond of (I started out with C,
and have never regretted the decision), C was a fairly early entry into the
high-level (read "above Assembler") language pool, with syntax resembling
Pascal, which another poster mentioned. C was created to be concise and
powerful, and to resemble the actual mathematical processes that it
abstracted. For this reason, learning C can be very useful in terms of
understanding what programming is, and what it does, including how the
processor works, and the mathematical nature of all computer operations.

Each successive "version" of C, starting with C++, has been what might be
characterized as an "extension" of the C language, which was intentionally
designed to be extensible. C++ was literally such an extension originally,
the first object-oriented C language, which abstracted the programming model
further with object-oriented principles and additional syntax to accomodate
these new abstractions. The "++" (iterator) in the name exemplifies this. C#
took the abstraction further, and incorporated much friendlier syntax, in
terms of these abstractions (Hence, the overlapping iterator symbols in the
name). While a C++ program still looks a lot like the procedural C code that
it is based upon, C# class-related code looks more like the abstractions
which it represents. The syntax is less cryptic, but still strongly
resembles C in most ways, and in fact, can accomodate in-line C code blocks.

Some of C# was developed to accomodate and interact with the .Net platform
on which it operates, which includes automatic memory management (garbage
collection) and object-oriented value types, something which C++ could not
accomplish.

With each successive version of C#, more extensions have been added, such as
Generics and Linq. These have been added for the same purposes, to simplify
and streamline the coding process. But it is important to note that they are
not necessary for writing software. They simply encapsulate functionality
which formerly took more code to create. Therefore, it is not necessary to
be able to work with all of these extensions to learn C#.

In other words, what I'm saying is that learning programming is a lot like
the process of writing software. It is best handled one chunk at a time. So,
you needn't worry about your son having to learn all of it (in fact, it is
not possible, as it continues and will continue to evolve). Like anything
else, if he starts with the basics, he can work his way up at his own pace.
I'm not suggesting that you start him off with C, but he can easily learn
the base C# language as you have, starting with the simplest concepts, and
working his way up from there. The archetypical "Hello World" application
remains the best starting place, as it involves the simplest sort of
programming, and it is important not to overwhelm the beginner, lest he/she
lose heart.

Bob.. My first Z80 assembly project moved a fish around the screen on an
8K
Exidy Sorcerer. My second assembly project printed text sideways since
all I had
was a narrow thermal printer.

IMHO this type of positive feedback is really useful to a beginner, no
matter what
the language. So I would consider practical scripting use a script
language as a
first step, where the coder can see practical and useful results.

Regards,
Jeff

Depends on what your ambitions for your son are. If you want him to be
a wise, all-knowing programmer, then you're getting ahead of yourself.
There is no better way to start programming than with a simple "Hello,
World". How you show him how to do it is the interesting part.

Now, personally, I prefer to teach programming starting from the
command console application. I let more complicated topics like forms
come in later, since they tend to limit you to one platform and they
hide a lot of details. For simple console applications, C# is hard to
beat. If he gets to the point where he needs collections, start him
out with something simple like Array or ArrayList.  When he gets tired
of casting all the time, introduce generics.

Of my students, most of them pick up generics first by memorizing the
syntax and then only later grasping the "fill in the blank" concept.

Again, personally, SQL is in itself a whole new programming language.
It is an advanced topic for a starter. It is probably one of the most-
used programming tools, as well. But, again, start with something
simple, like flat files, and when he gets tired of parsing all the
time, introduce 'a' database management system and portable SQL. When
he gets tired of writing SQL in-line with the code, teach him stored
procedures, and so on. There are so many branches in computer science
that you can either become a master at one topic or you can fan
yourself out over multiple topics. I fan myself out fairly well and it
comes in handy for making good design decisions. I also don't like the
feeling of being "done" with a branch because I like to keep striving
to find newer and better ways.

I believe that becoming a good programmer involves being interested in
what you are doing. If you hit topic after topic, spilling your brains
out, you're just going to frustrate the kid. I have tutored/tortured
enough people to know when too much is too much. For some people,
getting the idea of 'Hello, World' is enough. For people with an
interest, it seems to grow naturally without any help. I tend to get
my students accustom to showing me everything they do. When they think
they did some thing cool, I pat them on the back and say, "You know
what would make this really cool?" or "Check this out!". A lot of
times, just bringing up phrases like: design pattern, SQL, HTML, Web
Service, XML, <language name>, <operating system>, <field of research>
lets them know there are things out there for doing what interests
them.

The way I see it, everyone at some point thinks MessageBox.Show is the
sweetest thing ever. When we get tired of clicking 'OK', we want to
try newer, harder things. My personal favorite thing to do anymore is
just to write a cool application and spend the rest of my time
improving it. Anyone can make something work; it takes talent to make
it work well; it takes even more talent to make the code approachable.

And remember, you're not the best programmer in the world. Don't
always correct his code by putting curly braces in the right place. He
may develop his own style and defensive programming techniques that
work better for him (and better than yours do for you). What is
instructive, though, is to show flaws in logic by doing something to
break his code. Say, "Oops"; it builds a competitiveness in the
student to make their code unbreakable. When coders become defensive,
they tend write better code the first time around . . . the proverbial
"well, what if . . .".

Most of all, make learning programming fun. Don't go about
"assignments" with anal requirements. Make applications straight-
forward - something to "just get it done". One thing that always
killed programming juices were assignments that asked students to
parse lines, or something that could be done in an easier fashion. If
your assignment is to parse lines, then make that the assignment. If
it is to calculate an average, make parsing simple. Beginning
programmers have trouble with assignments with multiple requirements
because each requirement is a battle - which each can take a whole
week - they don't need another one hanging over their heads to bog
them down.

Here is a pretty generic agenda for programming students:

1) Hello, World - Simply learn the syntax and basic operation of the
environment/language.
2) Hello, <Input> - Get user input and display it on the screen.
2.1) Introduce IF - Introduce conditional branching and have them
output different results depending on input.
2.2) Introduce While, etc. - Introduce looping to perform an action
multiple times.
3) Count - Count the number of lines in a file or from the command
line.
4) Average - Calculate the average from numbers passed in.
5) Min/Max - Find the minimum/maximum in a list (can be done while
receiving input).
6) Array - Store the input in a array and then print it out.
7) Cumulative - Redo the previous exercises with the array now.
8) Sort - sort the input using bubble, insertion, and/or selection
sort (a mix between min, swap and iteration).
8.5) Introduce methods/functions - Place separate code into functions/
methods; e.g. Count, Sum, Average, Max, Min, Sort.
9) Multiple Arrays - Have input where the first item is a key and the
other items are values. Store the items in separate arrays. Keep
association between key and values by index while performing sorts,
averages, etc.
10) Introduce Structures/Classes - Instead of storing information in
in arrays and associating by index, create a class to contain all
values. Repeat program above.
11) Introduce methods - Put calculations on objects into methods
inside the object class.
12) Introduce accessibility/visibility - Hide fields, such as sum/
average, in private fields. Use properties to make visible or use
properties to calculate.
13) Introduce inheritance - Create a super class. Explain keywords
like virtual and sealed.
14) Introduce interfaces - Create interface for both classes.
15) Introduce abstract class - Create abstract base class for both
classes. (Good time to teach "Concrete classes only as leaves")
16) Polymorphism - Stick both classes in an Array or ArrayList and
extract as interface. Call method through interface.
17) Accessibility Part 2 - Explain protected and internal.
18) Introduce Generics - Make ArrayList above List<T>.
19) Data Structures - implement as easily as possible.
19.1) Array<T> - indexer, fixed-size
19.2) List<T> - add, remove, find (insert is advanced)
19.3) LinkedList<T> - insert on front/back/middle, remove, find
(splice is advanced)
19.4) BinarySearchTree<T> - add, find (remove can be advanced)
19.5) Graph - shortest path, etc.
20) Forms - basics about forms.
21) XML - basics about.
22) Database - basics about SQL.
23) Source control - basics about source control.
24) Other technologies - other languages, systems programming,
serialization, operating systems, algorithms, design patterns, etc.
25) Software Engineering/Architecture - explain requirements
gathering, design, flow model, testing, etc.
26) Independent study - where you go, "You know what would make that
even better?"

That is a fairly flexible path for someone to follow if they want to
get the basics down first. Usually, students tend to pick things up as
they go along. The further down the list they get, the longer it
takes. Most of my students never get past data structures and get hung
up somewhere between polymorphism and generics. Those who are
interested seem to get to binary search trees, or beyond, before they
start to struggle. A good thing to do is have a reference manual when
teaching a new language. Wrox makes a fairly decent Professional C#
book. It is a great supplement and gives students a chance to learn
about features not covered in their lessons. I often reward students
who find a .NET class to do their programs for them (I just make them
do it over and give them bonus points).

I am not saying C# is the ultimate language for teaching. Mostly
likely, any language you choose will have you hitting these topics.
However, VS makes programming fairly easy and lightens memory load
(Intellisense and what not).

Hope it helps,
Travis

P.S. - I would like to say I do not agree with programming courses and
books that teach classes straight forward. Many courses now teach
classes first because of the requirement that all code be contained in
classes in languages like Java and C#. However, when learning C/C++,
you weren't required to know functions to work with "int main()".
Students have trouble grasping Integers ("why can't they have decimal
points and be as big as you want?") and putting a class in the mix can
be even more confusing. Personally, I believe classes should be first
thought of as syntactic candy and then later revealed. I mean, no
language would expect a start-up programmer, let alone a professional,
to understand console I/O. Let's try to keep it simple, stupid! That's
my guff.