• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Learning C#

Alareth

Philosopher
Joined
Aug 30, 2006
Messages
7,682
Location
Jacksonville, FL
For various reasons it's time I actually learned how to program but I'm not sure where to begin. I've not written a line of code other than HTML since Commodore BASIC on a C64.

For the project I'm going to be helping my stepson with I need to find tutorials and primers for C# Sharp.

Can anyone help point me in the right direction?
 
I'm a big fan of this book. But I made the jump from C++. That's a very different challenge than learning programming essentially from scratch.

Google "C# online tutorial" and there are tons of hits.

Once you get the basics down, challenge yourself with programming problems at http://projecteuler.net
 
Last edited:
I've been using C# for years and years, its a good first language to learn, and has lots of nice things for advanced users.

Resources:

Head First C#, 2nd Edition. Highly recommended, was published in 2010 and is up-to-date with C# 4.0. Good for first-time programmers. Make sure you get the latest version, which corrects errors and typos from earlier version.

C# In Depth. Intended for intermediate-to-advanced users, covers a lot of the nuts and bolts of .NET, and how it influenced the design of C#.

Development environment:

Visual Studio Express (Windows). Highly recommended.

Monodevelop (Linux, Windows). Preferred on Linux environments.

emacs or vim (Linux, Windows). "Expert friendly." Learning curve and configuration is prohibitively annoying for first-time programmers, but once you get through that, makes a good general-purpose editing environment.

For getting help:

Stackoverflow, well-known programming Q&A site. Be aware that SO has a "help those who help themselves" culture. You can expect fast, correct answers to good questions, but don't expect hand-holding. Example question: how to compute a sha512 hash in C#.

Programmers.SE, for more general, open-ended questions about programming. Example question: book recommendations for C#.

Beyond C#:

F# Wikibook. Assumes no prior programming experience, lots of code snippets to learn functional programming style. F# compliments C# very nicely. Functional programming makes you a more rounded, general purpose programmer.
 
Last edited:
The resources in this thread are great already. I was going to suggest the book I read many years ago "Programming C# by Jesse Liberty" as a beginner book but I was not a beginner so I don't know how it would work.

For advanced .NET though and if you want to find out how it ticks then the book "CLR via C#" is the best book out there in my opinion.
 
I'd second Dessi's recommendation of Head First. I got their java book after floundering for a while and it did what it says on the tin, got the ideas across. I found the style a bit annoying after a bit but by then I was on a fairly heavy java book. Decades of procedural programming and (it turns out) half-assed C++ left me with a lot of wrong preconceptions.
 
Decades of procedural programming and (it turns out) half-assed C++ left me with a lot of wrong preconceptions.

I suspect that easing a procedural programmer into OOP through something like C++ is a very bad way to teach OOP. I have friends and coworkers who've done exactly that, and 10 years later they still have only a vague concept of OOP. They know how to create simple objects and classes in C++, but aren't quite sure why they would ever do that. In unguarded moments, they may admit that they view the OOP stuff as clutter.
 
I think that's very true. I wrote a few classes and programs but until I started on Java and got to grips with stack I think I really just thought of OO as a cousin of data-driven modeling. Now I'm struggling with spring dependency injections. Please sir, may I leave? My brain is full.
 
I think that's very true. I wrote a few classes and programs but until I started on Java and got to grips with stack I think I really just thought of OO as a cousin of data-driven modeling. Now I'm struggling with spring dependency injections. Please sir, may I leave? My brain is full.

I always had the impression OO was intended for data-modeling when it was first conceptualized, then Java came around and evangelized the view that OO the backbone for whole architectural systems. Now our entire industry is full of OO abstractions and indirection so high level you can't figure out what code is actually executing without running it.

I get the feeling monolithic, complex business applications get that way because they use OO, not the other way around.
 
Last edited:
I always had the impression OO was intended for data-modeling when it was first conceptualized, then Java came around and evangelized the view that OO the backbone for whole architectural systems. Now our entire industry is full of OO abstractions and indirection so high level you can't figure out what code is actually executing without running it.

Yeahhh . . . I feel your pain on that one. In theory, you don't need to know what the code on the other side of the interface is doing, because the code on the other side is working perfectly, and the interface is properly designed, and you understood exactly how to use the interface. And if all of those things are true, then the opacity of the interface is actually good, because it helps you focus on your own code and it makes it difficult for you to use the interface in ways that weren't intended.

In practice . . . once in a great while :rolleyes:, something will go wrong, and you'll need to figure out whether the problem is on your side, on the other side, in the interface description, etc. And if you're programming to an interface, trying to figure out exactly what is being done by whichever of 17 different IWayTooClever-compliant classes was created by some context-sensitive ICleverFactory, for which you don't have the context and may not even know which ICleverFactory implementation was being invoked . . .

<sigh> Sometimes there's just not enough diet Dr. Pepper, Cheetos, and Monty Python quotes in the world.
 
I always had the impression OO was intended for data-modeling when it was first conceptualized, then Java came around and evangelized the view that OO the backbone for whole architectural systems. Now our entire industry is full of OO abstractions and indirection so high level you can't figure out what code is actually executing without running it.

I get the feeling monolithic, complex business applications get that way because they use OO, not the other way around.

Yeah. We have created that problem ourselves at work.

We have a term for it now. We call it "premature generalization".

The problem is that people don't see OO as being there to solve a problem, instead they make every problem look like an OO problem.
 
Last edited:
Yeah. We have created that problem ourselves at work.

We have a term for it now. We call it "premature generalization".

The problem is that people don't see OO as being there to solve a problem, instead they make every problem look like an OO problem.

When the only tool you have is a hammer, every problem starts to look like a nail.

Some of you might be interested in this entertaining Wikipedia page:

http://en.wikipedia.org/wiki/Antipattern
 
I suspect that easing a procedural programmer into OOP through something like C++ is a very bad way to teach OOP. I have friends and coworkers who've done exactly that, and 10 years later they still have only a vague concept of OOP. They know how to create simple objects and classes in C++, but aren't quite sure why they would ever do that. In unguarded moments, they may admit that they view the OOP stuff as clutter.

Agreed. One of the most important features of object oriented design IMHO is interfaces, which is not a feature of C++ (at least, it wasn't many years ago when I learned it). I've found that many developers are either resistant to using them, or even worse, some will create an interface for every class without understanding why they should be used.
 
While it's true that C++ doesn't have, explicitly, interfaces, it is trivial to create them:
Code:
class InterfaceForWossname
{
   public:
      virtual ~InterfaceForWossname(); // should always have virtual destructors
      virtual void method1(const std::string &arg) = 0;
      virtual std::string getSomeValue() = 0;
};

...
class MyWossname: public InterfaceForWossname
{
   public:
    ... implement InterfaceForWossname
}
Behaves pretty much exactly like an interface, although - being C++ - there is always the temptation to sneak implementation or other items into the interface class.

ETA: Key is the "interface" class contains only pure virtual methods.
 
Last edited:

Back
Top Bottom