I can't begin to express how much I agree with this. While life without Visual Studio would be painful, hiring programmers that learned all they know in Visual Studio makes me want to cry. I've interviewed programmers with "10 years of ASP and ASP.NET experience" that don't know what an object model is.
If you want to be self-taught, steer clear of the "<insert language here> in 21 days" variety and learn the concepts of object orientation and data structures before learning the syntax of a specific language. I'd even say start with this wikipedia page (and those linked) just go learn the concepts involved. Then pick your language and find a book that talks about design for that language.
There are already one or two published high-end games (I'm drawing a blank right now) that used C#. There is GarageGames upcoming (it's still in beta) Torque X, the .NET version of a game platform for their Torque Game Builder for 2d games (GarageGames is at the core the guys who originally wrote Tribes and Tribes 2). Biggest drawback right now to XNA is that there isn't a quality network stack. There are several in the C/C++ world (such a TorqueNetworkLibrary, RakNet, etc) but the .NET and Java landscape is pretty barren (and I don't count Sun's "Sun Games Server" as such). Also, I know that that NCSoft has a few key developers working on a Java 3D engine (available to the community as the JMonkey) and was recently.
Unfortunately, with XNA (and same with ASP.NET too), there is too much emphasis on making things "easy" for the "drag-n-drop" coder with less regard to professional and enterprise quality level programming. But another topic, as I could rant on that for hours.
And as another point-in-case, J2EE (although its not called JEE) has been used for nearly 10 years as an application stack for building enterprise level web applications and back-ends.
I'd love to get into programming from a general knowledge type angle. After 25 years of being around computers it kind of sucks that I use software everyday but have no idea how programs are made at all.
take a look at what i linked and research "uml" a little ... it will teach you a lot of the fundamental things you need to know about programming from a higher level point of view which is where you should start
unless you want to become a bottom up asm kind of guy
I'm going to say that in my opinion you should just grab some tutorials, get an IDE and then start programming. I wouldn't worry about the big picture too much until you need to, the best learning is done through hands-on practice. Well for me it is anyway.
The Classy Way : [Credit to Filur for this one, the damn show off that he is]
<?php php class FizzBuzz_Number { public function __construct($int) { $this->scalar_value = (int) $int; } public function __toString() { $fizz = (bool) is_int($this->scalar_value / 3); $buzz = (bool) is_int($this->scalar_value / 5); if ($fizz && $buzz) { return 'FizzBuzz'; } elseif ($fizz) { return 'Fizz'; } elseif ($buzz) { return 'Buzz'; } else { return (string) $this->scalar_value; } } } class FizzBuzz_Runner { public static function Run() { foreach (range(1, 100) as $number) { echo new FizzBuzz_Number($number), PHP_EOL; } } } FizzBuzz_Runner::Run(); ?>
If you can past the FizzBuzz test, then your already a lot better then most of the people who call them selfs computer programmers. Grok'ing programming is very important these days, but we see more and more that people who claim to be programmers really don't know how to turn on the computer, let alone program one.
LOL, Yeah. Enterprise, funny you should say that too, as I use that example as a the entrance exam of sorts to get into programming for the company I work for. That's what filur come up with. We giggled for a while about that one.
darktimes' example is exactly the reason why no one should start out with java or anything .net
i havent dug into either one yet but from what ive seen they appear to require you to put a lot of essentially useless overhead around the actual code to make it do anything in the first place
Private Sub Form_Load() Select Case MsgBox("This is easy too, right?", vbYesNo, "VB6 Example") Case vbYes: MsgBox "Damn right!" Case vbNo: MsgBox "Lies!" End Select End Sub
I fail to see how anything within the code I posted was essentially useless, except arguably the function of the program itself.
namespace NotAnEnterprise { class Program { static void Main(string[] args) { System.Console.WriteLine("Not an enterprise application."); } } }
First we have the namespace, which is used to stop your class names clashing with those in other libraries and programs. This is optional by the way.
Then we have the Program class deceleration, and seeing as everything in C# is an object, this is pretty essential.
We then declare our Main method, which is marked static to show that the Program class does not need to be instantiated for Main to be run, then void which is of course the return type of the method, last we have our optional command line arguments string array.
Finally we go into the System namespace, then into the Console class of that namespace, and pass our string literal to the WriteLine() method, which sends it to the standard output.
I'd claim the opposite. Anyone can learn the essence of calling a command that executes some intrinsic part of the language. But for any decent size program (not some one of script), structure of the code becomes absolutely vital for the extendability and maintainability of the application over its lifetime. A object oriented language forces a lot of boilerplate that for Hello World and it's ilk appears to be significant effort, but for any real program become negligible. Meanwhile some basic structure has been instilled in the program logic.
Mind you, OO doesn't mean you can't write crap. You can over- or under-design your model and getting it right is not deterministic. Only more reason to start with design fundamentals before learning the syntactic nitty-gritty of a particular language.
[color=#ff0000]namespace NotAnEnterprise { class Program { static void[/color] Main([color=#ff0000]string[] args[/color]) { [color=#ff0000]System.Console.[/color]WriteLine("Not an enterprise application."); } [color=#ff0000]} }[/color]
Most of that is either OOP overhead, that serves no other purpose than to confuse the beginner, or language conventions you´re forced to abide by even if they dont serve any paricular purpose (args, calling a few silly classes to get it to print something).
It forces you to learn a lot of syntax and a relatively complicated paradigm, before you can even get to the point where the program does something as simple as printing a line to the console.
This article, those who want to do the test i linked to earlier dont read this until youve done it, http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf claims otherwise (they claim its a paper but its rather informally written).
IMHO the main hurdles the article describes are correct; at least from my own experience.
Grasping the idea behind OOP isn´t all that hard once you´ve got someone to the point where hes got some basic understanding of coding, but first and foremost the things he has to learn are:
1) syntax and that its essentially arbitrary and that code is meaningless without it
2) iteration and recursion as the very basics of programming
Now if you´re going to start with that code snipplet up there (I think it was C#) which has tons of syntactic overhead for basically nothing youre just going to confuse him.
At the end of the day the only syntax that _really_ matters in that thing is {print "hello world"} and understanding the way it´s evaluated. In essence even the main{} stuff could be dropped since it serves no other purpose than to make it compileable which would not be needed in an interpeted language.
So IMHO you should start out with a language that has a simple easy and most of all consistant syntax, ie. scheme. Then from there go on to teach some basic methods of writing code (iteration, recursion) and the trail of thought you should employ (top to bottom) (even though you often wont in real live).
You´re both making it sound like OOP is _the_ holy grail of programming and that you should teach it first before you get to the point of teaching someone how to actually do something with it.
If you look at it from above its just a convention of how to combine functions to a complex system. The actual code, the thing you really need to learn in the first place, is however contained within those functions and not in the glue you put around them.
OO is not the holy grail, but currently it is the predominant paradigm in programming today, so understanding it is definitely beneficial, no matter what your goals are.
And I do believe that code structure, data structure and control flow are language independent concepts that should be learned prior to figuring out any particular languages specific syntax for printing out a line of text. You can find the commands the perform specific actions in your reference documentation, but it won't tell you what's a good or bad way of structuring your code.
True but how are you going to teach those without establishing at least some kind of pseudo code?
To quote myself:
Thing is youll need to have some kind of way of talking about these things, some language be it an actual one or some pseudo code that helps you express these ideas about structure (btw on a side note I don´t think data representation is something you should put that much emphasis on when you begin to learn about coding).
See... this is exactly what I'm talking about... 
haha