I've been writing in C# for about 4 years now, coming from VB.net and
VB6 before that, in which I know I'm not alone. I found learning C#,
at least to the extent that I use it in developing database front-
ends, to be rather painless. The language and VS ide seemed
comfortable pretty quickly.
Some of the enhancements that have come along in the last two updates
(via VS 2005 and 2008) like Generics and now Linq and anonymous types
etc, are really nice, but seem to have made the learning curve a bit
steeper. I'd like to see my son learn coding, but where I used to tell
him he could get off the ground in a few months, that now seems more
like two or three years. After all, how would you use Linq to Sql if
you didn't understand T-Sql yet? And WPF seems like it has great
potential, but that's another layer again.
Anybody have thoughts they care to share on this?
Bob
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.
