The C# class was what I expected. I got out of it what I wanted - a week of uninterrupted focus on the language where I could learn where C# differed from java (more later on that) and the background habits, practices and conventions of C# programmers and enough examples and practice Labs that I could begin to absorb all of that in a way that will stick if I use it for a while.  

If there is a negative, it's that my classmates were relatively new to programming or at least high level OO programming, so they were there to learn programming where I was there to learn a language.  This of course forced the instructor to focus more on what I would consider elementary material than the details which were of deeper interest to me.  In a way that may have been a good thing: MS terminology is often more distinctive and specific about particular terms than their general use in discussions about programming. The focus on elementary constructs may have helped set those distinctions in my mind. I'm satisfied - I'm confident that my grounding is now sufficient that I can find the answer to deeper questions from other sources.  Kudos to my instructor, Darsham Mehta, who obviously knew the material and language very well, as well as programming in general, and was an enthusiastic teacher and patient with my sometimes arcane questions.

Should anyone else be interested in C# who already has a grounding in programming, my teacher recommended the book "Professional C# 2005".  I've barely started through it but it's 1500 pages of dense material and looks very much like the perfect rounding out of what I need.

C# and Visual Studio

C# is very, very similar to java.  So much so that when it first came out, there were claims that one could translate between java and C# with a Perl program.   Now having a little deeper look at C# I don't believe that true for any but the simplest cases. Java (at least earlier java) to C# yes, but not the other way.   Remember java was there first and fairly mature; MS's engineers had the advantage of seeing what was missing in it, adding what might be useful, and deciding what may have been mistakes and correcting them.  Of course they copied some of the mistakes too...

There are innumerable comparisons between java and C# already out there on the web (just google "java C# comparison"), so I'm not going to give a complete rundown of them, only those which struck me as most significant.  It should be noted that there are a number of innovations in java 1.5 and 1.6 and many of those comparisons do not account for.   For example, enums and varargs are now supported in java where C# evidently had them from the beginning.  And generics are (relatively) new to both java and C#. I'd add that learning C# has made me look much harder at the new features in java than in the past; in some cases (the enhanced "for", for example) I didn't know they were there - so learning C# is going to make me a better java programmer.

One of the early and I suspect more problematic differences is that C# allows passing of primitive types by reference.   This means that you can change a primitive value in the called method and its value will be changed in the calling method.   Now any experience programmer can see the danger in that - one expects local primitives to stay local. But the danger is somewhat ameliorated by the requisite of using the "ref" (or "out") keyword in invocation.  In other words doing this is required to be quite explicit.  Similarly the "out" keyword indicates a pass by reference but the compiler will not then allow the called program to access data from that parameter, only to write to it's value.   But object references too can be passed by reference, and it is quite possible that the called method can change the instance object referred to by the caller.  There are grave dangers here ... but also interesting possibilities.  Only by time and practice will I decide whether one outweighs the other.

I suspect that the driving force behind the above was the inclusion of a "struct" in C#.  Struct's are simply data structures, or from the other direction, classes with no methods.   But they also differ from classes in that they can be implemented locally, on the stack, by declaring a struct without a "new" keyword.  The pass by reference allows "functions" to manipulate these without otherwise encapsulating them.  This is a performance enhancement, and potentially valuable but (as with many of my complaints) ugly from an object oriented standpoint.

C# uses namespaces rather than packages.  Most of what this means is that the name of the file and directory structure in which the source code resides does not necessarily have any connection to the class(es) it contains.  This has both positive and negative aspects.  Negative in that the enforced structure in java always tells you where the corresponding class can be found while developing before you've created your jar.  Positive because as the programmer/packager you now have more freedom to build and use the directory structures as you wish.   And one also means one can define many classes in a single file.  Likewise C# supports "partial" classes allowing a class to be defined over several files.  Having written some classes with a large number of methods, the ability to group these methods into separate files separately relating to different aspects of the objects' behaviors could be a big plus.  Of course the purist (maybe me, sometimes) would say that probably means the class should be refactored and broken into smaller classes.

But there is a more practical motivation for classes spread across several files as well.  As part of my (self imposed) learning experience I've started writing my own variant of Conway's Life, and thus using Visual Studio.  Now Visual Studio's form designer produces its code in one file for initialization, but the event handlers you do have to write code for go into another file .  You don't want to change the source in the file (or at least that section of it) created and marked by forms designer - it will be overwritten if you change the form!  But abstracted this makes even more sense.  If you have tools that generate code, by allowing the class to be composed of separate files agglomerated later, you can have those portions generated by tools be separate objects to the file system from those which the developer must maintain manually.  I can easily imagine several possibilities where the specifications for something could be stored in an XML file (or database, among other possibilities) which subsequently drives generation of new code.  The developer would then never touch the code generated by the XML processing tool, but could still change as needed those other portions of the class which needed to be manually maintained without any risk of corrupting the generated code (or having the manual code corrupted or removed by the tool).

Let's take a trivial example.  You have a lot of customers and your sales force is way out of control in negotiating billing options but your customer management system only has a single numeric for billing code.  No problem.  You write an XML:

<?xml verson='1.0' encoding='ISO-8859-1' ?>
<billingOptions>
  <option id='1' cycle='monthly' net='30' discount='0' >
  <option id='2' cycle='weekly'  net='30' discount='0' />
  <option id='3' cycle='monthly' net='60' discount='3' />
  ...
</billingOptions>

Now all your code generation tool (which in this case could be a simple xsl piped to a file) does is take this xml and generate a method which contains a case statment which calls a method the same name as the cycle attribute with the net and discount parameters.  Well that's trivial enough ... you don't need tools for that... except that in real life there could be a hundred or more different codes and it could be many different codes mapping to complex behaviors to be mapped to different methods with different meanings and lots of different case statements.  But the XML is self documenting where lots of complex case statements are touchy to read and understand at best.  And then along comes salesman Joe who really can land a large account with group of rich California Wiccans at a very high profit margin except that they insist on being billed on the full moon with a two lunar net.  Still no problem.  You add:

<option id='666' cycle='lunar' net='"2lunar"' discount='0' />

 ... to the xml and write the code for method lunar(string net, int discount){ ...} in the manually maintained portion, run the XML tool, compile and you're done.

I really like the idea of partial classes.  There are workarounds and other ways of doing it that I've used for java.  I've written Perl scripts which sometimes write complete class files then referenced as static or as a singleton and others which look for a / ==BEGIN= to find where to insert code into a source file.   But the partial class is far the more elegant solution.

Another difference between java and C# is that in java you need to declare the exceptions which can be thrown in the method declaration.  C# doesn't.   I recognize and understand the motivation for removing this - I've written many a method with a boilerplate "throws Exception" but on the other hand I've often had the compiler tell me that the class I've written might throw an exception I hadn't anticipated but needed to do something about enough to be wary.  It basically means the programmer needs to give a little more thought to how exceptions can "boil up" than otherwise.

One of the features I really like about C#, borrowed from Visual Basic, is the "property".   These are commonly used as accessors as in getters and setters but aren't required to be; they can invoke more sophisticated processing.  It essentially means that assignment to or from a named element triggers the processing, similar to a tie in Perl.  Of course in java you can always write more complex code in your getXXXX and setXXX methods as well, but I've always been bothered by the java tool sets' dependency upon a convention which isn't part of the language.

Another useful feature is syntactic encapsulation of handling delegates.  We didn't get to this in class - not enough time.  I found out about it studying the code that forms designer created then looking at help and finally the Pro C# 2005 book.  In java you deal with delegates by writing an interface specifying the methods which must be there, implementing those methods in the classes and adding the objects instantiated to a list of delegate objects to do the appropriate processing then calling the prescribed method on those objects when the delegated process is required (most commonly, an asynchronous event).   All very straightforward and logical but somewhat tedious to do in practice (of course the graphics, xml parser and similar libraries already have the interfaces, event registrar and actual delegation methods, and usually some base classes with null handlers already defined, but if you're writing something new you have to do it all yourself).  C# has syntax to handle delegate assignment trivially, and adding or removing listeners by += and -= syntactic expressions.  Additionally there is no requirement to use the same method name for different objects which may wind up being listeners; their parameter lists must match, obviously, but the method names can reflect their local behavior rather than their relation to the delegating behavior.

I said above that C# had copied some of java's mistakes.  Both java and C# purport to be "object oriented".  But this is not strictly true.  In both cases static ("class") variables and methods are "early bound", meaning bound to the scope in which they are referenced rather than the object being referenced.  So if you have class A with static variable x set to "a" and class B which subclasses A but which also has an independent static variable of x, set to "b", then in executable code you have a declaration of an A which in the instance contains a B, the dereference of x will give an "a" rather than a "b" even though the object is supposed to be a B.   I've actually written code that broke because of this before I understood what was going on.  And I keep writing code where the object based behavior rather than the lexically (or more precisely "scope") or "early" bound behavior would be more useful ... I wind up having to write a (-an instance) method and invoking that rather than simply referencing the variable.  This is also true of static methods, but I haven't yet come across a case where that in particular would break expectations.

Now C# goes a little farther in this breakage than java - in java instance methods are always "late bound", i. e. the method invoked will always reflect the object instance.   In C# a method by default will be lexically ("early") bound, that is the actual method invoked will be the one associated with the local reference class rather than the referenced object's class.  BUT C# gives you the option on how to handle it.  You can add the "virtual" keyword to the method declaration in the base class, and "override" on the method in subclasses, to specify that a method invocation should follow the object.  And there are ways to change and limit how the "chain" of subclasses are followed when a method is invoked (the "new" keyword on the method declaration).  What this means to a java programmer is that you almost always want to use virtual and override in defining methods which might be overridden.  Otherwise it means that C# is more flexible but potentially quite vexing in deciding on what and how a level of subclassed method should be invoked from a referenced object.

This understanding all by itself more than justified the cost of the C# class.   Without the labs that drove this home, the lack of understanding this difference from java would have left me puzzled and it might well have been a long time with storied misadventures in coding and debugging before I understood it.

One of the more visible but more trivial differences are style conventions.  It seems that MS has written a large style guide.  Methods should be pascal cased.  Instance variables should begin with an underscore, and many others.  In my younger, more arrogant, days I used to be contemptuous of style recommendations, rather feeling fit to roll my own as I went along.  Now, with too many years and too many languages behind me I find that conformity has a real value.  Not only does it make your code more readable to others, if you follow the language conventions yourself you will better and more quickly read and understand code that others have written following those conventions.   Besides which, the IDE's and tools often force compliance with at least the larger elements of the language conventions and contrariness is an uphill and almost always losing battle.

There are numerous other features in C# that differ from java.  Some are trivial, as "sealed" means essentially the same thing as "final" in a class declaration.  Others are more significant, vis the "using" block to force immediate deallocation of resources in a class which implements IDisposable.   Not only do I not have the time and inclination to delineate them all, but at my present stage I'm probably ignorant of many as well.

It is possible to write C# with a text editor and use the command line "csc" command to compile and build executables and libraries (dll's), but the standard and natural way to write C# is with Visual Studio.   I would generally say that unless you're into masochism in a big way you must use Visual Studio.

At one time Visual Studio was "hot stuff", considered one of, if not the best programming environments available.  It wasn't the first of course - I remember having tools on green screens connected to the mainframe to write CICS screen definitions.  But now being used to Eclipse (3.2 at home) I'm less than impressed with it.  Of course I'm new to VS as well and certainly don't know all the tricks available to use all its features, but it seems considerably less able than Eclipse in a lot of areas.  There are more options in code refactoring in Eclipse.  Your ability to specify code generation options is much greater in eclipse.  You seem in VS to be limited to working on one "project" at a time.  Hey, where are the emacs key bindings?!!

Now Eclipse had humble beginnings and evidently my teacher only ever saw a much older version of it.  He was continually surprised when he would proclaim some feature of VS as wonderful and I would "ho hum" it. He seemed to think that the ability to find the definition of a reference in a project and globally change it's name was significant. Quite frankly VS is now a toy, at least not counting what I don't know of its capabilities (admittedly MS, in many instances, has a perverse way of hiding some very powerful features in ways that make them difficult to find, or even guess that they exist), compared to Eclipse.

But of course, C# and any other language, for any thing complex enough to be interesting and useful it is not so simple as write a file, compile and go.  There are complexities in putting together "assemblies" - collections of compiled objects with mutually bound references - into an executable and or library which will take me a long time to learn.   VS, naturally, does all this without getting in the way.  Ergo, it makes it possible to work on large projects without and before having to learn those complexities.

The most beloved feature (at least for the Visual Basic crowd who are its keenest admirers) of VS is the forms designer.  Here I have to admit that  in the brief time I've been using it is something worthwhile that Eclipse (by itself, anyway) doesn't have.  Now for C# forms designer really only generates C# code that gets compiled into your project just like any other source code file.  You can forego forms designer and write all the form object initialization yourself if you are inclined to tedium.   But from where I sit not only does form designer remove a lot of that drudgery, but as a neophyte to the language and platform the code that it generates is very useful in gaining an understanding of C# and the .NET environment.

Conclusion

So, in the end, do I like C# so far?  Yep.  And I'll be happy to use and play with this toy.  It will be an interesting ride.  Will I use C# in preference to java in my casual play programming?  Nope.  Despite the interesting and in some cases superior features, it is still far too tightly bound to the Microsoft platform.  When I want a tool of general use, I'll use java.  But C# is powerful enough, clean enough, and interesting enough to use without qualm and with considerable pleasure when professionally required.